Data-Centric AI / Snorkel / Programmatic Labeling 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_PROGRAMMATIC_LABELING_DATA_CENTRIC_AI_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Source Anchors

核心导读

Data-Centric AI 关注的不是单纯增加标注量，而是把标签定义、专家规则、弱监督信号、冲突处理、数据版本、质量指标和治理证据做成可迭代的系统能力。Snorkel / programmatic labeling 的关键机制，是把专家知识、业务规则、字典、远程监督、模型信号和 LLM 辅助判断写成可版本化的 labeling functions，再通过 label model 处理覆盖、冲突和来源准确率。

这类方法适合标签稀缺、专家知识强、业务变化快的场景，但弱标签不能冒充事实标签。架构上必须把 labeling functions、gold set、人工仲裁、评估隔离、数据合同和审计证据放在同一条数据治理链路里，否则训练数据会变成不可追溯的风险来源。

核心问题

很多 AI 项目失败，不是因为模型不够大，而是因为标签系统不成熟。

金融零售里经常遇到这些问题：

• AML typology 标签稀缺，真实阳性少，专家判断依赖复杂上下文。
• KYC 文档模板跨国家、渠道和证件类型变化快，人工标签总是滞后。
• 投诉意图 taxonomy 经常调整，历史标签口径不一致。
• 欺诈模式快速变化，旧标签很快不能覆盖新攻击。
• RAG 评测需要判断 answer correctness、citation support、policy safety 和 customer usefulness，人工成本高。
• 客服、风控、合规系统里存在大量历史 disposition，但它们不是干净训练标签。

传统做法是启动标注项目：

抽样 -> 外包/专家标注 -> 训练模型 -> 上线 -> 下次问题再标注

这个流程有四个缺陷。

第一，专家知识没有被产品化。专家写在邮件、Excel、会议纪要和标注指南里的判断规则，无法稳定复用。

第二，标签质量不可追溯。一个标签来自人工、规则、历史系统、远程监督还是模型推断，经常混在一起。

第三，taxonomy 漂移会污染训练集。标签定义变了，历史数据是否还可用没有版本控制。

第四，生产反馈无法闭环。上线后发现的冲突、错误、盲区和新模式没有系统地回到标签资产。

Data-Centric AI 要解决的是：

把数据和标签从一次性准备工作，升级为持续迭代、可审计、可治理的产品能力。

方法/论文贡献

Snorkel 的核心贡献，是提出 data programming：用户不必逐条手工标注，而是编写 labeling functions。每个 LF 是一个弱监督信号源，可以给样本打标签，也可以 abstain。

这个贡献的重要性在于，它把专家知识从非结构化经验变成可运行、可测试、可版本化的代码或规则。

第二个贡献是 label matrix。多个 LF 对未标注数据投票，形成一个矩阵。矩阵里不仅有标签，还有 abstain、overlap 和 conflict。冲突不再只是错误，而是可分析的信号：规则口径不一致、taxonomy 不清、样本复杂或数据质量有问题。

第三个贡献是 label model。简单多数投票会把所有 LF 当成同等可靠，也会把相关 LF 当成独立证据。Snorkel 的生成式标签模型尝试估计不同 LF 的准确率和相关性，输出概率标签，而不是直接压成硬标签。

第四个贡献是把弱监督标签用于训练 discriminative model。最终上线的模型不一定运行所有 LF，而是用概率标签训练一个能泛化到 LF 之外模式的下游模型。

这条路线改变了训练数据创建的组织方式：

expert knowledge
  -> labeling functions
  -> label matrix
  -> label model
  -> probabilistic training labels
  -> downstream model
  -> error analysis and LF iteration

它不是绕过人工专家，而是把专家时间从逐条标注转移到规则设计、冲突仲裁、盲区分析和标签政策治理。

机制原理：Labeling Function

Labeling Function 是一个程序化弱标签源。

它可以是规则：

if OCR text contains "passport" and MRZ pattern exists:
  label = passport
else:
  abstain

也可以是业务字典：

if complaint text contains "unauthorized fee" or "fee charged without consent":
  label = fee_dispute
else:
  abstain

也可以是远程监督：

if transaction counterparty appears in confirmed mule account list:
  label = mule_network_related
else:
  abstain

LF 的来源很广：

LF 设计的关键不是覆盖所有样本，而是明确适用范围。一个高精度低覆盖 LF 很有价值；一个高覆盖但低精度 LF 可能会污染训练。

因此每个 LF 都需要元数据：

• owner。
• 适用标签。
• 输入字段。
• 数据时点。
• 适用 segment。
• 已知风险。
• 单元样例。
• 版本和审批记录。

LF 是可审计专家知识，不是随手写的临时脚本。

机制原理：Label Matrix

多个 LF 对样本打标签后，会得到 label matrix。

sample_001: LF1=passport, LF2=abstain, LF3=passport, LF4=national_id
sample_002: LF1=abstain, LF2=structuring, LF3=structuring, LF4=abstain
sample_003: LF1=fee_dispute, LF2=fraud_claim, LF3=abstain, LF4=fee_dispute

这个矩阵最重要的不是最终标签，而是四类质量信号。

还要看 segment coverage。一个 KYC 文档分类 LF 在美国驾照上覆盖很好，不代表在东南亚证件、低质量图片或移动端上传样本上也有效。一个投诉意图 LF 在英文渠道有效，不代表在中英混合、语音转写或社媒投诉中有效。

冲突样本尤其重要。高冲突可能表示：

• taxonomy 设计过粗或过细。
• 标签之间不是互斥关系。
• 标注指南有歧义。
• 数据字段质量差。
• 业务政策变化后旧规则失效。
• 新型风险模式出现。

因此冲突不是垃圾数据，而是 data-centric loop 的输入。

机制原理：Label Model

简单多数投票有明显问题。

三个低质量 LF 同意，不一定比一个高质量专家 LF 更可靠。两个规则看似独立，可能都来自同一个历史字段，不能重复当作两份证据。某些 LF 在一个 segment 准确，在另一个 segment 失效。

Label model 的目标，是估计 LF 的可靠性和相关性，并输出概率标签。

sample -> P(label = A) = 0.72, P(label = B) = 0.21, P(label = C) = 0.07

概率标签比硬标签更诚实。它保留了不确定性，也允许下游训练时按置信度加权。

但 label model 不是魔法。它需要 LF 有足够 overlap 和 conflict 才能估计来源质量。若所有 LF 都来自同一个偏见来源，label model 也无法凭空恢复真实标签。若 taxonomy 本身混乱，label model 只能把混乱统计化。

因此必须有独立 gold set。Gold set 的作用不是替代所有弱监督，而是校准 LF、验证 label model、评估下游模型，并在高风险场景提供可信基准。

为什么有效

Programmatic labeling 有效的第一层原因，是专家规则比逐条标注更可扩展。一个 AML 专家写出 20 条 typology LF，可能覆盖数万历史 case；逐条标注同样数量样本几乎不可行。

第二层原因，是它让标签问题可迭代。传统标注项目结束后，很难系统性修改历史标签；LF 版本更新后，可以重跑标签矩阵，比较 coverage、conflict 和 downstream lift。

第三层原因，是它把冲突显性化。人工标注常把争议压成一个最终标签，弱监督系统会把不同来源的分歧暴露出来，推动 taxonomy 和政策改进。

第四层原因，是它降低冷启动难度。在新产品、新地区、新文档类型和新风险模式中，gold labels 少，但专家规则、历史系统、知识库和弱信号通常已经存在。

第五层原因，是它形成可审计数据资产。LF、标签来源、覆盖、冲突、版本和评审记录可以进入模型风险和审计材料。

局限和误用

第一类误用，是把弱标签当成真实标签。弱监督生成的是训练信号，不是监管事实、客户事实或最终业务结论。

第二类误用，是高覆盖低质量。为了快速扩大训练集，团队可能写出覆盖很广但噪声很大的 LF，短期模型指标看似提升，长期泛化变差。

第三类误用，是 LF 泄漏未来信息。例如用 case 最终处置、chargeback 结果或人工审核后的字段去标注决策时点样本，会让离线指标虚高。

第四类误用，是 taxonomy 没有版本。投诉标签、AML typology 或 KYC 文档分类一旦调整，历史标签需要映射、冻结或分版本训练，不能混在一起。

第五类误用，是 LLM 标签幻觉。LLM 可以作为 LF 候选，但必须记录 prompt、模型版本、证据要求、抽检结果和失败模式。不能因为 LLM 输出流畅就把它当专家。

第六类误用，是忽略 segment。LF 在总体上 precision 高，不代表对少数语言、低质量图片、新渠道、薄文件客户或特定地区可靠。

第七类误用，是把 LF 逻辑散落在 notebook 中。没有 registry、review、测试、owner 和版本控制，programmatic labeling 会变成不可审计脚本堆。

架构/产品价值

Data-centric 平台要把标签变成一等资产。

use case intake
  -> label taxonomy and policy
  -> raw / unlabeled data pool
  -> LF registry and review workflow
  -> label matrix builder
  -> quality analyzer
  -> label model
  -> probabilistic dataset
  -> model training and eval
  -> SME review and active learning
  -> dataset registry and evidence binder

关键组件如下：

产品价值不是“少花标注钱”这么简单。更重要的是：

• 快速把专家知识转成可复用训练信号。
• 发现标签定义和政策口径问题。
• 让训练数据版本和模型版本可以一起治理。
• 支持新模式、新地区、新产品的快速适配。
• 为审计和模型风险提供标签来源证据。

金融零售系统案例

KYC 文档分类

KYC 文档分类可以从多个 LF 起步：

冲突样本很有价值。例如 MRZ 指向 passport，但 OCR 关键词指向 national ID，可能是 OCR 误读、复合文档、模板库缺失或欺诈文档。

上线前要按国家、渠道、图片质量、文档类型和客户群体查看 coverage 和 precision。低质量图片和新模板应进入 SME review，而不是用弱标签自动通过。

AML Typology Tagging

AML typology 标签非常适合 programmatic labeling，因为专家知识强、真阳性少、历史 narrative 丰富。

LF 可以来自：

• 交易规则命中。
• case narrative 关键词。
• 对手方网络特征。
• 高风险行业和地理路径。
• 调查员 disposition。
• 历史 SAR 主题。
• 关系图中的已知 typology 连接。

但治理边界必须清楚。弱标签可以训练 alert triage 或 case routing 模型，不能直接作为 suspicious activity 结论。监管 filing evidence 需要独立证据、人工判断和政策依据。

高冲突 typology 样本应进入 adjudication。它可能说明 typology 重叠、规则过期、新型模式出现，或调查员口径不一致。

投诉意图识别

投诉意图经常是多标签问题。一个客户可能同时表达费用争议、欺诈担忧、服务态度和账户限制。

LF 来源包括：

• 投诉分类字典。
• 监管关键词。
• 客服 disposition。
• 客户旅程事件。
• 产品和费用代码。
• LLM 辅助意图判断。
• 历史升级原因。

这里最容易犯的错，是把标签设计成互斥单选。Data-centric 平台应该支持多标签、主次意图、监管敏感标签和证据片段。冲突样本可以推动 taxonomy 调整，而不是简单丢弃。

学习验证

学习这篇后，可以做一个 data-centric labeling 练习。

1. 选择 KYC、AML、投诉、欺诈或 RAG eval 任一场景。
2. 定义 label taxonomy，说明标签是否互斥、多选、分层或有监管敏感标签。
3. 写出至少 10 个 LF，标明来源、输入字段、输出标签、abstain 条件和风险。
4. 设计 label matrix 的 coverage、overlap、conflict 分析。
5. 说明为什么多数投票不够，以及 label model 试图解决什么问题。
6. 设计 gold set 和 SME adjudication 流程。
7. 识别至少三个 LF 可能泄漏未来信息的点。
8. 按 segment 设计覆盖和质量检查。
9. 定义 weak label、gold label、adjudicated label 和 business fact 的边界。
10. 设计 dataset registry 和 evidence binder 字段。

完成这些任务后，应该能把 data-centric AI 理解为标签平台和治理能力，而不是一次性标注项目。

关键结论

Data-Centric AI 的核心是持续改进数据和标签资产，而不是只换更大的模型。

Snorkel / programmatic labeling 的核心机制是 labeling function、label matrix、label model 和概率训练标签。

弱监督的价值是速度、覆盖、可迭代和专家知识复用；风险是标签污染、未来信息泄漏、taxonomy 漂移和弱标签冒充事实。

金融零售落地时，标签系统必须和 gold set、SME review、active learning、dataset registry、model risk evidence 和生产监控连接。

真正成熟的 AI 数据平台，不是有更多标签，而是知道每个标签从哪里来、适用于什么、可信到什么程度、什么时候需要重新验证。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。