缓冲 + 长文#1 定稿 + P1 主线 SOTA 复查

日期: 2026-07-11 阶段: Phase 1 - 产品定义×评测×可观测底座 标签: #longform #sota-recheck #evals #honesty-discipline

核心问题

P1 的最后一篇日间笔记要做两件事：(1) 给长文#1《从 recall@k 原型到生产级 evals》定稿——把 P1 散落的方法论（Day 3 evals、Day 4 错误分析、Day 26 失败归因、W4 tracing）压成一条有本项目真实数字支撑的演进叙事，而不是综述；(2) 在动笔前做一次 P1 主线资料全量 SOTA 复查——semconv 是否转 stable、Langfuse 收购后是否仍开源、Hamel/Shreya 方法论与 judge 范式是否被替代。复查不是仪式，它直接决定长文里哪些句子要改：若 semconv 已 stable，Day 3/Day 4 里「保留独立属性映射层」的设计前提就动摇了。

本篇的隐性命题是写作中的诚实纪律：长文要展示「规则基线在 66 案金标上 recall 1.0」，但这串数字若不带限定语就是阶1 诚信止血要消灭的那类夸大——满分 = 口径一致性，非性能。长文如何在「展示作品」与「不夸大」之间走钢丝，是本篇要钉死的方法。

关键内容

A. P1 主线资料全量复核方法（怎么查，不是查了没）

复核不能凭「我记得」，要按固定四问对每条主线资料过一遍：(1) 一手原文是否有新版本/日期更新？(2) 状态字段（experimental/stable、开源/闭源、在售/停服）是否变化？(3) 是否出现替代品使其不再 SOTA？(4) 本项目据其做的设计决策是否因变化而需调整？第四问是关键——复查的产出不是「资料还在」，而是「设计要不要改」。本次复查结论汇总：

复查踩坑：semconv 的「stable 与否」不是一个布尔值。整体 spec 仍标 Development，但 client spans 这一子集早 2026 已退出 experimental——若只查首页 status 字段会误判「全部 experimental」，若只看新闻标题「client spans stable」会误判「全部 stable」。正确口径是按 sub-component 分别记：client span 部分可直采，agent span / MCP 仍须保留映射层。这正是 Day 4 设计映射层时的判断在 2026-07 依然成立的原因。

B. 长文#1 的论证骨架（带本项目真实数字的演进，非综述）

长文标题《从 recall@k 原型到生产级 evals：一个 AML copilot 的尺子是怎么长出来的》。论证不是「介绍 evals 的种类」，而是一条有先后、有因果、有数字的演进线：

阶段0（现状·已入仓）
  src/agent/eval/retrievalGolden.ts + runRetrievalEval.ts
  → recall@k 框架；23 条 golden，query 内嵌 slug
  → 自承局限（文件头 HONESTY NOTE）：slug 内嵌 = 结构/词法匹配，非语义检索
  → 这是「尺子的雏形」：能跑、能进 CI，但量的是 BM25 对文件名的命中，不是语义

      │ 局限驱动 ↓ 「为什么 recall@k 不够」
      ▼
阶段1（三类 evals·Day 3）
  代码型检查（确定性、零方差、便宜） + LLM-judge（语义、四段式 rubric） + 人工抽检（兜底）
  → AML 侧落地：typology recall 用代码型（标签可比对）；SAR 质量用 judge；可提交性用人工
  → 真实数字（src/aml/evalBaseline.ts 实测）：
       structuring/layering/mule_network recall = 1.00（n=18/15/15）
       normal FPR = 0.0556（1/18，刻意保留的 1 个 FP）

      │ 「满分意味着什么」→ C 节诚实纪律
      ▼
阶段2（CI gate·Day 3/W3）
  eval = CI/CD 质量门（Braintrust 范式）：低于门槛阻断 merge
  → 升级自现有非阻断跑法；门槛 recall≥0.85 已 +0.15 余量，FPR≤0.15 已余 0.094
  → eval 在 LLM 代码之前就位 = 「先建尺子」命题的物证

      │ 「构建期质量门有了，生产呢」
      ▼
阶段3（可观测·Day 26/W4）
  OTel GenAI semconv（client span 可直采 / agent span 留映射层） + Langfuse 自托管
  → $/案件成本聚合用 gen_ai.usage.*_tokens；失败归因面板按工具/幻觉/上下文三桶折叠
  → recall@k 的结构匹配局限，由归因面板的「上下文污染桶占比」侧面暴露

四阶段的因果链是骨架本身：每一阶段的局限驱动下一阶段。综述会平铺「evals 有 A/B/C 类」，长文则讲「为什么这个项目从 recall@k 走到了三类 evals 再走到 CI 再走到可观测」——演进的动力学才是叙事价值。本项目真实数字（23 golden、recall 1.0、FPR 5.56%、门槛余量）贯穿全文，使其区别于任何二手综述。

C. 写作中的诚实纪律（满分 = 口径一致性，非性能）

长文最大的诚信风险点是 B 节阶段1 那串 recall 1.0。诚实纪律要求每次展示这串数字都强制携带三条限定语，缺一即触发阶1 诚信止血定义的「夸大」：

1. 它不是性能声明，是口径一致性声明。src/aml/generator.ts（生成器）与 src/aml/typology.ts（规则引擎）出自同一人之手、共享同一窗口语义（10 天窗 ≡ 跨度 ≤9）。recall 1.0 主要证明「数据定义与规则定义对齐、无 off-by-one」，外推到真实数据毫无依据。
2. 唯一的 FP 是设计出来的，不是规则犯的错——它把 FPR 钉在非平凡值（5.56%）上，并给 P3 的 LLM 版留下明确超越点（规则分不清商户营业款与拆分）。
3. 基线满分使「扩集」从可选变必要。v1 金标上 LLM 最多打平，判别力为零——所以 P3 扩集（≥100 案、含贴线案件与叠加类型学）是让对比有判别力的逻辑前提，不是任务清单上的可选项。

诚实纪律的反直觉点：诚实增强而非削弱作品说服力。一份敢写「我的满分只证明口径对齐、不证明性能」的作品集，向招聘方展示的恰恰是稀缺的 eval 判断力——区分「指标好看」与「指标有意义」正是 OpenAI CPO 口中「PM 最重要技能」（2025-08）的实操体现。把限定语删掉省下的两行字，换来的是把自己暴露成「不懂 eval 口径陷阱的人」。

设计要点/决策表

对本项目的落地

• 长文落盘：长文#1 写入 docs/aipa/longform/ 并接 learn track（体例同 src/data/aipa-posts.ts + app/learn/aipa/），骨架严格按 B 节四阶段；阶段0 直接引 src/agent/eval/retrievalGolden.ts 文件头的 HONESTY NOTE 原文作为「自承局限」的物证。
• 数字单一真相源：长文所有 eval 数字必须引自 evalRuleBaseline(getGoldenDataset()) 的实测输出（src/aml/evalBaseline.ts），不得手抄——避免数字漂移；门槛值另列且标「设计假设」。
• 复查回写：本次四问复查结论回写 docs/daily/AIPA_PROGRESS.md 的 P1 行 SOTA✓ 列；semconv「client span 退 experimental」这一变化需在 Day 3/Day 4 笔记的 SOTA 检查段补一行交叉引用（不改正文设计，映射层决策仍成立）。
• 诚实纪律入审查清单：把 C 节四行「危险/诚实」对照表抽成一条 PR/文案自查项——任何展示 src/aml/ eval 数字的页面（含未来作品集首页、/aml-copilot 演示页）发布前过一遍，禁止出现左列写法。
• 失败归因接续：Day 26 的三桶归因面板是阶段3 的核心组件，长文阶段3 直接引其「上下文污染桶占比侧面暴露 recall@k 结构匹配局限」作为 recall@k → 生产可观测的闭环论据。

参考资料

• OpenTelemetry GenAI semantic conventions（官方 spec，整体 Development）+ Inside the LLM Call: GenAI Observability with OpenTelemetry（opentelemetry.io blog, 2026）：内容捕获默认关 opt-in；gen_ai.request.model/usage.input_tokens/usage.output_tokens/response.finish_reasons/input.messages
• How OpenTelemetry Traces LLM Calls, Agent Reasoning, and MCP Tools — Greptime（2026-05-09）：GenAI 与 MCP semconv 仍 development
• ClickHouse welcomes Langfuse — ClickHouse 官方博客（2026-01-16）：$400M D 轮收购，MIT 开源不变、自托管路线不变；Orrick / SiliconANGLE 同口径（2026-01）
• Hamel Husain & Shreya Shankar — LLM Evals: Everything You Need to Know（hamel.dev FAQ, 2026-01-15）；Why AI evals are the hottest new skill（Lenny's, 2025-09）：错误分析→开放编码→轴向编码→judge→代码型检查；「先看 trace 再写 judge」
• Aman Khan —「Evals are the new PRDs」/三类 evals/四段式 judge（Aakash Gupta AI PM Crash Course, 2025-06 发布 / 2026-04 更新）
• OpenAI CPO —「PM 最重要的技能是写 evals」（2025-08）
• 本仓物证：src/agent/eval/retrievalGolden.ts（HONESTY NOTE）、src/aml/evalBaseline.ts（recall/FPR 实测）

SOTA 检查 (2026-06-11)

• semconv 整体仍 Development，client spans 已退出 experimental（早 2026）；agent span / MCP semconv 仍 development（Greptime 2026-05-09）。设计含义：成本聚合用的 gen_ai.usage.*_tokens（client span 维度）可直采，agent 维度埋点保留独立映射层——Day 3/Day 4 的映射层决策在 2026-07 仍成立，但理由从「全部 experimental」收窄为「agent span 仍 development」。
• Langfuse 开源承诺经收购仍成立：ClickHouse 2026-01 收购后 MIT 开源、自托管、路线均不变（官方博客 + Orrick 法务确认）——「开源自托管首选」叙事更稳，无需更换观测后端候选。
• Hamel/Shreya 方法论无替代：2026-01-15 新 FAQ 巩固其地位；judge 范式仍在但约束加强（Shreya 2026 课堂：直接 dump trace 给 LLM 会漏 nuance）——本项目「judge 先校准、人工抽检兜底」决策被进一步背书。
• 过时认知警示：(1) 不可再说「semconv 全部 experimental」——client span 已稳定，须按子组件分述；(2) 不可裸展示 recall 1.0——必带「口径一致性、非性能」限定语，这是阶1 诚信止血的硬线。
• 待跟踪：semconv agent span / MCP 的 stable 时间表（官方称「无公开时间线」）——P2 开工（07-28）前复查，若 agent span 转 stable 则可拆除映射层、简化埋点；τ²-bench pass^k（2025-06，2026-04 更新 38 模型）作为 P2 agent 可靠性指标的候选，复查其是否仍为 SOTA agent 评测基准。