如何通过人工审核改进黄金数据集

2026年5月21日 Ornella Altunyan 9分钟

在构建评估工作流时，很容易忘记人类专业知识是最重要的输入之一。如果你没有对AI产品的"好"标准进行某种验证，就无法判断你构建的质量是提升了还是退步了，因为你没有权威的参照物来对比输出结果。

识别这些信息并将其整合到评估工作流中，通常需要领域知识、政策专业知识和客户期望，而这些是prompt、启发式规则或模型置信度无法完全捕捉的。这正是人工审核发挥作用的地方。

将人工审核加入评估生命周期

将人工审核加入评估流程的目标，是将你的生产trace转化为随时间更新的黄金数据集，并帮助你在数据变化时调整评分器。流程大致如下。

借助人工审核，这个流程可以帮助你构建一个可在CI中运行的数据集、一个可随时间监控的仪表板，以及一个持续将新的边缘案例反馈回数据集的队列。

在任何真实的生产规模下，你都无法通过自己浏览每条trace来完成标注步骤。trace需要先按失败模式、意图、情感等进行分类，这样审核者才能关注模式而非单个事件。Topics 可以自动完成这项工作，将生产trace聚类到命名类别中，并将这些分类作为可SQL查询的标签持久化到每条trace上。然后人工审核在此基础上叠加，运用专业知识确认Topics发现的每个模式上的正确输出。

expected 及其重要性

expected 值是你指定"正确"答案的方式，该答案反映了你所使用的模型或构建的AI产品之外的人类专业知识。知道模型应该产生的输出，可以让你在获得更多生产数据时改进评分器。

在编写 expected 值时，你需要：

• 包含模型应产生的完整响应，或你希望返回的具体值。
• 确保格式、语气、schema、引用和安全行为与应用在生产环境中的期望一致。
• 使用确定性目标，例如"返回包含键X/Y/Z的JSON"，这比"一个有用的答案"更容易评分。
• 如果单条trace涉及多种行为，考虑将其拆分为多个数据集行，使每行都有一个清晰的 expected。

保持 expected 的简洁很重要。任何支持性细节或源材料都应存储在metadata或reference字段中，而不是 expected 本身。证明 expected 值正确所需的上下文也是如此。这可以使 expected 在不同审核者之间具有可比性，并使评分信号更清晰。

人工审核工作流：trace、数据集、expected

将人工审核应用于评估流程的工作流应遵循一个模式：获取trace，将其放入数据集，然后根据人工审核的 expected 值进行测试。

首先，人工审核者选择一个"糟糕"或"有趣"的trace进行深入分析。大多数情况下，这会是显著的失败、边缘案例或Topics集群中的代表性示例。然后审核者将该trace复制到目标数据集中。这可以是现有的黄金数据集、回归测试套件或类似的东西。最后，审核者根据其主题专业知识、过往经验或对业务事实的了解，填写 expected 值。本质上，这就是模型本应产生的答案。

对人工审核者的质量要求应该很高。如果你无法自信地从现有来源写出 expected，最好咨询其他主题专家，而不是猜测。如果存在多个可能"正确"的输出，或者事实足够复杂以至于需要不同的正确输出，你可能需要缩小任务范围使其更具体，或者在评分器中编码可接受的差异，例如基于rubric的评判器。

在Braintrust中添加人工审核

要在Braintrust中开始配置人工审核，你需要在项目级别定义一个清晰的rubric。在你的Braintrust 项目中，进入设置，然后选择人工审核，并定义你想要捕获的审核分数。

选择与你所需判断相匹配的字段类型：

• 通过/失败：用于最快的决策和最清晰的指标（例如 is_correct、needs_fix）。
• 分类字段：当你想要一致的分类法时（例如 failure_type = hallucination | retrieval_miss | tool_misuse | policy | formatting）。
• 连续滑块：用于主观维度（例如 helpfulness、tone 或 groundedness，采用1到5的等级）。
• 自由文本字段：用于 notes 或理由。

最好先保持rubric简短，只有在审核者之间达成一致后才进行扩展，因为长的rubric会降低吞吐量并增加不一致性。为了使rubric在实践中可用，在字段描述中直接添加简短的定义和示例（"好"和"坏"的样子），并确保每个字段映射到一个操作。例如，needs_fix 应驱动分类和所有权，failure_type 应映射到行动手册或负责团队。

一旦rubric就位，使用审核队列和分配将trace路由到正确的主题专家。当你从日志/Trace中标记span或日志进行审核时，你可以直接将它们分配给特定的审核者，或者将它们留在共享队列中未分配。Topics标签是路由的有用过滤器，因为你可以将所有带有特定失败模式或任务类别标签的trace发送给负责该领域的团队。这种队列结构让你能保持清晰的运营节奏。

一个快速决定"忽略 vs. 需要审核 vs. 重复"的分类队列将帮助你快速处理关键问题。当Topics就位时，这个分类步骤通常变成确认或细化Topics已应用的标签，而不是从零开始。一个填充 expected 和 is_correct 等事实字段的SME队列将确保严格应用真实世界的专业知识。一个校准队列让多个审核者定期对相同项目进行评分，以保持rubric的一致性。

在trace通过这些队列进行初步审核后，将人工审核分数视为策展的主要杠杆。你可以按Topics标签和人工审核分数过滤已审核的日志，找到你想要"提升"到数据集中的示例。从过滤后的集合中，将这些"提升"的trace或span添加到持久测试用例的黄金数据集中。提升后，在更改后针对此数据集运行实验，持续添加新的失败案例，定期修剪重复和过时的案例，并逐步将重复出现的人工审核模式转化为自动化评分器，这样人工精力就能集中在模糊和新颖的案例上。

Braintrust还支持自定义trace视图，用于捕获不适合 expected 值的审核者判断。自定义trace视图是可嵌入的React组件，可将原始trace重新渲染为特定于角色的审核界面。审核者无需浏览嵌套的span和原始JSON，而是可以看到与其工作流相关的输入、输出、工具调用、检索到的上下文和业务元数据。

将自定义trace视图与人工审核配对，可以让你暴露结构化rubric无法表达的标注功能。审核者可以直接从界面应用修正、标签和注释，这些注释会写回span元数据，作为可查询的信号，用于过滤日志、策展数据集、触发在线评分器和回归测试。团队通常会为不同的审核者角色构建不同的界面，这样每个组只能看到有效评估trace所需的上下文。

随时间改进评分器

一旦你设置了人工审核并获得了足够多满足 expected 值的结果，你就可以将这种人工审核的事实转化为可扩展的自动化评估。

对于客观检查，这通常从启发式评分器（精确匹配、正则表达式、差异和schema验证）开始，这些评分器可以低成本、确定性地捕获明显的回归。对于更主观的维度，你可以引入LLM-as-judge评分器，它们遵循审核者使用的相同rubric语言。随着时间的推移，跟踪评判器与人类的一致性并在它们偏离时校准prompt或阈值变得特别有价值，这将有助于在你的产品和数据演变时保持自动化评分的诚实。

随着数据集因真实标注的失败案例而增长，你的评分器变得更有意义，回归也更容易捕获。经过审核的生产失败案例成为测试用例，评分器将这些用例转化为指标，实验和CI运行告诉你更改是改进了还是破坏了某些东西。

随着时间的推移，人工审核从主要的评估机制转变为高质量训练信号的来源，这些信号应用于由现有评估工作流自动生成的数据集和评分器。

避免这些反模式

尽管人工审核最终会转向事后质量控制，但你仍需保持警惕，避免可能破坏飞轮的反模式。

最常见的反模式是将trace复制到数据集中，但将 expected 留空。在这种情况下，你保存了一个示例，但没有提供清晰的真实情况来对照检查，因此该行无法作为可靠的回归测试，数据集也不会随着时间的推移增强你的评分信号。

另一个问题是将参考材料、上下文或理由直接混入 expected 中。这使得 expected 在不同审核者和不同时间之间难以比较，并且通常会导致评分嘈杂，因为两个"正确"的输出可能仅在额外的解释内容上有所不同。保持 expected 作为清晰的目标输出，并将支持材料放在metadata或单独的notes字段中。

最后，避免推迟审核工作流的设计。如果你等到"以后"再定义rubric、所有权和审核节奏，你会积累大量有趣的trace，但不会有一致的标注流程将它们转化为可操作的测试用例和评分器改进。