前面五章建起来的系统，现在面临一个朴素的问题：你改了提示词、换了模型、调了检索，然后呢？打开聊天框试三个例子，觉得「好像变好了」？这就是绝大多数 AI 应用的真实状态——凭感觉迭代。传统软件有测试，AI 应用的对应物是 评估（evals）。一句话概括这一章：没有评估，前面所有章节的东西你都只是在碰运气。
为什么「试试感觉不错」不成立
传统代码改坏了，测试会红。AI 系统改坏了，表面风平浪静——它照样流畅地输出，只是边缘情况的答案悄悄变蠢了。而你手工试的那三个例子，恰好都是最容易的例子。模型的输出是分布，不是函数：同样的输入跑两次都可能不同，「试了三次都对」和「通过率 99%」之间隔着几百个没测过的输入。
更隐蔽的是回归不可见：为了让模型学会处理「用户骂人」的情况，你在提示词里加了一条规则，骂人场景修好了——但这条规则同时让正常投诉的回复变得生硬。没有对照评估，这种拆东墙补西墙你永远不会发现。
评估集：不是题库，是资产的快照
评估的第一步是造一个 评估集：一批「输入 + 期望表现」的样例。它从哪里来？最好的来源是线上真实数据——用户真实问过的问题、系统真实答砸过的案例。每出一次线上事故，就把那个输入收进评估集。久而久之，评估集成了这个系统最值钱的资产：它是「我们的用户到底在意什么」的快照，比任何通用 benchmark 都懂你的业务。
大白话：通用 benchmark 考的是「别人家的孩子」，评估集考的是「你家的孩子」。换模型、改提示词时，你关心的是后者。
规模上有个反直觉的事实：起步时五十个精心挑选的样例，好过五千个随手抓的。因为评估集的价值在于覆盖面——每个已知的失败模式、每类典型输入至少占一席——而不在于数量。样例要持续维护：太容易的删掉（已经 100% 通过的样例不提供信息量），新失败模式随时补入。
判分：模型评模型，人评模型评得好不好
判分（「这个回答算好吗」）比造题难。三种办法，按成本递增：
- 程序化判分：输出有确定答案时用——JSON 能不能解析、关键字段对不对、答案里有没有出现禁用词。便宜、绝对可靠，但只覆盖结构化任务。
- 模型判分：让另一个（通常更强的）模型按评分细则给回答打分，即「LLM 当裁判」。便宜、可扩展，能评开放式回答；代价是它有自己的偏见——偏爱长的、偏爱措辞自信的、偏爱自己生成的风格。所以评分细则要写得像合同：列出具体的扣分项，而不是「给 1 到 5 分」。
- 人工判分：最贵最慢，但它是校准器——定期抽样人工评一批，用来检验「LLM 裁判的分数和人类判断一致吗」。不一致，就先修裁判，再信它的分数。
工程上的组合通常是：每次改动跑程序化判分 + LLM 裁判（几分钟、几块钱），每周人工抽样校准一次。
评估驱动的迭代节奏
有了评估集和判分器，迭代从碰运气变成科学实验：改一个变量，跑全量评估，看总分和每个失败类别的变化，决定留下还是回滚。这就是第三章说的「提示词可回归」的落地方案。
架构师视角下，评估还有一个更深的作用：它是全书的枢纽。后面第八章的成本账（便宜模型掉多少分）、第九章的微调决策（微调到底提升了吗）、第十二章的自训模型（训出来的模型到底变好了没有）——每一个重大决策的度量衡都是评估。不会造评估的人，在后面的每一步都是盲人。
下一章换一个方向：系统内部做对了还不够，它还得在外部世界的混乱里活下来——超时、限流、模型提供商宕机。可靠性工程。