RAG Docs
首页 系统学习 做项目 快速回查 讲解 / 面试 知识地图
返回首页
当前页 · 辨析与讲解
共享词汇表 方案边界 知识地图
概念名称
✕
Explain / Compare / Interview

RAG 完全理解

这页做横向辨析、讲解表达和面试复习，涵盖 10+ 个参考维度和 23 个可检索概念。你可以把它当成”概念边界和方案判断”的训练场，而不是第一次学习 RAG 的入口。

5D 框架 横向辨析 场景判断 讲解表达
这页负责术语速查、横向辨析和面试复习，不负责数学原理推导。 想深入理解向量空间直觉请看 02 · 概念手册；第一次学习请回到 总站首页。
适合任务
面试复习、方案说明、概念边界判断，以及把 RAG 讲清楚给别人听。
一句话版本：RAG 让 AI 在回答前先去查资料，而不是只靠训练时记住的知识。它解决的核心问题是"LLM 知识过时 + 不知道你的私有数据"。
普世方法论
从"记忆"到"检索"的范式转移
RAG 背后的核心思想在软件工程里普遍存在：不要把所有东西都存在最快但最贵的地方。CPU 缓存极快但极小；内存快但有限；硬盘慢但无限。LLM 的训练记忆就像 CPU 缓存——精炼但有限；向量数据库就像内存——可按需查询；原始文档就像硬盘——完整但需要检索。RAG 实现了这三层的协同，让"智能"来自动态检索，而不是静态记忆。
RAG 的完整流程（一眼看懂）
原始文档
PDF、网页、笔记、代码库
→
切块
Chunking
按段落/语义切
→
向量化
Embedding
文字→数字向量
→
向量库
Vector DB
存储+检索
↓ 用户提问时
用户提问
"我们的退款政策是什么？"
→
检索
Retrieval
找最相关的块
→
注入 Context
把检索到的内容
塞进 prompt
→
LLM 生成
基于真实内容
生成回答
RAG 解决了什么问题
纯 LLM 的两个致命缺陷

① 知识截止日期——不知道最新信息
② 不知道你的私有数据——公司文档、产品手册、内部知识库对它是透明的

结果：幻觉（Hallucination）——没有依据时会自信地编造答案
RAG 的解法

每次回答前先"查资料"——从你的知识库里检索相关内容，附在 prompt 里给 LLM 参考。

LLM 不再靠记忆，而是基于检索到的真实内容生成答案，幻觉大幅降低。
5D 拆解地图
维度RAG 的关键问题
D1 分层解构数据层 / 索引层 / 检索层 / 生成层——每层独立优化
D2 对比辨析有RAG vs 没有RAG；RAG vs 微调；稀疏检索 vs 稠密检索
D3 类比迁移开卷考试 / 图书馆馆员 / Google 搜索 + 摘要生成
D4 错误雷达Chunk 越小越好？向量相似 = 语义相关？RAG = 微调的替代？
D5 实战锚定客服知识库 / 法律文书 / 预售场景 / ToB 话术
RAG 包含两个独立阶段、四个子层。建设期（离线）和查询期（在线）完全分离，优化方向不同。
普世方法论
分层架构：每层单一职责，故障隔离
计算机网络 OSI 7层模型、MVC 架构、微服务架构——都在用同一个思想：把复杂系统切分成职责单一的层，每层只需优化自己的问题。RAG 的四层架构同理。好处是：出问题时能精准定位到哪一层，不会牵一发动全身。这是系统设计的核心原则之一。
建设期（离线，一次性或定期更新）
📂 数据层 Data Layer
关注：原始数据的质量和格式
核心工作：数据清洗（去除噪声、格式统一）、文档解析（PDF表格/图片处理）、数据去重
核心原则：Garbage In, Garbage Out ——数据质量决定 RAG 天花板，优化检索算法无法弥补烂数据
🔢 索引层 Index Layer
关注：如何把文档变成可检索的形式
核心工作：Chunking（切块策略）+ Embedding（向量化）+ 存入 Vector DB
关键决策：块的大小（太大=噪声多，太小=上下文丢失）、块的 overlap（重叠）防止语义被切断、Embedding 模型选择
查询期（在线，每次用户提问时触发）
🔍 检索层 Retrieval Layer
关注：如何找到最相关的内容
核心工作：把用户问题向量化，在 Vector DB 里找最近邻，返回 Top-K 个块
关键决策：检索方式（稠密/稀疏/混合）、Top-K 数量、Reranking（重排序）
✨ 生成层 Generation Layer
关注：如何把检索结果转化为高质量回答
核心工作：把检索到的块注入 prompt，引导 LLM 基于这些内容回答
关键决策：Prompt 模板设计、上下文排列顺序（Lost in the Middle 问题）、引用来源标注
四层的优化方向完全不同
层出问题的症状优化方向
数据层回答基于错误信息数据清洗、去重、格式修复
索引层找到的块上下文残缺调整 Chunk 大小和 overlap
检索层找到的块和问题不相关换检索策略、加 Reranking
生成层有正确信息但回答还是差优化 Prompt 模板
调试 RAG 时的第一步：先判断问题出在哪一层，不要上来就调整所有参数。分层诊断才能精准优化。
对比 1：有 RAG vs 没有 RAG
纯 LLM（没有 RAG）

用户问："我们 Q3 的退款政策是什么？"

LLM：凭训练时的记忆回答，可能一本正经地编造一个听起来合理的政策

→ 幻觉风险高
→ 不知道你的私有数据
→ 知识有截止日期
LLM + RAG

用户问同样的问题

系统先从知识库检索到《退款政策v3.2.pdf》的相关段落，附在 prompt 里

LLM 基于真实文件回答，还能标注"来源：第2页第3段"

→ 可溯源，可验证
→ 知识库更新即生效
对比 2：RAG vs 微调（Fine-tuning）
维度RAGFine-tuning
解决的问题知道什么（知识注入）怎么说（行为改变）
适合场景知识频繁更新、需要可溯源固定风格/格式、任务专一化
知识更新更新知识库即生效，几乎实时需要重新训练，耗时耗费
可解释性可以展示"参考了哪些文档"黑盒，无法解释知识来源
幻觉控制强——有真实内容可参考弱——仍可能编造
成本低——主要是 Embedding + DB 成本高——GPU 训练成本
不适合需要改变模型行为/推理方式知识量大且频繁更新
不是二选一：最佳实践通常是两者结合——先微调让模型掌握领域风格，再用 RAG 注入最新知识。
普世方法论
工具选择原则：按问题类型匹配工具，而不是用同一把锤子打所有钉子
RAG 解决"知识层面"的问题（知道什么），微调解决"行为层面"的问题（怎么做）。这个"分清问题域再选工具"的思路，在工程里处处适用：数据库选型（OLAP vs OLTP）、缓存策略（Redis vs Memcached）、消息队列（Kafka vs RabbitMQ）——都是先问"这是什么性质的问题"再选方案。
对比 3：稀疏检索 vs 稠密检索 vs 混合检索
稀疏检索
BM25 / TF-IDF
基于词频匹配。速度快，可解释，专业术语/代码/型号精确匹配好。

缺陷：不理解语义，"汽车"≠"车辆"
稠密检索
向量相似度
基于语义相似度。理解同义词、上下文关系，模糊查询好。

缺陷：精确词匹配弱，Embedding 模型有偏差
混合检索
Hybrid Search
两者结合，用 RRF（互惠排名融合）合并结果。

生产环境推荐——兼顾精确匹配和语义理解
概念索引：点击任意概念标签，立即查看深度解析。共 23 个 RAG 核心概念，覆盖全文所有橙色虚线词。
🔧 基础流程
Garbage In, Garbage Out Chunking · 切块策略 Overlap · 块重叠 Embedding · 向量化 Vector DB · 向量数据库
🔍 检索技术
Retrieval · 检索 稀疏 vs 稠密检索 混合检索 · Hybrid Search RRF · 互惠排名融合 Reranking · 重排序 召回率 · Recall Query 改写 / 扩展 Metadata Filter · 元数据过滤
🏗 架构选型
Fine-tuning vs RAG 实时性场景 · 替代方案
🧠 LLM 行为
Hallucination · 幻觉 注意力机制 & Lost in the Middle Lost in the Middle LLM 行为 · 深度理解 Few-shot · 少样本提示
📐 高级概念
同构 · Isomorphism Query 与 Document · 双编码器 Token 与汉字 · 换算关系
💡 这些概念词在其他 Tab 的正文中也以橙色虚线标注，点击文中的词同样可以查看解析。
RAG 是一个细节决定成败的系统。以下5个误解是实际项目中最高频的失败原因，每一个都有人踩过真实的坑。
误解 01 Chunk 越小，检索越精准
✕ 直觉 切得越细，每块越"纯粹"，检索噪声越少
✓ 事实 Chunk 太小会丢失上下文，检索到的片段无法独立理解
例子 退款政策被切成50字小块：第1块「申请退款需要在购买后」，第2块「30天内提交申请，并附上」，第3块「订单截图方可受理」——每块单独看都残缺不全，LLM 无法理解完整条件。
解法 起点 256–512 token（约128–340汉字），加 20–30% overlap；或用 Parent-Child Chunking：小块检索，大块注入。
误解 02 向量相似度高 = 回答了用户的问题
✕ 直觉 向量距离近代表语义相关，语义相关就能回答问题
✓ 事实 语义相似 ≠ 回答了问题。「取消原因」和「取消步骤」语义相近，但一个问 Why，一个问 How
例子 用户问「如何取消订单」，Top-1 检索结果是「取消订单的常见原因（买错了/不需要了）」——语义确实很近，但根本没有回答操作步骤。这是 RAG 失败最常见的原因。
解法 Reranking（重排序）：用交叉编码器把 query+document 拼在一起联合判断「这块内容是否真的回答了这个问题」，而不是只比较表面相似度。
误解 03 RAG 是微调的替代品，能解决所有 LLM 问题
✕ 直觉 有了 RAG，就不需要微调了；RAG 能解决 LLM 的一切局限
✓ 事实 RAG 解决「知道什么」（知识注入），微调解决「怎么做」（行为改变），两者解决的是完全不同的问题
例子 想让 LLM 输出格式永远是 JSON、始终以客服语气回答——这是行为稳定性问题，RAG 注入「请输出 JSON」的文档效果非常不稳定。简单场景用 system prompt + few-shot 就够；复杂场景才需要微调。
解法 先判断是「知识问题」还是「行为问题」：知识→RAG；行为→先试 prompt，不稳定再微调；两者都要→先微调再加 RAG。
误解 04 检索到了相关内容，答案就一定准确
✕ 直觉 把正确的文档给了 LLM，它就会给出正确的答案
✓ 事实 检索正确只是前提。Prompt 没有约束「只用提供的内容回答」时，LLM 会混合检索内容和训练记忆，产生更难识别的混合性幻觉
例子 检索到了正确的退款政策段落，但 LLM 把它和训练数据里「电商行业常见的7天退款」混合，输出了一个半真半假的回答——既有真实条款又有编造内容，比纯幻觉更难察觉。
解法 Prompt 必须明确：「仅基于以下内容回答，如果内容中没有相关信息，请明确说明无法找到答案，不要依据其他知识推测。」
误解 05 RAG = 把文档全部塞进 Context Window
✕ 直觉 Context Window 越来越大了，直接把所有文档塞进去更简单可靠
✓ 事实 RAG 的核心价值是「精确检索少量最相关内容」，不是「全部塞入」
例子 10万字文档全部塞入：① Token 成本 ≈ $0.5–1/次（GPT-4o），高频查询费用爆炸；② Lost in the Middle——LLM 对中间部分注意力弱，关键信息放错位置就被忽略；③ 仍然可能超过 context window 上限。
解法 文档 <10页 → 可以直接放 system prompt；10–50页 → 看查询频率决定；>50页 → 必须 RAG。精确检索 5–10 个块，比粗暴塞入更准更省。
RAG 失败的诊断清单
症状可能原因排查方向
回答内容是编造的检索失败，或 Prompt 没限制 LLM 只用提供的内容检查检索结果；加「仅基于以下内容回答」约束
检索到的内容不相关Embedding 模型不适合领域；Chunk 策略问题换 Embedding 模型；调整 Chunk 大小；加 Reranking
回答太笼统，缺细节Chunk 太小，上下文丢失增大 Chunk 大小；增加 overlap；用父子切块
专业术语匹配失败纯向量检索对精确词匹配弱改用混合检索
多文档综合问题回答差Top-K 太小，相关内容没全部检索到增大 Top-K；加 Query 扩展
业务场景是理解技术选型的最好工具。同样是 RAG，客服知识库和法律文书的 Chunk 策略、检索方式完全不同。
🎧 客服知识库 · 实时 QA 场景
高频查询 精确匹配 频繁更新
痛点 用户咨询量大，产品手册每月更新，新员工培训周期长，回答质量参差不齐。
数据层
产品手册 PDF + 历史工单  ·  清洗重复/矛盾条目，统一格式
索引层
按问答对切块（128–256 token），保留「问题」和「答案」完整配对  ·  Embedding: text-embedding-3-small（成本低，支持中英混合）
检索层
混合检索：稀疏匹配产品型号 + 稠密理解用户意图  ·  Top-K=5 + Reranking（确保「回答了用户的问题」而非仅语义相似）
生成层
Prompt 约束「仅基于以下内容回答」，每条答案标注来源工单编号，支持客服主管核查
洞察 产品手册更新后只需重新 Embedding 变更部分，当天即生效。知识更新延迟从「2周新员工培训」降到「1小时文档更新」。
⚖️ 法律合同审查 · 长文本精读场景
长文档 精确条款 高准确率
痛点 律师审查合同需在数百页文件中定位特定条款，传统关键词搜索无法理解语义，人工阅读效率极低。
数据层
合同 PDF（OCR 处理扫描件） ·  结构化标注：甲方/乙方/期限/违约条款  ·  去除页眉页脚干扰
索引层
按完整条款切块（512–1024 token） ·  元数据：合同类型、签约日期、甲乙方名称  ·  Parent-Child Chunking：小块定位 + 大块注入
检索层
元数据过滤（合同类型=采购合同）缩小候选集  →  向量检索语义相关条款  →  BM25 精确匹配法律术语（「不可抗力」「违约金」）
生成层
Prompt 要求标注「依据第 X 条第 X 款」 ·  附置信度提示  ·  禁止引用检索结果范围外的内容
洞察 法律场景核心是可溯源。Parent-Child Chunking 解决了「精确定位」与「完整上下文」的矛盾：小块命中正确条款，大块保证 LLM 理解完整语境。
📊 预售知识库 · 多文档综合场景
跨文档综合 元数据过滤 竞品对比
痛点 销售在客户会议前需快速准备行业案例、竞品分析、历史成功案例，内部文档分散，人工翻找耗时半天。
数据层
历史项目文档 + 竞品分析报告 + 客户访谈记录  ·  匿名化处理敏感客户信息
索引层
按章节切块（256–512 token） ·  元数据标注：行业 / 年份 / 客户规模 / 方案类型
检索层
查询示例：「金融行业 TOP100 的 AI 客服案例」
① 元数据过滤 industry=金融, scale=大型（10万条 → 500条）
② 在500条内做混合检索 + RRF 合并
③ Reranking 取 Top-5
生成层
输出：结构化摘要 + 来源文件名 + 推荐相关案例列表  ·  支持「按行业/规模/方案类型」筛选再生成
洞察 「先元数据过滤，再向量检索」是本场景关键：低成本的结构化过滤（O(1)）把搜索空间从10万缩到500，再做高成本的语义检索，精准度和速度都大幅提升。
📖 词典知识库 · 精确查询 + 语义探索场景
结构化数据 MCP 协同 多语言
痛点 用户提问千变万化（「excuse 和 excuse me 有什么区别」），词典数据结构高度标准化，需同时支持精确词条查找和模糊语义探索。
数据层
权威词典（牛津/朗文） ·  解析词条结构：词性 / 释义 / 例句 / 辨析 / 近义词
索引层
以词条为单位切块（一词条 = 一或几个 Chunk） ·  Embedding 使用多语言模型（支持英中混合查询）
检索层
RAG 路径（语义探索）：用户问模糊问题 → 向量检索相关词条 → 返回候选列表
MCP 路径（精确读取）：用户点击具体词条 → MCP Resource 按 URI 直接读取完整词条
生成层
LLM 基于词典内容生成对比解释  ·  标注「来源：牛津英语词典 第X版」 ·  附例句和使用场景说明
洞察 RAG 和 MCP 分工明确——不知道要找哪个词条时用 RAG（语义探索）；知道要找「excuse」完整词条时用 MCP（精确读取）。同一份数据，两种访问范式并存互补。
技术选型参考
组件轻量方案（验证期）生产方案（规模化）
Vector DBChroma（本地）、FAISSQdrant、Weaviate、Pinecone
Embedding 模型text-embedding-3-smalltext-embedding-3-large、BGE-M3（中文强）
RAG 框架LangChain、LlamaIndex同左，加自定义 Reranking 层
Reranking不加（初期）Cohere Rerank、BGE-Reranker
评测手工抽样RAGAS（自动评测 RAG 质量）
RAG 不是只有一种做法。根据场景选择合适的 RAG 变体，是区分初级和进阶工程师的关键。
Naive RAG vs Advanced RAG
Naive RAG（基础版）
问题 → Embedding → 检索 Top-K → 塞入 Prompt → 生成

适合：快速验证可行性，文档量小，问题类型单一

缺点：用户 query 质量不稳定时检索效果差；向量相似≠真正相关
Advanced RAG（进阶版）
加入：Query 改写、混合检索、Reranking、上下文压缩、引用追踪

适合：生产环境，文档量大，问题类型复杂

代价：延迟增加（多次模型调用），系统复杂度提升
关键进阶技术
Query 改写 / 扩展
用户的问题表达可能不够准确或信息不足，在检索前先用 LLM 改写或扩展查询。

单轮改写："这个怎么退" → ["退款流程是什么", "退款条件有哪些", "退款需要多久"]
多轮改写（指代消解）：用户前一句说"退款"，这句问"怎么操作" → 改写为"退款操作流程"
效果：检索召回率从 65% 提升到 85%（典型数据）
Reranking（重排序）
向量检索返回 Top-20，再用交叉编码器（Cross-Encoder）对"问题+每个候选块"联合打分，取最相关的 Top-5 发给 LLM。

关键理解：双编码器（向量检索）是分别编码再比较，效率高但精度有限；交叉编码器是把问题和文档拼在一起理解，精度高但速度慢。两阶段结合：粗召回（速度优先）+ 精排序（精度优先）。

代价：速度变慢（多一次模型推理）；收益：准确率大幅提升。生产环境几乎必加。
Parent-Child Chunking（父子切块）
检索时用小块（保证精准匹配），但实际注入 LLM 的是小块所属的大块（保证上下文完整）。

具体例子：合同第5.2条"违约金为合同总额的10%"（小块，精确检索到）→ 注入给 LLM 的是第5条完整条款（大块，LLM 理解完整语境）。

解决"检索到了正确的句子，但 LLM 没有足够上下文来回答"的问题。
Metadata Filter + 混合检索
向量相似度 + 元数据精确过滤 + BM25 关键词匹配三者结合，用 RRF 合并结果。

执行顺序：元数据过滤（低成本，大幅缩小候选集）→ 混合检索（在候选集内精确排序）→ Reranking（最终精排）

是生产级 RAG 的标准检索架构，兼顾语义理解和精确匹配。
什么时候不应该用 RAG
① 知识量很小（<50页文档）→ 直接放进 system prompt，全局理解反而更好，但每次消耗全部 token
② 需要改变 LLM 的推理方式或稳定输出格式 → 微调（或 system prompt + few-shot）
③ 所有问题都是精确查找 → 传统数据库/搜索引擎直接查更好
④ 实时性要求极高（秒级更新）→ RAG 的 Embedding 入库有延迟，新内容无法被立刻检索到
普世方法论
两阶段检索：粗排 + 精排
Reranking 背后的思想是信息检索领域的经典范式：先用低成本方法快速缩小候选集，再用高成本方法精确排序。电商搜索（召回层 + 排序层 + 重排层）、推荐系统（粗排 + 精排）、Google 搜索（倒排索引快速召回 + 神经网络重排）——都是同样的思路。成本和精度是矛盾的，两阶段设计让你在正确的地方花正确的成本。
21 个高频问题深度解答。这些是理解 RAG 过程中最容易卡住的地方。
🧱 核心原理 · Q1–Q4
Q1Garbage In, Garbage Out 分别是什么意思？
直译"垃圾进，垃圾出"。这是计算机科学的基础原则，意思是：无论算法多好，输入数据质量差，输出结果必然差。在 RAG 里具体指：文档有错误内容 → 检索到错误内容 → LLM 基于错误内容生成错误回答。就像厨师再厉害，食材是烂的也做不出好菜。这个原则的深层含义：优化算法的投入回报，永远低于提升数据质量的投入回报。
Q2Reranking 是什么，为什么能解决"语义相关不代表回答问题"？
向量检索的局限："取消订单原因"和"取消订单步骤"在向量空间里距离很近（都和"取消订单"相关），但一个回答"为什么"，一个回答"怎么做"——本质不同。

Reranking 的原理：交叉编码器把"问题 + 文档"拼在一起输入模型，联合理解"这个文档是否真的回答了这个问题"。类比：向量检索是"看封面猜内容"，Reranking 是"翻开书逐页阅读判断相关性"。精度高但速度慢，所以只用在候选集缩小后的精排阶段。
Q3图书馆馆员的类比是否牵强？
这个类比的核心是强调分工，不是强调"问人"这件事。馆员的角色：不直接答题，而是"知道去哪里找答案"——这和 RAG 里"检索层找到相关块，再交给生成层"的分工一致。

类比的牵强之处：现实馆员会理解你的隐含意图（你说"找本帮助失眠的书"，他会想到《睡眠革命》或心理疏导类书籍）；RAG 的向量检索只理解表面语义相似，不理解隐含逻辑。所以补充：Query 改写就是在弥补这个差距——让 LLM 扮演"理解你真实意图的馆员"，再去向量库检索。
Q4同构是什么意思？
来自数学的概念，指两个不同系统之间存在相同的结构关系。例：开卷考试和 RAG 表面完全不同，但"从外部资料检索→基于资料回答"这个结构是同构的。

类比迁移的价值：当你找到同构结构，就可以直接迁移已有认知，不需要重新建立理解框架。学过开卷考试的人立刻就能理解 RAG 的核心逻辑。这是高效学习和解释复杂概念的核心技巧。
✂️ 分块 & 向量 · Q5–Q12
Q5RAG 协调了哪三层？
你的理解正确。RAG 协调了：原始文档（数据源，PDF/网页/笔记）→ 向量数据库（索引层，把文档变成可快速语义检索的形式）→ LLM（生成层，基于检索结果理解并输出答案）。向量库是原始文档的「检索索引」而不是替代——检索时从向量库找到相关 Chunk 的位置，再去原始文档里拿内容给 LLM。三层各司其职，可以独立升级。
Q6query 和 document 分别编码，这里的 query 和 document 是什么？
Query（查询） = 用户提的问题，是「需求方」；Document（文档块）= 知识库里的 Chunk，是「供给方」。

双编码器分别把两者编码成向量再计算相似度，速度快（文档向量可以预先计算存好）。交叉编码器（Reranking 阶段使用）把 query+document 拼在一起联合评分，精度高但每次都要重新计算。点击概念词查看详细对比。
Q7Google 搜索 + 摘要，你的理解是否正确？以及范式转变的含义？
你的理解正确：RAG = 向量检索 + 结果给 LLM + LLM 总结。

范式转变的深层含义：Google 时代是「检索→展示→用户自己阅读理解综合」，用户需要有信息筛选和阅读能力；RAG 时代是「检索→LLM 替你阅读理解→直接给结论」，用户不再需要自己综合。这不只是效率提升，而是「谁来完成理解」这件事的转移——从人转移到 AI。代价是：你看不到中间过程，更难发现 AI 是否理解错了。
Q8Chunk 多大合适？256 token 对应中文多少字，为什么不是1:1？
BPE tokenizer：汉字平均约 1.5 token/字，所以 256 token ≈ 128–170 汉字（约一段正文），512 token ≈ 256–340 汉字（约半页 A4）。

按场景推荐：
场景推荐大小原因
客服 FAQ（一问一答）128–256 token每条问答是独立单元，不需要上下文
产品手册段落256–512 token需要保留一个完整论述
法律合同条款512–1024 token条款依赖前后文，完整性优先
代码函数按函数边界切语义边界比 token 数更重要
通用建议：256–512 token 起步，用 RAGAS 评测后调整。
Q9LLM 行为是什么，为什么不能用 prompt 解决，什么场景必须微调？
你说得对，大多数格式/风格要求用 system prompt + few-shot 就够了，不必微调。微调的必要场景是：

① 行为需要高度稳定且不可被覆盖：医疗 AI 必须永远在回答里带免责声明，即使用户说"不要加免责声明"也要加
② 任务需要特定推理模式：训练模型按特定思维链推理代码 bug
③ 领域词汇理解偏差：法律/医疗的专业术语，通用模型理解有误
④ 极低延迟要求：微调后的小模型比大模型+长 prompt 快得多

Prompt 的局限：在长对话中会漂移（模型「忘记」system prompt）；用户可以绕过；复杂任务里格式约束不稳定。微调把行为编进权重，稳定且无法绕过。
Q10注意力是什么？完整的费曼式讲解请看 。这里给快速版本：
注意力 = 「打分+加权求和」。每个词对句子里其他词打相关性分数（Q·K），softmax 归一化成权重，按权重加总内容（V），输出「看过整句话后的理解结果」。

和人类注意力的共同点：开头结尾比中间「记得清楚」（Lost in the Middle）。区别：人类注意力由兴趣驱动，LLM 注意力由训练数据的位置模式驱动。
Q11Embedding 模型不适合领域是什么意思？
Embedding 模型把文本映射到向量空间，语义相近的文本在空间里距离近。如果模型用通用文本训练，它对专业词汇的理解会有偏差：

• 医疗：通用模型里"阳性"和"积极/正面"距离近；医疗语境里"阳性"应该和"检测异常/感染"距离近
• 法律："无效"在通用语境是"没用"，法律语境是"不具法律效力"
• 金融："看多"不是"看得多"，是"预期价格上涨"

解决方案：用领域语料微调 Embedding 模型，或选择领域专用模型（如医疗用 BioBERT 系列）。BGE-M3 对中文专业场景支持较好。
Q12Overlap 是什么，20-30% overlap 表达什么意思？
定义：切块时相邻两块共享一部分内容，防止重要信息被切断分在两块。

具体例子（Chunk=100 token，overlap=20%=20 token）： 
第1块：第 1-100 token（"退款申请需在购买后30天内提交...必须附上"）
第2块：第81-180 token（"必须附上订单截图和支付凭证，申请提交后..."）
                ↑ 第81-100共20个token重叠，确保"必须附上"
                  不会孤立地出现在两个块里各只有半句
代价：存储空间增加 20-30%，检索时可能出现重复内容（需去重）。收益：大幅降低"语义被切断"导致的检索质量下降。
🔎 检索策略进阶 · Q13–Q18
Q13为什么混合检索比单一检索更有效？人类是如何检索的？
互补盲区： • 稀疏检索（BM25）盲区：不理解同义词和语义关联——"汽车"和"车辆"会被认为完全不同的词 • 稠密检索（向量）盲区：精确词匹配弱——"iPhone 16 Pro Max 256GB 钛金黑"可能被模糊匹配到其他型号

人类检索的过程：你在搜索框输入关键词（稀疏），系统返回结果后你用语义理解判断哪条真的相关（稠密）。大脑自动做了混合检索。

混合检索的机制：两种方式分别返回排序列表，用 RRF 合并（排名靠前且在两个列表里都靠前的得分最高）。结果比任何单一方式都好，代价是计算量翻倍。
Q14多文档综合问题回答差，具体讲解一下？
场景：用户问"对比我们2023年和2024年的定价策略有什么变化"。

问题：这个问题需要同时检索 2023 年文档和 2024 年文档的相关段落。如果 Top-K=3，系统可能只返回 3 条结果，而这 3 条可能全来自 2024 年文档（因为更新，向量更接近当前 query），2023 年的数据根本没有进入 context。LLM 没有足够信息做对比，只能编造或说"没有2023年数据"。

解决方案： ① 增大 Top-K（如 K=10）让两年数据都能进入候选集 ② 子问题分解：把大问题拆成["2023年定价策略是什么", "2024年定价策略是什么"]，分别检索，合并结果 ③ 元数据过滤：检索时强制包含 year=2023 和 year=2024 各若干条
Q15Query 扩展是什么？召回率是什么？
用户的原始 query 往往太短、信息不足，导致检索召回不全。Query 扩展就是用 LLM 把原始 query 扩展成多个相关 query，每个 query 分别检索，合并去重后统一送入 Reranking。

具体例子： 
原始 query: "这个怎么退"
扩展后:
  → "退款申请流程"
  → "退款需要什么条件"  
  → "退款到账需要几天"
  → "退款申请在哪里提交"
四个 query 分别检索 → 合并去重 → Reranking → Top-5 → LLM
效果：把召回率从 65% 提升到 85%（典型场景数据）。代价：增加 LLM 调用次数和延迟。
Q16Metadata Filter + 混合检索的机制是什么？有成型技术方案么？深层方法论是什么？
机制：在向量检索之上叠加结构化字段过滤。先用元数据（行业/年份/文档类型）缩小候选集，再在候选集内做混合检索。

执行顺序： 
全量文档（100,000条）
  → 元数据过滤：industry=金融 AND year≥2023  → 候选集（500条）
  → 向量检索 + BM25 在500条内分别排序
  → RRF 合并排序结果
  → Reranking 精排
  → Top-5 → LLM
成型技术方案：Qdrant、Weaviate、Pinecone 都原生支持"向量检索 + 元数据过滤"组合查询。Qdrant 的 Filter API 尤其成熟。

深层普世方法论：先过滤再排序。用低成本操作（结构化字段匹配，O(1) 查询）大幅减少高成本操作（向量距离计算，O(n)）的搜索空间。这个思路在数据库索引、推荐系统、搜索引擎里普遍存在。
Q17Query 改写，LLM 是基于单个句子改写，还是基于上下文改写？
两种模式都有，取决于场景：

单轮对话：只有当前 query，LLM 基于这一句改写，扩展意图（如 Q13 的例子）。

多轮对话（更重要的场景）： 
用户第1句: "我想了解退款政策"
用户第2句: "那如果是预售商品呢"  ← 指代不明
改写后:   "预售商品的退款政策是什么" ← 加上上下文
这叫指代消解（Coreference Resolution）——把对话历史里的"那""它""这个"替换成明确的指代对象。多轮对话场景下，不做指代消解的 RAG 系统在 3 轮以后检索质量会显著下降。

实现：每次检索前，把最近 N 轮对话历史 + 当前 query 一起发给 LLM，让它改写成独立完整的查询。
Q18RRF 是什么，怎么用，为什么这么用？
定义：Reciprocal Rank Fusion，互惠排名融合。合并多个排序列表的算法。

公式：score(doc) = Σ 1/(k + rank_i)，k=60（经验值），rank_i 是文档在第 i 个列表里的排名

具体例子： 
文档A: 向量检索排名第1, BM25排名第3
  score = 1/(60+1) + 1/(60+3) = 0.0164 + 0.0159 = 0.0323

文档B: 向量检索排名第2, BM25排名第1
  score = 1/(60+2) + 1/(60+1) = 0.0161 + 0.0164 = 0.0325 ← 更高
为什么不直接加分数？向量相似度是 0.85，BM25 分数是 47.3——两个完全不同的尺度，直接相加没有意义。排名是可比的（第1名就是第1名），用排名融合绕开了尺度问题。
🏗 系统设计 · Q19–Q21
Q19知识量小（<50页）直接放 system prompt，准确率如何？有什么问题？
优势：LLM 能整体理解文档的完整语境，没有检索误差，对需要跨文档推理的问题效果更好。

问题和限制： • 成本：每次请求都消耗全部文档的 token，50页约 25,000 token，每次请求费用 ≈ $0.05-0.1（GPT-4o），高频查询成本很高 • Lost in the Middle：50页文档塞进 context，中间部分注意力弱，实际准确率不如想象中高 • Context Window 上限：超过模型限制（如 GPT-4o 的 128k token）就用不了 • 更新麻烦：文档更新需要修改 system prompt，没有 RAG 的热更新便利

实际建议：<10页用 system prompt；10-50页看查询频率，高频用 RAG，低频可以放 system prompt；>50页必须 RAG。
Q20256-512 token 对应中文是多少个字？
OpenAI tokenizer 对中文的处理：1个汉字 ≈ 1-2个 token（平均约 1.5 token）。

• 256 token ≈ 128-170 个汉字（约一个段落，100-150字的正文）
• 512 token ≈ 256-340 个汉字（约半页 A4 纸的正文）
• 1024 token ≈ 512-680 个汉字（约一整页 A4 纸）

注意：中文标点、数字、英文字母的 token 计算方式不同，以上是近似值。实际开发时建议用 tiktoken 库精确计算。
Q21稀疏检索就是关键词切分，稠密检索就是向量，理解对吗？
理解基本正确，补充更精确的定义：

稀疏检索：文档表示为词频向量——每个维度对应一个词，值是该词在文档中的权重（TF-IDF/BM25）。维度数量 = 词汇表大小（通常数万维），但每个文档只有少量非零维度，所以叫"稀疏"。BM25 是稀疏检索的主流算法，改进了简单词频计数，考虑了词的稀有性和文档长度。

稠密检索：文档通过神经网络（Embedding 模型）映射到固定维度的向量（通常 768-1536 维），所有维度都有值，所以叫"稠密"。检索时计算 query 向量和文档向量的余弦相似度或点积。

你的理解中"模糊匹配"用来描述稠密检索是准确的——因为向量距离可以捕捉语义相似性，即使没有完全匹配的词也能找到相关内容。
面试题库已整理为专题文档，内容更完整。
位置：rag/code/mock-interview/
01_基础概念题.md
RAG 定义、流程、RAG vs 微调等基础问答
04_rag评估方案汇总.md
MRR vs RAGAS、评估工具选型
05_混合检索RRF平局陷阱.md
RRF 平局的三种解法深度分析
06_embedding选型参考.md
C-MTEB 榜单解读、合成 Query 陷阱
07_agentic_rag_模型选型.md
Self-RAG meta-cognition 要求、小模型特性
必读Transformer 注意力机制是理解所有现代 LLM 的底层基础。用费曼方法从直觉到数学，5个层次递进讲解。
Level 1 · 直觉
派对上你是怎么「聚焦」的？
想象你在一个100人的嘈杂派对上。所有人都在说话，但你能清晰地听到老朋友的声音。你的大脑在做什么？

它对每个声音打了一个「重要度分数」——老朋友：90分，陌生人：5分，背景音乐：2分。然后按分数加权混合，你「听到」的就是加权后的结果。

Transformer 的注意力机制做的是完全一样的事情——只不过不是对声音打分，而是对句子里的每个词对其他词打相关性分数。
Level 2 · 具体例子
一个句子里，词是如何「看见」彼此的？
句子：「银行边的河岸边，我钓到了一条鱼」

当模型处理「河岸」这个词时，它需要判断：这里的「银行」是金融机构还是河岸边？

注意力机制让「河岸」对「钓鱼」「鱼」打了高分，对「金融」「账户」打了低分。
通过这些分数，模型正确理解了这是自然河岸，不是金融银行。

关键洞察：每个词的「含义」不是固定的，而是由它和整句话里其他词的关系动态决定的。这就是为什么 LLM 能理解多义词和语境——它在「看」整个句子，不是单独处理每个词。
Level 3 · 机制拆解
Q / K / V 三个角色是什么？
每个词会被变换成三个向量，扮演三个不同角色：
Q · Query 「我想知道什么？」

当前词作为「提问者」：我是「河岸」，我需要知道我的上下文是什么性质的？
K · Key 「我能提供什么信息？」

其他词作为「被查询的索引标签」：我是「钓鱼」，我的标签是：户外/水边/休闲活动
V · Value 「如果你选中我，我给你的内容」

其他词作为「实际信息载体」：我是「钓鱼」，如果你关注我，我给你的语义信息是：[钓鱼的完整语义向量]
类比：Q 是搜索框里的关键词，K 是文档的标签/标题，V 是文档的正文内容。用关键词（Q）和标签（K）计算相关性，然后按相关性加权获取正文（V）。
Level 4 · 公式每一项的物理意义
Attention(Q, K, V) = softmax(QKᵀ / √d) · V
QKᵀ（点积矩阵）
Q 是「我想找什么」，K 是「我能提供什么标签」。Q 和 K 做点积，得到每对词之间的相关性得分。n 个词就产生 n×n 的得分矩阵——每个词对每个词都打了一个分。

/ √d（缩放因子）
d 是向量维度（现实中是 64 或 768）。维度越高，点积绝对值越大，softmax 会把分布压成「一个 1 其他全 0」，梯度消失无法学习。除以 √d 把数值压回合理范围——纯粹的数学稳定技巧，没有语义含义。

softmax(…)
把一组得分转成概率分布，所有权重加和 = 1。得分高的词权重大，得分低的词权重接近 0。这一步决定了「我应该有多关注每个词」。

· V（加权求和）
V 是「我的实际内容信息」。按 softmax 给出的权重，把所有词的 V 加权求和——高权重词的信息贡献多，低权重词贡献少。输出是一个新向量，融合了整句话的语境信息。
Level 4b · 用真实数字走完整5步
句子「银行 边的 河」——每步都有数字，看清楚到底发生了什么
假设 d=2（向量2维）。目标：计算「河」这个词看过整句话之后的新向量表示。

① 每个词有三个2维向量（Q / K / V） 
词    Q（我在问）    K（我的标签）   V（我的内容）
银行  [1.0, 0.2]    [0.8, 0.1]     [0.5, 0.9]
边的  [0.1, 0.8]    [0.2, 0.7]     [0.1, 0.2]
河    [0.9, 0.3]    [0.7, 0.2]     [0.6, 0.8]
      ↑ 用河的Q，去和所有词的K比较
② 点积 QKᵀ — 「河」的 Q 分别和每个词的 K 点乘 
河.Q · 银行.K = 0.9×0.8 + 0.3×0.1 = 0.72+0.03 = 0.75 ← 最高
河.Q · 边的.K = 0.9×0.2 + 0.3×0.7 = 0.18+0.21 = 0.39
河.Q · 河.K   = 0.9×0.7 + 0.3×0.2 = 0.63+0.06 = 0.69
③ / √d = / √2 ≈ /1.41 — 压缩数值范围 
0.75/1.41 = 0.53 | 0.39/1.41 = 0.28 | 0.69/1.41 = 0.49
④ softmax — 转成概率权重（三个数加和=1） 
e^0.53=1.70  e^0.28=1.32  e^0.49=1.63   总和=4.65
权重: 1.70/4.65=0.37  1.32/4.65=0.28  1.63/4.65=0.35
       ↑银行37%        ↑边的28%       ↑河自己35%
⑤ · V — 按权重加总三个词的内容向量 
输出 = 0.37×[0.5,0.9] + 0.28×[0.1,0.2] + 0.35×[0.6,0.8]
     = [0.185,0.333] + [0.028,0.056] + [0.210,0.280]
     = [0.42, 0.67]  ← 这就是「河」新的向量表示
结论：「河」的新向量 [0.42, 0.67] 融合了「银行」(37%) 和「河」本身(35%) 的信息，而不只是「河」原本的孤立含义。模型因此知道这里是自然河流，不是金融机构旁边。

注：真实场景中 d=64 或 768，每词有数百维向量，但计算步骤完全一样。
Level 5 · 和 RAG 的联系
为什么会 Lost in the Middle？
位置编码的影响：Transformer 通过位置编码让模型知道词的顺序。训练数据里，重要信息通常在开头（标题/摘要）和结尾（结论/总结）——人类写作的习惯就是如此。

结果：模型在训练中学到了「开头和结尾的内容更重要」这个模式，导致注意力分数系统性地偏向头尾，中间部分分数偏低。

这不是 bug，是训练数据分布导致的模式。

对 RAG 的实践含义：把最重要的检索结果放在 prompt 的开头或结尾，不要夹在中间。如果 Top-5 结果都很重要，考虑分多次调用或增加 context window。
为什么这个概念值得单独必读
注意力机制是现代 AI 的「操作系统」
RAG、ChatGPT、Claude、Gemini——所有这些都建立在 Transformer 注意力机制之上。理解了它，你就理解了：为什么 LLM 能理解语境（注意力让词看见词）、为什么有 context window 上限（QKᵀ 是 n² 复杂度）、为什么会 Lost in the Middle（位置偏差）、为什么 prompt 里例子的顺序重要（注意力分数受位置影响）。这一个概念，解释了几十个常见的 LLM 行为现象。
5 道选择题验证你对 RAG 的理解。每道题点击选项即时反馈，附解析。
Q1用户问「如何申请退款」，RAG 系统检索到了「退款申请的常见原因（买错了/不满意）」排在 Top-1。最可能的根本原因是？
AChunk 切得太小，丢失了上下文
B向量检索只衡量语义相似，没有衡量「是否回答了问题」
CEmbedding 模型不支持中文
D数据层的文档质量太差
✓ B 正确。「退款原因」和「退款申请步骤」在语义空间里距离很近（都和退款相关），但一个回答 Why，一个回答 How。向量相似度无法区分这个差异。解决方案是加 Reranking：用交叉编码器联合判断「这段内容是否回答了这个具体问题」。
Q2以下哪种场景最不适合用 RAG？
A公司内部知识库问答（文档每月更新）
B法律合同条款检索与解析
C让 AI 始终以 JSON 格式输出并保持客服语气
D产品手册问答（手册内容频繁更新）
✓ C 正确。「始终以 JSON 格式输出」是行为稳定性问题，不是知识问题。RAG 注入「请输出 JSON」的文档效果极不稳定。这种需求应该用 system prompt + few-shot 解决，复杂场景才需要微调。A/B/D 都是知识注入场景，RAG 正好适用。
Q3RRF（互惠排名融合）在混合检索中解决的核心问题是？
A减少向量检索的计算成本
B合并两种分数尺度不可比的排序列表
C提高 Embedding 模型的召回率
D过滤掉不相关的文档
✓ B 正确。BM25 分数（如 47.3）和向量余弦相似度（如 0.85）尺度完全不同，不能直接相加。RRF 用排名而不是原始分数：score = Σ 1/(60+rank)，把两个不可比的分数体系转化为可以合并的排名体系。
Q4Transformer 注意力机制中，除以 √d 的目的是？
A让模型能处理更长的句子
B提高注意力分数的精确度
C防止点积值过大导致 softmax 梯度消失
D减少模型参数量
✓ C 正确。向量维度 d 越大，Q·K 的点积值越大（方差随 d 线性增长）。如果值太大，softmax 后的概率分布会极度尖锐（一个词权重接近1，其他接近0），导致梯度消失，模型无法学习。除以 √d 把方差控制在稳定范围，保证 softmax 输出合理的概率分布。
Q5RAG 建设期（离线）和查询期（在线）的核心分工是？
A建设期负责生成答案，查询期负责验证答案
B建设期把文档变成可检索的向量索引，查询期根据问题检索并生成回答
C建设期训练 LLM，查询期部署 LLM
D两个阶段功能相同，只是时间不同
✓ B 正确。建设期（离线）：文档清洗 → Chunking → Embedding → 存入 Vector DB，是一次性或定期的「知识准备」工作。查询期（在线）：每次用户提问时触发，问题向量化 → 检索 → 注入 Prompt → LLM 生成。两个阶段完全分离，优化方向不同。
0/5
关联学习路径
← 返回
AI 知识中心
全局词汇库 · 学习地图
前置知识
Embedding 深度
向量空间 · 余弦相似度
即将发布
深度延伸
Transformer & Attention
注意力机制 · 完整架构
即将发布（预览在本文 🔬 Tab）