关键要点
- RAG = 上传文档 + 检索 + 本地大语言模型回答。无需训练。
- 五个步骤：（1）加载文档，（2）分块为500-1000个令牌，（3）生成嵌入，（4）存储到向量DB，（5）查询时检索。
- 最优嵌入模型：nomic-embed-text（137M，本地运行，768维向量）。
- 最优向量DB：Chroma（简单，内置）用于<100万文档；Qdrant（分布式）用于生产环境。
- 截至2026年4月，本地RAG比云API更快更便宜。质量取决于检索准确性和提示工程。
RAG 如何分步骤工作？
- 1文档导入： 加载PDF、文本文件或网页。
- 2分块： 将文档分割为500-1000个令牌的片段（重叠20%以防止上下文破裂）。
- 3嵌入： 使用本地嵌入模型将每个片段转换为向量（768-1536维）。
- 4存储： 将向量存储在向量数据库（Chroma、Qdrant、Milvus）中，包含元数据（文档名、页码、时间戳）。
- 5查询时： 将用户问题转换为嵌入，在向量DB中搜索前K个相似片段（k=5-10）。
- 6上下文组装： 将检索到的片段与大语言模型指令合并为提示。
- 7生成： 本地大语言模型根据检索到的上下文生成答案。
- 8归属： 返回答案来自哪些文档。
最优的分块策略是什么？
分块策略决定检索质量。 不良分块 = 相关信息分散在多个片段，检索失败。
语义分块（推荐）： 按句子或段落分割，保留含义。示例：每个段落 = 1个片段。
固定大小分块： 每个片段500个令牌，20%重叠。简单但可能分割句子。
递归分块： 先按段落分割，如果太大则按句子分割。保留层次结构。
截至2026年4月，使用500-1000个令牌的语义分块和20%重叠对大多数用例最优。
# Python: 语义分块示例
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=200, # 20% 重叠
separators=["\n\n", "\n", ".", " "] # 按段落、句子分割
)
chunks = splitter.split_documents(documents)
print(f"Created {len(chunks)} chunks")应该使用哪个向量数据库？
| 数据库 | 类型 | 容量 | 设置难度 | 最适合 |
|---|---|---|---|---|
| Chroma | 内置 | <100万文档 | pip install | 原型设计、小规模RAG |
| Qdrant | 分布式 | 无限制 | Docker或云 | 生产环境、可扩展 |
| Milvus | 分布式 | 无限制 | 复杂 | 企业、大规模 |
| Weaviate | 图+向量 | 无限制 | Docker | 复杂查询、关系 |
| Pinecone（云） | 托管 | 无限制 | API密钥 | 无服务器、无维护 |
应选择哪个嵌入模型？
| 模型 | 向量维度 | 速度 | 质量 | 推荐 |
|---|---|---|---|---|
| nomic-embed-text（本地） | — | 快 | 优秀 | 本地RAG最佳 |
| bge-m3（本地） | — | 快 | 优秀 | 多语言支持 |
| OpenAI text-embedding-3（云） | — | 非常快 | 业界最佳 | 混合方案 |
| Cohere（云） | — | 快 | 优秀 | 生产云RAG |
如何优化检索质量？
检索质量 决定RAG成败。好的检索 = 好的答案。差的检索 = 幻觉。
衡量检索质量的三个指标：（1）召回率（recall）：找到了多少相关片段的百分比；（2）精准率（precision）：找到的片段中有多少是实际相关的；（3）NDCG：排序质量。
优化技巧：
- 调整片段大小： 尝试256-1000个令牌。太小会丢失上下文，太大会增加噪音。
- 调整重叠： 尝试10-50%。
- 更换嵌入模型： 领域特定嵌入可能优于通用模型。
- 调整搜索参数： K值（结果数）、分数阈值、重新排序算法。
最佳实践：在小型测试集（10-20个用例）上测量检索质量，在生产前迭代改进。
评估与优化：如何测试RAG系统
关键指标：
- 答案质量得分（0-10）： 人工标注。准确性、完整性、相关性。
- 检索成功率（%）： 返回的片段是否足以回答问题？
- 延迟（毫秒）： 从用户问题到回答。目标：<2秒。
- 成本（$）： 本地无API成本；使用云嵌入/重排时的成本。
测试方法：
1. 手工测试集： 10-50个（问题、期望答案、参考文档）组合。
2. 基线测量： 测试当前系统。
3. 调整单个参数： 片段大小、嵌入模型、K值等。
4. 重新测量指标： 改进了吗？
5. 生产验证： 实际用户满意度和反馈。
生产环境RAG的三种模式
模式1：个人RAG（本地、单用户）
- 设置：Ollama + Chroma + nomic-embed-text
- 规模：1-100,000文档
- 成本：免费
- 用例：个人知识库、私密文档
模式2：团队RAG（本地、共享）
- 设置：LM Studio或vLLM + Qdrant + bge-m3
- 规模：100,000-1,000,000文档
- 成本：本地GPU、Qdrant服务器
- 用例：内部文档搜索、知识共享
模式3：企业RAG（混合）
- 设置：vLLM + Milvus + 云嵌入（OpenAI或Cohere）
- 规模：1,000,000+文档
- 成本：Milvus托管 + 嵌入API
- 用例：金融、医疗、法律的合规RAG
常见错误
- 错误1：随意选择片段大小。 结果：检索失败。 → 解决方案：测试256-1000个令牌，用测试集测量。
- 错误2：选择最高维度嵌入。 OpenAI 3072维不必要。 → 解决方案：用nomic-embed-text（768维）获得99%质量，速度快10倍。
- 错误3：嵌入模型领域不匹配。 金融RAG = OpenAI通用嵌入不是最优。 → 解决方案：使用在金融文本上微调的领域特定模型。
- 错误4：幻觉测试不足。 不检查检索片段是否真实出现在答案中。 → 解决方案：自动评分"这个答案来自这个片段吗？"
- 错误5：生产前不评估。 本地测试好，实际用户失败。 → 解决方案：生产前测试10-20个真实用例。
常见问题
本地RAG比云RAG（OpenAI、Cohere）快吗？
是。本地RAG没有网络延迟，<1秒完成检索+生成。云RAG需要2-5秒（API调用）。但云嵌入精度更高（3072维），小测试集更合适。
本地RAG和微调大语言模型的区别？
微调 = 重新训练大语言模型本身（重、慢）。RAG = 搜索外部知识传给大语言模型（轻、实时更新）。RAG更容易添加/删除文档，幻觉率更低。
RAG支持多少向量数据库？
几乎所有：Chroma、Qdrant、Milvus、Weaviate、Pinecone、Redis、Faiss。选择取决于规模：<100万文档 = Chroma（简单），生产 = Qdrant（分布），超大规模 = Milvus。
RAG需要GPU吗？
不需要。CPU + Chroma 能运行。但速度慢（嵌入生成需要数分钟）。加GPU（RTX 4070+）速度快5-10倍。
本地RAG能保证隐私吗？
是。所有数据（文档、嵌入、查询、答案）保留在本地，不通过互联网传输。完全符合GDPR、HIPAA等法规。
参考资源
- LangChain文档 -- https://python.langchain.com/docs/use_cases/question_answering/
- RAG基准测试 -- https://github.com/explodinggradients/ragas
- 嵌入模型对比 -- https://huggingface.co/spaces/mteb/leaderboard
- Qdrant文档 -- https://qdrant.tech/documentation/