做农业AI项目踩过的坑多了你会发现一个绕不开的事实通用大模型在农技问答、病虫害识别、土壤诊断这些场景里经常一本正经地胡说八道。把“黄瓜霜霉病”答成“缺镁”把“水稻分蘖期”说成“拔节期再施肥”这种错在演示Demo里能忍真到田间地头就是事故。所以当团队决定把DeepSeek大模型微调方案引入农业科技系统时我一开始就清楚这不是跑个微调脚本那么轻松的事。从数据采集与预处理、模型选择与配置到微调方案实施、系统集成与部署再到项目评估与优化每一环都是一场硬仗。这篇文章是这次完整过程的复盘。我不会只讲“我成功了”的光鲜部分更多是记录那些走了弯路之后才算明白的细节农业数据到底怎么洗才干净、LoRA参数怎么定才不过拟合、模型参数微调到什么程度才敢放到生产环境、上线之后为什么回答又开始飘。对于已经在跑通用对话场景、想做农业垂直方向深挖的团队或者刚接触大模型微调、准备进入农业信息化领域的技术同学这份记录应该能帮你省掉不少试错时间。1. 项目整体思路与选型考量1.1 为什么农业场景不能只靠提示词工程很多人上来就问为什么不直接封装一个在线通用大模型API写一套农技提示词就完事了我的回答是可以但效果大概率兜不住。农业场景有几个让纯提示词工程崩溃的特征。第一是知识长尾极其严重。主流大模型训练数据里农业内容占比本来就低而真正的农业知识往往高度本地化同样是“玉米施肥”黄淮海夏玉米区和东北春玉米区的方案差着十万八千里这种信息在大模型训练语料里几乎抓不到。第二是专业术语和口语描述之间存在巨大鸿沟。农户不会说“霜霉病”他们会说“叶子上长了一层白毛毛”不会说“pH值”会说“地发酸”。通用模型缺乏这种语义映射能力。第三是需要私有化部署。农业数据里有地块坐标、产量、用药记录等敏感信息很多项目根本不允许把这些数据送到在线API去。综合下来唯有私有化部署的开源基座模型加领域微调才是能长期落地的技术路线。这里要纠正一个偏见微调不是替代RAG检索增强生成两者是配合关系。微调解决的是“模型拿到问题后能不能用农业领域的方式思考和表达”RAG解决的是“回答里的事实和数据从哪里来”。我这次项目的主线是微调但后面部署阶段仍然挂了知识库兜底这个后面细说。1.2 选DeepSeek做基座模型的几个实际理由选基座模型不是看谁参数多、谁榜单分高而是看它在目标场景下好不好用。我们当时对比了几个开源模型最终在DeepSeek系列上定了方向理由其实很朴素。第一是中文基础能力扎实。农业问答里很多句子是半口语化的长句掺杂方言、作物名、病害俗名DeepSeek系列在中文语义理解上明显占优微调前做零样本测试它对农技问题的“理解程度”就比其他模型高出一截这意味着微调时能把更多算力花在学领域知识上而不是重新教它中文。第二是上下文窗口够用。我们的农技问答经常需要把一段完整的“症状描述环境条件过往操作”放进去动辄上千字上下文长度不够的话很多有效信息会被截断。DeepSeek系列在长文本上表现比同量级模型稳这直接关系到微调之后的多轮对话质量。第三是生态和部署灵活。它开源了不同量级的版本从7B级别到更大规模都有给了我们按算力选型的空间。我们在实验期用7B级版本跑通流程如果效果不足再换更大模型这种渐进路线在项目排期里非常友好。1.3 技术路线全貌五步走的主线整个项目是按照五个阶段推进的数据采集与预处理、模型选择与配置、微调方案实施、系统集成与部署、项目评估与优化。对应到工程上其实是一条从“喂什么”到“怎么训”再到“怎么用”的完整链条。我习惯先用一张表确认每个阶段的交付物没有交付物就不进入下一阶段这在多部门协作时尤其重要阶段核心交付物关键验收标准数据采集与预处理清洗后的训练集、验证集、评测集样本量达标、格式统一、无敏感信息模型选择与配置基座模型选定、训练参数方案显存估算通过、实验计划可执行微调方案实施微调模型权重、训练日志、评测结果评测集分数达标、无明显过拟合系统集成与部署推理服务API、前后端联调、监控日志并发稳定、响应时延满足业务要求评估与优化上线后效果报告、迭代优化方案关键指标持续改善、成本可控一句话概括整个方案的核心逻辑让模型先“懂农业语言”再用知识库“查农业事实”最后靠评估体系“守农业质量”。2. 数据采集与预处理把“脏乱差”的农业数据喂给模型之前2.1 数据来源与采集渠道农业数据的第一个特点是来源极度分散。我们当时梳理下来至少五个源头要处理。传感器设备数据土壤墒情、温湿度、光照、EC值等结构化数据来自项目试点区域布设的物联网设备。这类数据最大的问题是格式五花八门不同厂家输出的JSON结构不一样时间戳时区不一致缺失值和异常值比例高。农技问答历史数据团队积攒了几年的农户线上咨询记录包含问题、专家答复、追问这是最宝贵的语料但同时也最乱大量语音转文字的错别字表情符号商品推广链接。农业书籍和资料出于合规考虑只采集了公开的、可授权的技术手册和种植规范。用OCR转出来的文本有大量断行和乱码表格数据变成了一堆无意义的符号。病虫害图像描述农业专家对典型病虫害的图片描述文本比如病斑颜色、位置、形态变化这些用于构建模型对“视觉症状”的文本理解能力。天气与农事日志试点区域的公开天气记录配合农事操作记录用来构建“天气异常时应该如何应对”这类推理型问答。采集阶段的经验法则是宁可源头多不可后期补。刚开始我们只盯着问答历史数据后来发现只靠问答样本训练出来的模型遇到“低温寡照天气下番茄应该怎么管理”这种结合天气的复合问题时表现很差因为训练数据里根本没有天气和农事的关联样本。后来补了天气日志和农事记录效果立刻不一样。2.2 清洗、去噪与格式化这一节全是血泪。农业文本的“脏”超过很多人的想象。第一步是去噪清洗。我们需要去掉URL、表情符号、无意义字符、重复段落OCR内容要统一处理断行。这里给一段我当时用的Python清洗片段思路比代码本身重要import re def clean_agri_text(text: str) - str: # 去掉链接和HTML标签 text re.sub(rhttp\S|www\.\S|[^], , text) # 去掉表情符号和特殊符号 text re.sub(r[\U0001F000-\U0001FAFF]|[\u2600-\u27BF], , text) # 统一换行和多余空格 text re.sub(r\s, , text) # 处理OCR常见的断行粘连数字和单位之间乱码 text re.sub(r(\d)\s([斤亩克毫升]), r\1\2, text) return text.strip()第二步是单位统一。农业数据里单位混用是重灾区。“每亩用2公斤”和“一亩地使2千克”是同一个意思但对模型来说就是两个完全不同的表达。我们把重量、面积、浓度、温度都做了归一化映射比如“公斤/千克/斤”这一组按比例转成统一单位但保留原表述在回答里的使用习惯训练时作为同义表达增强。第三步是敏感信息过滤。涉及农户真实姓名、电话、详细地块坐标的内容必须打码或删除。这里有个容易忽略的坑不要只做规则匹配还要人工抽检。因为电话号码可能以“找小王”“打幺三几那个电话”这种口语形式出现正则很难完全覆盖。第四步是语义去重。农业问答里相似问题太多了“西红柿卷叶怎么办”“番茄叶片卷曲什么原因”“圣女果叶子发卷”本质上高度相似。如果不做去重模型会过拟合到高频表述换个问法就答偏。我们当时用embedding向量做聚类去重相似度超过阈值的样本只保留代表性几条同时确保保留问题表述的多样性不让训练集变成同义句集合。2.3 对话样本构造与配比策略原始语料是零散的而微调需要的是结构化的“提问-回答”对甚至是多轮对话序列。这一步决定了模型最终学会的是“知识”还是“句式”。我们构造样本的核心规则是每个样本必须包含足够的上下文信息而不是简单的一问一答。比如这样的格式{ instruction: 请根据以下症状判断番茄可能得了什么病并给出防治建议。, input: 番茄中下部叶片出现水渍状暗绿色病斑湿度大时病斑背面有白色霉层近期连续阴雨棚内湿度长期超过90%。, output: 根据症状描述这很可能是番茄晚疫病。建议1. 及时清除病叶病果并带出棚外销毁2. 降低棚内湿度加强通风排湿3. 发病初期可选用代森锰锌等保护性杀菌剂严重时需咨询当地植保部门确认药剂种类和浓度。 }这个结构里我把书本上“晚疫病症状”的枯燥描述改写成了农户视角的观察语言同时把防治措施落到可执行颗粒度。微调模型学的就是这样一种“输入症状观察输出判断和行动建议”的映射关系。样本配比也是一个关键决策。我们把训练集按场景分成五大类并严格控制比例病虫害诊断与防治大约30%栽培管理约30%水肥管理约20%气象灾害应对约10%农机农资及其他约10%。这个比例不是拍脑袋定的而是参照了我们线上问答数据的真实分布。如果病虫害样本过多模型会形成“一切都往病害方向答”的惯性如果作物栽培样本太少模型在农事管理问题上会明显变笨。配比做好后训练出来的模型在各场景下的表现均衡很多。3. 模型选择与配置从基座版本到微调参数的落地决策3.1 基座版本怎么选不是越大越好模型选型的核心矛盾是效果和成本的平衡。农业项目往往没有互联网大厂那种烧算力的预算所以要学会在有限资源下选最优解。我们的经验是按“业务复杂度”和“数据量”两个维度来选。如果场景只是短文本问答、数据量在2到5万条7B量级的DeepSeek基座模型完全够用如果要做长文档阅读理解、复杂推理、或者计划接入多模态图像识别那就要考虑14B往上或者干脆用更大参数规模加量化方案。我们这次项目选择了7B量级起步核心原因是早期数据量不够大用大模型容易欠拟合或者过拟合小模型反而能更快收敛、便于调试。还有一个容易踩的坑不要追新追大。基座模型版本越新配套的Tokenizer、对话模板、训练脚本差异越大社区踩坑资料也少。农业项目追求的是稳定复现我们会优先选择发布满一定周期、有较多实践反馈的稳定版本而不是最新的实验性版本。3.2 关键训练参数配置与计算逻辑微调参数决定了训练能不能收敛以及收敛后的模型会不会失去通用能力。我当时确定的配置参考如下具体数值因数据和算力而异但逻辑是通用的参数推荐范围我们项目实际使用选择理由学习率LoRA1e-4 ~ 3e-42e-4学习率太大会让通用能力被破坏太小则领域知识学不进去训练轮数2 ~ 53轮数过多容易过拟合3轮在5万样本上表现最佳Batch Size4 ~ 164配合梯度累积受显存约束小batch配合梯度累积等效大batchMax Length512 ~ 20481024覆盖90%的农技问答长度太长浪费算力太短截断关键上下文LoRA Rank8 ~ 3216rank越大可学习的表达能力越强但过大会增加过拟合风险LoRA Alpharank的1~2倍32控制LoRA权重的影响强度常用alpha 2 * rankLoRA Dropout0.05左右0.05防止微调阶段对训练集记忆过深这里说说几个参数背后的计算逻辑。学习率为什么这么关键因为微调阶段我们希望模型“在原有能力基础上加增量”而不是“推倒重学”。用生活类比基座模型已经是个读过很多书的毕业生微调相当于岗前培训培训力度学习率太大会把之前的常识冲掉太小又记不住岗位要求。LoRA Rank同理它决定了“岗位培训时记笔记的厚度”16是一个稳居中庸的选择复杂任务可以试32简单任务8就够。训练轮数需要结合早停机制动态判断。我们监控验证集loss的变化一旦发现验证集loss开始回升而训练集loss还在下降就说明模型开始背答案了这时候停止训练取验证集表现最好的那一轮作为最终权重。3.3 算力估算与训练时间预估开始训练前一定要把算力账算清楚否则跑到一半发现显存爆了前面的时间全部白费。一个粗略但实用的显存估算公式是显存占用约等于模型参数存储、梯度/优化器状态、激活值三者之和。以7B模型为例如果用BF16全参微调光模型权重就需要约14GB加上梯度和优化器状态再加上反向传播过程中的激活缓存单卡24GB基本是极限。所以我们的方案是用4bit量化加载基座模型再用LoRA方式只训练少量参数这样显存占用能控制在15GB上下单卡38GB左右的显卡就能跑起来而且训练速度并不慢。训练时间的估算也比较朴素。总训练token数约等于样本数乘以平均样本长度按5万条样本、平均长度600 token算一轮就是3000万token。根据显卡的实际吞吐量可以粗略算出每一轮所需时间再乘以训练轮数。实际项目里我们通常会预留30%的时间余量给参数调试和断点续训。4. 微调方案实施从训练脚本到评测闭环4.1 为什么选LoRA而不是全参微调微调方案的第一步是确认用全参微调还是参数高效微调。我们坚定选了LoRA理由有三点。第一是算力门槛低。全参微调7B模型的显存压力很大而LoRA只训练注入的低秩矩阵可训练参数通常只占模型总量的1%左右显存和训练时间都大幅下降。第二是通用能力保持好。全参微调很容易出现“灾难性遗忘”模型把农业知识学会了但普通对话能力、通用常识反而退化。LoRA因为冻结了原始权重等于在原模型边上加了一个“领域技能模块”通用能力几乎不受影响。第三是便于迭代和回滚。LoRA生成的权重文件很小几百MB就够我们可以在同一个基座模型上挂不同的LoRA适配器分别对应不同作物、不同地区的版本切换成本极低。这次项目我还额外加了QLoRA的量化加载技巧。简单说就是在加载基座模型时把权重量化到4bit然后插入LoRA适配器训练。这样做的唯一代价是训练速度略慢一点但显存占用大幅下降。用下来性价比很高。4.2 核心训练流程与脚本整个训练流程我拆成七个步骤。环境准备阶段用到的核心库是PyTorch配合Transformers微调组件用PEFT。下面是我简化后的训练脚本结构关键在配置和回调逻辑不是完整代码from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training # 1. 以4bit量化加载基座模型 model AutoModelForCausalLM.from_pretrained( deepseek-ai/deepseek-llm-7b-base, load_in_4bitTrue, device_mapauto ) tokenizer AutoTokenizer.from_pretrained(deepseek-ai/deepseek-llm-7b-base) model prepare_model_for_kbit_training(model) # 2. 配置LoRA参数 lora_config LoraConfig( r16, lora_alpha32, lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) # 3. 设置训练参数 training_args TrainingArguments( output_dir./agri_deepseek_lora, per_device_train_batch_size4, gradient_accumulation_steps2, learning_rate2e-4, num_train_epochs3, logging_steps50, save_steps500, evaluation_strategysteps, eval_steps500, load_best_model_at_endTrue, fp16True, ) # 4. 开始训练 trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, eval_dataseteval_dataset, ) trainer.train()几个容易被忽略的细节Tokenzier的pad_token要手动设置否则训练时会随机报错对话模板里的特殊token比如|im_start|这类必须在清洗数据时保持一致训练和推理时的max_length要保持一致否则模型在生成长度接近上限时行为会不一样。训练过程中我会同时盯两个指标训练集loss和验证集loss。比较好的状态是两者同步下降最后验证集loss趋于平稳。如果训练集loss降到零点几但验证集loss很高基本就是过拟合了这时候优先回调学习率、增加数据多样性而不是继续加轮数。4.3 评测闭环微调不是训完就算完我见过太多团队微调完模型拿三五个问题试了试觉得“回答像样了”就宣布完成这是极其危险的。我们专门建了一个300条样本的农业评测集按病虫害、水肥、栽培、气象、农机五大场景分类每条评测样本都经过专家审定标准答案并给每个场景设置了及格线。评测采用自动评估加人工打分的双重机制。自动评估主要看生成的答案和标准答案的语义相似度、关键实体召回率比如“代森锰锌”这个药名有没有出现“晚疫病”判断是否正确。人工打分则更细从信息准确、步骤可执行、语气自然、安全合规四个维度各打1到5分。评测维度微调前得分微调后得分说明病虫害识别准确率62%89%以关键病名/虫名是否判断准确为准农事建议可执行性41%83%专家按建议步骤能否直接落地判断回答语气自然度68%91%是否像真人农技员的表达方式无关问题拒绝率54%87%涉及用药安全等无法确认的问题是否建议咨询当地植保站评测集的价值不仅在验收还在回归。后续每迭代一版模型都要跑同一套评测集防止优化一个问题反而带崩另一个场景。这个习惯帮我们拦住过至少三次“看起来变强、实则整体变笨”的坏版本。5. 系统集成与部署让模型真正跑在田间地头5.1 推理服务的API封装微调完的模型不能直接丢给前端用需要包一层推理服务。我们的做法是用FastAPI做模型服务层对外暴露统一接口。请求体设计成兼容主流对话格式的JSON前端和业务系统对接起来几乎没有额外成本。{ model: agri-deepseek-lora, messages: [ {role: user, content: 番茄中下部叶片出现暗绿色水渍状病斑湿度大时有白霉怎么办} ], temperature: 0.3, max_tokens: 500 }这里有个非常关键的经验农业问答场景的温度参数一定要调低。通用对话喜欢一点随机性让回答不那么机械但农技场景下随机性就是风险。temperature设置0.3左右生成结果基本稳定如果设成0.8同一问题每次回答的药剂名都有可能变这在生产环境完全不可接受。遇到“不知道”的边界问题宁可让模型直说“建议联系当地植保站”也不能让它编。5.2 与农业业务的对接落地模型服务要真正产生价值必须和业务系统打通。我们项目里主要对接了三个场景。第一个是农户端小程序问答。农户在对话窗口用语音或文字描述问题后端通过API调用推理服务返回判断和操作建议。这个场景对时延敏感我们要求首字返回时间在3秒内所以部署时用了流式输出模型边生成边推送。第二个是物联网设备告警联动。土壤湿度传感器持续上报数据当系统判断墒情异常时不直接发一段干巴巴的数字告警而是把“当前土壤湿度、最近降雨情况、作物当前生长阶段”拼成一段上下文让模型生成一段通俗的农事提醒发给种植户。这里微调模型的价值体现得非常明显。第三个是农技知识库问答。把专家的技术文章切片后入库通过向量检索召回到相关片段连同用户问题一起交给微调模型由模型组织成通顺的答案。这就是前面说的“微调为主、RAG兜底”的架构。5.3 部署形态与运维注意点部署形态的选择要先想清楚使用场景。集中式GPU服务器适合所有请求走云端的场景稳定、好扩容但如果田间信号差、希望离线可用就得考虑边缘部署。我们当时的折中方案是云端部署主服务同时把模型量化为INT8版本在试点基地的本地服务器上也放一套网络中断时自动切换。运维中有几个很容易翻车的细节。第一是版本管理。模型文件、LoRA权重、对话模板、评测数据集全部要打版本号否则过两周回头查问题根本不知道线上跑的是哪个参数组合。第二是回滚机制。新模型上线前先在影子环境跑一天对比新旧模型的回答质量和拒绝率发现问题一键回滚旧版别在田间场景逞强。第三是季节因子。农业知识的时效性很强今年推荐的品种和防治方案明年可能就过时了所以部署层要留出定期换模型的通道最好是自动化流程每到一个农事节点就触发一轮重评估。6. 项目评估与优化上线只是起点6.1 建立可量化的业务评估指标上线之后的评估体系比训练阶段的评测集更复杂因为要加入真实业务指标。我习惯把指标分成三层来盯。第一层是模型质量指标回答准确率、关键实体正确率、拒答率、多轮对话一致率。这些指标通过线上日志抽检加自动评测定期更新。第二层是业务效果指标用户提问后的采纳率农户看完了是否继续追问、问题重复率同一个问题被反复提交说明回答没解决、农事建议的合规性有没有涉及禁用农药。第三层是成本指标单次请求的token消耗、GPU利用率和平均响应时延。这个三层指标模型真正起作用是在优化阶段。比如我们发现某个问题回答准确率不低但用户反复追问“然后呢”说明“操作步骤输出不完整”才是痛点单纯提升回答准确率解决不了。这时候就需要回到数据层面补充更多包含完整步骤链条的训练样本。6.2 数据闭环与持续优化手段“项目上线后优化”最大的误区是一上来就调模型参数正确的顺序是先看数据再动训练。我们从线上日志里定期捞取表现不好的问题按场景归类挑选典型案例交给农业专家重新作答形成补充训练集。这个闭环跑起来之后模型隔两周就多学会一批它之前答不好的问题。在此基础上优化手段是分层的。第一层是数据增补补足长尾场景。第二层是训练策略调整比如对某一个薄弱场景单独做一轮小学习率的增量微调只更新LoRA权重不动其他权重。第三层才是换结构或换参数比如增大LoRA Rank、增加上下文长度。把顺序反过来很容易陷入“调参救不了烂数据”的泥潭。6.3 用RAG和人工反馈做加法微调模型的短板在于事实性知识的更新速度。田间地头的实际问题上经常涉及新品种、新药剂、新的天气模式训练数据跟不上。所以我们同时接入了RAG系统。RAG的具体做法是通过向量库存储农技专家的实时文章、本地天气信息和品种手册用户提问时先检索相关段落再把这些段落塞进提示词让模型“参考以下资料进行回答”。这样模型既保持农业专业表达方式回答又有依据幻觉率大幅下降。在部署初期RAG对模型准确率的提升甚至比继续加大训练数据还要明显。这里也提醒一句加入RAG之后评测方式必须跟着变不能只测模型训练集的旧问题要专门构造需要检索最新资料的测试问题验证模型是否真的会“引用”而不是“无视”检索到的信息。6.4 成本与效益的对照分析农业项目的预算控制通常比互联网产品严格得多所以成本效益要提前算清楚。我们做过一个对比如果直接采用纯在线通用大模型API按每万次问答调用量计算一年玩下来是一笔不小的订阅费而且数据全部出域很多农业信息化项目根本接受不了这个前提。自建微调方案的成本主要集中在一次性算力投入和人工标注。一次性训练花掉的费用和调用在线API大半年差不多持平但换来的是数据私有化和一次训练多次部署的边际递减成本。对一个要服务上千名农户、每天成千上万次问答的项目来说部署模式反而更省钱。成本项微调自建方案纯粹大模型API方案数据安全性私有化不出域出域依赖平台政策领域准确性持续可控随微调迭代受限于通用能力需要大量提示词调优长期成本前期投入高按次成本低按次累积成本高维护复杂度需要专职团队运维简单这个账算清楚之后决策就很坚定了。7. 常见问题与避坑实录7.1 典型问题排查速查表把整个项目过程中的高频问题整理成一张速查表遇到同类问题可以少走很大弯路。问题现象可能原因处理方式训练loss下降很慢或震荡学习率过高、数据长度不一致、batch过小降低学习率到1e-4左右检查数据是否全部截断到同一长度训练集loss很低但验证集loss高过拟合增加数据多样性降低训练轮数LoRA Dropout提到0.1模型回答出现重复句子训练数据里有大量重复表述、温度设置偏高清理语义重复样本temperature降到0.3以下打开重复惩罚模型把通用常识也“微调”没了学习率过大、全参微调导致灾难性遗忘改用LoRA降低学习率加入通用语料混合训练对农技术语判断正确但步骤不完整训练样本的target输出太简短重新整理标准答案把防治步骤写完整再训练并发上来后响应延迟飙升推理服务未做并发控制、GPU利用率打满加排队和流式输出机制必要时部署多副本换季之后模型还在回答过时方案模型权重没有及时更新建立农时节点评估机制到期触发重新评测和增量微调这张表里的前三条是我们项目真实踩过的坑。尤其是重复句子这个问题一开始我以为模型出BUG了查了半天才发现是训练集里同一句“建议加强通风”出现了几百次模型把这个表达焊死在了输出里把这条高频样本删掉、换成多种表达方式之后问题立刻消失。7.2 实操避坑心得汇总最后集中说几个我想提醒所有做类似项目的同行注意的点。不要让微调模型去背培训资料原文。很多团队把专家手册的整段内容放进训练集指望模型“背下来”结果模型把原文背得半熟不熟却失去了灵活应对农户各种问法变体的能力。正确做法是把资料内容拆碎人工改写成语义一致但表述不同的样本模型的泛化能力才会起来。不要忽视对话模板的一致性。基座模型在预训练时有固定的对话模板微调时如果你自定义的模板和它不一致模型会学得很痛苦。我们中途换过一次模板导致同样的模型回答质量明显下滑排查了大半天才定位到是模板问题。这条建议是免费的。不要为了“省人工”完全用大模型自动生成训练数据。我们尝试过批量用在线通用大模型生成农业问答对生成速度快但错误率很高尤其是农药剂量和作物生长阶段判断这些需要精确知识的地方必须人工逐条过。后来我们的做法是用大模型辅助改写专家提供的种子答案而不是直接让大模型从头造答案。不要在评估集上自欺欺人。如果评估集本身就是从训练集里抽出来的那测出来的分数再高也没有意义。我们专门把评测集设计成独立抽样并且每隔一段时间从线上日志里补充新问题保证模型不是“背会了考题”。如果只让我留一条经验那就是把“微调完成”当成项目起点而不是终点。我也曾因为测试集分数不错就把模型放了上去结果农时一到新旧技术交替回答里还残留去年的防治方案。后来把模型评估做成了常态化流程每两周用新一批农技问题回测一次这比任何花哨的参数调整都管用。农业跟别的行业不太一样它的知识是跟着节气、品类、土壤实时变的模型也不能一劳永逸。把数据闭环和评估机制转起来这个项目才真正算落地了。