阶段 3 实践 — 召回对比与错误上下文注入

阶段 3 实践 — 召回对比与错误上下文注入

本实践的产出 ⭐ 最小产出：构造一次错误召回实验，观察错误上下文如何诱发错误答案 完整产出：检索通道对照 + 错误注入实验 + 可核验回答格式 + 本仓知识系统职责边界图

预计投入：5～7 小时。语料直接用本仓真实文档，不要用玩具数据——玩具数据看不出真实的失败模式。

实践 1 · 关键词检索 vs 向量检索对照

语料：从 产品文档/、代码逻辑/、wiki/concepts/ 各取 30～50 段，混成一个语料库。必须包含：

• 含三字码/航班号/订单号的段落
• 同一规则的新旧两个版本（时效冲突的素材）
• 措辞不同但语义相同的两段（同义素材）

查询集：15～20 条，覆盖四类：

记录表：

要看到的现象：

• 专有编号类查询，向量检索排名明显靠后
• 方向/否定类查询，两种通道都可能把错误但极相似的文档排到第一
• 混合 + 重排后，前两类改善明显，第三、四类改善有限——这是必须靠元数据过滤和 Query Rewrite 解决的部分

验收：能列出"三类必须靠检索之外手段解决的查询形态"，并给出各自的解法。

实践 2 · 错误召回注入（⭐ 必做）

这是本阶段最重要的一个实验，因为它演示的是 Agent 里最难被发现的一类故障。

做法：

1. 挑一个有确定答案的业务问题，例如某航线某舱位的退改规则。
2. 准备三种上下文：
   • A · 正确上下文：只放正确的那条规则
   • B · 错误上下文：放一条同航线但不同舱位的规则（相似度极高、业务上完全不同）
   • C · 冲突上下文：同时放新旧两个版本的规则，都不标注时间
3. 各跑 5 次，记录回答内容与模型的确信程度。

记录表：

要看到的现象（这三条现象是本实验的全部价值）：

• B 情况下，模型几乎不会说"这条规则可能不适用"，而是自信地照着错误上下文回答
• C 情况下，模型的选择不稳定——多跑几次可能给出不同版本
• 无论 B 还是 C，回答的语气和 A 一样自信

第二轮改进实验：给每段上下文加上 来源 与 生效时间 元数据，并在系统提示词里写"当上下文冲突时，以生效时间更晚的为准，并显式说明存在冲突"。重跑 C，看改善幅度。

验收：

• 能用一段话解释"为什么 RAG 让幻觉更难发现，而不是更少"
• 能给出至少三条上下文组装层面的防御措施（不是提示词层面的"不要编造"）

实践 3 · 可核验回答格式

设计一套知识问答的输出格式，并用实践 2 的三种上下文验证它。

格式要求（结构化输出，不是提示词约定）：

answer          结论，先说结论
citations[]     每条: source_id / quote / doc_time / relevance
confidence      high | medium | low
unknown_parts[] 明确列出未找到依据的子问题
conflicts[]     检测到的上下文冲突（若有）

验收：

• 在 B（错误上下文）下，confidence 是否下降？如果没有，说明置信度字段是装饰性的，需要重新设计判据
• 在 C（冲突上下文）下，conflicts 是否被填上？
• unknown_parts 是否会被滥用（什么都往里塞）？需要在描述里给出使用条件

置信度字段的常见陷阱 直接让模型自评"你有多确定"，结果通常没什么区分度。更有效的做法是把它拆成可判定的子问题：引用条数是否 ≥1？引用是否直接包含答案？是否存在冲突？文档时间是否在有效期内？——由这几个布尔量推出置信度，而不是让模型凭感觉打分。

实践 4 · 本仓知识系统职责边界图

任务：画一张图 + 一张决策表，回答"一个问题该问谁"。

涉及的系统（CLAUDE.md 里已定义，这里是把它内化）：

必须在图上表达的三件事：

1. 派生关系：哪个是从哪个编译/索引出来的
2. 升级路径：在派生层拿到结论后，要回到哪一层核对才能进 PRD
3. 时效风险：哪些层可能是旧的，旧多久

决策表：

验收：

• 能解释"为什么本地代码镜像的结论不能直接写进 PRD"
• 能解释 GBrain 里 vf-req-impl 源的 L3-检索推断 为什么必须先核对再引用
• 图能直接用作阶段 8 "Vault / Wiki / GBrain / Session Log / 模型上下文关系图"的底稿

这一实践的元价值 你正在用的这套知识库，本身就是一个完整的 RAG 系统 + 记忆系统。分析它比分析任何教科书案例都有效，因为你知道它每一层是怎么建起来的、在哪出过错。

自测

Related Documents

• 阶段 3 讲义
• 阶段 8 实践：知识边界地图
• 学习路线