如何设计一个 RAG 系统
RAG（Retrieval-Augmented Generation） 是当前企业级大模型应用中最常见的架构之一。其核心思想是：通过外部知识库检索相关信息，再将检索结果作为上下文提供给大模型生成答案，从而解决模型幻觉（Hallucination）、知识时效性和私有知识接入等问题。
一个完整的 RAG 系统通常包含以下核心阶段：
- 文档解析（Document Parsing）
- 文档切片（Chunking）
- 向量化（Embedding）
- 向量存储（Vector Storage）
- 检索（Retrieval）
- 重排（Rerank）
- Prompt 构建与生成（Generation）
一、RAG 的核心思想
RAG（Retrieval-Augmented Generation）是一种将 信息检索系统 与 **大语言模型（LLM）**结合的架构。
核心思想：
先检索，再生成。
工作流程：
- 从知识库中检索相关信息
- 将检索结果作为上下文输入大模型
- 由模型生成最终答案
RAG 解决的核心问题：
- 大模型幻觉（Hallucination）
- 私有知识接入
- 知识实时更新
- 降低模型训练成本
二、RAG 系统整体架构
一个典型 RAG 系统包含 离线数据处理 + 在线检索服务 两部分。
flowchart TD A[企业文档] --> B[文档解析] B --> C[文本清洗] C --> D[文档切片] D --> E[Embedding向量化] E --> F[向量数据库] User[用户Query] --> Q1[Query Embedding] Q1 --> F F --> R1[TopK召回] R1 --> R2[Rerank重排] R2 --> P[Prompt构建] P --> LLM[大语言模型] LLM --> Answer[最终回答]
系统可以拆分为 两个主要链路：
离线处理链路
文档 → 解析 → 切片 → embedding → 向量库
在线查询链路
Query → embedding → 检索 → rerank → prompt → LLM
三、文档解析（Document Parsing）
RAG 的第一步是 将各种格式文档转换为结构化文本。
企业知识通常来源：
- Word
- Excel
- PPT
- HTML
- Wiki
- Markdown
- API文档
- 内部知识库
目标是将这些文档转换为统一的文本格式，推荐使用 Markdown，原因包括：
- 保留标题层级结构（
#、##、###） - 保留列表、表格等语义结构
- 更容易进行后续的语义切片
常见解析工具
1 传统解析工具
常用工具：
- PyMuPDF
- pdfplumber
- Apache Tika
适合：
- 普通 PDF
- 文本型文档
优点：
- 速度快
- 成本低
缺点：
- 表格解析差
- 复杂排版丢失
2 OCR 文档解析
如果是 扫描版 PDF：
需要 OCR：
常用工具：
- PaddleOCR
- Tesseract
3 基于大模型的解析
近年越来越多系统使用 LLM + Layout 识别进行解析：
优势：
- 能识别复杂表格
- 结构恢复更好
- Markdown 输出质量高
常见工具：
- MinerU
- markitdown
文档解析流程
flowchart LR A[PDF/Word/PPT] --> B[Layout识别] B --> C[OCR] C --> D[结构解析] D --> E[Markdown]
四、文本清洗（Text Cleaning）
文档解析后通常需要 文本清洗：
常见问题：
- 页眉页脚
- 页码
- 重复段落
- 无意义空行
- OCR 错误字符
示例：
清洗前
Page 3 of 20
Company Confidential
清洗后
删除
五、文档切片（Chunking）
文档切片是 RAG 系统中 最关键的设计之一，它直接影响：
- 检索召回率
- LLM理解能力
- Token成本
- 上下文完整性
如果切片过大：
- 检索噪声增加
如果切片过小：
- 语义上下文被破坏
切片原则
好的 chunk 应满足：
- 语义完整
- 长度适中
- 不破坏上下文
常见切片策略
1. 不切片
适用于：
- 短文档
- FAQ
- 单页文档
2. Markdown结构切片（推荐）
利用标题结构切片：
# 一级标题
## 二级标题
### 三级标题
优点：
- 保持语义完整
- 结构清晰
- 更符合人类阅读逻辑
3. 段落切片
按空行或段落分割。
适用于：
- 文档结构不规范
- 非 Markdown 文档
4. 句子切片
按标点切片：
。.;,
适合：
- QA 语料
- 对话语料
5. 按固定 Token / 字符数切片
例如：
chunk_size = 512 tokens
overlap = 50 tokens
优点：
- 实现简单
- 稳定
缺点：
- 可能破坏语义结构
Overlap （重叠窗口）设计
Overlap 用于防止语义断裂。
示例：
chunk_size = 500
overlap = 50
切片：
chunk1: 0-500
chunk2: 450-950
推荐经验值：
| chunk size | overlap |
|---|---|
| 256 | 20-40 |
| 512 | 50-80 |
| 1024 | 100-150 |
六、Embedding 向量化
文档切片后，需要将文本转换为 向量表示（Embedding），以支持语义检索。
流程：
flowchart LR TextChunk --> EmbeddingModel EmbeddingModel --> Vector
Embedding 模型选型
Embedding 模型的选择需要考虑：
- 是否支持多语言
- 语义检索精度
- 向量维度
- 推理成本
- 推理速度
常见 Embedding 模型
开源模型：
- BGE 系列
- E5 系列
- Jina Embedding
- GTE
商用 API：
- OpenAI embedding
- Cohere embedding
- Voyage embedding
模型选择建议
| 场景 | 推荐模型 |
|---|---|
| 中文业务 | BGE-large / BGE-base |
| 多语言 | E5-multilingual |
| 轻量部署 | BGE-small |
| 高精度 | BGE-large |
向量维度
常见：
| 模型 | 维度 |
|---|---|
| BGE-base | 768 |
| BGE-large | 1024 |
| OpenAI | 1536 |
Embedding 粒度
Embedding 应该对 切片后的 chunk 进行，而不是整个文档。
Document
├── Chunk1 → embedding1
├── Chunk2 → embedding2
└── Chunk3 → embedding3
这样可以提高检索精度。
七、向量数据库（Vector DB）
向量需要存储在 向量数据库 中以支持高效相似度检索。
向量检索算法
主流 ANN 算法：
- HNSW
- IVF
- PQ
- DiskANN
向量数据库架构
flowchart TD Embedding --> Index构建 Index构建 --> HNSW索引 HNSW索引 --> Search Search --> TopK
常见向量数据库
向量需要存储在 向量数据库 中以支持高效相似度检索。
常见方案分为两类。
传统数据库 + 向量插件
适合 中小规模系统。
常见方案：
- Elasticsearch + vector
- PostgreSQL + pgvector
优点：
- 与业务数据库统一
- 运维成本低
- 系统架构简单
缺点：
- 向量检索性能有限
- 大规模数据扩展困难
专用向量数据库
适合 大规模 RAG 系统。
常见方案：
- Milvus
- Qdrant
- Weaviate
- Pinecone
优势：
- 支持 ANN（Approximate Nearest Neighbor）
- 支持 GPU
- 支持分布式扩展
当向量规模达到，千万级，甚至亿级，专用向量数据库的优势非常明显。
FAISS 自建向量引擎
如果需要 极致性能 或 离线系统：
可以直接使用 FAISS 构建向量检索系统。
优点：
- 极高性能
- 完全可控
缺点：
- 需要自行维护索引
- 不支持分布式管理
数据规模选型
| 数据规模 | 推荐 |
|---|---|
| < 1M | pgvector / Elasticsearch |
| 1M - 10M | Qdrant / Weaviate |
| 10M - 100M | Milvus |
| > 100M | Milvus / 自建 FAISS |
八、检索（Retrieval）
检索阶段的目标是：
从知识库中找到与 Query 最相关的文本片段。
流程：
Query → embedding → vector search → TopK Chunk
TopK 参数
推荐：
TopK = 10 ~ 30
九、多路召回（Hybrid Retrieval）
单一向量检索存在问题：
- 专有词召回差
- 精确匹配能力弱
因此通常使用 Hybrid Search。
常见组合：
- Vector Search
- BM25
- Keyword Matching
BM25 特别适合：
- 精确词匹配
- 产品型号
- API 名称
- 数字编号
例如：
"HTTP 502 error"
BM25 的效果通常优于向量检索。
多路召回架构
flowchart TD Query --> VectorSearch Query --> BM25 Query --> KeywordSearch VectorSearch --> Merge BM25 --> Merge KeywordSearch --> Merge Merge --> CandidateSet
十、结果合并（Merge）
多路召回后需要进行 结果合并与去重：
步骤：
- 去重（duplicate removal）
- 按 score 排序
- 限制候选数量
- 补充上下文
例如：
chunk_i
- chunk_i+1
保证语义完整性。
上下文补充
例如：
chunk_i
chunk_i+1
保证语义完整。
十一、Rerank 重排
向量检索是 粗排（Retrieval）。它的优点是，非常快，可处理亿级数据；缺点是语义理解浅，容易误召回
Rerank 的作用是对候选文档进行 深度语义匹配
(Query, Document) → Score
这种模型通常采用 Cross Encoder 架构。
特点：
- Query 和 Document 共同输入模型
- 深度语义交互
- 排序准确度高
但计算成本高，因此只用于：
Top 50 → rerank → Top 5
Rerank 原理
输入：
Query + Document
输出：
相关性 Score
Cross Encoder
架构：
[Query + Document] → Transformer → Score
特点：
- 深度语义理解
- 高精度
常见 Reranker
- BGE-Reranker
- Jina Reranker
- Cohere Rerank
- ColBERT
Rerank Pipeline
flowchart TD VectorSearch --> Top50 Top50 --> Rerank Rerank --> Top5
十二、Prompt 构建
最后一步是将 检索结果 + 用户问题 组合成 Prompt。
典型结构：
System Prompt
+ Context
+ Conversation History
+ User Query
Prompt 示例
You are a helpful assistant.
Use the following context to answer the question.
Context:
{retrieved_chunks}
Question:
{user_query}
设计要点：
1 限制回答必须基于知识库
2 避免模型编造内容
3 控制 Token 长度
例如为了防止幻觉，prompt可以加入：
If the answer is not in the context, say "I don't know".
十三、Token 控制
LLM 有 上下文长度限制。
需要控制：
TopK
chunk_size
history length
推荐：
context tokens < 3000
十四、系统性能优化
RAG 系统瓶颈通常在：
1 embedding
2 vector search
3 rerank
4 LLM
优化方法
1 Query Embedding Cache
相同 query 直接复用。
2 ANN 索引优化
推荐 HNSW 参数：
M=16
efConstruction=200
efSearch=64
3 批量 embedding
batch_size = 32
提高 GPU 利用率。
4 结果缓存
缓存：
query → answer
可减少 LLM 调用。
十五、生产级架构
生产环境通常采用 微服务架构：
flowchart TD User --> API API --> RetrievalService API --> LLMService RetrievalService --> VectorDB RetrievalService --> RerankService OfflinePipeline --> DocumentParser OfflinePipeline --> ChunkService OfflinePipeline --> EmbeddingService OfflinePipeline --> VectorDB
十六、进阶 RAG 方向
传统 RAG 只是基础架构，当前行业已经发展出多种增强方案：
Graph RAG
使用 知识图谱增强检索能力：
Entity → Relation → Entity
适用于：
- 金融
- 医疗
- 法律
Multi-modal RAG
支持多模态数据：
- 图片
- 表格
- 视频
Agentic RAG
结合 Agent 能力：
- 动态检索
- 多步推理
- 自动工具调用
总结
一个成熟的 RAG 系统需要重点优化以下四个环节：
- 高质量文档解析
- 合理的切片策略
- 高召回率的检索系统
- 高精度的 Rerank 排序
RAG 的核心逻辑可以用一句话概括：
用检索解决知识问题，用大模型解决表达问题。
一个完整的 RAG 系统工程链路：
Documents
↓
Parsing
↓
Chunking
↓
Embedding
↓
Vector DB
↓
Hybrid Retrieval
↓
Rerank
↓
Prompt
↓
LLM
↓
Answer