1. 从“哄”说起我们和AI的第一段磨合期去年我们团队接了一个内部智能客服的项目技术选型确定用大模型做核心问答。起初一切顺利简单的业务问题它回答得像模像样我们一度觉得“AI落地也就那么回事”。但真正进入生产联调之后问题接踵而来——模型偶尔答非所问、输出格式不稳定、同一个问题换个说法结果就不一样。那段时间大家最常做的事就是凑在一起围着提示词改来改去试一个词、调一个标点碰运气一样等它输出一个“看起来对”的结果。后来我们内部管这个阶段叫“哄”模型把大模型当成一个闹脾气的小孩子反复试探、讨好、猜它的心思。“哄”出来的东西最可怕的不是它经常错而是你不知道它什么时候会错。我印象非常深的一次某条规则类问题在测试环境里连续跑了一周全是正确的我们以为稳了结果上线当天因为用户换了种问法模型直接给出一段结构完全合法但内容错误的答案下游系统照单全收数据就乱套了。这种问题靠“多试几次”“换个说法”根本解决不了。我们开始意识到光在提示词层面使劲远远不够真正要把大模型用在生产环境需要一整套工程化方法去约束它、验证它、兜住它的底。这篇东西就把我们从“哄”到“驯服”的完整经历写下来包括思路转变、具体方案、实操步骤和踩过的坑。如果你也在做类似的事刚好可以拿去当参考。2. 为什么提示词工程救不了生产环境2.1 提示词的脆弱性从哪来“哄”的核心手段是不断改提示词但提示词工程的脆弱性本质是模型本身的概率性带来的。同样一段输入大模型每次解码都从概率分布里采样温度参数不为零时输出天然带随机性。哪怕把温度调到0不同批次的推理也可能因为算子优化、量化误差出现细小差异这些差异在日常交互里察觉不到放到生产流程里就会被下游逻辑放大成严重故障。我们当时的做法是在Prompt里写“你必须返回JSON格式”结果模型大部分时候确实返回了JSON但偶尔会在JSON前后带一段解释性文字或者把单引号当双引号用解析器直接报错。为了处理这个我们又在Prompt里加了一句“不要输出任何其他文字”情况好了一些但又有小概率出现Markdown代码块包裹。于是再去加各种“禁止”条款Prompt越来越长开始挤占上下文空间模型的注意力也被稀释正常回答的质量反而下降。这就是典型的提示词工程死循环。想深一层“哄”之所以存在是因为我们在用一个自然语言工具却希望它像程序一样精确。但自然语言本身就有歧义模型对指令的理解是概率性的它并不像编译器解析语法那样严格。用户口里的“大概”“尽量”“可以吗”都会让它产生不同理解更不用说我们还经常在指令里塞一堆业务术语和缩写模型只能靠猜。后来我们统计过早期线上出现的大部分格式或解析错误根源都不在模型能力而是我们的指令没有给它一条真正没有歧义的路。那段时间每天都像打地鼠修好一个冒出一个永远有人在盯着对话记录看模型又“抽风”了没有。2.2 稳定性要求逼着我们换思路也是从那时候开始我们问了自己一个问题我们到底是在做产品还是在做概率游戏如果是概率游戏那每次发版之前靠人肉试几遍根本没法保证质量。我们需要的是一套能衡量“模型表现是否达标”的机制以及一套当模型本身不完美时依然能让系统保持正确的架构。这套机制和架构就是后来我们说的“驯服”。我打个比方哄模型像是在和一只猫商量“请你在猫砂盆里上厕所”话说得再好听猫心情不好照样乱来驯服则更像是给猫做一个围栏、铺好猫砂、定期检查猫愿不愿意配合不那么重要重要的是系统设计保证它只能在这个框里活动即使偶尔越界也有兜底。这个类比虽然糙但方向是对的。从那以后团队里再有人提“再调一下Prompt试试”的时候我们都会先问一句评测集里有没有对应case如果评测集都还没有试出来的“好”毫无意义。3. 驯服模型的第一步把评测做成门槛3.1 不建评测集所有优化都是盲人摸象我们决定从零开始建评测集。一开始团队里有人觉得没必要理由是“我们每天测了那么多条心里有数”。但“心里有数”恰恰是最不靠谱的——每个人测的那几十条覆盖面有限不同人对“正确”的理解也不一样。更致命的是今天觉得没问题的问题过一周你可能根本想不起来为什么当时觉得没问题。我们的做法是先拉线上近三个月的真实用户问题去掉敏感信息按业务场景分类再从每个类别里挑出高频、典型、边界三类问题一共凑了大约两百条评测样本。每条样本都写好标准答案或答案要点开放性问题只标“必须包含哪几个关键要素”不追求逐字逐句一致。评测集不求大但必须覆盖核心场景并且每一条都要有明确判定逻辑。这个工作看起来枯燥但它后来成了我们所有模型优化的尺子。建评测集合的时候还有一个小教训一开始我们把“边界问题”理解成极端刁钻的反面例子结果评测集里全是各种“如果用户骂人怎么办”之类的问题覆盖面严重偏了。后来我们发现真正的边界问题是那些“跟正例长得很像但答案完全不同”的case比如关键词相近但业务规则不同、需要区分两种相似产品型号的场景这些才最容易暴露模型的区分能力不足。调整之后评测集对线上问题的反映就准多了。3.2 评分标准怎么订评分这件事也要说清楚。我们把模型回答分成四个等级完全正确、部分正确、错误、无法回答。完全正确要求答案要点齐全且无明显误导部分正确是主要信息对了但细节有缺错误是事实性不对无法回答则是模型没接住问题。每次改提示词、调参数、换模型都在这两百条上跑一遍计算正确率和严重错误率两个核心指标。这里有个特别重要的心得不要把好看的数字当成一切。我们最初只盯着正确率后来发现正确率涨了但严重错误率也在悄悄涨——因为模型把一些边界问题回答得特别自信反而不如以前“老实”。后来我们把严重错误率设成红线指标只要它超阈值正确率再高也不准发版。生产环境里一个频繁给出自信错误答案的AI比一个经常说“不知道”的AI可怕得多因为前者会让用户相信错误信息后者至少还有机会转到人工处理。4. 束缚模型结构化输出与上下文管理的实战4.1 输出约束比想象中有用评测集搭好之后第一件要改的事是输出格式。我们彻底废弃了“在Prompt里求模型返回JSON”的做法改用结构化生成框架让模型按预设的schema输出并在解析前做严格校验。实际操作中我们在系统提示词里写明“你只负责提取以下字段并严格遵循给定格式”同时在输出端加正则和schema校验双重关卡只要解析不过就自动触发重试或转人工。这套做下来JSON输出问题基本绝迹。但是我要提醒一点结构化框架有它自己的学习成本而且太复杂的schema会让模型无所适从。我们的经验是schema保持扁平、字段尽量少能少嵌套就少嵌套嵌套层级一多模型出错率就会明显上升。另外涉及可选字段时宁可让模型输出空字符串也不要让它自由发挥“无此信息”之类的文字。因为自由发挥的文字格式不统一下游程序解析起来极其痛苦改规则都不知道从哪里改起。4.2 上下文管理是系统设计问题接着是上下文。很多团队拿到模型就直接把整本知识库塞进Prompt指望模型自己“翻书”结果上下文窗口够时效果尚可一旦问题变复杂、知识量变大模型就开始胡编。我们早期也干过这事后来才明白上下文不是仓库而是“工作台”——只放当前这一步处理需要的东西其他信息一律通过检索按需取用。具体实现上我们把对话拆成了三个结构系统提示词固定不变用来描述角色、任务和回答红线用户输入经过意图识别和实体抽取之后拼接成结构化的请求相关知识通过向量检索从知识库召回再以“参考材料”的身份附在输入里。三步分开之后模型看到的东西干净了很多不会因为无关信息被带偏也不会因为上下文过长丢失前面的关键指令。有一点容易忽略系统提示词的顺序对模型行为影响很大。我们做过一个对比同样的指令放在第一句和放在最后一句在长上下文场景下表现有明显差异。模型对开头和结尾的内容会更敏感中间部分容易被稀释。所以我们习惯把最重要的角色设定和输出要求放在开头把动态变化的参考材料放在中后段把“本次任务的具体要求”放在接近结尾的地方。这个顺序调整听起来玄学但实测下来对稳定性的提升很实在。5. 外部知识兜底让RAG真正干活5.1 从“背答案”到“查资料”知识密集型的问题靠模型背答案是靠不住的。我们的业务里有大量条款、政策类问题模型对这类内容的记忆既不全也不准一本正经编答案的概率非常高。后来我们给系统接入了RAG让模型从“凭记忆回答”变成“先查资料再回答”。这个转变是决定性的。但RAG不是加个向量库就完事。我们一开始天真地以为把文档切一切、灌进向量库就行结果召回的片段经常文不对题。查下来主要问题出在切分——最初我们按固定字数比如五百字一刀切把完整的一条条款拦腰截断语义断了向量检索自然召不回好结果。后来改成按语义段落切分再配合标题层级做父子分块召回质量一下就上来了。切分粒度这件事值得细说。切太粗一个块里塞太多内容向量表征会被稀释检索时相似度区分不开切太细语义不完整模型拿到的参考材料支离破碎。我们后来的做法是采用两级结构父块保持一个完整章节的语义子块是具体的段落检索时先命中子块再把它所属的父块内容一并交给模型。这样一个既能精准定位又能保证上下文完整效果明显好过单一粒度的切分。5.2 检索和生成要分开调RAG链路里“检索到的内容对不对”和“模型用没用对”是两回事。我们曾经碰到一个问题检索召回的文档明明是对的模型却视而不见自己跑去编答案。查了半天原因是Prompt里“参考材料”的位置放得太靠后被前面冗长的指令挤出了注意力范围。把参考材料移到用户问题附近、并明确告诉模型“优先使用下列参考材料作答材料中未提及的不要编造”之后这种情况大幅减少。还踩过一个坑是召回条数。最初我们设召回五条想着多点信息总比少了好结果模型被多条相似内容干扰反而答不准确。后来我们做了实验把召回数量从二调到六逐个对比发现三条效果最好既给足信息又不会杂乱。当然这个数字不是通用的知识库的文档风格、问题复杂度都会影响最优值。但方向是一致的给模型够用的而不是给模型所有的。我们还在检索端加了一个“不相关过滤”的逻辑。向量检索有时候召回的内容看着相似度不低但其实是另一个业务方向的内容混进去只会误导生成。我们在重排阶段给每一条候选内容打一个与当前问题主题的相关分数低于阈值就直接丢弃。这个动作很小但对最终答案质量的提升比想象中大尤其是知识库规模上去了之后靠向量相似度已经很难完全挡住语义漂移的问题。5.3 引用溯源不可省的一步RAG接入之后还有一个容易被忽略的点引用溯源。我们一开始做RAG只关心答案对不对没管答案的依据从哪里来后来出了两次线上争议用户质疑答案的来源我们却拿不出对应的文档依据非常被动。之后我们在系统里强制要求模型在给出关键结论时带上参考材料编号前端可以把编号对应到原文展示给用户。这个改动不仅改善了用户体验更重要的是让我们能在出问题时回溯“这个答案到底是从哪条资料来的”定位问题快了很多。6. 微调最后的手段也是最重的武器6.1 什么时候才轮到微调团队里有人一开始就提议“直接微调一个专用模型”我们一直压着没动。微调不是说不好而是它成本高、周期长、迭代慢一旦微调后面每次想改行为都得重新训练。对大部分应用场景来说先靠提示词加RAG把效果压到八九成剩下的边角再用微调补是最务实的路径。我们真正下决心微调是因为有一类特定格式的文书摘要任务提示词和RAG怎么调都达不到预期。这类任务语言风格高度固定、格式要求严格、输出的句式和框架几乎一成不变恰好是微调最擅长解决的场景。我们整理了两千多条真实业务数据做清洗和标准答案标注在开源底座模型上用低秩适配方式微调了一版效果提升非常明显格式规范和关键信息点覆盖都上了一个台阶。6.2 微调之后仍要回到评测集微调最容易被忽略的一步微调完的模型还要回到我们那两百条通用评测集上跑一遍防止它“偏科”。我们当时就遇到了一个典型问题微调后的模型在目标任务上表现很好但通用问答能力有所下降一些原本能答对的基础问题开始出错。后来调整了微调数据的配比混入一部分通用对话数据这个问题才缓解。如果你也在考虑微调我的建议是先用评测集把问题定位清楚确认是模型能力问题而不是提示词或检索问题再启动微调。微调数据宁缺毋滥数据质量比数据量重要得多。我们最初标注标准答案时为了图快让标注员自由发挥结果数据里同一类问题的答案风格天差地别模型学了反而更乱。后来改成先由一个人写了一批规范答案作为参照其他人照着风格改质量才稳定下来。7. 生产中躲不开的坑与排查经验7.1 幻觉问题防不胜防但可以降概率幻觉绕不开。我们做了三层防护第一层是上面说的RAG尽量让模型基于材料回答第二层是在提示词里明确“无法从材料中找到依据时直接说明不知道”第三层是下游再做一次关键事实点校验用规则或另一个小模型对关键结论做二次确认。三层都上之后严重幻觉率明显下降但不可能归零。我们对这个事的态度是允许它不会不允许它瞎说。有个经验想分享判断模型是不是在编可以观察答案的细节密度。真按材料回答的答案通常细节丰富、措辞有出处编出来的答案往往空洞、泛化还爱用“通常来说”“一般情况下”这类回避性措辞。后面我们会专门在建评测集时加了一个“是否有依据”维度人工评审时一眼就能看出来这条维度和事实正确率并不完全等价但对幻觉的捕捉很有效。7.2 版本漂移和多环境不一致大模型相关项目还有个常被吐槽的坑版本漂移。模型服务方或开源底座过一阵子就升级一次哪怕代码一行没改模型的输出行为也可能变。我们遇到过同一个Prompt在旧版本上正常换了新版之后突然开始输出多余内容。解决的办法是锁版本线上用的模型版本固定不动升级之前先在评测集上完整回归达标再切。另一个常见问题是开发环境和生产环境效果不一致多数出在推理参数上。比如开发时用了较激进的高温采样感觉输出有创造性上了生产忘了改结果就是不稳定。我们现在的规范是生产环境一律低温度需要多样性的场景宁可多做几次请求再从候选项里选也不把随机性直接暴露给用户。7.3 成本与延迟的权衡最后说成本和延迟。大模型落地的考核指标不只有效果还有响应时间和单次调用成本。我们早期一股脑把所有请求都发给最大参数的模型账单和延迟都很难看。后来做了分级路由简单问题走轻量模型复杂问题才请求强模型中间靠一个意图分类器判断。这条优化做完整体成本降了大约四成用户体验反而提升因为简单问题响应更快了。延迟方面别忘了输出token数的影响。我们曾经为了追求回答完整把max tokens设得很大结果用户等得心焦。后来发现这类业务的答案普遍在两百字以内干脆把输出上限设到三百token极少触发截断响应时间明显缩短。还有一个细节是首token延迟在需要快速反馈的场景里可以在系统层面先给用户一个“正在处理”的状态提示把感知等待时间降下来。7.4 日志、监控与回滚模型应用和传统软件有个重要区别传统软件出bug基本能复现大模型的问题很多是低概率的、上下文高度相关的。这意味着没有详尽日志排查就像大海捞针。我们把每一次请求入参、实际返回、评测结果、是否命中兜底全部落日志关键case还能一键回放当时完整的上下文。这套日志体系建好之后线上问题的定位时间从小时级降到了分钟级。再提一下回滚机制。因为模型的输出可能悄悄变差我们在发布流程里加了“按评测集回归”的硬门槛同时预留了模型的回滚通道一旦线上指标异常可以快速切回上一个稳定版本。这个通道不常用但有它在团队改动的底气就足很多不会因为害怕出问题而不敢动任何东西。8. 写在最后的话从“哄”到“驯服”我们最大的转变不是用了什么新框架、新模型而是心态上不再把模型当成一个可以被说服的对象而是当成一个需要被系统约束的组件。每次模型表现不对第一反应不再是改措辞去“哄”它而是检查评测集有没有覆盖这种情况、上下文有没有给对、有没有兜底能拦住这次错误。这个思维转换比任何技术方案都重要。对我个人来说大模型落地这件事最有意思的地方在于它逼着你把“也许”变成“确定”把“它大概懂我意思”变成“它必须这么做”。这条路没有捷径评测集、上下文管理、检索兜底、微调补漏每一步都得扎扎实实走过去。最后再分享一个小技巧建评测集别只盯着效果指标也留意一下“稳定性”。同一批case多跑几次看看哪些回答偶尔会变、变的幅度大不大。我们给评测系统加了一个“波动率”统计专门记录模型对同一条case多次输出之间的差异这个数字在调参的时候特别有用。如果你也在做类似的项目建议先别急着上微调也别沉迷于打磨Prompt花两周时间把评测集建好把要解决的问题定义清楚。模型是现成的难的是你对自己业务的理解以及愿意为稳定性付出多少纪律性。祝你把模型从“哄”变成“驯”。