RAG（Retrieval-Augmented Generation，检索增强生成）是解决大模型知识局限和幻觉问题的关键技术。核心思路是：先检索相关知识，再基于检索结果生成回答，从而让 AI 能回答训练数据之外的问题。本文结合行业数据与实践案例，介绍 RAG 的核心原理、架构设计、向量数据库选择与实践步骤。
一、RAG 为何重要：解决大模型的根本问题
大模型存在知识截止、幻觉、无法访问私有数据等问题。RAG 通过「检索 + 生成」的方式，让模型能基于最新、最准确的知识库回答，显著提升回答质量与可信度。
| 问题 | 传统大模型 | RAG 方案 | 改善程度 |
|---|---|---|---|
| 知识时效性 | 训练数据截止日期 | 实时检索最新文档 | 显著提升 |
| 私有数据访问 | 无法访问 | 可检索内部知识库 | 完全解决 |
| 回答准确性 | 可能产生幻觉 | 基于检索结果，可追溯来源 | 提升 40–60% |
| 成本控制 | 需微调模型 | 仅检索 + 生成，成本更低 | 降低 60–80% |
数据来源：LangChain、LlamaIndex 等 RAG 框架的公开测试数据（综合整理）。
根据 Gartner 2025 年 AI 应用调研，约 72% 的企业 AI 应用采用 RAG 架构，用于知识问答、文档摘要、智能客服等场景。下表对比了 RAG 与其他方案的差异：
| 方案 | 适用场景 | 成本 | 准确性 | 实施难度 |
|---|---|---|---|---|
| 纯 Prompt | 通用问答、创意生成 | 低 | 中等（依赖模型知识） | 低 |
| RAG | 知识问答、文档检索、私有数据查询 | 中 | 高（基于知识库） | 中 |
| 微调（Fine-tuning） | 特定领域、风格定制 | 高 | 很高（但需大量数据） | 高 |
| RAG + 微调 | 专业领域 + 知识库 | 很高 | 最高 | 很高 |
二、RAG 核心原理与架构
RAG 的基本流程是：查询 → 检索相关文档 → 将文档作为上下文 → 生成回答。以下介绍核心组件。
2.1 文档处理（Document Processing）
将原始文档（PDF、Word、Markdown 等）切分为小块（Chunk），通常每块 200–500 字。切分策略影响检索效果：太小可能丢失上下文，太大可能引入无关信息。
2.2 向量化（Embedding）
使用嵌入模型（如 OpenAI text-embedding-3、BGE、M3E）将文档块转换为向量，存入向量数据库。查询时，将问题也向量化，通过相似度检索最相关的文档块。
2.3 检索（Retrieval）
根据查询向量，从向量数据库中检索 Top-K（通常 3–5 个）最相关的文档块。常用相似度算法：余弦相似度、点积、欧氏距离。
2.4 生成（Generation）
将检索到的文档块作为上下文，与大模型 Prompt 组合，生成最终回答。Prompt 通常包含：系统提示、检索到的文档、用户问题。
三、向量数据库选择
向量数据库是 RAG 的核心组件，负责存储和检索文档向量。以下对比主流方案：
| 数据库 | 类型 | 优势 | 适用场景 |
|---|---|---|---|
| Pinecone | 云服务 | 易用、托管、高性能 | 快速原型、中小规模应用 |
| Weaviate | 开源/云 | 功能丰富、支持混合检索 | 企业级应用、复杂查询 |
| Qdrant | 开源 | 性能优秀、资源占用低 | 自托管、大规模应用 |
| Chroma | 开源 | 轻量、易集成 | 开发测试、小规模应用 |
| Milvus | 开源 | 可扩展、支持分布式 | 大规模、高并发场景 |
| PGVector（PostgreSQL） | 开源扩展 | 与现有 PG 生态集成 | 已有 PostgreSQL 的项目 |
数据来源：各数据库官方文档与社区评测（综合整理）。
四、RAG 优化要素权重
基于实际项目经验，以下要素对 RAG 效果的影响程度（相对权重，满分 100）：
说明：权重基于对 LangChain、LlamaIndex 等 RAG 项目的实践归纳，非官方披露数据，仅供参考。
五、RAG 实施步骤
按以下步骤逐步实施，可构建一个基础的 RAG 应用：
- 准备文档：收集需要检索的文档（PDF、Markdown、网页等），确保内容准确、格式统一。
- 文档切分：将文档切分为小块（Chunk），建议每块 200–500 字，保留必要的上下文。
- 选择嵌入模型：根据语言（中文/英文）和成本选择嵌入模型，如 OpenAI text-embedding-3、BGE-large-zh-v1.5 等。
- 向量化存储：将文档块转换为向量，存入向量数据库（如 Pinecone、Qdrant）。
- 构建检索流程：实现查询向量化、相似度检索、Top-K 文档获取。
- 设计 Prompt：将检索到的文档作为上下文，设计 Prompt 让大模型基于文档生成回答。可参考本站《Prompt 工程最佳实践》。
- 测试优化：用真实问题测试，根据回答质量调整切分策略、Top-K 数量、Prompt 等。
六、常见问题与优化技巧
RAG 实施中常见问题及解决方案：
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 检索不到相关内容 | 文档切分不当、嵌入模型不匹配 | 调整切分策略、尝试不同嵌入模型、增加 Top-K |
| 回答包含无关信息 | Top-K 过大、未做重排序 | 减少 Top-K、使用 Rerank 模型二次排序 |
| 回答不准确 | Prompt 设计不当、上下文过长 | 优化 Prompt、限制上下文长度、要求模型引用来源 |
| 检索速度慢 | 向量数据库选择不当、索引未优化 | 选择高性能数据库、优化索引参数、使用缓存 |
6.1 重排序（Rerank）
向量检索可能返回语义相似但实际不相关的文档。使用 Rerank 模型（如 Cohere Rerank、BGE Reranker）对 Top-K 结果二次排序，可提升相关性 15–25%。
6.2 混合检索（Hybrid Search）
结合关键词检索（BM25）和向量检索，兼顾精确匹配和语义理解。适用于专业术语多、需要精确匹配的场景。
七、RAG 优化自检清单
RAG 应用上线前，可按下列项自检：
| 检查项 | 优先级 | 是/否 |
|---|---|---|
| 文档已切分为合适大小的块（200–500 字） | 必须 | □ |
| 已选择并测试嵌入模型，向量质量良好 | 必须 | □ |
| 向量数据库已部署并索引文档 | 必须 | □ |
| 检索 Top-K 数量已调优（通常 3–5） | 必须 | □ |
| Prompt 已优化，要求模型基于文档回答 | 必须 | □ |
| 已实现重排序（Rerank）提升相关性 | 建议 | □ |
| 已测试真实问题，回答质量符合预期 | 必须 | □ |
| 已实现来源追溯，可查看引用的文档 | 建议 | □ |
八、小结
RAG 是解决大模型知识局限和幻觉问题的关键技术，通过「检索 + 生成」让 AI 能基于最新、最准确的知识库回答。核心是文档切分、向量化、检索、生成四步，选择合适的向量数据库和嵌入模型是关键。
落地时可从准备文档、文档切分、选择嵌入模型、向量化存储、构建检索流程、设计 Prompt、测试优化七步入手，结合自检清单逐步完善。若希望优化 Prompt 设计以提升生成质量，可参考本站《Prompt 工程最佳实践》；若需要让内容更易被生成式引擎引用，可阅读《如何做好 GEO 生成式引擎优化》。