Grounding 选型指南：向量索引、知识图谱、语义层，到底该用哪个

这是「吴恩达 AI 工程技能地图深挖」系列的第 ③ 篇，对应地图第 2 格「用数据为模型提供依据（Grounding）」。总纲：20 格自测与 12 周落地路线｜上一篇：编程智能体 SOP

吴恩达在 Part 2 给这一格列了一张"菜单"：

用 RAG + 向量搜索只是早期尝试，给模型提供依据的技术集合已经大幅增长。比如，你必须决定什么写进 prompt、什么让 LLM 用工具按需检索，以及哪种表示方式更契合你的数据与查询——向量索引、知识图谱，还是结构化数据的语义层。

"RAG 只是早期尝试"这句话，是这一格最容易被忽略的部分。2023 年的默认答案（切块 + 向量检索）在今天只是一条分支。这篇把它整理成两级决策：先决定要不要检索，再决定用哪种表示。

一、第一级决策：要不要检索？

1.1 一个明确的分界线：20 万 token

Anthropic 在 Contextual Retrieval 那篇文章里给了一条少见的、可执行的经验法则：

如果你的知识库小于 200,000 token（约 500 页内容），可以直接把整个知识库放进 prompt，不需要 RAG。

配合 prompt caching（缓存常用前缀），这条路线的代价被压得很低：延迟降低 2 倍以上，成本最多降低 90%。

所以第一级决策的顺序应该反过来问：

问题	如果答案是"是"	做法
知识库 < 200k token？	直接全量塞 prompt + 缓存	不要为了"像 RAG"而搭 RAG
知识库大得多，或内容频繁变化？	需要检索	进入第二级决策
需要最新数据、只有运行时才知道要什么？	需要工具化按需检索	让模型自己决定取什么

1.2 第二级同时要考虑的另一个问题：预计算还是即时取

Anthropic 把这两种风格分开讲得很清楚：

预计算检索（embedding-based pre-inference retrieval）：提前把数据向量化，推理时按相似度取。快，但对动态内容容易"索引过期"。
即时检索（just-in-time）：Agent 只持有轻量标识符（文件路径、查询语句、链接），运行时用工具动态加载。它不是"记住全部资料"，而是像人一样依赖文件系统、书签、收件箱来按需调取。

后者带来一个重要的副产品：渐进式披露（progressive disclosure）。文件大小暗示复杂度、命名约定暗示用途、时间戳是相关性的代理——Agent 逐层搭建理解，只把必要内容留在工作记忆里。

现实中更常见的是混合策略。Claude Code 的做法是典型：CLAUDE.md 这类信息直接塞进上下文，而 glob、grep 这类原语让它即时导航文件系统，从而绕开"索引过期"和"语法树复杂"两个坑。

一句话原则：内容稳定 → 预计算；内容动态 → 即时取；两者都有 → 混合。

二、第二级决策：三种表示，各治一种病

如果确定要检索，接下来要选"数据的表示方式"。这里最有效的思路不是选"最好的"，而是按病症选药。

先把三个概念分层摆清楚（业界常见的一种划分）：

层	回答的问题	本质
上下文层（Context Layer）	模型此刻需要知道什么？	运行时组装：向量检索 + 图遍历 + 结构化查询
语义层（Semantic Layer）	这些数据意味着什么？	持久化的业务定义：指标、维度、实体、关系
知识图谱（Knowledge Graph）	东西之间怎么连接？	实体（节点）+ 有类型的关系（边）+ 属性

2.1 向量索引：治"模糊召回"

它擅长：非结构化文本上的语义相似匹配。用户问"如何申请退款"，能召回写着"退费流程说明"的段落。

它会漏的地方：精确字符串。Anthropic 给的例子非常典型——用户查 "Error code TS-999" 时，embedding 可能找到一堆"关于错误码"的内容，却漏掉那个精确的 TS-999。

处方：向量 + BM25 混合检索。BM25 基于词法匹配（TF-IDF 的改进，考虑文档长度并对词频做饱和处理），专治唯一标识符、技术术语这类精确匹配需求。两者用排名融合（rank fusion）合并后再去重。

另一个更隐蔽的病：切块把上下文切没了。原文的例子——某块内容是"公司营收环比增长 3%"，但没说是哪家公司、哪个季度，检索和使用都会出问题。

处方：Contextual Retrieval。在 embedding 之前，用模型为每个 chunk 生成一段 50–100 token 的"定位说明"，拼接到 chunk 前面，再建 embedding 与 BM25 索引：

原文块：     "The company's revenue grew by 3% over the previous quarter."
上下文块：   "本块来自 ACME 公司 2023 年 Q2 的 SEC 文件；上一季度营收为 3.14 亿美元。
             公司营收环比增长 3%。"

2.2 知识图谱：治"关系与可追溯"

它擅长：答案是"实体 + 关系"的问题，比如"A 公司给谁供货""这个人还关联了哪些主体""这条异常交易链路怎么走的"。向量检索只能做相似度，跟不了多跳关系。

它的成本：建模、维护、实体消歧（entity resolution）都需要真功夫；对纯文本模糊召回不如向量。

常见误区：以为"上了图谱就能推理"。图谱提供的是结构的可追溯路径，推理仍要靠模型。

2.3 语义层：治"模型乱猜口径"

这是最容易被工程团队忽略、但在数据密集型应用里收益最大的一层。

它的作用很具体：当模型需要查询数据库时，没有语义层，它只能从表名和列名猜含义——这是幻觉与错误取数的标准配方。有了语义层，user_id 不再是一个列，而是"客户"实体上的一个属性，lifetime_value 有明确的定义与计算口径。

与技能地图的呼应：吴恩达把这一格描述为"在向量索引、知识图谱、结构化数据的语义层之间选型"。对大多数企业内部系统来说，第三项往往才是真正的瓶颈——不是模型不懂检索，而是没人把口径写清楚。

2.4 三者不是选择题，而是层次

一个更成熟的看法是：知识图谱存世界模型，语义层定义它的意义，上下文层在推理时取用其中一片。 三者构成技术栈，而不是三个竞品。

至于要不要"用一套系统实现三层"，则是一个工程取舍：

拼装多个专用系统（图库 + 向量库 + 关系库 + 语义层工具）的优点是在各自主场更强、故障隔离更好；代价是同步问题、四套查询语言、四份故障模式，以及应用侧合并结果的延迟与一致性成本。
多模型单引擎把风险从"集成税"换成"爆炸半径"——一个集群问题会同时影响图、向量与关系负载。

这个选择没有标准答案，但必须显式做：先算清楚"运行/同步/合并四种系统的总成本"是否值得。

三、收益是可量化的：一张值得背下来的数据表

Anthropic 在多个知识域（代码库、小说、arXiv 论文、科学论文）、多种 embedding 与检索策略下做过实验，结论如下（指标为"前 20 块检索失败率"，即 1 − recall@20）：

配置	检索失败率	相对基线
基线（普通向量检索）	5.7%	—
+ Contextual Embeddings	3.7%	−35%
+ Contextual Embeddings + BM25	2.9%	−49%
+ 上述 + Rerank	1.9%	−67%

另外几条同样重要的结论：

收益可叠加：上下文 embedding + 上下文 BM25 + 重排 + 取 top-20，是实验中最优组合。
top-20 优于 top-10，也优于 top-5。多给一些块能提高相关信息被包含的概率——当然，信息越多也越可能干扰模型（见第四节）。
BM25 总是好过"只用 embedding"。
成本可控：以 800 token 的块、8k token 文档、每块约 100 token 上下文估算，生成上下文块的一次性成本约 $1.02 / 百万文档 token（依赖 prompt caching）。
四个实现细节：chunk 大小/边界/重叠会影响效果；不同 embedding 模型收益不同（实验中 Voyage 与 Gemini 表现较好）；上下文生成 prompt 可按领域定制（如附术语表）；"始终跑 evals"——把上下文块与原文块做区分后交给模型，效果可能更好。

注意：这组数据来自 Anthropic 自研方法与其选定的数据集，不能当成"通用提升幅度"。它真正的价值是告诉你改进的方向有优先级：先做上下文化，再补词法检索，最后加重排。

四、别只盯着"检索"：上下文是有限资源

这一格另一个常被忽略的事实：放进上下文的东西太多，模型会变笨。

Anthropic 用 "context rot"（上下文腐化）描述这个现象：随着上下文里 token 数增加，模型准确召回其中信息的能力会下降。原因是架构性的——注意力机制下 n 个 token 有 n² 对关系，序列变长，捕捉能力被摊薄。所以：

好的上下文工程 = 找到最小的一组高信号 token，最大化期望结果出现的概率。

由此推出几条实用判断：

"最短"不等于"最好"：最小必要集合可能并不短，但必须没有冗余。系统提示应处在"恰好合适的高度"——一端是硬编码的脆弱 if-else，另一端是含糊到无法执行的泛泛而谈。
工具要少而清晰：最常见的失败模式是"工具集臃肿、功能重叠"，连人都说不清该用哪个工具时，Agent 更判断不了。
少样本示例要挑选，而不是堆砌：给一组多样、典型的规范示例，好过罗列所有边界情况。
长任务的三件套（当任务跨越分钟到小时级）：
1. 压缩（compaction）：接近窗口上限时摘要历史，保留架构决策、未解决的 bug、实现细节，丢弃冗余的工具输出；配套的"最轻量压缩"是清除旧的工具结果；
2. 结构化笔记（structured note-taking）：把笔记写到上下文之外（如 NOTES.md、待办清单），需要时再读回——这是让 Agent 跨几十次工具调用保持连贯的关键；
3. 子智能体架构：让子 Agent 各自用干净的窗口做深度探索（可能消耗数万 token），只把 1000–2000 token 的浓缩结论返回主 Agent。

五、一张可以抄的选型决策树

Q1 知识库 < 200k token（约 500 页）？
   └─ 是 → 全量塞 prompt + prompt caching，结束。
   └─ 否 → 进入 Q2

Q2 数据以什么形态存在？
   ├─ 大量非结构化文本 → 向量检索
   │    ├─ 有唯一标识符 / 专有名词 / 代码串 → 必须加 BM25（混合检索）
   │    └─ 切块后丢上下文 → 加 Contextual Retrieval
   ├─ 实体与关系是答案的核心 → 知识图谱（可与向量并用）
   └─ 结构化表/指标要被模型安全访问 → 语义层（定义先行）

Q3 什么时候取？
   ├─ 内容稳定 → 预计算索引
   ├─ 内容动态 / 只有运行时才知道要什么 → 让 Agent 用工具即时取
   └─ 两者都有 → 混合（稳定部分直接进上下文，其余按需）

Q4 还有什么收尾动作？
   ├─ 加 Rerank（top-150 → top-20）
   ├─ 控制注入总量（注意 context rot）
   └─ 建评测：检索失败率与端到端表现都要测（见系列第 ① 篇）

六、三个常见错误

把"检索"当目的。200k token 以下的知识库直接塞 prompt 就够了，硬搭一套检索管线只是徒增故障面。
只用向量检索。忽略 BM25、忽略重排、忽略切块导致的上下文丢失——这三项恰好是有明确数据支撑的三个改进点。
只优化检索，不优化"注入什么"。检索到 20 个块不等于应该把 20 个块都塞进上下文；也别忘了给模型一套"少而清晰"的工具，而不是把所有能力都堆上去。

七、小结

两级决策：先问"要不要检索"（20 万 token 分界线），再问"用什么表示"。
三种表示治三种病：向量治模糊召回（但需配 BM25 与上下文化）、图谱治关系与可追溯、语义层治口径不清。
收益有优先级：上下文化 → 加词法检索 → 加重排，失败率 5.7% → 1.9%。
上下文是有限资源：context rot 真实存在，"最小的高信号 token 集合"是唯一标准，长任务用压缩/笔记/子智能体三件套。
最后一句来自 Anthropic 的实践建议，也适合当作这一格的收尾："做能跑通的最简单的事。"

下一篇离开技术层，进入地图的最后一格，也是最容易被组织结构卡住的一格：塑造构建——当工程师被要求"主动定义该做什么"时，现实里到底缺什么。

参考来源

Andrew Ng, The AI Engineering Skills Map Part 2 — AI Applications，2026-08-21（第 2 格定义与"RAG 只是早期尝试"的判断）
Anthropic Engineering, Contextual Retrieval in AI Systems（200k token 阈值、prompt caching 成本、−35%/−49%/−67% 数据、top-20 结论、$1.02/百万 token 上下文化成本、四个实现注意事项）
Anthropic Engineering, Effective context engineering for AI agents（context rot 与注意力预算、just-in-time 检索与渐进式披露、混合策略与 CLAUDE.md、压缩/结构化笔记/子智能体三件套、工具集臃肿的失败模式）
SurrealDB, Context layers, semantic layers, and knowledge graphs: the modern data architecture for AI（三层定义与分层关系、拼装式栈的四种同步成本、单引擎的爆炸半径权衡）
本站：总纲：20 格自测与 12 周落地路线｜Evals 实操手册｜编程智能体 SOP

说明：第五节的决策树与第六节的常见错误为本站基于上述来源整理的整合建议，非任何一方原文表述；Anthropic 的实验数据来自其自研方法在特定数据集上的测量结果，不应外推为通用提升幅度。