什么是 RAG
RAG（Retrieval-Augmented Generation，检索增强生成）是一种方法：语言模型在回答之前先从你的知识库中检索相关片段，再生成文本。它不必把所有文档"记"进模型权重，也不必整份载入上下文，而是搜索合适段落并注入 prompt。下文介绍 RAG 是什么、流水线如何工作，以及何时适合用于生产环境。
通俗定义
检索增强生成包含两个阶段：
该概念在 Lewis 等人（2020）之后迅速普及，成为企业聊天机器人、客服系统和内部助手的标配。RAG 不替代模型 - 而是用训练中没有或昨天才变更的最新数据来增强它。
RAG 如何工作：典型流水线
┌──────────┐ ┌─────────────┐ ┌──────────────┐ ┌─────────┐
│ 文档 │───▶│ 分块+嵌入 │───▶│ 向量数据库 │ │ │
│ (PDF,MD) │ │ Embeddings │ │ (索引) │ │ LLM │
└──────────┘ └─────────────┘ └──────┬───────┘ │ │
│ │ │
用户提问 ──▶ 嵌入 ──▶ Top-K ──▶ Prompt + 上下文 ──▶ 回答
1. 数据准备（离线）
- 导入 - 解析 PDF、HTML、Markdown、Confluence、Notion、代码仓库。
- 分块（Chunking） - 切成 256-1024 token 的片段，带重叠，避免在段落边界截断语义。
- 嵌入（Embedding） - 用嵌入模型把每个 chunk 转为向量（OpenAI text-embedding-3、Cohere、开源 BGE、E5）。
- 索引 - 向量存入 向量库：Pinecone、Weaviate、Qdrant、pgvector、Chroma、Milvus。
此阶段在文档新增或更新时执行，而非每次用户提问。
2. 查询（在线）
- 用户问题用同一编码器嵌入。
- 向量库返回 Top-K 最近邻 chunk（通常 K = 3-10）。
- 可选 重排序（Reranking） - 第二模型比纯余弦相似度更准地按相关性排序。
- 检索片段写入 system/user prompt，并指示「仅依据上下文回答」。
- LLM 生成回答；常附带 引用 chunk id 或源页码。
RAG 质量约 80% 取决于检索：若正确片段未进 Top-K，模型要么幻觉，要么诚实说「不知道」。
核心组件
| 组件 | 作用 | 示例 |
|---|---|---|
| 嵌入模型 | 文本 → 语义搜索向量 | text-embedding-3-large、bge-m3、voyage-3 |
| 向量数据库 | 存储与 ANN 快速检索 | Qdrant、Pinecone、pgvector、Weaviate |
| 分块策略 | 平衡粒度与噪声 | 固定长度、语义切分、按标题 |
| LLM | 最终推理与回答 | GPT-5.6、Claude Fable 5、Gemini 3.1、本地模型 |
| 编排层 | 串联步骤、缓存、日志 | LangChain、LlamaIndex、Haystack、自研 |
2026 年许多框架（LlamaIndex、LangGraph）和产品（Cursor @Codebase、Notion AI、类 Glean 企业系统）在底层实现 RAG，但要调试和调优仍需理解基础流水线。
实际应用场景
- 客服与 FAQ - 基于文章库和历史工单回答，无需人工检索。
- 内部 wiki - 「如何请假」「 incident runbook 在哪」。
- 法务与合规 - 在合同、规章中搜索并引用条款。
- 代码助手 - 对仓库做语义搜索（文件索引 + 嵌入），补充 IDE 中的完整上下文。
- 文档分析 - 对报告、研究、会议记录提问。
常见模式：语料大、更新频、需要出处 - RAG 比一次性把文件丢进聊天更合适。
RAG vs 微调 vs 长上下文
| 方式 | 适用场景 | 局限 |
|---|---|---|
| RAG | 文档常更新、来源透明、无需重训 | 依赖检索质量 |
| 微调 | 风格、格式、领域术语、稳定知识 | 数据变更后更新成本高 |
| 长上下文 | 单次会话需要整份文档或整个代码库 | 成本、延迟、「中间迷失」 |
三者不互斥。2026 常见组合：RAG 搜大语料 + 长上下文承载少量完整文件 + 轻量微调或 system prompt 统一语气。
局限与常见问题
RAG 解决知识接入，但不能：
典型故障：
- 分块不当 - 表格被拦腰切断、公式失去标题。
- K 值不对 - chunk 太少漏事实；太多则 prompt 噪声大。
- 索引过期 - 文档已改，嵌入未重算。
- 未配混合检索 - 纯语义搜索对 SKU、ID、日期不准；混合检索（BM25 + 向量）有帮助。
生产环境应监控检索命中率、对 chunk 大小做 A/B、收集人工反馈、设置「置信度低则不答」护栏。
如何改进 RAG 系统
- 元数据 - 部门标签、日期、文档版本；向量检索前过滤。
- 混合检索 - 关键词（BM25）+ 语义；技术文档尤其有效。
- Reranker - 初筛 Top-20 后用 cross-encoder 得到最终 Top-5。
- 查询变换 - 改写、多查询、HyDE（假设文档）。
- Graph RAG - 在扁平 chunk 之上处理关联实体（人、项目、依赖）。
- 评估 - 问答金标准数据集；faithfulness、context recall（RAGAS、DeepEval）。
先从简单流水线（分块 → 嵌入 → Top-5 → GPT）测 baseline，只在指标提升处增加复杂度。
RAG 与智能体生态
RAG 常与 MCP 和 tool calling 配合：RAG 从文档取知识，tools 执行动作（建工单、查余额）。Cursor 的语义索引 @Codebase 是对项目文件的 RAG 变体；企业栈将同一模式扩展到 Confluence、Slack、CRM。
| 层 | 任务 |
|---|---|
| RAG | 「文档里写了什么？」 |
| MCP / tools | 「系统里现在是什么？去执行」 |
| LLM | 综合回答与规划步骤 |
RAG 不适合的场景
RAG 会带来工程复杂度并需要持续维护，因此并非总值得引入：
- 知识库很小且几乎不变 - 直接把文本粘进 system prompt 即可，不需要检索或向量数据库。
- 没有资源维护流水线 - 文档变更时需要更新索引，还要持续监控检索质量；没有专门团队或供应商负责，系统会很快过时并开始给出错误答案。
- 需要保证准确性 - 涉及计算、法律措辞等容不得出错的任务，确定性系统加人工复核比模型生成更可靠。
- 任务是执行动作而非检索文档 - 建工单、修改记录等，仅靠 RAG 无法完成，需要 tools/MCP（见下文）。
启动前建议先估算文档量、变更频率以及由谁负责维护索引 - 这决定了 RAG 是否划算，还是更简单的方案就够用。
总结
RAG 是在不重训模型的前提下，把 LLM 接到你的数据上的标准做法：文档被索引，按问检索相关片段，模型据此作答。可从 Chroma + OpenAI 原型扩展到带混合检索、重排序与质量监控的集群。
首个项目建议：选一个语料（如 50 页 FAQ），调好分块与 Top-K，测量正确段落是否进入上下文 - 这是系统成败的主要预测指标。
如需开发、AI 部署或网站运维方面的帮助 - 请与我联系。
常见问题
RAG 与微调有何区别？
微调用样本改变模型权重 - 适合风格、格式和稳定模式。RAG不改权重：每次请求从索引拉最新片段。每周变的文档用 RAG（重建索引）比重训更省事。微调适合模型应「背熟」流程；RAG 适合重视时效与出处。
模型有百万 token 上下文还需要 RAG 吗？
长上下文（Claude、Gemini、GPT-5.6 的 1M+ token）可在单次会话载入大量文本，但不能替代大语料的 RAG：100 GB PDF 放不进 prompt，成本与延迟线性增长。RAG 选相关片段；长上下文适合检索后的少量完整文件或 IDE 中的仓库代码。实践中常两者并用。
RAG 该选哪种向量库？
视规模与基础设施而定。pgvector - 已有 PostgreSQL、向量量级百万以内。Qdrant、Weaviate、Milvus - 增长期自托管或托管。Pinecone - 免运维集群。Chroma - 快速原型。关键在嵌入质量、分块与监控；许多生产系统从 Chroma 迁到 pgvector 或 Qdrant 而应用逻辑不变。
RAG 为何有时答错？
主因：(1) 检索未命中 - 正确 chunk 未进 Top-K；(2) 模型忽略上下文 用「记忆」补全；(3) 索引过时；(4) chunk 互相矛盾。可通过混合检索与 reranker、严格 prompt（「上下文没有就说不知道」）、引用来源和 eval 集防回归来改善。
能用本地模型做 RAG 吗？
可以。嵌入模型（bge-m3、nomic-embed）与 LLM（Ollama 上的 Llama、Qwen、Mistral）可离线运行；向量库也可本地部署。限制是硬件一般时检索与生成质量；需按 GPU/RAM 选模型规模。医疗、金融、政务等敏感场景常用本地 RAG：文档不出边界，流水线架构与云端相同。
本文术语
RAG — Retrieval-Augmented Generation — 检索增强生成
retrieval — finding relevant context before generation — 生成前先检索相关上下文
LLM — Large Language Model — 大语言模型
Confluence — Atlassian wiki for team documentation — Atlassian 团队文档 Wiki
chunking — splitting documents into retrieval-friendly pieces — 将文档切分为便于检索的片段
embedding — numeric vector that captures text meaning — 表示文本语义的数值向量
Pinecone — managed vector database for similarity search — 托管型向量相似度检索数据库
pgvector — PostgreSQL extension for vector search — PostgreSQL 的向量搜索扩展
reranking — reordering search results by relevance — 按相关性重排搜索结果
Qdrant — vector database for similarity search — 用于相似度检索的向量数据库
Chroma — open-source embedding database for RAG apps — 面向 RAG 应用的开源向量库
LlamaIndex — framework for connecting LLMs to private data — 将 LLM 连接到私有数据的框架
top-k — keep only the k most likely next tokens when sampling — 采样时只保留概率最高的 k 个 token
LangChain — framework for building LLM applications — 构建大语言模型应用的框架
LangGraph — framework for stateful AI agent workflows — 有状态 AI 代理工作流框架
system prompt — hidden instructions that steer the model for a task — 引导模型行为的隐藏系统指令
ANN — Approximate Nearest Neighbor — 向量空间中的近似最近邻搜索
runbook — step-by-step playbook for incidents and operations — 事故与运维的逐步操作手册
cross-encoder — rerank model that scores query and document together — 把查询与文档一起打分的重排模型
faithfulness — how well an answer sticks to the retrieved sources — 回答是否忠实于检索到的来源
tool calling — model invoking external tools or APIs — 模型调用外部工具或 API
reranker — model that reorders search hits by relevance — 按相关性重排搜索结果的模型
MCP — Model Context Protocol — 模型上下文协议
ETL — Extract, Transform, Load — 提取、转换、加载
SKU — Stock Keeping Unit — 库存单位
baseline — reference measurement before changes
CRM — Customer Relationship Management — 客户关系管理
GPT — Generative Pre-trained Transformer — 生成式预训练变换模型系列
Ollama — tool to run local open-weight LLMs on your machine — 在本地运行开源权重大模型的工具
GPU — Graphics Processing Unit — 图形处理器