前端学 LLM

LLM 评估体系专题总览

LLM 应用进入生产后，最危险的状态不是“偶尔答错”，而是团队无法判断一次改动到底让系统变好了还是变差了。

换了模型、改了 prompt、调整了检索参数、增加了工具、开放了 Agent 步骤之后，如果没有评估体系，产品和工程只能靠几个演示样例、用户投诉和主观感觉做决策。这样的系统可以做原型，但很难稳定运营。

LLM 评估体系的目标不是追求一个统一总分，而是把业务场景拆成可复用样本、可解释指标、可执行门禁和可回放反馈。本专题包括三篇文章：《黄金数据集建设》《LLM-as-Judge 工程化》和《持续评估、质量门禁与线上反馈闭环》。

提出问题：为什么 LLM 应用需要系统化评估

假设一个企业已经上线了三类 AI 能力：知识库问答、客服助手和运营 Agent。

知识库问答需要基于内部文档回答客户问题；客服助手会读取工单、生成回复草稿并建议下一步；运营 Agent 会查询 CRM、分析客户风险并创建跟进任务。它们都用了 LLM，但失败方式完全不同。

能力使用者输入输出失败代价
知识库问答客服、售前、客户用户问题、权限、知识库带引用答案误答、引用错误、越权引用
客服助手一线客服工单、历史对话、用户状态回复草稿、分类、建议动作口径错误、遗漏关键信息
运营 Agent运营、客户成功任务目标、CRM、工单、工具结果风险判断、任务创建计划跑偏、误调用工具、重复写入

没有 AI 时，团队通常依赖人工抽查、业务报表和事故复盘。引入 LLM 后，问题变成：模型输出不是单一确定结果，质量会随上下文、知识库、工具、模型版本和用户输入变化。只看最终满意度太慢，只看离线样例又不够贴近线上。

所以评估体系要回答一个工程问题：在什么样的证据下，团队可以允许一次模型、prompt、检索、工具或 Agent 策略变更进入生产。

分析问题：不同 LLM 能力要评估不同风险

LLM 评估不是一个任务，而是一组任务。不同能力的评估对象不同，不能用同一张表打天下。

评估类型核心对象主要问题常见指标人工位置
RAG Eval检索、证据、答案、引用是否找到正确证据，答案是否忠于证据recall@k、precision@k、faithfulness、citation accuracy标注黄金证据、复核争议答案
Tool Eval工具选择、参数、权限、执行结果是否该调用工具，参数是否正确，副作用是否受控tool selection accuracy、argument accuracy、permission pass rate、side-effect safety审核高风险动作、标注误调用
Agent Eval目标、计划、步骤、恢复是否按目标推进，是否跑偏、循环、误执行task success rate、plan adherence、loop rate、recovery success、human takeover rate审核失败轨迹、定义任务成功标准
输出质量 Eval分类、抽取、生成、改写是否满足业务口径和格式要求exact match、field F1、rubric score、schema pass rate标注标准答案、校准评分 rubrics

模型适合参与评分、归因和样本初筛，但评估体系本身不能只交给模型。人工标注要定义什么是“好结果”、什么是“可接受结果”、什么是“必须拦截的坏结果”。线上反馈要负责发现离线样本没有覆盖的新失败类型。

收益来自三处：

  • 变更前能比较不同方案，而不是凭感觉选模型或 prompt。
  • 上线时能设置质量门禁，防止明显回退进入生产。
  • 上线后能把用户反馈、人工纠错和事故样本沉淀为回归集。

成本也很真实：需要样本建设、标注规范、评估运行、报告分析、门禁维护和人工复核。低风险原型可以先用人工抽查；一旦输出影响客户、数据、流程或业务承诺，就必须进入工程化评估。

列举方案：从抽查到 Eval + Ops

评估体系可以分层建设，不需要第一天就做成完整平台。

阶段做法增加的能力新增成本
人工抽查每周抽样看 trace 和用户反馈快速发现明显问题依赖经验，难以回归
小型黄金集固定 50 到 200 条关键样本能比较 prompt、模型和检索改动需要标注和维护
自动评分引入规则、schema 校验和 LLM-as-Judge扩大覆盖范围，降低人工成本需要校准 judge 和抽检
分层评估分别评估 RAG、Tool、Agent 和最终输出能定位质量问题来源指标体系更复杂
质量门禁在 CI、灰度或发布前阻断回退让评估进入发布流程需要阈值、豁免和 owner
线上闭环收集反馈、纠错、事故和低置信样本评估集持续贴近真实流量需要反馈产品和标注流程

RAG Eval 要优先拆链路：先看检索有没有找到证据，再看答案是否被证据支持，最后看引用是否准确。只给最终答案打一个“好/坏”分，无法判断应该改 chunk、embedding、rerank 还是 prompt。

Tool Eval 要关注工具边界：模型是否选择了正确工具，参数是否来自可信上下文，权限是否通过，写入动作是否需要人工确认，失败后是否会重复执行。工具评估不只是“调用成功率”，还要看是否不该调用却调用了。

Agent Eval 要评估轨迹，而不是只评估最终答案。Agent 的风险包括 plan drift、tool misuse、infinite loop 和恢复失败。评估样本要包含目标、允许工具、预算、预期步骤、成功条件和不可接受行为。

决策判断：什么时候需要哪种评估

场景条件推荐方案不推荐方案判断理由额外成本
原型阶段、低风险、内部试用人工抽查 + 失败样本记录建大型评估平台先验证需求和失败类型每周人工复盘
输出必须结构化入库Schema 校验 + 黄金集回归只看人工满意度格式错误会污染业务数据schema、重试、错误分类
答案必须引用内部资料RAG Eval只做答案打分需要定位检索、生成和引用问题黄金证据标注
模型会调用查询或写入工具Tool Eval + 权限门禁只统计 tool success成功调用不代表调用正确工具轨迹标注、确认审计
Agent 会自主规划多步骤任务Agent Eval + 回放 + 人工接管用单轮问答评估需要评估步骤、预算、恢复和副作用trace 存储、轨迹评分
高频生产链路持续迭代持续评估 + 质量门禁 + 线上反馈临时抽测变更频繁，必须防回退CI/灰度集成、owner 机制

明确的判断是：评估复杂度要跟业务风险和系统复杂度同步增长。简单 prompt 不需要重型 Agent Eval；能影响客户承诺、业务数据或外部动作的系统，也不能只靠几个示例和主观体验。

常见反模式有四类。

第一，把所有能力都用同一套打分。RAG、Tool 和 Agent 的失败对象不同，混在一起会让报告看起来完整，却无法指导修复。

第二，用 LLM-as-Judge 代替人工标注。judge 可以扩展评估规模，但标准、样本和高风险争议仍然要人工校准。

第三，只评估成功样本。生产风险往往来自拒答、越权、工具失败、状态不确定和长尾输入，这些负样本必须进入黄金集。

第四，没有质量门禁。评估报告如果不影响上线、灰度、回滚和 owner 责任，就只是一个漂亮仪表盘。

结论收束：把评估变成发布和运营机制

LLM 评估体系最终推荐的不是单个指标，而是一条闭环：用黄金数据集定义质量，用 LLM-as-Judge 和规则扩大自动评估，用人工标注校准标准，用质量门禁控制发布，用线上反馈持续补充样本。

最低可上线版本应该包括：

  • 场景边界：明确用户、输入、输出、权限和失败代价。
  • 黄金样本：覆盖高频、长尾、拒答、越权和高风险样本。
  • 分层指标：RAG、Tool、Agent 按不同对象评估。
  • 人工标注：有标注规范、仲裁机制和抽检比例。
  • 质量门禁：关键指标低于阈值时阻断发布或进入人工审批。
  • 线上反馈：用户反馈、人工修改和事故样本能回流到评估集。
  • 可观测性：保存 prompt、上下文摘要、检索结果、工具调用、模型版本和输出。
  • 回滚恢复：评估失败或线上退化时能定位变更并回滚。

当系统仍是低风险原型时，可以降级为人工抽查和小样本回归。当输出进入客户触点、业务记录、工具执行或 Agent 自主流程时，评估必须升级为工程机制。