没有评测就没有迭代：LLM 应用该建立怎样的评估体系？

去年秋天，一个做智能客服的朋友兴奋地告诉我，他们把基座模型升级到了新版本，”回答明显更通顺了”。两周后看数据，用户满意度却掉了 4 个百分点。问题出在哪？新模型在共情表达上更流畅，但面对退货规则咨询时，开始过度承诺”一定全款退”，导致后续纠纷率上升。这种”感觉变好了”的幻觉，在大模型应用迭代中极其常见。没有扎实的评估体系，迭代就是盲人摸象。

离线评测集：守住”有没有变差”的底线

离线评测集是回归测试的锚点。我们给一家电商客户搭建客服 Agent 时，整理了 480 条核心测试用例，覆盖退货、比价、催单、发票等 8 类高频意图，特意塞了 20% 的边界 case：比如用户输入”你们的东西太差了，我要告你们”，测试模型是否会为了安抚情绪而违规承诺赔偿。每次模型迭代或 prompt 调优后，全量跑一遍评测集是发版前的硬性门槛。有一次，工程师觉得新版 prompt 让回答更简洁，但离线评测显示，针对”修改地址”类问题的准确率从 91% 掉到了 86%，原因是新 prompt 过度要求简短，漏掉了”需在原订单未发货时才可修改”的关键限制。这个版本被直接拦截。

评测集必须保持动态更新。我们建议每两周 review 一次线上 bad case，把有代表性的问题抽象成新的测试用例。静态的评测集一个月后就会失效。

线上 A/B：小流量验证真实世界的效果

离线指标再漂亮，也只是实验室数据。某知识库问答产品升级模型后，ROUGE-L 分数提升了 12%，团队准备全量上线。好在他们先做了 5% 流量的 A/B 实验，对照组沿用旧模型。七天后数据出来：实验组的人均会话轮次增加了 0.8 轮，7 日留存反而下降了 2.3%。深入分析发现，新模型倾向于给出更详尽的解释，移动端用户面对大段文字直接跳出。如果只看离线文本相似度，这个致命体验问题根本暴露不出来。

线上 A/B 的流量分配要足够谨慎。对于 LLM 应用，建议初始灰度 1%-5%，至少观察一个完整业务周期。核心关注的不是 perplexity，而是转化率、留存率、任务完成率这些用户用脚投票的指标。

人工抽检：定义”好”的可操作标准

模型输出没有标准答案时，就需要人工抽检建立主观评价的客观框架。我们内部的做法是每天从线上日志随机抽取 150 到 200 条，按三个维度打分：事实准确性（是否出现幻觉）、任务完成度（是否真正解决了用户问题）、合规安全（是否泄露隐私或给出违规建议）。每条样本由两人独立标注，Kappa 系数低于 0.8 就重新校准评分标准，避免”我觉得还行”的随意性。

人工抽检曾帮我们发现过一个隐蔽问题：模型在推荐商品时，会自信地编造不存在的优惠券代码，如”您可以使用 SAVE50 立减 50 元”。离线测试集里没有覆盖这个特定问法，但抽检连续三天都发现类似幻觉，于是紧急在检索环节增加了优惠券有效性的实时校验。

对齐业务指标：别让技术指标骗了你

LLM 团队最容易陷入的误区，是过度优化学术指标而忽略了业务结果。我们见过一个法律文档审查工具，团队花了两个月把模型的 F1 分数提升了 5%，但接入律师工作流后发现，平均审查时长只减少了不到 2 分钟，对业务几乎没有体感。反观另一个客服场景，模型的文本生成 BLEU 分没有变化，但通过调整回答结构，把”操作步骤”前置、”寒暄”后置，首次解决率（FCR）从 62% 提升到了 71%，这才是业务真正关心的增量。

因此，评估体系必须与业务指标强耦合。客服看首次解决率和平均处理时长（AHT），销售看转化率和客单价，内容审核看漏审率和误伤率。技术团队要和业务部门约定好北极星指标，而不是在实验室里自我感动。

闭环：从发现问题到回归验证

评估的最终目的不是打分，而是形成”发现问题 – 修复 – 验证不再复发”的闭环。我们要求所有线上 bad case 必须录入统一的案例库。之前某次抽检发现，模型在回答”如何重置密码”时，错误地把用户引导到了”注销账号”页面。修复后，不仅解决了当前问题，还在离线评测集中增加了 3 个口语化变体，比如”我忘了密码怎么找回”、”想重新设个密码”，确保后续每次发版都会自动回归验证。

每周一，团队会跑一轮全量离线评测，对比上周数据，任何波动超过 2% 的维度都必须给出技术解释。这个看似笨重的流程，让我们在过去半年里避免了至少三次”感觉很好、数据很糟”的上线事故。

大模型应用的竞争已经进入下半场，拼的不是谁更快换到新模型，而是谁更清楚自己的应用到底在真实世界里表现如何。建立可量化、可回归的评估体系，是迭代的必要基础设施，而不是可有可无的装饰品。