RAG（Retrieval-Augmented Generation，检索增强生成）
2026/1/5大约 4 分钟
chat
是什么？
下面我从**“为什么需要 RAG → RAG 是什么 → 核心架构 → 关键技术细节 → 常见模式 → 工程落地 → 典型误区与进阶方向”**几个层次，系统、完整地展开介绍 RAG（Retrieval-Augmented Generation，检索增强生成）。
会偏工程与架构视角，结合你过往关注的 知识库 / AI 平台 / 可落地性 来讲。
一、为什么需要 RAG（它解决的根本问题）
1. LLM 的三个先天限制
即使是最强的大模型，也存在硬限制：
知识是静态的
- 训练完成后，模型“冻结”
- 无法天然感知你公司的内部文档、数据库、实时数据
上下文窗口有限
- 再大的 context，本质仍是有限
- 不可能把所有知识都塞进 prompt
幻觉（Hallucination）不可避免
- 在“不确定”时，模型倾向于“合理编造”
👉 结论：
LLM 很擅长“语言与推理”，但不擅长“知识存储与检索”。
2. RAG 的核心思想（一句话版）
把「找资料」这件事交给检索系统，把「理解 + 组织语言」交给大模型。
即：
- 检索（Retrieval）：从真实、可控的数据源中找“相关事实”
- 生成（Generation）：基于事实生成自然语言回答
二、RAG 是什么（标准定义）
RAG（Retrieval-Augmented Generation）
是一种将 外部知识检索系统 与 大语言模型生成能力 结合的架构模式。
其本质不是一个模型，而是一个 系统架构范式。
三、RAG 的标准架构（工程视角）
1. 基本流程（最小闭环）
用户问题
↓
Query 重写 / 向量化
↓
知识检索（Vector / Keyword / Hybrid）
↓
上下文构建（Context Assembly）
↓
LLM 生成答案
↓
答案 + 引用2. 核心组件拆解
（1）知识源（Knowledge Source）
常见类型：
- Markdown / PDF / Word
- Wiki / Confluence / Notion
- 代码仓库（README / API 文档）
- 数据库（结构化数据）
- 日志、告警、工单（你熟悉的领域）
（2）数据切分（Chunking）
这是 RAG 成败的关键点之一
常见策略：
- 固定长度（如 500 tokens）
- 语义切分（按标题 / 段落）
- 滑动窗口（Overlap）
设计原则：
- 太大：召回不准
- 太小：上下文碎片化
（3）向量化（Embedding）
把文本 → 向量
目标：语义相似度
常用模型：
- OpenAI embeddings
- bge / m3e / E5（中文场景常见）
向量维度通常 768 ~ 3072
（4）向量数据库（Vector Store）
职责：近似最近邻搜索（ANN）
常见选型：
- FAISS（本地 / 单机）
- Milvus
- Weaviate
- Qdrant
- pgvector（Postgres）
工程关注点：
- 搜索延迟
- 数据量
- 是否支持 metadata 过滤
（5）检索策略（Retrieval Strategy）
不止“Top-K”这么简单：
- 相似度检索
- 关键词 + 向量混合（Hybrid Search）
- 多路召回（Multi-Retriever）
- Re-ranking（重排序）
（6）Prompt 组装（Context Injection）
把检索到的内容，以结构化方式注入 Prompt
典型 Prompt 结构：
System: 你是一个专业助手
Context:
文档 1
文档 2
文档 3
Question:
用户问题
Instruction:
仅基于上述内容回答，不要编造四、RAG 的常见模式（从简单到复杂）
1. Naive RAG（最基础）
- 单轮问题
- 向量检索 + 拼 Prompt
适合：
- Demo
- 文档问答 PoC
2. Advanced RAG（工程常用）
增强点包括：
- Query Rewriting（把用户问题改写成更“可检索”的形式）
- Re-ranking（Cross-Encoder）
- 多文档融合
- 引用来源
3. Conversational RAG
解决：
- 多轮对话
- 指代消解（“刚才那个方案”）
方式：
- 历史摘要
- Memory + 当前问题联合检索
4. Agentic RAG（你后续一定会用到）
把 RAG 作为 Agent 的一个 Tool：
Agent 决定：
- 查不查？
- 查哪个库？
- 查几次？
典型场景：
- 根因分析
- 复杂决策支持
五、RAG 在你关注领域中的典型应用
1. 企业知识库 / 文档助手
- 技术文档
- 规范 / 流程
- 架构设计说明
👉 RAG 是唯一可控方案
2. 运维 / 监控 / 根因分析（非常关键）
RAG +：
- 告警规则
- 历史事故
- Runbook
- 专家经验
形成：
“经验增强的智能诊断系统”
这与你“AI 根因分析平台”的构想是天然契合的。
3. 研发提效 / AI Coding
- 项目代码 + 设计文档 RAG
- 约束生成风格、架构一致性
六、RAG 的核心工程难点（真实世界）
1. 召回不准 ≠ 模型不行
80% 的问题出在：
- 切分策略
- Query 表达
- 检索策略
2. Prompt 注入 ≠ 上下文越多越好
- 需要 Context Budget 管理
- 信息冲突会直接拉低模型表现
3. 评估困难
RAG 的评估不是 BLEU / ROUGE，而是：
- Recall@K
- Faithfulness（是否编造）
- Groundedness（是否基于事实）
七、RAG 的常见误区
- ❌ 把 RAG 当“外挂搜索”
- ❌ 认为“向量库 = 知识库”
- ❌ 忽视数据治理（版本、权限、生命周期）
- ❌ 不做引用与溯源
八、RAG 的进阶方向（2024–2026）
Graph RAG
- 知识图谱 + 检索
- 非线性关系建模（非常适合根因分析）
Self-RAG / Adaptive RAG
- 模型先判断“需不需要检索”
- 动态控制检索深度
RAG + Tools / MCP
- 把 RAG 作为 Tool，而不是固定流程
RAG + Long-Context
- 不是替代关系，而是互补