RAG、向量检索与 GraphRAG

本页沿着“切分—表示—召回—重排—生成”的数据流，整理 RAG、ANN、HNSW、混合检索和 GraphRAG。

一、RAG、向量检索与 HNSW

1.1 RAG 的基本数据流

RAG（Retrieval-Augmented Generation）先从外部知识库检索相关内容，再把检索结果放入上下文，辅助 LLM 生成答案：

$$\text{文档}\stackrel{\text{Chunking}}{\to }\text{文档块}\stackrel{\text{Embedding}}{\to }\text{向量}\stackrel{\text{向量索引}}{\to }\text{候选文档}\stackrel{\text{Reranker}}{\to }\text{上下文}\stackrel{\text{LLM}}{\to }\text{答案}$$

文档切分的边界、overlap 和 Recursive Split 已在深度学习基础中的文档切分小节整理。这里重点关注向量表示、近似最近邻索引和检索质量之间的分工。

模块	主要职责	典型失败模式
Chunking	把长文档组织成可检索单元	语义被截断、块过大或过小
Embedding Model	把文本映射到语义向量空间	领域表达不匹配、相似度不能反映任务相关性
ANN Index	快速召回近似相邻向量	漏召回、延迟与内存取舍
Reranker	对少量候选重新精排	计算成本高、候选集已经漏掉正确答案
LLM	基于上下文组织最终答案	忽略证据、产生幻觉或违反输出约束

因此：

$$\text{Embedding}=\text{表示质量}\text{ANN}=\text{候选召回效率}\text{Reranker}=\text{候选精排}$$

1.2 精确搜索与 ANN

设向量库中有 $N$ 个 $d$ 维向量，查询向量为 $q$。精确搜索需要计算 $q$ 与所有向量的相似度：

$$\mathrm{sim}(q,x_1),\dots ,\mathrm{sim}(q,x_N)$$

其计算量随 $N$ 线性增长。ANN（Approximate Nearest Neighbor）索引通过图、树、量化或分区等结构减少需要实际比较的候选数量，以少量召回率损失换取更低延迟。

若精确搜索得到的 Top-$K$ 集合为 $T_K$，近似索引返回的集合为 ${\hat{T}}_K$，可以用：

$$\mathrm{Recall}@K=\frac{|T_K\cap {\hat{T}}_K|}{K}$$

衡量 ANN 漏掉了多少真实近邻。ANN 的目标通常是延迟、吞吐、内存与 Recall 之间的折中，而不是改变 Embedding 的语义空间。

1.3 HNSW 的工作原理

HNSW（Hierarchical Navigable Small World）是一种基于分层图的 ANN 索引。它为向量节点建立多层邻接关系：

• 高层节点较少，用于快速确定搜索的大致区域；
• 越往底层节点越密集，用于进行局部精细搜索；
• 查询从高层入口开始，逐层向下扩展候选。

因此 HNSW 不需要像 brute-force 那样遍历整个向量库，但也不保证一定返回精确最近邻。它解决的是“如何更快找到相近向量”，不会自动改善 Embedding 模型本身，也不会自动学习 query 和 document 的语义对齐关系。

查询时可以粗略理解为：

入口节点
  ↓
高层图：快速靠近查询向量
  ↓
中间层：扩大候选范围
  ↓
底层图：局部精细搜索
  ↓
返回近似 Top-K

1.4 HNSW 参数与工程取舍

不同实现的参数名称可能略有差异，但常见控制项包括：

参数	主要作用	增大后的典型影响
$M$	每个节点保留的邻接边数量	图索引内存和构建成本增加，通常有利于召回
$efConstruction$	建图时搜索和选择候选邻居的宽度	构建更慢，但图质量可能更好
$efSearch$	查询时维护的候选集合宽度	Recall 通常提高，但查询延迟和计算量增加

实际调参应以 Recall@K、P95/P99 延迟、吞吐量和索引内存共同衡量。HNSW 的图结构本身还会占用向量之外的内存；向量量化、压缩或二值化是另一类存储优化，不能当作 HNSW 的固有能力。

1.5 混合检索与 RAG 评估

对于技术文档、网络日志和故障案例，纯向量相似度可能忽略错误码、命令名、版本号和 IP 等精确字段；纯 BM25 又可能无法识别不同措辞表达的同一故障。因此常见方案是：

$$\text{BM25 精确召回}+\text{向量语义召回}\to \text{候选合并}\to \text{Reranker 精排}$$

RAG 评估也应拆成多个层次：

评估层	关注问题	常见指标或方法
检索召回	正确证据是否进入候选集	Recall@K、MRR、nDCG
精排质量	相关证据是否排在前面	MRR、nDCG、人工相关性标注
上下文利用	模型是否使用了检索证据	引用对齐、证据覆盖率、人工检查
最终答案	是否正确、完整、可追溯	Exact Match、任务指标、Judge、人工评审

HNSW 与其他优化手段的边界

HNSW 主要通过图结构减少查询时需要访问的候选数量；GQA、MQA 和 MLA 主要优化 Transformer 推理时的 KV Cache；向量量化主要减少向量存储和带宽；Reranker 则提升已经召回的候选排序质量。

它们分别作用于不同环节：

$$\text{模型表示}\to \text{向量存储}\to \text{候选召回}\to \text{候选精排}$$

优化其中一个环节，不能自动替代其他环节的能力。

1.6 GraphRAG：显式建模实体与关系

普通向量 RAG 主要根据 Query 与文本 chunk 的语义相似度召回内容：

$$\text{Query}\to \text{Similar Chunks}\to \text{LLM}$$

GraphRAG 则会从文档中抽取实体和关系，进行实体归一化，并把结果组织成图结构。查询时可以结合向量检索定位入口，再沿实体关系进行遍历、聚合或多跳推理：

$$\text{Query}\to \text{Entities / Relations}\to \text{Graph Traversal}\to \text{Context}\to \text{LLM}$$

典型处理流程包括：

文档
  ↓
实体与关系抽取
  ↓
跨文档实体归一化
  ↓
知识图谱或实体关系图
  ↓
关系遍历、路径查询或社区聚合
  ↓
组织证据并交给 LLM

GraphRAG 更适合以下任务：

• 需要跨多个事实进行多跳推理；
• 需要沿人物、公司、论文、产品或事件关系进行路径查询；
• 同一实体在不同文档中有多个名称，需要先做 Entity Resolution；
• 需要跨文档统计实体提及次数、关系数量或社区主题；
• 需要发现关系链、实体社区或全局主题，而不是只找局部相似段落。

例如，若图中有：

$$A\stackrel{\text{母亲}}{\to }B,C\stackrel{\text{父亲}}{\to }B$$

查询与 A、B 的亲属关系时，可以直接沿图中的实体和边进行推理。若多篇报道分别使用全名、简称和中文译名描述同一人物，系统还需要先建立：

$$\text{全名}=\text{简称}=\text{中文译名}$$

再对该实体的跨文档提及进行聚合。

但“数据中存在图结构”并不等于“任何查询都需要 GraphRAG”。如果任务只是根据研究方向找到语义相关的代表性论文，向量检索和排序可能已经足够；只有当查询要求利用引用路径、共同邻居、影响链或全局关系统计时，图结构才是问题本身的一部分。

查询需求	更合适的方案	原因
找与问题最相似的 FAQ 或段落	普通向量 RAG	主要是局部语义匹配
按错误码、命令名或关键词精确查找	BM25 或混合 RAG	结构化词项匹配更直接
沿人物、公司或论文关系进行多跳查询	GraphRAG	需要显式访问实体和边
统计多个文档中同一实体的全局提及	GraphRAG	需要实体归一化与跨文档聚合
语义召回后根据关系补充上下文	向量 RAG + GraphRAG	两种检索信号可以组合使用

因此，GraphRAG 的判断标准不是数据量大小，也不是数据是否天然可以画成图，而是查询是否需要显式利用实体、关系、多跳路径或全局聚合。

RAG 检索速记

Embedding 决定“表示得像不像”，HNSW 决定“近邻找得快不快”，Reranker 决定“候选排得准不准”；HNSW 用少量 Recall 损失换取检索效率，不会自动优化 Embedding。