07 · 评测与反馈闭环 · 落地方案
07 · 评测与反馈闭环 · 落地方案
对应蓝图 §8。本文解决：如何度量知识体系的效果？如何从失败中持续改进？
状态：草案（E2.3 / E3.2 / E3.3 / E4.2 / E5.2 / E6.2 / E7.1 待确认）
前置依赖：05-知识检索与引用（审计日志，须先补 §2.3 所列反馈埋点字段）· 04-知识存储（
chunk_ref内容寻址）关联文档：06-知识维护与治理（边际价值）· 02-知识验证（冲突检测）· 08-约束执行（工程基线数据来源）· 09-度量评价与落地路径（评测体系排在 P2）
1. 定位与边界
评测与反馈闭环是知识库的"质量仪表盘"：它不生产知识，也不直接改进知识，但它决定哪些知识值得保留、哪些改进方向最有价值。
与 06 的分工：06 通过边际价值评估"这条知识是否值得维护"，本文通过评测集评估"这套知识体系整体是否有效"。
与 05 的分工：05 §9.3 提供审计日志原始数据，本文将其加工为可度量的指标与可归因的改进信号。
数据源缺口（阻塞项）：05 §9.3 与蓝图 §6.6.3 定义的审计字段为
trace_id/actor/query_text/permission_set/retrieved_chunks/filtered_out_count/generated_claims/rejected_claims/refusal/latency_breakdown/index_version/degradation_flags——其中没有「点踩」「重复追问」「转人工」「人工纠正」「代码回滚」「人工介入时长」任何一项。而 §2.3 六步流水线的全部输入信号、§2.4 的成本类指标、06 §2.4 边际价值的「命中有效率」都依赖它们。因此本文所有涉及这些信号的指标均标注**「需新增埋点」**，且埋点是本文的 P0 前置条件而非可选优化。已在 05 §9.3 增补的字段：
user_feedback（thumbs_down/repeat_ask/escalate/manual_correction/rollback）与human_in_loop_ms。采集点在 MCP Server 侧还是 IDE/CLI 侧属待决策项（E7.1），因为它决定了能否覆盖「不经过 MCP 的本地交互」。唯一不需要新增埋点的项是「条目命中次数 / 引用次数」（可由
retrieved_chunks与generated_claims直接统计）。原表述「数据源已存在，无需新增埋点」只对这一项成立，不得推广到整个反馈闭环。
2. 核心设计决策
2.1 四层失败归因
蓝图 §8.1 定义四层失败类型，归因顺序是串行的：必须先排除上一层，才能归因到下一层。
| 类型 | 诊断问题 | 判定方法 |
|---|---|---|
| Retrieval Failure | 正确证据是否进入 Top-K | 金标集比对：expected_citations 是否出现在检索结果 |
| Generation Failure | 证据正确但答案是否错误 | 证据已在 Top-K，但输出的 claim 与证据矛盾或未被证据支持 |
| Business Understanding Failure | 是否误解术语、角色、版本或约束 | 证据正确、答案表面通顺，但违反了 05 §6 受控术语表、06 §2.1 版本裁决或适用范围 |
| Execution Failure | 代码、测试或工具操作是否错误 | 知识正确传达，但生成的代码/命令/工具调用不通过编译、测试或 08 §3.1 Hook 校验 |
归因纪律：
- 若正确证据未进 Top-K，即使答案也错，也只记 Retrieval Failure（避免一次检索失败被重复计入多类，导致改进优先级误判）。
- 同一样例允许记录一个主归因 + 多个次归因，统计改进收益时只按主归因计数。
2.2 评测集体系：八类样例
蓝图 §8.2 给出初期 100–300 条样例的八类划分：
| 类别 | 用途 | 样例来源 |
|---|---|---|
| 固定金标集 | 基准回归 | 双人独立标注（§3.1） |
| 线上失败集 | 真实场景补强 | 05 §9.3 审计日志中的点踩/返工事件 |
| 权限和越权集 | 验证 05 §9.1 权限过滤 | 构造越权 query，验证拒答 |
| 精确标识符集 | 验证 Exact 通道 | 含类名/方法名/配置 Key 的 query |
| 新旧版本冲突集 | 验证 06 §2.1 版本裁决 | 同一主张在不同 source_revision 下答案不同 |
| 无答案和拒答集 | 验证 05 §8 拒答规则 | 知识库无相关条目时的 query |
| 多跳影响分析集 | 验证 06 §3.4 影响分析 | 跨模块依赖链的 query |
| AI Coding 规则集 | 验证 08 §2.3 四件套中的机器规则 | 触发 ArchUnit / Lint 的代码生成 |
样例 Schema：
query: # 用户问题原文
expected_intent: # 期望业务意图（枚举，见下）
# 注意：不是 §2.1 的失败归因四层。归因层级由评测运行时判定，
# 不得在标注阶段预填——否则等于把结论写进输入，§2.1 的串行互斥纪律失效
authorized_scope: # 期望授权范围（classification）
reference_contexts: # 期望引用的 chunk_ref 列表
expected_answer_or_rubric: # 期望答案或评分细则
knowledge_versions: # 期望命中的知识版本（source_revision）
expected_citations: # 期望输出的 evidence_id 列表
expected_action: # 期望生成的代码/命令（可选）
risk_level: # 风险等级（P0/P1/P2）expected_intent 的取值枚举（业务意图，与失败归因四层无关）：identifier_lookup（精确标识符查询）/ concept（概念解释）/ howto（操作步骤）/ impact_analysis（影响面分析）/ no_answer（知识库应拒答）。
2.3 反馈闭环：六步流水线
各环节自动化程度：
| 步骤 | 自动化程度 | 实施方 | 说明 |
|---|---|---|---|
| 脱敏 | 自动 + 人工抽检 | 正则 + NER | 识别敏感实体（密钥/Token/PII）并替换。正则 + NER 的召回率不可能为 100%，「全自动」等于漏检即入库，而本步产物会回流金标集（§2.3 第 6 步），造成敏感数据二次扩散。故必须配：抽检比例（待实测）、漏检即回收并标记 desensitization_failed、责任人（平台组）。脱敏后样本继承原始审计日志的密级（05 §9.3 纪律 3「日志本身有密级」），不因脱敏而降密 |
| 聚类和去重 | 全自动 | 向量相似度 + 主题聚类 | 相似度 > 0.9 视为重复。0.9 属阈值待实测，且必须注明用哪个 embedding 模型、在什么粒度上比较（chunk / 整条反馈）——同一阈值在不同粒度下含义完全不同 |
| 四层失败归因 | 半自动 | AI 提议 + Owner 确认 | AI 给出主归因 + 次归因建议，Owner 审核 |
| 修知识/索引/规则 | 半自动 | AI 草稿 + Owner 审批 | AI 生成修复建议，Owner 走 03 审核流程 |
| 加入动态回归集 | 全自动 | 归因确认后自动入库 | 进入 §2.2 八类评测集对应类别 |
| 退出动态回归集 | 半自动 | 系统提议 + Owner 确认 | 原设计只有入库没有出库。§2.3 第 4 步是「AI 提议 + Owner 确认」的半自动归因，必然有错判；错判样本一旦进入回归集就会永久污染它，而回归集又是 §2.5 的硬门禁依据 → 合法变更被长期阻断。退出条件：对应知识条目 deprecated、归因被推翻、连续 N 次与金标集结论冲突。责任人：Steward，季度复审 |
| 知识边际价值评估 | 半自动 | 系统统计 + Owner 判断 | 06 §2.4 模型输入 |
2.4 工程基线指标
蓝图 §8.4 明确不预设 AI Coding 提升百分比，先建立工程基线。12 项基线指标：
| 类别 | 指标 | 数据来源 | 依据 |
|---|---|---|---|
| 质量 | 首次 CI 通过率 | 02 §4.1 知识类 CI 门禁 + 项目既有代码 CI | 蓝图 §8.4 |
| 质量 | 契约测试通过率 | 06 §3.2 契约变更工具链 + 08 §2.4 required_tests | 蓝图 §8.4 |
| 质量 | Review 缺陷数 | 代码 Review 平台（MR 评论数 / 缺陷标签），不是 03 | 蓝图 §8.4 |
| 质量 | 人工重写比例 | AI 输出快照 vs 人工修改后 diff，口径见 §2.4.1 | 蓝图 §8.4 |
| 稳定性 | Review 后提交轮次 | MR 迭代次数 | 自定义 |
| 稳定性 | 缺陷逃逸率 | 上线后缺陷数 / 总缺陷数 | 自定义 |
| 稳定性 | Deployment Rework Rate | 需要重新部署或回滚的部署次数 / 总部署次数 | DORA（以部署为单位，不是 MR） |
| 吞吐 | 首个可评审 MR 耗时 | 从任务开始到首次提 MR 的时间 | 自定义 |
| 吞吐 | Time to Merge | MR 创建到合并的时间 | 自定义 |
| 时效 | Change Lead Time | 首次 commit → 生产部署 | DORA 官方口径 |
| 时效 | Feature Lead Time | 需求提出 → 上线 | 自定义（不得挂 DORA 名） |
| 成本 | 每个成功任务的人类介入时间 | 审计日志 human_in_loop_ms（需新增埋点，见 §1） | 蓝图 §8.4 |
| 成本 | 每个成功任务的模型成本 | LLM 调用 token 数 × 单价 | 蓝图 §8.4 |
三处口径更正说明：
- 「Review 缺陷数」的数据来源不可能是 03：03 §4.1 的五维清单是知识条目审核标准，而该指标度量的是代码 Review 缺陷，两者不是一回事。原文把 03 §4.1（CODEOWNERS 配置）当作数据来源属双重错配。
- Change Lead Time 的 DORA 口径是 commit → production deployment，不是「需求提出 → 上线」（后者是 feature/flow lead time）。两者差值可能很大，混用会让「时效」类指标失去横向可比性。
- 「回滚率」不是 DORA 指标，且原表以 MR 为单位。DORA 的对应项是 Change fail rate 与 Deployment rework rate，均以部署为单位。已替换为 Deployment Rework Rate。
- 分类错位更正：原表把「缺陷逃逸率、回滚率、Review 后提交轮次」归入「效率」。按 DORA 的 throughput / instability 划分，它们属稳定性/质量，与效率方向相反——把它们算作效率会在报表上产生「稳定性变差但效率变好」的误导。
为什么「不预设提升百分比」是刻意设计：公开复盘确实报告了产出规模数字（例：OpenAI "Harness Engineering"，openai.com/index/harness-engineering/，2026-02 发布；第三方转载称约 5 个月 / 约 100 万行 / 约 1500 PR，该组数字本文不作为依据引用，仅说明此类外部数字存在）。但这些数字来自特定团队、特定代码库、特定时间窗，把外部数字抄成本团队的验收线，等于用一个无法验证的承诺替代基线测量。
2.4.1 人工重写比例的可计算口径
原文只写「代码 diff 与 AI 输出的文本相似度」，但该值无法直接计算：必须在人工修改前持久化 AI 原始输出快照，而 08 §3.1 的 Hook 设计里没有这一项。08 §4 与 09 §2.7.2 都把口径挂到「07 §3.1」，而 §3.1 是金标集标注流程，全文没有定义该口径——这是一个在三份文档间循环推诿的空指标。现定义如下：
| 要素 | 规定 |
|---|---|
| 快照采集点 | IDE/CLI 侧 Hook（PostToolUse 后落盘），这是 08 §3.1 必须新增的 Hook |
| 快照存放与保留期 | 与审计日志同存储、同密级、同保留期（05 §9.3 纪律 3/4） |
| 相似度算法 | 行级 diff + 归一化编辑距离（不用 AST 级，因为跨语言成本过高；不用 token 级，因为对格式变更过敏） |
| 「大幅修改」阈值 | 归一化编辑距离 > 30% 记为大幅修改。阈值待实测 |
| 责任人 | 平台组 |
2.5 回归集门禁分级
蓝图 §8.5.4 明确不对所有变更设硬门禁（过严等于没有），按变更类型分级：
| 变更类型 | 回归集角色 | 理由 |
|---|---|---|
| 检索参数调整（k、Top-K、rerank 阈值） | 硬门禁，不通过不得合并 | 直接影响 Recall@K，且可快速验证 |
| Embedding 模型升级 | 硬门禁 + 双索引对比（04 §5.6） | 影响全量向量，回滚成本高 |
| 切分策略变更 | 硬门禁 | 影响 chunk_hash 与全部引用可解析性 |
| 单条知识内容修订 | 软门禁，失败仅告警 | 单条变更影响面小，硬门禁会拖慢知识更新 |
| 知识条目新增 | 软门禁：跑受影响域的金标子集，Recall@K 下降超阈值则告警并要求 Owner 确认 | 原表述「新增不影响既有召回」在检索原理上不成立：新增 chunk 会直接进入 Top-K 竞争（可能把原本正确的证据挤出窗口）、改变 BM25 的 IDF 统计、改变 RRF 名次，因此必然可能改变既有金标样例的 Recall@K。「除非引入重复」只覆盖其中一种情形，而重复拦截与召回位移是两类不同风险，须分别处置。用「回归集存在的理由」论证「不需要回归集」构成循环论证 |
2.6 离线评测与线上 A/B 分工
| 维度 | 离线评测集 | 线上 A/B |
|---|---|---|
| 能回答 | 检索与引用的正确性是否退化 | 用户实际是否更愿意采纳 |
| 不能回答 | 用户真实满意度、采纳率 | 为什么退化（须回到离线归因） |
| 成本 | 低，可每次合并运行 | 高，需流量与周期 |
| 使用时机 | 全部检索/索引/模型变更 | 重大架构变更、判官校准后的指标验证 |
关键纪律：线上指标（点踩率、返工率、人工介入时长）与离线指标（Recall@K、Faithfulness）不可互相替代。离线全绿但线上点踩率上升，说明评测集分布已偏离真实查询——此时应重新采样 query（§3.1 第 1 条），而不是继续调参。
3. 实施细节
3.1 金标集标注流程
四条纪律：
- query 必须来自真实场景，不得由开发者凭想象编写。想象的 query 分布与线上分布差异极大，用它调出的参数在线上无效。
- 标注「期望证据」而非「期望答案文本」。答案文本会随模型与知识修订变化，证据引用（
chunk_ref）相对稳定。这也是 05 §7.1 采用内容寻址的直接受益方——若evidence_id用 chunk 序号，每次重新切分都会让金标集作废。 - 不可裁决的 query 必须丢弃并记录原因。强行保留会让评测结果长期噪声化。歧义原因本身是知识缺口的信号，应回流到 §2.3 反馈闭环。
- 知识变更后触发重标：被引用条目
deprecated或source_revision变更时，相关金标样例进入复审队列，否则评测集会静默过期。
3.2 标注一致性度量
双人标注必须量化一致性，否则「一致」只是主观判断：
| 标注对象 | 一致性指标 | 说明 |
|---|---|---|
| 期望证据集合 | Krippendorff's Alpha（MASI 或 Jaccard 距离） | 这是集合型（多标签）标注，不是类别型。Cohen's Kappa 只适用于恰好 2 名标注者 + 单一名义标签，直接用于集合型数据无定义。若必须用 Kappa，须先按候选 chunk 逐项二值化再计算 |
| 归因层级（§2.1 四层） | 仅对主归因计算 Cohen's Kappa；次归因用 Alpha + 集合距离单独统计 | §2.1 允许「1 个主归因 + N 个次归因」，标注结果是集合型而非单一互斥类别，对整体直接算 Kappa 与 §2.1 的设计不自洽 |
| 答案质量评分 | 加权 Kappa 或 ICC | 有序等级评分，需加权 |
标注者人数与指标选择必须匹配：§3.1 引入「第三人仲裁」后标注者为 3 名，Cohen's Kappa 已不适用（它只定义在 2 名标注者上），须改用 Fleiss' Kappa 或统一用 Krippendorff's Alpha。本方案统一用 Alpha，避免同一份数据混用两种系数。
Kappa / Alpha 低于阈值时，先修标注指南再重标，不得直接进入仲裁。指南不清导致的分歧会持续产生，仲裁成本远高于重写指南。
初始参考区间（来自方法学惯例，正式门槛仍须实测）：Cohen's Kappa 0.61–0.80 视为可接受、> 0.80 良好；Krippendorff's Alpha ≥ 0.80 可用、0.667–0.80 须说明理由。
小样本与类别不平衡陷阱：§2.2 的评测集初期只有 100–300 条、分八类，单类可能只有十几条。Kappa 在样本量小、类别极不平衡（prevalence problem）时估计极不稳定，同一批数据换个分布就能从 0.4 跳到 0.9。因此必须同时报告 PABAK 或分类别一致率，并规定每类最小标注样本量，否则「达标 / 不达标」的判定本身不可信。
3.3 LLM-as-Judge 的偏差控制
蓝图 §8.5.3 列出五类偏差及控制手段：
| 偏差 | 表现 | 控制手段 |
|---|---|---|
| 位置偏差 | 倾向选择靠前/靠后的候选 | 交换顺序各评一次，结果不一致则记为「判官不确定」 |
| 长度偏差 | 倾向认为更长的答案更好 | 评分维度中显式排除长度；提供等长对照样例 |
| 自我偏好 | 倾向认可同族模型生成的内容 | 判官模型与生成模型不同族 |
| 权威腔偏差 | 措辞自信即判为正确 | 判官只看「claim 是否被 evidence 支持」，不评措辞 |
| 格式偏差 | 结构化输出得分偏高 | 评分规则中固定格式权重为零 |
判官必须先通过人工一致性校准：取一批已有人工标注的样例，计算判官与人工的一致性（按 §3.2 用 Krippendorff's Alpha）。判官一致性未达标前，其产出的指标只能观测，不得作为门禁——这与蓝图附录「阈值待实测」的处置一致。
判官模型与 rubric 必须版本化，升级须重跑校准集：
| 要素 | 规定 | 理由 |
|---|---|---|
| 判官模型版本 | 锁定到具体版本号，写入每次评测 run 的元数据 | 判官升级会让历史指标不可比，不锁版本就无法判断指标变化来自知识改进还是判官漂移 |
| 判官 prompt / rubric | 与金标集同仓库版本管理，Owner 明确（平台组） | rubric 改动等同于换判官 |
| 升级流程 | 升级前在校准集上重跑，报告新旧判官的指标偏移量；偏移超阈值则重设基线并标注基线断点 | 否则月度环比（§4「基线改善趋势」）会出现无法归因的跳变 |
| 「判官不确定」比例 | 设上限（待实测）；超限则该批结果作废，先修 rubric | 位置偏差控制手段（交换顺序各评一次）会产生大量不确定样本，无上限则评测退化为抛硬币 |
| 不同族模型不可得时的降级 | 允许同族判官，但其结果只能观测，永久不得作为门禁 | §3.3 的自我偏好控制手段失效时，不能假装它仍然有效 |
3.4 实施步骤
| 步骤 | 优先级 | 内容 | 产出物 | 触发条件 | 责任人 | 失败处置 |
|---|---|---|---|---|---|---|
| S1 | P0 | 反馈埋点字段落地（user_feedback / human_in_loop_ms） | 05 §9.3 Schema 变更 + 采集端实现 | 05 S2（审计日志）完成 | 平台组 | 埋点未落地则 §2.3 整条流水线与 §2.4 成本类指标全部无数据源，不得启动 S4 |
| S2 | P0 | AI 输出快照 Hook + 返工口径实现 | 08 §3.1 新增 Hook + §2.4.1 口径脚本 | S1 | 平台组 | 同上 |
| S3 | P0 | 工程基线采集与看板 | 12 项基线指标的采集脚本 + 看板 | S1、S2 | 平台组 | 09 §3.1 已把「工程基线采集与看板」列为 P0 建设项 |
| S4 | P1 | 权限和越权集建集 | ≥ 10 条越权样例 | S1 | 平台组 + 安全 | 09 §2.7.1 的越权门禁不可判定 |
| S5 | P2 | 金标集标注（双人独立 + 第三人仲裁） | ≥ 30 条金标样例（09 §3.3 已把它列为 P2 的前置行） | 业务专家时间到位 | 业务专家 + 平台组各 1 名 | 业务专家不可替代：期望证据的判定需要业务语义知识。仲裁人为第 3 名标注者，一致性统一按 §3.2 用 Alpha |
| S6 | P2 | 一致性度量与标注指南迭代 | Alpha 报告 + 指南修订记录 | S5 | 平台组 | Alpha 低于参考区间 → 修指南重标，不进仲裁 |
| S7 | P2 | 判官校准 + 版本锁定 | 校准报告 + 判官版本号 | S5、S6 | 平台组 | 未达标则判官结果只观测不门禁 |
| S8 | P2 | 回归集门禁接入 CI | 分级门禁 Job（§2.5） | S5、S7 | 平台组 | 见下「门禁执行细则」 |
| S9 | P2 | 反馈归因流水线上线 | §2.3 六步流水线 | S1–S3 | 平台组 + 各层 Owner | 归因 SLA 逾期升级至 Steward |
门禁执行细则（原文缺失）：
| 要素 | 规定 |
|---|---|
| 触发者 | §2.5 的三类硬门禁变更（检索参数 / Embedding 升级 / 切分策略）在 MR pipeline 触发；全量回归在 nightly 触发 |
| CI Job | 独立 Job，不与 02 §4.1 的知识校验混在一个 script（后者是秒级，前者是分钟级） |
| 运行时长预算 | 待实测；超预算则按域分片并行 |
| 索引快照 | 必须固定 index_version，否则同一 MR 重跑结果不可比 |
| 失败后的例外审批 | Owner + Steward 双签，例外记录写入 MR 并保留期限（待实测） |
4. 度量指标
| 指标 | 计算方式 | 目标 | 性质 |
|---|---|---|---|
| 反馈归因覆盖率 | 已归因反馈 / 总反馈数 | ≥ 80% | 阈值待实测 |
| 同类问题复发率 | 归因修复后同类问题再次出现的比例 | ≤ 5% | 阈值待实测 |
| 回归集通过率 | 每次版本迭代后回归测试的通过比例 | ≥ 95% | 阈值待实测（回归集自身规模须先达标，见 §2.5） |
| 基线改善趋势 | 各工程基线指标的月度环比 | 持续正向 | 趋势指标 |
5. 决策点清单
5.1 已确认决策
| 编号 | 决策点 | 选定方案 | 依据 |
|---|---|---|---|
| E1.1 | 失败归因是否分层 | 是，四层串行归因 | 蓝图 §8.1 |
| E1.2 | 归因顺序是否串行 | 是，先排除上一层再归因下一层 | 蓝图 §8.1 |
| E1.3 | 同一样例是否允许多归因 | 是，一个主归因 + 多个次归因，统计按主归因 | 蓝图 §8.1 |
| E2.1 | 评测集是否分类 | 是，八类样例 | 蓝图 §8.2 |
| E2.2 | 评测集规模 | 初期 100–300 条 | 蓝图 §8.2 |
| E3.1 | 反馈是否直接写回正式知识库 | 否，先归因审核再修复 | 蓝图 §8.3 |
| E4.1 | 是否预设 AI Coding 提升百分比 | 否，先建立工程基线 | 蓝图 §8.4 |
| E5.1 | 回归集是否对所有变更设硬门禁 | 否，按变更类型分级 | 蓝图 §8.5.4 |
| E6.1 | 离线评测与线上 A/B 是否互相替代 | 否，分工不同 | 蓝图 §8.5.5 |
5.2 待确认决策
| 编号 | 决策点 | 候选方案 | 建议 |
|---|---|---|---|
| E2.3 | 八类评测集的优先级 | A. 全部同步建设 / B. 先建金标集 + 线上失败集 + 拒答集 + 权限和越权集 | B（已修订）。原建议把「权限和越权集」排除在首批之外，与 09 §2.7.1 把「越权拦截」列为 P0 硬门禁直接矛盾——P0 门禁的度量输入正是这一类样例，不建集则该门禁在 P0 不可判定。二者必须择一，本方案选择把越权集提前 |
| E3.2 | 反馈归因的自动化程度 | A. 全人工 / B. AI 提议 + Owner 确认 / C. 全自动 | B，平衡效率与准确性 |
| E3.3 | 反馈闭环的 SLA | A. 7 天内完成归因 / B. 14 天内完成归因 | A，避免问题积压。7 天是起点值，非规范值——§6 已把「反馈归因的 SLA」列为待实测项，两处口径须一致 |
| E4.2 | 工程基线指标的数据采集频率 | A. 每日 / B. 每周 / C. 每月 | B，平衡粒度与成本 |
| E5.2 | 硬门禁的回归集规模下限 | A. 全量评测集 ≥ 100 条 / B. 从八类中分层抽取，每类 ≥ 10 条、合计 ≥ 80 条 | B（已修订）。原建议 A/B 都是「≥ 50 / ≥ 100 条」，但 E2.2 已定八类合计只有 100–300 条：若回归集下限取 100 条，回归集几乎等于全量评测集（八类分层失去意义），或建设初期根本无法达标 → 硬门禁形同虚设。此外原理由「统计显著性」没有给出任何计算依据（效应量、显著性水平、power 均未定义），已删除该理由，改为分层配额 |
| E6.2 | 线上 A/B 的最小流量 | A. 10% 流量 × 2 周 / B. 20% 流量 × 1 周 | A，降低风险。附带前置条件：05 §10.1 的 MCP 工具入参中没有实验 / 变体字段，须先确定分流键（按用户还是按会话）并改造接口。Agent 高频检索场景下若按用户分流，同一任务可能跨变体，评测结论不可用 |
| E7.1 | 反馈埋点的采集点 | A. MCP Server 侧 / B. IDE-CLI Hook 侧 / C. 两侧 | C。只在 MCP 侧采集会漏掉「不经过 MCP 的本地交互」（08 §3.1 的 SessionStart 预加载路径）；只在客户端采集则无法与 trace_id 关联 |
6. 待实测项
- Kappa / Krippendorff's Alpha 达标阈值（初始参考区间见 §3.2，正式门槛须实测）
- 每类样例的最小标注样本量与类别不平衡处置
- 判官与人工一致性的达标阈值
- 回归集规模与分层配额（与 E5.2 联动）
- A/B 所需流量与周期、分流键
- 反馈归因的 SLA（E3.3 的 7 天为起点值）
- 工程基线指标的数据采集频率
- 脱敏抽检比例与「大幅修改」阈值（§2.4.1）
- 聚类去重的相似度阈值与比较粒度
- 「判官不确定」比例上限
- 单次命中节省的人时（06 §2.4 边际价值的输入，两组对照实测）
7. 与其他文档的接口
| 接口方 | 接口内容 | 方向 |
|---|---|---|
| 02 知识验证 | 冲突检测准确率作为评测集的一类样例 | 02 → 本文 |
| 03 知识审核 | 审核通过率作为工程基线指标之一 | 03 → 本文 |
| 05 检索与引用 | 审计日志（retrieved_chunks、refusal、点踩）作为反馈数据源 | 05 → 本文 |
| 06 知识维护 | 边际价值评估作为反馈闭环的改进方向之一 | 06 ← 本文 |
| 04 知识存储 | §2.5 的两条硬门禁（Embedding 升级、切分策略变更）由 04 §5.6 双索引蓝绿切换承载；chunk_ref 内容寻址是金标集稳定的前提 | 04 → 本文 |
| 08 约束执行 | 一次 CI 通过率、返工率作为工程基线指标；08 §3.1 须新增 AI 输出快照 Hook（§2.4.1） | 08 ↔ 本文 |
| 09 度量与落地路径 | 金标集 / 判官校准 / 回归集门禁均为 P2 建设项；越权集因 P0 硬门禁提前至 P1（§3.4 S4） | 09 ← 本文 |