第 5 章 — LLM 应用的评估
《LLM Primer V: Building Real-World LLM Applications》 章节走读的第五篇。这一章承认 assertEqual 在 LLM 输出上已经死了,再围绕锚点法官、RAG 三角、轨迹测试,把测试纪律重新搭起来。
这一章为什么存在
经典软件测试建立在这样一个假定上:正确的输出就是那个特定的输出 —— 函数返回 42,字符串等于 “Hello, world”,JSON 跟 fixture 一致。LLM 系统会产出语义等价但字符不同的改写,而支撑了软件测试五十年的精确匹配 assert 一到重生成就塌。团队接着去用 BLEU、ROUGE、embedding 余弦相似度,然后发现这些指标跟人类在真正重要的事上 —— 答对没答对、有没有落地、有没有回答这个问题 —— 的判断关联很弱。第 5 章围绕真正管用的东西,把测试纪律重新搭起来:带锚点的 LLM-as-a-judge 评分标准、RAG 三角、智能体轨迹测试,以及那条 “生产 trace 喂进评估集、评估集把下一次发布卡住” 的持续闭环。
5.1 评估的缝与 LLM-as-a-judge
评估的缝,是 “经典测试能测的” 跟 “LLM 输出真正需要测的” 之间的距离。精确匹配和参考字符串类指标,在改写密集的任务上抓不到任何有趣的失败。LLM-as-a-judge 是把这道缝合上的主力,而让它跟一个魔术表演分开的是两项纪律。第一,法官的评分标准是有锚点的:每一个分值都有书面定义,理想情况下带一个示例,让法官不是在自由联想一个数。第二,法官在给分之前先写出理由,因为不得不写理由的法官打分会更一致。程序化的检查是法官的补丁,用在能确定性验证的地方 —— JSON 能不能 parse、必填字段是否都有、有没有禁用字符串、响应长度在不在范围。法官不是万能的;它覆盖的是确定性检查覆盖不了的那片地。
5.2 RAG 三角 —— 上下文、落地、答案相关
对检索系统,已经沉淀下来的模式是分别评估三个顶点。上下文相关度问的是,检索出来的 chunk 是不是真的跟 query 相关,它把检索的失败从生成的失败里分离出来。落地度(groundedness)问的是,生成的答案是不是从检索到的上下文里推出来的,它抓那些能过形状校验却是幻觉的答案。答案相关度问的是,答案有没有回答用户实际问的那个问题。分开打分,三个顶点就能定位失败:上下文相关度低指向检索,落地度低指向生成器,答案相关度低指向路由器或系统在回答一个邻近但不同的问题。RAGAS 把三角化成一条批处理管道;法官模型的质量主宰打分的质量,所以法官本身也是团队要评估的一个组件。
5.3 框架分工与智能体回归
三种框架各有各的生态位。RAGAS 用一份问答对数据集做 RAG 三角的批处理评估,是做定期数据集评估的对的工具。TruLens 把反馈函数挂在实时生产流量上,直接在 trace 上算三角,把 “生产” 和 “评估” 之间的回路接上。DeepEval 把 LLM 测试当作 CI gate 来跑 —— 就像 pytest 跑单元测试那样 —— 并按每个指标设阈值。智能体把这套东西从三个方向扩展:轨迹快照测试对固定输入断言工具调用序列的形状,抓结构漂移;不变量断言校验智能体没调禁用工具、没跳过必须的审批;评分标准测试给轨迹本身打分,判断这条路径合不合理。一个用错的方式得到对答案的智能体,离 “用同样错的方式得到错答案” 只差一次 prompt 变更 —— 而轨迹测试就是抓这个的纪律。
第 5 章为后面铺了什么
评估需要生产 trace 来采样。CI gate 需要真实的回归来防守。这条持续改进的闭环只有在有一层可观测性 —— 记录每一次调用的每一步:模型调用、工具调用、检索结果、子智能体的跳转、成本、延迟、用户反馈 —— 时,才能跑起来。第 6 章就是那一层。它走 OpenTelemetry 的 GenAI 语义约定、真正对 LLM 系统起作用的那几个指标、平台选择,以及 —— 最重要的 —— 那条 “把低分 trace 送回下一次发布评估集” 的导出管道。
明天 — 第 6 章:AI 可观测性与追踪。那层让评估和调试都变得可能的底座 —— 一次调用对应一棵嵌套的 trace,把成本和质量都作为一等属性挂上去。
