简介：本文系统讲解大模型RAG的定义、产生背景、核心组成、工作流程及高级方法，帮助开发者理解如何通过检索技术提升大模型回答的准确性与时效性，并给出典型场景、相关概念辨析与工程落地注意事项。
RAG，全称为检索增强生成，是一种将信息检索技术与大语言模型生成能力相结合的技术架构。它的核心思想是：在大模型回答问题之前，先从外部知识源中检索与问题相关的信息，再把检索结果与原始问题一起送入大模型，由大模型基于这些材料生成最终答案。
从技术视角看，RAG可以理解为“检索器 + 生成器”的组合范式。检索器负责从文档库、知识库、数据库或互联网等来源中寻找与输入问题最相关的内容片段；生成器则通常是一个大语言模型，它不再仅依赖训练时固化在参数中的知识，而是利用检索到的上下文进行推理和文本生成。
从业务视角看，RAG为大模型提供了一种“外挂知识库”的能力。企业可以将内部文档、产品手册、规章制度、行业资料等放入知识库中，用户在提问时，系统先从这些资料里查找相关内容，再让大模型据此作答。这样既保留了大模型在语言理解与表达上的优势，又弥补了它缺乏实时信息和企业私有知识的短板。
从使用视角看，RAG表现为一种增强型问答模式。用户感知到的是：模型给出的回答更具体、更有依据、更贴近当前上下文，而不是泛泛而谈或凭空编造。RAG让大模型从“只靠记忆回答”转变为“边查资料边回答”。
一句话总结：RAG就是在向大模型提问时，先从各类数据源中检索相关信息，将检索到的信息和问题一起注入提示词模板，由大模型最终给出答案。RAG等于检索技术加上大模型提示与生成。
大语言模型虽然在众多自然语言处理任务上表现突出，但在实际应用中存在几个显著问题。
第一，知识时效性问题。大模型的知识来自训练数据，而训练数据往往存在截止时间。对于训练之后才发生的事件、新出台的政策、新发布的技术版本等，模型无法给出准确回答。如果完全依赖重新训练来更新知识，成本极高且周期很长。
第二，知识覆盖不足。通用大模型虽然训练数据规模庞大，但不可能覆盖所有垂直领域和所有企业的私有知识。企业内部的项目文档、工单记录、产品参数、运营数据等，通常不在公开训练语料中，模型自然无法回答相关问题。
第三，幻觉问题。大模型在缺乏足够信息时，有时会生成看似合理但实际错误的内容。这种“一本正经地胡说八道”在严肃业务场景中风险较大，尤其涉及医疗、法律、金融等对准确性要求高的领域。
第四，可解释性与可追溯性问题。直接让模型回答，用户无法判断答案的依据是什么。而如果模型能引用检索到的具体文档片段，用户就可以追溯信息来源，增强对答案的信任。
RAG正是针对上述问题的有效方案。它通过检索外部知识源，把最新的、私有的、可追溯的信息提供给大模型，使模型能够基于这些材料作答。RAG的价值可以概括为三点：降低幻觉概率、注入实时与私有知识、提供答案依据。同时，与重新训练或微调大模型相比，RAG的落地成本更低、更新更灵活，只需要维护好外部知识库即可。
一个典型的RAG系统通常由以下几个核心模块组成。
知识库是RAG的数据基础。它可以由企业文档、网页内容、数据库记录、API返回结果等多种来源构成。原始文档需要经过清洗、切分、向量化等处理，最终形成可供检索的索引。常见的索引方式包括向量索引和关键词索引。向量索引将文本映射为稠密向量，通过向量相似度进行语义匹配；关键词索引则基于词项匹配，适合精确查询场景。
检索器负责接收用户问题，并从知识库中找到最相关的文档片段或数据记录。检索质量直接影响最终答案质量。检索器可以基于向量相似度、关键词匹配、混合检索等策略。混合检索通常将多种检索结果进行融合排序，以兼顾语义相关性和精确匹配。
提示词模板是连接检索结果与大模型的桥梁。它将用户问题与检索到的上下文按照一定格式组织起来，形成大模型的输入。一个典型的提示词模板可以包含系统角色说明、背景上下文、用户问题和回答约束等部分。设计良好的提示词模板能够引导模型正确使用检索材料，避免模型忽略材料或过度依赖自身知识。
生成器通常是一个大语言模型。它接收提示词模板拼接后的完整输入，基于检索到的上下文进行推理和文本生成。生成器的作用不仅是组织语言，还包括筛选、归纳、对比和总结检索材料中的信息。
在一些完整的RAG方案中，系统还会对生成结果进行后处理，例如补充引用来源、格式规范化、敏感信息过滤等。引用模块可以在答案中标注哪些内容来自哪些文档片段，方便用户核实。
RAG的工作流程可以划分为以下几个阶段。
第一阶段：离线索引构建。 系统将知识库中的文档进行预处理，包括文本提取、清洗、切分成适当大小的片段。每个片段通过嵌入模型转换为向量表示，并存入向量索引中。同时可以建立关键词索引作为补充。这一阶段通常在系统上线前完成，也可在知识库更新时增量执行。
第二阶段：在线检索。 用户输入问题后，系统首先将问题转换为向量表示，然后在向量索引中检索最相似的若干个文档片段。如果采用混合检索，还会同时执行关键词检索，并将结果融合排序。最终选取排名靠前的若干片段作为候选上下文。
第三阶段：上下文组装。 系统将检索到的候选片段与用户问题按照预设的提示词模板进行组装。模板中通常包含明确的指令，例如“请根据以下资料回答问题，如果资料中没有相关信息，请说明无法找到”。
第四阶段：生成回答。 组装好的提示词被送入大语言模型，模型基于上下文材料生成最终回答。由于模型此时拥有了与问题直接相关的资料，其生成结果更有依据，幻觉概率也会降低。
第五阶段：结果输出与引用。 系统将生成的回答返回给用户，可以附带引用来源信息。部分方案还会记录用户反馈，用于后续检索效果和模型效果的评估优化。
下面给出一个通用流程的伪代码示意，帮助理解各模块的协作关系：
def rag_pipeline(question, knowledge_base, retriever, llm):# 1. 检索相关文档片段retrieved_docs = retriever.search(question, knowledge_base, top_k=5)# 2. 组装提示词context = "\n".join([doc.content for doc in retrieved_docs])prompt = build_prompt(question, context)# 3. 大模型生成答案answer = llm.generate(prompt)# 4. 附上引用来源sources = [doc.source for doc in retrieved_docs]return answer, sources
该伪代码仅用于说明RAG的基本流程，实际系统中还会包含预处理、重排序、过滤、缓存等更多环节。
基础的RAG流程已经能够解决很多问题，但在复杂场景中，研究人员和工程师们提出了一系列高级方法，以进一步提升检索质量和生成效果。
单一向量检索对语义相近的文本效果好，但对精确名称、编号、代码片段等可能表现不佳。混合检索同时使用向量检索和关键词检索，将两类结果合并。重排序阶段可以引入一个排序模型，对合并后的候选片段进行更精细的相关性打分，选出最优的若干片段交给大模型。这样可以明显改善检索命中率。
在实际系统中，单一路径的召回往往不够全面。多路召回指同时从多个索引或多个检索策略中获取候选片段，例如一路使用稠密向量召回，一路使用稀疏词项召回，一路基于知识图谱召回。多路结果通过融合算法进行统一排序，以提高覆盖率。
文档切分方式对检索效果影响很大。切分粒度过细可能导致语义不完整，过粗则可能引入大量无关内容。一种常见做法是采用“子文档检索、父文档返回”的策略：将文档切成较细的小片段用于精确匹配检索，一旦某个小片段被命中，就返回它所属的更大范围的父文档片段。这样可以在保证检索精度的同时，为大模型提供更完整的上下文。
用户的原始问题往往表达不够规范，可能包含口语化词汇、简称、指代不明等情况。查询改写指在检索之前，利用大模型对用户问题进行改写，使其更清晰、更适合检索。查询扩展则是在原始问题基础上，生成语义相近的多个查询语句，分别进行检索后合并结果。这些方法可以提升复杂问题的检索召回率。
检索到的文档片段可能包含大量与问题无关的内容。如果全部塞入提示词，会占用珍贵的上下文窗口，还可能导致模型注意力分散。上下文压缩技术利用小型模型或规则，对检索结果进行摘要、裁剪和去噪，只保留与问题最相关的部分。这样可以在有限的上下文限制下，容纳更多有价值的信息。
有些问题需要多步推理才能回答，例如“某产品在去年第三季度的销量相比前年同期增长了多少”。单一轮检索可能无法获得全部所需信息。迭代检索允许系统在生成中间结果后，根据中间结果再次发起检索，逐步获取缺失信息，最终形成完整答案。这种“检索—生成—再检索”的循环适用于复杂问答和数据分析场景。
为了让用户信任答案，高级RAG方案会在生成答案的同时，让模型标注哪些句子来自哪些文档。这可以通过在提示词中要求模型使用引用标记来实现，也可以在生成后用规则或模型对答案进行后处理，将答案片段与检索文档进行对齐。可追溯性在合规要求较高的行业中尤为重要。
部分场景中，知识以结构化形式存在，如关系数据库、知识图谱、表格等。RAG不仅可以从非结构化文本中检索，也可以将结构化数据转换为文本片段或直接作为上下文。结合知识图谱可以让模型理解实体之间的关系，提高推理准确度。例如，将“员工所属部门”“设备关联位置”等信息以三元组形式加入上下文，模型在回答组织架构或资产归属类问题时会更准确。
RAG的应用场景非常广泛，以下列举几类常见场景。
企业知识库问答。 企业将内部制度、流程、产品资料、培训材料等放入知识库，员工通过自然语言提问，系统检索相关资料并生成答案。这种方式比传统关键词搜索更直观，比纯模型回答更可靠。
智能客服与工单辅助。 在客服系统中，RAG可以检索历史工单、产品手册和FAQ，协助客服人员快速定位问题并提供标准化回复建议。对于用户侧的自助服务机器人，RAG也能显著提升问题解决率。
技术文档助手。 开发者在查阅技术资料时，RAG可以检索大量开发文档、接口说明和最佳实践，根据开发者的问题生成针对性说明和示例代码片段，帮助快速理解和使用相关能力。
行业研究报告辅助。 分析人员需要从大量研报、新闻和数据中提取信息。RAG可以检索相关内容，辅助生成摘要、对比分析和趋势总结，提高研究效率。
合规与风控支持。 在金融、法律、医疗等强监管领域，RAG可以从法规库、案例库和内部规范中检索相关条款，辅助生成合规建议或风险提示，并附上来源依据，增强决策的可解释性。
在理解RAG时，容易与几个相关概念混淆。
RAG与微调的区别。 微调是在特定数据集上继续训练大模型，改变模型参数，使模型内化新知识。RAG则不改变模型参数，而是在推理时动态检索外部知识。微调适合让模型学习稳定的风格、格式或领域语言习惯，RAG适合注入频繁变化的事实性知识和私有知识。两者可以结合使用，并不互斥。
RAG与纯提示词工程的区别。 纯提示词工程仅通过设计提示语来引导模型行为，不引入外部检索。RAG在提示词中注入检索到的真实资料，本质上是增强了提示词的上下文内容。可以理解为RAG是一种动态、基于检索的提示词增强技术。
RAG与知识图谱问答的区别。 知识图谱问答通常先将问题解析为结构化查询，再在知识图谱上执行查询并返回结果。RAG通常基于非结构化文本检索，再将检索结果交给大模型生成自然语言答案。两者可以互相补充，知识图谱可以作为RAG的知识来源之一。
RAG与长上下文模型的区别。 长上下文模型可以直接处理很长的输入，例如将整本书放入上下文。但上下文窗口始终有限，且过长输入会带来推理成本和注意力分散。RAG通过检索筛选最相关的片段，在信息聚焦和成本控制方面具有明显优势。
在实际落地RAG时，有几个关键点需要关注。
检索质量决定上限。 如果检索器找不到正确文档，生成器再强也无法给出准确答案。因此需要重视文档切分、索引构建、召回策略和重排序等环节，持续评估检索命中率。
文档切分策略要结合业务内容。 不同数据类型适合不同的切分粒度。例如，技术文档可以按小节切分，FAQ可以按问答对切分，代码可以按函数或文件切分。切分过细会丢失上下文，过粗会引入噪声。
提示词模板需要精心设计。 模板应明确告诉模型只能基于给定资料回答，在资料不足时应坦承无法回答，避免模型回到自身记忆生成不可靠内容。同时要合理放置上下文，避免用户问题与检索内容之间发生混淆。
上下文窗口限制。 大模型的上下文窗口有限，不能无限制地塞入检索结果。需要设置合理的最大片段数，并结合压缩、过滤或重排序策略，在信息量和窗口限制之间取得平衡。
知识库需要持续更新。 RAG的效果高度依赖知识库的新鲜度和完整性。需要建立知识入库、更新、删除的运维机制，避免过时信息长期残留导致答案错误。
安全与权限控制。 当检索涉及企业内部敏感数据时，需要在检索阶段就做好权限校验，确保用户只能检索到其有权访问的内容。生成阶段也需避免越权信息泄露。
效果评估与持续优化。 RAG系统上线后，需要建立评估机制，采集真实用户问题、检索结果和生成答案，通过人工标注或自动化指标评估检索命中率和答案质量，再针对性地优化各环节。
RAG是一种将检索技术与大模型生成能力相结合的技术范式。它通过在推理阶段动态检索外部知识，将相关资料与用户问题一起交给大模型，使模型能够基于实时、私有、可追溯的信息生成答案。RAG有效缓解了大模型的知识时效性不足、覆盖有限和幻觉等问题，同时避免了频繁重训练的高成本。
从系统组成看，RAG包含知识库与索引、检索器、提示词模板、生成器和后处理等模块。从工作流程看，它经历了索引构建、在线检索、上下文组装、生成回答和结果输出等阶段。高级方法包括混合检索、多路召回、查询改写、文档切分优化、上下文压缩、迭代检索和引用生成等，这些方法进一步提升了RAG在复杂场景中的表现。
理解RAG的关键在于认识到：它并不改变大模型本身，而是通过检索为模型提供更可靠的输入材料，从而提升输出的准确性、及时性和可解释性。在知识密集型、实时性要求高、数据私有化程度高的场景中，RAG已经成为大模型应用落地的重要基础架构之一。对于开发者而言，掌握RAG的定义、原理和工程实现方法，是构建高质量大模型应用的必要能力。