RAG技术栈深度解析：从向量数据库到检索增强生成的工程化落地

原创于 2026-08-13 22:29:12 发布 · 468 阅读

7 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

数据库

RAG技术栈深度解析：从向量数据库到检索增强生成的工程化落地

从零构建企业级RAG系统的完整指南：技术选型、架构设计、性能优化与避坑指南

在这里插入图片描述

一、为什么RAG是大模型落地的关键技术

2023年被称为"RAG元年"，检索增强生成（Retrieval-Augmented Generation）从一个学术概念迅速成为企业级大模型应用的标配技术。那么，RAG究竟解决了什么问题，为什么它如此重要？

1.1 大模型的三大固有缺陷

即使是GPT-4这样的前沿大模型，也存在三个无法通过模型训练彻底解决的问题：

知识时效性问题 — 大模型的知识截止于训练数据的时间点。GPT-4的训练数据截止到2023年，对于2024年以后发生的事情它一无所知。企业内部的最新产品文档、政策法规、客户案例等动态知识更是无法覆盖。

领域专业性问题 — 通用大模型在垂直领域的专业知识往往不够深入。法律、医疗、金融等行业有大量专业术语和案例，通用模型很难准确掌握。即使通过微调（Fine-tuning）注入领域知识，成本高且周期长，知识更新也不灵活。

事实幻觉问题 — 大模型会"一本正经地胡说八道"，生成看似合理但实际错误的内容。在企业场景中，幻觉可能导致严重的后果：法律建议出错、医疗诊断失误、财务报告失真等。

1.2 RAG的核心思想

RAG的核心思想非常朴素但极其有效：让大模型在回答问题之前，先从外部知识库中检索相关的文档片段，然后基于这些检索到的信息生成答案。

这个思路类似于人类的"开卷考试"——你不需要把所有知识都记在脑子里，只需要知道去哪里找、怎么找，然后结合找到的信息来回答问题。

RAG带来的三个核心价值：

知识实时更新 — 知识库可以随时更新，不需要重新训练模型
答案可溯源 — 每个答案都可以追溯到具体的来源文档，可信度更高
降低幻觉 — 基于检索到的事实生成答案，大幅减少虚构内容

1.3 RAG vs 微调 vs Prompt Engineering

很多团队在落地大模型时会纠结：到底应该用RAG、微调还是Prompt Engineering？实际上这三者并非互斥，而是互补关系。

维度	RAG	微调（Fine-tuning）	Prompt Engineering
知识更新	实时更新，成本低	重新训练，成本高	即时调整
事实准确性	高，可溯源	中等，仍有幻觉	取决于Prompt质量
领域适配	适合事实性知识	适合风格/格式学习	适合简单任务
实现成本	中等	高	低
响应速度	较慢（需检索）	快	快
数据需求	需要知识库文档	需要标注数据	需要少量示例

最佳实践：三者结合使用。用Prompt Engineering做基础引导，用RAG注入外部知识，用微调和对齐模型的输出风格和行为模式。

在这里插入图片描述

二、RAG系统的完整技术栈拆解

一个完整的RAG系统可以分为两大阶段：索引阶段（离线）和检索生成阶段（在线）。

2.1 索引阶段（离线处理）

索引阶段负责将各种来源的文档处理成向量并存入向量数据库，是RAG系统的基础。

数据加载 → 文档清洗 → 文档切分 → 向量化（Embedding）→ 向量存储

数据加载：支持PDF、Word、Excel、PPT、Markdown、HTML、网页、数据库等多种数据源。LangChain和LlamaIndex都提供了丰富的Document Loader。

文档清洗：去除页眉页脚、目录、页码等无关信息；处理表格、图片等非文本内容；统一字符编码和格式。

文档切分（Chunking）：将长文档切分成合适大小的片段（Chunk）。这是RAG中最关键也最容易被忽视的环节，切分策略直接影响检索质量。

向量化：将每个文本片段通过Embedding模型转换成高维向量（通常是768维或1024维）。

向量存储：将向量和对应的原始文本存入向量数据库，建立索引以便快速检索。

2.2 检索生成阶段（在线服务）

检索生成阶段负责接收用户查询，从知识库中检索相关内容，然后交给大模型生成答案。

查询改写 → 向量检索 → 结果重排序（Rerank） → Prompt组装 → LLM生成 → 结果返回

查询改写：用户的原始查询可能存在歧义、表述不完整等问题。通过大模型对查询进行改写、扩展，可以提升检索的召回率。

向量检索：将用户查询转换为向量，在向量数据库中进行相似度搜索，返回最相关的Top K个文档片段。

结果重排序：向量检索返回的结果是基于语义相似度排序的，但语义相关不等于答案相关。通过Reranker模型对检索结果进行二次排序，可以显著提升准确率。

Prompt组装：将检索到的文档片段和用户的问题按照一定的模板组装成最终的Prompt，发送给大模型。

LLM生成：大模型基于检索到的上下文信息生成答案。

三、向量数据库选型与深度对比

向量数据库是RAG系统的核心组件，负责存储和检索向量。当前主流的向量数据库种类繁多，各有侧重。

3.1 主流向量数据库对比

特性	Milvus	Pinecone	Chroma	Weaviate	Qdrant	pgvector
类型	开源	SaaS	开源	开源+SaaS	开源	PostgreSQL扩展
开发语言	Go/C++	-	Python	Go	Rust	C
部署方式	分布式/单机	托管	单机	分布式/单机	分布式/单机	单机
向量索引	HNSW, IVF, DiskANN	HNSW	HNSW	HNSW	HNSW	HNSW, IVFFlat
标量过滤	支持	支持	支持	支持	支持	原生支持
多租户	支持	支持	不支持	支持	支持	支持
性能	极高	高	中	高	高	中
扩展性	好	好（托管）	差	好	好	一般
适合场景	大规模生产	快速上线	原型/小型	企业级	高性能	已有PG栈

3.2 选型建议

初创项目/原型验证：推荐Chroma或Qdrant。Chroma最轻量，几行代码就能跑起来；Qdrant性能更好，单节点也能支撑百万级向量。

中大型生产环境：推荐Milvus。作为LF AI & Data基金会的毕业项目，Milvus在性能、稳定性和社区活跃度方面都处于领先地位，支持分布式部署，能够支撑十亿级甚至百亿级向量的检索。

已有PostgreSQL技术栈：推荐pgvector。不需要引入新的数据库组件，运维成本低，适合向量规模不大（千万级以内）的场景。

不想自己运维：推荐Pinecone或Weaviate Cloud。完全托管，开箱即用，但成本相对较高。

在我们的生产实践中，采用了Milvus作为主力向量数据库，主要基于以下考量：

开源免费，社区活跃，文档完善
性能优异，十亿级向量毫秒级检索
支持多种索引类型，可根据场景灵活选择
支持标量过滤，满足复杂查询需求
分布式架构，支持水平扩展

3.3 索引类型选择

向量数据库的索引类型直接影响检索的速度和精度。常见的索引类型：

HNSW（Hierarchical Navigable Small World）：

基于图的索引，查询速度快，精度高
内存占用较大，构建速度较慢
适合对查询性能要求高的场景
是目前最主流的索引类型

IVF（Inverted File）：

基于聚类的索引，构建速度快，内存占用适中
查询速度和精度略低于HNSW
适合数据量大、对构建速度敏感的场景

DiskANN：

基于磁盘的索引，内存占用极低
查询性能接近HNSW
适合超大规模（百亿级）向量场景
Milvus 2.3+版本已支持

选型建议：绝大多数场景下选择HNSW即可。如果数据量超过10亿且内存有限，可以考虑DiskANN。

四、Embedding模型选型与优化

Embedding模型的质量直接决定了RAG系统的检索效果。选择合适的Embedding模型至关重要。

4.1 主流Embedding模型对比

模型	维度	语言	MTEB排名	开源/商用	特点
text-embedding-3-large	3072	多语言	高	OpenAI商用	综合质量最好
text-embedding-ada-002	1536	多语言	中高	OpenAI商用	经典款，性价比高
BGE-M3	1024	中英	高	开源（BAAI）	开源最强，多语言
GTE-large	1024	中英	高	开源（阿里）	中文效果优秀
M3E-large	1024	中文	中高	开源（Moka）	中文场景表现好
bge-large-en-v1.5	1024	英文	高	开源（BAAI）	英文开源首选
Cohere embed-multilingual	1024	多语言	高	Cohere商用	多语言支持好

4.2 选型建议

英文场景：预算充足选OpenAI text-embedding-3-large，追求开源选BGE-large-en-v1.5。

中文场景：推荐BGE-M3或GTE-large。BGE-M3支持多粒度（短句、长文档）和跨语言检索，是目前开源界的标杆；GTE-large在中文检索任务上表现同样出色。

混合场景：BGE-M3是最佳选择，支持中英双语，且在MTEB榜单上名列前茅。

成本考量：如果是大规模向量化（百万级文档），开源模型的成本优势非常明显。将BGE-M3部署在GPU上，每秒可以处理上千个文本，成本几乎可以忽略不计。

4.3 Embedding优化技巧

选择合适的维度：并非维度越高越好。维度越高，计算量越大，存储成本也越高。对于大多数场景，1024维已经足够。OpenAI的text-embedding-3-large支持动态降维，可以在API中指定输出维度。

微调Embedding模型：如果在特定领域（如法律、医疗）检索效果不理想，可以用领域数据对Embedding模型进行微调。只需要几千对标注数据（query - 相关文档），就能带来显著的效果提升。

批量向量化：向量化时尽量使用批量接口（batch），可以充分利用GPU的并行计算能力，提升吞吐效率。

五、文档切分策略：被忽视的关键环节

很多团队在做RAG时，把主要精力放在了选向量数据库和Embedding模型上，却忽视了文档切分这个环节。实际上，切分策略的好坏对最终效果的影响可能比选哪个Embedding模型更大。

5.1 常见的切分方式

按字符数切分（Character Splitting）：

最简单的方式，按固定字符数切分
问题：可能把一个完整的句子或段落从中间切开，破坏语义完整性
适用：快速原型验证

按语义单元切分（Semantic Chunking）：

按段落、章节等自然语义单元切分
优点：保持语义完整性
问题：段落长度差异大，有的太长有的太短

递归字符切分（Recursive Character Splitting）：

LangChain默认的切分方式
优先按段落、句子等分隔符切分，只有当片段仍然太长时才按字符切
在保持语义和控制长度之间取得平衡
是最常用的切分方式

基于Token数切分（Token Splitting）：

按Token数量而非字符数切分
更准确地控制每个Chunk的Token数，避免超出LLM的上下文限制
适合对上下文长度敏感的场景

语义嵌入切分（Semantic Embedding Chunking）：

对每个句子做Embedding，然后将语义相似的连续句子聚合成一个Chunk
理论上效果最好，但计算成本高，速度慢
适合对质量要求极高的场景

5.2 切分大小如何选择

Chunk大小是一个需要权衡的参数：

Chunk太小：单个片段包含的信息不完整，检索到了也无法回答问题
Chunk太大：包含太多无关信息，稀释了关键内容，还可能超出上下文窗口

经验值：

通用问答场景：500-1000个中文字符（约300-600个Token）
长文档摘要场景：1000-2000个中文字符
代码片段场景：根据函数/类的自然边界切分，可能更长

最佳实践：不要使用固定的Chunk大小，而是采用"大小Chunk结合"的策略：

小Chunk（200-500字）：用于检索，保证召回的精准度
大Chunk（1000-2000字）：用于生成，提供更完整的上下文
检索时用小Chunk，找到相关内容后，返回对应的大Chunk给LLM

5.3 元数据与父子文档

除了文本内容本身，每个Chunk还应该携带丰富的元数据（Metadata）：

文档标题、作者、创建时间
章节信息（一级标题、二级标题）
页码（PDF场景）
标签、分类
来源URL

元数据的作用：

检索过滤：可以按时间范围、文档分类等条件过滤检索结果
结果展示：用户可以看到答案来自哪篇文档的哪个章节
权限控制：不同用户只能检索自己有权限的文档

**父子文档（Parent-Child Document）**是一种进阶的Chunk管理策略：

父文档：完整的章节或文档，内容较完整
子文档：从父文档中切分出的小片段，用于检索
检索时匹配子文档，但返回给LLM的是对应的完整父文档
兼顾了检索的精准度和生成的完整性

六、检索策略优化：从单一检索到混合检索

简单的向量检索在实际应用中往往不够用。下面介绍几种进阶的检索优化策略。

6.1 混合检索（Hybrid Search）

向量检索（稠密检索）擅长捕捉语义相似度，但在处理专有名词、精确匹配等场景时效果不佳。而传统的关键词检索（稀疏检索，如BM25）正好相反。

混合检索结合了两者的优势：

用BM25做关键词匹配，保证精确词汇的召回
用向量检索做语义匹配，保证语义相关的召回
两者的结果通过RRF（Reciprocal Rank Fusion）等算法进行融合

实践证明，混合检索的效果通常优于单一的向量检索，尤其是在专业领域场景中。

实现方式：

Elasticsearch/OpenSearch：原生支持向量检索+BM25的混合检索
Milvus + Elasticsearch：Milvus存向量，ES存全文索引，应用层融合结果
Weaviate：内置混合检索支持

6.2 查询改写（Query Rewriting）

用户的查询往往存在各种问题：太短太模糊、表述口语化、包含指代、多意图混杂等。对查询进行改写可以显著提升检索效果。

常见的改写策略：

查询扩展（Query Expansion）：

用大模型将用户的简短问题扩展成更详细的描述
例如：“怎么退税？” → “个人所得税退税的申请条件、办理流程和所需材料”

多查询生成（Multi-Query）：

用大模型从不同角度生成多个查询变体
对每个变体分别检索，合并结果
可以提升召回率，但检索耗时也会增加

假设文档生成（Hypothetical Document Generation，HyDE）：

让大模型先根据问题生成一个假设的答案文档
用这个假设答案去做向量检索
原理是：假设答案和真实答案在向量空间中更接近
在某些场景下效果显著

6.3 Rerank重排序

向量检索返回的Top K结果是按相似度排序的，但相似度最高的不一定是最相关的。Reranker模型可以对检索结果进行二次精排，进一步提升准确率。

Reranker的工作原理：

向量检索先召回Top 50-100个候选结果（召回阶段，保证召回率）
Reranker模型对每个候选结果和查询进行相关性打分（精排阶段，保证准确率）
按Reranker的打分重新排序，取Top N送入LLM

常用的Reranker模型：

BGE-Reranker（BAAI开源）：中文效果最好的开源Reranker之一
Cohere Rerank：商用API，效果优秀
cross-encoder系列（MS MARCO）：英文场景经典选择

为什么Rerank有效：

向量检索是双编码器（Dual Encoder）结构，查询和文档分别编码，速度快但精度有限
Reranker是交叉编码器（Cross Encoder）结构，查询和文档同时输入模型进行深度交互，精度更高但速度慢
两者结合，先用向量检索快速召回候选集，再用Reranker精排，在速度和精度之间取得最佳平衡

实践建议：

向量检索召回Top 50，Rerank后取Top 5-10送入LLM
Rerank带来的效果提升通常比换更好的Embedding模型更显著
如果性能敏感，可以用小一点的Reranker模型，或者减少Rerank的候选数量

七、Prompt工程与生成策略

检索到相关文档后，如何组装Prompt、如何引导大模型生成高质量的答案，同样有很多讲究。

7.1 Prompt模板设计

一个好的RAG Prompt模板应该包含以下要素：

角色设定：告诉模型它的身份和职责
指令要求：明确要求模型只能基于提供的上下文回答
上下文内容：检索到的文档片段
用户问题：用户的原始问题
输出格式：规定答案的格式和风格

一个完整的Prompt模板示例：

你是一个专业的知识助手，请基于以下提供的参考资料回答用户的问题。

【回答规则】
1. 只能使用参考资料中提供的信息，不要使用你自己的知识
2. 如果参考资料中没有相关信息，请直接回答"根据现有资料无法回答该问题"
3. 答案要准确、客观、完整，不要添加任何主观判断
4. 对于关键信息，请标注来源文档的标题和页码

【参考资料】
{context}

【用户问题】
{question}

【回答】