返回 AICAP-180
B17 · Day 161outcome 指标仪表盘 + A/B

M7 outcome 指标定义

B17 是整条 B1→B18 能力曲线上「从能跑到能证明价值」的拐点。

阶段: B17 · outcome 指标仪表盘 + A/B（Day 161-170） 标签: #aml-outcomes #fincen-effectiveness #metrics-spec #amla

今日导引（由浅入深）

B17 是整条 B1→B18 能力曲线上「从能跑到能证明价值」的拐点。

前面 B1-B16 已经把 AML Copilot 的链路搭起来了：证据汇集 → 类型学比对 → SAR 草稿 → HITL → 治理一页纸。B16 还把可用性从主观吐槽量化成了任务成功率 Δ。

但所有这些都还在回答「模型/原型好不好用」，没回答更尖锐的那个问题——这套系统对执法到底有没有价值。

今天 Day 161 就是为整个 B17 block 立骨架：锁定 4 个 outcome 指标（FPR / SAR 质量 / cost-per-case / p95），写一份 metricsSpec.ts 规格，把每个指标的公式与数据源钉死。

最小可判定产出：一份 metricsSpec 设计稿 + 1 条对手算样本断言公式数值的单测。

1. 机理精读

outcome 指标 vs output 指标的本质区别。

output 指标回答「系统做了多少」——跑了多少案件、产了多少份 SAR、模型 benchmark 多少分。

outcome 指标回答「这些产出对下游目标产生了什么效果」。在 AML 语境里，下游目标是「对执法有价值」（value to law enforcement），不是「报告数量」。

一个一年报 10 万份 SAR 但 95% 是噪声的系统，output 极高、outcome 极低——它把执法资源淹没在误报里。这正是监管口径在 2025-2026 反复纠偏的方向。

为什么是这 4 个指标，而不是别的。

FinCEN 的 effectiveness rule 与 AMLA 的「value to law enforcement」要求把「SAR 数量」重述为四个可分别度量的效果维度：

  • 报得准不准 → FPR（误报率）：正常案件被误判为可疑的比例。FPR 高，合规团队就在无效告警上空转。
  • 报得好不好 → SAR 质量：narrative 是否完整、可溯源、用规范监管语言。examiner 会因叙述含糊而质询。
  • 报得贵不贵 → cost-per-case：单案件的 token×单价成本。决定这套 AI 方案的单位经济性。
  • 报得快不快 → p95：时延分布第 95 分位，反映尾部体验而非被均值掩盖的长尾。

这 4 个维度两两正交：准（质量错判）、好（叙述质量）、贵（成本）、快（时延），合起来就是一份 outcome 仪表盘的最小完整骨架。

为什么先写 spec、后写实现。

指标一旦上仪表盘并对外宣称，就有了「数字契约」效应——别人会拿它做决策。

所以公式必须先被冻结、被单测锁住，再去填真值，否则口径会在迭代中悄悄漂移。一个经典坑：FPR 的分母到底是「全部正常案件」还是「被系统触达的正常案件」？差之毫厘谬以千里。

metricsSpec.ts 的职责就是把「公式 + 数据源映射」写成代码可断言的规格，让一组手算样本能证明「实现确实算的是 spec 里那个公式」。

与相邻概念的边界。

这里定义的是「指标规格」，不是「指标真值」。

真值要等后续几天分别接：FPR（Day 162 金标）、SAR 质量（Day 163 rubric）、cost+p95（Day 164）、活仪表盘聚合（Day 165）才填进来。

今天只立公式与数据源映射，一个真实模型测量数字都不产生。

2. 推导 / 手算 / 代码走读

metricsSpec.ts 是本日新增文件——src/aml/observability/ 目录当前只有 attributeMap.ts（已读，124 行，OTel GenAI 语义约定属性映射层）。所以本日是「规格设计 + 手算样本单测」，不是对既有实现的代码走读。

下面把 4 指标公式与数据源映射逐条钉死，作为 spec 的内容：

  • FPR 公式：FPR = fp / (fp + tn)。

    • 数据源映射：fp/tn 来自独立金标 labels（agent-evals/labels），预测来自规则引擎或 LLM。
    • spec 应直接复用 src/aml/groundTruthEval.ts 的 binaryEval——其内 fpr: fp + tn ? fp / (fp + tn) : 0 与该公式完全一致，不要另写一份。

  • SAR 质量公式：quality = Σ(weight_d × score_d)，四维加权均值。

    • 维度：completeness / factual_faithfulness / typology_citation / regulatory_language。
    • 数据源映射：维度分来自 src/aml/sarQualityRubric.ts 的 SAR_RUBRIC 权重 + judge/code-check 打分；聚合用 weightedScore()（权重和 RUBRIC_WEIGHT_SUM ≈ 1）。

  • cost-per-case 公式：cost = (inputTokens + outputTokens) × unitPrice / caseCount。

    • 数据源映射：token 数从 trace（attributeMap.ts 的 USAGE_INPUT_TOKENS/USAGE_OUTPUT_TOKENS），单价从 OpenRouter（DeepSeek-V4-Flash/Pro）。

  • p95 公式：时延样本排序后取第 95 分位。

    • 数据源映射：直接复用 src/agent/eval/stats.ts 的 summarizeLatency（已 built+tested，返回 p50/p95/p99/mean）。

手算单测样本（固定值，非模型测量）：

p95 样本：取 5 个时延样本 [100, 200, 300, 400, 500] ms。

按 percentile(sorted, 95)：

  1. idx = 0.95 × (5−1) = 3.8
  2. lo = 3, hi = 4, w = 0.8
  3. 结果 = sorted[3]×(1−w) + sorted[4]×w = 400×0.2 + 500×0.8 = 480

单测断言 spec 引用的 p95 实现返回 480。

FPR 样本：金标 [normal, normal, normal, structuring]，预测 [structuring, normal, normal, structuring]。

逐条：normal/structuring→fp；normal/normal→tn；normal/normal→tn；structuring/structuring→tp。得 fp=1, tn=2 → FPR = 1/3 ≈ 0.333。

这些都是手算固定值，用于证明公式接线正确，不是模型跑出来的真值。

3. 今日实战

  1. 在 src/aml/observability/ 下新建 metricsSpec.ts，导出一个 4 指标规格对象（每项含：指标 id、公式说明、数据源映射、引用的既有实现函数名）。
  2. FPR 项映射到 groundTruthEval.ts 的 binaryEval/binaryEvalWithCI。
  3. SAR 质量项映射到 sarQualityRubric.ts 的 weightedScore + SAR_RUBRIC。
  4. cost 项映射到 token×单价；p95 项映射到 stats.ts 的 summarizeLatency。
  5. 写 1 条公式单测：用上面的手算样本（p95=480、FPR≈0.333）断言 spec 引用的实现数值对得上。
  6. 跑 pnpm test 验证公式单测通过。

4. 今日实测 / 产出

  • metricsSpec 设计稿 + 1 条公式单测 = 本日产出（规格 + 手算断言）。
  • observability/ 目录现仅有 attributeMap.ts；metricsSpec.ts 为本日新增的规格文件——待落地后跑 pnpm test 验公式。
  • 公式样本数为手算固定值，非模型测量数。
  • 本日不产生任何真实模型测量数字。

5. 常见误区 / 陷阱

  • 把 spec 写成实现：spec 该引用既有纯函数（binaryEval/summarizeLatency/weightedScore），不要在 metricsSpec.ts 里重写一份公式——双份实现必然漂移。
  • FPR 分母搞错：必须是 fp/(fp+tn)（正常案件里被误报的比例），不是 fp/总数。
  • 用 output 思维填指标：别把「产了多少 SAR」当 outcome——effectiveness rule 已明确否定「SAR 数量越多越好」。
  • 手算样本当真值对外：手算固定值只证明接线正确，不能拿去宣称「我们 FPR=0.333」。

6. 学习资源（每条带 YYYY-MM）

  • FinCEN AML/CFT National Priorities / effectiveness rule 叙事（2026）——本日 4 指标骨架的监管依据。
  • FinCEN SAR Narrative 指引 / FFIEC BSA/AML 手册 Appendix L「SAR 质量指引」（2003-11 监管底稿；2026 审查口径「质量优于数量」）。
  • AMLA「value to law enforcement」要求（AMLA 2025 起逐步生效）。
  • Anthropic「Demystifying evals」outcome vs output 评测方法论（2026-01）。
  • 本仓代码：src/aml/groundTruthEval.ts / src/aml/sarQualityRubric.ts / src/agent/eval/stats.ts（公式实现底座）。

SOTA检查 (2026-06 更新)

  • 当前主流：FinCEN effectiveness rule + AMLA「value to law enforcement」叙事仍是 2026 的 AML outcome 主线，AMLA 自 2025 起逐步生效，仍 SOTA。
  • 过时黑名单：避免用「SAR 数量越多越好」这种已被 effectiveness rule 取代的旧 KPI 叙事；不要把 output 计数当 outcome。
  • 下次复查点：2026-08-02 EU AI Act Art.50 透明度义务生效点，需复查 outcome 指标里的披露/透明度要求是否要新增维度。AMLA 配套技术标准（RTS/ITS）发布节奏需按季复查。

衔接

  • 昨天：Day 160 — 一次量化迭代 + 复测（B16 收尾：把可用性改前/改后 Δ 量化）。
  • 今天：把「系统有没有价值」拆成 FPR/SAR 质量/cost-per-case/p95 四个 outcome 指标，写成可单测的 metricsSpec 规格。
  • 明天：Day 162 — M7 FPR 与 normalFalsePositiveRate（修复循环自评，改用独立金标算 FPR）。
上一篇 · Day 160
一次量化迭代 + 复测
下一篇 · Day 162
M7 FPR 与 normalFalsePositiveRate