---
type: concept
title: RAG（检索增强生成）
created: 2026-04-26
updated: 2026-04-26
tags: [llm, rag, retrieval, vector-search, knowledge-management]
---

## 定义

**RAG（Retrieval-Augmented Generation，检索增强生成）**是一种将外部知识库与 LLM 生成能力结合的技术范式。其核心流程是：在 LLM 回答问题时，先从向量数据库或文档库中检索与问题相关的文本片段（chunks），将这些片段作为上下文注入 LLM 的 Prompt，再由 LLM 基于检索结果生成答案。

RAG 是目前企业和个人在"让 LLM 使用私有文档"场景下最常见的技术方案。但在 [[wiki/entities/andrej-karpathy|Karpathy]] 的 [[wiki/concepts/llm-wiki|LLM Wiki]] 模式提出后，RAG 的局限性受到了更广泛的讨论。

## 核心要点

### RAG 的标准流程

1. **文档预处理**：将文档切分为固定大小的 chunks，向量化后存入向量数据库（如 Pinecone、Chroma、Weaviate）
2. **查询时检索**：将用户问题向量化，与数据库中的 chunks 做相似度匹配，取 Top-K 片段
3. **注入生成**：将检索到的 chunks 拼入 Prompt，LLM 基于这些片段生成答案

### RAG 的优势

- **易于部署**：文档不需要复杂预处理，直接分块向量化即可使用
- **适合大规模文档**：数千万份文档的即时检索是 RAG 的强项
- **知识更新快**：新文档加入后，无需重新训练模型，只需向量化并加入库
- **适合事实查询**：对于"某文档说了什么"类的直接查询效果好

### RAG 的局限性（与 LLM Wiki 对比）

| 局限 | 说明 |
|------|------|
| **知识不积累** | 每次查询独立进行，LLM 无法在会话间积累对某领域的深度理解 |
| **跨文档综合弱** | 需要同时综合 5 篇以上文档的深度推理时，依赖召回质量，容易遗漏关键信息 |
| **矛盾处理盲区** | 当不同文档对同一事实有矛盾时，RAG 系统通常无法识别和标注矛盾 |
| **上下文窗口受限** | Top-K 召回的 chunks 可能无法涵盖所有相关信息，截断导致答案不完整 |
| **无主动知识生产** | RAG 是被动检索工具，不会主动总结、归纳或发现文档间的规律 |
| **可读性差** | 中间状态（向量）对人类不可读，无法像 wiki 页面那样直接被用户浏览和审阅 |

### 适用场景对比

| 场景 | 推荐方案 | 原因 |
|------|---------|------|
| 大型企业文档库的即时问答（数万份文档） | RAG | LLM Wiki 的编译成本在此规模下过高 |
| 个人/小团队的持续知识积累（数十至数百份资料） | LLM Wiki | 知识复利效应显著，综合能力强 |
| 需要跨多文档深度分析 | LLM Wiki | Synthesis 页专为此设计 |
| 文档频繁更新、无需深度综合 | RAG | 快速摄入新文档的优势明显 |
| 需要可读、可审阅的知识库 | LLM Wiki | Markdown wiki 页面人类可读 |

## 不同来源的说法

| 来源 | 观点 |
|------|------|
| [[wiki/library/llm-wiki|Karpathy Gist]] | RAG 是"每次从零开始重新推导"，缺乏知识积累；LLM Wiki 通过预编译解决了 RAG 的根本局限 |
| 业界主流观点（截至 2026 年）| RAG 仍是企业大规模文档问答的主流方案，但在个人知识管理、研究助理等场景中正被 LLM Wiki 类方案挑战 |
| 社区讨论 | 两者并非完全对立，部分实践者将 LLM Wiki 作为 RAG 的前置处理层：先用 LLM Wiki 编译，再用 RAG 检索 wiki 页面 |

## 相关实体

- [[wiki/entities/andrej-karpathy|Andrej Karpathy]]

## 相关概念

- [[wiki/concepts/llm-wiki|LLM Wiki]]
- [[wiki/concepts/knowledge-compilation|知识编译]]

## 参考来源

- [[wiki/library/llm-wiki|llm-wiki（Karpathy Gist）]]