02-RAG技术简介
| 版本 | 内容 | 时间 |
|---|---|---|
| V1 | 新建 | 2026年04月03日00:26:21 |
参考：
- 《基于大模型的RAG应用开发与优化-构建企业级LLM应用》
- 《从零开始构建企业级RAG系统》
- https://github.com/datawhalechina/all-in-rag/tree/main
大模型的问题
大模型的问题：
知识的时效性问题：大模型参数庞大、训练成本高，迭代周期长且需安全测试，因此存在知识滞后，无法回答训练截止后的问题；
输出难以解释的“黑盒子”问题：大模型因黑盒运行模式而简单易用，用户只需输入提示词，无需关注内部推理过程，但这也导致调试困难、输出存在随机性。2023 年 Anthropic 团队的研究在大模型可解释性上取得进展，不过大规模模型实现可解释性仍面临巨大技术挑战；
输出的不确定性：大模型输出具有随机性与不确定性，这能使其生成富有创意的内容，适配创意创作等场景，但在需精准、可预测结果的公司知识、开发调试等场景中，会带来不小的应用挑战。
大模型输出不确定的根源是其基于概率统计的非线性模型，依据概率分布选词而非固定规则。虽可通过 temperature 参数调控随机性，OpenAI 也推出 seed 参数提升输出可复现性，但无法彻底消除随机问题。
“幻觉”问题：大模型看似合理却输出错误内容，表现为编造事实、推理出错等，主要原因如下：
- 训练知识存在偏差：训练数据含错误、过时、偏见信息，大模型学习后会在输出中重现。
- 过度泛化地推理：模型过度泛化语言规律，套用至特定场景，导致输出不准确。
- 理解存在局限性：模型无真正理解与常识，在需深度理解、复杂推理时易出错。
- 缺乏特定行业与垂直领域的知识：通用大模型缺乏垂直领域专业知识，面对专业问题易编造内容。
RAG 技术，主要用于解决大模型实际应用问题，尤其是幻觉问题，是该领域关键优化方案。
什么是 RAG
RAG (Retrieval-Augmented Generation）将大模型与信息检索结合，引入外部实时数据补充知识。其本质是融合模型内部参数化知识与外部非参数化知识，生成前检索参考资料，提升回答准确性与时效性，缓解幻觉问题。
将大模型比作应考学生，易因知识不足编造答案产生幻觉，而 RAG 就如同考试时提供的参考书，让其依托参考资料答题，大幅提升答案准确性。
RAG 核心原理
RAG 主要有两个阶段：1）检索阶段 2）生成阶段
- 检索阶段：RAG 核心依赖检索增强生成，需先准备检索内容。传统检索多用关键词匹配，而 RAG 常采用向量语义检索，依据相似度排序选取前 K 个相关数据块，向量存储索引也因此成为 RAG 最常见的索引形式。
- 加载（Loading）：RAG 所需知识来源多样，涵盖不同结构、存储位置及形式的内容，该步骤需实现对各类异构知识内容的连接与读取，为后续处理提供基础数据。
- 分割（Splitting）：为提升检索效果，需将大型文档、网页等大体积知识内容切分为知识块 Chunk 并建立索引，同时要合理确定块大小与段落分割标识。
- 嵌入（Embedding）：构建向量存储索引时，需借助商用或开源嵌入模型，将切分后的知识块转化为高维向量，以此适配向量语义检索的技术要求。
- 索引（Indexing）：将生成的向量存入向量数据库实现持久化，借助其检索算法完成语义检索；高级 RAG 还可按需构建知识图谱、关键词表等多种索引。
- 生成阶段：RAG 应用在数据查询阶段的两大核心阶段是检索与生成 。
- 检索（Retrieval）：检索依托向量存储等索引，从库中取出相关知识块并按相关性排序，为后续生成提供参考上下文
- 生成（Generation）：生成以本地或 API 大模型为核心，结合检索知识块与用户问题，通过 Prompt 生成最终结果。
图片来源：https://datawhalechina.github.io/all-in-rag/#/chapter1/01_RAG_intro
随着 RAG 范式与架构的不断演进与优化，有一些新的处理阶段被纳入生成阶段，其中典型的两个阶段为检索前处理与检索后处理。
（1）检索前处理（Pre-Retrieval）
检索前处理是优化版 RAG 在检索前执行的步骤，主要开展查询转换、查询扩充、检索路由等操作，为后续流程做好准备，以此提升检索召回知识的精准度，进而改善最终生成内容的质量。
（2）检索后处理（Post-Retrieval）
检索后处理在检索完成后进行，会对获取的知识块开展重排序、过滤不合格内容等处理，将优质合规的知识块前置，优化上下文结构，有效提升大模型输出内容的质量。
RAG 应用面临的挑战
| 挑战 | 详情&解决方案 |
|---|---|
| 检索召回的精确度 | RAG 的核心是通过语义检索为大模型补充外部知识，是其生成高质量结果的重要保障。但受检索算法局限、查询表达不足等影响，存在关键文档召回不足、内容泛化、关键上下文丢失等问题。可通过查询优化、多元检索策略、超参数调优、重排技术解决。 1）查询优化处理：通过补充用户查询的上下文细节、优化查询措辞提升检索结果相关性，核心措施包括查询重构、生成假设文档嵌入、拆分创建子查询等。 2）多元检索策略调整：采用多样化检索方式，如递归检索、语义相似度评分等，提升系统检索相关信息的精准度。 3）检索超参数调优：优化检索环节的核心超参数，包括文本块大小、相似度阈值等，平衡计算效率与信息检索质量。 4）检索结果重排优化：在将检索结果输入大语言模型前，通过重排技术处理结果，进一步提升送入模型内容的相关性与准确性。 |
| 大模型自身对抗干扰的能力 | 大模型需识别处理检索知识中的干扰、冗余、矛盾信息并按 Prompt 输出，其自身能力是影响最终生成质量的关键因素。 |
| 上下文窗口的限制 | 大模型存在上下文 token 窗口限制，RAG 检索过多知识块易触发超限，如何在窗口内承载更多有效知识是其开发核心要点之一。 |
| RAG 与微调的选择 | 微调是大模型适配垂直领域的常用方法，可提前融入领域知识、简化架构，RAG 与微调的选型配合是很多人纠结的问题。 |
| 响应性能问题 | RAG 相较大模型直接输出增加了处理步骤，复杂优化范式提升输出质量的同时会降低响应性能，兼顾质量与低延迟是企业级场景的开发挑战。 |
| 数据可观察性和治理 | RAG 企业应用中，数据可观察性与治理至关重要，需建立审计监控机制、完善治理框架，保障信息可靠，提升用户对系统的信任。 |
RAG 应用架构的演进
RAG 的技术架构经历了从简单到复杂的演进，如下图大致可分为三个阶段
| 阶段 | 内容 | 特点 |
|---|---|---|
| Naive RAG 阶段 | 索引、检索与生成 | 基础线性流程 |
| Advanced RAG 阶段 | 在 Naive RAG 的基础上对索引、检索与生成这 3 个主要阶段进行了增强，特别是在检索阶段，增加了检索前处理与检索后处理 | 增加检索前后的优化步骤 |
| Modular RAG 阶段 | Modular RAG 将 RAG 流程拆分为模块类、模块、算法三级结构，模块类对应预检索等核心流程，模块为查询转换等功能单元，算法是具体实现方案。各组件无固定顺序与绑定关系，可按需灵活组合。该模式扩展性极强，能持续集成新算法，也可适配场景定制工作流。 | 模块化、可组合、可动态调整 |
RAG vs 微调
一个大模型的训练通常需要下面几个阶段：
- 预训练阶段：这是大模型训练算力消耗最大的核心奠基阶段。基于万亿 token 级海量无标注通用语料，通过自监督的「下一个 token 预测」任务，让模型学习语言规律、世界知识与基础逻辑，最终产出具备基础文本生成能力的基础模型，是后续所有优化的核心底座。
- 微调阶段：在宏观上可以把后面的阶段都归到微调，即受监督微调、奖励模型+基于人类反馈的强化学习（Reinforcement Learning from Human Feedback，RLHF）阶段。
大模型的微调的成本相对于 RAG 来说是很大的，在选择具体的技术路径时，一个重要的考量是成本与效益的平衡。通常，我们应优先选择对模型改动最小、成本最低的方案，所以技术选型路径往往遵循的顺序是提示词工程（Prompt Engineering） -> 检索增强生成 -> 微调（Fine-tuning）。
可从两个核心维度区分大模型相关优化技术的差异：
1）横轴为LLM 优化，代表对模型本身的修改程度，从左到右修改深度递增，其中提示工程、RAG 完全不改动模型权重，微调则直接修改模型参数；
2）纵轴为上下文优化，代表对模型输入信息的增强程度，从下到上增强幅度提升，其中提示工程仅优化提问方式，RAG 则通过引入外部知识库，大幅丰富了模型的输入上下文。
图片来源：https://datawhalechina.github.io/all-in-rag/#/chapter1/01_RAG_intro
接下来我们看下 RAG 和微调的优缺点
| RAG | 模型微调（Fine-tuning） | |
|---|---|---|
| 优点 | 1. 使用灵活，可随时调整 Prompt 以获得期望输出 2. 技术实现门槛更低，流程更简单 3. 可通过知识增强 Prompt 让大模型即时适配领域知识 4. 无额外的模型训练成本 | 1. 可让大模型内化特定领域知识，固化适配特定输出格式 2. 下游应用对接更友好，特定任务中使用更简便 3. 推理阶段无需额外拼接长上下文，token 消耗更少、推理成本更低 |
| 缺点 | 1. 效果受限于大模型的上下文窗口大小 2. 基于知识增强 Prompt 实现长上下文连续对话难度较高 3. 高准确性要求的场景中，模型输出不确定性易提升失败风险 4. 长上下文 Prompt 会带来更高的推理 token 成本 5. 基础模型迭代后，大概率需要重新适配调整 Prompt | 1. 无法开箱即用，前期准备流程长 2. 需承担数据标注清洗、算力资源等额外的训练成本 3. 对技术团队要求高，需机器学习、数据领域专业人才支撑 4. 无法根治模型幻觉问题，过度微调还可能导致模型基础能力下降 5. 模型迭代周期长，无法适配实时性要求高的知识更新场景 |
基于此，我们的选择路径就清晰了：
提示工程：优先尝试，适配简单任务、模型已有相关知识的场景
RAG：模型缺特定 / 实时知识时选用，外挂知识库补充上下文
微调：适配模型行为 / 风格 / 格式优化，为非知识类需求的最终选择。例如需要注入较大数据量且相对稳定、迭代周期较长的领域知识；需要形成一个相对通用的领域大模型用于对外服务或者运营。
RAG 与具有理解超长上下文能力的大模型
超长上下文大模型：通过扩大模型原生上下文窗口（如 128k、200 万甚至上亿 token），让模型可一次性加载、理解超长文本，核心是提升模型本身处理文本长度的能力上限，无需额外外挂系统，端到端完成长文本理解与生成。
| 优点 | 缺点 | |
|---|---|---|
| 超长上下文大模型 | 1. 端到端使用门槛极低，无需复杂工程搭建，适合长文档摘要、合同全量审核、整本书籍分析等需要全局逻辑关联的场景； 2. 可完整保留文本的上下文链条，避免 RAG 分块导致的语义断裂、跨段落关联信息丢失问题，长文本生成的连贯性更强。 | 1. 存在「Lost in the Middle（中间迷失）」问题：学术与工业界均已验证，模型对长上下文首尾内容的注意力远高于中间段落，超长文本中关键细节的召回率会大幅下降； 2. 推理成本与延迟随文本长度指数级上升，海量知识库场景下，全量文本输入完全不具备落地可行性； 3. 知识更新不灵活，新增知识要么每次全量输入（成本极高），要么重新微调（周期长、成本高），无法适配实时性要求高的场景。 |
| RAG | 1. 成本与效率优势显著，仅向模型输入高相关的知识片段，大幅降低 token 消耗与推理延迟，企业级海量知识库场景下唯一具备落地性的方案； 2. 知识更新灵活可控，新增、修改知识库内容即可即时生效，完美适配规章制度、产品信息、实时资讯等高频更新的场景； 3. 可有效降低模型幻觉，答案可溯源至原始文档，满足金融、法律、医疗等对准确性、可解释性要求极高的场景。 | 1. 工程链路复杂，对分块策略、嵌入模型、检索算法、重排优化均有较高要求，技术门槛高于直接使用长上下文模型； 2. 分块检索天然存在全局上下文丢失的问题，难以处理跨章节、跨文档的长逻辑链推理，长文本的全局理解能力弱于原生长上下文模型。 |
超长上下文大模型与 RAG 并非二选一的对立关系，而是相互赋能、互补增效的组合，也是当前企业级应用的主流落地方向：
- RAG 做前置过滤，长上下文做深度理解：海量知识库场景中，RAG 先筛选高相关知识片段，再由长上下文模型深度推理，兼顾成本与效果，补齐双方核心短板。
- 长上下文模型反向赋能 RAG 全链路：长上下文模型可降低 RAG 分块难度、减少语义断裂，同时可用于 RAG 链路中的查询重构、多轮推理、结果重排、自动分块等环节，全面提升 RAG 的检索与生成效果。
总结：哪怕模型上下文窗口无限大，RAG 在知识更新、成本控制、精准召回、可解释性上的核心价值依然不可替代；而长上下文模型的发展，也进一步放大了 RAG 的能力上限，二者结合是当前大模型落地的最优解。