3.5 Metrics：编译的指挥棒

3.5 Metrics：编译的指挥棒

本节摘要：指标是编译过程的方向盘：它给优化器提供"什么叫更好"的判断，还在自举时充当示范的质检员。本节讲指标的两种形态（规则函数与 LLM judge）、指标在编译与评估中的双重角色、指标失真的典型症状，以及设计一个"不容易被骗"的指标的实操手法。

指标为什么决定编译上限？因为优化器本质上是"在指标曲面上爬山"的搜索过程：指标在哪里隆起，搜索就往哪里走。指标测的不是你真正关心的东西，编译产物就精确地优化到你不在乎的方向上去——这比"没有指标"更危险，因为一切看起来都在正常运转，分数还在涨。

形态之一：规则函数

规则函数是普通 Python 函数，签名约定为接收预测、样例与轨迹三个参数，返回布尔或分数。最常用的是硬匹配类：

def exact_match(pred, example, trace=None):
    """预测答案与标准答案完全一致才得分。"""
    return pred.answer.strip().lower() == example.answer.strip().lower()

def contains_match(pred, example, trace=None):
    """标准答案出现在预测中即得分，适合长答案任务。"""
    return example.answer.strip().lower() in pred.answer.strip().lower()
​

规则函数的优点是便宜、确定、可复现；缺点是只认字面。exact_match 会把"Bern"与"伯尔尼"判为不同，把"the capital of Switzerland is Bern"判为不匹配；contains_match 又宽松到可以被"把标准答案整段复述"的策略骗过。规则函数适合答案空间封闭的任务（分类、枚举、格式化字段、有唯一标准答案的事实问答），开放式任务硬上规则函数，迟早教会模型说谎。

形态之二：LLM judge

LLM judge 用另一个模型当裁判，把"语义上对不对"交给它判断。DSPy 里裁判本身就是一个签名加预测器：

class AnswerJudge(dspy.Signature):
    """判断预测答案与标准答案在语义上是否一致。"""
    question = dspy.InputField()
    correct_answer = dspy.InputField()
    predicted_answer = dspy.InputField()
    is_correct = dspy.OutputField(desc="true 或 false")

judge = dspy.Predict(AnswerJudge)

def semantic_judge(pred, example, trace=None):
    verdict = judge(
        question=example.question,
        correct_answer=example.answer,
        predicted_answer=pred.answer,
    )
    return "true" in verdict.is_correct.lower()
​

裁判的两个工程参数要心里有数：成本与稳定性。成本方面，裁判意味着编译期间每条轨迹多一次模型调用，训练集与验证集的每一次打分都翻倍。稳定性方面，裁判自己也是模型，判断会漂——换裁判模型，同一批预测的分数可能差出好几个点。实操上有两条纪律：裁判与被评程序使用不同模型（避免同源偏好），裁判的判断定期抽样人工复核（建议每次编译后抽一成人工过目）。

指标的第二个身份：示范质检员

很多人把指标只当"打分工具"，低估了它在自举里的质检职能：优化器生成自举示范时，只有指标放行的轨迹才会变成示范。这意味着指标直接决定模型"看过什么范例"——比最终打分的影响更早、更深。一个只查答案不查过程的指标，会把"答案对、依据错"的轨迹放进去，模型学到的就是"大胆编，碰对了就行"。治理手法是让指标在轨迹模式下多做一层检查：trace 参数非空时，说明这次调用发生在自举期，此时可以加验中间字段（比如检查答案是否真的引用了给定证据文段），不合格的轨迹连带拒绝。

指标反馈在编译流程中的双重回路

图里能看到指标出现在两个位置：验收轨迹（内环）与评估候选（外环）。内环决定"模型学什么"，外环决定"搜索往哪走"——两环共用同一个指标函数，所以指标缺陷会同时污染两处，这正是它被称为"指挥棒"的原因。

指标失真的症状与修正

症状有典型三联。一，分数涨、业务不涨：验证集分数每轮创新高，真实用户反馈没有变化甚至变差，说明指标与业务目标脱钩。二，产物话术异常：编译后的答案出现奇怪的套话（比如总是把原文整段复述、总在结尾附加免责声明），这些多半是模型在钻指标的空子。三，不同轮次分数震荡剧烈：若指标本身靠 LLM judge，震荡可能来自裁判漂移而非程序变好变坏。修正的次序建议是：先规则后裁判（能用封闭答案空间就别上裁判）；先窄后宽（先在封闭子任务上验证指标，再扩展到开放式任务）；先抽样后全量（新指标先在一百条人工核对过分数，再放心交给编译器大规模使用）。

一个来自实战的例子收尾：某团队做合同问答，最初用关键词命中率做指标，编译两轮后发现模型学会了在答案里堆砌关键词，答案变得不可读。换成"关键词命中加 LLM judge 双条件"后，模型不得不既命中事实又保持语义通顺，产物质量才回到可用区间。教训与本章主旨完全一致：编译器忠实优化的不是你的意图，而是你的指标写出来的东西。

本节要点回顾

• 指挥棒原理：优化器在指标曲面上爬山，指标测错方向，编译就精确优化到你不关心的地方。
• 两种形态：规则函数便宜确定但只认字面，LLM judge 能评语义但要管理成本与漂移，裁判模型应与被评模型异源。
• 质检员身份：指标在自举期过滤轨迹，直接决定示范质量；trace 模式下可加验中间字段。
• 失真三联症状：分数涨业务不涨、产物话术异常、分数剧烈震荡；按"先规则后裁判、先窄后宽、先抽样后全量"修正。
• 通向下一章：指标就位后，编译器家族如何真正开动起来？第 4 章从环境与数据讲起，一路走到自举与联合搜索的实战现场。