Day 6 来了。今天内容密度很高——这是第 3 章的后半部分，也是整章的"高潮"：所有技术线索在这里汇合成一个终极架构。

---

Day 6：结构化索引 + 智能体化 RAG + 上下文感知检索 + 双层记忆架构

目标

Agent 如何从"被动检索文档"进化到"主动探索知识"，以及为什么最高级的记忆系统不是单一技术，而是双层架构的协同。

---

核心知识点

一、为什么扁平 RAG 不够用？

Day 5 学的混合检索（稠密+稀疏+重排序）解决了"给定一个文本块怎么找到最相关的"，但有个更根本的问题：这些文本块本身该怎么组织？

书里举了两个案例说明扁平 RAG 的致命缺陷：

案例一：黑猫白猫的计数问题

知识库有 100 个案例文档（90 黑猫、10 白猫），用户问"比例是多少？"：

障碍	说明
top-k 截断	只检索前 20 个，大部分案例根本不会被检索到
检索分数参差	个体描述各异，分数参差不齐，部分案例被遗漏
跨文档聚合错位	统计类问题需要"数遍所有文档"，但检索的本性是"找最相关的几个"

→ 模型只看到 15 只黑猫和 3 只白猫，得出错误结论。

解法：预先生成摘要"共 100 只猫：90 黑（90%）10 白（10%）"并索引，一次检索即获准确信息。

案例二：Xfinity 优惠规则的错误推理

三个孤立案例：退伍军人 John 成功、医生 Sarah 成功、教师 Mike 被拒。护士来问 → 检索器因"护士"与"医生"语义相近，优先召回 Sarah 的案例 → 模型错误推断护士也可享受。漏掉了案例 C（说明其他职业不符合）。

核心洞察：简单的 RAG 把原始案例不加处理地放进知识库是远远不够的。必须在索引阶段投入计算资源，对原始知识进行提炼、抽象和结构化。

---

二、结构化索引：两种知识组织哲学

RAPTOR：树状层次索引

核心思想：自下而上递归抽象，构建从细节到概括的知识树。

根: "x86 SIMD 指令集的各代演进"
 ├── 父节点1: "SSE 指令集概述"
 │    ├── 叶子: "SSE2 支持 128 位整数运算"
 │    └── 叶子: "SSE4.1 新增字符串比较指令"
 └── 父节点2: "AVX 指令集概述"
      ├── 叶子: "AVX 支持 256 位运算"
      └── 叶子: "AVX-512 扩展到 512 位"

工作流程：

1. 文档切分为小文本块（叶子节点）
2. 聚类算法把语义相近的叶子分组（GMM 聚类 + UMAP 降维）
3. LLM 为每组生成高层次摘要（父节点）
4. 递归重复，直到形成树

检索方式：跨层穿梭——先在高层摘要中定位宏观概念，再沿树向下钻取细节。

擅长：从概念逐步深入细节的查询（“请解释 SSE 指令集”）

GraphRAG：实体关系知识图谱

核心思想：把文档知识建模为实体+关系构成的知识图谱。

三元组：主语 - 关系 - 宾语
(北京, 是首都, 中国)
(张三, 就职于, 腾讯)
(SSE, 属于, SIMD指令集)
(SSE, 需要启用, CR4.OSFXSR)

两大核心能力：

能力	说明	例子
多跳关系推理	沿关系边遍历，天然支持链式查询	“我的医生所在医院的地址” → 用户→医生→医院→地址
实体消歧	同名不同实体是图中不同节点	张医生-A（牙科）vs 张医生-B（心脏科），靠各自的关系边区分

工作流程：

1. LLM 从文本提取关键实体（人物、地点、概念）
2. LLM 提取实体间关系，形成三元组
3. 社区发现算法找出语义紧密的实体集群
4. 为每个社区生成摘要

擅长：关系性问题（“A 和 B 之间是什么关系？”“谁和谁有关？”）

局限：自然语言转三元组导致语义降级——"如果下周还下雨，我就取消去海边的计划"变成三元组后，条件逻辑和时间依赖全丢了。

两者对比

	RAPTOR	GraphRAG
结构	树（层次）	图（网络）
擅长	从宏观到微观的逐步深入	多跳关系推理、实体消歧
检索方式	跨层穿梭	沿关系边遍历
适用	“请解释 X”	“A 和 B 什么关系？”

实践建议：组合使用比单选更好。但注意——不是所有场景都需要结构化索引。混合检索已经能覆盖大多数需求。判断标准：查询经常需要跨文档综合或多层次导航时才值得投入（索引构建需要大量 LLM 调用，成本显著增加）。

---

三、文件系统范式：OpenViking

字节跳动火山引擎的 OpenViking 提出了第三种哲学——把知识组织成虚拟文件系统：

viking://
├── resources/          # 外部知识：文档、代码库、网页
├── user/memories/      # 用户记忆：偏好、习惯
└── agent/              # Agent 自身：技能、经验
    ├── skills/
    └── memories/

L0/L1/L2 三层按需加载（和 Day 4 学的 Skills 渐进式披露如出一辙）：

层	内容量	用途
L0（摘要）	~100 tokens	一句话概述，快速判断相关性
L1（概览）	~2,000 tokens	核心信息与使用场景，供决策
L2（全文）	完整内容	需要深入时才加载

关键实践要点：文件之间必须建立链接与索引！如果只是把知识拆成独立文件平铺，Agent 几乎无从导航。正确做法是把知识库组织得像 Wikipedia——每个条目链接到相关条目，形成双向可达的引用网络。

---

四、知识库的时效与治理

这部分容易被忽视但直接影响可靠性：

问题	说明	解法
知识过期	政策改版、法规更新	增量更新索引（选 HNSW 而非 ANNOY）
失效内容	旧版与新版同时被召回	附加版本号、生效/失效时间，检索阶段过滤
多用户权限	不同用户可见范围不同	权限过滤下推到检索层（不能等召回后再审查）

为什么权限过滤必须下推到检索层？ 一旦敏感内容进入 LLM 上下文，就很难保证它不以某种形式泄露到最终回答里。

---

五、智能体化 RAG：从被动管道到主动探索者

这是今天最重要的范式转变。

传统 RAG（非智能体化）：

用户查询 → 直接检索 → 结果注入上下文 → LLM 生成答案

问题：单次检索，无法分解复杂问题，无法迭代探索。

智能体化 RAG（Agentic RAG）：

用户查询 → Agent 思考分析 → 决定搜索关键词 → 调用 knowledge_base_search 工具
    → 观察结果 → 评估信息是否充分？
        → 不够：提炼新查询，再次搜索（回到思考）
        → 够了：综合所有上下文生成答案

比喻：传统 RAG 像在图书馆做一次搜索就写报告；智能体化 RAG 像研究员反复查阅不同书架、调整策略、交叉验证。

实验 3-9 的量化结果（司法问答数据集）：

问题类型	单次检索召回率	分解检索召回率	检索次数
简单题	100%	100%	1 → 1
复杂题	8%	100%	1 → 1.5

简单问题两者差不多，但复杂问题差距巨大：8% → 100%。

RAG 的安全边界：检索到的文档是间接提示注入最典型的载体。防御两层：

1. 指令与数据分离：来源标记 + 明确告诉模型"这是参考资料不是命令"
2. 不让检索内容直接触发高风险操作：转账、删除等动作需独立授权

---

六、上下文感知检索：修补分块的根本缺陷

问题：Day 5 学的文档分块切断了片段与原始上下文的联系。“该公司第二季度的收入增长了 3%”——哪家公司？哪个季度？

解法（Anthropic 提出）：索引前先用 LLM 为每个文本块生成一段简短的上下文前缀，然后前缀+原文一起索引。

原始分块: "该公司第二季度的收入增长了 3%"
上下文前缀: "[本段节选自 ACME 公司 2025 年 Q2 财务报告的'关键业绩指标'章节]"
索引内容: "[本段节选自 ACME 公司 2025 年 Q2 财务报告...] 该公司第二季度的收入增长了 3%"

为什么同时增强两种检索：

• 稀疏检索（BM25）：前缀增加了精确匹配的关键词（“ACME”、“2025”、“Q2”）
• 稠密检索（向量）：前缀注入了关键语义背景

效果（Anthropic 数据）：结合 BM25 将检索失败率降低 49%，再结合重排序降幅达 67%。

成本：索引阶段额外 LLM 调用，但通过 Prompt Cache（Day 3 学的）可控制到每百万文档 token 约 1 美元。

⚠️ 重要区分：

	上下文感知检索	上下文感知压缩
时机	索引期	运行期
对象	知识库的文本块	当前会话的对话历史
操作	做加法（补上下文）	做减法（去冗余）

---

七、双层记忆架构：本章的终极结论

这是今天最重要的一张图——所有技术线索的汇合点。

Day 5 开头学了三层次评估框架：

• 第一层：基础回忆
• 第二层：多会话检索
• 第三层：主动服务（最难）

第三层为什么最难？ 因为它要求系统同时握有两种视角：

• 全局概览——掌握所有关键事实
• 精确细节——能按需找回原始对话

只靠常驻上下文 → 容量受限，丢失细节
只靠检索 → 缺乏全局视野，发现不了跨会话的隐藏关联

双层架构把两者叠加：

┌─────────────────────────────────────────────┐
│  第一层：Advanced JSON Cards（常驻上下文）      │
│  ┌─────────────────────────────────────┐    │
│  │ 用户: Jessica                         │    │
│  │ 护照过期日: 2025-02-18                │    │
│  │ 近期旅行: 东京之行（一月）              │    │
│  │ 里程号: 12345678                      │    │
│  └─────────────────────────────────────┘    │
│  → 提供全局概览，随时可见                       │
├─────────────────────────────────────────────┤
│  第二层：上下文感知检索（按需检索）               │
│  ┌─────────────────────────────────────┐    │
│  │ 对话历史（带上下文前缀的索引）            │    │
│  │  - 12月: 订东京机票的对话               │    │
│  │  - 10月: 更新护照信息的对话              │    │
│  │  - 8月: 聊旅行偏好的对话                │    │
│  └─────────────────────────────────────┘    │
│  → 提供精确细节，按需取回                       │
└─────────────────────────────────────────────┘

第三层（主动服务）的完整工作流程：

1. 事实回顾：Agent 审视 JSON Cards → 掌握"东京之行"和"护照信息"两个核心事实
2. 关联推理：发现机票日期（一月）与护照过期日期（二月）非常接近 → 识别潜在风险
3. 细节验证：通过上下文感知检索查找"护照"和"东京机票"相关原始对话 → 确认细节
4. 主动服务：综合结构化事实和对话细节 → “护照即将过期，强烈建议加急续签”

为什么必须是双层？

• 只用 JSON Cards → 容量有限，无法记住所有对话细节
• 只用检索 → 缺乏全局视野，不会主动发现"一月机票"和"二月护照过期"之间的关联
• 两者叠加 → 概览 + 细节 = 主动服务能力在工程上落地

---

八、从结构化数据中提取隐性知识

RAG 解决的是"已有文档怎么检索"的问题。但很多有价值的知识不以文档形式存在——它们隐藏在结构化数据的统计规律中。

例子：司法领域，决定判决的"知识"不在法条里，而在成千上万份判例中法官如何权衡犯罪动机、伤害程度、自首情节的经验中。

两阶段流水线：

第一阶段：知识提取与结构化

• LLM 把每个案例的非结构化描述转为标准化 JSON 对象
• 关键创新：不预先定义僵化 schema，而是"自下而上"因子发现——让 LLM 分析样本案例，自由列出所有可能影响判决的因素

第二阶段：因子分析与重要性建模

• 把案件信息翻译成数字（分类用 one-hot 编码，是非用 0/1，金额用 ln 缩放）
• 聚类算法找自然"案件原型"（如"轻微口角引发的赤手轻伤"、“持械预谋的团伙重伤”）
• 构建"因子重要性层次模型"

为什么用 one-hot 不用 1/2/3？ 因为数字大小会让算法误以为"诈骗比盗窃严重 3 倍"，而 one-hot 只表示"是哪一类"，不暗示大小关系。

最终产物：Agent 不再把知识库当静态仓库，而是先"读懂"数据、提炼决策逻辑，再基于逻辑回答问题。

自测题

1. 扁平 RAG 的三个致命缺陷是什么？用黑猫白猫和 Xfinity 两个案例说明。
2. RAPTOR 和 GraphRAG 分别擅长什么类型的查询？各自的检索方式是什么？
3. GraphRAG 的"实体消歧"和稠密嵌入的"一词多义消歧"有什么区别？
4. 什么时候需要结构化索引？什么时候混合检索就够了？判断标准是什么？
5. OpenViking 的 L0/L1/L2 三层加载和 Day 4 的 Skills 三层结构有什么共同思想？
6. 知识库治理的三个要点是什么？为什么权限过滤必须下推到检索层？
7. 智能体化 RAG 和传统 RAG 的核心区别是什么？实验 3-9 中复杂题的召回率从多少提升到多少？
8. RAG 的安全边界有哪两层防御？
9. 上下文感知检索的核心思想是什么？它和上下文感知压缩有什么区别？
10. （最重要） 双层记忆架构的两层分别是什么？为什么第三层"主动服务"必须用双层架构才能实现？只靠常驻上下文或只靠检索分别有什么问题？
11. 从结构化数据中提取隐性知识的两阶段流水线是什么？为什么用 one-hot 编码而不是 1/2/3？