1. 为什么智能体项目绕不开 LLM Evals做智能体开发的人大概都经历过这样一个阶段Demo 跑得飞起老板看了点头产品经理拍板要上线结果一进真实流量就翻车。用户问东它答西工具调用乱成一锅粥RAG 检索回来的内容驴唇不对马嘴。你回头去查日志发现模型输出飘忽不定同一个问题今天答得对、明天答得错根本没法复现。这个问题的根源不在于你的 Prompt 写得不够花哨也不在于你选的模型不够大而在于你没有一套生产级的评估体系。LLM Evals 这个词这两年火起来不是因为它听起来高级而是因为它是智能体从能跑到能用之间那道必须跨过去的坎。我见过太多团队智能体框架选的是最时髦的工具链搭得花里胡哨但评估环节就是人工点几下看看输出顺不顺眼。这种做法在 Demo 阶段没问题一旦要面对成百上千种用户输入、要接入真实业务数据、要做版本迭代就彻底失控了。因为你根本不知道这次改动到底是让系统变好了还是变坏了你只能靠感觉。LLM Evals 要解决的核心问题就一个把感觉还行变成数据说话。它是一套方法论加工具链的组合让你能够系统性地、可重复地、自动化地衡量一个大模型应用或智能体在特定任务上的表现。注意我这里说的是特定任务因为评估从来不是泛泛地测这个模型好不好而是测这个模型在我的场景下、完成我的任务时表现如何。这套东西适合谁来学如果你只是拿大模型聊聊天、写写文案那确实用不上。但只要你开始做智能体、做 RAG 应用、做任何需要把大模型接入生产环境的项目评估体系就是你的基础设施跟数据库、日志系统是一个级别的东西。不管你是刚入门的智能体开发者还是已经带团队做了一年多 Agent 的老手这篇文章里的东西都能直接拿去用。2. 智能体评估体系到底在评什么2.1 从传统软件测试到 LLM 评估的思维转变传统软件测试的逻辑是确定性的输入 A经过函数 f必然得到输出 B。你写个断言assert f(A) B跑通了就是对的跑不通就是有 bug。这套逻辑在 LLM 应用里完全失效因为大模型的输出是概率性的同一个输入温度参数稍微一变输出就完全不同。更麻烦的是很多任务的正确答案本身就不是唯一的——你让智能体写一段推荐语十种写法可能都对。所以 LLM 评估的第一个思维转变就是从对错判断转向质量度量。你不再问这个输出对不对而是问这个输出有多好。这就引入了评分的概念可能是 1 到 5 分的 Likert 量表也可能是 0 到 1 的连续值还可能是多个维度的综合打分。第二个转变是从单点测试转向分布评估。你不能只测一个输入你要测一批输入看整体表现。因为大模型在某些输入上表现好、某些输入上表现差你需要知道的是它在你的业务分布上的平均表现和方差而不是某一个 case 的表现。第三个转变是从人工判断转向自动化 人工校准。纯人工评估成本太高你不可能每次改个 Prompt 就拉十个人来打分。但纯自动化评估又容易失真所以生产级方案通常是自动化跑分 人工抽样校准两者结合。2.2 智能体评估的四个核心维度一个智能体的表现不能只看最终输出。因为智能体跟单纯的 LLM 调用不一样它中间有推理、有工具调用、有多轮交互。所以评估要分层看第一层是最终响应质量。用户看到的那个答案是否准确、是否完整、是否相关、是否有害。这是最直观的一层也是大多数团队最先做的。第二层是推理过程质量。智能体在给出答案之前它的思考链条是否合理有没有跳步有没有逻辑漏洞这一层在需要多步推理的任务里特别重要比如数学题、复杂规划、多跳问答。第三层是工具调用质量。智能体有没有选对工具参数传得对不对调用顺序合不合理有没有该调工具的时候不调、不该调的时候乱调这一层是 Agent 区别于普通 LLM 应用的关键。第四层是检索质量针对 RAG 场景。检索回来的文档是否相关是否覆盖了回答问题所需的信息排序是否合理这一层直接决定了 RAG 系统的上限。我见过很多团队只评第一层结果就是输出看起来还行但一深究就发现智能体是靠猜蒙对的换个稍微变形的输入就崩了。所以生产级评估必须四层都覆盖至少要有前三层。2.3 离线评估与在线评估的分工评估体系要分两条线走离线评估和在线评估。离线评估是在你发布之前跑的用一批固定的测试集快速验证这次改动有没有引入回归。它的特点是快、可重复、成本可控。你每次改 Prompt、换模型、调工具都先跑一遍离线评估通过了再上线。在线评估是在真实流量上跑的用真实用户输入观察真实表现。它的特点是最贴近实际但反馈慢、成本高、不可重复。在线评估通常用 A/B 测试的方式把流量分到两个版本对比关键指标。两条线的关系是离线评估负责守门防止明显退步的版本上线在线评估负责探路发现离线测试集覆盖不到的问题。两者缺一不可但优先级上离线评估要先建起来因为它是你迭代速度的保障。3. 主流评估工具与框架选型3.1 RAGASRAG 场景的评估利器RAGAS 是目前 RAG 评估领域用得最多的开源框架之一。它的核心价值在于把 RAG 系统的评估拆成了几个可量化的指标而且这些指标大多不需要人工标注参考答案靠 LLM 自己就能算出来。RAGAS 最常用的几个指标Faithfulness忠实度生成的答案是否完全基于检索到的上下文有没有编造。这个指标直接对应幻觉问题。Answer Relevancy答案相关性答案是否切题有没有答非所问。Context Precision上下文精确率检索回来的文档里有多少是真正相关的排序是否合理。Context Recall上下文召回率回答问题所需的信息有多少被检索回来了。前两个指标不需要标准答案后两个需要。这就是 RAGAS 的巧妙之处它用 LLM 作为裁判把很多原本需要人工标注的评估变成了自动化。我实测下来RAGAS 的 Faithfulness 和 Answer Relevancy 在大多数场景下跟人工判断的相关性能到 0.7 以上作为快速迭代的信号是够用的。但要注意它本身也依赖 LLM所以裁判模型的选择会影响结果稳定性。我的经验是裁判模型至少要用跟被测模型同级别或更强的否则会出现弱模型评强模型的偏差。3.2 LLM-as-judge用模型评模型的正确姿势LLM-as-judge 是现在自动化评估的主流范式核心思路就是让一个强模型来给另一个模型的输出打分。听起来有点自己评自己的嫌疑但实践证明只要设计得当它跟人工判断的一致性可以做到很高。用好 LLM-as-judge 有几个关键点第一评分标准要具体到可操作。你不能只说给这个答案打 1 到 5 分你要给出每个分数对应的具体标准。比如 5 分是完全准确、完整、无冗余3 分是基本准确但有细节缺失1 分是答非所问或包含错误信息。标准越具体评分越稳定。第二要提供参考示例。在 Prompt 里给几个打分示例让裁判模型知道你的尺度。这叫 few-shot calibration能显著提升一致性。第三要控制位置偏差。如果你让裁判模型对比两个答案它会倾向于选第一个或第二个这跟答案质量无关。解决办法是交换顺序跑两次取平均。第四要定期人工校准。抽一批裁判模型的打分结果人工复核看偏差有多大。如果偏差超过可接受范围就要调整评分标准或换裁判模型。3.3 工具选型对比工具/框架适用场景核心优势主要局限RAGASRAG 系统评估指标成熟、无需标注、社区活跃主要面向 RAGAgent 场景覆盖有限DeepEval通用 LLM 评估指标丰富、支持自定义、CI 集成好部分指标依赖 OpenAI国内用需替换LangSmith全链路追踪 评估跟 LangChain 生态无缝、可视化强商业产品免费额度有限PromptfooPrompt 对比测试配置简单、支持多模型对比深度评估能力相对弱自建评估脚本高度定制场景完全可控、贴合业务开发成本高、维护麻烦选型的逻辑很简单先用现成的不够用再自建。大多数团队从 RAGAS 或 DeepEval 起步就够了等业务复杂到现成框架覆盖不了再考虑自建。不要一上来就自建那是浪费生命。4. 从零搭建生产级评估体系的实操路径4.1 第一步构建评估数据集评估数据集是整个体系的地基。没有数据集后面所有工具都是空转。构建数据集的核心原则是覆盖真实分布包含边界情况。具体做法从真实日志里采样。如果你已经有线上流量直接从日志里抽一批真实用户输入这是最贴近实际的。人工构造边界 case。比如空输入、超长输入、包含特殊字符的输入、多轮对话中的指代消解、需要拒答的敏感问题。分层组织。按任务类型、难度、场景分组这样评估结果能看出系统在哪类任务上强、哪类弱。标注参考答案可选但推荐。不是所有指标都需要参考答案但有参考答案的指标如 Context Recall质量更高。数据集规模上我的经验是起步阶段 50 到 100 条就够用关键是覆盖度而不是数量。等你发现评估结果波动大、区分度不够再逐步扩充到几百条。不要一上来就搞几千条标注成本会让你崩溃。4.2 第二步定义评估指标与评分标准这一步是把好这个模糊概念拆解成可测量的维度。以智能体为例我通常会定义这几组指标响应质量组准确性答案是否符合事实完整性是否覆盖了问题的所有方面相关性是否切题简洁性是否有冗余过程质量组推理合理性思考链条是否逻辑自洽工具选择准确率是否选对了工具参数正确率工具参数是否传对步骤效率是否有多余的无效步骤安全组拒答准确率该拒答的是否拒答了有害内容率是否输出了有害内容每个指标都要有明确的评分标准。我建议用 1 到 5 分制因为粒度适中既不会太粗也不会太细导致评分不稳定。4.3 第三步搭建自动化评估流水线流水线的核心是输入数据集 → 跑智能体 → 收集输出 → 裁判打分 → 汇总报告。用 Python 伪代码示意一下核心结构import json from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy # 1. 加载评估数据集 with open(eval_dataset.json, r, encodingutf-8) as f: dataset json.load(f) # 2. 跑智能体收集输出 results [] for item in dataset: response agent.run(item[question]) results.append({ question: item[question], answer: response.answer, contexts: response.retrieved_contexts, ground_truth: item.get(reference_answer, ) }) # 3. 用 RAGAS 评估 eval_result evaluate( datasetresults, metrics[faithfulness, answer_relevancy] ) # 4. 输出报告 print(eval_result.to_pandas())实际生产里这个流水线要集成到 CI 里每次代码提交或 Prompt 变更都自动跑一遍结果不达标就阻断合并。这是保证迭代质量的关键机制。4.4 第四步建立基线与人机校准机制第一次跑完评估你会得到一组分数。这组分数就是你的基线。之后所有的改动都是跟这个基线比。但基线本身是否可信这就需要人机校准。具体做法是从评估数据集里抽 20 到 30 条人工打分然后跟裁判模型的打分对比。计算两者的相关性如果相关性低于 0.6说明裁判模型不可信需要调整评分标准或换模型。校准不是一次性的要定期做。因为你的业务在变、数据分布在变、模型也在更新裁判模型的表现也会漂移。5. 实操中踩过的坑与排查技巧5.1 评估结果波动大怎么办这是最常见的问题。同一批数据跑两次结果差很多。原因通常有三个一是模型温度参数没固定。评估时要把温度设成 0 或接近 0保证输出稳定。如果业务需要一定随机性那评估时也要固定随机种子。二是裁判模型本身不稳定。LLM-as-judge 的输出也有随机性解决办法是多次采样取平均或者用更确定的评分方式比如让模型输出结构化 JSON 而不是自由文本。三是数据集里有歧义样本。有些问题本身就有多种合理解读导致评分不稳定。这类样本要么剔除要么在评分标准里明确说明按哪种解读评。5.2 裁判模型跟人工判断不一致这个问题比波动更严重因为它意味着你的评估体系方向错了。排查思路先看是不是评分标准太模糊。把标准细化到每个分数都有具体描述通常能解决大部分问题。再看是不是裁判模型能力不够。如果被测模型是 GPT-4 级别的裁判模型至少也要同级别否则它理解不了答案的微妙之处。最后看是不是任务本身主观性太强。有些任务比如创意写作确实很难用自动化评估这时候就要接受人工评估为主、自动化为辅。5.3 评估成本失控LLM 评估是要花钱的尤其是用强模型做裁判的时候。控制成本的几个技巧分层评估核心指标每次都跑次要指标定期跑。采样评估数据集大的时候每次随机采样一部分跑而不是全量。缓存结果没变的部分不重复评估。用小模型做初筛先用便宜模型跑一遍把明显有问题的挑出来再用强模型精评。5.4 常见问题速查表问题现象可能原因排查方向解决建议评估分数忽高忽低温度未固定/裁判不稳定检查温度参数、多次采样固定温度、取多次平均分数普遍偏高评分标准太宽松复核评分标准细化标准、增加难度样本分数普遍偏低评分标准太严/裁判模型弱人工复核样本调整标准、换强裁判评估跑得特别慢串行调用/数据集太大看耗时分布并发调用、采样评估成本超预算全量跑强模型统计 token 消耗分层采样、小模型初筛跟人工判断差很多标准模糊/任务主观对比人工打分细化标准、接受人工为主6. 评估体系如何反哺智能体迭代评估体系建起来之后最大的价值不是知道现在多好而是知道往哪改。我自己的做法是每次评估跑完不只看总分更要看分项指标和失败样本。比如总分 4.2但工具调用准确率只有 3.1那就说明工具选择这块是短板下一步优化重点就在这。再比如失败样本里有一半是检索不到相关内容那就说明知识库覆盖不够要补数据。这种评估驱动迭代的循环能让你的智能体每周都有可量化的进步而不是靠感觉瞎调。我见过最快的团队一周能跑三轮评估迭代一个月下来效果提升非常明显。还有一个容易被忽略的点评估数据集本身也要迭代。随着业务发展用户输入分布会变老的测试集可能不再有代表性。所以要定期从新日志里采样补充到数据集里保持它的时效性。最后分享一个我个人的小技巧把评估结果做成趋势图每次迭代都记录。这样你不仅能看到当前状态还能看到变化趋势。当某次改动导致指标突然下降你能立刻定位到是哪次提交引入的。这个习惯看起来简单但坚持下来能帮你省掉大量排查时间。