一、什么时候需要RAG
大模型有两大先天缺陷：
- 知识截止于训练数据时间点，无法回答之后的问题
- 不知道企业内部私有知识（合同、手册、规范、FAQ）
RAG（Retrieval-Augmented Generation）的核心价值是：让大模型在回答问题之前，先从企业知识库中检索相关内容，再结合检索结果生成答案。
适用场景判断：
- 需要基于企业内部文档回答问题 → RAG
- 只需要通用知识（如“什么是区块链”） → 不需要RAG
- 需要精确引用来源（客户、合规） → RAG
- 实时数据查询（如“现在库存多少”） → RAG + API调用
二、选型：RAG系统的四个核心组件
一个完整的RAG系统包含四个组件：
组件1：文档解析与切分
将PDF、Word、Markdown等格式的文档解析为纯文本，并按策略切分成段落。
常见切分策略：
- 固定长度切分（如512 tokens），简单但可能切断语义
- 语义切分（按段落、标题），保留语义完整性
- 混合切分：先按标题切分章节，再对长章节按段落切分
组件2：向量化模型（Embedding Model）
将文本片段转换为向量，用于后续相似度检索。
选型考量：
- 开源模型：BGE、M3E、GTE（中文效果较好）
- API模型：OpenAI text-embedding-3-small/large
- 选择标准：推理速度、维度大小、中文效果、是否支持私有部署
组件3：向量数据库
存储和检索向量，支持相似度搜索。
主流选项对比：
| 数据库 | 特点 | 适用场景 |
|---|---|---|
| Chroma | 轻量、嵌入式、易上手 | 开发测试、小规模 |
| Qdrant | 性能好、过滤功能强 | 生产环境、中等规模 |
| Milvus | 分布式、高可用、生态完整 | 大规模、企业级 |
| PGVector | Postgres插件，复用现有数据库 | 已在用Postgres的团队 |
组件4：大模型（LLM）
基于检索到的上下文生成答案。
选型考量：上下文长度（至少8K以上）、推理速度、成本、是否私有部署。
三、搭建：从零开始实现一个RAG
第一步：准备文档
选择10-20份核心文档作为起点，确保是可解析的格式（PDF/Word/Markdown），扫描件需要先OCR。
第二步：文档切分
Python伪代码示例（纯文本格式）：
经验值：chunk_size在512-1024 tokens之间，overlap在10-20%之间。
第三步：向量化并存入数据库
流程：
- 遍历所有chunk
- 调用Embedding模型，将chunk转为向量
- 将向量+原始文本+元数据（文件名、页码）存入向量数据库
第四步：实现检索
用户问题到检索的流程：
- 用户输入问题
- 调用同一Embedding模型，将问题转为向量
- 在向量数据库中执行相似度检索，返回Top K个最相似的chunk（K一般取3-10）
- 将检索到的chunk拼接为上下文
第五步：生成答案
构造Prompt（纯文本格式）：
第六步：返回结果
将模型生成的答案返回给用户，同时附上检索到的来源信息，方便用户核实。
四、测试：如何评估RAG效果
评估维度一：检索准确率
- Recall@K：正确答案是否在Top K个检索结果中
- MRR：正确答案的排名位置
评估维度二：生成质量
- 答案相关性：回答是否切题
- 幻觉率：回答是否包含知识库中没有的信息
- 来源正确性：引用的来源是否确实包含该信息
测试方法：
准备50-100个“问题-期望答案-期望来源”的三元组测试集。答案可以人工标注，也可以用大模型辅助生成后人工校验。
五、优化：RAG调优的实战经验
调优方向一：文档切分
- chunk太小：上下文不完整，答案可能遗漏信息
- chunk太大：引入噪声，且增加token消耗
- 经验值：按段落切分，保留自然语义边界
调优方向二：检索策略
- 调整Top K值：K太小可能漏信息，K太大引入噪声
- 增加重排序：检索出Top 20个chunk后，用更精细的模型重新排序，取Top 5
- 混合检索：向量检索 + 关键词检索（BM25），合并结果
在具体实现上，有企业采用 ZGI 作为RAG检索调优的平台底座，其内置的重排序和混合检索能力可以显著提升召回效果。
调优方向三：Prompt优化
- 明确“不知道就说不知道”，减少幻觉
- 要求附上来源，增强可信度
- 添加输出格式约束（如JSON格式输出特定字段）
调优方向四：元数据过滤
在检索时按业务维度过滤：指定文档范围、指定时间范围、指定文档类型。
六、持续迭代：RAG的闭环优化
RAG系统上线后，持续迭代的方法：
收集bad case
记录用户对答案的负反馈（点踩、重新提问、手动修改），作为优化素材。
定期评估
每周/每月跑一次测试集，监控准确率和幻觉率的变化趋势。
优化动作
- 补充新的文档到知识库
- 调整切分策略和检索参数
- 针对高频bad case优化Prompt
- 必要时微调Embedding模型
七、总结与建议
RAG是从0到1搭建企业知识库问答系统的核心范式。
建议按以下路径推进：
- 从一个小场景开始：选择文档量少、问题边界清晰的场景（如一个产品线的FAQ）
- 快速搭建MVP：1-2周完成从文档到可问答的闭环
- 测试验证效果：用50个测试问题评估当前水平
- 持续迭代优化：bad case驱动，每周迭代一轮
本文基于RAG系统建设实践整理，希望能为从0到1搭建RAG的团队提供一些参考。
