AI 应用上线，最怕一句话：我感觉效果还行。

一、为什么必须做评测？

大模型应用和普通后端服务不一样。普通接口只要输入一样，结果基本稳定。大模型不一样，它会受模型版本、Prompt、检索结果、上下文顺序、工具返回、温度参数影响。今天答对，明天可能答偏。

所以，RAG 和 Agent 不能靠肉眼体验。你要把“感觉不错”拆成一套可以复盘、可以对比、可以卡上线的评测系统。

评测真正解决三个问题：第一，知道系统哪里好；第二，知道系统哪里坏；第三，知道新版本有没有把旧能力改崩。

二、先分清：离线评测和在线评测

离线评测，是上线之前跑固定题库。它像单元测试。你改了 Prompt，换了 Embedding，调了 chunk_size，必须跑一遍。否则你不知道到底是变好了，还是只是某几个样本看着变好了。

在线评测，是上线之后看真实表现。用户点踩、追问、投诉、转人工、工具报错、超时、成本升高，都是线上质量信号。离线评测挡住低级错误，在线评测发现真实世界的问题。

三、RAG 评测：先看检索，再看生成

RAG 的错误，通常不是一句“模型不行”就能解释。很多时候，是资料没有找对；也有时候，资料找对了，但模型没有按资料回答。

所以 RAG 评测必须拆两层。第一层看 Retriever：有没有把正确文档召回，正确文档是否排在前面。第二层看 Generator：答案是否忠于资料，是否答到用户问题，是否引用了正确来源。

RAGAS 的 Context Precision 就是典型检索排序指标，它关注相关 chunk 是否排在更靠前的位置。DeepEval 的 Faithfulness 则关注实际输出是否和 retrieval_context 保持事实一致。

四、Agent 评测：不只看答案，还要看轨迹

Agent 更复杂。它不是一次输入、一次输出。它会判断、路由、调用工具、读工具结果，再决定下一步。

所以评测 Agent，不能只看最终答案。还要看它有没有选对工具，有没有传对参数，有没有多调工具，有没有绕远路，有没有越权，有没有在高风险场景触发人工介入。

一个 Agent 表面答对，不代表流程对。比如它本该查订单接口，却从历史消息里猜了一个状态；本该拒绝高危操作，却直接调用了退款工具。这些都属于“最终答案看着不错，但执行链路有风险”。

五、LangSmith 评测的核心模型

LangSmith 的评测逻辑很清晰：先创建 Dataset，再定义 Target Function，再定义 Evaluators，最后运行 Experiment。

Dataset 是题库。里面放用户输入、参考答案、期望文档、期望工具、期望结构化输出。Target 是被测对象，可以是整个 Agent，也可以是某个 Retriever、某个 Prompt、某个 Tool Router。Evaluator 是裁判，可以是代码规则、人工审核、LLM-as-Judge，也可以是两版结果的 Pairwise 比较。

源码级压缩后，就是下面这条线。

六、源码级理解：evaluate() 到底做了什么？

不要把 evaluate() 理解成“让模型给模型打分”。它更像一个批处理执行器。它从 Dataset 里取样本，把 inputs 交给 target 运行，拿到 outputs，再把 inputs、outputs、reference_outputs 交给 evaluator 计算分数，最后把这些结果写入一次 Experiment。

真正关键的是：target 只负责产出结果，evaluator 只负责判断结果。两者必须隔离。否则你会把业务逻辑和质量判断混在一起，后面就无法复盘。

如果你评测 RAG，target 可以返回 answer、retrieved_docs、citations。如果你评测 Agent，target 还应该返回 tool_calls、trajectory、final_state、error。评测不是只要答案，而是要完整证据链。

七、Evaluator 怎么选？

能用代码规则判断的，不要一上来就用 LLM-as-Judge。JSON 是否合法，字段是否齐全，工具参数是否符合 schema，引用数量是否大于 0，这些都应该用规则。规则稳定、便宜、可重复。

语义相关性、答案忠实度、摘要质量、对话体验，才适合用 LLM-as-Judge。高风险样本，比如金融、法律、医疗、资金操作，要加入人工评审。

八、企业级评测架构怎么落地？

真正上线时，评测不是一个 Python 脚本。它应该接入你的 Java 主服务、Python AI 服务、Trace 日志、数据集管理、实验记录、质量看板和发布流水线。

推荐架构是：线上每次调用都打 trace_id。关键请求写入 Trace 存储。差评、转人工、异常、超时样本自动进入候选数据集。研发改完新版本后，Eval Service 批量跑离线题库。指标不过线，禁止发布。

九、回答错了，怎么定位？

没有评测时，回答错了只能靠猜。有评测后，可以顺着证据链定位。

如果正确文档没有召回，是 Retriever 问题。如果正确文档召回了但排在后面，是 Rerank 问题。如果资料对了但答案答偏，是 Prompt 或 Generator 问题。如果答案和资料矛盾，是 Faithfulness 问题。如果工具调错，是 Tool Router 或工具 schema 问题。

十、评测系统最容易踩的坑

第一，题库太少。5 条题跑通，只能说明 Demo 能跑，不能说明系统能上线。

第二，只看最终答案。RAG 和 Agent 必须看中间过程。检索文档、重排分数、Prompt、工具调用、工具返回都要进入评测证据链。

第三，过度依赖 LLM-as-Judge。裁判模型也会漂，也会偏，也会误判。必须抽样人工校准。

第四，没有回归门禁。没有门禁，评测就是报告。只有进入 CI/CD，低于阈值禁止上线，评测才真正有牙齿。

第五，失败样本不回流。线上出过的问题，不进入离线题库，下一次还会犯。

十一、总结

RAG 和 Agent 的质量，不是“看起来还行”。它必须被数据集验证，被指标度量，被实验对比，被 Trace 复盘，被发布门禁约束。

评测系统的价值，不是给一个漂亮分数，而是告诉你：到底是检索坏了、生成坏了、工具坏了、Prompt 坏了，还是成本和延迟撑不住。