一句话解释RAGRetrieval-Augmented Generation检索增强生成是一种让大模型在回答前先从外部知识库检索相关资料再基于检索结果生成答案的方法。更直白地说不要只让模型“凭记忆回答”而是让它先“查资料”再“带着资料回答”。为什么最近变火RAG 的正式命名通常追溯到 2020 年 Lewis 等人的论文Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。但它真正成为 AI 应用开发中的高频词是在 2023 年 ChatGPT 和企业大模型应用爆发之后。原因很简单大模型很会生成语言却并不天然知道你的私有文档、公司制度、项目代码、数据库记录和最新业务变化。即使模型在训练时见过大量公开知识它的知识也可能过时、不完整甚至会在不确定时编造答案。企业和开发者很快遇到几个现实问题公司知识库、合同、产品文档、客服手册不在模型训练数据里。重新训练或微调大模型成本高也不适合频繁变化的资料。用户希望答案能引用来源而不是只得到一段看似可信的文本。长上下文模型虽然能塞入更多资料但仍需要知道“该塞哪些资料”。真实应用需要权限控制、审计、更新、可追溯而不是一次性聊天。RAG 正好提供了一个务实方案把“知识存储”和“语言生成”分开。知识放在外部系统里模型需要时检索模型负责理解问题、整合资料、生成回答。这让 RAG 成为大模型应用的第一批核心工程模式之一。它不要求你重新训练一个模型就能让通用大模型接入企业私有知识、最新信息和可引用来源。它解决了什么问题知识过时模型训练数据有截止时间外部知识库可以持续更新。私有知识缺失企业文档、内部制度、代码仓库、客户记录可以通过检索提供给模型。幻觉风险让模型基于检索材料回答可以降低凭空编造的概率。答案可追溯检索结果可以作为引用来源方便用户检查。微调成本高很多知识更新不需要改模型参数只需要更新索引。上下文有限不是把所有文档塞给模型而是先筛选最相关片段。权限与合规检索层可以控制用户能访问哪些资料。需要注意RAG 不是“消灭幻觉”的魔法。它只是把模型回答的依据从内部参数扩展到外部知识。检索错了、资料过时、上下文拼接混乱、模型忽略证据仍然会导致错误答案。核心概念1. 生成模型生成模型通常是大语言模型例如 GPT、Claude、Gemini、Llama、Mistral 等。它负责理解用户问题、阅读检索结果并生成自然语言答案。在 RAG 中生成模型不是唯一主角。它更像一个会读资料、会总结、会解释的写作者。它写得好不好取决于模型能力也取决于给它的资料是否准确、完整、相关。2. 检索器检索器负责从知识库中找出和用户问题相关的内容。它可以基于关键词也可以基于语义向量还可以混合使用。常见检索方式包括检索方式核心思想优点局限关键词检索根据词项匹配例如 BM25对精确术语、编号、名称很有效不理解同义表达和语义相似向量检索用 embedding 表示语义相似度能找语义相关内容可能忽略精确词、数字、过滤条件混合检索结合关键词和向量兼顾精确匹配和语义匹配系统更复杂需要调参图检索利用实体、关系和知识图谱适合复杂关系和全局总结构建和维护成本更高3. EmbeddingEmbedding 是把文本、图片、代码等内容转换成向量表示的方法。相似含义的内容在向量空间中通常距离更近。例如如何申请年假 年假审批流程是什么这两句话字面不完全相同但语义接近。向量检索可以帮助系统找到相关制度文档。为什么向量距离能表达语义很多人第一次听到用余弦相似度衡量句子语义会觉得奇怪几个浮点数怎么会知道两句话意思相近直觉可以从早期词向量讲起。Word2Vec、GloVe 训练时让经常出现在相似上下文的词在向量空间中相互靠近。结果就出现了那个著名的king − man woman ≈ queen——性别维度、王室维度都被自动编进了向量的不同方向。现代句子 embedding如 BGE、E5、OpenAI text-embedding-3、Cohere Embed规模更大、训练数据更多但核心思想一致用对比学习把互相相关的内容在向量空间拉近、把无关内容推远。在训练目标的反复打磨下向量的不同维度会捕捉不同语义特征——话题、情绪、领域、是否是问句等等。所以向量距离 ≈ 语义距离不是巧合而是训练目标直接造成的。理解这一点可以解释 RAG 工程里几条经验规则通用 embedding 在专业领域法律、医疗、代码效果可能不佳——训练数据没覆盖这种语义多语言场景下要用专门训练过的多语种 embedding否则跨语言相似度不可靠同一个查询用不同 embedding 模型会得到完全不同的检索结果——这不是 bug是各模型对相似的定义不一样。4. ChunkChunk 是把长文档切成较小片段。RAG 通常不会把整本手册直接放进索引而是切成一段一段方便检索和放入模型上下文。切分看似简单实际很关键。切得太短片段缺少上下文切得太长检索不够精确也浪费上下文窗口。好的 chunk 策略会考虑标题、段落、表格、代码块、章节结构和语义边界。Chunk 的几个关键参数经验数字仅供参考需要按业务评测调整chunk size常见经验值是200-800 token。文本越规整、问答越细颗粒可以越小技术手册、合同条款这类需要完整段落的场景适合更大。overlap重叠相邻 chunk 之间留10-20% 的重叠避免关键信息正好被切在边界上。比如一个 500 token 的 chunk 配 50-100 token 的 overlap。切分单位优先按段落 → 句子 → 字符层级切避免在句子中间硬截断。代码用 AST 节点切、Markdown 用标题/段落切、表格按行切。保留上下文除了 chunk 正文最好在每段前面加上来源标题、章节路径如第 3 章 3.2 节 报销流程这样模型读到 chunk 时知道它来自哪。更高级的做法包括Parent-Child Chunking用小 chunk 做精确检索命中后返回它所在的更大 parent 段落给模型兼顾召回精度和上下文完整性Semantic Chunking用 embedding 找语义跳变点让分块顺着语义边界而不是固定长度Late Chunking先对整篇文档做 embedding再按位置切——保留全文上下文影响下的局部向量。实际项目中chunk 策略的好坏只能靠评测验证。两个 chunk 配置在不同领域语料上的检索召回率可能差几十个百分点。5. Reranking第一轮检索通常会召回多个候选片段但它们不一定都适合最终回答。Reranking 会对候选结果重新排序把更相关、更可靠的片段排在前面。Bi-Encoder vs Cross-Encoder为什么需要两步理解 reranker 的关键是看清召回和精排用的是两种不同的编码方式维度Bi-Encoder双塔编码器Cross-Encoder交叉编码器编码方式Query 和 Doc 分别独立编码成向量Query 和 Doc 拼接后一起送进模型打分计算时机Doc 向量可提前计算并存入向量库必须在查询时实时计算速度快单次查询毫秒级扫百万级文档慢每个候选都要跑一次模型准确度中缺少 Query-Doc 交互信息高模型能直接看到两者关系典型用法向量库召回阶段top-50 ~ top-200精排阶段重排成 top-3 ~ top-10代表模型BGE、E5、text-embedding-3BGE-Reranker、Cohere Rerank、Jina Reranker工程上常见的两阶段流水线用户查询Bi-Encoder 召回 top-100Cross-Encoder 精排 top-5送给 LLM 生成为什么不直接用 Cross-Encoder因为它无法预计算——每一对 (query, doc) 都要单独跑一次模型。对一个百万级文档库单查询就要算百万次完全不可行。Bi-Encoder 牺牲一点精度换百万倍速度先把范围缩到 50-200 个候选再让 Cross-Encoder 精排这样质量和成本就能兼顾。近年还出现了late interaction路线如 ColBERT、ColPali把每个 token 单独 embedding检索时再做 token 级交互。它在质量和速度之间找了另一个折衷点常用于高质量企业 RAG。可以把检索分成两步召回先尽量把可能相关的内容找出来。重排再精细判断哪些内容最值得给模型。这和搜索引擎很像。第一步要“别漏掉”第二步要“排得准”。工作原理一个典型 RAG 系统分为两个阶段离线建库和在线问答。离线阶段负责准备知识库收集资料PDF、网页、Markdown、数据库、代码、客服记录等。清洗内容去掉噪声、重复、导航栏、无意义格式。文档切分按章节、段落或语义边界切成 chunks。生成向量为每个 chunk 计算 embedding。建立索引把文本、元数据、向量存入检索系统。在线阶段负责回答用户问题用户提出问题。系统对问题做改写、扩展或生成 embedding。检索器从知识库找相关 chunks。可选reranker 重新排序。系统把最相关材料放进 prompt。大模型基于材料生成答案。返回答案、引用来源和必要说明。更成熟的 RAG 系统还会加入权限过滤、结果去重、上下文压缩、冲突检测、引用校验、日志记录、反馈学习和自动评估。一个关键点RAG 是系统不是一个模型很多初学者会以为 RAG 是某种模型名称。更准确地说RAG 是一种系统架构。它把检索系统和生成模型组合起来让模型能利用外部知识。因此RAG 做得好不好不能只看大模型强不强还要看文档是否干净chunk 是否合理embedding 是否适合领域检索是否准确reranker 是否有效prompt 是否能约束模型基于证据回答引用是否可追溯用户权限是否正确评估集是否覆盖真实问题。RAG 很像一个资料室加一位写作者。写作者再聪明如果资料室混乱、索引错误、拿到的材料不相关也很难写出可靠答案。RAG 质量拆解召回、排序、生成、引用初学者调 RAG 时常犯的错误是看到答案错了就马上换模型。实际上RAG 的质量至少要拆成四层看层次要回答的问题常见失败召回相关资料有没有被找出来embedding 不适合领域、chunk 太碎或太长、查询改写错误排序最有用的资料有没有排在前面top-k 太大引入噪声reranker 缺失或不适配领域生成模型是否基于证据回答模型使用常识补全、忽略检索资料、上下文冲突未处理引用答案能否追溯到来源引用片段不能支持结论、引用旧版本文档、权限过滤缺失因此排查 RAG 问题时可以按顺序问相关文档是否在知识库里相关 chunk 是否被检索出来被检索出来的 chunk 是否排在足够靠前的位置Prompt 是否明确要求“只基于资料回答”答案中的每个关键结论是否能被引用支持如果第 2 步就失败问题在检索不在模型如果检索正确但回答编造问题在上下文构造、生成约束或引用校验如果引用看似存在但不能支持结论问题在答案验证。这样拆开看RAG 才能从 demo 走向可维护系统。典型应用场景1. 企业知识库问答这是最典型的 RAG 场景。员工可以询问公司制度、报销流程、产品文档、技术规范、项目历史等问题系统从内部知识库检索资料后回答。关键要求是权限控制。不同员工能访问的文档不同RAG 系统必须先过滤用户无权访问的资料再交给模型生成答案。2. 客服和售后支持客服系统可以把产品手册、FAQ、工单记录、历史解决方案作为知识库。用户提问时系统检索相关条款或步骤再生成更自然的回答。这类场景要特别注意答案准确性。不能为了语气流畅而编造政策或承诺因此通常需要引用原文、设置拒答规则并在高风险问题上转人工。3. 法务、合同和合规审查合同条款、法规、内部政策和历史案例都适合 RAG。模型可以帮助查找相关条款、总结差异、提示风险。但法务场景不能只依赖模型结论。RAG 更适合做辅助检索和草稿总结最终判断仍需要专业人员审核。4. 代码库问答与开发助手开发者可以问“这个函数在哪里被调用”“登录流程如何实现”“为什么这个测试失败”系统从代码仓库、文档、Issue、PR 记录中检索相关片段再让模型解释。代码 RAG 不只是检索文本还需要理解符号、依赖、调用关系和文件结构。成熟系统往往会结合全文检索、语义检索、AST、语言服务器和执行结果。5. 研究助手和资料综述RAG 可以帮助读论文、查资料、整理引用。用户提出研究问题系统检索相关论文段落、报告、网页再生成结构化综述。这类场景的关键是引用质量。模型应该明确区分“资料中有证据的内容”和“根据资料推断的内容”。和其他概念的区别概念解决的问题典型做法和 RAG 的关系RAG给模型补充外部知识检索相关资料后生成答案核心是“先查再答”Fine-tuning让模型学会特定风格、格式或任务能力用训练数据更新模型参数适合行为和格式不适合频繁更新事实Prompt Engineering改善单次输入对模型的引导写更好的指令和示例RAG 会把检索内容放进 promptContext Engineering系统性组织模型上下文管理指令、记忆、检索、工具结果RAG 是上下文工程的重要组成部分Vector Database存储和检索向量向量索引、相似度搜索是 RAG 常用基础设施不等于 RAGSearch Engine找到相关网页或文档关键词、排序、索引RAG 可以使用搜索引擎作为检索器Agent围绕目标多步行动规划、工具调用、反馈循环Agent 可以把 RAG 当作工具Long Context模型能读取更长输入扩大上下文窗口长上下文不能替代检索常与 RAG 结合RAG 和微调怎么选一个常见问题是有了 RAG还需要微调吗答案是看目标。如果你想让模型知道最新产品手册、内部制度、合同条款优先考虑 RAG。因为这些知识会变化放在外部知识库更容易更新和审计。如果你想让模型稳定输出某种格式、学会特定语气、掌握某类标注规则、适应固定任务微调可能更合适。很多真实系统会同时使用两者微调让模型更会“怎么回答”RAG 提供“回答依据是什么”。一个简单例子假设公司有一份内部制度文档员工每年可申请 10 天年假。连续请假超过 5 天需要直属主管和部门负责人共同审批。用户问我想一次性请 6 天年假需要谁审批没有 RAG 时模型可能根据常识回答一般需要主管审批具体请查看公司制度。使用 RAG 后系统会先检索到相关制度片段再把它放进上下文已检索资料 员工每年可申请 10 天年假。连续请假超过 5 天需要直属主管和部门负责人共同审批。 用户问题 我想一次性请 6 天年假需要谁审批模型就可以回答需要直属主管和部门负责人共同审批。依据是公司年假制度中“连续请假超过 5 天需要直属主管和部门负责人共同审批”的规定。这个例子很小但体现了 RAG 的本质答案不是来自模型“猜测公司制度”而是来自可检索的外部资料。常见误解误解 1RAG 可以完全消除幻觉不能。RAG 可以降低幻觉但不能完全消除。检索不到资料、检索到错误资料、资料互相冲突、模型没有严格遵守证据都可能导致幻觉。更可靠的做法是让模型在证据不足时明确说“不确定”或“资料中未找到”并提供引用来源。误解 2只要接入向量数据库就是 RAG不是。向量数据库只是常见组件。真正的 RAG 还包括文档处理、chunk 策略、检索策略、重排、上下文构造、生成约束、引用、权限、安全和评估。一个糟糕的向量索引加一个强模型仍然可能得到糟糕答案。误解 3RAG 一定比长上下文好不一定。长上下文适合用户一次性提供完整材料例如让模型读一份报告。RAG 适合从大量资料中筛选相关内容。真实系统常常结合两者先用 RAG 找资料再利用长上下文放入更多相关片段。误解 4RAG 不需要评估RAG 更需要评估因为它有更多环节。你不仅要评估最终答案还要评估检索是否命中、引用是否正确、上下文是否充分、模型是否忠于证据。常见评估维度包括维度问题检索召回正确资料有没有被找出来检索精度找出来的资料是否真的相关答案忠实度回答是否严格基于资料答案完整性是否回答了用户真正的问题引用准确性引用是否支持对应结论权限安全是否泄露用户无权访问的内容误解 5RAG 只适合文本早期 RAG 多用于文本但现在已经扩展到多模态。图片、表格、音频、视频、代码、结构化数据库都可以成为检索对象。多模态 RAG 和代码 RAG 是很重要的发展方向。未来趋势1. 从简单 RAG 到 Agentic RAG简单 RAG 通常只检索一次然后生成答案。复杂问题往往需要多轮检索先查背景再拆问题再查细节再验证答案。Agentic RAG 会让模型像研究员一样主动决定是否需要检索应该检索什么检索结果是否足够是否需要换关键词是否需要查数据库或调用工具最终答案是否被证据支持。这会让 RAG 从“固定流水线”变成“可迭代的信息获取过程”。2. Self-RAG 和 Corrective RAGSelf-RAG、CRAG 等研究试图让模型更主动地判断检索是否必要、检索结果是否可靠、生成答案是否需要修正。这类方法的共同方向是不要假设检索结果天然正确而是让系统学会反思和纠错。3. GraphRAG传统 RAG 常按片段检索适合回答局部问题。但当用户问“这个组织过去一年战略重点如何变化”或“这批事件之间有什么关系”时单个片段可能不够。GraphRAG 会从文档中抽取实体、关系和社群结构用图来组织知识再支持全局总结、关系推理和跨文档分析。它适合复杂知识网络但构建成本也更高。4. 多模态 RAG未来 RAG 不只检索文本。系统可能同时检索PDF 正文图片和图表视频片段音频转写表格数据代码符号数据库记录。多模态 RAG 的挑战是不同模态如何统一索引、如何对齐引用、如何让模型正确理解图表和视频中的证据。5. RAG 评估和可观测性RAG 从 demo 走向生产评估会越来越重要。系统需要记录每次问答检索了什么、用了哪些片段、生成了什么结论、用户是否满意、是否违反权限。未来成熟 RAG 系统会更像搜索引擎、数据库和 LLM 应用的结合体而不是一个简单 prompt 模板。小结RAG 的核心思想是让模型先检索外部资料再基于资料生成答案。RAG 解决了大模型知识过时、私有知识缺失、答案难追溯等问题。一个完整 RAG 系统包括资料清洗、切分、embedding、索引、检索、重排、上下文构造、生成和引用。RAG 是系统架构不是单个模型也不等于向量数据库。RAG 和微调不是替代关系RAG 更适合动态知识微调更适合稳定行为和任务格式。RAG 可以降低幻觉但不能完全消除幻觉。高质量 RAG 的关键在于检索质量、chunk 策略、权限控制、引用校验和评估体系。长上下文不会让 RAG 消失二者往往会结合使用。未来 RAG 会向 Agentic RAG、Self-RAG、GraphRAG、多模态 RAG 和生产级评估演进。参考资料Patrick Lewis et al.,Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020: https://arxiv.org/abs/2005.11401Vladimir Karpukhin et al.,Dense Passage Retrieval for Open-Domain Question Answering, 2020: https://arxiv.org/abs/2004.04906Kelvin Guu et al.,REALM: Retrieval-Augmented Language Model Pre-Training, 2020: https://arxiv.org/abs/2002.08909Gautier Izacard and Edouard Grave,Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering, 2020: https://arxiv.org/abs/2007.01282Sebastian Borgeaud et al.,Improving language models by retrieving from trillions of tokens, 2021: https://arxiv.org/abs/2112.04426Gautier Izacard et al.,Few-shot Learning with Retrieval Augmented Language Models, 2022: https://arxiv.org/abs/2208.03299Yunfan Gao et al.,Retrieval-Augmented Generation for Large Language Models: A Survey, 2023: https://arxiv.org/abs/2312.10997Akari Asai et al.,Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection, 2023: https://arxiv.org/abs/2310.11511Yan Xiong et al.,Corrective Retrieval Augmented Generation, 2024: https://arxiv.org/abs/2401.15884Darren Edge et al.,From Local to Global: A Graph RAG Approach to Query-Focused Summarization, 2024: https://arxiv.org/abs/2404.16130Microsoft Research,GraphRAG: Unlocking LLM discovery on narrative private data, 2024: https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/下一篇Multimodal AI多模态AI