RAG检索增强生成架构设计：向量数据库选型与Chunk分割策略实战

RAG架构核心流程与适用场景

RAG（Retrieval-Augmented Generation）通过将外部知识库检索与大模型推理结合，解决LLM知识截断与幻觉问题。核心流程分三个阶段：文档预处理与向量化存储、用户Query检索匹配、上下文注入LLM生成答案。在企业知识库、智能客服、法律合规审查等场景下，RAG比纯微调方案迭代成本低、知识更新快，已成为大模型落地的首选架构。

RAG架构的关键技术决策集中在两个维度：向量数据库选型决定检索性能上限，Chunk分割策略直接影响召回质量。选型错误导致检索延迟过高，分割不合理造成语义截断，两者均会使最终生成答案偏离事实。

向量数据库选型对比：Milvus、Qdrant与Chroma

主流开源向量数据库中，Milvus、Qdrant和Chroma覆盖了从单机到分布式的主要需求场景。

Milvus支持分布式部署，单集群可管理十亿级向量，提供IVF_FLAT、HNSW、DiskANN等多种索引类型。生产环境下推荐使用HNSW索引，查询延迟在毫秒级，召回率95%以上。Milvus的架构分为Access Layer、Coordinator Service、Worker Node和存储层，各层可独立扩缩容。

Qdrant用Rust实现，单机性能突出，支持WAL持久化和动态分片。其Filterable HNSW索引允许在向量检索时叠加标量过滤条件，适合需要metadata联合过滤的场景（如按部门、日期范围筛选文档）。

Chroma定位轻量级嵌入数据库，单进程Python包即可运行，适合原型验证和小规模场景。Chroma内置多种嵌入函数，无需额外调用Embedding API，但分布式能力和写入吞吐不及Milvus。

选型决策路径：数据量千万级以上或需要水平扩展选Milvus；百万级数据且查询条件复杂选Qdrant；快速验证选Chroma。云服务场景可考虑Pinecone或Zilliz Cloud（Milvus托管版），省去运维成本。

Embedding模型选择与维度影响

向量质量取决于Embedding模型。OpenAI text-embedding-3-large输出3072维向量，MTEB榜单排名靠前但调用有API成本。开源方案中BAAI/bge-large-zh-v1.5和BCE/bce-embedding-base_v1在中文场景表现优秀，1024维向量兼顾精度与存储效率。

模型维度直接影响存储与检索效率。3072维向量每条占12KB（float32），一亿条向量需1.2TB存储。通过Matryoshka表示学习（MRL）技术，bge系列支持截断到768维仍保持90%以上召回率，实际部署时可按存储预算灵活选择维度。

模型部署方案：低QPS场景用vLLM或TEI（Text Embeddings Inference）单GPU推理；高QPS场景用Infinity推理引擎，单卡A10可达到2000+ embed/s吞吐。

Chunk分割策略：固定长度、语义分割与递归分割

Chunk大小与边界划分是召回质量的决定因素。三种主流分割方案各有适用场景。

固定长度分割（Fixed-size Chunking）按token数切分，通常设overlap为chunk_size的10%-20%。优点是实现简单、向量长度一致利于索引优化，缺点是容易在句子中间截断，破坏语义完整性。

语义分割（Semantic Chunking）基于自然边界切分：按段落、小节、Markdown标题层级划分Chunk。LlamaIndex的SentenceSplitter和LangChain的RecursiveCharacterTextSplitter是常用实现。语义分割保证每个Chunk包含完整语义单元，召回质量显著优于固定长度。

递归分割（Recursive Chunking）按分隔符优先级逐级拆分：先按双换行符切段落，段落过长按单换行符切句子，句子过长按空格切词。LangChain的RecursiveCharacterTextSplitter默认分隔符优先级为换行符、空格等，实际效果接近语义分割且兼容性更强。

推荐配置：chunk_size=512 tokens，chunk_overlap=64 tokens，使用递归分割。技术文档类内容配合MarkdownHeaderTextSplitter按标题层级分割，可在检索时同时返回章节路径，增强上下文可追溯性。

检索策略优化：混合检索与重排序

纯向量检索在处理专业术语、缩写和否定表达时存在语义鸿沟。混合检索（Hybrid Search）将稀疏检索（BM25）与稠密向量检索结合，两者分数加权融合后排序，可显著提升召回率。

Milvus 2.4+原生支持多路召回，单次查询可同时执行向量搜索和标量全文搜索。Qdrant通过sparse向量字段支持BM25权重存储。未原生支持的方案中，Elasticsearch的rank_feature查询配合向量检索是常见实现。

重排序（Reranking）在召回候选集上做精排。Cohere Rerank、BAAI/bge-reranker-v2-m3等Cross-Encoder模型对query-document对做细粒度相关性打分，Top-10结果精度可提升15%-30%。典型流程：向量检索召回Top-50，BM25召回Top-50，合并去重后Rerank取Top-5送入LLM。

生产部署注意事项

向量索引构建阶段，HNSW参数M和efConstruction影响召回率与构建速度的权衡。M=16、efConstruction=256在1亿数据集上召回率98%+，构建时间约为M=8的2倍但查询更精确。查询阶段ef_search参数动态调整：低并发时设ef_search=128保精度，高并发时降至64换吞吐。

增量更新场景下，Milvus支持Insert和Upsert操作，HNSW索引在数据增长10%以内无需重建。超过阈值需触发索引重建，生产环境建议通过双Collection滚动切换实现零停机更新。

监控层面需关注检索延迟P99、召回率（定期用标注数据集跑Benchmark）、向量分布质量（通过PCA降维可视化检测embedding collapse）。Embedding模型升级或切换后，需全量重建向量索引，新旧模型产出的向量不可混用。