📌 本文看点
01 Rubric 是什么，为什么总分不够用
02 工业级 Rubric 的四个核心要素
03 三个典型场景与工程落地方法
过去两年，强化学习在数学和代码生成任务上取得了显著进展。这类任务具有唯一的标准答案，可以通过代码测试或精确匹配给出 0 或 1 的奖励信号。
但在金融、法律、医疗等实际业务中，任务通常是开放式的，例如撰写并购风险分析报告、审查长文本合同或解读复杂的医疗图表。这类任务没有标准答案。
过去常用的方法是让大模型裁判直接给出一个 1 到 5 分的整体评价。这种做法导致模型在训练中倾向于生成排版规整、篇幅冗长但缺乏实质准确性的内容。
图：Length-Controlled AlpacaEval（arXiv:2404.04475）Figure 3。同一批模型在 concise / standard / verbose 三种输出长度下的胜率：左半是原始 AlpacaEval，右半是长度控制版。gpt4_1106_preview 在原始版里从 22.9%（concise）跳到 64.3%（verbose），做长度控制后压到 41.9%–51.6%。仅靠把回答写长，就能把裁判分数拉高一倍多
为了解决开放式任务中的评估与训练问题，业界开始采用 Rubric（评分细则），将模糊的整体评价拆解为多个独立的、可验证的检查项。本文将结合具体业务场景，说明 Rubric 的结构设计、业界实践以及工程落地方法。
01
什么是 Rubric？为什么需要它？
在解释 Rubric 之前，我们可以看一个日常例子。
假设我们让模型解释一个技术概念，如果只让评估模型给出一个总分，我们可能会得到“8 分”。这个分数信息量很低，我们无法知道模型是因为概念解释得好得分，还是因为排版清晰得分。
如果使用 Rubric，评估过程会被拆解为一组具体的检查项：
1. 是否准确说明了核心概念？（是/否）
2. 是否提供了至少两个具体示例？（是/否）
3. 是否说明了该技术的局限性？（是/否）
图：HealthBench（arXiv:2505.08775）Figure 6。把同一批模型的表现按五个行为维度拆开：Communication quality、Instruction following、Context awareness、Accuracy、Completeness。同一个模型在不同维度上的分数差异明显，一个总分会把这些差异抹平
Rubric 的本质，是将主观的整体评价转化为客观的、可机器执行的检查清单。
在强化学习中，这种拆解解决了两个问题：
1. 评估一致性：不同的评估模型或人类专家，在面对同一份输出时，基于明确的检查项能得出高度一致的结论。
2. 细粒度奖励：模型在生成内容的过程中，每完成一个正确的步骤都能获得相应的奖励信号，而不是只在最终输出正确时才获得奖励。
图：HealthBench（arXiv:2505.08775）Figure 12。按七个主题比较每位医师的 Macro F1（灰点）与模型评分器 GPT-4.1 的 Macro F1（红三角），横轴 0–1.0。红三角落在灰点分布之中，即模型评分器与医师的一致性接近医师彼此之间的一致性——「评估一致性」是能量出来的
02
一条工业级 Rubric 的四个核心要素
在实际业务中，设计 Rubric 并非简单地列出几个评估维度。以“商业合同审查 Agent”为例，一条合格的工业级 Rubric 需要包含以下四个要素：
图：HealthBench（arXiv:2505.08775）Figure 1，OpenAI 随发布放出的官方信息图。左为示例对话与候选回复，右为针对这条对话由医师撰写的 Rubric Criteria & Grades 表：每条 Criterion 单独给 Points 与 Present（是/否），可见 +7、+5 的正向分与 −5、−6 的负向分，底部再把逐条结果汇总成 Score。一条检查项、一个二元判定、一个权重，全在这张表里
1. 单一检查项（原子化）
一条规则只验证一个独立的事实或逻辑步骤。
错误示例
“检查模型是否准确提取了合同金额并判断了违约风险。”（包含两个动作，如果金额提取正确但风险判断错误，评估模型无法给出准确的二元结果）。
正确示例
“检查模型提取的合同总金额是否与原文第 3.1 节一致。”
2. 证据锚点（Evidence Anchor）
明确指定验证该检查项所需参考的具体输入文件或上下文段落。这可以防止评估模型依靠自身的预训练知识进行主观判断。
• 示例：“判断依据仅限于 input_files/合同草案_v2.pdf 的第 4 页至第 6 页。”
3. 二元判断与权重
检查项的输出通常为 True/False 或 Pass/Fail，并根据业务重要性分配权重。
• 示例：提取金额正确（+5 分），格式符合要求（+2 分）。
4. 负向惩罚与一票否决（Hard-stop）
针对严重的合规风险或事实错误，设置高权重的负向惩罚。
• 示例：“如果模型在输出中包含了输入文件中未提及的虚构条款，直接扣除 20 分，并标记该任务为失败。”
03
业界在三个典型场景中的 Rubric 实践
以下是业界在解决特定业务痛点时，应用 Rubric 的三种典型模式。
图：HealthBench 论文、 5,000 组多轮对话、262 名医师撰写、48,562 条独立 rubric criteria，是「用检查清单给开放式回答打分」的公开实例
场景一：多模态图表分析（解决“幻觉”问题）
业务痛点 在分析复杂的科研或财务图表时，模型经常会编造图表中不存在的数据，或者计算过程正确但读取的初始数值错误。
Rubric 设计 将评估拆分为三个具有依赖关系的检查项：
1. 视觉提取：模型提取的 2024 年峰值数值是否与图表 Y 轴刻度一致？
2. 逻辑推理：模型计算的增长率是否基于其提取的峰值数值正确计算得出？
3. 指令遵循：输出是否严格采用了要求的三点列表格式？
效果 通过这种拆解，如果模型在第一步读取数值错误，后续的推理步骤即使逻辑正确也不会获得奖励，从而强制模型提高视觉提取的准确性。
图：ALE（arXiv:2606.05405）对 1,490 个专家任务实例的失败归因。外圈是具体失败模式：领域知识缺失 25%、策略选择错误 30%、产出不完整 17%、格式错误 10%、实现缺陷 8%、幻觉 6%、GUI 操作失败 4%；内圈是三层归因：理解层 31%、方法层 47%、执行层 22%。开放式长任务的失败分布在多个环节，靠一个总分定位不到具体环节
场景二：深度信息检索（解决“编造引用”问题）
业务痛点 模型在撰写长篇研究报告时，为了使内容看起来可信，会生成不存在的网页链接或学术文献。
Rubric 设计 引入“引用感知”机制。要求模型在满足每一条内容检查项（如“说明了某项政策的最新变化”）时，必须在输出中提供对应的真实网页引用来源。
效果 评估系统会核查引用的真实性。没有真实引用支撑的结论，即使内容看似合理，也无法通过该检查项。
场景三：法律与金融长文本（解决“遗漏关键风险”问题）
业务痛点 在审查包含数十个条款的并购合同时，模型找出了 10 个风险中的 8 个。在传统的百分比评分中，模型可以获得 80 分的高分，但漏掉的 2 个风险可能导致严重的商业损失。
Rubric 设计 采用“全过才算过（All-Pass）”的聚合机制。一份报告只有在所有关键风险检查项（如“控制权变更条款”、“排他性条款”）都返回 True 时，该任务才算完成。
效果 这种机制符合高风险行业的实际业务逻辑，即遗漏关键风险等同于任务失败，消除了模型通过堆砌次要信息来获取高分的可能。
图：AutomationBench（arXiv:2604.18934）的判分流水线：任务提示 → AI Agent（搜索工具发现 API、执工具调用 API）→ 模拟应用状态作为事实来源 → 确定性断言 → 通过/失败 + 成本。底部蓝框是关键：正向检查「必须达成的状态」+ 反向检查「绝不能出现的状态」，两类断言同时成立才判通过，对应本文的 All-Pass 聚合
04
落地实践：如何将 Rubric 接入训练与评测流程
在 DataMining 的工程交付中，我们将 Rubric 与执行环境封装为标准化的交付包。为了确保评估的确定性，需要遵循以下工程规范：
1. 隔离的执行环境：将业务相关的输入文档（如合同、财务报表）封装在独立的 input_files/ 目录中。
2. 物理隔离的评分器：评分逻辑（Verifier）与模型的运行环境物理隔离。模型无法读取测试脚本，也无法通过修改环境状态来影响评分结果。
图：DeepSWE 与 SWE-Bench Pro 的验证器误差对比。上：假阳性率（验证器放行、人工判定为错），DeepSWE 0.3% vs SWE-Bench Pro 8.5%。下：假阴性率（验证器拒绝、人工判定为对），DeepSWE 1.1% vs SWE-Bench Pro 24.0%。评分器自己也会判错，所以判分口径必须写得可复核
3. 结构化的交付物：一个标准的任务包包含：
• instruction.md：给模型的任务说明。
• input_files/：业务上下文数据。
• rubric.json：包含所有检查项、证据锚点和权重的配置文件。
• oracle/：人类专家提供的标准参考解，用于验证 Rubric 的合理性。
图：我们交付的一道真实医疗专家任务包结构（任务号 medical-20261015task001，已去标识）：input_files/ 放 5 份模型可读输入材料，其中附件3 明确标注为干扰文件；solution/ 放 4 份专家参考交付物，含「专家解题思路与证据索引」
图：我们交付的一道法律专家任务包（破产重整·上市公司公告案）：input_files/ 放 33 份模型可读输入材料，solution/ 放 2 份专家参考交付物。业务上下文与评分配置分开封装，是「证据锚点」能落地的前提
05
团队自查清单
如果你的团队正在为开放式任务设计评估标准或训练奖励，可以参考以下清单检查当前的工程水位：
| 检查维度 | 现状自查项 | 不达标的表现 | | --- | --- | --- | | 规则设计 | 单条规则是否只验证一个独立事实？ | 规则中包含“且”、“或”等复合逻辑，导致评估结果模糊。 | | 证据依赖 | 评估是否强制依赖提供的输入文件？ | 评估模型依靠自身的预训练知识判断对错，导致“幻觉奖励”。 | | 风险覆盖 | 是否针对严重错误设置了负向惩罚？ | 只有加分项，模型可以通过生成冗长但无用的内容获取基础分。 | | 环境隔离 | 评分脚本是否对模型不可见？ | 模型可以读取测试脚本，从而针对性地生成符合测试正则表达式的输出。 | | 聚合逻辑 | 关键业务指标是否采用了“一票否决”？ | 采用简单的平均分，导致模型遗漏关键风险仍能获得及格分。 |
06
总结
大模型后训练正在从依赖单一标量奖励的阶段，过渡到基于结构化 Rubric 的细粒度优化阶段。通过将复杂的业务逻辑分解为可执行的检查项，并结合隔离的验证环境，强化学习得以在缺乏标准答案的开放式任务中获取稳定的梯度信号。
这是提升大模型在垂直行业实际应用能力的基础工程。
END
