什么是 RAG？检索增强生成的实用指南

你问 ChatGPT 一个关于公司内部 HR 政策的问题,它一本正经地胡说八道。或者你问 Claude 上个月才发布的某个库的 bug,它引用了根本不存在的 API。模型不是在"说谎",只是它的权重里没有这些信息。RAG 就是目前最主流的解决办法。

一句话讲清核心思路

RAG 的全称是 Retrieval-Augmented Generation(检索增强生成)。它不只依赖 LLM 训练时记住的内容,而是在收到问题的瞬间做两件事:第一,从外部知识源(通常是向量数据库,有时是关键词索引或 SQL)检索最相关的文本片段;第二,把这些片段塞进 prompt 再让模型回答。模型基于检索到的内容作答,而不是凭参数化记忆瞎猜。

所以一个典型的 RAG prompt 长这样:"以下是公司内部文档的 5 段内容,请仅基于这些信息回答用户的问题:……"。聪明之处不在生成,而在"怎么从上百万段文本里挑出对的那 5 段"。

RAG 解决的三个痛点

LLM 有三个众所周知的局限,RAG 刚好对症。

知识截止时间。 GPT-4o、Claude Sonnet、Gemini 都有训练截止日,之后发生的事,还有它们从未见过的你公司内部文档,全是盲区。RAG 在推理时注入新鲜或私有数据,你不必每次 Confluence 改一页就重训模型。

幻觉(hallucination)。 模型不知道答案时倾向于编造听起来合理但其实错的内容。把检索到的段落喂进去,可以大幅降低(但无法消除)幻觉,因为模型有具体文字可以参照。更好的是可以附引用——"这个答案来自员工手册第 14 页"——让整个系统可被审计。

Context window 的成本。 就算 Gemini 有 2M token、Claude 有 200K,你也不可能把整个 50GB 的文档库塞进每一个 prompt。RAG 只挑出真正相关的片段,比如 8 段、每段 500 token,总共 4K token 的上下文,比全塞进去快得多也便宜得多。

RAG 系统实际怎么搭

一个上生产的 RAG pipeline 有两个阶段,跑在不同时间。

索引阶段(离线,文档变动时跑):

从 Notion、Google Drive、GitHub、PDF、数据库等加载文档。
把文档切块(chunking)。按固定 500 token 切是粗糙做法;按段落、章节、Markdown 标题做语义切块通常检索效果更好。
用 embedding 模型把每块转成向量,比如 OpenAI 的 text-embedding-3-small、Cohere 的 embed-v3,或开源的 bge-m3。
把向量存进向量数据库——Pinecone、Weaviate、Qdrant、pgvector,或原型阶段用 Chroma。

查询阶段(在线,每个请求都跑):

用同一个 embedding 模型把用户问题转成向量。
做相似度搜索(cosine 或 dot product),取 top-k 段。
可选但强烈建议:用 cross-encoder 做 rerank,比如 Cohere Rerank 或 bge-reranker。这一步比大多数人以为的更关键。
把检索到的段落 + 问题拼成 prompt,送给 LLM。
返回答案,最好附上指回原文的引用。

整套东西用 LangChain 或 LlamaIndex 大概 200 行 Python 就能跑起来。难的不是代码,是针对你自己的数据调 chunk 大小、检索质量和 prompt 结构。

真实产品里的 RAG 长什么样

Cursor 和 GitHub Copilot 对你的代码库做 RAG:你问"我们在哪里处理 Stripe webhook?",它不是在你的 repo 上 fine-tune,而是检索相关文件。Perplexity 对实时网页做 RAG——这基本上就是它整个产品。Notion AI 的问答在你的 workspace 上做检索。ChatGPT 的"带知识的 Custom GPT"就是托管版 RAG,Claude Projects 也是一个意思:上传文件、提问、背后检索。

企业里最常见的 RAG 场景:客服机器人查帮助中心、内部知识助手查 Confluence/SharePoint、法务查合同、开发助手查私有代码。

什么时候不适合用 RAG

RAG 不是万能药。AI 咨询行业有个坏毛病是把它卖给所有人。

内容塞得进 context 就别上 RAG。 如果你的知识库就一份 30 页 PDF,直接贴进 prompt。Gemini 1.5 Pro 或开了 prompt caching 的 Claude 处理长 context 又快又便宜,还省掉一整层基础设施。只有当文档量远超过 prompt 容量时,RAG 才有意义。

想改的是"行为"而不是"知识"别用 RAG。 想让模型用你的品牌口吻写作、输出特定格式、学会新任务?那是 fine-tuning 的活。RAG 加事实,fine-tuning 加技能。

数学、推理、聚合类问题别用 RAG。 "我们 10,000 张工单里有多少提到发货延迟?"这不是检索问题,是分析问题,该用 SQL 或结构化 pipeline。RAG 只会捞段落,不会数数。

数据高度结构化时要警惕。 如果你的"知识"其实是商品目录、库存、CRM,直接查数据库在准确度和延迟上通常都赢向量搜索。混合架构(function calling → SQL)往往比纯 RAG 好用。

没人会告诉你的坑

Demo 看起来很神,上线后一地鸡毛。真正的失败模式:

瓶颈在检索不在生成。 对的段落没进到 top-k,模型再聪明也答不对。大部分"RAG 不准"的抱怨,根本原因是检索召回率只有 40%。
Chunking 会破坏上下文。 一段写着"这种做法很危险"的文字,不知道在讲哪种做法就毫无意义。好的切块要保留足够上下文,常见做法是重叠窗口或 parent-document retrieval。
Embedding 有盲区。 它擅长处理同义改写,但对罕见专有名词、缩写、数字常常翻车。混合搜索(BM25 + 向量)几乎都赢纯向量。
索引会过期。 文档改了,索引要跟着更新。听起来很基本,直到你的 pipeline 默默坏掉三周才被发现。
评测很难做。 "答案有没有用对来源?"远比"答案听起来合不合理?"难量化。Ragas、TruLens、LangSmith 可以帮忙,但你还是需要一份人工标注的评测集。

延伸阅读

接下来值得跟进的概念:embeddings(文本怎么变成向量)、向量数据库、chunking 策略、hybrid search 与 reranking、fine-tuning vs RAG(各自适用场景)、长 context window(小语料的替代方案),以及 agentic RAG(模型自己决定要不要检索、检索什么)。

最快的学法是先做一个玩具版:100 份文档、Chroma、OpenAI embedding、50 行代码。然后故意丢刁钻问题去打它,看检索在哪里崩——一个下午学到的东西,比看十篇教程都多。