CS329Z中文学习站
首页 / 第6周 · 数据

LLM 应用的数据飞轮

Data Flywheels for LLM Applications

Shreya Shankar · "个人博客 (shreyashankar.com) · UC Berkeley · 2024-07-01"

必读全文中译查看原文(HTML) ↗

导读

本文是第 6 周"数据"一讲的核心阅读材料。作者 Shreya Shankar（UC Berkeley 博士，其"Who Validates the Validators"系列研究正是本周另一篇论文）在这篇 2024 年 7 月的博文中，系统回答了一个工程问题：如何用生产环境数据自动、持续地改进 LLM 应用——也就是构建"数据飞轮（Data Flywheel）"。

文章的重要性在于：它把此前散落在评估（evaluation）、LLMOps、提示工程等话题里的实践，收敛成一个可落地的三段式闭环框架——(1) 评估：定义成功指标，包括代码指标与 LLM-as-a-judge，并强调二值指标、输入验证与多步流水线中不同节点类型（分类器/生成器/代码生成器）需要不同的验证方式；(2) 监控：让指标集与指标实现随生产数据漂移而演进，用动态少样本（dynamic few-shot）保持裁判与人对齐；(3) 持续改进：主动学习式地修复低分轨迹，再把修复后的样本检索回提示作为示例。文末还提出三个开放研究方向（不确定性量化、LLM 调用图的图感知飞轮、数据库内建验证）。这与本课程"评估"一周的内容直接衔接：飞轮能否转起来，取决于指标定义与人对齐的质量。

全文中译

《LLM 应用的数据飞轮》

作者：Shreya Shankar · 发布于 2024 年 7 月 1 日 · 约 20 分钟阅读

引言

过去几个月，我一直在大量思考如何利用生产数据自动且动态地改进 LLM 应用的工作流。这源于我们关于在 LLM 流水线与应用中验证数据质量的研究——这些研究已经开始在垂直 AI 应用和 LLMOps 公司中走向生产化。（我始终非常感谢业界那些认为我的工作有用、并乐于合作的团队。）

我关于数据飞轮的想法建立在几个观察之上：

  • 人类需要定期参与评估环节，因为人类对 LLM 输出的偏好会随时间变化。
  • 微调模型伴随着可观的开销，许多团队更愿意使用 LLM API，以便快速迭代和简单部署。而 LLM API 并不总是听从提示中的指令，尤其是在大批量输入上，因此需要对 LLM 输出设置验证器（validator）。
  • LLM-as-a-judge（LLM 作为裁判）正日益流行。LLM 变得越来越便宜、越来越好、越来越快。
  • 实证证据表明，少样本示例（few-shot examples）是改进提示效果最有效的手段。因此，只要给出合适的少样本示例，LLM 裁判是可以与人类偏好对齐的。

在这篇文章中，我将概述解决这个问题的三部分框架。在深入每部分细节之前，先看一眼整个 LLM 应用流水线的总览：

图 1：持续演化的 LLM 应用流水线，改编自论文中的图 1。

这张图展示了我（理想化）的 LLM 流水线架构，从输入处理一直到评估与日志记录。它涵盖了本文将讨论的诸多想法，例如输入验证、动态少样本示例检索，以及同时使用基于代码和基于 LLM 的评估指标。

现在，让我们把这个过程拆解为几个主要部分：评估（Evaluation）、监控（Monitoring）和持续改进（Continual Improvement）。

构建飞轮的框架

1. 评估：定义成功指标

有不少专门讲评估的优秀资料。我特别喜欢我朋友 Hamel 写的一篇，里面有关于评估什么指标、用什么工具的具体例子。我将聚焦于指标流程的更高层概览：首先，为成功建立清晰的标准；然后，为这些指标找到合适的实现。这个过程比乍看之下更微妙：

a) 找出对你的具体用例真正重要的指标。

对一个客服聊天机器人，你可能关心"回复简洁度"或"共情分数"。但必须注意，你不能仅凭空想任务可能的失败模式来确定有效的标准。你需要审视真实数据——大量的 LLM 输出——才能对你这个具体任务想验证哪些标准获得真实的感知。

看数据之所以必要，是因为某些指标对应的是 LLM 的怪癖，甚至是你这个任务特有的怪癖。例如，你可能注意到"delve"、"crucial"这类词常带有一股你想避免的"GPT 味"。这时你就可以实现一个检查这类词是否缺席的指标。这类洞见只能来自对真实输出的仔细检视。

一旦确定了适合用例的指标，下一步就是有效地实现它们：

b) 实现这些指标。

如图 1 中"二值指标"部分所示，我们可以同时使用基于代码的指标和基于 LLM 的指标（通过提示）来做评估：

  • 简单的代码函数来评估启发式规则：例如用字符计数衡量简洁度。
  • "LLM-as-a-judge"：查询一个 LLM 来评估你定义的某个特定指标。这种方式对更主观或更复杂的标准特别有用。

使用 LLM 裁判时，让裁判的输出与你自己的判断对齐可能很有挑战性，尤其是对定制的、 bespoke（专为客户定制）的任务。在裁判的提示中提供一些你认为好和坏的 LLM 输出示例（针对你的指标），可以显著改善对齐。

值得注意的是，二值指标（真/假）从用户体验角度要容易对齐和推理得多。很多人条件反射地使用李克特量表（Likert scale）或更细粒度的指标给 LLM 裁判打分，但从简单开始往往更好。二值指标更容易对齐（只需就什么算真、什么算假达成一致），人类也更容易稳定地判断，这对长期维持评估数据的质量很重要。

c) 验证多步流水线（即 LLM 调用的"图"）。

在由相互连接的 LLM 调用"图"组成的复杂 LLM 应用中，我们可以把验证器看作软件可观测性中的探针（probe）。正如探针被策略性地放置以监控软件行为，验证器也应被安置在 LLM 图中，以评估中间输出与最终输出的质量和正确性。对 LLM 图中的每一类节点，我们希望用不同方式探测其行为。我的朋友 Han 提出过让我深有共鸣的三种节点类型。我觉得他的分类很有洞见，并决定结合我在一线的观察加以扩展：

图 2：客服聊天机器人流水线中的 LLM 节点。菱形节点代表分类器，六边形节点代表代码生成（codegen）节点，矩形节点代表 LLM 写作（writer）节点。为清晰起见，此图省略了工具使用（例如对数据库执行生成的 SQL 语句；在知识库中查找键以找到可能回答用户查询的文档）。

LLM 作为分类器（LLM as Classifiers）（状态转移节点；图 2 中的菱形节点）：

  • 示例：在一个较复杂的客服聊天机器人中，状态转移节点可以用 LLM 对用户意图分类（如"账单问题"、"技术支持"、"一般咨询"），并根据预测的意图把对话路由到相应子图。
  • 重点评估决策的正确性——使用准确率（accuracy）、精确率（precision）、召回率（recall）和 F1 分数等指标。
  • 应用基于规则的验证（例如，如果用户提到"bill"或"payment"，预期意图就应是"账单问题"；如果 LLM 预测的意图与预期不符，就把该对话标记给人工审查，并可能更新少样本示例和训练数据）。

LLM 作为写作者（LLM as Writers）（生成节点；图 2 中的矩形节点）：

  • 这类指标将是最 bespoke 的，因为它们高度依赖用户和任务。
  • 例如，评估生成内容的质量、连贯性和得体性。也可以用困惑度（perplexity）、多样性、对任务特定约束的遵守等指标——取决于它们对业务的可行动性（actionable）程度。
  • 在客服聊天机器人的例子中，可以编写一个基于 LLM 的验证器，检查输出是否遵守品牌语气与声音指南（基于公司品牌示例）。

LLM 作为编译器/代码生成器（LLM as Compilers/Code Generators）（代码生成节点；图 2 中的六边形节点）：

  • 示例：在客服聊天机器人中，LLM 代码生成节点可以根据用户意图和上下文生成 SQL 查询，从知识库中检索相关信息。
  • 使用静态代码分析、linter 和测试套件来验证生成的代码。
  • 在适用时采用动态分析技术，例如在 text-to-SQL 流水线中把生成的 SQL 语句自动对数据库执行并验证输出。
  • 还可以用基于 LLM 的验证器判断输出是否合理地回答了用户的查询。

在 LLM 调用图的每个节点都实现验证器时，验证器很容易变得很多，而且哪些最关键并不总是清楚。通过给验证器的输出打标签并计算每一步的准确率，你可以追踪错误如何在流水线中逐级复合，从而为针对性改进提供宝贵洞见。我认为，验证多步 LLM 流水线的完备方案仍是一个开放研究问题，稍后我会再谈。

d) 输入与输出都要验证。

图 1 左侧所示的输入验证，确保只有合适的查询会被 LLM 处理。尽管大多数文献聚焦于验证 LLM 的输出，但验证输入数据对构建稳健的 LLM 应用同样重要。这能确保你的流水线只处理它为之设计的输入，拒绝或标记分布外（out-of-distribution）的输入。

虽然数据验证在传统机器学习中已有充分研究，但把这些技术适配到带自由文本输入的定制 LLM 流水线，往往需要同样定制的验证方法，外加通用验证（如语言检测）。

我在这一点上的总体哲学与 Brendan Dolan-Gavitt 一致，他说：

"最好的设计原则似乎是 Postel 法则：对发给 LLM 的内容要严格，对可接受的合法响应要宽容。"

我们用客服聊天机器人的例子来说明一些输入验证指标：

用户身份认证（User Authentication）

  • 指标：查询只涉及已认证客户自己的数据
  • 实现：将查询中提到的实体（如订单号、账户详情）与你数据库中该客户的记录进行比对

主题相关性（Topic Relevance）

  • 指标：查询与预定义的支持主题相关
  • 实现：a) 关键词匹配：检查查询中是否出现与你的支持领域相关的关键词；b) 语义相似度：计算查询嵌入与你支持文档集嵌入之间的余弦相似度，设定最低阈值（如 0.7）

查询复杂度（Query Complexity）

  • 指标：查询的长度和结构落在预期范围内
  • 实现：为 token 数、句子数、特定句法结构的存在设定可接受范围

语言检测（Language Detection）

  • 指标：查询是受支持的语言（如英语）
  • 实现：使用语言检测库确保查询属于你支持的语言之一

敏感信息检测（Sensitive Information Detection）

  • 指标：查询不包含意外的敏感信息
  • 实现：用正则模式或命名实体识别标记潜在敏感数据（如信用卡号、社会安全号码）

对抗性输入检测（Adversarial Input Detection）

  • 指标：查询没有试图操纵系统
  • 实现：检查已知的对抗模式，如反复尝试访问其他用户的数据，或提示注入（prompt injection）尝试

异常检测（Anomaly Detection）

  • 指标：查询与近期查询相似
  • 实现：将查询的嵌入与近期查询的嵌入比较。若相似度低于阈值，则标记给人工审查

也可以用基于 LLM 的验证器来验证输入——这同样引出如何让 LLM 与人类判断对齐的问题。我将在下一小节讨论。

2. 监控：让指标实现运转起来

一旦定义了指标，下一个挑战是确保它们跟得上生产数据。鉴于 LLM 应用的动态特性，这个过程应当尽可能自动化。

a) 自动重估所选指标是否仍与目标对齐。

上一节得出的指标集不是一成不变的。部署应用后，你会了解到新的失败模式，可能需要更新指标集。此外，LLM API 在底层不断变化，你理想的系统行为也会随时间演进。

半自动化指标集演进的一个思路，是部署一个 LLM "Agent"，定期分析一批带标签的生产数据样本，判断指标集是否需要更新。这个 Agent 可以：

  • 提出新指标（例如，如果客户持续不喜欢某些措辞）
  • 建议修改指标定义（例如，意识到"简洁"比单纯的字符计数更主观）
  • 建议删除与关键绩效指标（如准确率或点击率）不相关的指标

在提示中，这个 LLM Agent 只需要生产数据样本和当前指标集。虽然这个 LLM Agent 可以定期自动运行，但在实施前由 AI 工程师实际审核新的指标集，大概是重要的。[注 1]

虽然 LLM Agent 能帮助指标集随时间演进，同样重要的是确保指标实现也在演进。

b) 保持指标实现与评估标准对齐。

随着生产数据随时间漂移，对齐情况必须不断重估。这对基于 LLM 的指标评估器尤为重要。一个更详细的工作流可能如下：

  • 对每个指标，定期从生产数据中采样并标注一批响应。
  • 把这些带标签示例存入数据库，最好带有时间戳以便追踪新旧。我知道有些人还会为标签示例建立基于嵌入的索引。
  • 对基于代码的指标实现，安排定期人工审查，确保代码在最新数据下仍抓住指标的本质。
  • 对基于 LLM 的评估，保持验证器提示的动态性：
  • 从数据库中检索与当前待验证实例相关的示例。图 1 中高亮的动态少样本示例，就是基于输入相似度检索的。
  • 考虑一种受主动学习（active learning）启发的做法：优先检索"人类标签与 LLM 预测不一致"的示例。这有助于聚焦边缘案例和潜在失配区域。我知道有两个人在这样做（相比均匀随机采样能带来多少提升，还有待观察。）
  • 按标签的新近度对相似度分数加权。较新的生产数据被选为少样本示例的概率应高于较旧的数据。这个新近度加权的具体想法请谨慎对待——我目前不知道有谁在这样做，但它看起来很重要。（有意思的是，我知道有一个人检索最近的少样本示例时完全不看语义相似度——主要因为数据量太小，语义相似度可能帮不上忙。）

这个流程中的一个重大挑战，是确保每个指标都有定期的人工标注。这很重要，但负担不小。LangChain 正在探索一种有意思的做法：默认用 LLM 给数据打标签，人类可以随意修改这些标签。这确实减轻了标注负担，但 LLM 标注者随时间推移能否与人类判断保持对齐尚不清楚——尤其是当工程师或团队成员犯懒、不想去核对标签时。不过，即便不完美，这个做法也能保证少样本示例持续不断地来自新鲜、相关的样本[注 2]，这本身就很有价值。

3. 持续改进：闭合回路

有了稳健的评估与监控，重心就转向系统性地改进你的应用。这个过程既包含（人工的）人类洞见，也包含基于真实使用情况的自动化改进技术。如图 1 中"日志（Logs）"组件所示，这里的前提是维护一份完整的输出及其对应指标分数的日志；许多 LLMOps 工具（如 LangSmith）都能帮上忙。

a) 手动迭代提示或流水线，以提升已定义指标上的表现。

关键在于利用评估与监控过程中获得的洞见。有了定义良好的指标和持续演进的实现，你就能识别哪些生产轨迹（trace）表现好、哪些不好，并从错误中学习以改进提示或其他应用组件。

可以考虑的一些策略：

  • 定期审查生产数据上指标分数的分布，寻找低分实例的模式或聚类。
  • 对输入或查询数据分布做分析，观察用户行为的模式与变化。
  • 尝试对不同的提示结构或流水线配置做 A/B 测试，用实验确定哪些在你的指标上表现更好。

b) 响应指标自动改进流水线。

虽然上述人工分析很有价值，但把改进过程的某些环节自动化可能会提升效率。以下是我设想的一种基础改进策略：

  • 定期审查并"修复"低分输出。可以按天或按周的节奏进行，取决于应用的规模和资源。这个"修复"过程包括：
  • 找出原始输出错在哪里；
  • 重写输出使其正确；
  • 记录所做的修改及理由（供团队其他成员学习）。
  • 实施受主动学习启发的持续改进：
  • 维护一个生产轨迹数据库，连同其指标分数和任何人工提供的修复。
  • 对低分轨迹，优先安排人工审查和修复。
  • 在应用运行时的 LLM 推理中，检索与当前查询最相似的"已修复"轨迹，并作为少样本示例放进提示。[注 3]

你可以尝试不同的检索策略，例如：

  • 同时纳入最相似的轨迹（不论其分数高低或是否被修复过）和最相似的已修复轨迹
  • 按新近度加权检索，偏向更新的示例
  • 引入多样性度量，确保少样本示例覆盖多种类型

值得注意的是，把"好"输出分解为多个维度，而不是让人类对轨迹做整体打标签，有几个关键好处：

  • 把质量拆解为具体指标，能让人类标注更准确、更一致。标注者不必做一次性的高层判断，而是聚焦于定义明确的方面（如简洁度、礼貌度）。这种粒度促进对齐、减少主观性。
  • 当 LLM 验证器一次只需检查一个指标时，对齐它们变得更容易。试图一口气捕捉"好"的完整概念很难，而验证单个维度则更可行。
  • 每个指标都有分数，能提供对表现更细致的视图。如果大多数输出因某个特定指标而失败，它就直接指出了需要改进的地方。

所以，无论如何都需要人类标注，但使用多个指标能为持续改进过程带来严谨性、一致性和可行动的洞见。它让我们能更系统、更有效地随时间精炼 LLM 应用。

LLM 应用：一组新挑战

我概述的框架为构建自我改进的 LLM 应用提供了坚实基础。然而，随着我们不断突破这些系统的能力边界，新的挑战也随之出现。以下是我在 LLMOps 生命周期中一直在思考的几个问题，更多是从研究视角出发：

LLM 不确定性量化在校准验证器上的应用

一个关键挑战是 LLM API 的不确定性量化（uncertainty quantification），尤其是面对定制任务时。主动学习是改进 ML 模型的强大工具，但在 LLM API 上变得困难，因为我们缺乏有意义的概率估计。指令微调模型的下一个 token 概率是无标定（uncalibrated）的，在规模化的输出分析中帮不上忙。一些 ML 论文探索让 LLM 在输出后直接给出置信度分数，但效果也不太好。当然，直接的解法是微调 LLM 而非使用 API，但这背离了前提——LLM API 的简单性。

稳健的不确定性估计可以显著增强我们校准指标实现、采样信息量大的少样本示例、以及为人工标注排优先级的能力。虽然这是开放研究问题，但该领域的进展可以直接强化框架中的评估与持续改进部分。

面向 LLM 调用"图"的数据飞轮

随着 LLM 应用复杂度增长，我们常要处理相互连接的 LLM 调用网络或"图"，表示多步推理过程。有些应用甚至把 LLM 放进循环里！为这类系统实施数据飞轮带来独特挑战：

  • 一个节点的错误会在后续节点中放大，需要尽早检测和纠正。
  • 我们需要同时评估中间和最终输出的质量。这靠人工逐个评分可能太多。
  • 图是动态的：基于 LLM 的图可能根据输入或中间结果改变结构，使评估和改进过程复杂化。

应对这些挑战的关键研究方向包括：

a) 实现图感知（graph-aware）的评估指标意味着什么？我们是否采用某种分层验证——先验证单个 LLM 调用或节点，再验证游走路径（walk）或子图（subgraph），最后验证整张图？这些验证探针对不同类型节点大概应该不同，但类型有哪些、验证应如何差异化？

b) 我们如何设计能在图的关键节点动态插入验证探针的系统？这条路线可能需要开发基于历史表现数据或不确定性度量——或因果分析技术——来识别高风险节点或转移的算法。理想情况下，我们能在错误传播到整个系统之前尽早捕获并纠正。

c) 我们能否把动态少样本学习的概念扩展到图结构？这可能涉及开发基于当前图配置和任务检索相关子图轨迹的技术。我们可以探索用图感知嵌入或子图匹配算法在历史数据中寻找相似模式。

数据库驱动的 LLM 流水线验证

我很好奇能否把验证器直接集成进数据库系统。目前，应用开发者要为所有轨迹实现日志和验证，工作量很大。实时地、甚至在应用后台完成少样本检索、确保所有验证器（尤其是 LLM 驱动的验证器）成功执行、把结果写回数据库等，都很困难——尤其是这可能需要大量计算资源或很长时间。理想情况下，数据库能替我们做这些事。

我一直在思考的关键问题包括：

a) 把验证器实现为数据库触发器（trigger）或存储过程：这样新数据插入或更新时，基于代码和基于 LLM 的验证器都能自动执行。我们如何设计这些触发器使其高效、且不明显拖累数据库性能？

b) 用数据库视图（view）做灵活的指标计算：把指标实现为视图而非全部现算（用 LLM 评估指标时开销可能很大），可以节省资源。对不同类型的指标，按需计算与物化视图（materialized view）之间如何权衡？

c) 日志语义索引的增量维护：为高效检索少样本示例，我们需要为 LLM 流水线轨迹维护最新的语义相似度索引。有没有简单的增量更新策略，能无需全量重建就保持索引最新？

结语

构建自我改进的 LLM 应用，就是要采用系统化的方法，聚焦对你的用例真正重要的东西，并基于真实世界的表现持续迭代。我概述的框架有意保持简单：它不依赖复杂的工具、ML 平台或企业级监控系统，而是强调深思熟虑的指标选择、持续的监控，以及数据驱动的改进。

说到底，人们（包括我自己）在所有生产数据都被最大化地用于未来流水线运行之前，是不会满意的——而这个希望保持简单的做法，朝着"把每一条生产轨迹都变成精炼与增强的机会"迈出了一大步。当然，仍有工作与研究要做——例如 LLM-as-a-judge 并不完美，LLM 应用可能相当复杂，或许需要不同的验证技术。

把视野拉远一点——我认为现在正是构建智能软件应用的激动人心的时代。自我改进的应用现在真的可以构建出来，而且还有许多问题等待回答。但最让我兴奋的是，前进的道路将是协作性的、跨学科的——把业界从业者、研究人员以及计算机科学各领域和子领域的专家凝聚在一起——共同规划智能软件工程的未来。

感谢我的朋友 Han Lee 对本文早期草稿的宝贵反馈与洞见。也感谢我的导师 Aditya Parameswaran 建议我就我们最近的 LLMOps 研究写一篇详细博文，感谢我的同事 Parth Asawa 启发了围绕数据飞轮概念的叙事。

如果你有兴趣参与这些研究项目中的任何一个，欢迎通过 shreyashankar@berkeley.edu 联系我。请附上你的简历，注明你感兴趣的项目，以及你可能有的初步想法。

脚注

注 1：虽然我还没见过哪个 Agent 完全按我上面描述的去做，但我参与的公司 Alta 已经在用一个 Agent 自动建议指标定义的修改。我认为 Alta 的做法很棒，让他们能实现极致个性化（即每个终端用户一套不同的指标集），我也期待看到它的演进。

注 2：Han 在审阅博文时提了一个好问题：这种做法在某些行业可能不被允许，比如法务团队要求提示进入生产前必须"签字放行"？另外，这里的提示投毒（prompt poisoning）风险如何——会不会有人恶意构造查询，使其被当作少样本示例收进提示？

注 3：我非常喜欢这篇博文（作者是我从前的同事 Devin Stein），它倡导在运行时动态获取提示示例。据我所知至少有 5 个人在做类似的事。有意思的是，这种架构把提示工程问题转化成了检索问题——如何检索出既 (1) 对 LLM 信息量最大、又 (2) 与终端用户想要的最相关的示例？

要点速览

  • 核心命题：LLM 应用可以用生产数据构建"数据飞轮"，形成评估→监控→持续改进的闭环，而无需依赖微调或重型 ML 平台。
  • 四个经验前提：人需要定期参与评估（偏好会漂移）；LLM API 不总听指令、输出需要验证器；LLM-as-a-judge 越来越便宜好用；少样本示例是改进提示最有效的手段——因此裁判可以被对齐。
  • 评估：指标必须从真实输出中归纳而非凭空设计（例如检测"delve/crucial"这类"GPT 味"用词）；优先用二值（True/False）指标而非李克特量表，因为更容易对齐、人类判断更稳定。
  • 多步流水线中把验证器当"探针"：LLM 分类器节点看准确率/精确率/召回率/F1；LLM 写作节点用高度定制的质量与品牌语气指标；代码生成节点用静态分析、linter、测试套件和动态执行验证。
  • 输入验证与输出验证同样重要：用户身份认证、主题相关性（关键词+嵌入相似度阈值如 0.7）、查询复杂度、语言检测、敏感信息、对抗输入（提示注入）、异常检测；设计哲学是 Postel 法则——发给 LLM 的要严格，接受的响应要宽容。
  • 监控：指标集不是静态的，可用 LLM Agent 定期分析生产数据提议增删改指标（人工审核后生效）；指标实现靠"定期采样人工标注 + 动态少样本检索"保持与人对齐，可按新近度加权、优先检索人机判断不一致的样本。
  • 持续改进：定期修复低分输出并记录理由，把"已修复轨迹"存库，运行时按相似度检索回提示作为少样本示例——把提示工程问题转化为检索问题（作者提及至少 5 个团队在这样做）。
  • 把质量拆成多维指标而非整体打分：人类标注更一致、LLM 验证器一次只需查一个维度、分数能直接定位薄弱环节。
  • 三个开放研究方向：LLM API 的不确定性量化（用于校准验证器与主动采样）；LLM 调用"图"的图感知验证与动态探针插入、子图级少样本检索；数据库内建验证（触发器自动执行验证器、视图式指标计算、语义索引增量维护）。
  • 与课程衔接：本文是"Who Validates the Validators"研究思路的工程化落地，也是第 6 周数据主题的总纲——飞轮的每个环节都围绕"人对齐"展开。