“这个回答挺好的。”很多 AI 产品的评审从这句话开始，也常常停在这里。
问题不在于这句话太主观。产品判断本来就包含主观部分。麻烦在于，团队里的每个人说“好”时，脑中想的可能不是同一件事。产品经理看任务有没有完成，研发关注调用是否成功，业务人员盯着数据口径，用户只在意自己是否还要追问。把这些判断压成一个“好不好”，后续既无法统计，也不知道应该改 Prompt、知识库还是工具链路。
质量评估的第一步，是把这句模糊评价拆开。
质量来自任务，不来自模型
同一段输出放进不同产品，结论会完全不同。广告文案可以允许发挥，经营分析必须守住数据口径；聊天陪伴重视交流感，退款 Agent 还要遵守权限和流程。模型没有一套脱离场景的“质量”。质量描述的是：在给定用户、任务和约束下，系统完成目标的程度，以及它为此付出的代价。
以全书的业务问答 Agent 为例。用户问：“华中区本月消耗为什么下降？”一句通顺的解释远远不够。系统需要识别“华中区”“本月”“消耗”和“下降原因”，调用合适的数据工具，使用正确的同比或环比口径，再把结论和证据对应起来。如果答案碰巧正确，查询参数却用了全国范围，这次运行仍然有问题；如果结论正确但连续重试十次，质量风险落在成本和稳定性上。
因此，定义质量时先写清任务，再写失败。一个实用的定义通常会覆盖结果和过程：回答是否正确、用户是否完成任务、执行路径能否接受、风险约束有没有被破坏。延迟和成本也要看，不过它们通常是直接采集的运行指标，不必为了统一展示再包装成“质量分”。
这里还有一个容易漏掉的问题：你到底在评价什么？一次模型输出、一次工具调用、一轮请求和整段会话不是同一个对象。判断引用是否忠于检索材料，需要看生成步骤及其证据；判断用户最后有没有解决问题，则要看完整会话。对象选错，评价器再精巧也只是在回答另一个问题。
先读失败，再建立分类
质量维度不能只靠会议讨论出来。团队最好先读一批真实运行记录，里面既要有正常请求，也要有差评、长耗时和高风险案例。阅读时记录可见现象，例如“时间范围少了一天”“已拿到结果却继续调用”“后续追问丢失区域条件”。“模型能力不足”不算好标签，因为它无法指向动作。
这一步通常叫开放编码。积累几十个案例后，再把相近现象归到较稳定的失败类型中。分类要能区分问题，也要能连接修复责任：意图理解错误可能落到 Prompt 或路由，工具参数错误要检查 Schema 和参数组装，证据不足可能来自检索，重复调用则要看停止条件。
错误分类不是越细越专业。每个案例单独一类，无法统计；“回答错误”又宽得没有用。判断分类是否合适，可以看两件事：同一案例在相同规则下能否稳定归类，这一类问题是否对应相近的改进办法。严重越权即使出现不多，也可能比高频的表达冗长优先级更高，所以排序还要考虑影响范围和风险。
分类稳定后，质量维度才有了落脚点。团队可以从最影响业务的失败中挑出少量维度，为每个维度写清合格、失败和边界案例。至此，“感觉不好”才开始变成一套可执行的评价语言。
Score 是一条有来历的判断
Score 可以是数字、布尔值或类别。它的价值不在形式，而在语义。
假设页面上出现一个 0.8。它可能是正确率，也可能是 Judge 的置信度，甚至是五分制换算结果。没有定义时，这个数字不能比较。一个可用的 Score 至少能回答：评价对象是谁，衡量哪一项质量，由什么方法产生，值域如何解释，什么情况需要行动。
例如，“工具参数正确”适合关联到工具步骤，取值为通过或失败；“本轮回答正确”可以关联一次请求；“会话任务完成”需要挂到整段 Session。错误类型更适合类别值，人工对表达质量的判断可以使用有序等级。只有当评分者能稳定区分相邻数值时，连续分数才有意义。无法解释 73 分和 76 分差别的百分制，只是看起来精确。
每个 Score 最好只表达一个维度。把准确、简洁、安全和成本混成“综合质量 82 分”，会遮住版本间的真实变化。新版可能更准确，却更容易越权；总分相抵后，团队什么也看不见。
还要保留分数的来源。用户反馈、人工标注、代码规则和模型 Judge 的可信边界不同。记录评价方法、规则或 Prompt 版本、时间和理由，日后才能判断分数变化究竟来自产品，还是评价标准改了。在 Langfuse 中，这些结果可以保存为 Score，并关联 Trace、Observation、Session 或 Experiment；其他平台可能叫 Feedback、Annotation 或 Evaluation Result。名字可以换，语义和来源不能丢。
评价方法要与问题匹配
能够写成确定条件的问题，优先交给代码。JSON 是否合法、金额能否解析、禁止工具有没有被调用，这些规则运行便宜，结果也容易复现。它们很适合全量检查和发布门禁。规则的局限同样清楚：出现了某个词，不代表回答相关；带有引用编号，也不能证明结论受证据支持。
人工评审适合标准尚未稳定，或者后果较重的判断。人可以解释为什么某个边界案例算失败，也能发现原有量表漏掉的问题。人工并非天然客观。没有统一说明和正反例，不同审核者照样会给出冲突结果。
语义判断数量较大时，可以使用 LLM-as-a-Judge。它把一次人工评审任务写成结构化模型调用：提供待评价内容、所需证据和评分量表，再要求模型输出稳定格式。比如检查“回答是否忠于数据”，Judge 需要同时看到回答和查询结果，并被明确告知只判断数字与结论能否由结果支持，不评价文风。
真正的项目往往混合使用这些方法。规则守硬约束，Judge 扩大语义检查的覆盖面，人工处理争议和高风险案例。怎么分配取决于判断用途。用于发现趋势的信号可以容忍一些噪声；用于阻断发布的判断需要更可靠的证据和失败处理。
Judge 也需要被评估
Judge 本身仍是一个 AI 应用。它有 Prompt、模型、输入映射和随机性，也会偏爱更长或更流畅的回答。让它稳定输出数字，不等于它理解了团队的标准。
校准从一组人工确认的样本开始。样本中要有常见情况，也要保留高风险和容易争议的边界。业务人员依据同一量表给出预期标签；如果审核者之间长期无法一致，应先修正量表。此时要求 Judge“猜对”没有意义。
然后固定 Judge 的模型和 Prompt，让它独立评价这批样本，并把结果与人工标签逐项比较。二分类只看准确率容易受类别比例影响。假设 95% 的请求都安全，一个永远回答“安全”的 Judge 也有 95% 准确率，却漏掉全部风险。混淆矩阵能显示误报和漏报，再结合 precision、recall、F1 观察错误方向。安全场景通常更怕漏判，客服升级可能更愿意接受多送一次人工复核。阈值应服从后果，而不是照搬示例。
发现分歧后要回到案例。原因可能是量表含糊、字段映射错误、参考证据不足，也可能是人工标签有争议。调整 Judge 后重新运行，并留出没有参与调试的样本，避免它只适配已知案例。产品分布、模型或评价 Prompt 发生明显变化时，也要重新校准。
Langfuse 可以用 Dataset 保存带预期标签的案例，通过 Experiment 运行 Judge，再比较预测与 expected output。这里需要注意当前版本边界：截至 2026-08-18，Langfuse v4 的在线 Evaluator 只读取目标 Observation 上可映射的字段，不会自动加载同一 Trace 的兄弟或子节点，也不会读取完整 Session 内容。需要任务级证据时，应提前汇总到目标 Observation，或改用 Experiment、外部评估流水线。旧 Trace 级 Evaluator 已进入弃用路径；Cloud 兼容期与自托管 v3/v4 也不能混为一谈，配置前应核对服务器、SDK 与功能矩阵。
校准的结果应说明适用范围，例如：“这个版本在这类样本上，对某项判断足够可靠，可以用于抽样监控”，或者“高风险漏判仍然偏多，只能辅助人工”。只报告“Judge 准确率 92%”，无法指导它能否参与发布门禁。
讨论“新版质量提升”时，团队至少应能拿出任务目标、失败类型、Score 的语义和来源，以及 Judge 在已知样本上的可信范围。
参考资料
系列目录：AI 应用可观测性与评估