AI Programmatic Labeling & Data-Centric AI Playbook

定位：面向高级 AI PM / AI BA / AI Architect / Model Risk / Data Governance / 金融零售运营团队，把 programmatic labeling、weak supervision、Snorkel/data programming、SME review、label quality、dataset documentation 和 release gate 组合成可上线、可审计、可迭代的数据中心型 AI 生产体系。

适用边界：本文面向 KYC 文件分类、AML case triage、客户投诉分类、欺诈 typology tagging、运营工单分流、合规文本归类、RAG 训练/评估集构建和内部 copilot 反馈标签。它不把“弱监督”当成免人工标注，而是把专家知识、规则、历史案例、系统证据和模型辅助判断组织成可版本化、可度量、可治理的标签资产。

重要说明：本文是学习、作品集和内部方案训练材料，不构成法律意见、合规结论、模型验证报告、监管解释或正式模型风险批准。正式项目必须由 Legal、Compliance、Model Risk、Fair Lending、Privacy、Security、Data Governance、Business Owner、Operations、SME 和管理层结合机构类型、司法辖区、客户影响、内部政策和使用场景确认。

---

Source Anchors

以下来源是本文的技术和治理锚点。本文把它们转成产品能力、架构组件、质量指标、SME 工作流、审计证据和上线门禁，不把任何论文或框架直接等同于监管合规结论。

---

1. 一句话定位

Programmatic labeling 的核心不是“用规则批量打标签”，而是：

Label-to-Model Control System =
把 SME 知识、政策定义、历史案例、业务规则、外部知识库、模型建议和抽样人工判断
编码为可测试、可版本化、可解释来源的 labeling functions，
再用 label model 和 gold set 估计标签质量，
把 noisy labels 转成可治理的训练数据、评估数据、路由策略和审计证据。

在金融零售里，label 是产品和风控的事实层，不是数据科学的中间产物：

高级 AI PM / 架构师要能回答四个问题：

1. 标签政策是什么，哪些标签能自动生成，哪些必须 SME 裁决？
2. 每个标签的证据、版本、冲突、覆盖率和质量指标在哪里？
3. 标签缺陷如何影响模型、流程、客户体验和审计风险？
4. 数据中心型迭代如何进入 release gate，而不是停留在 notebook 实验？

---

2. 为什么重要

2.1 从模型中心到数据中心

许多 AI 项目失败不是因为模型架构不够新，而是因为训练标签没有稳定定义。

典型失败链路：

业务团队说“识别高风险 AML case”
-> 数据团队从历史字段里取一个 proxy label
-> 历史标签混合了不同团队、时期和政策口径
-> 模型学到旧流程偏差
-> 线上效果不稳定
-> 团队继续调参、换模型、加特征
-> 根因仍然是 label policy 和 evidence trail 缺失

数据中心型 AI 的反向做法：

定义标签政策和业务动作
-> 设计 label ontology 和 evidence requirements
-> 建立 gold set 与 SME adjudication
-> 编写 labeling functions 捕获专家知识和系统证据
-> 分析 coverage / conflicts / precision / recall / segment gaps
-> 修正标签、数据和流程
-> 再训练模型和评估上线风险

2.2 Programmatic labeling 解决的不是成本，而是迭代速度和可治理性

人工标注可以产生高质量样本，但在金融零售的复杂场景里会遇到四个瓶颈：

Programmatic labeling 不等于自动化所有标注。它把“专家逐条判断”升级为“专家设计、测试、监控和治理标签系统”。

2.3 金融零售的标签风险具有客户影响

标签缺陷会进入模型训练、运营分流、客户沟通和管理报告。高级团队必须把 label quality 当成生产控制。

---

3. 核心概念地图

3.1 Programmatic labeling

Programmatic labeling 是用程序化规则、启发式、模式匹配、外部知识、历史系统信号、模型建议和 SME 逻辑批量产生标签候选。

它适合以下条件：

不适合以下条件：

3.2 Weak supervision

Weak supervision 把不完美但有用的监督信号组合起来：

Weak supervision 的目标不是让每个弱信号都正确，而是通过组合、估计、冲突分析和 gold validation 产生更稳健的 probabilistic labels。

3.3 Labeling function

Labeling function, LF，是一个输入样本到标签或 abstain 的函数：

LF(sample) -> one of {label_a, label_b, label_c, ABSTAIN}

优秀 LF 有五个特征：

3.4 Generative label model

在 Snorkel / data programming 思路中，多个 LF 会形成一个 label matrix：

Rows    = samples
Columns = labeling functions
Values  = label id or abstain

Generative label model 估计 LF 的准确率、相关性和冲突模式，输出 probabilistic labels。它解决的问题是：

LFs noisy and conflicting
-> estimate source accuracies and dependencies
-> produce confidence-weighted training labels
-> train downstream discriminative model

关键边界：

3.5 Data-centric AI

Data-centric AI 的 PM / 架构含义：

模型迭代 = 标签定义、数据覆盖、证据质量、冲突裁决、分段公平、数据文档和监控的共同迭代。

对 AI PM 来说，数据中心型工作不是“让数据科学家清洗数据”，而是建立 label product：

---

4. LabelOps 平台能力

4.1 能力全景

Source systems
  - documents, cases, transactions, complaints, CRM, core banking, fraud tools
  - policy docs, product catalog, external lists, investigation notes
-> Data ingestion and permission boundary
-> Label ontology and label policy registry
-> Labeling function development
  - rule LF
  - dictionary / taxonomy LF
  - metadata LF
  - knowledge-base LF
  - model-assisted LF
  - LLM-assisted LF with review controls
-> LF execution engine
-> Label matrix store
-> Label model and quality analysis
-> SME review and adjudication console
-> Dataset and label version registry
-> Training / evaluation / monitoring exports
-> Audit evidence binder and release gate

4.2 关键组件

4.3 角色模型

---

5. 架构设计

5.1 Reference Architecture

Operational and document sources
  -> data contract and access control
  -> canonical sample builder
     - document sample
     - case sample
     - complaint sample
     - transaction pattern sample
  -> evidence extractor
     - OCR spans
     - metadata
     - transaction aggregates
     - policy references
     - historical decisions
  -> LF runtime
     - deterministic rules
     - taxonomy matchers
     - knowledge-base joins
     - model-assisted signals
  -> label matrix
  -> quality analyzer
     - LF coverage
     - overlap and conflict
     - gold precision and recall
     - segment coverage
     - drift and stale rule checks
  -> label model
  -> probabilistic labels
  -> SME review queue
  -> adjudicated labels and gold set
  -> dataset registry
  -> downstream model training and evaluation
  -> release gate and monitoring

5.2 Canonical sample design

Programmatic labeling 平台必须先统一“被标注对象”，否则 LF 会绑定各系统的偶然字段。

5.3 Evidence trail schema

标签系统的审计价值来自 evidence trail。

5.4 Versioning strategy

标签版本必须同时覆盖数据、政策、LF、label model 和人工裁决。

Label Release =
dataset snapshot
+ extraction code version
+ label ontology version
+ label policy version
+ LF bundle version
+ label model version
+ gold set version
+ SME adjudication version
+ quality report
+ approval record

版本策略：

---

6. Labeling Function 设计

6.1 LF 类型

6.2 LF 设计原则

6.3 KYC document LF 示例

ABSTAIN = -1
PASSPORT = 1
UTILITY_BILL = 2
BANK_STATEMENT = 3

def lf_passport_keywords(sample):
    text = sample.ocr_text.lower()
    strong_terms = ["passport", "date of birth", "place of birth", "passport no"]
    if sum(term in text for term in strong_terms) >= 2:
        return PASSPORT
    return ABSTAIN

def lf_recent_utility_bill(sample):
    text = sample.ocr_text.lower()
    has_utility_terms = any(term in text for term in ["electricity", "water", "gas", "utility"])
    has_address = sample.extracted_address is not None
    is_recent = sample.document_date_within_days(120)
    if has_utility_terms and has_address and is_recent:
        return UTILITY_BILL
    return ABSTAIN

def lf_bank_statement_layout(sample):
    text = sample.ocr_text.lower()
    if "statement period" in text and "account number" in text and sample.has_transaction_table:
        return BANK_STATEMENT
    return ABSTAIN

产品/架构注意点：

6.4 AML case triage LF 示例

ABSTAIN = -1
STRUCTURING_SIGNAL = 10
RAPID_MOVEMENT_SIGNAL = 11
HIGH_RISK_COUNTERPARTY_SIGNAL = 12

def lf_structuring_pattern(case):
    tx = case.transaction_summary
    if tx.cash_deposit_count_30d >= 5 and tx.amounts_cluster_below_reporting_threshold:
        return STRUCTURING_SIGNAL
    return ABSTAIN

def lf_rapid_in_out(case):
    tx = case.transaction_summary
    if tx.incoming_to_outgoing_ratio_7d > 0.85 and tx.median_hold_time_hours < 24:
        return RAPID_MOVEMENT_SIGNAL
    return ABSTAIN

def lf_high_risk_counterparty(case):
    if case.counterparty_risk_hits >= 1 and case.counterparty_match_quality in ["strong", "confirmed"]:
        return HIGH_RISK_COUNTERPARTY_SIGNAL
    return ABSTAIN

边界要求：

6.5 Complaints classification LF 示例

ABSTAIN = -1
UNAUTHORIZED_TRANSACTION = 20
SERVICE_DELAY = 21
FEE_DISPUTE = 22

def lf_unauthorized_transaction_terms(complaint):
    text = complaint.normalized_text
    terms = ["unauthorized", "did not authorize", "fraudulent charge", "identity theft"]
    if any(term in text for term in terms):
        return UNAUTHORIZED_TRANSACTION
    return ABSTAIN

def lf_service_delay_terms(complaint):
    text = complaint.normalized_text
    terms = ["still waiting", "not received", "delay", "no response", "pending for"]
    if any(term in text for term in terms) and complaint.days_open >= 3:
        return SERVICE_DELAY
    return ABSTAIN

def lf_fee_dispute_terms(complaint):
    text = complaint.normalized_text
    if "fee" in text and any(term in text for term in ["waive", "refund", "charged", "overdraft"]):
        return FEE_DISPUTE
    return ABSTAIN

投诉标签要连接：

6.6 Fraud typology LF 示例

ABSTAIN = -1
ACCOUNT_TAKEOVER = 30
CARD_NOT_PRESENT = 31
SYNTHETIC_IDENTITY = 32

def lf_account_takeover(event):
    login = event.login_features
    tx = event.transaction_features
    if login.new_device and login.geo_velocity_high and tx.first_time_payee and tx.value_zscore > 3:
        return ACCOUNT_TAKEOVER
    return ABSTAIN

def lf_card_not_present(event):
    if event.card_present is False and event.ecommerce_mcc and event.avs_mismatch:
        return CARD_NOT_PRESENT
    return ABSTAIN

def lf_synthetic_identity(event):
    identity = event.identity_features
    if identity.thin_file and identity.recently_created_contact_points and identity.high_credit_velocity:
        return SYNTHETIC_IDENTITY
    return ABSTAIN

欺诈标签要避免两个误区：

---

7. Label Quality Metrics

7.1 基础指标

7.2 高级指标

7.3 Label precision / recall 的业务解释

标签 precision 和 recall 不是单纯模型指标，而是运营风险语言。

7.4 Gold set 设计

Gold set 是标签系统的校准锚点，不是随手抽一批样本。

Gold set 审查要求：

每条 gold label =
label
+ evidence references
+ policy version
+ reviewer
+ rationale
+ adjudication status
+ timestamp

---

8. SME Workflow

8.1 从逐条标注到标签系统治理

SME 的高价值工作不是无休止点击标签，而是：

8.2 SME Review Queue

Review queue 不应随机堆积样本，而要按信息价值排序。

8.3 Adjudication protocol

Step 1: Reviewer 只看原始样本、证据和 label policy，不看模型最终建议
Step 2: Reviewer 给出 label、evidence、rationale、confidence
Step 3: 第二 reviewer 审查高影响或争议样本
Step 4: Disagreement 进入 adjudication panel
Step 5: Panel 决定是样本误判、政策模糊、标签体系缺失还是 LF 缺陷
Step 6: 结果进入 gold set、policy change 或 LF backlog

8.4 SME 工作量设计

---

9. 金融零售场景落地

9.1 KYC document classification

目标不是“识别图片是什么”，而是减少客户反复提交、提升预校验准确性，并把证据交给后续 KYC 流程。

关键边界：

Document type label != KYC pass decision
Proof of address label != address verified
Passport label != identity verified

9.2 AML case triage

目标是帮助调查队列排序、typology 初筛和证据组织，而不是自动做正式合规结论。

产品机会：

9.3 Complaints classification

目标是提升路由、SLA、根因分析和整改闭环，而不是用 AI 替代客户权益判断。

9.4 Fraud typology tagging

目标是把欺诈事件从“是否欺诈”拆成攻击模式、控制缺口、客户影响和补救路径。

---

10. 治理和 Release Gate

10.1 NIST AI RMF 映射

10.2 Label policy

每个高价值标签必须有 label policy。

10.3 Fairness and segment coverage

弱监督标签也会产生 fairness 风险。即使最终模型尚未训练，标签阶段已经可能引入偏差。

公平性治理动作：

发现 segment gap
-> 判断是数据缺失、政策差异、LF 缺陷还是真实业务差异
-> 扩充 gold set 或 LF
-> 必要时限制自动化用途
-> 在 release report 中记录残余限制和风险接受

10.4 Audit evidence binder

一个标签版本进入下游模型训练或生产分流前，至少应形成 evidence binder：

10.5 Release gate

Release Gate Decision =
用途是否清楚
+ 标签政策是否批准
+ 数据权限是否满足
+ LF 是否有 owner 和测试
+ gold set 是否覆盖关键 segment
+ coverage / precision / recall 是否达标
+ conflicts 是否有处置
+ 高影响用途是否有人审
+ audit evidence 是否完整
+ monitoring and rollback 是否可执行

Gate 结果：

---

11. 模板

11.1 Label policy template

# Label Policy: Complaint - Unauthorized Transaction

## Business Purpose
用于投诉路由、SLA 优先级、根因分析和模型训练标签候选。

## Allowed Use
- 客服工单初始分类建议
- 质检抽样和根因分析
- 投诉分类模型训练和评估

## Prohibited Use
- 不直接作为客户赔付、拒赔、账户限制或正式监管结论
- 不绕过人工复核处理高严重度投诉

## Positive Criteria
- 客户明确表示交易、扣款、转账或账户访问未经授权
- 文本或客服摘要包含与未授权、身份盗用、欺诈交易相关的证据

## Negative Criteria
- 仅对费用金额不满但承认交易发生
- 仅询问交易状态或处理延迟
- 商户服务争议但无未授权主张

## Evidence Requirement
- 原始客户文本 span
- 关联交易 id 或账户事件 id
- 渠道、时间、产品线
- reviewer rationale

## SME Review Rule
- 高严重度、客户损害、重复投诉、低置信或与 fee dispute 冲突的样本进入二审。

11.2 Labeling function card

# Labeling Function Card: lf_unauthorized_transaction_terms

## Intent
捕获客户投诉文本中明确表达未授权交易、身份盗用或欺诈扣款的样本。

## Input
- complaint.normalized_text
- complaint.product
- complaint.channel
- linked_transaction.exists

## Output
- UNAUTHORIZED_TRANSACTION
- ABSTAIN

## Evidence
- matched_terms
- text_spans
- linked_transaction_id

## Expected Strength
高 recall 初筛；precision 依赖否定语义和上下文过滤。

## Known Failure Modes
- 客户引用银行回复中的“unauthorized”但本人并未主张未授权
- 商户争议被误判为未授权交易
- 非英语或混合语言文本覆盖不足

## Metrics Required
- coverage overall
- precision on gold
- recall on gold
- conflict with FEE_DISPUTE and SERVICE_DELAY
- coverage by language and channel

## Review Owner
Complaint operations SME lead

11.3 Dataset / label version card

# Label Dataset Card: AML Triage Labels v2026.06

## Purpose
为 AML case triage model 提供 typology training labels 和 analyst evidence pack，不用于自动生成正式合规结论。

## Data Sources
- AML case management cases closed between 2025-10-01 and 2026-03-31
- Transaction aggregates generated by approved feature pipeline
- Analyst notes with restricted access controls
- Counterparty risk source version 2026.05

## Label Ontology
- STRUCTURING_SIGNAL
- RAPID_MOVEMENT_SIGNAL
- HIGH_RISK_COUNTERPARTY_SIGNAL
- INSUFFICIENT_EVIDENCE

## Label Policy Version
AML-TYPOLOGY-POLICY-2026.05

## LF Bundle Version
AML-LF-BUNDLE-2026.06.2

## Gold Set
- 1,200 adjudicated cases
- stratified by product, channel, customer type and alert source
- all high-conflict samples reviewed by two SMEs

## Quality Summary
- label coverage: 78%
- conflict rate: 14%
- top-label precision on gold: 86%
- lowest segment precision: 79% for new digital channel cases
- release restriction: new digital channel cases require analyst confirmation

## Limitations
- Historical analyst labels may reflect prior queue strategy
- Typology labels are triage support and do not replace investigation conclusions

11.4 SME review protocol template

# SME Review Protocol: Fraud Typology

## Review Scope
Review high-conflict, high-loss, customer-disputed and low-coverage samples from the latest fraud typology label run.

## Reviewer Instructions
1. Read the policy definition before viewing LF outputs.
2. Inspect transaction, device, login and customer claim evidence.
3. Assign one primary typology and optional secondary typology.
4. Record rationale using concrete evidence.
5. Mark policy ambiguity when evidence supports multiple labels.

## Escalation
- New attack pattern goes to fraud taxonomy owner.
- Customer harm or adverse action issue goes to operations risk owner.
- Potential policy conflict goes to governance review.

## Output
- adjudicated_label
- evidence_refs
- reviewer_confidence
- rationale
- policy_issue_flag

11.5 Release gate checklist

# Label Release Gate: KYC Document Classification v2026.06

## Scope
Mobile and web upload document classification for onboarding pre-check and operations routing.

## Required Evidence
- Approved label ontology and policy
- LF inventory with owner and tests
- Gold set report with segment coverage
- Quality dashboard export
- New vs previous version impact analysis
- Security and privacy approval for OCR text handling
- SME approval
- Monitoring and rollback plan

## Minimum Criteria
- top-label precision on gold >= 90%
- unsupported document recall >= 85%
- no critical segment below approved precision threshold
- all high-conflict document templates reviewed
- no LF with expired policy or external source dependency

## Decision
Approve with restriction: unsupported or low OCR quality samples route to manual review.

---

12. 30 天训练计划

---

13. 面试答案

Q1: Programmatic labeling 和普通规则标注有什么区别？

30 秒版本

普通规则标注通常是批量 if-else。Programmatic labeling 是一个标签生产系统：用多个 LF 表达专家知识和弱监督信号，显式保留 abstain、conflict、coverage 和 evidence，再用 label model、gold set 和 SME review 估计标签质量，最终形成可版本化、可审计的训练数据。

2 分钟版本

我会从四层解释。第一层是 label policy，先定义标签含义、证据和禁止用途。第二层是 LF，把规则、知识库、历史信号和模型建议转成可测试的弱监督来源。第三层是 label model 和质量分析，处理 LF 之间的冲突、相关性和噪声，输出 probabilistic labels。第四层是治理，包括 gold set、SME adjudication、segment coverage、release gate 和 monitoring。在金融场景里，弱标签不能直接触发客户不利动作，它更多用于训练、分流、证据组织和人工复核优先级。

Q2: Generative label model 解决什么问题？

30 秒版本

它解决多个 noisy、conflicting、abstaining LF 如何融合的问题。它估计 LF 的准确性和依赖关系，把 label matrix 转成概率标签。

2 分钟版本

在 weak supervision 中，每个 LF 都可能覆盖有限、精度不一，还可能相互冲突。Generative label model 不是训练最终业务模型，而是建模标签生成过程：哪些 LF 更可信，哪些 LF 经常一起错，哪些冲突代表真正不确定。输出的 probabilistic labels 再用于训练下游 discriminative model。它的边界是必须通过 gold set 和 SME review 验证，不能因为模型给出概率就把标签当真值。

Q3: 如何衡量标签质量？

30 秒版本

我会同时看 coverage、overlap、conflict、precision、recall、label entropy、segment coverage、review overturn rate 和 downstream sensitivity。

2 分钟版本

coverage 告诉我们标签系统覆盖多少样本；conflict 告诉我们政策或规则哪里有争议；precision / recall 要在 gold set 上看，尤其是高影响标签；segment coverage 和 segment precision 用来识别不同渠道、语言、地区和客户类型的质量差异；review overturn rate 反映 SME 是否经常推翻系统标签；downstream sensitivity 判断某类 LF 改动是否会显著影响模型。金融场景不能只看总体准确率，因为低覆盖 segment 可能正是风险最高或客户影响最大的地方。

Q4: SME 在 programmatic labeling 中应该做什么？

30 秒版本

SME 不应该只是逐条打标签，而应该设计标签政策、审查 LF、裁决冲突、建立 gold set、审查 release report，并用生产反馈持续修正标签系统。

2 分钟版本

Programmatic labeling 的价值是放大 SME 判断。高级 SME 先定义 label ontology 和 policy，包括 positive、negative、boundary cases 和证据要求。数据团队把这些知识编码成 LF 后，SME 审查 LF 是否符合业务现实。系统运行后，SME 优先处理高冲突、高不确定、高影响和低覆盖 segment 样本。裁决结果不仅形成 gold set，还反向推动政策澄清和 LF 改进。这样 SME 时间从低价值重复标注转向高价值治理。

Q5: 如何防止弱标签固化历史偏差？

30 秒版本

不能直接把历史处理结果当真值。要记录标签来源，区分 outcome、action 和 proxy，按 segment 检查 coverage 和 precision，用 gold set、SME review 和生产反馈校验。

2 分钟版本

历史标签可能反映旧政策、旧资源分配和旧队列优先级。例如 AML case 被调查并不等于真实风险更高，投诉被某团队处理也不等于分类正确。我会在 label policy 中明确 allowed source，给 historical decision LF 标记 proxy risk，并在质量报告里单独看 segment bias、review overturn 和 downstream sensitivity。高风险历史 proxy 只能作为弱信号，不能作为唯一真值。上线前 release gate 必须说明这种残余风险如何被限制。

Q6: LabelOps 平台 MVP 应该包括什么？

30 秒版本

MVP 至少包括 label ontology/policy registry、LF registry、LF execution、label matrix、quality dashboard、SME review、dataset versioning 和 release gate。

2 分钟版本

我会先建端到端闭环，而不是追求复杂 UI。第一是定义和版本化标签政策。第二是让数据科学家和 SME 能提交 LF，并记录 owner、evidence、测试和依赖。第三是运行 LF 生成 label matrix，展示 coverage、conflict、precision、recall 和 segment gaps。第四是 SME review console，处理高价值样本并形成 gold set。第五是 dataset registry 和 release gate，把标签版本进入训练或生产前的证据、审批和 rollback 固化下来。

Q7: LLM 可以作为 labeling function 吗？

30 秒版本

可以作为弱监督来源，但必须有 prompt version、evidence requirement、gold validation、segment analysis 和 SME review，不能把 LLM 输出直接当真值。

2 分钟版本

LLM 适合处理文本分类、摘要辅助、候选 evidence extraction 和 hard sample suggestion。但它的输出受 prompt、上下文、模型版本和数据分布影响，可能流畅但错误。因此我会把 LLM LF 设计成可审计组件：记录 prompt、model version、input context、输出、引用证据和置信信息；在 gold set 上评估 precision / recall；按语言和渠道切片；高影响样本必须人工复核。LLM LF 的定位是扩展覆盖和发现候选，不是替代标签政策。

Q8: 如何向管理层解释 Data-centric AI 的投资价值？

30 秒版本

它降低的不是单次标注成本，而是模型迭代、审计、运营一致性和风险控制成本。高质量标签平台让 AI 项目从一次性实验变成可复用的数据资产。

2 分钟版本

我会用金融零售语言表达：第一，减少开户、投诉、欺诈和 AML 队列中的误分流，提高运营效率；第二，形成可审计证据，支持模型风险和合规审查；第三，提升模型上线后的稳定性，因为标签政策、数据覆盖和 segment quality 可监控；第四，缩短新产品、新渠道、新攻击模式下的迭代周期。与其不断换模型，不如把最稀缺的 SME 知识变成可版本化、可复用、可治理的标签资产。

---

14. 作品集表达

14.1 Portfolio case structure

# Case Study: Data-Centric AI LabelOps for Financial Retail

## Business Problem
KYC / AML / complaints / fraud 场景中标签质量不稳定，导致模型效果、运营分流和审计证据不足。

## Product Goal
建立 programmatic labeling 平台，把 SME 知识、规则、历史证据和弱监督信号转成可版本化标签资产。

## Architecture
Source systems -> canonical sample -> evidence extractor -> LF runtime -> label matrix -> label model -> SME review -> dataset registry -> release gate -> monitoring.

## Key Product Decisions
- 弱标签不直接触发高影响客户动作
- 每个标签必须有 policy、evidence 和 owner
- conflict 和 low coverage 被视为产品信号
- release gate 以质量指标和审计证据为核心

## Metrics
- label coverage
- precision and recall on gold set
- conflict rate
- segment coverage
- SME review overturn rate
- downstream model lift
- operational routing improvement

## Governance
用 NIST AI RMF 的 Govern / Map / Measure / Manage 映射 label policy、SME review、fairness coverage、audit evidence 和 release gate。

## Outcome Narrative
把 AI 项目从模型调参转向标签资产治理，使金融零售团队能够更快构建训练集、更清楚解释数据来源，并在高影响场景中保留人工和治理控制。

14.2 简历 bullet

Designed a data-centric AI LabelOps architecture for financial retail use cases, covering programmatic labeling, weak supervision, SME adjudication, label quality metrics, dataset versioning, audit evidence and release gates for KYC, AML, complaints and fraud typology workflows.

14.3 面试故事线

Situation:
模型效果不稳定，根因不是算法，而是标签定义、历史 proxy、低覆盖 segment 和 SME 裁决缺失。

Task:
建立一个可复用的标签生产和治理体系，支持多个金融零售 AI 场景。

Action:
设计 label ontology、label policy、LF registry、label matrix、generative label model、SME review queue、gold set、dataset card、quality dashboard 和 release gate。

Result:
让团队能解释每个标签的来源、证据、版本、质量和限制，并把数据中心型迭代纳入 AI 风险治理。

14.4 架构师表达

架构师不要只说“我们使用 Snorkel”。更高级的表达是：

我把 weak supervision 放在 LabelOps 控制平面里：
标签定义由 policy 管理，
专家知识由 LF 表达，
冲突由 label matrix 暴露，
质量由 gold set 和 segment metrics 度量，
上线由 release gate 控制，
审计由 evidence binder 支撑。

---

15. 关键结论

1. Programmatic labeling 是标签生产体系，不是批量规则脚本。
2. Weak supervision 的价值来自多个弱信号的组合、冲突暴露、质量估计和 SME 闭环。
3. Generative label model 能融合 noisy LF，但不能替代 gold set、SME review 和治理审批。
4. 金融零售标签必须有 evidence trail、版本、禁止用途和 release gate。
5. Label quality 要同时看 coverage、precision、recall、conflict、segment gaps 和 review overturn。
6. Data-centric AI 的高级 PM 能力，是把 SME 知识、政策、数据、模型和运营反馈组织成可复用的标签资产。
7. 作品集表达要从“我会标注数据”升级为“我能设计可审计、可治理、可迭代的 LabelOps 平台”。