向量检索 on 纪伟的个人博客

RAG 进阶：从 naive 到 Agentic（2026）

Sun, 05 Apr 2026 10:00:00 +0800

写在前面

2024 年的 RAG “Hello World” 是这样的：把 PDF 切一切塞进向量库，查询时检索 top-K 喂给 LLM。当年够用，2026 年不够了——这套 naive 流程在生产里召回差、容易幻觉、答非所问。

这篇讲 RAG 怎么从 naive 进化到 production-grade：chunking、混合检索、reranking、GraphRAG，再到 2026 的 SOTA——Adaptive / Agentic RAG。地基是上一篇《向量检索入门：embedding、ANN 与向量库选型》讲的向量检索；这篇讲怎么把它用对。

这是 AI 分类的第二篇（第一篇是《Claude Code 使用指南》）。它和数据库分类的向量检索篇互为表里：那篇是"存储/检索原语"，这篇是"之上的应用范式"。

一、naive RAG 长什么样，为什么不够

经典三步：

1
2


离线: 文档 → 切块 → embedding → 存向量库
在线: 查询 → embedding → 向量检索 top-K → 拼进 prompt → LLM 生成答案

它的问题一针一线都在：

切得粗：固定大小切块会截断语义、切碎表格和代码，检索到的块缺上下文；
召回差：纯向量检索对精确词、专有名词、代码、数字反而不如关键词——“ERROR_0x80070005” 这种，向量相似没用，字面匹配才准；
幻觉：LLM 拿到不相关的上下文也硬编一通，没有"这个检索结果到底支不支持回答"的判断；
一律重型：不管查询是"公司成立于哪年"还是"你好"，都跑同一套检索+生成，浪费。

下面每一节都是在修其中一个洞。

二、chunking：第一道关

切块决定了"检索能召回什么"。固定大小（比如每 500 字符）是最朴素也最差的：

块太大 → 一个块塞了多个主题，检索时相似度被稀释，召回不准；
块太小 → 上下文断裂，“它指代什么"丢了，LLM 拿到片段也看不懂。

进阶做法：

语义切块：按句子/段落的语义边界切（用模型判断"这里是不是话题转折点”），而不是按字符数；
层次切块（parent-child）：检索用小子块（精准命中），但喂给 LLM 时返回它所属的大父块（保留完整上下文）。这是生产里最常用的一招；
带元数据：每个块附上标题、章节、来源、时间——检索时能按元数据过滤（“只在 2025 年的文档里找”）。

chunk 大小是 recall（怕漏）vs 噪声（怕混）的权衡，没有标准答案，要按你的文档和评估指标调。

三、混合检索（Hybrid Search）：向量 + 关键词

纯向量检索有个盲区：它擅长"意思像"，不擅长"字面就是"。代码、错误码、人名、型号、精确数字——这些你要的是字面匹配，向量相似反而会把"长得像的错误码"排前面。

于是混合检索：同时跑两路——

1
2
3
4


查询 ──┬── BM25 / 倒排（关键词路）──→ 召回 A
 └── 向量检索（语义路） ──→ 召回 B
 ↓
 RRF（Reciprocal Rank Fusion）融合排序

BM25 是《数据库系列（三）：索引原理》里倒排索引那套传统检索；向量检索是上一篇讲的语义检索。两路各自召回 top-K，再用 RRF（倒数排名融合） 把两个排名合成一个——取两者之长。这是 production RAG 的标配，纯向量检索在 2026 已经很少单独用了。

pgvector + PG 的全文检索、或者 Elasticsearch，都能在一个库里同时跑这两路。

四、reranking：检索分两阶段

为什么检索要分两阶段？因为"快+全"和"准"没法用一个模型兼顾：

召回阶段（要快、要全）：用 bi-encoder——查询和文档分别独立编码成向量，靠 ANN 飞速从百万文档里捞回 top-50。糙但快。
重排阶段（要准）：用 cross-encoder——把"查询 + 文档"作为一对一起喂进模型，输出一个精确的相关性分数。准但慢，所以只对召回的小集合（top-50）跑，重排出 top-5。

1
2


百万文档 ──bi-encoder + ANN──→ top-50 ──cross-encoder rerank──→ top-5 ──→ LLM
 (快，召回) (慢，精排)

典型 reranker：开源的 bge-reranker、Cohere Rerank。这一步对最终答案质量提升极大——召回里混进的不相关块，rerank 基本能剔掉。

五、GraphRAG：知识图谱加持

向量检索本质是"片段相似"。但有些问题是关系型的：

“A 公司的 CEO 之前在哪些公司任职？” —— 答案散在多份文档里，要靠"人→公司→职位"的关系串起来；
“X 和 Y 的区别？” —— 要把两个实体的属性拉出来对比。

这种多跳推理，纯向量检索（找相似片段）做不好。GraphRAG 的思路：离线时先把文档抽成知识图谱（实体 + 关系），检索时结合图遍历 + 向量——向量找入口实体，图遍历顺着关系找答案。

Neo4j 是这块的代表（把图数据库和向量检索结合）。GraphRAG 适合关系密集、需要跨文档推理的领域（医药、法律、尽调）；普通 FAQ 类 RAG 用不上，别为了用而用。

六、Adaptive / Agentic RAG：2026 的 SOTA

前面四节都是"管线固定、查询来了无脑跑一遍"的 RAG。2026 的前沿是把 RAG 变聪明——让系统自己决定怎么检索：

Adaptive RAG（查询路由）：加一个分类器，先判断查询复杂度，再路由到不同管线——
- 简单事实查询 → 直接向量检索一次就答；
- 复杂推理查询 → 多步检索 / 上 GraphRAG；
- 闲聊 / 不需要检索的 → 跳过检索直接答。
别对所有查询都跑重型管线，省算力、降延迟。
Self-RAG（自我反思）：LLM 在过程中自问三件事——“这个问题需要检索吗？““检索回来的相关吗？““我的回答有依据吗？"——不相关就重检索，没依据就拒答。自带质量门。
Agentic RAG：把 RAG 包成一个 Agent——能多次检索、能调工具（计算器、SQL、API）、能迭代优化答案，而不是一次性检索+生成。这是当前最前沿的形态，也是"让 agent 帮你干活"那个大方向里的具体一例。

这一节的演进方向很清楚：从固定管线到按需路由到自我反思到自主 Agent。复杂度和能力都在涨，但不是每个应用都需要 Agentic——多数企业 RAG 到 chunking + 混合检索 + rerank 就够好了。

七、生产化：评估与监控

RAG 上线后最头疼的是”怎么知道它好不好"。靠人肉看答案不靠谱，要有指标：

评估（离线）：用 RAGAS 这类框架打分——faithfulness（回答有没有依据，不幻觉）、answer relevance（答没答到点上）、context precision/recall（检索回来的东西有没有用）。改一处 chunking 或换一个 reranker，跑评估看分数升降。
监控（在线）：检索召回率、端到端延迟、幻觉率、用户反馈（👍👎）。出问题能定位是检索层还是生成层——这和《后端架构实战（七）：可观测性》的链路追踪是同一思路：给每次 RAG 调用一个 traceId，把检索、rerank、生成分段打 span。
增量更新：文档变了，别全量重建索引——按文档版本增量 re-embedding。

小结

naive RAG（切块→向量→生成）是起点，生产里召回差、易幻觉。
进阶三件套：chunking（语义/层次切块）+ 混合检索（BM25 + 向量 + RRF）+ reranking（bi-encoder 召回、cross-encoder 精排）。这是 production RAG 的标配。
GraphRAG：补"关系型/多跳推理"的洞，关系密集领域才用。
2026 SOTA：Adaptive RAG（查询路由）→ Self-RAG（自我反思）→ Agentic RAG（自主 Agent）。方向是让 RAG 从固定管线变聪明。
生产化：评估（RAGAS）+ 监控（traceId 贯穿检索/rerank/生成）+ 增量更新。

一句话：2026 的 RAG，“塞进向量库"只是地基；真正的功夫在 chunking、混合检索、rerank 和评估上。 地基（向量检索）上一篇讲过了，这篇是盖在上面的楼。

参考资料

All You Need to Know About RAG (in 2026)
20 Advanced RAG Types to Know in 2026 — Turing Post
Advanced RAG Techniques — StackAI
Advanced RAG Techniques — Neo4j（GraphRAG）
Advanced RAG Methods — Google Codelabs（chunking / reranking）
配套地基篇：《向量检索入门：embedding、ANN 与向量库选型（2026）》（本博客）

向量检索入门：embedding、ANN 与向量库选型（2026）

Sat, 28 Mar 2026 10:00:00 +0800

写在前面

传统搜索靠关键词（BM25 / 倒排索引），找的是字面匹配。但"怎么提高查询速度"这篇和"如何让 SQL 跑得更快"意思一样、用词不同——关键词检索抓不到这层关系。

语义检索要的是"意思匹配"，向量检索就是它的地基。这篇讲三件事：向量检索的原理（embedding / 相似度 / ANN）、2026 主流向量库怎么选、以及为什么大多数项目 pgvector 就够了。RAG 应用是下一篇的事。

这是数据库系列之外的一篇独立稿。它把"向量库"当作数据库的一个新分支——接在《数据库系列（十）：数据存储全景》里提到的 NoSQL 之后，向量库是这个时代最新的存储类型。

一、为什么需要向量检索

回顾一下传统检索：《数据库系列（三）：索引原理》讲过倒排索引——把文档分词，建"词 → 文档列表"的映射，搜的时候按词查。它快、它准，但它是词面匹配。

词面匹配的盲区：

1
2
3
4
5
6
7


查询: "怎么让接口更快"

 关键词检索: 找含"接口""更快"的文档
 → 找不到标题是"性能优化实战""降低延迟"的文档（虽然讲的是同一件事）

 语义检索: 找"意思相近"的文档
 → 能匹配上，因为它们在语义空间里离得近

向量检索补的就是这一块——按意思找，不是按字面找。它是搜索、推荐、RAG、去重、聚类这一整类应用的底座。

二、embedding：把内容变成向量

用 embedding 模型把文本（或图片、音频）映射成一个高维稠密向量，常见维度 768 / 1024 / 1536。关键是：语义相近的内容，向量在空间里离得近。

1
2
3


"如何提升性能" → [0.12, -0.45, 0.88, ..., 0.03] (1536 维)
"怎样让程序更快" → [0.11, -0.43, 0.85, ..., 0.05] ← 和上面很近
"今天的午餐" → [-0.67, 0.21, -0.10, ..., -0.92] ← 和上面很远

这一步把"语义"这种没法直接算的东西，变成了"向量距离"这种可以算的东西。模型是预训练好的（OpenAI 的 text-embedding、开源的 BGE / e5 系列），你只管把文本喂进去拿向量。

维度越高表达力越强，但存储和计算也越贵。1536 维 × 1000 万条 = 几十 GB，量级感先有。

三、相似度：怎么算"有多近"

把"两段内容有多像"变成"两个向量有多近"，常用三种：

余弦相似度：看两个向量的夹角，忽略长度。最常用于语义检索（只关心方向像不像）。
点积：夹角 × 长度。当向量都归一化后，点积 = 余弦。
L2 距离（欧氏）：直线距离。对绝对位置敏感。

语义检索绝大多数用余弦或点积。道理很简单：归一化后，“方向相近"就是"语义相近”。

四、为什么精确 KNN 不行，ANN 登场

最朴素的找最近邻：和库里每个向量算距离，排序取前 K。这叫精确 KNN，复杂度 O(N × d)。

1000 万条 × 1536 维 = 每次查询 150 亿次乘加。完全不可行。

于是有了 ANN（Approximate Nearest Neighbor，近似最近邻）——用空间索引结构，牺牲一点 recall（召回率）换几个数量级的加速。主流两种：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


HNSW（分层小世界图）—— 当前主流首选
 · 把向量建成分层导航图
 · 查询：从顶层粗筛 → 逐层下沉到底层精修
 · 优点：查询快、recall 高
 · 代价：内存大（要存整张图），构建慢

IVF（倒排文件）+ PQ（乘积量化）—— 超大规模用
 · 先把向量空间聚成 N 个簇（质心），查询只扫最近的几个簇
 · 配合 PQ 把向量压缩省内存
 · 优点：省内存、扛超大规模（亿级）
 · 代价：recall 调参更麻烦

核心 tradeoff 就三个旋钮：recall（准不准）× latency（快不快）× memory（省不省内存）。没有银弹，按规模和精度要求选。绝大多数项目 HNSW 就够了，所以下面选型里基本都在比"谁把 HNSW 跑得又快又省"。

五、2026 向量库选型

库	形态	最适合	一句话特点
pgvector	Postgres 扩展（内嵌）	中小规模 + 已有 Postgres	默认首选；零额外运维；和关系数据能 JOIN
Pinecone	全托管 SaaS（serverless）	大规模 + 不想运维	企业级、开箱即用、按量付费
Milvus	开源（自建）	超大规模、高吞吐	能力最全、索引类型最多、运维最重
Qdrant	开源（Rust，自建/托管）	性能 + 简洁的平衡	Rust 写的，快且省资源，API 干净
Chroma	轻量嵌入式	原型 / 小型 AI 应用	上手最快，几行代码跑起来

一句话选型：

规模没到千万级 + 已经跑着 Postgres → pgvector（大多数项目停在这里）；
要托管省心、规模大 → Pinecone；
超大规模、有自建能力 → Milvus；
追性能和简洁的平衡、自建 → Qdrant；
做原型、几万条以内 → Chroma。

六、pgvector 为什么是默认首选（重点）

单独拎出来讲，因为这是 2026 业界共识里最该记住的一条：start with pgvector。

理由很简单：

你大概率已经有 Postgres。pgvector 是它的扩展，装上就能用，CREATE EXTENSION vector，然后像普通列一样存向量、建 HNSW 索引、用 <=> 算余弦——零额外组件、零额外运维。
向量数据和关系数据在一个库里。你能 JOIN 用户表、能走事务、能用现有备份/监控/权限体系。专用向量库往往要把数据同步两份，一致性是麻烦。
规模天花板对多数项目够用。HNSW 索引下，几十万到千万级向量、中等 QPS，pgvector 都扛得住。真撑不住（通常是亿级 + 高 QPS）再迁不迟。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


-- pgvector 大概长这样
CREATE EXTENSION vector;

CREATE TABLE docs (id int, content text, emb vector(1536));
CREATE INDEX ON docs USING hnsw (emb vector_cosine_ops);

-- 语义检索 + 关系过滤一条 SQL 搞定
SELECT content
FROM docs
WHERE user_id = 42 -- 关系过滤
ORDER BY emb <=> $1 -- 余弦距离排序
LIMIT 10;

最后那个"向量相似度排序 + 关系 WHERE 过滤一条 SQL"是 pgvector 最香的地方——专用向量库做这个要绕一圈（先向量检索再回 DB 过滤，或者搞混合检索）。

小结

向量检索 = embedding 把语义变成向量 + ANN 高效找近邻。它补的是关键词检索"按意思找"这块盲区。
ANN 的核心是 recall × latency × memory 的三角 tradeoff，HNSW 是当前主流首选，IVF+PQ 适合超大规模。
2026 选型：pgvector 默认够用、Pinecone 托管省心、Milvus 超大规模自建、Qdrant 性能简洁、Chroma 原型。
最重要的一条：start with pgvector——大多数项目不需要专用向量库，Postgres + pgvector 一套搞定，撑不住再迁。

下一篇《RAG 进阶》在这块地基上，讲怎么用向量检索搭一个真正好用的 RAG 系统——为什么"把 PDF 塞进向量库"的 naive RAG 已经不够了。