RAG基础讲解
RAG 基础概念
RAG (Retrieval-Augmented Generation，检索增强生成) 是一种将强大的信息检索 (Information Retrieval, IR) 技术与生成式大语言模型 (LLM) 相结合的框架。
RAG 的核心思想是：在让 LLM 回答问题或生成文本之前，先从一个大规模的知识库（如数据库、文档集合）中检索出相关的上下文信息，然后将这些信息与原始问题一并提供给 LLM，从而“增强”其生成能力，使其能够产出更准确、更具时效性、更符合特定领域知识的回答。
RAG的目的是通过从外部知识库检索相关信息来辅助大语言模型生成更准确、更丰富的文本内容。那我们如何理解RAG的检索、增强和生成呢？
检索：检索是RAG流程的第一步，从预先建立的知识库中检索与问题相关的信息。这一步的目的是为后续的生成过程提供有用的上下文信息和知识支撑。
增强：RAG中增强是将检索到的信息用作生成模型（即大语言模型）的上下文输入，以增强模型对特定问题的理解和回答能力。这一步的目的是将外部知识融入生成过程中，使生成的文本内容更加丰富、准确和符合用户需求。通过增强步骤，LLM模型能够充分利用外部知识库中的信息。
生成：生成是RAG流程的最后一步。这一步的目的是结合LLM生成符合用户需求的回答。生成器会利用检索到的信息作为上下文输入，并结合大语言模型来生成文本内容。
RAG的“检索、增强、生成”，谁增强了谁，谁生成了答案，主语很重要。是从知识库中检索到的问答对，增强了LLM的提示词（prompt），LLM拿着增强后的Prompt生成了问题答案。
为什么需要 RAG？
尽管 LLM 本身拥有海量的知识，但它依然面临三个核心挑战，而 RAG 正是解决这些挑战的有效方案：
1. 解决知识时效性问题（对抗“知识截止”）
预训练的 LLM 的知识被固化在其 训练数据的截止时间点（Knowledge Cutoff）。例如，GPT-4 的知识库可能截止于 2023 年 12 月。对于此后发生的新事件、新知识，LLM 无法直接给出准确答案。RAG 通过 动态检索外部知识源，为 LLM 提供“实时”的知识补充，从而克服了知识过时的问题。
2. 打通私有数据访问（支撑企业级应用）
出于数据安全和商业机密的考虑，企业内部的 私有数据（如产品文档、内部知识库、客户数据等）无法被公开的 LLM 直接访问。RAG 技术能够安全地连接这些私有数据源，在用户提问时，仅将与问题相关的片段信息提取出来提供给 LLM，使其能够在 不泄露全部数据 的前提下，基于企业自身的知识进行回答，实现真正可用的企业级智能应用。
3. 提升回答的准确性与可追溯性（对抗“模型幻觉”）
LLM 有时会产生 “幻觉（Hallucination）” ，即编造不符合事实的信息。RAG 通过提供明确的、有据可查的参考文本，强制 LLM 的回答 基于检索到的事实，大大降低了幻觉的发生率。同时，由于可以展示引用的原文，使得答案的 来源可追溯、可验证，增强了系统的可靠性和用户的信任度。
RAG 的常见用途有哪些？
RAG（检索增强生成）最适合用在 “答案依赖外部资料、且资料会变化/很长” 的场景：先从知识库检索相关内容，再让大模型基于检索结果生成回答，从而减少胡编、提升可追溯性。
下面列举几个最常见的场景：
客服机器人：基于产品知识库做问答、排障、流程引导；例：“如何退换货/开发票？”“某型号设备报错码怎么处理？”
研发/运维 Copilot：检索代码库、接口文档、告警手册，辅助定位问题与生成修复建议。
医疗助手：检索指南/药品说明/院内规范后生成辅助建议（不做最终诊断）；例：“某药禁忌是什么？”“依据指南解释检查指标含义”。
法律咨询：基于法规条文/案例/合同模板检索，生成条款解释与风险提示；例：“违约金如何计算？”“不可抗力条款怎么写更稳妥？”
教育辅导：从教材/讲义/题库检索知识点，生成讲解与例题步骤；例：“这道题对应哪个公式？怎么推导？”
企业内部助手：连接制度、SOP、会议纪要、技术文档做检索/总结/对比；例：“某流程最新版本是什么？”“对比两份方案差异并给结论”。
其他：投研/合规/审计（报告/披露/内控）；销售/方案支持（产品手册/标书模板、生成方案并标注出处）。
⭐️既然这些场景这么好，为什么有些企业还是宁愿用传统搜索而不是 RAG？
因为 RAG 存在推理成本和响应延迟的问题。在某些纯粹为了“找文件”而非“总结答案”的简单场景，传统搜索依然具备极致的效率优势。
下面简单对比一下二者：
RAG 工作原理
RAG 过程分为两个不同阶段：索引和检索。
在索引阶段，文档会进行预处理，以便在检索阶段实现高效搜索。该阶段通常包括以下步骤：
输入文档：文档是需要被处理的内容来源，可能是文本文件、PDF、网页、数据库记录等。
清理文档：对文档进行去噪处理，移除无用内容（如 HTML 标签、特殊字符）。
增强文档：利用附加数据和元数据（如时间戳、分类标签）为文档片段提供更多上下文信息。
文档拆分（Chunking）：通过文本分割器（Text Splitter）将文档拆分为较小的文本片段（Segments），严格适配嵌入模型和生成模型的上下文窗口限制（Context Window）。
向量化表示 (Embedding Generation)：通过嵌入模型（如 OpenAI text-embedding-3 或 Hugging Face 上的开源模型）将文本片段映射为语义向量表示（Document Embedding，也就是高维稠密向量）。
存储到向量数据库：将生成的嵌入向量、原始内容及其对应的元数据存入向量存储库（如 Milvus, Faiss 或 pgvector）。
索引过程通常是离线完成的，例如通过定时任务（如每周末更新文档）进行重新索引。对于动态需求，例如用户上传文档的场景，索引可以在线完成，并集成到主应用程序中。
索引阶段的简化流程图如下：
检索通常在线进行的，当用户提交一个问题时，系统会使用已索引的文档来回答问题。该阶段通常包括以下步骤：
接收请求： 接收用户的自然语言查询（Query），例如一个问题或任务描述。在某些进阶场景中，系统会先对原始查询进行改写或扩充，以提高后续检索的覆盖率。
查询向量化： 使用嵌入模型（Embedding Model）将用户查询转换为语义向量表示（Query Embedding，也就是高维稠密向量），以捕捉查询的语义信息。
信息检索 (R)： 在嵌入存储（Embedding Store）中，通过语义相似性搜索找到与查询向量最相关的文档片段（Relevant Segments）。
生成增强 (A)： 将检索到的相关片段和原始查询作为上下文输入给 LLM，并使用合适的提示词引导 LLM 基于检索到的信息回答问题。
输出生成 (G)： 向用户输出自然语言回复，并附带相关的参考资料链接。
结果反馈（可选）： 如果用户对生成的结果不满意，可以允许用户提供反馈，通过调整提示词或检索方式优化生成效果。在某些实现中，支持多轮交互，进一步完善回答。
检索阶段的简化流程图如下：
RAG 与传统搜索引擎的区别是什么？
RAG 与传统搜索引擎虽然都涉及信息获取，但它们在检索机制、信息处理和交付形式上有本质区别：
检索机制：
传统搜索主要依赖倒排索引与词汇匹配（如 BM25、TF-IDF），对关键词的字面形式依赖强。虽然现代搜索引擎也引入了语义理解（如 BERT），但核心仍是基于词汇统计的相关性计算。
RAG 通常采用向量语义搜索，能够识别同义词和深层语境，解决语义鸿沟问题。
处理逻辑：
传统搜索本质是相关性排序器，将候选文档按相关性得分排序后直接呈现给用户。每个结果相对独立，不进行跨文档的信息融合。
RAG 的本质是 信息综合器，它会将检索到的多个知识碎片（Chunks）喂给 LLM，由模型进行逻辑归纳和跨文档的信息整合。
结果交付：
传统搜索提供候选文档列表（线索），需要用户二次阅读过滤；
RAG 提供的是答案，能直接回答复杂指令，并通过引文标注（Citations）兼顾了信息的来源可追溯性。
时效性与数据范围： 传统搜索更依赖大规模爬虫和全网索引；RAG 则常用于私有知识库或垂直领域，能低成本地让 LLM 获得实时或特定领域的知识补充，无需频繁微调模型。
⭐️ RAG 的核心优势和局限性分别是什么？
RAG 的核心优势和局限性可以从知识管理、工程落地和性能指标三个维度来分析：
核心优势：
知识时效性与低维护成本： 相比微调，RAG 无需重新训练模型。只需更新向量数据库或知识库，模型就能立即获取最新信息，非常适合处理新闻、法规、产品文档等频繁变动的数据。这种即插即用的特性使得知识更新的成本从数千美元降低到几乎为零。
显著降低幻觉并提供引文追溯： RAG 将模型从“基于参数化记忆生成”转变为“基于检索证据生成”。每个回答都有明确的信息来源，提供了关键的可解释性和可验证性。这对金融合规、医疗诊断、法律咨询等对准确性要求极高的场景尤为关键。
数据安全与细粒度权限控制： 可以在检索层实现精准的多租户隔离和访问控制（ACL），确保用户只能检索其权限范围内的数据。相比将敏感数据通过微调“烧入”模型参数（存在数据泄露风险），RAG 的架构天然支持数据隔离和合规要求。
领域适应性强： 无需针对特定领域重新训练模型，只需构建领域知识库即可快速适配垂直场景，如企业内部知识管理、专业技术支持等。
局限性与工程挑战：
严重的检索依赖性： 遵循 GIGO（Garbage In, Garbage Out）原则。如果输入的信息质量不好，即便下游模型再强，也很难输出正确的结果。这个在 RAG 系统里体现得尤为明显。比如说，如果检索阶段的 embedding 表达不准确，或者分块策略不合理，导致召回的内容跟问题无关，那无论上下游用什么大模型，最终生成的答案也不会靠谱。
上下文窗口与推理噪声： 虽然 Context Window 已经卷到了百万级（如 Claude 4.6 Opus 的 1M 上限），但这并不意味着我们可以“暴力喂养”。注入过多无关片段（Noisy Chunks）会造成注意力稀释，干扰模型的逻辑推理，且带来不必要的 Token 开销。
首字延迟（TTFT）增加： 完整链路包括“查询改写 -> 向量化 -> 相似度检索 -> 重排序（Rerank）-> 上下文构建 -> LLM 生成”，每个环节都增加延迟。
工程复杂度： 需要维护向量数据库、处理文档更新的增量索引、优化检索策略等，相比纯 LLM 应用复杂度大幅提升。
长文本 Token 成本： 虽然省去了训练费，但单次请求携带大量上下文会导致推理成本（Input Tokens）显著高于普通对话。
参考链接：