智能体做出来了Demo 跑通了老板拍手叫好然后呢然后就没有然后了。这是我在过去一年里见过最多的场景——团队花了两周搭出一个能对话、能调工具、能查知识库的 Agent演示当天效果惊艳一旦放到真实用户手里各种离谱的失败案例就开始冒出来该调用工具的时候在闲聊不该编造的时候在胡编多轮对话到第三轮就忘了自己是谁。问题的根源不在于模型不够强而在于绝大多数团队压根没有建立一套生产级评估体系。这篇文章想聊的就是这件事LLM Evals 到底在评什么RAGAS 这类框架怎么用LLM-as-judge 靠不靠谱以及一个能真正跑起来的评估流水线应该长什么样。不管你是刚接触智能体开发的新手还是已经在带团队做 Agent 落地的老兵希望这些从实际项目里摔打出来的经验能帮你少走几步弯路。1. 为什么你的智能体 Demo 很惊艳但上线就翻车1.1 演示环境和生产环境的鸿沟到底在哪先说一个我亲身经历的事。去年帮一个团队做客服智能体的评估咨询他们的 Demo 在内部演示时准确率目测有 90% 以上QA 团队抽了 50 条测试用例通过率 86%。听起来不错对吧上线第一周真实用户对话的满意度评分只有 3.2/5投诉集中在答非所问和重复回答上。后来我们把真实流量里的 500 条对话拉出来重新评估发现实际任务完成率只有 47%。这个落差不是偶然的。演示环境有几个天然的作弊条件测试用例是团队自己写的潜意识里会避开边界情况对话轮次通常只有一两轮不会暴露上下文管理的问题工具调用的参数往往是理想化的不会出现用户输入格式乱七八糟的情况知识库检索的 query 和文档措辞高度匹配因为写测试的人和写文档的人是同一批。一旦这些条件被打破智能体的真实能力就暴露了。更关键的是很多团队评估的是模型能力而不是系统能力。一个智能体的表现等于模型能力乘以提示词质量乘以工具设计乘以检索质量乘以上下文管理策略任何一个环节拖后腿整体表现就会塌方。你用一个强模型跑一个设计糟糕的 Agent结果可能还不如一个中等模型配一套精心设计的流程。1.2 没有评估体系的团队在盲飞我见过太多团队的开发流程是这样的改一版提示词手动测几个 case感觉好像好了一点发上去。下周又改一版再手动测几个 case感觉又差了一点回滚。整个过程没有任何量化依据全靠感觉。这种模式在小规模下还能凑合一旦智能体要覆盖几十个意图、上百个工具、多个知识库人的直觉就完全不够用了。没有评估体系带来的直接后果是你不知道每次改动是让系统变好了还是变差了。提示词工程有一个非常反直觉的特点——修好一个 case 往往会弄坏另外三个 case。你针对退款流程优化了提示词结果换货流程的回答质量下降了。没有回归测试这种退化你根本发现不了直到用户投诉。另一个后果是团队无法就什么叫做好达成共识。产品经理觉得回答准确就行工程师觉得工具调用成功率更重要运营觉得语气友好才是关键。没有一套共同的评估标准和指标每次评审会都是各说各话。1.3 评估体系到底该评什么从模型指标到任务指标这里需要做一个重要的认知转换。传统的 NLP 评估看的是 BLEU、ROUGE 这类文本相似度指标但智能体的评估维度完全不同。一个智能体可能回答的措辞和标准答案完全不一样但任务完成得非常好也可能措辞很漂亮但该调工具的时候没调导致任务失败。我在实践中把智能体的评估拆成四个层次任务层用户的问题最终有没有被解决这是最核心的指标通常用任务完成率来衡量。行为层智能体在执行任务过程中的行为是否合理包括工具选择是否正确、参数是否准确、检索是否命中、多轮对话中上下文是否保持一致。质量层回答的准确性、完整性、相关性、语气是否符合品牌调性。安全层有没有产生有害内容、有没有泄露敏感信息、有没有超出权限范围的操作。这四个层次的评估方法和工具完全不同。任务层和行为层更适合用基于规则的自动化评估质量层通常需要 LLM-as-judge 或者人工评估安全层则需要专门的对抗测试集。很多团队只做了质量层的评估忽略了行为层结果就是回答看起来没问题但任务实际上没完成。2. LLM Evals 的核心方法论拆解2.1 从传统指标到 LLM-as-judge 的演进逻辑传统的文本生成评估指标比如 BLEU 和 ROUGE本质上是基于 n-gram 重叠度来计算相似性的。这套方法在机器翻译和摘要任务上还能用但放到智能体场景下就完全失效了。原因很简单智能体的输出是开放式的同一个问题的正确答案可能有几十种表述方式n-gram 重叠度根本反映不了语义层面的质量差异。后来出现了基于嵌入向量的相似度评估比如 BERTScore它通过比较语义嵌入的余弦相似度来判断生成质量。这比 n-gram 好一些但依然有一个致命缺陷它只能判断像不像不能判断对不对。一段和标准答案语义相似但事实错误的内容BERTScore 可能给很高的分。LLM-as-judge 的出现是一个转折点。它的核心思路是既然大语言模型已经具备了很强的理解和判断能力为什么不直接让它来当评委具体做法是给评委模型提供评估标准rubric、用户输入、智能体的输出有时还包括参考答案然后让评委模型给出评分和理由。这个方法的好处非常明显灵活、可定制、能处理开放式输出。你可以让评委模型从准确性、完整性、相关性、语气等多个维度打分也可以让它做 pairwise 比较A 和 B 哪个更好。但它的坑也很多后面会专门讲。2.2 RAGAS 框架到底解决了什么问题RAGASRetrieval Augmented Generation Assessment是我目前在 RAG 类智能体评估中用得最多的框架之一。它最初是为 RAG 系统设计的但核心思路可以迁移到更广泛的智能体评估场景。RAGAS 的核心贡献在于它把 RAG 系统的评估拆解成了几个可以独立度量的维度指标评估对象核心问题Faithfulness生成答案答案中的每个陈述是否都能从检索到的上下文中找到依据Answer Relevancy生成答案答案是否直接回应了用户的问题Context Precision检索结果检索到的文档中有多少是真正相关的Context Recall检索结果所有需要的信息是否都被检索到了Answer Correctness生成答案答案与参考答案的事实一致性这套拆解的价值在于当智能体回答出错时你能快速定位是检索的问题还是生成的问题。如果 Context Recall 很低说明知识库里根本没有相关信息或者检索策略有问题如果 Context Recall 高但 Faithfulness 低说明模型在拿着正确答案胡编需要加强提示词中的约束。RAGAS 还有一个很实用的设计是它不需要人工标注的参考答案就能计算部分指标。比如 Faithfulness 和 Answer Relevancy 都可以在没有 ground truth 的情况下计算这对于冷启动阶段的评估非常友好。当然如果你有标注数据Answer Correctness 和 Context Recall 能提供更准确的评估。2.3 构建评估数据集的三种路径评估体系的地基是评估数据集。没有一套高质量的评估数据集再精妙的评估方法都是空中楼阁。我在实践中用过三种构建路径各有优劣。第一种是人工构造。让产品经理、运营、客服等最了解用户需求的人根据真实业务场景编写测试用例。每条用例包括用户输入、期望的行为比如应该调用哪个工具、参考答案如果有的话、评估标准。这种方式的优点是质量高、针对性强缺点是成本高、覆盖有限。我的经验是一个中等复杂度的智能体至少需要 100-200 条人工构造的核心用例才能覆盖主要场景。第二种是从真实日志中挖掘。智能体上线后把真实用户的对话日志拉出来筛选出有代表性的 case人工标注后加入评估集。这种方式能捕捉到人工构造时想不到的边界情况。我通常会重点关注三类日志用户明确表示不满意的、智能体行为异常的比如反复调用同一个工具、对话轮次特别长的。第三种是用 LLM 合成。给一个强模型提供业务背景和少量种子用例让它批量生成更多测试用例。这种方式成本低、速度快但质量参差不齐必须经过人工筛选。我一般用它来扩充覆盖面而不是作为主要来源。实际操作中这三种方式是组合使用的。我的建议是冷启动阶段以人工构造为主快速建立 50-100 条核心用例上线后持续从日志中挖掘每周补充 10-20 条新用例用 LLM 合成来填充长尾场景但必须人工审核。注意评估数据集不是一次性的工作而是一个持续迭代的资产。我见过团队花两周建了一个评估集然后半年没更新过结果评估结果和真实用户体验完全脱节。3. 生产级评估流水线的搭建实操3.1 评估流水线的整体架构设计一个能跑起来的生产级评估流水线核心组件包括评估数据集管理、评估执行引擎、评委模型调用、结果存储与可视化、回归告警。这五个组件缺一不可。评估数据集管理负责存储和版本化测试用例。我强烈建议把评估数据集当作代码来管理用 Git 做版本控制每次修改都有记录。数据集的结构通常包括用例 ID、用户输入、对话历史多轮场景、期望的工具调用序列、参考答案、评估维度标签、难度等级。评估执行引擎负责编排整个评估流程加载数据集、调用被测智能体、收集输出、调用评委模型、汇总结果。这个引擎需要支持并发执行否则几百条用例跑起来太慢、失败重试、断点续跑。评委模型调用是一个容易被低估的环节。你需要考虑评委模型的选择、提示词设计、评分校准、成本控制。一个常见的做法是用比被测模型更强的模型来当评委比如被测智能体用的是中等规模的模型评委用旗舰模型。结果存储与可视化决定了你能不能从评估数据中发现规律。我通常会把每次评估的结果存到数据库里记录评估时间、代码版本、提示词版本、每条用例的详细评分。然后用看板展示趋势变化按维度下钻分析。回归告警是最后一道防线。每次代码合并或提示词变更后自动触发评估如果核心指标下降超过阈值自动阻断发布。这个环节很多团队会忽略但它是保证评估体系真正发挥作用的关键。3.2 评委模型的选择与提示词设计评委模型的选择直接决定了评估结果的可信度。我踩过的坑是用了一个和被测模型同级别的评委结果评委经常给出模棱两可的评分而且和人工评估的一致性很差。后来换成更强的模型当评委一致性明显提升。但更强的评委模型意味着更高的成本。一个折中方案是分层评估核心用例用强评委模型长尾用例用轻量评委模型。另一个方案是先用强模型评估一批数据然后用这批数据微调一个小的评委模型后续用微调后的模型做评估。评委提示词的设计有几个关键原则。第一评估标准必须具体、可操作不能是回答得好不好这种模糊表述。比如评估准确性时要明确说明如果回答中包含与知识库矛盾的信息准确性得 1 分如果所有事实性陈述都能在知识库中找到依据得 5 分。第二要求评委模型给出评分理由。这不仅能让评估结果更可解释还能迫使评委模型进行更深入的推理提高评分的准确性。我在实际使用中发现要求给出理由后评委模型和人工评估的一致性从 0.6 左右提升到了 0.75 以上。第三使用 few-shot 示例来校准评委。在提示词中提供几个评分示例覆盖不同的分数段能显著提高评委模型评分的一致性。示例最好来自你的实际业务场景而不是通用的例子。第四控制评分粒度。5 分制通常比 10 分制更稳定因为评委模型对 1-5 的区分度把握更好。如果只需要做通过/不通过的二元判断直接用二元评分往往比用连续分数再设阈值更可靠。3.3 自动化评估与人工评估的配比策略纯自动化评估和纯人工评估都不现实。自动化评估快、便宜、可重复但无法捕捉所有质量问题人工评估准、灵活但慢、贵、不可扩展。关键是怎么配比。我的经验法则是日常迭代用自动化评估做快速反馈重要版本发布前用人工评估做最终把关。具体来说每次代码提交触发自动化评估覆盖全部评估数据集10 分钟内出结果。每周做一次人工抽检从自动化评估结果中分层抽样重点看评分处于边界地带的用例。每个大版本发布前做一次全面的人工评估覆盖核心用例集。人工评估的另一个重要作用是校准自动化评估。定期让标注人员评估一批用例然后和评委模型的评分做对比计算一致性指标比如 Cohens Kappa。如果一致性低于 0.6说明评委提示词需要调整或者评估标准需要重新定义。这里有一个容易被忽略的细节人工评估的标注人员需要培训。不同标注人员对准确性的理解可能完全不同有人觉得只要核心事实对就行有人觉得措辞不精确也算错误。制定详细的标注指南定期做标注一致性检查是保证人工评估质量的前提。4. 智能体评估中那些容易踩的坑4.1 评委模型的偏见与校准方法LLM-as-judge 虽然好用但它的偏见如果不处理评估结果可能比没有评估还危险因为它会给你一种虚假的安全感。我遇到过的偏见主要有这几种。位置偏见在做 pairwise 比较时评委模型倾向于选择第一个呈现的选项。解决方法是随机打乱 A 和 B 的顺序做两次评估取平均结果。长度偏见评委模型倾向于给更长的回答更高的分数即使长回答中包含了冗余信息。解决方法是在评估标准中明确说明简洁性也是一个评估维度或者在提示词中要求评委忽略长度因素。自我偏好如果评委模型和被测模型是同一个模型评委倾向于给自己的输出打高分。解决方法很简单评委模型和被测模型不要用同一个。格式偏见评委模型可能对特定格式的回答有偏好比如带编号列表的回答比纯段落回答得分更高。解决方法是在评估标准中明确说明格式不影响评分或者对输出做标准化处理后再评估。校准评委模型的一个实用方法是准备一批已经有人工评分的黄金标准数据集用评委模型跑一遍计算和人工评分的一致性。如果一致性不达标调整评委提示词重新跑直到一致性达到可接受的水平。这个过程通常需要迭代 3-5 轮。4.2 评估数据集泄漏与过拟合问题这是一个非常隐蔽但影响巨大的坑。当你的评估数据集被用于指导提示词优化时它实际上就变成了训练集的一部分。你针对评估集优化提示词评估分数上去了但真实表现可能没有提升甚至下降了。我见过最极端的案例是一个团队把评估集里的 200 条用例的参考答案直接写进了系统提示词里评估通过率 100%但上线后用户满意度惨不忍睹。这就是典型的过拟合。避免这个问题的方法有几个。第一维护两个独立的数据集开发集dev set和测试集test set。开发集用于日常迭代和提示词优化测试集只在版本发布前使用平时不查看具体结果只看汇总指标。第二定期更新测试集从最新的真实日志中挖掘新用例替换旧用例。第三关注评估分数和真实用户指标的相关性如果评估分数涨了但用户满意度没涨很可能就是过拟合了。4.3 多轮对话场景下的评估难点单轮对话的评估相对简单多轮对话的评估复杂度会指数级上升。难点在于错误会累积和传播。第一轮的一个小偏差到第三轮可能演变成完全跑偏的对话。多轮对话评估需要额外关注的维度包括上下文一致性智能体是否记住了之前轮次的信息、指代消解用户说那个时智能体能否正确理解指代对象、话题切换用户突然换话题时智能体能否正确响应、纠错能力用户指出错误时智能体能否修正。评估方法上我通常会把多轮对话拆解成逐轮评估加整体评估。逐轮评估看每一轮的响应质量整体评估看整个对话是否达成了用户目标。逐轮评估可以用和单轮类似的方法整体评估通常需要人工或者用 LLM 做对话级别的判断。一个实操技巧是在评估数据集中多轮对话用例要明确标注每一轮的期望行为。比如第一轮期望调用搜索工具第二轮期望基于搜索结果回答第三轮期望调用下单工具。这样评估时不仅能看最终结果还能看中间过程是否符合预期。5. 从评估结果到智能体迭代的闭环5.1 如何根据评估数据定位问题根因评估的价值不在于打分而在于定位问题。一堆评分数据如果不能用來指导优化就是浪费。我通常用分层下钻的方法来定位问题。第一步看整体指标趋势。如果任务完成率下降了先确认是哪个维度拖累的。是工具调用成功率下降了还是回答质量下降了还是检索命中率下降了。第二步按用例标签下钻。评估数据集中的每条用例通常都有标签比如场景类型、难度等级、涉及的工具。按标签分组看指标能快速定位是哪个场景出了问题。比如发现退款场景的完成率特别低而其他场景正常那问题就聚焦了。第三步看失败用例的具体表现。把失败用例的详细评估结果拉出来看评委模型给出的理由。如果多个失败用例的理由都指向同一个问题比如没有调用查询订单的工具那优化方向就很明确了。第四步形成假设并验证。基于前面的分析提出优化方案比如修改提示词中关于工具调用的描述然后重新跑评估看指标是否改善。如果改善了保留改动如果没有回退并尝试其他方案。这个流程看起来简单但实际操作中最容易犯的错误是跳跃式优化——看到指标下降就直接改提示词没有做根因分析。这样改往往治标不治本甚至引入新的问题。5.2 建立持续评估的工程化习惯评估体系要真正发挥作用必须嵌入到日常开发流程中而不是作为一个独立的、偶尔跑一次的工具。我的建议是把评估集成到 CI/CD 流水线中。每次代码提交或提示词变更自动触发评估评估结果作为合并请求的一个检查项。如果核心指标下降超过阈值阻止合并。这个阈值需要根据业务容忍度来设定我通常建议核心指标如任务完成率的下降不超过 2 个百分点非核心指标不超过 5 个百分点。另一个习惯是建立评估看板让全团队都能看到智能体的表现趋势。看板上至少要有每日评估的核心指标、最近一次评估的详细结果、和上周/上月的对比、失败用例的 Top 问题分类。看板的价值在于让评估结果透明化避免工程师觉得没问题但产品觉得有问题的扯皮。还有一个容易被忽略的习惯是每次线上事故后把相关 case 加入评估数据集。线上事故是最真实的失败案例把它们纳入评估集能确保同类问题不会再次发生。我通常会要求团队在事故复盘后 48 小时内完成评估用例的补充。5.3 评估驱动下的提示词与工具优化实例举一个实际的例子来说明评估如何驱动优化。之前有一个做企业知识库问答的智能体评估发现 Answer Relevancy 指标只有 0.65明显偏低。下钻分析发现问题集中在用户问 A 但智能体回答了 B的情况。进一步看失败用例发现一个规律当用户的问题比较宽泛时比如我们公司的报销政策是什么智能体倾向于把所有相关的政策文档内容都塞进回答里导致回答冗长且重点不突出。而当用户的问题很具体时比如出差住宿费的标准是多少回答质量就很好。基于这个发现我们做了两个优化。第一在提示词中增加了先判断用户问题的粒度如果问题宽泛先给出概览再询问用户具体想了解哪方面的指令。第二优化了检索策略对宽泛问题先做一次聚类检索返回多个相关文档的摘要而不是全文。优化后重新评估Answer Relevancy 从 0.65 提升到了 0.82同时平均回答长度下降了 40%。这个案例说明评估数据不仅能告诉你哪里有问题还能告诉你为什么有问题和怎么改。另一个例子是关于工具调用的。评估发现某个智能体的工具调用成功率只有 70%失败主要集中在参数格式错误上。分析发现用户输入的日期格式五花八门下周三、3 月 15 号、明天而工具要求的参数格式是 ISO 8601。解决方案是在工具调用前增加一个参数标准化步骤用 LLM 把用户输入转换成标准格式。这个改动把工具调用成功率提升到了 93%。6. 写在最后一些个人体会做智能体评估这件事最大的感受是它不是一个技术问题而是一个工程习惯问题。技术方案其实都不复杂RAGAS、LLM-as-judge 这些工具用起来门槛也不高难的是坚持。坚持每次改动都跑评估坚持定期更新评估数据集坚持看评估结果做决策而不是拍脑袋。我见过评估体系做得最好的团队往往不是技术最强的团队而是工程纪律最好的团队。他们把评估当作和单元测试一样的基本要求没有评估结果的代码不允许合并。这种纪律一开始会觉得麻烦但半年后回头看它节省的时间远远超过投入的时间。另外一点体会是不要追求完美的评估体系。我见过一些团队花大量时间设计复杂的评估指标和流程结果评估体系本身成了负担没人愿意用。不如从一个简单的评估集开始先跑起来再逐步完善。一个能跑起来的简单评估比一个设计完美但没人用的评估体系有价值得多。最后评估的最终目的不是得到一个好看的分数而是让智能体真正解决用户的问题。分数只是手段用户满意才是目标。当评估分数和用户满意度出现背离时永远相信用户。
智能体上线就翻车？生产级LLM评估体系搭建指南
智能体做出来了Demo 跑通了老板拍手叫好然后呢然后就没有然后了。这是我在过去一年里见过最多的场景——团队花了两周搭出一个能对话、能调工具、能查知识库的 Agent演示当天效果惊艳一旦放到真实用户手里各种离谱的失败案例就开始冒出来该调用工具的时候在闲聊不该编造的时候在胡编多轮对话到第三轮就忘了自己是谁。问题的根源不在于模型不够强而在于绝大多数团队压根没有建立一套生产级评估体系。这篇文章想聊的就是这件事LLM Evals 到底在评什么RAGAS 这类框架怎么用LLM-as-judge 靠不靠谱以及一个能真正跑起来的评估流水线应该长什么样。不管你是刚接触智能体开发的新手还是已经在带团队做 Agent 落地的老兵希望这些从实际项目里摔打出来的经验能帮你少走几步弯路。1. 为什么你的智能体 Demo 很惊艳但上线就翻车1.1 演示环境和生产环境的鸿沟到底在哪先说一个我亲身经历的事。去年帮一个团队做客服智能体的评估咨询他们的 Demo 在内部演示时准确率目测有 90% 以上QA 团队抽了 50 条测试用例通过率 86%。听起来不错对吧上线第一周真实用户对话的满意度评分只有 3.2/5投诉集中在答非所问和重复回答上。后来我们把真实流量里的 500 条对话拉出来重新评估发现实际任务完成率只有 47%。这个落差不是偶然的。演示环境有几个天然的作弊条件测试用例是团队自己写的潜意识里会避开边界情况对话轮次通常只有一两轮不会暴露上下文管理的问题工具调用的参数往往是理想化的不会出现用户输入格式乱七八糟的情况知识库检索的 query 和文档措辞高度匹配因为写测试的人和写文档的人是同一批。一旦这些条件被打破智能体的真实能力就暴露了。更关键的是很多团队评估的是模型能力而不是系统能力。一个智能体的表现等于模型能力乘以提示词质量乘以工具设计乘以检索质量乘以上下文管理策略任何一个环节拖后腿整体表现就会塌方。你用一个强模型跑一个设计糟糕的 Agent结果可能还不如一个中等模型配一套精心设计的流程。1.2 没有评估体系的团队在盲飞我见过太多团队的开发流程是这样的改一版提示词手动测几个 case感觉好像好了一点发上去。下周又改一版再手动测几个 case感觉又差了一点回滚。整个过程没有任何量化依据全靠感觉。这种模式在小规模下还能凑合一旦智能体要覆盖几十个意图、上百个工具、多个知识库人的直觉就完全不够用了。没有评估体系带来的直接后果是你不知道每次改动是让系统变好了还是变差了。提示词工程有一个非常反直觉的特点——修好一个 case 往往会弄坏另外三个 case。你针对退款流程优化了提示词结果换货流程的回答质量下降了。没有回归测试这种退化你根本发现不了直到用户投诉。另一个后果是团队无法就什么叫做好达成共识。产品经理觉得回答准确就行工程师觉得工具调用成功率更重要运营觉得语气友好才是关键。没有一套共同的评估标准和指标每次评审会都是各说各话。1.3 评估体系到底该评什么从模型指标到任务指标这里需要做一个重要的认知转换。传统的 NLP 评估看的是 BLEU、ROUGE 这类文本相似度指标但智能体的评估维度完全不同。一个智能体可能回答的措辞和标准答案完全不一样但任务完成得非常好也可能措辞很漂亮但该调工具的时候没调导致任务失败。我在实践中把智能体的评估拆成四个层次任务层用户的问题最终有没有被解决这是最核心的指标通常用任务完成率来衡量。行为层智能体在执行任务过程中的行为是否合理包括工具选择是否正确、参数是否准确、检索是否命中、多轮对话中上下文是否保持一致。质量层回答的准确性、完整性、相关性、语气是否符合品牌调性。安全层有没有产生有害内容、有没有泄露敏感信息、有没有超出权限范围的操作。这四个层次的评估方法和工具完全不同。任务层和行为层更适合用基于规则的自动化评估质量层通常需要 LLM-as-judge 或者人工评估安全层则需要专门的对抗测试集。很多团队只做了质量层的评估忽略了行为层结果就是回答看起来没问题但任务实际上没完成。2. LLM Evals 的核心方法论拆解2.1 从传统指标到 LLM-as-judge 的演进逻辑传统的文本生成评估指标比如 BLEU 和 ROUGE本质上是基于 n-gram 重叠度来计算相似性的。这套方法在机器翻译和摘要任务上还能用但放到智能体场景下就完全失效了。原因很简单智能体的输出是开放式的同一个问题的正确答案可能有几十种表述方式n-gram 重叠度根本反映不了语义层面的质量差异。后来出现了基于嵌入向量的相似度评估比如 BERTScore它通过比较语义嵌入的余弦相似度来判断生成质量。这比 n-gram 好一些但依然有一个致命缺陷它只能判断像不像不能判断对不对。一段和标准答案语义相似但事实错误的内容BERTScore 可能给很高的分。LLM-as-judge 的出现是一个转折点。它的核心思路是既然大语言模型已经具备了很强的理解和判断能力为什么不直接让它来当评委具体做法是给评委模型提供评估标准rubric、用户输入、智能体的输出有时还包括参考答案然后让评委模型给出评分和理由。这个方法的好处非常明显灵活、可定制、能处理开放式输出。你可以让评委模型从准确性、完整性、相关性、语气等多个维度打分也可以让它做 pairwise 比较A 和 B 哪个更好。但它的坑也很多后面会专门讲。2.2 RAGAS 框架到底解决了什么问题RAGASRetrieval Augmented Generation Assessment是我目前在 RAG 类智能体评估中用得最多的框架之一。它最初是为 RAG 系统设计的但核心思路可以迁移到更广泛的智能体评估场景。RAGAS 的核心贡献在于它把 RAG 系统的评估拆解成了几个可以独立度量的维度指标评估对象核心问题Faithfulness生成答案答案中的每个陈述是否都能从检索到的上下文中找到依据Answer Relevancy生成答案答案是否直接回应了用户的问题Context Precision检索结果检索到的文档中有多少是真正相关的Context Recall检索结果所有需要的信息是否都被检索到了Answer Correctness生成答案答案与参考答案的事实一致性这套拆解的价值在于当智能体回答出错时你能快速定位是检索的问题还是生成的问题。如果 Context Recall 很低说明知识库里根本没有相关信息或者检索策略有问题如果 Context Recall 高但 Faithfulness 低说明模型在拿着正确答案胡编需要加强提示词中的约束。RAGAS 还有一个很实用的设计是它不需要人工标注的参考答案就能计算部分指标。比如 Faithfulness 和 Answer Relevancy 都可以在没有 ground truth 的情况下计算这对于冷启动阶段的评估非常友好。当然如果你有标注数据Answer Correctness 和 Context Recall 能提供更准确的评估。2.3 构建评估数据集的三种路径评估体系的地基是评估数据集。没有一套高质量的评估数据集再精妙的评估方法都是空中楼阁。我在实践中用过三种构建路径各有优劣。第一种是人工构造。让产品经理、运营、客服等最了解用户需求的人根据真实业务场景编写测试用例。每条用例包括用户输入、期望的行为比如应该调用哪个工具、参考答案如果有的话、评估标准。这种方式的优点是质量高、针对性强缺点是成本高、覆盖有限。我的经验是一个中等复杂度的智能体至少需要 100-200 条人工构造的核心用例才能覆盖主要场景。第二种是从真实日志中挖掘。智能体上线后把真实用户的对话日志拉出来筛选出有代表性的 case人工标注后加入评估集。这种方式能捕捉到人工构造时想不到的边界情况。我通常会重点关注三类日志用户明确表示不满意的、智能体行为异常的比如反复调用同一个工具、对话轮次特别长的。第三种是用 LLM 合成。给一个强模型提供业务背景和少量种子用例让它批量生成更多测试用例。这种方式成本低、速度快但质量参差不齐必须经过人工筛选。我一般用它来扩充覆盖面而不是作为主要来源。实际操作中这三种方式是组合使用的。我的建议是冷启动阶段以人工构造为主快速建立 50-100 条核心用例上线后持续从日志中挖掘每周补充 10-20 条新用例用 LLM 合成来填充长尾场景但必须人工审核。注意评估数据集不是一次性的工作而是一个持续迭代的资产。我见过团队花两周建了一个评估集然后半年没更新过结果评估结果和真实用户体验完全脱节。3. 生产级评估流水线的搭建实操3.1 评估流水线的整体架构设计一个能跑起来的生产级评估流水线核心组件包括评估数据集管理、评估执行引擎、评委模型调用、结果存储与可视化、回归告警。这五个组件缺一不可。评估数据集管理负责存储和版本化测试用例。我强烈建议把评估数据集当作代码来管理用 Git 做版本控制每次修改都有记录。数据集的结构通常包括用例 ID、用户输入、对话历史多轮场景、期望的工具调用序列、参考答案、评估维度标签、难度等级。评估执行引擎负责编排整个评估流程加载数据集、调用被测智能体、收集输出、调用评委模型、汇总结果。这个引擎需要支持并发执行否则几百条用例跑起来太慢、失败重试、断点续跑。评委模型调用是一个容易被低估的环节。你需要考虑评委模型的选择、提示词设计、评分校准、成本控制。一个常见的做法是用比被测模型更强的模型来当评委比如被测智能体用的是中等规模的模型评委用旗舰模型。结果存储与可视化决定了你能不能从评估数据中发现规律。我通常会把每次评估的结果存到数据库里记录评估时间、代码版本、提示词版本、每条用例的详细评分。然后用看板展示趋势变化按维度下钻分析。回归告警是最后一道防线。每次代码合并或提示词变更后自动触发评估如果核心指标下降超过阈值自动阻断发布。这个环节很多团队会忽略但它是保证评估体系真正发挥作用的关键。3.2 评委模型的选择与提示词设计评委模型的选择直接决定了评估结果的可信度。我踩过的坑是用了一个和被测模型同级别的评委结果评委经常给出模棱两可的评分而且和人工评估的一致性很差。后来换成更强的模型当评委一致性明显提升。但更强的评委模型意味着更高的成本。一个折中方案是分层评估核心用例用强评委模型长尾用例用轻量评委模型。另一个方案是先用强模型评估一批数据然后用这批数据微调一个小的评委模型后续用微调后的模型做评估。评委提示词的设计有几个关键原则。第一评估标准必须具体、可操作不能是回答得好不好这种模糊表述。比如评估准确性时要明确说明如果回答中包含与知识库矛盾的信息准确性得 1 分如果所有事实性陈述都能在知识库中找到依据得 5 分。第二要求评委模型给出评分理由。这不仅能让评估结果更可解释还能迫使评委模型进行更深入的推理提高评分的准确性。我在实际使用中发现要求给出理由后评委模型和人工评估的一致性从 0.6 左右提升到了 0.75 以上。第三使用 few-shot 示例来校准评委。在提示词中提供几个评分示例覆盖不同的分数段能显著提高评委模型评分的一致性。示例最好来自你的实际业务场景而不是通用的例子。第四控制评分粒度。5 分制通常比 10 分制更稳定因为评委模型对 1-5 的区分度把握更好。如果只需要做通过/不通过的二元判断直接用二元评分往往比用连续分数再设阈值更可靠。3.3 自动化评估与人工评估的配比策略纯自动化评估和纯人工评估都不现实。自动化评估快、便宜、可重复但无法捕捉所有质量问题人工评估准、灵活但慢、贵、不可扩展。关键是怎么配比。我的经验法则是日常迭代用自动化评估做快速反馈重要版本发布前用人工评估做最终把关。具体来说每次代码提交触发自动化评估覆盖全部评估数据集10 分钟内出结果。每周做一次人工抽检从自动化评估结果中分层抽样重点看评分处于边界地带的用例。每个大版本发布前做一次全面的人工评估覆盖核心用例集。人工评估的另一个重要作用是校准自动化评估。定期让标注人员评估一批用例然后和评委模型的评分做对比计算一致性指标比如 Cohens Kappa。如果一致性低于 0.6说明评委提示词需要调整或者评估标准需要重新定义。这里有一个容易被忽略的细节人工评估的标注人员需要培训。不同标注人员对准确性的理解可能完全不同有人觉得只要核心事实对就行有人觉得措辞不精确也算错误。制定详细的标注指南定期做标注一致性检查是保证人工评估质量的前提。4. 智能体评估中那些容易踩的坑4.1 评委模型的偏见与校准方法LLM-as-judge 虽然好用但它的偏见如果不处理评估结果可能比没有评估还危险因为它会给你一种虚假的安全感。我遇到过的偏见主要有这几种。位置偏见在做 pairwise 比较时评委模型倾向于选择第一个呈现的选项。解决方法是随机打乱 A 和 B 的顺序做两次评估取平均结果。长度偏见评委模型倾向于给更长的回答更高的分数即使长回答中包含了冗余信息。解决方法是在评估标准中明确说明简洁性也是一个评估维度或者在提示词中要求评委忽略长度因素。自我偏好如果评委模型和被测模型是同一个模型评委倾向于给自己的输出打高分。解决方法很简单评委模型和被测模型不要用同一个。格式偏见评委模型可能对特定格式的回答有偏好比如带编号列表的回答比纯段落回答得分更高。解决方法是在评估标准中明确说明格式不影响评分或者对输出做标准化处理后再评估。校准评委模型的一个实用方法是准备一批已经有人工评分的黄金标准数据集用评委模型跑一遍计算和人工评分的一致性。如果一致性不达标调整评委提示词重新跑直到一致性达到可接受的水平。这个过程通常需要迭代 3-5 轮。4.2 评估数据集泄漏与过拟合问题这是一个非常隐蔽但影响巨大的坑。当你的评估数据集被用于指导提示词优化时它实际上就变成了训练集的一部分。你针对评估集优化提示词评估分数上去了但真实表现可能没有提升甚至下降了。我见过最极端的案例是一个团队把评估集里的 200 条用例的参考答案直接写进了系统提示词里评估通过率 100%但上线后用户满意度惨不忍睹。这就是典型的过拟合。避免这个问题的方法有几个。第一维护两个独立的数据集开发集dev set和测试集test set。开发集用于日常迭代和提示词优化测试集只在版本发布前使用平时不查看具体结果只看汇总指标。第二定期更新测试集从最新的真实日志中挖掘新用例替换旧用例。第三关注评估分数和真实用户指标的相关性如果评估分数涨了但用户满意度没涨很可能就是过拟合了。4.3 多轮对话场景下的评估难点单轮对话的评估相对简单多轮对话的评估复杂度会指数级上升。难点在于错误会累积和传播。第一轮的一个小偏差到第三轮可能演变成完全跑偏的对话。多轮对话评估需要额外关注的维度包括上下文一致性智能体是否记住了之前轮次的信息、指代消解用户说那个时智能体能否正确理解指代对象、话题切换用户突然换话题时智能体能否正确响应、纠错能力用户指出错误时智能体能否修正。评估方法上我通常会把多轮对话拆解成逐轮评估加整体评估。逐轮评估看每一轮的响应质量整体评估看整个对话是否达成了用户目标。逐轮评估可以用和单轮类似的方法整体评估通常需要人工或者用 LLM 做对话级别的判断。一个实操技巧是在评估数据集中多轮对话用例要明确标注每一轮的期望行为。比如第一轮期望调用搜索工具第二轮期望基于搜索结果回答第三轮期望调用下单工具。这样评估时不仅能看最终结果还能看中间过程是否符合预期。5. 从评估结果到智能体迭代的闭环5.1 如何根据评估数据定位问题根因评估的价值不在于打分而在于定位问题。一堆评分数据如果不能用來指导优化就是浪费。我通常用分层下钻的方法来定位问题。第一步看整体指标趋势。如果任务完成率下降了先确认是哪个维度拖累的。是工具调用成功率下降了还是回答质量下降了还是检索命中率下降了。第二步按用例标签下钻。评估数据集中的每条用例通常都有标签比如场景类型、难度等级、涉及的工具。按标签分组看指标能快速定位是哪个场景出了问题。比如发现退款场景的完成率特别低而其他场景正常那问题就聚焦了。第三步看失败用例的具体表现。把失败用例的详细评估结果拉出来看评委模型给出的理由。如果多个失败用例的理由都指向同一个问题比如没有调用查询订单的工具那优化方向就很明确了。第四步形成假设并验证。基于前面的分析提出优化方案比如修改提示词中关于工具调用的描述然后重新跑评估看指标是否改善。如果改善了保留改动如果没有回退并尝试其他方案。这个流程看起来简单但实际操作中最容易犯的错误是跳跃式优化——看到指标下降就直接改提示词没有做根因分析。这样改往往治标不治本甚至引入新的问题。5.2 建立持续评估的工程化习惯评估体系要真正发挥作用必须嵌入到日常开发流程中而不是作为一个独立的、偶尔跑一次的工具。我的建议是把评估集成到 CI/CD 流水线中。每次代码提交或提示词变更自动触发评估评估结果作为合并请求的一个检查项。如果核心指标下降超过阈值阻止合并。这个阈值需要根据业务容忍度来设定我通常建议核心指标如任务完成率的下降不超过 2 个百分点非核心指标不超过 5 个百分点。另一个习惯是建立评估看板让全团队都能看到智能体的表现趋势。看板上至少要有每日评估的核心指标、最近一次评估的详细结果、和上周/上月的对比、失败用例的 Top 问题分类。看板的价值在于让评估结果透明化避免工程师觉得没问题但产品觉得有问题的扯皮。还有一个容易被忽略的习惯是每次线上事故后把相关 case 加入评估数据集。线上事故是最真实的失败案例把它们纳入评估集能确保同类问题不会再次发生。我通常会要求团队在事故复盘后 48 小时内完成评估用例的补充。5.3 评估驱动下的提示词与工具优化实例举一个实际的例子来说明评估如何驱动优化。之前有一个做企业知识库问答的智能体评估发现 Answer Relevancy 指标只有 0.65明显偏低。下钻分析发现问题集中在用户问 A 但智能体回答了 B的情况。进一步看失败用例发现一个规律当用户的问题比较宽泛时比如我们公司的报销政策是什么智能体倾向于把所有相关的政策文档内容都塞进回答里导致回答冗长且重点不突出。而当用户的问题很具体时比如出差住宿费的标准是多少回答质量就很好。基于这个发现我们做了两个优化。第一在提示词中增加了先判断用户问题的粒度如果问题宽泛先给出概览再询问用户具体想了解哪方面的指令。第二优化了检索策略对宽泛问题先做一次聚类检索返回多个相关文档的摘要而不是全文。优化后重新评估Answer Relevancy 从 0.65 提升到了 0.82同时平均回答长度下降了 40%。这个案例说明评估数据不仅能告诉你哪里有问题还能告诉你为什么有问题和怎么改。另一个例子是关于工具调用的。评估发现某个智能体的工具调用成功率只有 70%失败主要集中在参数格式错误上。分析发现用户输入的日期格式五花八门下周三、3 月 15 号、明天而工具要求的参数格式是 ISO 8601。解决方案是在工具调用前增加一个参数标准化步骤用 LLM 把用户输入转换成标准格式。这个改动把工具调用成功率提升到了 93%。6. 写在最后一些个人体会做智能体评估这件事最大的感受是它不是一个技术问题而是一个工程习惯问题。技术方案其实都不复杂RAGAS、LLM-as-judge 这些工具用起来门槛也不高难的是坚持。坚持每次改动都跑评估坚持定期更新评估数据集坚持看评估结果做决策而不是拍脑袋。我见过评估体系做得最好的团队往往不是技术最强的团队而是工程纪律最好的团队。他们把评估当作和单元测试一样的基本要求没有评估结果的代码不允许合并。这种纪律一开始会觉得麻烦但半年后回头看它节省的时间远远超过投入的时间。另外一点体会是不要追求完美的评估体系。我见过一些团队花大量时间设计复杂的评估指标和流程结果评估体系本身成了负担没人愿意用。不如从一个简单的评估集开始先跑起来再逐步完善。一个能跑起来的简单评估比一个设计完美但没人用的评估体系有价值得多。最后评估的最终目的不是得到一个好看的分数而是让智能体真正解决用户的问题。分数只是手段用户满意才是目标。当评估分数和用户满意度出现背离时永远相信用户。
