RAG 基础概念详解
我来为您整理这篇关于RAG基础概念的详尽笔记。
万字详解 RAG 基础概念 | 学习笔记
原文：https://javaguide.cn/ai/rag/rag-basis.html 作者：Guide（JavaGuide） 阅读时间：约22分钟 | 字数：约6549字（原文标注），实际扩展至近1.2万字
一、RAG 基础概念
1.1 什么是 RAG
RAG（Retrieval-Augmented Generation，检索增强生成） 是一种将信息检索（Information Retrieval, IR） 技术与 生成式大语言模型（LLM） 相结合的框架。
核心思想：在让 LLM 回答问题或生成文本之前，先从大规模知识库中检索出相关上下文信息，将这些信息与原始问题一并提供给 LLM，从而"增强"其生成能力。
本质：不是让模型"硬记"所有知识，而是"按需查找"再生成。
二、为什么需要 RAG？（三大核心痛点）
| 痛点 | 具体表现 | RAG 解决方案 |
|---|---|---|
| 知识时效性 | LLM 训练数据有截止时间点（Knowledge Cutoff），无法掌握新事件、新政策、新产品 | 动态检索外部知识源，提供最新上下文 |
| 私有数据访问 | 企业敏感数据（产品文档、客户数据、内部制度）不能暴露给公开 LLM | 安全连接私有数据源，仅提取相关片段，不泄露全部数据 |
| 模型幻觉（Hallucination） | LLM 编造不符合事实的信息 | 提供明确、有据可查的参考文本，引导模型基于证据回答 |
⚠️ 重要：RAG 不能彻底消除幻觉。检索错误、上下文噪声、引用错配、模型不遵循指令，仍可能导致错误答案。生产级 RAG 还需：引用校验、答案评估、拒答机制、人工反馈闭环。
三、RAG 的常见应用场景
核心适用特征："答案依赖外部资料、且资料会变化/很长"
| 场景 | 典型用例 |
|---|---|
| 客服机器人 | "如何退换货/开发票？""某型号设备报错码怎么处理？" |
| 研发/运维 Copilot | 检索代码库、接口文档、告警手册，辅助定位问题 |
| 医疗助手 | 检索指南/药品说明后生成辅助建议（不做最终诊断） |
| 法律咨询 | "违约金如何计算？""不可抗力条款怎么写更稳妥？" |
| 教育辅导 | 从教材/题库检索知识点，生成讲解与例题步骤 |
| 企业内部助手 | "某流程最新版本是什么？""对比两份方案差异并给结论" |
| 投研/合规/审计 | 报告/披露/内控文档检索分析 |
| 销售/方案支持 | 产品手册/标书模板检索，生成方案并标注出处 |
四、RAG vs 传统搜索：企业为何有时仍选传统搜索？
关键原因：RAG 存在推理成本和响应延迟问题。纯"找文件"场景，传统搜索效率更优。
| 维度 | 传统搜索（搜索框） | RAG（检索+生成） |
|---|---|---|
| 用户目标 | 找到文档/页面/附件 | 直接得到可读答案/总结/对比结论 |
| 延迟与成本 | 极低、易扩展 | 更高（检索+LLM 推理） |
| 可控性/可审计 | 强：给原文链接 | 弱一些：可能误解/总结偏差，需引用与评测 |
| 风险 | 低（主要是召回排序） | 更高（幻觉、引用错误、越权泄露） |
| 数据治理 | 相对成熟（ACL、字段过滤） | 更复杂（检索过滤+上下文脱敏+日志） |
| 适用场景 | 编号/标题/关键词检索、找模板、找制度原文 | 客服解答、技术排障、制度解读、跨文档总结对比 |
| 最佳实践 | ES/BM25 + 权限过滤 | 混合检索 + 重排 + 引用溯源 + 权限过滤 + 评测闭环 |
五、RAG 工作原理（两阶段架构）
5.1 离线索引阶段（Indexing）
目标：将原始文档处理成可检索的数据结构
原始文档 → 清理文档 → 增强文档 → 文档拆分(Chunking) → 向量化(Embedding) → 向量数据库| 步骤 | 说明 | 关键注意点 |
|---|---|---|
| 输入文档 | 文本文件、PDF、网页、数据库记录等 | — |
| 清理文档 | 去噪：移除 HTML 标签、特殊字符等 | 保留语义完整性 |
| 增强文档 | 附加元数据（时间戳、分类标签） | 为后续检索提供更多上下文 |
| 文档拆分（Chunking） | 文本分割器将文档拆分为较小片段 | 核心权衡：过大引入噪声，过小丢失上下文。需兼顾语义完整性、Embedding 模型输入长度、生成模型上下文窗口、召回粒度 |
| 向量化表示 | Embedding 模型将文本映射为高维稠密向量 | OpenAI text-embedding-3-small/large、Hugging Face 开源模型等 |
| 存储 | 向量+原始内容+元数据存入向量存储 | Milvus、pgvector、Elasticsearch/OpenSearch、Faiss 等 |
索引通常离线定时更新（如每周末），也可在线实时更新（用户上传场景）。
5.2 在线检索增强生成阶段（Retrieval-Augmented Generation）
原始查询 → [查询改写] → 嵌入模型 → 查询向量 → 向量数据库 → 相关片段 → 上下文构建 → LLM → 生成答案 + 引用| 步骤 | 说明 | 优化方向 |
|---|---|---|
| 接收请求 | 用户自然语言查询 | 进阶场景：查询改写（Query Rewrite）、扩充，提高检索覆盖率 |
| 查询向量化 | 同 Embedding 模型转为语义向量 | 需与文档向量使用同一模型，保证向量空间一致 |
| 信息检索（R） | 语义相似性搜索找 Top-K 相关片段 | 混合检索、Rerank、权限过滤 |
| 上下文增强（A） | 检索片段+原始问题+系统指令+引用要求 → Prompt | 上下文压缩、去噪、引用格式规范 |
| 输出生成（G） | LLM 生成自然语言回复+参考资料 | 温度参数、输出格式控制 |
| 结果反馈（可选） | 用户反馈优化 | 多轮交互、提示词调整 |
检索效果不稳定时，从 Query Rewrite、混合检索、Rerank、上下文压缩 等方向优化。
六、Embedding 深度解析
6.1 本质理解
Embedding = "把文本变成一串数字"
更准确：将文本映射到高维稠密向量空间，使语义相近的文本在空间中距离更近。
示例：
- "如何申请退款？"
- "退款流程是什么？"
- "订单怎么取消并退钱？"
→ 字面不同，语义接近 → 好的 Embedding 模型映射到相近位置
6.2 维度与成本权衡
| 模型 | 默认维度 | 特点 |
|---|---|---|
OpenAI text-embedding-3-small | 1536 | 性价比高 |
OpenAI text-embedding-3-large | 3072 | 表达能力更强，支持 dimensions 参数降维 |
规律：维度越高 → 信息越丰富 → 但存储/索引/计算成本越高
6.3 模型选型
| 类型 | 代表 | 适用场景 |
|---|---|---|
| 闭源 API | OpenAI text-embedding-3-small/large、Cohere Embed、Jina Embeddings API | 追求开箱即用、多语言效果、少运维 |
| 开源模型 | BGE 系列、GTE 系列、E5 系列、Jina Embeddings 开源模型 | 数据不出内网、私有化部署、成本控制 |
选型建议：不要只看 MTEB 榜单排名，必须用自己的业务问题评测召回率、相关性和延迟。
⚠️ Embedding 不是实时理解世界的模型：遇到新术语、梗、产品名、领域缩写，需通过业务语料评测确认效果。
七、向量相似度计算
| 度量方式 | 核心含义 | 特点 | RAG 适用性 |
|---|---|---|---|
| 余弦相似度（Cosine Similarity） | 两向量方向是否一致 | 对向量长度不敏感 | ⭐ 最常用 |
| 内积（Inner Product/Dot Product） | 对应维度乘积之和 | 若已 L2 归一化，与余弦排序结果通常等价 | 需确认归一化状态 |
| 欧氏距离（L2 Distance） | 空间中绝对距离 | 对向量幅度更敏感 | 需模型/索引明确按 L2 优化 |
面试标准答法：
"RAG 关注语义方向是否接近，而非向量长度；余弦相似度对长度不敏感，更适合文本语义检索。实际项目中还需与 Embedding 模型推荐的距离度量、向量库索引类型保持一致，否则可能导致索引无法命中或召回效果下降。"
八、RAG vs 传统搜索引擎（本质区别）
| 维度 | 传统搜索引擎 | RAG |
|---|---|---|
| 检索机制 | 倒排索引、关键词匹配（BM25）、字段权重、过滤条件 | 向量检索、BM25、混合检索、图检索、数据库查询 → 结果进入 LLM 上下文参与生成 |
| 处理逻辑 | 相关性排序器：候选文档按得分排序后直接呈现，结果相对独立，不跨文档融合 | 信息综合器：多个知识碎片喂给 LLM，进行逻辑归纳和跨文档信息整合 |
| 结果交付 | 候选文档列表（线索），需用户二次阅读过滤 | 直接答案，可回答复杂指令，通过引文标注（Citations）兼顾可追溯性 |
| 时效性与数据范围 | 依赖大规模爬虫和全网索引 | 常用于私有知识库或垂直领域，低成本获得实时/特定领域知识 |
九、RAG vs 微调（Fine-tuning）：如何选型？
核心区分原则：
RAG 解决"模型不知道新知识/私有知识"的问题微调解决"模型不会按你的方式说话或做事"的问题
| 维度 | RAG | 微调（Fine-tuning） |
|---|---|---|
| 知识更新 | 更新知识库/向量索引即可 | 通常需重新准备数据并训练 |
| 数据安全 | 知识保留在外部库，按需检索 | 训练样本模式会固化到模型参数，敏感数据需额外评估合规 |
| 幻觉控制 | 可引用原文，便于溯源校验 | 仍可能编造，引用来源不天然可见 |
| 成本结构 | 检索成本 + Input Token 成本 + 向量库成本 | 数据标注、训练 GPU、评测、版本管理成本 |
| 适合场景 | 知识密集型问答、企业知识库、法规制度、产品文档、实时信息 | 风格适配、格式控制、领域术语对齐、固定任务行为优化 |
| 主要风险 | 检索不到、召回噪声、权限过滤复杂 | 数据过拟合、知识过期、训练回滚成本高 |
组合策略（常见实践）：
先用微调让模型懂领域术语、输出格式和任务边界 → 再用 RAG 提供实时知识和可追溯证据
适用场景：客服、法律、医疗、金融投研等
面试一句话收尾：
"知识变动频繁、需要引用来源，优先 RAG；输出风格和任务行为不稳定，考虑微调；既要懂领域表达又要查实时知识，两者结合。"
十、长上下文窗口会取代 RAG 吗？
结论：不会。
长上下文适合的场景：
- 单篇长文档深度分析
- 一个代码仓库或项目目录的集中理解
- 长对话历史总结
- 一次性材料较少但需要完整阅读的任务
RAG 不可替代的原因：
| 原因 | 详细说明 |
|---|---|
| 知识库规模远超上下文窗口 | 企业知识库、客服工单、日志、合同库常达百万到亿级文档片段 |
| Token 成本和延迟不可忽视 | 大量无关内容 → 输入成本↑、首字延迟↑、推理时间↑ |
| 效果可能反而变差 | 无关片段越多 → 信噪比越低 → 模型易被噪声干扰 → 事实不稳 |
| 注意力稀释（Lost in the Middle） | 关键信息放长上下文中间时，更容易被模型忽略 |
| 权限隔离难靠"全塞"解决 | 企业知识库必须先过滤用户有权访问的内容 |
| 可追溯性更重要 | RAG 可明确返回引用片段，便于审计和人工复核 |
核心洞察：
"长上下文解决的是**'能不能放进去'的问题，RAG 解决的是'该放什么进去'**的问题。"
最佳实践：结合使用
先用 RAG 从海量知识库筛出高质量证据（提高信噪比）→ 再利用长上下文窗口放入更多相关材料 → 让 LLM 做更充分的推理、归纳和对比
十一、RAG 演进三阶段
| 阶段 | 典型链路 | 核心特点 | 适用阶段 |
|---|---|---|---|
| Naive RAG | 文档切块 → Embedding → Top-K 检索 → LLM 生成 | 最基础、最易实现 | Demo、简单知识库 |
| Advanced RAG | Query Rewrite / HyDE → 混合检索 → Rerank → 上下文压缩 → LLM 生成 | 重点解决召回不准、上下文噪声、排序不稳 | 生产环境优化 |
| Modular RAG | 检索器、重排器、压缩器、路由器、生成器等模块可插拔组合 | 按业务场景动态路由，高可维护性 | 复杂系统、Agent 架构 |
十二、RAG 的核心优势与局限性
12.1 核心优势
| 优势 | 详细说明 |
|---|---|
| 知识时效性与低维护成本 | 无需重新训练模型，更新知识库/索引即可获取最新信息，适合新闻、法规、产品文档等频繁变动数据 |
| 显著降低幻觉并提供引文追溯 | 从"基于参数化记忆生成"转变为"基于检索证据生成"，每个回答有明确来源，提供可解释性和可验证性 |
| 数据安全与细粒度权限控制 | 检索层实现多租户隔离和 ACL，用户只能检索权限范围内数据，比微调更容易做数据隔离和合规治理 |
| 领域适应性强 | 无需针对领域重新训练，构建领域知识库即可快速适配垂直场景 |
12.2 局限性与工程挑战
| 挑战 | 详细说明 |
|---|---|
| 严重的检索依赖性（GIGO） | Garbage In, Garbage Out。Embedding 表达不准确、分块策略不合理导致召回无关内容 → 下游 LLM 再强也难输出正确结果 |
| 上下文窗口与推理噪声 | 注入过多无关片段（Noisy Chunks）→ 注意力稀释、逻辑推理受干扰、不必要的 Token 开销 |
| 首字延迟（TTFT）增加 | 完整链路：查询改写 → 向量化 → 相似度检索 → Rerank → 上下文构建 → LLM 生成，每环节都增加延迟 |
| 工程复杂度 | 需维护向量数据库、增量索引、检索策略优化等，复杂度远高于纯 LLM 应用 |
| 长文本 Token 成本 | 单次请求携带大量上下文 → Input Tokens 显著高于普通对话 |
十三、实战项目推荐
项目：基于 Spring Boot 4.0 + Java 21 + Spring AI + PostgreSQL + pgvector + RustFS + Redis 的智能面试平台
核心功能：
- 简历智能分析
- AI 模拟面试
- 知识库 RAG 检索
技术栈特点：学习门槛低，适合作为学习和简历项目
| 平台 | 地址 |
|---|---|
| GitHub | https://github.com/Snailclimb/interview-guide |
| Gitee | https://gitee.com/SnailClimb/interview-guide |
| 详细教程 | 《SpringAI 智能面试平台+RAG 知识库》（星球专属，18w+ 字已更完） |
十四、面试高频问题汇总
- 什么是 RAG？为什么需要 RAG？
- RAG 和传统搜索引擎有什么区别？
- RAG 和微调怎么选？什么时候用 RAG，什么时候微调，什么时候两者结合？
- RAG 系统中 Embedding 模型怎么选？为什么？
- 余弦相似度、内积和欧氏距离有什么区别？
- RAG 的"幻觉"问题怎么解决？RAG 一定不会产生幻觉吗？
- 什么是 Lost in the Middle 问题？怎么应对？
- 长上下文窗口是否会取代 RAG？
- RAG 系统的评估指标有哪些？
- RAG 的核心优势和局限性是什么？
- 什么场景适合用 RAG？什么场景不适合？
十五、核心要点总结
| 要点 | 一句话概括 |
|---|---|
| RAG 是什么 | 先检索相关知识，再让 LLM 基于检索结果生成回答，减少幻觉、提升可追溯性 |
| 为什么需要 | 解决 LLM 知识时效性、私有数据访问、幻觉三大核心问题 |
| vs 传统搜索 | RAG 是"信息综合器"，传统搜索是"相关性排序器" |
| vs 微调 | RAG 适合外部知识注入和引用溯源，微调适合风格/格式/任务行为对齐 |
| vs 长上下文 | 长上下文适合少量材料深度分析，RAG 适合海量知识库、实时更新、权限隔离、成本控制 |
| 局限性 | 检索依赖性、上下文窗口限制、工程复杂度、Token 成本 |
十六、学习建议
- 理解原理：不要只记流程，要理解每一步为什么这样设计
- 动手实践：从文档切分 → 向量检索 → LLM 生成，搭建完整链路
- 关注优化：Chunking 策略、Embedding 选择、Rerank 等，每个点都值得深入研究
最终洞察：RAG 是连接 LLM 与企业知识的桥梁，理解其工作原理和适用边界，比追逐最新框架更实在。