当文档库达到百万级，RAG系统的主要矛盾会从“能不能生成答案”转向“如何在几十毫秒内从海量候选块中准确捞出相关上下文”。单路向量检索擅长处理同义改写，但对编号、型号、接口名等精确匹配不够稳定；传统倒排检索能精准命中关键词，却无法理解语义变化。实际系统通常会采用分层漏斗结构：先通过多路召回把候选从百万级压缩到几百条，再用重排序模型压缩到几十条，最后交给大模型生成。
百万级文档库的检索难点与架构总览
百万级文档库的一个常见规模是100万篇文档，每篇文档平均切分成10到30个块，总块数可能达到千万级。以1536维的embedding向量为例，一千万条向量用float32存储约需要61GB，加上索引结构后内存很容易超过100GB。如果直接把全部块送入单路向量检索，不仅内存压力大，还会因为候选集过大导致召回精度下降。
长文本带来的另一个问题是语义稀释。一篇上万字的技术手册可能同时涵盖安装、配置、API和排障，切分后单个块只包含局部信息。如果查询要求跨段落的因果链，固定长度切分会产生大量语义不完整的块，召回时很容易漏掉关键上下文。因此架构设计不能只考虑向量库选型，还要把切分策略、元数据过滤、混合召回和重排序放在一起规划。
推荐的分层架构是：离线阶段对文档进行清洗、结构解析、分块和向量化，同时建立倒排索引与向量索引；在线阶段先做查询理解，随后并行执行BM25稀疏召回和向量稠密召回，经RRF融合得到候选集合，再由交叉编码器重排，最终把Top K块拼接到提示词中。这个漏斗的每一层都要控制候选数量，否则延迟会失控。
文档切分与索引构建策略
切分粒度直接决定召回质量。太小的块会丢失上下文，太大的块又会让向量表示变得模糊。对于技术文档，建议优先使用结构感知切分，按照标题、段落、代码块和表格边界划分，而不是机械地按字符数截断。LangChain的递归字符切分器可以设置多级分隔符，代码示例如下：
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=512,
chunk_overlap=64,
separators=["\n\n", "\n", "。", "，", " "]
)
chunks = splitter.split_text(long_document)
代码中的chunk_overlap用于在相邻块之间保留一定重叠，避免关键句子被硬切开。separators会按优先级寻找合适的断点，提升块内的语义完整性。对于API文档或法律文本，还可以结合正则表达式按条款、函数定义或表格区域切分。
在百万级场景下，单纯的扁平分块不够用，父子分块是更稳妥的方案。父块存储较大的逻辑单元，子块用于向量召回；当子块被命中时，把对应父块或相邻子块一并加入上下文。这样既保证了召回精度，又给大模型提供了更完整的背景。另一个有效做法是为每个父块生成简短摘要并独立索引，摘要向量召回可以覆盖长文档的全局主题，避免只命中局部片段。
元数据过滤同样重要。给每个文档打上来源、版本、语言、状态等标签后，检索时可以先按条件缩小候选范围。例如只检索已发布版本，或者只检索特定产品线文档。元数据过滤能显著降低候选规模，也能避免旧版本内容污染答案。
混合召回与重排序的工程实现
BM25适合精确词匹配，向量检索适合语义匹配，两者天然互补。一个常见错误是只调高向量召回数量，试图靠语义覆盖所有查询，结果在包含型号、错误码、函数名等硬性条件的查询上表现很差。混合召回可以先各自取Top 100到Top 200，再用RRF融合分数。RRF不依赖分数的绝对值，通过排名倒数计算融合分数，稳定性好。
下面是一个简化实现的思路：
from rank_bm25 import BM25Okapi
import numpy as np
def hybrid_search(query, chunks, embeddings, embed_fn, top_k=100):
tokenized_chunks = [c.split() for c in chunks]
bm25 = BM25Okapi(tokenized_chunks)
sparse_scores = bm25.get_scores(query.split())
sparse_rank = np.argsort(sparse_scores)[::-1][:top_k]
q_emb = embed_fn([query])[0]
dense_scores = np.dot(embeddings, q_emb)
dense_rank = np.argsort(dense_scores)[::-1][:top_k]
rrf = {}
for rank, idx in enumerate(sparse_rank):
rrf[idx] = rrf.get(idx, 0) + 1.0 / (60 + rank)
for rank, idx in enumerate(dense_rank):
rrf[idx] = rrf.get(idx, 0) + 1.0 / (60 + rank)
fused = sorted(rrf.items(), key=lambda x: x[1], reverse=True)[:top_k]
return [chunks[i] for i, _ in fused]
实际系统通常使用Elasticsearch或OpenSearch提供BM25召回，用Milvus、Qdrant或FAISS提供向量召回，应用层负责融合。融合后的候选一般控制在200到500条，再送入重排序模型。RRF中的常数60可以根据召回效果微调，但通常保持默认即可。
重排序推荐使用交叉编码器，例如bge-reranker或Cohere Rerank，它把查询和候选块拼接后做深度交互，精度远高于双塔向量分数。交叉编码器计算量大，因此只能处理少量候选。百万级检索中，召回层负责高召回率，重排层负责高精确率，两者职责不能混淆。重排后的Top 8到Top 20条才进入提示词，既能控制上下文长度，也能减少无关信息对大模型的干扰。
量化压缩与性能成本优化
千万级向量如果全部使用float32原始向量，内存和磁盘成本都很高。工程上可以采用乘积量化或标量量化，把每条向量压缩到原来的四分之一甚至更低。FAISS的IVF-PQ索引先把向量空间划分为多个聚类，再对残差做PQ编码，查询时只搜索最近的几个聚类中心，能在召回率损失可控的前提下把延迟和内存大幅降低。
HNSW图索引查询速度快，但内存占用更大；IVF索引内存占用小，但召回率略低。对于百万级文档、千万级块的规模，常见方案是采用IVF加PQ，或者使用支持磁盘索引的向量库。具体选择要结合QPS、延迟预算和硬件配置。例如单机内存128GB、要求P99延迟小于300毫秒时，HNSW加标量量化通常比IVF-PQ更稳定。
除了索引优化，还可以从业务侧做冷热分层。把频繁访问的文档放在高性能索引中，把长尾文档压缩后存储；或者按时间、部门、产品线建多个独立索引，查询时路由到对应子集。缓存热门查询的召回结果也能降低重复计算。最后，不要忽视查询侧优化：对用户查询做改写、拆解和扩展，往往比继续堆召回路数更有效。百万级文档库的RAG系统最终能否稳定运行，取决于召回、索引、成本三者之间的持续调优，而不是单一环节的模型效果。