十个RAG系统，九个死在检索上。

不是模型不行，是检索层出了问题。向量数据库不是"语义搜索引擎"那么简单的东西，它是一个有明确权衡的存储引擎：用精确性换速度，用内存换召回率，用写入吞吐换查询延迟。每个交换都是需要量化的工程决策。

检索栈的五层，每层都有坑

一本新出的工程手册把RAG的检索栈拆成了五层：

表示层：文本到向量的转换。核心问题是你关心的语义有没有被编码进去。密集向量和稀疏向量各有所长，但很多人在选型时根本没做过对比实验。

索引层：向量到近邻的搜索。HNSW、IVF、PQ、DiskANN——每种索引算法都是在精确性和资源消耗之间做取舍。HNSW查询快但吃内存，IVF省内存但需要调参。一个工程师能说"我们选IVF-PQ是因为HNSW需要340GB内存，每月多花4200美元，召回率只高了1.8个点"，这才是有质量的工程决策。说"HNSW更好"不算。

存储层：数据的持久化、过滤和扩展。写入、删除、故障恢复和重建时发生什么？大多数人搭demo时不想这些，上线后才发现。

检索层：从候选集中筛出答案。正确的chunk有没有进候选集？没进的话上面的层全白搭。多查询扩展、父子文档检索、上下文检索各有各的适用场景。

排序层：候选集变成有序上下文。最好的证据在不在最前面？多样性够不够？交叉编码器、延迟交互、MMR——每种重排方法都需要证明它增加的延迟是值得的。

每一层都对上面的层构成上限。没有重排器能恢复检索器没返回的chunk，没有检索器能恢复嵌入模型没编码的语义。调试检索系统意味着先找到最低的那层坏掉的层。

七种分块策略，你用过几种

分块（chunking）是RAG管线里最容易被忽略、却对效果影响最大的环节。

这本手册对比了七种分块策略：固定长度切分、按段落切分、按语义切分、递归切分、按文档结构切分（Markdown标题层级）、滑动窗口、以及基于LLM的语义切分。每种策略在不同文档类型上的表现差异显著。

固定长度切分最简单但容易截断句子；按段落切分保留了语义完整性但段落长度不均匀；基于LLM的语义切分效果最好但成本最高。大多数团队默认用LangChain的递归切分，没有针对自己的数据做过对比。

手册的建议是：先跑一遍自己的数据，用检索召回率作为评估指标，把七种策略都试一遍。数据说话，不要凭直觉选。

生产环境的坑

从demo到生产，检索系统会遇到几类典型问题：

多租户隔离。多个客户共享同一个向量库时，元数据过滤必须做到位，否则客户A的数据会出现在客户B的搜索结果里。

实时索引。数据更新后多久能被检索到？如果用的是批量写入加定期重建索引，延迟可能在分钟级。这对客服知识库可以接受，对交易系统不行。

十亿级搜索。数据量到了十亿条向量，内存成本和查询延迟同时成为瓶颈。DiskANN把索引放在磁盘上，用SSD的随机读取能力换内存节省，但查询延迟会从毫秒级涨到十毫秒级。

成本模型。容量规划应该打印美元而不是形容词。HNSW在百万级数据时需要多少内存？换成IVF-PQ能省多少？这些数字决定了架构选择。

源势AI观点

RAG系统最常见的失败模式是"demo惊艳，上线翻车"。根因是团队把检索层当成一个调API就完事的组件，没有把它当成一个需要持续调优的存储系统来对待。

一个实用的起步框架：搭完RAG管线后，先做三件事。第一，准备一个100条标注数据的评估集，测检索召回率和答案准确率。第二，把分块策略跑一遍对比，选出最适合自己数据的方案。第三，在索引层做一次容量估算——当前数据量需要多少内存，一年后会涨到多少，对应的成本是多少。

这三步做完，大部分"上线就崩"的问题都能提前暴露。向量数据库不是魔法，它的每一个参数都是一个需要你拍板的工程决策。

---

来源：

1. 《Vector Database Engineering for AI》(AI Engineering Insider, 2026)

2. FAISS/Milvus/Qdrant/Weaviate/Pinecone/Chroma/pgvector性能对比数据

3. LangGraph状态机RAG管线工程实践