第1章 · RAG与语义检索全景
文档摘要
第 1 章 · RAG与语义检索全景 章节摘要：大模型知道很多，但不知道你公司的内部文档、产品手册、客户工单。检索增强生成（RAG）就是解决"模型怎么用上我的私有知识"这件事。这一章从最朴素的向量 RAG 讲起，说清它在多跳推理和实体关系查询上为什么力不从心，再看知识图谱增强的 GraphRAG 如何补这块短板，最后落到工程上最实在的问题——向量数据库到底怎么选。读完你会对"我家的知识该用什么方式检索"有清晰判断。
第 1 章 · RAG与语义检索全景
章节摘要：大模型知道很多，但不知道你公司的内部文档、产品手册、客户工单。检索增强生成（RAG）就是解决"模型怎么用上我的私有知识"这件事。这一章从最朴素的向量 RAG 讲起，说清它在多跳推理和实体关系查询上为什么力不从心，再看知识图谱增强的 GraphRAG 如何补这块短板，最后落到工程上最实在的问题——向量数据库到底怎么选。读完你会对"我家的知识该用什么方式检索"有清晰判断。
核心问题
阅读完本章，你应当能够：
- 说清 RAG 的索引、检索、生成三个阶段各自做什么，以及每个阶段的常见坑
- 解释向量相似度检索在多跳推理、实体关系上的局限，并能举出一个具体例子
- 描述 GraphRAG 如何用知识图谱补足向量检索的短板，以及它的构建和维护成本
- 在 Pinecone、Weaviate、Milvus 等向量数据库之间，根据数据规模和延迟要求做出选型
- 设计一个混合检索方案，把稠密检索和稀疏检索的优势结合起来
核心概念速览
RAG 的生命周期可以拆成三段：索引、检索、生成。索引阶段把你的私有知识做两种处理——一种是切块后向量化，塞进向量数据库，靠的是"语义相近的文本在向量空间里离得也近"；另一种是从文档里抽出实体和关系，搭成知识图谱，靠的是"显式的关系网络能回答需要多跳才能推出的问题"。这两条路并不互斥，现实里往往是混合用的。
检索阶段拿到用户问题后，先把它向量化，再去库里找相似内容。但"相似"不等于"相关"——一句"我们公司的退货政策"和知识库里"商品退换货流程"语义相近能命中，可一旦问题变成"上个月退货量最多的三个品类"，向量检索就抓瞎了，因为它不擅长聚合、计数、多跳关联。这正是 GraphRAG 要补的缺口。生成阶段把检索到的片段塞进提示词，让大模型基于这些材料作答，理想情况下还要标注引用来源，便于核验。
RAG 的本质不是"搜一下再答"，而是"把模型的开放式接龙，约束到你的知识边界内"——检索质量直接决定回答质量。检索召回率上不去，模型再强也只能在错材料上发挥。
这里有个常被低估的环节：切块（chunking）。切得太粗，一个块里塞了多个主题，向量表示被稀释，检索精度下降；切得太细，上下文断裂，模型拿到的片段读不懂。实践中往往按语义边界（段落、标题）切，再叠加重叠窗口，没有一刀切的最优值，得拿自己的数据试。索引质量是地基，后面检索和生成再怎么调，也救不回一个稀烂的索引。
子章节导航
1.1 RAG基础与向量检索局限
从零讲 RAG 的标准流程，重点剖析向量检索在语义模糊、多跳推理、实体关系三个维度上的短板。比如"张三的主管的部门负责什么"这种两跳查询，纯向量检索几乎无能为力——它会找到很多提到"张三"或"部门"的块，却很难把两跳关系串起来。这节是理解后面为什么要引入图检索的前提。
1.2 GraphRAG知识图谱增强检索
把非结构化文档转成实体-关系网络，让模型能做多跳推理。这节讲实体抽取、关系抽取、图嵌入，以及 GraphRAG 相对向量 RAG 在复杂查询上的提升和代价。代价是实打实的：建图要跑额外的抽取模型，图的维护和更新比向量库麻烦得多，查询时还得在图上做遍历或子图检索，延迟和工程复杂度都上一个台阶。
1.3 向量数据库选型实战
落到工程选型。对比几种主流向量数据库在索引算法（HNSW、IVF 等）、部署方式（托管 SaaS vs 自建）、延迟、成本上的差异，给出"什么场景该用哪个"的判断框架。选型没有银弹——百万级向量自建 Milvus 性价比高，十亿级且要低延迟可能得考虑托管服务，小团队验证想法用 Pinecone 这种全托管最快上手。
1.4 混合检索与重排序工程实战
讲稠密向量加稀疏 BM25 的两路混合检索，以及 cross-encoder 重排序，给出一套可落地的参数调试顺序。混合检索的直觉是：向量擅长抓语义相似但会漏掉精确关键词匹配，BM25 恰好相反，两路召回再融合能显著提升覆盖率；重排序则用更重但更准的模型对候选集精排，把最相关的顶到前面。
子章节之间的逻辑关系
先建立"标准向量 RAG 长什么样、卡在哪"的基准（1.1），再看 GraphRAG 如何针对性地补短板（1.2），接着回到工程现实——无论用哪种检索，底层的存储和索引都得靠向量数据库（1.3），最后用混合检索加重排序把检索准确率再提一档（1.4）。
1.1 向量RAG基准 ──► 1.2 GraphRAG补强 ──► 1.3 数据库落地 ──► 1.4 混合检索重排 （看清局限） （图结构增强） （工程选型） （精度再提一档） │ │ │ │ └───────检索质量决定回答质量──────────────────────────────────┘
本章关键取舍速查
| 决策点 | 倾向方案 | 理由 |
|---|---|---|
| 知识以事实问答为主 | 向量 RAG | 语义相近即可命中，建索引便宜 |
| 知识涉及多跳关系、聚合统计 | GraphRAG 或图库混合 | 向量检索做不了两跳以上的关联 |
| 百万级向量、有运维能力 | 自建 Milvus | 性价比高，可控性强 |
| 十亿级向量、低延迟硬指标 | 托管服务 | 省去集群运维，SLA 有保障 |
| 召回率总差一口气 | 稠密+BM25 混合再加重排序 | 两路互补，重排用精度换延迟 |
⚠️ 常见坑：跳过检索质量评估直接调生成端。回答不好时先量召回率，材料都没检索对，换再强的模型也没用。
💡 关键直觉：RAG 系统的效果上限由检索决定，下限由生成兜底——先修上限，再修下限。
前置知识与后续延伸
- 前置知识：对大语言模型的基本用法有概念，知道 embedding（向量嵌入）是把文本变成高维数值的意思，会读 Python。
- 后续延伸：本章讲的是"怎么把知识喂给模型"。第 3 章会讲"怎么用提示词更好地激发模型用这些知识推理"，两者配合才能拿到最好的问答效果。