| 版本 | 内容 | 时间 | | ---- | ---- | ---------------------- | | V1 | 新建 | 2026年04月03日00:26:21 | 参考： 1. 《基于大模型的RAG应用开发与优化-构建企业级LLM应用》 2. 《从零开始构建企业级RAG系统》 3. https://github.com/datawhalechina/all-in-rag/tree/main ## 大模型的问题大模型的问题： 1. **知识的时效性问题**：大模型参数庞大、训练成本高，迭代周期长且需安全测试，因此存在知识滞后，无法回答训练截止后的问题； 2. **输出难以解释的“黑盒子”问题**：大模型因黑盒运行模式而简单易用，用户只需输入提示词，无需关注内部推理过程，但这也导致调试困难、输出存在随机性。2023 年 Anthropic 团队的研究在大模型可解释性上取得进展，不过大规模模型实现可解释性仍面临巨大技术挑战； 3. **输出的不确定性**：大模型输出具有随机性与不确定性，这能使其生成富有创意的内容，适配创意创作等场景，但在需精准、可预测结果的公司知识、开发调试等场景中，会带来不小的应用挑战。大模型输出不确定的根源是其基于概率统计的非线性模型，依据概率分布选词而非固定规则。虽可通过 temperature 参数调控随机性，OpenAI 也推出 seed 参数提升输出可复现性，但无法彻底消除随机问题。 4. **“幻觉”问题**：大模型看似合理却输出错误内容，表现为编造事实、推理出错等，主要原因如下： 1. **训练知识存在偏差**：训练数据含错误、过时、偏见信息，大模型学习后会在输出中重现。 2. **过度泛化地推理**：模型过度泛化语言规律，套用至特定场景，导致输出不准确。 3. **理解存在局限性**：模型无真正理解与常识，在需深度理解、复杂推理时易出错。 4. **缺乏特定行业与垂直领域的知识**：通用大模型缺乏垂直领域专业知识，面对专业问题易编造内容。
RAG 技术，主要用于解决大模型实际应用问题，尤其是幻觉问题，是该领域关键优化方案。 ## 什么是 RAG RAG (Retrieval-Augmented Generation）将大模型与信息检索结合，引入外部实时数据补充知识。其本质是融合模型内部参数化知识与外部非参数化知识，生成前检索参考资料，提升回答准确性与时效性，缓解幻觉问题。 > 将大模型比作应考学生，易因知识不足编造答案产生幻觉，而 RAG 就如同考试时提供的参考书，让其依托参考资料答题，大幅提升答案准确性。 ## RAG 核心原理 RAG 主要有两个阶段：1）检索阶段 2）生成阶段 ![](https://img.guosgbin.cn/RAG/image-20260403153758608.png) 1. **检索阶段**：RAG 核心依赖检索增强生成，需先准备检索内容。传统检索多用关键词匹配，而 RAG 常采用向量语义检索，依据相似度排序选取前 K 个相关数据块，向量存储索引也因此成为 RAG 最常见的索引形式。 1. **加载（Loading）**：RAG 所需知识来源多样，涵盖不同结构、存储位置及形式的内容，该步骤需实现对各类异构知识内容的连接与读取，为后续处理提供基础数据。 2. **分割（Splitting）**：为提升检索效果，需将大型文档、网页等大体积知识内容切分为知识块 Chunk 并建立索引，同时要合理确定块大小与段落分割标识。 3. **嵌入（Embedding）**：构建向量存储索引时，需借助商用或开源嵌入模型，将切分后的知识块转化为高维向量，以此适配向量语义检索的技术要求。 4. **索引（Indexing）**：将生成的向量存入向量数据库实现持久化，借助其检索算法完成语义检索；高级 RAG 还可按需构建知识图谱、关键词表等多种索引。 2. **生成阶段**：RAG 应用在数据查询阶段的两大核心阶段是检索与生成。 1. **检索（Retrieval）**：检索依托向量存储等索引，从库中取出相关知识块并按相关性排序，为后续生成提供参考上下文 2. **生成（Generation）**：生成以本地或 API 大模型为核心，结合检索知识块与用户问题，通过 Prompt 生成最终结果。 ![RAG 双阶段架构示意图](https://img.guosgbin.cn/RAG/1_1_1.svg) > 图片来源：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 的技术架构经历了从简单到复杂的演进，如下图大致可分为三个阶段 ![](https://img.guosgbin.cn/RAG/1_1_2.png)
| 阶段 | 内容 | 特点 | | ----------------- | ------------------------------------------------------------ | -------------------------- | | Naive RAG 阶段 | 索引、检索与生成 | 基础线性流程 | | Advanced RAG 阶段 | 在 Naive RAG 的基础上对索引、检索与生成这 3 个主要阶段进行了增强，特别是在检索阶段，增加了检索前处理与检索后处理 | 增加**检索前后**的优化步骤 | | Modular RAG 阶段 | Modular RAG 将 RAG 流程拆分为模块类、模块、算法三级结构，模块类对应预检索等核心流程，模块为查询转换等功能单元，算法是具体实现方案。各组件无固定顺序与绑定关系，可按需灵活组合。该模式扩展性极强，能持续集成新算法，也可适配场景定制工作流。 | 模块化、可组合、可动态调整 | ## RAG vs 微调一个大模型的训练通常需要下面几个阶段： 1. **预训练阶段**：这是大模型训练算力消耗最大的核心奠基阶段。基于万亿 token 级海量无标注通用语料，通过自监督的「下一个 token 预测」任务，让模型学习语言规律、世界知识与基础逻辑，最终产出具备基础文本生成能力的基础模型，是后续所有优化的核心底座。 2. **微调阶段**：在宏观上可以把后面的阶段都归到微调，即受监督微调、奖励模型+基于人类反馈的强化学习（Reinforcement Learning from Human Feedback，RLHF）阶段。大模型的微调的成本相对于 RAG 来说是很大的，在选择具体的技术路径时，一个重要的考量是成本与效益的平衡。通常，我们应优先选择对模型改动最小、成本最低的方案，所以技术选型路径往往遵循的顺序是**提示词工程（Prompt Engineering） -> 检索增强生成 -> 微调（Fine-tuning）**。可从两个核心维度区分大模型相关优化技术的差异： 1）横轴为**LLM 优化**，代表对模型本身的修改程度，从左到右修改深度递增，其中提示工程、RAG 完全不改动模型权重，微调则直接修改模型参数； 2）纵轴为**上下文优化**，代表对模型输入信息的增强程度，从下到上增强幅度提升，其中提示工程仅优化提问方式，RAG 则通过引入外部知识库，大幅丰富了模型的输入上下文。 ![技术选型路径](https://img.guosgbin.cn/RAG/1_1_3.png) > 图片来源：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 并非二选一的对立关系，而是**相互赋能、互补增效**的组合，也是当前企业级应用的主流落地方向： 1. **RAG 做前置过滤，长上下文做深度理解**：海量知识库场景中，RAG 先筛选高相关知识片段，再由长上下文模型深度推理，兼顾成本与效果，补齐双方核心短板。 2. **长上下文模型反向赋能 RAG 全链路**：长上下文模型可降低 RAG 分块难度、减少语义断裂，同时可用于 RAG 链路中的查询重构、多轮推理、结果重排、自动分块等环节，全面提升 RAG 的检索与生成效果。总结：哪怕模型上下文窗口无限大，RAG 在知识更新、成本控制、精准召回、可解释性上的核心价值依然不可替代；而长上下文模型的发展，也进一步放大了 RAG 的能力上限，二者结合是当前大模型落地的最优解。

RAG-02-RAG技术简介.

Dylan Kwok

RAG-02-RAG技术简介