RAG（检索增强生成）简介
发布: (2026年3月30日 GMT+8 17:56)
10 分钟阅读
原文: Dev.to
Source: Dev.to
生成式 AI 与 LLM 的局限性
- Stale knowledge – LLM 只能了解截至其训练截止日期之前可用的内容。
- No access to private data – 它们没有在贵公司的内部文档上进行训练，将这些文档暴露给公共模型是不安全的。
- Hallucinations – 当被询问最近或专有信息时，模型可能会礼貌地拒绝，或自信地捏造答案。
常见的变通方法（以及它们为何不足）
| 方法 | 工作原理 | 缺点 |
|---|---|---|
| 微调 | 在您的私有数据上重新训练基础模型，使其能够回答关于该数据的问题。 | • 费用高（计算密集） • 耗时 • 每当数据更改时都必须重新微调 |
| 大上下文提示 | 将所有相关信息打包进提示，并指示模型仅依据这些数据作答。 | • 大型语言模型的上下文窗口有限 • 提示还必须包含系统消息和聊天历史 • 当数据集较大时容易触及令牌上限 |
介绍检索增强生成（RAG）
检索增强生成（RAG） 是一种将大型语言模型（LLM）与外部知识源相结合的 AI 框架。在生成响应之前，系统会 检索 来自可信存储（例如数据库、内部文档）的最相关、最新的信息，并用这些数据 增强 提示。此类 grounding 大幅降低了 hallucinations。
两个核心阶段
- 索引阶段 – 收集文档，将其拆分为块，对每个块进行嵌入，并将嵌入向量存储在向量数据库中。
- 检索阶段 – 给定用户查询，从向量存储中获取最相关的块，并将它们（连同查询一起）输入 LLM 以生成答案。
现实世界的类比
想象一下，你正在主持一场大型颁奖典礼。
完整的剧本包含所有获奖者、每个表演顺序以及你可能需要的每一句台词。
- 问题： 你无法记住整个剧本，也无法在舞台上携带那本巨大的书。
- 解决方案： 你将最重要的信息提取到小提示卡上，放进盒子里，需要时抽取对应的卡片。
| 颁奖典礼要素 | RAG 对应 |
|---|---|
| 完整剧本 | 大规模文档集合 |
| 提示卡 | 小的、语义上有意义的片段 |
| 卡片盒 | 向量存储（向量数据库） |
| 抽取正确的卡片 | 检索器获取最相关的片段 |
| 阅读卡片 | 大语言模型生成有依据的答案 |
RAG 管道组件
- Document Ingestion & Indexing – 从各种来源（文件、API、网页等）获取数据。
- Text Splitters – 将大型文档拆分为可管理的块（例如 500‑1,000 token 窗口）。
- Vector Embeddings – 使用嵌入模型（例如 OpenAI 的
text-embedding-ada-002、Sentence‑Transformers）将每个块转换为稠密向量。 - Vector Store / Vector DB – 持久化嵌入并实现快速相似度搜索（例如 Pinecone、Weaviate、FAISS、Qdrant）。
- Retriever – 根据查询执行最近邻搜索，返回前 k 个最相关的块。
- Prompt Augmentation Layer – 将检索到的块与用户查询结合（通常配合系统提示，指示 LLM 引用来源）。
- LLM (the Generator) – 处理增强后的提示，生成高度准确、无幻觉的答案。
RAG 的优势
- 最新知识 – 检索可以在不重新训练 LLM 的情况下获取最新数据。
- 成本效益 – 无需昂贵的微调；大部分计算用于廉价的嵌入生成和向量搜索。
- 可扩展性 – 向量库能够处理数百万个块，同时保持低延迟（尤其是使用近似最近邻索引）。
- 可解释性 – 检索到的块可以作为引用展示给用户，提升信任度。
缺点与挑战
| 问题 | 为何重要 |
|---|---|
| 检索依赖性 | 如果检索器返回不相关、过时或不完整的片段，LLM 的答案将受到影响。 |
| 性能与延迟 | 添加检索步骤（嵌入查找 + 相似度搜索）会引入额外的延迟，这在实时使用场景中可能成为问题。 |
| 系统复杂性 | 构建、监控和维护摄取管道、向量数据库以及检索逻辑会增加运维负担。 |
| 嵌入漂移 | 嵌入模型会演进；更换嵌入模型可能需要对整个语料库重新建立索引。 |
| 安全与访问控制 | 敏感文档必须安全存储，检索过程必须遵守权限边界。 |
快速参考清单
- Ingest all relevant documents (internal wikis, PDFs, DB dumps).
摄取 所有相关文档（内部维基、PDF、数据库转储）。 - Chunk them using a suitable text splitter (sentence, paragraph, or token‑based).
使用合适的文本分割器（句子、段落或基于标记）对其进行 Chunk。 - Embed each chunk with a reliable embedding model.
使用可靠的嵌入模型对每个块进行 Embed。 - Store embeddings in a performant vector DB with appropriate indexing (IVF, HNSW, etc.).
将嵌入存储在性能良好的向量数据库中，并使用适当的索引（IVF、HNSW 等）进行 Store。 - Configure a retriever that returns top‑k results with a relevance threshold.
Configure 一个检索器，使其返回前 k 条结果并设定相关性阈值。 - Design a prompt template that cleanly injects retrieved context and asks the LLM to cite sources.
Design 一个提示模板，干净地注入检索到的上下文，并要求 LLM 引用来源。 - Monitor latency, retrieval quality, and LLM output for hallucinations.
Monitor 延迟、检索质量以及 LLM 输出的幻觉情况。 - Secure the pipeline (encryption at rest, access controls, audit logs).
Secure 管道安全（静态加密、访问控制、审计日志）。
TL;DR
RAG 让你在保持 LLM 精简 的同时，按需提供 对新鲜、私有且可信的数据的访问。通过将知识存储（向量存储）与生成（LLM）分离，你可以避免昂贵的微调，保持在上下文限制之内，并显著降低幻觉——前提是你要管理好检索质量、延迟和系统复杂度。
构建和维护 RAG 系统的挑战
- 数据库、嵌入和检索管理 – 更新知识库需要复杂的重新索引和重新嵌入。
- 数据安全和隐私风险 – 如果访问控制未得到严格实施，RAG 系统可能会将敏感或专有的内部数据暴露给未授权用户。
- 上下文理解失败 – RAG 系统在处理复杂的跨学科查询或将检索到的零散信息进行关联时可能会出现困难，导致输出不连贯。
- 成本 – 运行 RAG 系统可能成本高昂，需要向量存储基础设施以及为检索和生成过程提供更多计算资源。
- 分块错误 – 文档划分不当可能导致关键信息缺失或断裂。
- 调试困难 – 由于管道涉及多个活动部件（检索器 + LLM），定位糟糕答案的根本原因变得复杂。
结论
简而言之，RAG 是一种实用的方法，使 AI 更加智能并更好地满足您的特定需求。与其花费大量时间和金钱从零开始“教会” AI 所有知识，RAG 只需让 AI 在回答问题之前能够查阅您私有文档中的事实——就像开卷考试一样。