#AI 应用为什么必须做 Eval

传统前端上线前会跑单元测试、组件测试、端到端测试和类型检查。因为我们知道：代码一改，行为可能退化。

AI 应用也会退化，而且退化更隐蔽。

你改了一句 Prompt，模型回答可能更礼貌，但事实准确率下降。你升级了模型，开放问答可能变好，但 JSON 格式稳定性变差。你调整了检索切片，召回更多内容，但答案开始混入无关段落。你为了降低成本换了便宜模型，延迟降了，投诉却上来了。

如果没有 Eval，这些变化只能靠“试几个问题感觉还行”来判断。

Eval 的价值，就是把 AI 应用的质量从主观感觉变成可追踪、可比较、可回归的工程对象。

#Eval 到底评估什么

很多人以为 Eval 是评估模型本身。真实产品里，更应该评估整个 AI 系统。

一次回答的质量不只由模型决定，还取决于：

• 用户输入如何被解析。
• Prompt 如何组织。
• 历史消息如何裁剪。
• 检索 query 如何生成。
• 检索结果是否相关。
• 工具是否调用成功。
• 输出格式是否符合 schema。
• UI 是否正确展示状态和引用。
• 安全策略是否生效。

所以 Eval 不是“给模型考试”，而是给 AI 功能做回归测试。

如果你的产品是客服问答，Eval 要评估答案是否正确、是否基于知识库、是否遗漏关键步骤。
如果你的产品是代码助手，Eval 要评估生成代码能否编译、是否符合 API、是否引入安全问题。
如果你的产品是数据分析助手，Eval 要评估查询字段是否正确、计算逻辑是否准确、图表解释是否过度推断。

#为什么手动试用不够

手动试用适合探索体验，但不适合管理质量。

第一，样本太少。开发者通常会试几个自己熟悉的问题，但真实用户会问出大量边界问题、脏数据问题、多语言问题、权限问题和含糊问题。

第二，判断不稳定。同一条回答，今天看觉得不错，明天看觉得啰嗦。不同同事对“好回答”的标准也不一样。

第三，无法回归。你很难记住上个版本对 100 个问题分别答成什么样，更难判断这次修改到底让哪些问题变好、哪些问题变差。

第四，无法自动进 CI。Prompt、RAG 配置和模型路由都可能在代码提交里变化。如果质量检查不能自动运行，回归就会晚到线上才被发现。

传统测试不会因为“我点了几下页面感觉可以”就省略。AI Eval 也是同理。

#Eval 解决的核心问题

第一个问题：能不能发布。

每次改 Prompt、换模型、改检索、加工具，都应该有一组最低质量门槛。例如格式通过率必须 99% 以上，关键任务准确率不能下降，安全拒答不能少于基线。

第二个问题：哪里坏了。

Eval 不只是给总分。它应该能告诉你失败来自检索、上下文、工具、格式、安全还是回答质量。否则分数下降也很难修。

第三个问题：是否值得换模型。

模型选择不能只看榜单和价格。你需要拿自己的业务样例比较不同模型在准确性、延迟、成本、格式稳定性和安全性上的表现。

第四个问题：线上质量有没有变差。

即使代码没变，知识库更新、外部 API 变化、用户问题分布变化，也会影响质量。Eval 应该和线上反馈一起形成持续监控。

第五个问题：团队能否对齐标准。

“回答好不好”很容易争论。Eval 通过 rubric、样例和失败分类，把抽象质量变成团队可讨论的标准。

#前端工程师为什么要关心 Eval

前端往往是 AI 体验的入口，也是质量问题最先暴露的地方。

用户不会说“你的 retrieval ranking 有问题”，他们会说：

• 它没理解我刚才上传的文件。
• 它一直重复。
• 它说已经保存了，但页面没变化。
• 它引用的内容点不开。
• 它给的代码不能跑。
• 它这次怎么和上次不一样。

这些问题背后既有模型链路，也有前端状态设计。

例如 streaming 过程中工具失败，前端如果只展示最终文本，就会掩盖失败状态。再比如引用来源丢失，可能不是模型没给引用，而是前端消息结构没有保存 source metadata。

做 Eval 时，前端工程师应该参与定义这些可观察结果：

• 消息状态是否正确。
• 引用是否能点击并定位。
• 工具调用状态是否和后端一致。
• JSON 输出是否能驱动组件渲染。
• 错误、拒答和追问是否有合适 UI。
• 用户反馈是否能绑定到 run id。

AI 质量不是纯后端问题。它最终会落在用户界面和交互流程上。

#Eval 的几种类型

规则评估适合确定性检查。

比如 JSON 能否 parse、字段是否符合 schema、引用 source id 是否存在、答案是否包含禁止内容、工具调用参数是否越权。这类检查应该优先用代码完成，因为便宜、稳定、可解释。

参考答案评估适合有明确正确答案的任务。

比如分类、抽取、数学计算、SQL 生成、API 参数生成。可以把模型输出和期望结果做精确匹配、模糊匹配或字段级比较。

LLM-as-judge 适合开放式回答。

例如摘要质量、回答完整性、语气是否合适、是否基于资料、是否解决用户问题。这类任务很难用规则完全覆盖，可以让评审模型按 rubric 打分。

人工评审适合高风险和校准。

人工不应该评全部样例，但应该评关键样例、抽样样例和 judge 有争议的样例。人工评审也是校准 LLM-as-judge 的重要方式。

线上反馈适合发现未知问题。

点赞、差评、重试、复制、编辑、转人工、用户投诉，都可以成为质量信号。它们不能直接等同于正确率，但能帮助你找到需要加入评估集的真实样例。

#一个 Eval 闭环

Eval 不是一次报告，而是一条持续运行的链路。

这个闭环的关键是：线上发现的问题要沉淀回评估集。否则团队会反复修同一类 bug。

#评估指标怎么选

不要一开始就追求一个万能总分。AI 应用的质量应该拆成多个维度。

常见指标包括：

对前端可见的 AI 功能，还应关注体验指标：

• 首 token 时间。
• streaming 中断率。
• 用户停止生成比例。
• 重新生成比例。
• 差评率。
• 引用点击率。
• 用户编辑模型结果的比例。

这些指标不都属于 Eval，但它们能帮助解释质量问题。

#Eval Case 应该长什么样

一个好的评估样例不只是用户问题。

它至少应该包含：

• 输入：用户消息、必要上下文、历史消息或文件引用。
• 场景：功能入口、用户角色、语言、权限。
• 期望行为：应该回答、拒答、追问、调用工具还是返回结构化数据。
• 评分标准：哪些点必须满足，哪些错误是严重错误。
• 元数据：用例类型、风险等级、来源、创建时间。

例如：

type EvalCase = {
  id: string;
  feature: 'support-qa' | 'order-assistant' | 'doc-summary';
  input: {
    messages: Array<{ role: 'user' | 'assistant'; content: string }>;
    context?: Array<{ id: string; title: string; content: string }>;
    userRole?: string;
  };
  expectedBehavior: 'answer' | 'refuse' | 'ask_clarification' | 'call_tool';
  rubric: string;
  tags: string[];
};

这类结构对前端也有价值。因为很多评估场景需要模拟真实 UI 状态，而不是只测一段孤立文本。

#常见坑

第一个坑：只评模型，不评链路。

如果评估时绕过检索、工具、上下文裁剪和输出解析，结果会比真实产品乐观。用户用的是系统，不是裸模型。

第二个坑：评估集只放理想问题。

真实评估集应该包含高频问题、边界问题、历史失败、恶意输入、权限不足、资料缺失和格式压力测试。只放简单样例会制造虚假的安全感。

第三个坑：过度依赖 LLM-as-judge。

评审模型也会有偏差。它可能偏好更长答案、语气更自信的答案，或被候选顺序影响。关键指标要抽样人工复核，规则能做的检查不要交给 judge。

第四个坑：只有总分，没有失败原因。

总分从 82 掉到 78 并不能指导修复。你需要知道是 groundedness 掉了、格式失败变多了，还是某类用户问题变差了。

第五个坑：Eval 不进发布流程。

如果评估只在大版本前手动跑一次，它很快会失效。至少核心评估集应该能在 CI、预发布或模型切换前自动运行。

#小结

AI 应用必须做 Eval，因为模型输出不是确定性函数，质量会随着 Prompt、上下文、检索、工具、模型和线上数据变化而波动。

Eval 的目标不是追求一个漂亮分数，而是建立可回归的质量管理机制：知道当前系统表现如何，知道改动带来了什么影响，知道失败样例如何进入下一轮修复。

对前端工程师来说，Eval 不只是后端测试。它会影响消息结构、状态展示、引用 UI、反馈入口、错误处理和发布门禁。真正可靠的 AI 产品，一定有一套持续运行的评估体系。