RAG 基础概念：检索、生成与工程取舍
做企业知识库问答时，很多团队最初会尝试把文档直接塞进大模型上下文。文档只有几篇时确实能跑通，但当知识库涨到几十万字甚至上百万字，单次请求很快就会触碰 Token 上限或推高首字延迟；企业场景还要处理文档更新、权限隔离、引用溯源和调用成本，无法靠全量拼接上下文支撑日常查询。
RAG 会在模型生成回答前先从知识库检索相关片段，再把这些片段放进上下文交给模型，让回答建立在可核对的证据之上。检索、上下文组织和生成任一环节出错，最终答案都可能偏离原文。
什么是 RAG？
RAG（Retrieval-Augmented Generation，检索增强生成） 将信息检索与大语言模型生成结合在一起。系统先从数据库、文档集合或企业内部系统中检索出与当前问题相关的片段，再把这些片段和原始问题一起组装到 Prompt 中交给 LLM，让模型依据检索到的资料生成回答，而不单靠预训练参数中记住的知识。
为什么需要 RAG？
直接调用预训练大模型做企业问答，通常会卡在三个问题上：
- 知识时效性受限：预训练模型的知识停留在训练数据截止时间点。训练后发布的新政策、新产品手册或实时业务数据，模型本身并不掌握，需要通过外部检索或工具调用动态注入。
- 私有数据无法直接使用：企业内部的产品文档、制度库和客户数据不能直接放进公开模型的训练集。RAG 在用户提问时按权限只提取相关片段送入上下文，无需重新训练模型，就能利用企业内部知识回答问题。
- 事实性幻觉难以核查：LLM 在缺少依据时仍可能生成看似通顺的错误结论。RAG 通过提供参考原文，让模型基于给定证据作答并附上出处，能够降低无根据编造的概率。不过 RAG 并不能彻底消除幻觉，检索漏召回、上下文噪声、引用错配或模型未遵循指令，依然会导致错误回答，生产环境通常还要配合引用校验、拒答机制和评测反馈。
RAG 的常见用途有哪些？
RAG 适合答案依赖外部资料、资料篇幅较长或更新频繁的场景。常见落地方向包括：
- 客服与售后支持，基于产品手册做排障与流程引导，例如退换货规则查询、设备报错码处理。
- 研发与运维助手，检索代码库、接口文档、告警手册和历史工单，辅助定位故障和编写修复方案。
- 医疗与临床辅助，检索诊疗指南、药品说明书和院内规范，解释检查指标或用药禁忌，供医生核对参考。
- 法律与合规检索，检索法规条文、判例和合同模板，辅助条款比对与风险提示。
- 企业内部知识助手，连接人事财务制度、SOP、会议纪要和技术方案，支持跨文档问答、总结与对比。
为什么有些企业还是宁愿用传统搜索而不是 RAG？
很多企业保留传统搜索框，是因为大量日常需求只需要定位文档本身，并不需要模型代读并生成结论。
如果用户只是想下载一份制度原文、核对某个接口定义或找一份合同模板，输入关键词返回文档列表反而更直接，链路短、成本低、结果也更可控。RAG 在检索之后还要组织上下文并调用 LLM 生成答案，只要经过模型生成，就会增加首字延迟、Token 成本以及总结偏差的风险。
选传统搜索还是 RAG，取决于用户的目标是找到原始材料，还是综合多份材料得出结论。
| 维度 | 传统搜索（搜索框） | RAG（检索 + 生成） |
|---|---|---|
| 用户目标 | 找到文档、页面、附件 | 直接得到可读答案、总结或对比结论 |
| 延迟与成本 | 通常较低，容易扩展 | 更高，需要检索和 LLM 推理 |
| 可控性 / 可审计 | 强，直接给原文链接 | 弱一些，可能误解或总结偏差，需要引用与评测 |
| 风险 | 低，主要是召回排序问题 | 更高，包括幻觉、引用错误、越权泄露 |
| 数据治理 | 相对成熟，ACL、字段过滤都好做 | 更复杂，需要检索过滤、上下文脱敏、日志治理 |
| 适用场景 | 编号、标题、关键词检索，找模板、找制度原文 | 客服解答、技术排障、制度解读、跨文档总结对比 |
| 最佳实践 | ES / BM25 + 权限过滤 | 混合检索 + 重排 + 引用溯源 + 权限过滤 + 评测闭环 |
实际落地时，很多企业会同时保留两套入口，简单查找走搜索，复杂问答走 RAG，兼顾响应速度与问答体验。
RAG 工作原理了解吗？
RAG 的工程链路分为离线索引和在线检索生成两个阶段。离线阶段把原始文档处理成可检索的数据结构；在线阶段在用户提问时完成查询理解、检索召回、上下文构建和答案生成。
离线索引阶段主要包括以下步骤：
- 文档接入与解析，从 PDF、Word、网页、Markdown 或数据库记录中提取正文、表格和结构信息。
- 清洗去噪，剔除乱码、重复页眉页脚、无意义 HTML 标签等噪声。
- 元数据提取，补充文档来源、更新时间、章节路径、租户和访问控制（ACL）等字段，供后续检索过滤与引用溯源使用。
- 文档切分（Chunking），将长文档切分为较小片段。切分粒度需要兼顾语义完整性、Embedding 模型输入上限和召回精度，块太大容易带入无关噪声，太小又会切断前置条件。具体切分策略见 RAG 文档处理篇。
- 向量化（Embedding Generation），调用 Embedding 模型将每个文本块映射为高维稠密向量。常见选择包括 OpenAI 的
text-embedding-3-small/text-embedding-3-large，以及 BGE、Qwen3-Embedding 等开源模型。 - 写入索引存储，将向量、原文片段和元数据写入 Milvus、pgvector、Elasticsearch / OpenSearch 等存储系统。索引算法与选型实践见 RAG 向量库篇。
离线索引可以通过定时批处理或变更事件触发增量更新；如果是用户在对话中临时上传文件的场景，也可以在线实时解析并写入临时索引。
在线检索与生成阶段通常按以下顺序执行：
- 接收查询与改写，获取用户的自然语言问题，必要时先做查询改写（Query Rewrite）、拆解或提取元数据过滤条件。
- 查询向量化，使用与离线索引相同的 Embedding 模型将查询转换为向量。
- 检索与重排（Retrieval & Rerank），结合元数据过滤、向量相似度检索或关键词混合检索召回候选片段，再通过 Rerank 模型按问题相关性精排。
- 上下文组装（Augmentation），将精排后的片段、原始问题、系统指令（如仅依据给定资料作答、标注引用来源）组装为完整 Prompt。
- 答案生成（Generation），LLM 基于上下文输出回答并附上参考资料链接。
检索效果不稳定时，问题往往出在切分粒度、查询改写、混合召回或重排环节，具体排查方法见 RAG 优化篇。
Embedding 是什么？
Embedding 是将文本映射到高维稠密向量空间的过程，目标是让语义相近的文本在向量空间中距离更近。
比如这三句话：
- “如何申请退款？”
- “退款流程是什么？”
- “订单怎么取消并退钱？”
它们用词不同，但表达的意图相近。经过 Embedding 模型编码后，这三句话的向量会落在相近区域，即使文档里写的是“退货与退款办理指南”，向量检索也能跳过字面差异将其召回。
常见 Embedding 维度有 768、1024、1536、3072 等。向量维度由模型结构决定，不能脱离具体模型得出“维度越高效果越好”的结论，而更高的维度会直接增加内存占用、索引构建时间和距离计算开销。以 OpenAI 为例，text-embedding-3-small 默认输出 1536 维，text-embedding-3-large 默认输出 3072 维，两者都支持通过 Matryoshka 表示学习（dimensions 参数）截断到更低维度使用。
常见 Embedding 模型可分为闭源商用 API 和开源可私有化模型两类：
| 类型 | 代表模型 | 适合场景 |
|---|---|---|
| 闭源 API | OpenAI text-embedding-3-small / text-embedding-3-large、Cohere Embed、Jina Embeddings API | 追求开箱即用、多语言效果、少运维 |
| 开源模型 | BGE 系列、Qwen3-Embedding、GTE 系列、E5 系列、Jina Embeddings 开源模型 | 数据不能出内网、需要私有化部署、希望控制成本 |
选型时，公开评测榜单 MTEB（Massive Text Embedding Benchmark）可以作为初筛参考，但最终仍需在业务自己的问题集上验证召回率、延迟和部署成本。如果业务语料包含大量内部缩写、专有型号或特定错误码，单纯依赖通用 Embedding 往往不够，通常需要配合 BM25 关键词检索使用。
向量相似度怎么计算？
文本转换为向量后，检索系统通过距离或相似度函数衡量查询向量与文档向量的接近程度，常见度量方式有三种：
| 度量方式 | 含义 | 特点 |
|---|---|---|
| 余弦相似度（Cosine Similarity） | 衡量两个向量夹角方向的一致性 | 对向量模长不敏感，文本语义检索最常用 |
| 内积（Inner Product / Dot Product） | 计算两个向量对应维度乘积之和 | 当向量已完成 L2 归一化时，内积在数值和排序结果上都与余弦相似度等价，计算更快 |
| 欧氏距离（L2 Distance） | 计算两个点在空间中的直线距离 | 受向量模长影响；若向量已做 L2 归一化，其排序结果同样与余弦距离一致 |
面试中如果被问到为什么文本检索常用余弦相似度，可以从两方面回答：一是文本长短或词频变化可能影响未归一化向量的模长，而余弦相似度只关注向量方向，能更稳定地反映语义方向是否接近；二是主流 Embedding 模型大多以余弦相似度或归一化内积作为训练目标。实际落地时，向量库索引配置的距离类型必须与 Embedding 模型推荐的度量方式一致，否则会导致召回质量下降或无法命中索引。
RAG 与传统搜索引擎的区别是什么？
传统搜索引擎和 RAG 都包含检索环节，但检索之后的交付物不同：传统搜索将候选文档按相关性排序后直接返回链接列表，由用户自行点开阅读和比对；RAG 则把召回的多个文档片段送入 LLM 上下文，做跨片段的信息提取与整合，直接生成带引用的答案。
两者在工程实现上的主要差异如下：
- 检索机制：传统搜索以倒排索引和关键词匹配（如 BM25）为核心，现代搜索也会叠加向量召回与排序模型；RAG 的检索层则围绕“为 LLM 提供高信噪比证据”设计，常结合向量检索、BM25、元数据过滤、Parent-Child 块扩展或图检索。
- 结果形态：传统搜索返回文档级或段落级列表；RAG 输出自然语言解答或结构化结论，并附上引用片段供核查。
- 延迟与成本：传统搜索单次响应通常在几十毫秒内，边际成本极低；RAG 增加了 LLM 推理环节，首字延迟通常在秒级，且每次请求都会消耗输入与输出 Token。
RAG 和微调怎么选？
“为什么不直接微调模型？”是 RAG 面试中的高频问题。两者的职责边界很清晰：RAG 解决模型缺少外部或最新知识的问题，微调（Fine-tuning）解决模型输出风格、格式或特定任务指令遵循不稳定的问题。
拿企业规章制度问答举例：RAG 相当于开卷考试，规章手册放在外部向量库里，每次回答前先检索相关条款，制度改版时只需更新索引；微调相当于闭卷背诵，通过训练调整模型权重。如果指望靠微调记住频繁变动的业务细则，不仅训练与评估周期长，模型也依然可能张冠李戴，且无法天然给出原文出处。
| 维度 | RAG | 微调（Fine-tuning） |
|---|---|---|
| 知识更新 | 更新知识库或向量索引即可 | 需要重新构造训练集、训练并评估模型 |
| 数据安全 | 知识保留在外部存储，检索时按用户 ACL 动态过滤 | 训练数据中的模式和信息会进入模型参数，难以按用户权限做细粒度隔离 |
| 幻觉控制 | 可要求模型仅依据召回原文作答并标注引用 | 模型凭参数生成，仍可能编造细节，且无法直接绑定原文引用 |
| 成本结构 | 向量存储成本 + 每次请求的检索与上下文 Token 成本 | 数据清洗标注、训练算力、模型托管与多版本维护成本 |
| 适合场景 | 知识密集型问答、企业知识库、法规制度、产品文档、实时信息 | 语气风格对齐、特定结构化格式输出、领域术语理解、垂类小模型能力蒸馏 |
| 主要风险 | 召回遗漏、上下文噪声干扰、权限过滤遗漏 | 灾难性遗忘、训练数据过拟合、知识过期后回滚与更新成本高 |
在复杂垂直场景（如法律、医疗、金融投研）中，两者也可以配合使用：用微调让模型熟悉领域术语、推理规范和固定输出格式，再用 RAG 注入实时业务数据和可追溯的原文证据。对于大多数工程团队，建议先把 RAG 链路和评测集搭稳，确认痛点确实是模型指令遵循或领域语言风格问题后，再评估是否引入微调。
长上下文窗口会取代 RAG 吗？
不会。两者是互补关系，适用边界取决于数据规模、调用频次和治理要求。
长上下文窗口（如 128K 到 1M+ Token）适合单次、少文档的完整阅读任务，例如分析一份完整的财报 PDF、理解单个中小型代码模块，或总结一段长会议记录。这类任务需要通读全文，切块检索反而容易漏掉全局脉络。
一旦进入企业级知识库场景，长上下文就会遇到四个硬约束：
- 知识库规模远超窗口上限：企业文档、历史工单、合同库动辄数千万到数亿 Token，根本无法全量塞入单次请求。
- 延迟与调用成本成倍放大：即使知识库只有几十万 Token 能勉强塞进超长窗口，每次普通问答都携带几十万输入 Token（即使配合 Prefix Caching），首字延迟（TTFT）和账单成本也远高于只传入几千 Token 的检索片段。
- 注意力稀释（Lost in the Middle）：上下文中混入大量无关文档时，模型对中间位置关键事实的提取准确率会明显下降，更容易被相近但无关的条款干扰。
- 权限隔离与审计溯源：企业知识库要求按租户、角色和文档 ACL 严格过滤可见范围，并明确记录回答引用了哪篇文档的哪一页。RAG 的检索层天然承担了前置权限过滤、缩小证据范围和绑定引用元数据的职责。
RAG 有哪些演进阶段？
业界通常将 RAG 的架构演进划分为三个阶段：
| 阶段 | 典型链路 | 特点 |
|---|---|---|
| Naive RAG | 文档切块 → Embedding → Top-K 检索 → LLM 生成 | 最基础、最容易实现，适合 Demo 和简单知识库 |
| Advanced RAG | Query Rewrite / HyDE → 混合检索 → Rerank → 上下文压缩 → LLM 生成 | 重点解决召回不准、上下文噪声和排序不稳 |
| Modular RAG | 检索器、重排器、压缩器、路由器、生成器等模块可插拔组合 | 按业务场景动态路由，适合生产系统和复杂 Agent |
Naive RAG 能够快速跑通原型，但在真实复杂文档上容易遇到切分破坏结构、专有名词漏召回和 Top-K 排序不准的问题。Advanced RAG 在检索前加入查询改写、在检索中引入混合召回与重排、在检索后加入上下文压缩。Modular RAG 则进一步把解析、路由、检索（向量、全文、SQL、图谱）和自检拆成可编排模块，按问题类型动态选择链路。
RAG 的工程局限有哪些？
前面已经介绍了 RAG 在知识更新、私有数据隔离和引用溯源上的优势。在生产落地时，更需要提前评估它的五个工程代价：
- 检索质量直接决定回答上限：如果 PDF 表格在解析时已经错位，或者关键前置条件在切块时被截断，未进入候选池的证据无论下游 LLM 多强都无法凭空恢复。
- 上下文噪声会误导生成：召回的相似片段中如果混有旧版本文档或相近产品的规则，模型很容易把不同来源的条件拼凑成错误结论。
- 端到端延迟增加：一次完整请求可能串联查询改写、Embedding 编码、多路召回、Cross-Encoder 重排和 LLM 生成，每一跳都会累加耗时，需要针对高并发场景设计缓存、超时与降级。
- 多存储组件的一致性维护复杂：文档新增、修改、删除或权限变更时，需要同步更新向量库、全文索引和元数据库，处理不当就会召回已删除或已无权访问的“幽灵数据”（详见 RAG 知识库更新篇）。
- 持续的 Token 与运维开销：虽然省去了模型训练费用，但每次查询都需要拼接检索片段作为输入 Token，同时还要维护向量索引与离线评测管线。
总结
RAG 的核心价值是把大模型的回答约束在可检索、可引用、可做权限控制的外部证据上。
在技术选型上可以把握三条主线：
- 只需要定位原始文件时走传统搜索；需要跨片段提炼、总结或解答具体问题时走 RAG。
- 知识变动频繁、要求数据按权限隔离并附上原文引用时优先用 RAG；需要调整模型语气风格、固定输出格式或蒸馏垂直能力时考虑微调。
- 单篇长文档全局阅读适合直接利用长上下文窗口；跨海量文档的知识库问答依然依赖 RAG 先缩小证据范围。
Demo 跑通只完成了向量库接入，生产级 RAG 真正耗时的是文档解析质量、混合召回与重排调优、增量更新一致性以及固定评测集回归。
面试常问问题自查：
- 什么是 RAG？它主要解决大模型的哪些局限？
- RAG 和传统搜索引擎有什么区别？什么场景下没必要上 RAG？
- RAG 和微调怎么选？什么情况下需要将两者结合？
- RAG 系统中如何选择 Embedding 模型？为什么不能只看 MTEB 榜单？
- 余弦相似度、内积和欧氏距离有什么区别？向量归一化后它们有什么关系？
- 为什么加了 RAG 还是会产生幻觉？应该从哪些环节排查和缓解？
- 什么是 Lost in the Middle 问题？为什么长上下文窗口不能完全取代 RAG？
- Naive RAG、Advanced RAG 和 Modular RAG 的核心差异是什么？