← 返回文章列表

什么是 RAG

RAG（Retrieval-Augmented Generation，检索增强生成）是一种方法：语言模型在回答之前先从你的知识库中检索相关片段，再生成文本。它不必把所有文档"记"进模型权重，也不必整份载入上下文，而是搜索合适段落并注入 prompt。下文介绍 RAG 是什么、流水线如何工作，以及何时适合用于生产环境。

通俗定义

检索增强生成包含两个阶段：

  1. Retrieval（检索） - 根据用户问题，在语料库中找到最匹配的文本片段：wiki、PDF、工单、代码、规章。
  2. Generation（生成） - LLM 将检索到的片段作为上下文，据此组织回答。

该概念在 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. 查询（在线）

  1. 用户问题用同一编码器嵌入。
  2. 向量库返回 Top-K 最近邻 chunk（通常 K = 3-10）。
  3. 可选 重排序（Reranking） - 第二模型比纯余弦相似度更准地按相关性排序。
  4. 检索片段写入 system/user prompt，并指示「仅依据上下文回答」。
  5. 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 解决知识接入，但不能：

  • 保证事实准确（模型可能忽略上下文）
  • 完成复杂多步操作（需 tools / MCP）
  • 自动保持索引最新（文档变更需 ETL）

典型故障：

  • 分块不当 - 表格被拦腰切断、公式失去标题。
  • K 值不对 - chunk 太少漏事实；太多则 prompt 噪声大。
  • 索引过期 - 文档已改，嵌入未重算。
  • 未配混合检索 - 纯语义搜索对 SKU、ID、日期不准；混合检索（BM25 + 向量）有帮助。

生产环境应监控检索命中率、对 chunk 大小做 A/B、收集人工反馈、设置「置信度低则不答」护栏。

如何改进 RAG 系统

  1. 元数据 - 部门标签、日期、文档版本；向量检索前过滤。
  2. 混合检索 - 关键词（BM25）+ 语义；技术文档尤其有效。
  3. Reranker - 初筛 Top-20 后用 cross-encoder 得到最终 Top-5。
  4. 查询变换 - 改写、多查询、HyDE（假设文档）。
  5. Graph RAG - 在扁平 chunk 之上处理关联实体（人、项目、依赖）。
  6. 评估 - 问答金标准数据集；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 是在不重训模型的前提下，把 LLM 接到你的数据上的标准做法：文档被索引，按问检索相关片段，模型据此作答。可从 Chroma + OpenAI 原型扩展到带混合检索、重排序与质量监控的集群。

首个项目建议：选一个语料（如 50 页 FAQ），调好分块与 Top-K，测量正确段落是否进入上下文 - 这是系统成败的主要预测指标。

常见问题

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：文档不出边界，流水线架构与云端相同。

联系方式