Improve your prompts by hill-climbing with Evaluations
Other 高级 27m

通过爬山法评估优化你的提示词

Improve your prompts by hill-climbing with Evaluations

2026年6月10日

在 Apple 官方观看视频

一句话判断

这场 Session 最值得关注的一件事是：Apple 告诉你优化 AI 功能的第一步绝不是瞎改业务 Prompt，而是用统计学里的 Cohen’s kappa (科恩 kappa 系数) 去校准你的“模型裁判 (Model Judge)”。

这场 Session 讲了什么

做 App 里的 AI 功能（比如根据书评自动打标签），最怕的就是“感觉不对但不知道哪不对”。Apple 在之前的 Session 推出了 Evaluations framework (评估框架)，让你用 ModelJudgeEvaluator (模型判断评估器) 来给 AI 的输出打分。但这次他们戳破了一个幻觉：你的模型裁判本身可能就是个“糊涂蛋”。当数据集变大时，裁判的打分和人类专家的打分会出现 Drift (漂移/偏差)。

为了解决这个问题，Apple 把科学实验的思维搬进了 Xcode。他们引入了 Cohen’s kappa 来精准测量裁判和人类的一致性，排除了“瞎蒙也能蒙对”的概率。整个流程变成了严格的爬山法 (Hill-climbing)：先通过修改裁判的 Prompt 和 Few-shot (少样本提示) 把“尺子”校准，然后再用控制变量法去对比测试业务功能的 Prompt，甚至加入 Tool (工具调用) 来看效果。这对所有在 App 里深度集成 LLM 的开发者来说，是一套直接可以抄作业的工业化标准。

值得深挖的点

尺子不准，量什么都白搭 (Judge Alignment & Cohen’s kappa)

很多团队做 AI 评估，喜欢算个 Accuracy (准确率)，觉得裁判和人类打分一致的比例高就行。Apple 在这里极其敏锐地指出了这个坑：如果你的数据集里 80% 都是高质量输出，人类和模型都倾向于打高分，哪怕模型是在瞎猜，Accuracy 也会很高。这就是数据分布不均带来的假阳性。

Apple 直接搬出了 1960 年代的统计学神器 Cohen’s kappa。这个系数的精妙之处在于，它从 Accuracy 中减去了“随机一致性”的概率，然后进行归一化。只有当 kappa 值达标（比如 0.6 以上），你才能相信这把尺子是准的。这个设计选择非常硬核，它直接把 Prompt 工程从“凭感觉炼丹”拉升到了“严谨的科学实验”层面。在实战中，这意味着你不仅要写业务代码，还要专门写一个 BookTagJudgmentCalibration 这样的评估测试，用 Swift Testing 的 #expect 来断言你的裁判是否合格。如果尺子是歪的，你后续对业务 Prompt 的所有优化都是在做无用功。

控制变量法与 Trade-off 的可视化

当尺子校准后，Session 展示了如何用 Xcode 27 的新特性做 Comparative evaluation (对比评估)。这就像做 A/B 测试，左边是 Baseline (基线/对照组)，右边是 Experimental (实验组)。比如你在业务 Prompt 里加了 App 上下文，结果发现 Relevance (相关性) 上去了，但 Usefulness (有用性) 掉下来了。

这种 Trade-off (权衡) 在 LLM 开发中太常见了。Apple 提供的 Side-by-side (并排) 对比视图和 Assistant Editor (辅助编辑器)，让你能直接钻取到具体的样本（比如《科学怪人》的标签），看看模型到底在哪翻车了。这种“改一个变量 -> 跑评估 -> 看 Trade-off -> 决定取舍”的闭环，比单纯看一个干瘪的平均分有用得多。它强迫开发者去思考：为了提升 10% 的相关性，牺牲 5% 的有用性，在当前的业务场景下到底值不值？

代码片段

1. 定义带明确边界的 ScoreDimension (评分维度)

场景：告诉模型裁判什么是“好”，什么是“坏”，避免它把读者的情感当成书的标签。

let relevance = ScoreDimension(
    "Relevance",
    description: """
        标签是否描述了书本本身（类型、主题、基调），
        而不是读者的反应或对作者的元评论。
        书可以是“悬疑的”（文本属性），但读者不能是“疲惫的”（读者反应）。
        错误标记类型是严重的失败。
        """,
    scale: .numeric([
        4: "每个标签都描述了书本本身",
        3: "大多数标签描述了书本，有一个 picked up 了读者反应",
        // ... 其他分数定义
    ])
)

坑：描述越抽象，模型裁判的幻觉越严重。必须给出具体的反例（如“读者不能是疲惫的”）来划定边界。

2. 使用 Cohen’s kappa 进行自定义聚合

场景：在评估测试中，用统计学公式计算人类专家和模型裁判的真实对齐度。

func aggregateMetrics(using aggregator: inout MetricsAggregator) {
    // 提取人类专家的打分
    let expertRelevance = Self.samples.map { Double($0.expected?.expertRelevanceScore ?? 0) }
    
    aggregator.group("Relevance") { group in
        group.computeMean(of: relevance.metric)
        // 计算 Cohen's kappa，排除随机一致性
        group.custom(of: relevance.metric, label: "Relevance Alignment Score") { judge in
            cohensKappa(ratings1: expertRelevance, ratings2: judge) ?? 0
        }
    }
}

坑：如果数据集中某个分数（比如 4 分）出现频率极低，kappa 计算可能会返回 nil 或产生极端值，需要做好兜底处理并保证数据集的分布相对均匀。

3. 在 Judge Prompt 中加入 Few-shot (少样本) 校准

场景：光靠文字描述不够，直接给模型裁判看几个“人类专家是怎么打分的”具体例子。

ModelJudgeEvaluator(
    judge: SystemLanguageModel(),
    dimensions: [relevance, usefulness],
    prompt: ModelJudgePrompt(
        instructions: """
            你正在与一位专家图书管理员进行校准... 
            你的目标是匹配该管理员的打分方式。使用以下示例进行校准。

            ## 示例
            输入书评: "这本书让我熬了三个通宵，情节太紧凑了..."
            生成的标签: ["悬疑", "惊悚", "熬夜"]
            专家打分: Relevance: 3, Usefulness: 2
            专家理由: "熬夜"是读者的行为，不是书的属性，因此扣掉相关性分数。
            """
    )
)

坑：Few-shot 例子千万别给太多（Session 建议 deliberately few），否则模型裁判会过拟合 (overfit) 这几个例子，导致在没见过的数据上表现极差。

最佳实践

  • 已有项目的迁移策略：如果你已经在用 LLM 做功能，立刻停下来。先抽取 50-100 个历史真实数据，自己人工打分作为 Ground Truth (基准真相)。然后跑一遍现有的 Model Judge，算一下 Cohen’s kappa。如果低于 0.6，先别急着优化业务 Prompt，去改 Judge 的 Prompt 直到 kappa 达标。
  • 新项目的采用建议：把 Evaluation 当作 TDD (测试驱动开发) 的一部分。在写业务 Service 之前，先写 Evaluation。没有评估集的 AI 功能，就像没有单元测试的底层库，根本不敢发版。
  • 实战中容易踩的坑：不要试图用一个 Prompt 同时优化所有维度。Session 里展示了改了一个变量后，Relevance 上去了但 Usefulness 掉下来了。遇到这种情况，拆分成多个 Evaluator，或者在 Prompt 里明确各个维度的优先级。

还有什么值得关注

  • Tool 调用也能做对比评估：除了改 Prompt，Session 还演示了给模型加一个 BookLookupTool (书籍查询工具)，并通过评估对比了“有工具”和“无工具”的得分差异，这为 Agentic (智能体) 应用的评估打了样。
  • Xcode 的 Attachment (附件) 机制：评估运行后生成的 JSON 附件可以直接被下一个评估任务（如校准测试）复用，省去了手动导出导入数据的麻烦，让数据流转非常丝滑。
  • Drift (漂移) 监控：随着用户数据增多，原本校准好的 Judge 可能会再次发生 Drift。Apple 建议把 Judge Alignment 测试加入 CI/CD，定期监控 kappa 值的变化，防止尺子用久了变歪。
Evaluations Prompt Engineering Cohen's kappa Swift Testing LLM