Appearance
RAG 基础与评估体系
方向定位：聚焦 RAG 的根本动机、概念边界与质量评估方法论——回答"为什么要用 RAG"和"RAG 做得好不好怎么衡量"。包括 LLM 知识冻结的三类问题（知识过期/私有知识缺失/幻觉）、RAG 与微调的本质差异、向量库三元结构（向量+原文+metadata）、检索质量三大指标（Precision/Recall/MRR）、测试集构建与分维度评估方法。不深入文档处理细节（→ RAG 文档处理与 Chunk 工程）、不研究检索优化与失败排查（→ RAG 检索质量与排查）、不涉及服务化与企业级落地（→ RAG 服务化与企业级工程）。 当前版本：v0.2 首次构建：2026-05-15 最近更新：2026-05-19 文件名日期同步：2026-05-15 来源数：2 篇（20, 23 部分）
方向定位
RAG 基础与评估体系研究的核心问题是："为什么 LLM 必须配 RAG，以及 RAG 做出来后怎么知道它够不够好？"。它的边界包括：
- 包含：LLM 知识冻结的架构成因、RAG 解决的三类问题、RAG vs 微调的取舍、向量库每条记录的三元结构、检索质量三大指标（Precision/Recall/MRR）的定义、QA 测试集构建方法、分维度评估拆解
- 不包含：Chunk 切分策略与文档解析（→《RAG 文档处理与 Chunk 工程》）、检索失败的根因诊断与四层排查、Query 改写/Reranking/混合检索等优化手段（→《RAG 检索质量与排查》）、QPS/限流/缓存/多租户（→《RAG 服务化与企业级工程》）
- 与相邻方向的区别：本方向只回答"为什么"和"怎么量化"——指标"算什么"在这里讲；指标"算出来不好怎么救"留给检索方向
理解 RAG 的根本动机和评估方法，是 RAG 工程一切优化的起点——不知道为什么要 RAG，会把它当成"让模型更聪明的魔法"；不知道怎么评估，所有优化都是凭感觉。
知识图谱
- 知识冻结：所有 RAG 问题的根源
- 训练成本不可频繁重训
- 微调无法溯源
- 三类衍生问题：过期 / 私有缺失 / 幻觉
- RAG 三类问题对照
- 知识过期：曾经知道，信息变了
- 私有知识缺失：从来不在训练集
- 幻觉：知识缺失时的"应急策略"，是副产品不是 bug
- RAG 本质：开卷考试
- 知识管理与模型能力解耦
- 知识更新不需要碰模型
- 答案可溯源（区别于微调）
- 向量库三元结构
- 向量（embedding）：检索用，浮点数
- 原文（text）：LLM 阅读用
- metadata：过滤+溯源
- 检索质量三大指标
- Precision：查准率
- Recall：查全率
- MRR：第一条命中位置
- 评估方法论
- 200~500 组 QA 标注
- 分维度拆解（文本/表格/否定/多跳）
- 2 人 1 周前置投入，后续每次 10 分钟
核心概念
概念 1：知识冻结——LLM 所有知识局限的根源
来自快手面试解析。LLM 预训练时把海量文本知识"编码"进参数权重，像一本印刷完成的百科全书——内容丰富，但无法再更新。这不是 bug，是架构特性。
为什么不能靠重训或微调解决：
| 路径 | 致命缺陷 |
|---|---|
| 重训模型 | 千万美元级成本，不可能频繁做 |
| 微调注入新知识 | ① 无法溯源（出错找不到原因） ② 企业数据天天更新，无法匹配频率 |
| RAG 增量入库 | 实时生效，不动模型，可溯源 |
RAG 的增量入库是微调无法匹敌的优势——知识库更新实时生效，不需要任何模型变更。
概念 2：RAG 解决的三类问题
知识冻结这一根源衍生出三类具体问题，RAG 是同一套解法：
| 问题 | 本质 | 典型场景 | RAG 解法 |
|---|---|---|---|
| 知识过期 | 训练数据有截止日期 | 问最新财报、新产品功能 | 新内容随时入库，立刻生效 |
| 私有知识缺失 | 企业内部文档从未进过公开训练集 | 问公司退款政策、内部流程 | 私有文档入库后 LLM 即可"看到" |
| 幻觉 | 知识不足时模型硬编答案 | 医疗、法律、金融等容错率低场景 | 提供真实参考依据，答案可溯源 |
关键区分：知识过期 vs 私有知识——
- 知识过期：曾经知道，但信息变了（"旧了"）
- 私有知识缺失：从来没机会学到（"从没有"）
关键认知：幻觉是副产品——LLM 的核心机制是"预测下一个词"，没有内置"我不确定就停下来"的开关。知识过期会导致幻觉，知识缺失也会导致幻觉，根源是同一件事。RAG 解决的不是幻觉本身，而是幻觉的根源。
概念 3：RAG 本质——开卷考试
RAG 不动模型参数，只在外部维护知识库。用户提问时先检索最相关的内容片段，和问题一起塞进 prompt，让 LLM 基于"参考资料"作答而非凭记忆发挥。
用户提问
→ 问题向量化
→ 向量数据库相似度检索
→ 取出最相关 chunk 的原文
→ 与用户问题拼入 prompt
→ LLM 基于参考资料生成答案
→ 答案附带来源，可溯源核实这个设计让知识管理与模型能力彻底解耦——这是 RAG 成为企业 AI 落地首选的根本原因。
概念 4：向量库每条记录的三元结构
来自京东面试解析。很多初学者误以为"向量就是内容本身"——这是根本性的认知错误。本方向给出入门定义，链路下游对三元结构的具体运用（chunk 元数据字段设计 → 《RAG 文档处理与 Chunk 工程》；向量化排查与表述差异 → 《RAG 检索质量与排查》）。
| 组件 | 作用 | 类比 |
|---|---|---|
| 向量（embedding） | 语义空间位置，用于相似度检索 | 索引卡 |
| 原文（text） | LLM 实际阅读的内容，命中后塞进 prompt | 书页 |
| metadata | 来源文件名、页码、章节等，用于过滤和溯源 | 书签 |
向量负责"找到"，原文负责"阅读"，metadata 负责"过滤与溯源"，三者缺一不可。整篇文档不能直接存入向量库的两个原因：① 向量模型有输入长度限制；② 即便能塞下，整篇压缩成一个向量会让细节信息"被平均掉"，检索到的是笼统文档而非精确段落。
方法论与框架
框架 1：检索质量三大指标（指标定义）
来自阿里飞猪一面真题。任何 RAG 系统上线前必须跑这三个指标——本框架只讲定义与算法，"算出来不达标怎么优化"属于检索方向（→《RAG 检索质量与排查》四层优化体系）。
| 指标 | 定义 | 计算示例 |
|---|---|---|
| 精确率 Precision | 检索结果里有多少是真正相关的 | 返回 10 个，7 个相关 = 70% |
| 召回率 Recall | 所有相关文档里有多少被检索出来 | 库里 15 个相关，检出 7 个 = 46.7% |
| MRR（Mean Reciprocal Rank） | 第一个正确结果的排名，越靠前分越高 | 衡量"第一条结果是不是我要的" |
评估测试流程：
- 标注 200~500 组 QA 对（问题 + 对应标准答案 chunk）
- 批量放入检索模块，拿到返回结果
- 和标注结果对比，计算三个指标
框架 2：分维度评估拆解
来自吴师兄 RAG 切分实战。整体召回率会"掩盖短板"——必须分维度拆解才能定位优化方向。
实战做法（保险条款 RAG 案例）：
- 构建 QA 测试集：200 份文档 × 10 题 = 2000 QA 对，标注 ground truth chunk
- 端到端检索：Top 5 是否包含标注的正确 chunk
- 分维度拆解：按文本 / 表格 / 否定查询 / 多跳推理分类看召回率，定位短板
- 前置投入：2 人 1 周标注，后续每次评估仅需 10 分钟
分维度的实战价值：V2 整体召回 0.74，分维度看才发现表格类只有 0.51，文本类 0.82——直接指导 V3 优先解决表格问题。表格短板的具体处理方案（表头复制、列表前导句合并）见《RAG 文档处理与 Chunk 工程》。
框架 3：面试标准回答骨架（RAG 解决什么问题）
- 先说根源：LLM 知识冻结在参数里，是架构固有特性，不是 bug
- 再说三个问题：知识过期（时效性）、私有知识缺失（覆盖盲区）、幻觉（缺乏依据时的应急策略）
- 最后说解法：把知识搬到外部，实时检索注入，知识管理与模型解耦
- 被追问幻觉：幻觉是副产品，RAG 治的是根源，不是单独治幻觉
案例库
案例 1：RAG 解决的三种"不知道"场景
- 知识过期：问最新财报、新产品功能——训练截止日期之后的事一无所知
- 私有知识缺失：问公司退款政策、内部流程——从未进入公开训练集
- 幻觉触发：医疗、法律、金融等容错率低的场景——模型硬编答案，说得自信但可能错
案例 2：评估驱动优化的真实路径（宏观参考）
某派聪明 RAG 项目（阿里飞猪面试题）以三大指标为基线，通过更换 Embedding 与引入 Reranker，将 Precision 从 68% 提升至 89%，Top-5 命中率 +23%，MRR 从 0.61 升到 0.78。
本案例在这里只作为"评估指标如何作为优化前后对照基准"的示例。具体优化手段（Embedding 选型、bge-reranker-v2-m3 重排、混合检索）属于检索方向，详细路径见《RAG 检索质量与排查》四层优化体系；性能与延迟权衡见《RAG 服务化与企业级工程》Rerank 章节。
关键洞察
- RAG 不是"让大模型更聪明"，而是"绕开 LLM 架构的固有缺陷"——把它定位为"魔法"会忽视其根本动机，定位为"知识管理与模型解耦的工程方案"才能正确判断使用边界
- 幻觉、过期、私有缺失三者同源——三个症状一套解法，不需要分别治理。"我们的 RAG 是不是也要单独做一个治幻觉模块"是错误的拆分
- 向量不是内容本身——这是入门最容易踩的认知坑。向量找到，原文阅读，metadata 溯源，三者缺一不可
- 没有数据就没有优化方向——RAG 上线前必须先跑 Precision/Recall/MRR，"感觉更好"在工程答辩和面试中毫无说服力
- 整体召回率会掩盖短板——分维度拆解（文本/表格/否定/多跳）才能精准定位优化优先级
相关链路
本方向回答"为什么 + 怎么量化"，落地时按下游链路递进：
- 下一步：怎么切对？ → 《RAG 文档处理与 Chunk 工程》——回答"分维度短板里表格类只有 0.51 怎么救"
- 再下一步：怎么找对？ → 《RAG 检索质量与排查》——回答"三大指标不达标时的根因定位与优化体系"
- 最后：怎么扛得住？ → 《RAG 服务化与企业级工程》——回答"评估通过后如何在生产环境扛流量、过审计"
待探索问题
- RAG vs 微调的混合架构：什么场景下应该 RAG 提供事实、微调注入"风格/术语/格式"？两者怎么互补不互抵？
- 答案溯源的产品化呈现：检索到的多个 chunk 怎么在 UI 上让用户清晰看到"这段来自哪份文档第几页"？
- 评估测试集的演进：QA 测试集本身是不是要随知识库更新？怎么发现"测试集过期"？
- 可溯源 vs 自由发挥的平衡：要求 LLM 严格基于参考资料会牺牲流畅度，怎么在医疗/金融等场景找到平衡点？
来源索引
| # | 来源 | 提炼日期 | 主要贡献章节 |
|---|---|---|---|
| 1 | 快手面试官：RAG 主要解决什么问题（IT杨秀才公众号） | 2026-04-13 | 知识冻结、三类问题、RAG 本质、与微调对比 |
| 2 | 派聪明 RAG 真实面试题（阿里飞猪一面） | 2026-04-13 | 三大指标、评估流程、向量库三元结构 |
| 3 | 吴师兄 RAG 切分实战分享（节选评估部分） | 2026-04-03 | 分维度评估、QA 测试集构建成本 |
演进记录
- v0.2（2026-05-19） — 与《RAG 检索质量与排查》理顺分工。框架 1 仅保留指标定义，删除具体优化数值；案例 2 收缩为"评估驱动优化"宏观参考，详细优化路径引用至检索方向。新增"相关链路"段，串起入门 → Chunk → 检索 → 服务化四篇递进。概念 4 加入对下游方向的引用提示。
- v0.1（2026-05-15） — 首次构建，由 /route-knowledge 路由分析触发。聚合 RAG/20、RAG/23（评估部分）、RAG/04（评估部分）三个来源，初始化方向定位、知识图谱、核心概念（知识冻结/三类问题/开卷考试/三元结构）、方法论（三大指标/分维度评估/面试骨架）、案例库与关键洞察。