LLM‑evals 与 LLM‑as‑judge：质量评估框架

1. 为什么 ChatGPT App 需要 LLM‑evals

本讲我们来拆解如何使用第二个 LLM 模型作为“法官”为你的 ChatGPT 应用打分：它要评估回答的哪些方面、如何把这些写进 rubric‑prompt、如何从评分中获得可用于 CI 的结构化 JSON，以及如何把这一切和你已经熟悉的 golden prompts 连接起来。有兴趣吗？那就开始吧。

想象你决定提升 GiftGenius 的质量，并给它加上了不错的文本回答。可如何判断这些回答是否“好”？又该如何测试？传统的 NLP 工程师会怎么做？很可能会提出 BLEU/ROUGE 一类的指标，或者与某个基准字符串进行对比。问题在于，对于 ChatGPT 类应用，这几乎没什么用。

首先，同一个任务往往存在多种正确表述。用户需要在预算内提供 5 个礼物想法——你可以给出不同的商品、用不同的顺序、以不同的文本样式来呈现。“逐字”或“逐 token”与基准对比并不能意识到回答依然是好的。其次，我们关心的一些因素是传统指标看不见的：实用性、是否完成用户场景、语气与风格、安全性。

例如，如果 GiftGenius 回答：“买点数码产品，肯定会喜欢。”——从形式上看可能包含了“正确”的词，但这是一个完全无用的回答。而如果它给出的礼物超出了预算，对于用户来说这已经是失败了，即便文字再优美也一样。

因此对 ChatGPT App 和智能体来说，我们更关注行为而不只是文本。我们关心：

• 事实与逻辑的正确性（correctness/accuracy）；
• 实用性与完整性（helpfulness/completeness）；
• 风格与语气（style/tone）；
• 安全性与政策遵循（safety）。

这正是 LLM‑evals 的用武之地：我们使用另一套 LLM（通常更强、更“严格”）作为法官，根据形式化的评分标准来评估我们的 App 回答。

这样我们获得的不只是“感觉变好了”，而是可量化的数字：各项标准的分数、最终 verdict、可在 CI、仪表盘和报告里分析的 JSON 结果。

2. 什么是 LLM‑as‑judge

概念很简单，几乎像课堂打分：有任务，有“学生”（我们的 GiftGenius）来回答，有“老师”（LLM 法官）来检查并打分。

法官模型会得到三个核心要素：

接下来流程取决于任务类型。

场景一：“单个回答 → 打分”。 法官查看单个回答，并按标准打分（0–10、0–5 等），同时给出最终的 overall 和 \”pass\”/\”fail\” 判定。 这对于回归和 CI 很方便：我们绑定阈值，观察质量是否下降。

场景二：“两个回答 → 选更优”。 法官收到回答 A 和 B，需要指出哪一个更好，或说明它们大致相当。这个格式适合 A/B 实验：比较两个 prompt 方案或两版 SDK/模型。

有时只需要 pass/fail 标志，不需要细粒度打分。比如对于“回答是否包含危险建议或违反政策？”这类 safety 用例，更适合拿到一维的“通过/未通过”以及简短解释。

关键点在于：LLM 法官并不是“全知更懂”的魔法，而是一套有明确规则的确定性流程。结果高度取决于我们是否恰当地 a) 描述了标准，b) 设定了量表，c) 分析了结构化的 JSON。

3. LLM 法官的典型任务示例

为了感受其在实践中的工作方式，我们来看看几个典型的任务类别，并把它们与我们的 GiftGenius 关联起来。

Correctness（正确性）

对于 GiftGenius，正确性例如意味着：

• 所有建议的礼物都确实在指定预算内；
• 礼物符合描述的人与场景；
• 没有明显的事实性错误（例如不给行动不便者推荐“去珠峰滑雪”之类的礼物）。

对于技术/分析类 App，correctness 还包括对公式、代码、计算和逻辑的校验。LLM 法官需要能识别是否违反了任务的基本事实和要求。

Helpfulness（实用性）

即便事实上是对的，回答也可能并不实用。对于 GiftGenius，一个有用的回答