AI 面试知识体系

009：RAG 原理与评测（检索增强生成 · 原理工程 / 评测体系）

RAG 原理与评测（RAG 原理工程与查询改写 · RAG 评测框架 / 召回评估 / 生成效果评估）

体系定位：RAG 原理与评测（RAG 原理工程与查询改写 · RAG 评测框架 / 召回评估 / 生成效果评估） 来源文件数：6（从 001_AI大模型与智能体.md 拆出：005：RAG原理工程与查询改写 章 + RAG 评测 5 章） 说明：内容原封不动拆出，仅调整图片相对路径

📑 目录

1 RAG原理工程与查询改写

体系定位：RAG 原理、工程实战与查询改写（检索/重排/向量库/改写/故障） 来源文件数：18（内容原封不动按来源保留）

📄 来源：012_面试必考：怎么让RAG老实说不知道.md

2 面试必考：怎么让RAG老实说不知道

2.1 视频信息

项目 内容
视频名称 面试必考：怎么让RAG老实说不知道
时长 3分18秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7660837015446298021
飞书妙记 https://www.feishu.cn/minutes/obcnit87nsb2w6286f47q225
关键词 RAG、拒答、证据充分性、检索阈值、引用约束、置信度、无答案测试集

2.2 全文摘要

本视频深入讲解了RAG系统中"知识库没有答案时如何让模型老实说不知道"这一面试高频问题。核心观点是：RAG要说不知道，必须在检索、重排、生成和评估四层都设计不足证据的出口，不能只靠prompt。 视频指出模型最容易把相关但不充分的证据包装成确定答案，只靠提示词很难稳定控制。详细讲解了四层架构：检索阈值（区分相关性和可回答性）、生成约束（强制引用证据）、评估与回放（构造无答案测试集）、人工升级机制。同时强调拒答策略要与业务风险绑定，闲聊宽松、法律医疗金融严格，风险越高证据门槛越高。最后指出拒答的反向价值是暴露知识库缺口，驱动知识补录和文档治理。

2.3 原文结构化整理

2.3.1 问题本质：证据充分性判断

表面问题：知识库没答案时，怎么让RAG说不知道？

深层考点：证据充分性判断。

模型行为倾向：拼凑干扰材料 → 生成"看似有用"的答案

2.3.2 四层拒答架构设计

层级 机制 关键要点
第一层：检索阈值 零召回拒答 + 低质量召回拒答 区分"相关性"和"可回答性"，不能把相似度高当成证据充分
第二层：生成约束 强制引用证据 每个关键结论必须引用到具体片段，且引用片段必须直接支持结论；只有背景信息就输出"当前资料没有明确说明"
第三层：评估与回放 无答案测试集 专门构造知识库没有答案的测试集，看系统是否拒答
第四层：人工升级 灰区问题处理 转人工、提示补充信息、触发知识库补录

业界实践参考：OpenAI FileSearch、LlamaIndex、LangChain的RAG实践都强调检索结果要经过上下文组装和评估，不能直接相信。

2.3.3 评估与可观测性

常见误区： - 只测有答案问题 → RAG看起来准确率极高 - 上线遇到资料缺失 → 系统开始胡编乱造

正确做法： - 拒答率不是越低越好 - 关键是：证据不足时拒得对，证据充分时答得出 - 上线后拒答要可观测，记录为什么拒（相似度低/无直接证据/权限过滤后为空）

拒答样本分类： | 类型 | 后续优化方向 | |------|-------------| | 真的无答案 | 知识库补录 | | 召回失败 | 优化检索策略 | | 权限不足 | 权限治理 | | 问题太模糊 | 引导用户澄清 |

2.3.4 面试回答模板与追问应对

标准回答模板： 1. 先设置召回质量阈值 2. 判断片段是否直接回答问题 3. 生成时强制引用证据，没有直接证据就说不知道 4. 灰区问题升级人工或提示补充信息 5. 用无答案样本评估拒答质量，而不是只看命中率

追问：如何避免拒答太多？ - 拒答不是终点，要给下一步（补充合同编号、选择产品版本、转人工、触发知识库补录） - 防止模型用模糊话术假装拒答（如"通常可以"这种没有证据的软肯定也要拦）

追问：拒答策略如何落地？ - 与业务风险绑定：闲聊类宽松，法律/合同/医疗/金融/权限相关严格 - 风险越高，证据门槛越高

金句：RAG的目标不是每问必答，而是有证据才答。敢拒答才说明系统知道自己的边界。

拒答的反向价值：暴露知识库缺口。经常因无证据而拒答的问题，应该进入知识补录、文档治理或产品FAQ更新流程，而不是只当模型失败。

2.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00.380

面试官突然问一句，知识库里没有答案时，怎么让 RAG 老老实实说不知道？很多人会说，在 prompt 里写不会就说不知道，这个答案只能挡住一部分问题。真实 RAG 里，模型最容易把相关但不充分的证据包装成确定答案。我是小哲，点赞收藏加关注，我们马上开始。想系统学习 Agent 开发的同学可以查看橱窗哦。这个问题表面在问拒答，实际在考证据充分性判断。知识库没有答案，不代表召回为空，它可能召回一堆相关政策、相似案例、旧版本文档。模型看到这些材料后，就会倾向于给用户一个看起来有帮助的答案。这个时候只靠提示词很难稳定控制。

Speaker 1 00:00:37.140

一句话答案， RAG 要说不知道，必须在检索、重排、生成和评估四层都设计不足证据的出口。面试时不要只答prompt，要补上置信阈值、反向检索、引用约束、答案类型分类和人工升级。第一层是检索阈值，零召回当然要拒答，但更常见的是低质量召回。比如用户问企业版能否跨境传输数据，结果只召回到企业版支持权限管理，这叫相关，不叫回答。系统要区分相关性和可回答性，不能把相似度高当成证据充分。第二层是生成约束，要求模型每个关键结论都能引用到具体片段，而且引用片段必须直接支持结论。如果只能找到背景信息，就输出当前资料没有明确说明。 openai, FileSearch, llamaIndex 和 langchain 的 RAG 实践都强调检索结果要经过上下文组装和评估，不能直接相信。

Speaker 1 00:01:28.460

第三层是评估和回放，你要专门构造知识库没有答案的测试集，看系统是否拒答。很多团队只测有答案问题， RAG 看起来准确率很高，一上线遇到资料缺失就开始编，拒答率不是越低越好。关键是证据不足时拒得对，证据充分时答得出。面试回答模板，我会先设置召回质量阈值，再判断片段是否直接回答问题，生成时强制引用证据，没有直接证据就说不知道。对灰区问题升级人工或提示补充信息，最后用无答案样本评估拒答质量，而不是只看命中率。所以这题最重要的一句话是， RAG 的目标不是每问必答，而是有证据才答。

Speaker 1 00:02:07.450

面试官如果追问如何避免拒答太多，你可以说拒答不是终点，要给下一步，比如让用户补充合同编号、选择产品版本、转人工或者触发知识库补录。同时要把拒答样本分类，区分真的无答案、召回失败、权限不足、问题太模糊，后续优化方向完全不同。还要防止模型用模糊话术假装拒答，比如通常可以，这种没有证据的软肯定也要拦。

Speaker 1 00:02:31.210

上线后拒答也要可观测，不能只记录答案文本，要记录为什么拒，是相似度低、无直接证据，还是权限过滤后为空。能稳定说不知道的系统，反而比什么都敢答的系统更接近生产可用。最后面试时再补一句，拒答策略要和业务风险绑定，闲聊类问题可以宽松，法律、合同、医疗、金融、权限相关问题必须严格，风险越高，证据门槛越高。这样回答，面试官会觉得你不是在做一个会聊天的RAG，而是在做可控的信息系统。拒答做的好，还有一个反向价值，它能暴露知识库缺口。哪些问题经常因为无证据而拒答，就该进入知识补录、文档治理或产品 FAQ 更新流程。而不是只当模型失败。所以不知道不是能力差，而是在高风险场景里保护系统可信度的一种能力。敢拒答才说明系统知道自己的边界。

2.5 关键截图

2.5.1 模型行为倾向：拼凑干扰材料

img

模型看到相关但不充分的召回材料时，会倾向于拼凑干扰材料，生成"看似有用"的答案。这是RAG系统最核心的风险点。

2.5.2 常见误区：只测有答案问题

img

很多团队只测有答案问题，RAG看起来准确率极高，但一上线遇到资料缺失就开始胡编乱造。必须构造无答案测试集验证拒答能力。

2.5.3 策略与业务风险绑定

img

拒答策略要与业务风险绑定：闲聊类问题可以宽松，法律/医疗/金融等高危场景必须严格。风险越高，证据门槛越高。

📄 来源：017_面试官：RAG怎么处理Word和PDF.md

3 面试官：RAG怎么处理Word和PDF

3.1 视频信息

项目 内容
视频名称 面试官：RAG怎么处理Word和PDF
时长 4分44秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7660837015446298021
飞书妙记 https://www.feishu.cn/minutes/obcniuj55111k1wi785w8b9b
关键词 RAG、文档解析、Word、PDF、OCR、版面解析、结构感知切片、多路召回、重排、置信度兜底

3.2 全文摘要

本视频深入讲解了RAG系统中如何处理Word和PDF文档这一面试高频问题。核心观点是：RAG处理Word和PDF的难点不在检索，而在最前面的解析环节；文档解析没做好，后面切的再聪明、模型再强，喂进去的都是垃圾，召回的也是垃圾。 视频详细对比了Word（自带结构，相对好抽，但嵌入对象易丢）和PDF（版式格式，无语义结构，双栏、表格、扫描件都是坑）的解析差异，介绍了现代工程解法（版面解析工具如Unstructured/LlamaParse/Docling，以及多模态大模型直接理解版面），强调结构感知切片（顺着标题层级和段落边界切，表格代码块整块保留）优于粗暴按字数切，检索时要多路召回（向量+关键词）加重排，最后组装上下文必须带上来源引用，并在解析环节做置信度兜底，在召回率和准确率之间找平衡。

3.3 原文结构化整理

3.3.1 问题本质：难点不在检索，在解析

面试官问题：用户上传一个Word或者扫描版PDF合同，你是怎么让大模型读懂它的？

常见错误回答：切片加向量检索（八成的人一张嘴就是这个）

真正考点：有没有真把文档落地过，工程细节

核心金句：文档解析没做好，后面切的再聪明，模型再强，喂进去的都是垃圾，召回的也是垃圾。

3.3.2 Word vs PDF：解析难度完全不同

文档类型 特点 优势 坑点
Word 带结构的格式 标题、段落、表格在文件里都有标记，相对好抽 嵌入的图片、公式、文本框、Excel对象抽不干净就丢信息
PDF 版式格式 — 只关心每个字画在纸的哪个坐标，不存在标题、段落语义结构；双栏排版会左右交叉读成乱码；表格（跨页、合并单元格、不规则）行列全乱；扫描件本质是图片，没OCR一个字都拿不到

3.3.3 完整处理流水线

一句话总答案：先解析提取文字、表格、图片（扫描件走OCR）→ 保留文档结构按语义和版面切片 → 向量化入库 → 查询时多路召回加重排 → 组装上下文并带上来源引用

核心原则：先把文档变成结构清晰的文本，再谈检索。

3.3.3.1 第一关：解析（最难）

现代工程解法： - 版面解析（Layout Parsing）：用模型识别哪块是标题、哪块是表格、阅读顺序是什么 - 工具：Unstructured、LlamaParse、Docling - 多模态大模型（VLM）：把页面当图片看，让视觉模型理解版面，效果明显更稳 - 复杂表格和扫描件越来越多人直接上多模态

3.3.3.2 第二关：保留结构再切片

反直觉点：切片不是切的越碎越好，也不是简单按500字一刀

粗暴按字数切的问题：把一句话、一张表、一个完整逻辑从中间砍断，召回回来的片段缺头少尾，模型自然答错

正确做法：结构感知切片 - 顺着标题层级和段落边界来切 - 标题要跟着它管的那段内容走 - 表格和代码块尽量整块保留，不要拆散 - 研究印证：结构感知切片在专业领域能把准确率提升4成以上

实践配置： | 切片方式 | 配置 | 优缺点 | |----------|------|--------| | 递归切片 | 400-800 Token/块，留20%重叠 | 防止上下文断裂，常用 | | 语义切片 | 按句子语义找边界 | 更精细，但要给每个句子做向量，成本高3-5倍，提升仅2-3个点，看场景取舍 |

3.3.3.3 第三关：入库和检索

3.3.4 工程细节与兜底策略

线上坑要兜底： - 扫描质量差，OCR会错字 - 表格抽取会偶发错乱 - 解析阶段要做置信度判断，识别不出来的别硬塞 - 该走人工或多模态兜底就兜底 - 宁可少召回，也别召回错的

召回率和准确率的平衡： - 召回太贪 → 塞进噪声，拉低准确率 - 召回太保守 → 漏关键信息 - 得靠评估指标反复调

面试精简回答模板： RAG处理Word和PDF是一条流水线，难点不在检索在解析。Word有结构相对好抽，但嵌入对象要处理干净。PDF是版式格式，没有语义结构，双栏、表格、扫描件都是坑。所以要用版面解析识别结构和阅读顺序，扫描件走OCR或多模态，解析后按结构和语义切片，保住标题表格的完整性，再向量化入库。检索时多路召回加重排，组装上下文时带上来源引用，并在解析环节做置信度兜底，在召回率和准确率之间找平衡。

面试官真正想筛的是：有没有跟脏数据正面硬刚过的人。会背流程的人很多，知道PDF双栏会读乱、扫描件要兜底、表格不能拦腰切的人，才是真干过的人。

3.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00.310

面试官突然问一句，你们这套 RAG 系统，用户上传一个 Word 或者一个扫描版 PDF 合同，你是怎么让大模型读懂它的？你会怎么答？很多人卡在这，因为他们只背过向量检索，没真正处理过脏文档。我是小哲，点赞收藏加关注，我们马上开始。想系统学习 Agent 开发的同学可以查看橱窗哦。

Speaker 1 00:00:18.990

这道题表面问 RAG 怎么处理文件，实际在考你有没有真把文档落地过。面试官想听的不是流程背诵，而是工程细节。八成的人一张嘴就是切片加向量检索，听起来很顺，但真正的难点根本不在检索，而在最前面那一步解析。文档解析没做好，后面切的再聪明，模型再强，喂进去的都是垃圾，召回的也是垃圾。这一关藏着这道题真正的分。

Speaker 1 00:00:41.870

先给一句话总答案， RAG 处理 Word 和 PDF 本质是一条流水线，先解析提取出文字、表格、图片，扫描件还要走 OCR 识别文字，然后尽量保留文档结构，按语义和版面来切片，而不是粗暴按字数砍，再做向量化入库，查询时多路召回加重排，最后组装上下文并带上来源引用。核心就一句，先把文档变成结构清晰的文本，再谈检索。最难的就是解析这一关，而且 Word 和 PDF 难度完全不一样。

Speaker 1 00:01:11.070

Word 本身是带结构的，标题、段落、表格在文件里都有标记，相对好抽。但它也有坑，里面嵌的图片、公式、文本框、 Excel 对象，这些抽不干净就丢信息。 PDF 才是真正的硬骨头。 PDF 是一种版式格式，它只关心每个字画在纸的哪个坐标上，根本不存在标题、段落这种语义结构。最典型的翻车是双栏排版，你直接抽文字，左栏右栏会一行一行交叉读出来，拼成一段谁也看不懂的乱码。还有表格，跨页的、合并单元格的、不规则的，普通抽取出来行列全乱，再加上扫描件。本质是图片，没 OCR 就一个字都拿不到。

Speaker 1 00:01:47.610

所以现在的工程做法是用版面解析，先用模型识别出哪块是标题，哪块是表格，阅读顺序是什么？这就是unstructured、llama、paas、 docling 这类工具在干的事，专门解决版式没结构的问题。复杂表格和扫描件，越来越多人直接上多模态大模型，把页面当图片看，让视觉模型理解版面，效果明显更稳。

Speaker 1 00:02:07.490

解析完，第二关是保留结构再切片。这里要讲清楚一个反直觉的点，切片不是切的越碎越好，也不是简单按 500 字一刀，粗暴按字数切，最大的问题是把一句话、一张表、一个完整逻辑从中间砍断。召回回来的片段缺头少尾，模型自然答错。正确做法是结构感知切片，顺着标题层级和段落边界来切，标题要跟着它管的那段内容走，表格和代码块尽量整块保留，不要拆散。研究里也印证了这点，结构感知的切片在专业领域能把准确率提升 4 成以上。实践中常见配置是递归切片， 400 ~ 800 个 Token 一块，留 20% 左右的重叠，这样上下文不至于断裂。语义切片更精细，按句子语义找边界，但要给每个句子都做向量，成本高 3 ~ 5 倍，换来的可能只是两三个点的提升，要不要上得看场景。

Speaker 1 00:02:55.780

第三关是入库和检索。切好的片段做embedding，就是把文字转成向量，好做相似度匹配，存进向量库。查询时别只靠向量单路，要走多路召回。向量检索负责找语义相近的，关键词检索负责找精确命中的术语和编号。两路结果合并，然后过一道重排模型，把最相关的几条顶上去。这一步对准确率影响很大。最后组装上下文喂给大模型，并且一定要带上来源，告诉用户答案出自哪个文件哪一页，这就是答案引用，也是 RAG 比直接问模型更可信的地方。线上还有坑要兜底，扫描质量差， OCR 会错字，表格抽取会偶发错乱，所以解析阶段要做置信度判断，识别不出来的别硬塞，该走人工或多模态兜底就兜底，宁可少召回，也别召回错的。这背后就是召回率和准确率的平衡。召回太贪会塞进噪声，拉低准确。召回太保守又会漏关键信息，得靠评估指标反复调。如果面试时间紧，可以这样回答。

Speaker 1 00:03:49.840

RAG 处理 Word 和 PDF 是一条流水线，难点不在检索，在解析。 Word 有结构，相对好抽，但嵌入对象要处理干净。 PDF 是版式格式，没有语义结构，双栏、表格、扫描件都是坑。所以要用版面解析识别结构和阅读顺序，扫描件走 OCR 或多模态，解析后按结构和语义切片，保住标题表格的完整性，再向量化入库。检索时多路召回加重排，组装上下文时带上来源引用，并在解析环节做置信度兜底，在召回率和准确率之间找平衡。

Speaker 1 00:04:20.130

这套讲完，工程深度就出来了。说到底，这道题真正想筛的是你有没有跟脏数据正面硬刚过的人。会背流程的人很多，知道 PDF 双栏会读乱，扫描件要兜底，表格不能拦腰切的人，才是真干过的人。把解析这一关讲透，你就赢了一大半。今天就聊到这。如果对你准备面试有点用，顺手关注一下小哲，后面我们继续拆大模型工程里那些一问就露馅的真问题。

3.5 关键截图

3.5.1 Word解析特点对比

img

Word自带结构（标题、段落、表格）相对好抽，但隐藏的坑（图片、公式、文本框、Excel对象）容易丢信息。

3.5.2 现代工程解法：版面解析与多模态

img

现代工程解法：版面解析（Unstructured/LlamaParse/Docling）识别标题、表格、阅读顺序；多模态大模型（VLM）把页面当图片看，视觉模型理解版面。

3.5.3 递归切片与语义切片对比

img

递归切片（400-800 Token/块，保留20%重叠，防止上下文断裂）vs 语义切片（按句子语义找边界，成本高3-5倍，提升仅2-3%，看场景取舍）。

3.5.4 上下文组装与来源引用

img

上下文组装时将片段A（来源doc1.pdf）和片段B（来源doc2.word）喂给大模型生成答案，并标注引用来源，这是RAG比直接问模型更可信的关键。

📄 来源：023_向量检索算出排名，为啥还要额外加Re-rank模块.md

4 Rerank（重排序/精排）详解与工程最佳实践（2026-09-11 豆包会话）

体系定位：RAG 检索精排核心组件——Rerank 原理、Bi-Encoder vs Cross-Encoder、工业链路、模型选型、工程最佳实践 来源：豆包分享会话 https://www.doubao.com/thread/x3liRn2CCcAgJxsNz （2026-09-11 整理入库） 说明：从会话抽取结构化整理；与上文"向量检索算出排名，为啥还要额外加Re-rank模块"章互补（那里讲必要性，这里讲怎么做与工程细节）

4.1 Rerank 是什么

4.2 RRF 融合 vs Rerank（关键区分）

项目 RRF 融合 Rerank
原理 只看排名，不读文本语义，只是把多路召回结果合并 模型真正理解问题和文档内容，做细粒度相关性打分
精度 低 远高于 RRF
定位 粗召回阶段的合并去重 精排阶段

4.2.1 RRF 原理与收益（倒数排名融合详解）

来源：豆包会话 2026-09-14 补充整理；工程链路见 4.3，与 10.3.4（混合检索量纲问题）、26.3.6（MRR 提高）呼应。

全称：Reciprocal Rank Fusion（倒数排名融合），Cormack et al. 2009 年提出（论文 "Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods"）。

公式：

RRFScore(d) = Σ_{r ∈ 各检索路} 1 / (k + rank_r(d))

为什么用排名、不用分数（核心设计）：各路检索器分数量纲不可比——向量相似度是 0~1 区间的小数，BM25 打分可能是十几甚至几十（10.3.4 讲过：直接相加 BM25 会把向量分淹没）。RRF 彻底绕开分数，只比"谁排得靠前"，天然免疫量纲问题，也无需做分数归一化。

计算实例（两路：BM25 + 向量，k=60）：

文档 BM25 排名 向量排名 RRF 得分
A（两路都靠前） 3 5 1/(60+3) + 1/(60+5) = 0.0159 + 0.0154 = 0.0313
B（仅 BM25 第一） 1 未命中 1/(60+1) = 0.0164
C（仅向量第二） 未命中 2 1/(60+2) = 0.0161

→ 文档 A 虽然任何单路都不是第一，但"两路都靠前"让分数叠加后反超 B、C，排到融合结果最前。这就是 RRF 让相关文档 rank 提前的机制。

好处： 1. 零参数、免训练：只有一个 k（经验值 60 基本不用调），无训练成本、无权重学习，即插即用 2. 免疫分数量纲：不依赖任何一路的分数分布，BM25/向量/稀疏/稠密随便混 3. 鲁棒：某一路检索失效（如向量库挂了、query 太口语化 BM25 召回差），另一路还能兜底，融合结果不会整体崩 4. 实现极简：几行代码，计算快，适合线上低延迟场景 5. 多路互补：关键词精确命中与语义近义互相补充，让"正确但单路排名不高"的文档通过叠加进入候选池前列

提升的指标： - Recall@K ↑（最直接）：多路结果合并，候选集天然变大，正确文档漏召回概率下降 - Hit Rate ↑：随 Recall 上升，命中率同步改善 - MRR ↑：相关文档因多路同现叠加分数而排名提前，MRR（倒数排名）随之上升——这是 26.3.6 里"混合检索提升 MRR"的底层机制 - NDCG 温和改善：对排序质量有正向帮助，但 RRF 是启发式，提升幅度弱于学习型排序器（如 LambdaMART，见 10.3.4） - Precision@K 不确定：融合可能引入"只在某一路出现的高分噪音"，Precision 需要评测集实测，不保证提升

局限（面试常追问）： - 完全忽略分数信息：分数差距极大但排名相邻的两个文档被同等对待 - 默认各路等权：检索器质量差异被忽略（可加权重做 Weighted RRF） - 依赖每路 Top-K 质量：K 太小会漏，K 太大会引入噪音（4.6 说典型 15-30 条候选）

一句话记忆：RRF 是"只看排名的免训练融合器"，用倒数排名把多路结果叠加排序，解决量纲不可比，提 Recall/Hit Rate/MRR；它是粗召回阶段的合并去重，精排还要交给 Rerank。

4.3 工业标准链路

用户 Query
  → 向量检索 top20-40 + BM25 检索 top20-40
  → RRF 融合、去重，得到候选池（20-30 条）
  → Rerank 重排序
  → 取 top5-8 送入 LLM 生成答案

4.4 Bi-Encoder vs Cross-Encoder（底层原理）

项目 Bi-Encoder（embedding 向量模型，粗召回） Cross-Encoder（Rerank 重排模型，精排）
编码方式 query、文档分别独立编码成向量，最后只做余弦相似度 把 [CLS] query [SEP] chunk [SEP] 拼接成一整段输入，同一个 Transformer 一起编码
token 级交互 无，只能做粗粒度匹配 每一层注意力都让问题的词和文档的词互相看见
能力 速度快 能识别否定、反问、细微语义差异，相关性判断强很多
代价 可预计算文档向量 不能预计算文档向量；每一条候选都要跑一次推理，速度慢，只能处理小候选池

所以 Rerank 绝对不能直接跑全量知识库；必须先粗召回缩小候选池。

4.5 主流通用方案（模型选型）

开源本地部署（国内企业首选）： - BGE-reranker-v2-m3（智源）：中文通用首选，效果好，支持长文本，工业用的最多 - bce-reranker-base_v1（网易有道）：推理速度快，中文表现优秀 - qwen-rerank：通义千问开源重排，长上下文能力强 - 小显存优先 base 版本；显存充足上 large 版本；推理建议 INT8 量化降低显存加速推理

API 云服务（不想部署模型）：Cohere Rerank、阿里云、火山引擎的 rerank 服务，直接 HTTP 调用，适合 POC、小流量业务

4.6 工程最佳实践

  1. 候选池大小（送入 rerank 的数量）：粗召回合并后给到 rerank 的候选 15-30 条，不要超过 40 - 太小（<10）：rerank 没有足够候选，容易漏掉优质 chunk - 太大（>50）：延迟暴涨、QPS 下降、算力开销大 - 典型配置：向量 top30 + BM25 top30，RRF 融合去重后一般落在 20-30，直接丢给 rerank
  2. rerank 之后取多少条给 LLM：取 5-8 条送入大模型
  3. 分数阈值过滤（很实用）：rerank 输出分数设阈值，低于阈值全部丢弃 - 例：阈值 0.01，所有 chunk 分数都低于阈值 → 知识库没有答案，直接输出"知识库没有相关信息"，避免强行喂无关文档减少幻觉 - 注意：不同 rerank 模型分数分布不一样，阈值不要抄网上数字，拿自己业务评测集调
  4. 不要做的坑： - 不要把上千条文档直接丢 rerank（延迟爆炸） - 不要跳过 RRF 直接把两路原始结果丢 rerank（可以但重复候选多、浪费算力；优先 RRF 合并去重） - 不要迷信 rerank：rerank 救不了很差的 chunk 切片（切片质量差 rerank 效果也拉胯） - 不要用 rerank 替代 embedding 检索：rerank 只能做精排，不能做全库检索
  5. 性能优化（线上延迟）： - 模型量化：INT8/FP16 降低显存加速推理 - 做成独立 rerank 推理服务（HTTP/gRPC），业务服务调用 - 批量推理：一次把一批候选文档送进去，不要循环一条一条调用 - 延迟极度敏感业务：条件 rerank——向量 top1 分数很高时直接跳过 rerank，牺牲一点精度换速度
  6. 元数据增强小技巧：给 rerank 输入的 chunk 文本前面拼接元数据（如【文档标题：xxx；章节：xxx】\n 实际 chunk 内容），rerank 可利用标题、章节信息提升相关性打分

4.7 什么时候可以不用 Rerank

4.8 指标层面看 Rerank 带来的变化

5 向量检索算出排名，为啥还要额外加Re-rank模块

5.1 视频信息

项目 内容
视频名称 向量检索算出排名，为啥还要额外加Re-rank模块
时长 3分21秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7643017424383544630
飞书妙记 https://www.feishu.cn/minutes/obcnh4yah211l53d5h27u5pb
关键词 RAG、Re-rank、向量检索、重排序、召回率、精确率、交叉编码器

5.2 全文摘要

本视频以面试题形式深入解析了RAG系统中Re-rank（重排序）模块的核心作用。虽然向量检索已经通过相似度算出了排名，但仍需要Re-rank进行二次精排。核心原因是向量检索存在三大根本局限：语义粒度太粗（难以捕捉否定句、转折句等细粒度逻辑关系）、检索存在偏差（关键词漂移、同义词未对齐、专业术语泛化不足）、优化目标不一致（向量检索优化几何距离，而下游任务需要事实准确性和推理链支撑）。Re-rank作为RAG系统的质量闸门，通过交叉编码器等模型对候选文档进行精细化语义相关性打分，直接决定送入LLM的上下文纯度，是降低幻觉率、提升响应稳定性最立竿见影的手段。

注意：本视频为纯口播+背景画面，无PPT/架构图等有价值截图，故省略关键截图章节。

5.3 原文结构化整理

5.3.1 Re-rank的核心作用

5.3.2 两阶段解耦设计

阶段 目标 手段 特点
第一阶段：检索 高召回（Recall） 高效向量检索 在海量数据中快速捞出可能相关的文档
第二阶段：重排序 高精度（Precision） 更重更准的模型 对捞出的几十个片段精细化排查，把最能解决问题的答案顶到前面

5.3.3 向量检索的三大根本局限

5.3.3.1 语义粒度太粗
5.3.3.2 检索存在偏差
5.3.3.3 优化目标不一致（最核心）

5.3.4 Re-rank作为质量闸门

5.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 我看你的项目里用到了RAG技术，想问一下在RAG的场景中，rerank重排序的作用到底是什么？既然我们在第一步已经通过向量相似度算出了一个排名，为什么还需要大费周折地加一个rerank模块呢？

Speaker 2 00:00:12 这是一个非常经典且触及AI级核心痛点的问题。简单来说，rerank的核心作用就是对初始向量检索返回的top k候选文档进行更精细的语义相关性打分和重新排序。它的目的是提升最终送入大语言模型的上下文质量，确保信息密度更高，更契合用户的真实意图。我们可以从人机管道的两阶段解耦设计来看。为什么要这么做？第一阶段检索追求的是高召回Recall，我们需要用高效的向量检索，在海量数据里快速把可能相关的文档捞出来。第二阶段重排序，追求的是高精度Precision，我们要用更重更准的模型，对捞出来的这几十个片段进行精细化排查，把最能解决问题的答案顶到最前面。这就像传统的搜索引擎，向量检索相当于初筛，rerank相当于精排。

Speaker 1 00:01:09 两阶段的设计我理解。但既然向量检索已经算出了相似度，为什么说这个相似度还不够准？必须要有re-rank来修正呢？

Speaker 2 00:01:17 因为原始的向量检索在实际业务中存在三大根本局限。第一是语义粒度太粗，向量嵌入embedding通常是对一整段话或一整个段落进行整体表征，它是一个模糊的宏观印象，这就导致它很难捕捉到一些细粒度的逻辑关系，比如否定句、转折句、特定条件限制或者代词指代。可能两个句子的关键词很像，向量距离很近，但意思完全相反。

Speaker 2 00:01:45 第二是检索存在偏差，在实际场景中，用户提问往往千奇百怪，向量检索容易遇到关键词漂移、同义词没对齐或者特定领域专业术语泛化不足的问题，导致真正包含答案的片段排在了后面。第三也是最核心的一点，两者的优化目标不一致。向量检索优化的是嵌入空间的几何距离，比如余弦相似度，但我们rag下游任务真正需要的是对LM生成回答最有支撑作用的上下文。大模型需要的是事实的准确性、答案的覆盖度以及完整的推理链。这种任务级的信号是普通的向量距离无法表达的。

Speaker 1 00:02:27 明白，那也就是说，rerank在这里其实是一个质量把关的角色。

Speaker 2 00:02:31 对，您可以把它看作是整个RAG系统的质量闸门，因为大模型存在迷失在中间的现象。如果最关键的信息没有排在最前面，或者夹杂了太多噪音，大模型的回答准确率就会直线下降，甚至引发幻觉。通过引入cross减encode交叉编码器等重排模型，虽然多消耗了一点点计算资源，但它直接决定了送入LLM的上下文纯度。在我们的实践中，它是降低大模型幻觉率、提升响应稳定性最立竿见影的手段。所以，re-rank不是冗余，而是打通RAG落地最后一公里的关键。

Speaker 1 00:03:10 我整理好了一份大厂面试题和学习文档，里面就包含了整个AI产品的研发流程、大模型的未来发展方向以及AI产品当前存在的一些问题，想要的我可以安排。

📄 来源：025_三年大模型经验，被一个 “RAG 幻觉” 问题干沉默了….md

6 三年大模型经验，被一个"RAG幻觉"问题干沉默了…

6.1 视频信息

项目 内容
视频名称 三年大模型经验，被一个"RAG幻觉"问题干沉默了…
时长 4分56秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7660842253534907663
飞书妙记 https://www.feishu.cn/minutes/obcnh46645yc2p5mpytrgs58
关键词 RAG、幻觉治理、全链路、事实校验、重排序、文档冲突、溯源

6.2 全文摘要

本视频以面试题形式深入解析RAG系统幻觉治理方案。核心问题：用户问知识库没有覆盖的问题，大模型凭空编造答案，如何从根源上压制幻觉？常见错误回答是"提示词加一句只根据文档回答+检索Top3"，但这远远不够。真正的方案需吃透三层核心逻辑：明确幻觉来源和失效场景（切片粒度、检索失准、模型自由生成、多轮污染）、落地全链路治理（检索优化+后置事实校验+切片优化+重排序+回答溯源）、生产异常处理（提示词失效、非结构化文档、版本冲突、降级方案）。

6.3 原文结构化整理

6.3.1 面试题背景与常见错误回答

面试题：做过企业级RAG知识库系统，用户问知识库没有覆盖的问题，大模型却凭空编造答案，如何从根源上压制幻觉，保证回答百分百基于已有文档？

常见错误回答： - 提示词里加一句"只根据给定文档回答，不知道就说无法解答" - 检索Top3相关片段塞给模型

面试官追问（暴露漏洞）： - 提示词约束容易失效（基础模型对齐弱、用户诱导绕过），这算不算核心方案？ - 检索片段不相关或切片太碎导致上下文断裂，模型拼不出完整逻辑，幻觉怎么根治？ - 多份文档信息冲突，模型不知道采信哪条，怎么处理？ - 低延迟场景不允许每轮大模型自我校验，有没有不用提示词工程的方案？ - 知识库全是历史非结构化文档，没法提前做事实抽取，怎么办？

6.3.2 第一层：明确幻觉的来源和失效场景

幻觉不是简单的模型瞎说，而是检索、生成、校验全链路的漏洞叠加：

来源 具体问题
文档切片 切片粒度不合理，导致上下文断裂
检索召回 召回排序不准，引入无关信息
大模型生成 自身生成惯性，补全不存在的内容
多轮对话 历史污染当前回答

6.3.3 第二层：全链路治理核心方案

最可靠基线：检索召回优化 + 后置事实一致性校验

具体措施：

  1. 切片优化：建立文档多级切片机制，粗粒度召回、细粒度匹配
  2. 重排序：引入交叉编码器（Cross-Encoder）做二次重排序，过滤低相关片段
  3. 回答溯源：生成阶段强制模型标注答案来源片段，输出必须对应到具体文档的具体段落，无来源的内容禁止输出
  4. 后置校验：逐句比对召回文档，不一致的内容直接剔除或替换为"无法根据现有资料解答"

6.3.4 第三层：生产落地异常处理细节

异常场景 处理方案
提示词失效 系统提示词只做基础约束，不做核心防线；真正可靠性依靠检索质量+后置事实校验
非结构化历史文档 新增独立的事实向量库，离线抽取文档中的实体与关系存入；回答时先匹配事实库再生成
文档版本冲突 同一问题不同版本文档冲突时，以最新版本为准，并标注版本来源
监控告警 监控幻觉拦截次数、检索命中率、答案溯源覆盖率，异常波动自动告警
降级方案 校验模块不可用时，降级为严格提示词+缩短生成长度，配合人工抽检兜底

核心考察点：能不能识别检索失准、文档冲突、模型自由发挥等真实场景？知不知道不依赖提示词工程如何实现可控生成？有没有切片优化、重排序、事实校验、溯源体系等工程落地经验？

普通开发只会堆提示词，大厂开发能徒手设计从检索到生成再到校验的全链路幻觉治理体系。

6.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 你说你做过企业级RAG知识库系统，那我问你，用户问一个知识库没有覆盖的问题，大模型却凭空编造答案输出给用户，你的系统如何从根源上压制幻觉，保证回答百分百基于既有文档？今天刚面了一个大模型开发，我问他，RAG幻觉治理看似简单，但要考虑文档切片粒度、检索召回失准、大模型自由生成、多轮上下文污染等场景，从提示词约束到全链路增强怎么设计？他想了一下说，提示词里加一句，只根据给定文档回答。

Speaker 1 00:00:36 不知道就说无法解答，同时检索TOP3相关片段塞给模型就够了。我顺着他的话继续问，提示词约束很容易失效，比如基础模型对齐能力弱，或者用户诱导提问绕过限制，这个防御算不算你的核心方案？如果检索召回的片段本身不相关，或者切片太碎导致上下文断裂，模型拼不出完整逻辑，依然会编造内容补全，幻觉怎么根治？如果提示词没问题，但召回的多份文档存在信息冲突，模型不知道该采信哪条。

Speaker 1 00:01:07 最后输出错误结论，你怎么处理？如果业务场景有低延迟要求，不允许每轮都靠大模型自我校验，你有没有不用提示词工程的幻觉治理方案？比如基于知识库的事实校验，它的优缺点是什么？如果知识库本身全是历史非结构化文档，没法提前做事实抽取，你怎么办？他瞬间慌了，说可以把提示词写得更严格点，说不依赖提示词的话，可以多召回几篇文档。但问到非结构化文档的事实校验落地方案完全没思路，面试到这里基本就可以结束了，这正是会写提示词和能设计低幻觉RAG系统的关键分水岭。很多人以为加个系统提示词就解决了幻觉，但一遇到检索失准、文档冲突、模型自由发挥这些生产环境真问题就崩了。

Speaker 1 00:02:14 面试官问这个问题，考察的不是你会不会写prompt，而是你在任意文档、任意提问下，都保证回答有据可依。真正能通过面试的幻觉治理方案，必须吃透三层核心逻辑。第一层，先明确幻觉的来源和失效场景。幻觉不是简单模型瞎说，而是检索、生成、校验全链路的漏洞叠加。文档切片粒度不合理，导致上下文断裂。检索召回排序不准，引入无关信息。大模型自身生成惯性补全不存在的内容。多轮对话历史污染当前回答。第二层，选一套核心方案落地全链路治理。以检索召回优化加后置事实一致性校验为最可靠基线。辅以切片优化重排序，回答溯源，建立文档多级切片机制，粗粒度召回，细粒度匹配，引入交叉编码器做二次重排序，过滤低相关片段。生成阶段强制模型标注答案来源片段，输出必须对应到具体文档的具体段落，无来源的内容禁止输出。校验阶段逐句比对召回文档，不一致的内容直接剔除或替换为无法根据现有资料解答。

Speaker 1 00:03:28 第三层，生产落地的异常处理细节。提示词失效问题，系统提示词只做基础约束，不做核心防线，真正的可靠性依靠检索质量加后置事实校验，即使模型想编造，后置校验也会把不实内容拦下来。无法结构化的历史文档，新增独立的事实向量库，离线抽取文档中的实体与关系存入。回答时先匹配事实库，再生成。

Speaker 1 00:03:56 文档版本冲突问题，同一问题不同版本文档冲突时，以最新版本为准，并标注版本来源。监控幻觉拦截次数、检索命中率、答案溯源覆盖率。异常波动自动告警，如果校验模块不可用，业务可降级为严格提示词加缩短生成长度，配合人工抽检兜底。这个就叫专业。讲到这里大家就明白了，面试官问RAG幻觉治理，根本不是考你会不会写提示词，核心考察三点，能不能识别检索失准、文档冲突、模型自由发挥等真实场景？知不知道不依赖提示词工程如何实现可控生成？有没有切片优化、重排序、事实校验、溯源体系等工程落地经验？普通开发只会堆提示词，出问题只会让模型再严谨一点。大厂开发能徒手设计一套从检索到生成，再到校验的全链路幻觉治理体系，扛得住开放提问、文档混乱、模型波动的复杂生产场景。

6.5 关键截图

6.5.1 生产落地异常处理细节

img

📄 来源：034_26年大模型春招模拟面： RAG如何进行query改写.md

7 RAG Query 改写技术全景与工程最佳实践（2026-09-11 豆包会话补答）

体系定位：RAG 检索前置环节——Query 改写的技术分类、主流方法与工程落地 来源：豆包分享会话 https://www.doubao.com/thread/x3liRn2CCcAgJxsNz 中用户提问"RAG Query 改写有什么技术？"，该问题在链接内无 AI 回答，由豆包补答后整理入库（2026-09-11） 说明：与本章其他 Query 改写视频转录章节互补（视频讲具体面试答法，本篇给技术全景分类）

7.1 为什么需要 Query 改写

7.2 Query 改写技术全景（分类）

7.2.1 规则/传统方法

7.2.2 LLM 改写（主流）

7.2.3 检索增强改写

7.2.4 混合/路由策略

7.3 工程最佳实践

  1. 不是所有 query 都改：简单明确 query 直接检索，避免过度改写引入噪声、增加延迟
  2. 改写 prompt 要点：给对话历史、给改写规则（保持原意不变、只服务检索、输出格式约束如"只输出改写结果"）、必要时给文档领域术语提示
  3. 多轮场景：结合最近 N 轮历史做指代消解；历史太长时先用摘要压缩
  4. 改写产物设计：输出"改写后 query"，同时保留原始 query，两路都检索再 RRF 融合（改错了也有兜底）
  5. 评估：改写前后对比 HitRate / MRR / Context Precision；线上做 A/B 实验看端到端答案质量（而不是只看改写本身的合理性）
  6. 兜底：改写低置信/改写后召回更差时，回退原始 query 检索
  7. 成本控制：改写是一次额外 LLM 调用，高频场景可缓存（相同/相似 query 复用改写结果），或只对部分 query 触发改写

7.4 极简代码 Demo（LLM 改写）

def rewrite_query(llm, raw_query, history=None):
    """把用户 query 改写成检索友好 query：指代补全 + 口语转书面 + 保留原意"""
    prompt = f"""你是 RAG 检索系统的查询改写器。
历史对话（可能为空）：{history or '无'}
用户原始提问：{raw_query}
任务：把原始提问改写为适合向量检索的独立查询——
1. 补全指代（它/这个/那家 → 具体实体）
2. 去掉口语和语气词
3. 保持原意，不添加新事实
只输出改写后的查询，不要解释。"""
    return llm(prompt).strip()

# 工程用法：改写前后双路检索 + RRF 融合
def retrieve(rewriter_llm, embed_model, bm25, raw_query, history):
    rewritten = rewrite_query(rewriter_llm, raw_query, history)
    vec_hits = embed_model.search(rewritten, top_k=30)   # 改写后向量检索
    bm25_hits = bm25.search(raw_query, top_k=30)          # 原始 query BM25
    return rrf_fuse(vec_hits, bm25_hits)                  # RRF 融合去重 → 候选池

一句话总结：Query 改写 = 把"用户怎么说"翻译成"文档怎么写"，主流做法是 LLM 改写（指代消解/意图重写/问题分解）+ 检索增强（HyDE/伪相关反馈/双路融合），配合路由判断"哪些 query 值得改"。

8 26年大模型春招模拟面：RAG如何进行query改写

8.1 视频信息

项目 内容
视频名称 26年大模型春招模拟面：RAG如何进行query改写
时长 3分23秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7671234567890123456
飞书妙记 https://www.feishu.cn/minutes/obcnh57214k47t1ruxq63i3j
关键词 RAG、query改写、查询重写、多查询生成、子查询分解、假设文档嵌入、后退提示

8.2 全文摘要

本视频以面试模拟形式讲解RAG系统中的query改写技术。核心目的是把用户原始问题翻译成更适合检索的形式，解决用户提问口语化、模糊、冗余信息多导致检索效果差的问题。视频介绍了五种常见方案：查询重写（大模型改写更清晰专业）、多查询生成（一个问题展开成3-5个变体同时检索）、子查询分解（复杂问题拆成多个子问题分别检索）、假设文档嵌入（先生成假设性答案再用答案检索）、后退提示（从具体问题退到更宏观的问题检索背景信息）。实际项目中通常组合使用，关键是根据业务需求选择和组合。

注意：本视频为纯口播形式（真人出镜+字幕），无PPT/架构图等有价值截图，故不附关键截图。

8.3 原文结构化整理

8.3.1 为什么要做query改写

8.3.2 五种常见改写方案

方案 原理 适用场景 示例
1. 查询重写 用大模型把用户问题改写得更清晰、更专业 口语化问题 "某个产品最新版本怎么样？" → "请介绍某个产品最新版本功能特点和性能提升"
2. 多查询生成 把一个问题展开成多个相似但角度不同的问题，同时检索，最后合并结果 用户提问比较笼统 "如何提高RAG系统性能" → "RAG性能优化方法"+"提高RAG检索精准率技巧"+"RAG性能瓶颈及解决方案"
3. 子查询分解 针对复杂问题，拆成不同子问题，每个单独检索，再整合答案 包含多层意思的复杂问题 "对比GPT和Claude在代码生成和长文本理解上的差异" → 拆成代码生成、长文本理解、对比三个子问题
4. 假设文档嵌入 不是改写问题，而是先让大模型生成假设性答案/文档片段，再用假设文档去检索 问题与答案语义表达方式差别大 用假设的答案去检索，因为语义更接近实际文档，匹配度更高
5. 后退提示 不是让问题更具体，而是让问题更宏观、更通用 知识库没有具体信息时 "某个产品价格是多少" → 退一步问"这个公司的定价策略是什么"或"同系列相似产品价格体系"

8.3.3 实际项目中的组合使用

8.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 好，那你说一下RAG是怎么进行query改写的？

Speaker 2 00:00:03 先说一下为什么做query改写？因为用户的提问方式和知识库往往不太匹配，比如用户问的非常口语化，很模糊，或者问题里面夹杂了很多冗余信息，那这样直接去检索的话，效果肯定不好。query改写的核心目的就是把用户的原始问题翻译成更加适合检索的一种形式，让我们的检索结果更加精准。

Speaker 2 00:00:26 具体我就会用到几种常见的方案，第一种就是最直接的查询重写，这个思路就是用大模型把用户的问题改写的更加清晰，更加专业。比如用户问某个产品的最新版本怎么样？这个问题就太口语化了，可以让大模型直接把它改写成，请介绍某个产品最新版本功能特点，还有性能提升。改写之后问题就更加规范，关键词也更准确，检索的时候更容易匹配到相关的文档。

Speaker 2 00:00:53 第二个就是多查询生成，这个方法就是把一个问题展开成多个相似但角度不同的问题，同时去检索，最后把结果合并。比如用户提问如何提高RIG系统的性能，我们就可以把它变成3~5个变体。比如RIG性能优化方法，提高RIG检索精准率的技巧，RIG系统的性能瓶颈还有解决方案。把每个变体都去检索一遍，然后把结果汇总，这样覆盖面就更广，不容易漏掉关键信息。这个方法就特别适用于用户提问比较笼统的场景。

Speaker 2 00:01:26 第三个就是子查询分解，这个就是针对复杂问题的，有些用户的问题特别复杂，一下子包含了好几层意思。比如对比GPT和Claude在代码生成和长文本理解上的差异，这个问题其实包含了两个维度。代码生成和长文本理解，还要做对比。我们可以把它拆成不同的子问题，每个子问题单独去检索，再把答案整合在一起，这样逻辑就会更清晰一点。

Speaker 2 00:01:54 第四种就是假设文档嵌入，它不是直接改写问题，而是先让大模型根据问题生成一个假设性的答案或者文档片段，然后用这个假设性的文档去做检索。那为什么要这么做？就是因为有时候问题跟答案的语义表达方式差别很大，直接用问题去检索可能匹配不上。但如果用假设的答案去检索，因为语义就更接近实际的文档。匹配度就会更高。

Speaker 2 00:02:19 第五种就是后退提示，这个思路刚好相反，它不是让问题更具体，而是让问题更宏观、更通用。比如用户问某个产品的价格是多少，那这就是一个很具体的问题。但知识库里面如果没有这个具体的信息，检索就会失败。后退提示的做法就是先退一步，问一个更宏观的问题，比如这个公司的定价策略是什么？或者同系列相似产品的价格体系。

Speaker 2 00:02:45 先检索这些背景信息，再基于这些背景信息回答原始的具体问题，这样即便没有直接的答案，也可以给出一个合理的回复。在实际的项目里面，我们一般就把几种方法结合起来用，比如先做查询重写，把问题规范化，再生成多个query去检索，最后用重排序模型对结果重排序，这样效果就会更好一点。关键还是要根据具体的业务需求来选择和组合，经过不断的测试和优化，找到最合适的方案。

Speaker 1 00:03:15 我这里也整理了一份11万字大模型高频的面试题，感兴趣的小伙伴可以带回家学习。

📄 来源：035_RAG面试：TopK设多少？千万别瞎答 面试官问你RAG里的Top.md

9 RAG面试：TopK设多少？千万别瞎答

9.1 视频信息

项目 内容
视频名称 RAG面试：TopK设多少？千万别瞎答 面试官问你RAG里的Top
时长 4分14秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7669876543210987654
飞书妙记 https://www.feishu.cn/minutes/obcnh544557juh72n5s8a3he
关键词 RAG、TopK、召回率、精确率、重排序、切片大小、评估、拐点

9.2 全文摘要

本视频讲解RAG面试中"TopK设多少"这道高频题。核心不是一个数字，而是召回率和精确率的权衡。K太小会漏掉关键证据导致答不全，K太大会引入噪声（烧钱、变慢、干扰模型）。视频给出四个工程手段：与切片大小配合调、用粗召回+重排解耦矛盾、根据问题复杂度动态调、靠离线评估找到答案质量拐点。最后提供了完整的面试回答模板。

9.3 原文结构化整理

9.3.1 这道题在考什么

9.3.2 K太小的坑：召回不足

9.3.3 K太大的坑：噪声干扰

代价 说明
烧钱 上下文越长，Token越贵
变慢 处理内容多了，延迟上来
干扰模型 最要命，本来能答对的反而被无关信息带偏

9.3.4 工程上怎么设TopK（加分点）

  1. 别孤立调K，要跟切片大小一起看 - 切片大、信息全 → K可以小一点（如3个就够） - 切片碎 → 可能得5个甚至更多才能凑齐信息 - 这俩得配着调

  2. 最关键一招：用重排来解耦矛盾 - 先用检索粗捞一批（如二三十个），保证召回率 - 再用专门的重排模型重新打分排序，只把最靠前的几个真正喂给大模型 - 粗召回保证不漏，重排保证不噪

  3. K不一定要写死，可以动态调 - 简单问题少给几个，复杂问题多给几个

  4. 最后一定要靠评估说话 - 拿一批真实问题，试3、5、10这几个值 - 看命中率和答案准确率在哪个点最好 - 用数据定，不是拍脑袋

9.3.5 面试回答模板

  1. 纠正前提：TopK没有固定值，本质是召回率和精确率的权衡
  2. 讲两头的坑：K太小漏掉关键证据导致答不全；K太大引入噪声，又烧钱又变慢还干扰模型
  3. 讲怎么定：先根据切片大小定范围，切片大K可以小，切片碎K要大些
  4. 给出关键工程手段：用粗召回+重排解耦矛盾，先多捞保证不漏，再重排只留最相关的喂给模型
  5. 收尾：具体的K一定要靠离线评估在真实问题上跑出来，看答案质量的拐点在哪，而不是用默认值

核心记忆：少了会漏，多了会噪。先用召回保证不漏，再用重排保证不脏，最后用评估找到那个拐点。

9.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 面试官问你，RAG里topk你一般设多少？你要是脱口而出，我一般设个5或者10吧，那这题基本就答砸了。因为面试官问的根本不是一个数字，他是在看你懂不懂这个数字背后的权衡。你随口给个5，他下一句就会追，为什么不是3？为什么不是20？你要是答不上来，他就知道你只是照着教程抄了个默认值，从来没在真实项目里调过。

Speaker 1 00:00:21 我是小哲，点赞收藏加关注，我们马上开始。想系统学习Agent开发的同学可以查看橱窗哦。先说这题在考什么？topk的意思就是检索的时候，从知识库里捞回多少个最相关的片段，塞给大模型去参考。这题表面问你捞几个，实际是在考你理不理解检索里那个最核心的矛盾，召回率和精确率的拉扯。捞的太少，可能把真正有用的那条漏掉了，模型没料可用，答不全，甚至答错。捞的太多，一堆看着相关，其实没用的噪声也跟着进来了，不光烧token，增加延迟，还会干扰模型，让它抓不住重点。面试官想看的就是你能不能把这个拉扯讲明白，并且知道怎么去平衡它。

Speaker 1 00:00:59 一句话给你总答案，TopK没有标准值，它是一个要根据你的切片大小、内容质量和业务场景去调的平衡点。核心原则是，先保证该找的能找回来，再尽量少带噪声进来，然后靠评估去验证到底设多少最好。谁跟你说TOP K就该设5，那他八成没做过真实的RAG。我们先看K太小的坑。K设的太小，比如就取一两个，风险是召回不足。

Speaker 1 00:01:23 真实场景里，一个问题的答案经常散落在好几个片段里，你只取一两个，很可能刚好漏掉关键那条，模型手里的证据不全，只能瞎编或者答一半。尤其是当你的切片切的比较大，每一块信息密度高的时候，K小一点问题还不大。但如果切的比较碎，K太小就特别容易丢信息。所以k的下限是由你能不能把答案需要的证据凑齐来决定的。

Speaker 1 00:01:44 再看K太大的坑，这个坑更隐蔽，很多人觉得，那我多捞点总没错吧？宁可多带，别漏掉。错就错在这，K越大，召回率是上去了，但捞回来的东西里，那些看着主题相关，其实压根不支持答案的段落也越来越多，这就是噪声。噪声有三个代价，第一烧钱，上下文越长，Token越贵。第二变慢，处理的内容多了，延迟就上来。

Speaker 1 00:02:05 第三也是最要命的，模型会被这些无关信息带偏，本来能答对的，反而被干扰了。研究里有个规律，K从小往大调，答案质量一开始是涨的，因为覆盖变全了，但涨到某个点之后，噪声开始占主导，再加就不涨，甚至往下掉。你的任务就是找到那个拐点。那工程上到底怎么设？这是加分点。第一，别孤立的调K，要跟切片大小一起看。切片大，信息全，K可以小一点，比如3个就够。切片碎，可能就得5个甚至更多才能凑齐信息，这俩得配着调。第二，也是最关键的一招，用重排来解耦这个矛盾。你可以先用检索粗捞一批，比如捞回二三十个，保证召回率。然后用一个专门的重排模型给它们重新打分排序，只把最靠前的几个真正喂给大模型。这样召回和精确就不用互相牺牲了，粗召回保证不漏，重排保证不燥。第三，K不一定要写死，可以根据问题复杂度动态调。简单问题少给几个，复杂问题多给几个。第四，最后一定要靠评估说话。拿一批真实问题，试3、5、10这几个值，看命中率和答案准确率在哪个点最好，用数据定，而不是拍脑袋。给你一个面试回答模板。第一句，先纠正前提，TopK没有固定值，它本质是召回率和精确率的权衡。第二句，讲两头的坑，K太小会漏掉关键证据，导致答不全。K太大会引入噪声，又烧钱又变慢，还干扰模型判断。第三句，讲怎么定，先根据切片大小定个范围，切片大，K可以小，切片碎，K要大些。第四句，给出关键工程手段，用粗召回加重排解耦这个矛盾，先多捞，保证不漏。再重排，只留最相关的喂给模型。最后收一句，具体的k一定要靠离线评估在真实问题上跑出来，看答案质量的拐点在哪，而不是用默认值。这么讲下来，面试官就知道你是真调过线上RAG的。所以你看，TOP K这道题考的不是一个数字，是你脑子里有没有那杆秤。记住核心，少了会漏，多了会噪。先用召回保证不漏，再用重排保证不脏，最后用评估找到那个拐点。谁能把这套权衡讲清楚，谁才是真正做过RAG的人。这类大模型工程化的面试题背后全是真实项目里叼出来的经验。想系统准备的话，先关注我，下一道咱们接着拆。

9.5 关键截图

9.5.1 K太小：召回不足

img

9.5.2 证据散落与遗漏

img

9.5.3 K太大：噪声的三个代价

img

9.5.4 工程手段：粗召回+重排解耦

img

📄 来源：039_RAG准确率如何从60提升到85%？.md

10 RAG准确率如何从60提升到85%？

10.1 视频信息

项目 内容
视频名称 RAG准确率如何从60提升到85%？
时长 5分54秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7654321098765432109
飞书妙记 https://www.feishu.cn/minutes/obcnh595ljra98g6849xs656
关键词 RAG、准确率、动态切分、重叠窗口、Query改写、混合检索、重排序、LambdaMART、召回率、忠实度

10.2 全文摘要

本视频讲解如何将RAG系统准确率从60%提升到85%，核心是四步优化：数据处理优化（NLP语义感知动态切分+10%-20%Token重叠窗口，替代固定Token一刀切，单独就能提升15个点）、用户Query预处理（小模型扩写+余弦相似度≥0.8校验兜底，防止扩写幻觉引入噪声）、混合检索与重排序（向量检索+BM25混合，用LambdaMART排序学习模型统一量纲，策略路由分流控制耗时）、指标拆解（context recall上下文召回率+faithfulness忠实度，精准定位检索环节还是生成环节问题）。

10.3 原文结构化整理

10.3.1 问题背景：本地demo行，上线就60%

10.3.2 第一环：数据处理优化（文档分块）

全链路性价比最高的优化，没有之一。单独就能把准确率拉高15个点。

错误做法（实验室玩法）： - 固定Token数一刀切，如每500 token切一段 - 问题：把完整知识点、结构化表格、因果逻辑直接砍断 - 检索召回的全是碎片化残缺信息，大模型连完整上下文都看不到

工业界标准做法： - NLP语义感知的动态切分：用专业分句模型和文档结构解析模型，精准识别句子完整边界、文档标题层级、段落语义完整性 - 上下文重叠窗口：保留单切片10%-20%的Token重叠（100-200个Token），像接力赛交棒区，保证语义连贯不断层 - 绝不把同一段语义的内容拆到两个切片里

10.3.3 第二环：用户Query预处理

上线后准确率跳水的核心原因。

问题：真实用户提问根本不是实验室里的完整长问句，很多时候就两三个字（如"怎么退费？""开票规则"），问题极短，语义极度模糊，直接检索找不到匹配内容。

常规解法：用小模型做Query扩写，生成几个同义问句再检索。

90%的人都会踩的坑：扩写模型一旦出现幻觉，把"怎么退费"改成"怎么收费"，直接把检索带偏，准确率越来越低。

必须加的兜底机制： - Query改写语义相似度校验：所有扩写、改写后的问句，必须先用嵌入模型计算余弦相似度 - 确保和原问句相似度不低于0.8（通用场景黄金阈值） - 低于这个值说明改写偏离原意，直接废弃不用 - 从源头杜绝自己给系统引入噪声

10.3.4 第三环：混合检索与重排序

问题：向量检索打分是0.1区间，BM25打分可能是十几甚至几十，两个维度量纲完全不一样，直接简单相加会导致BM25分数把向量分淹没，混合检索等于白做。

工业界标准解法： - 用LambdaMART排序学习模型，不用拍脑袋定权重 - 轻量模型把多路检索特征统一映射到同一个打分维度，实现真正科学的混合排序

面试官90%会追问：排序模型效果好，但单条推理要200毫秒，高并发场景下接口超时甚至服务雪崩，怎么解决？

答案：策略路由分流 - 简单用户提问直接走向量检索，毫秒级响应 - 只有语义复杂、首轮检索匹配度低的难问题才触发重排序模型 - 好钢用在刀刃上，既保住准确率，又控制耗时和成本

10.3.5 第四环：指标拆解与问题定位

只说整体准确率85%完全没有说服力，必须把指标做拆解，核心盯两个指标：

指标 含义 问题定位
context recall（上下文召回率） 用户问题的正确答案有没有出现在检索回来的TopN切片里 没出现→检索环节问题，优化切分和检索策略
faithfulness（忠实度/幻觉率） 检索回来的资料里明明是A，大模型有没有脱离资料瞎编 有→生成环节问题，优化Prompt和生成策略

把这两个指标监控起来，才能精准定位问题，而不是盲目调参。

10.3.6 面试口诀

切分不搞一刀切，动态语义加重叠 改写不丢原语义，相似度校验做兜底 排序不拍脑袋定，LambdaMart来统一 优化不看笼统分，召回忠实拆分明

10.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 面试被问，怎么把RAG系统的准确率从60%拉到85%？你的回答直接决定了你是拿普通offer还是高薪offer。大家好，我是Jack。我敢说80%的人都在这个问题上踩过坑，本地demo跑起来样样行，一问就对，结果一上线连接真实用户流量，准确率直接卡在60%，不上不下。剩下的问题就像个摸不透的黑盒，根本找不到优化的方向，越调越乱。

Speaker 2 00:00:29 在这整理了全套高频面试题及解析，规划了系统的学习路线。还有几十上百集RAG Agent模型微调和项目实战的视频教程，相关书籍、课件等。

Speaker 1 00:00:37 今天就用我亲手落地的工业级RAG项目经验，给大家拆透到底靠哪几步核心优化，能稳稳把准确率拉高25个百分点，面试这么答，直接和只会调demo的候选人拉开绝对差距。第一环先打牢整个系统的地基，数据处理优化，也可以理解为文档分块处理，这是全链路性价比最高的优化，没有之一。很多人做文档切分图省事，直接固定token数，一刀切，比如每500 token切一段，这是典型的实验室玩法，上线必出问题。你想，一刀切下去，很可能把一个完整的知识点、一张结构化表格、一段因果逻辑直接砍断。检索的时候，召回的全是碎片化的残缺信息，大模型连完整上下文都看不到，怎么可能给出正确答案？工业界的标准落地玩法是NLP语义感知的动态切分，加上下文重叠窗口。我们不用死板的token计数器，而是用专业的分句模型和文档结构解析模型，精准识别句子的完整边界、文档的标题层级、段落的语义完整性。绝不把同一段语义的内容拆到两个切片里，同时切分的时候，我们会保留单切片10%到20%的Token重叠，也就是100到200个Token的上下文衔接，就像接力赛的交棒区，保证语义连贯不断层。

Speaker 1 00:02:01 就这一步优化，在固定Token切分的基线上，不用动大模型分毫，就能直接把准确率拉高15个点。面试里讲出这个细节，直接证明你有真实的线上落地经验。地基打稳了，接下来第二环就是线上问题的重灾区，用户Query的预处理，这是很多人上线后准确率跳水的核心原因。真实用户的提问根本不是实验室里的完整长问句，很多时候就两三个字，比如怎么退费？开票规则，问题极短，语义极度模糊，直接检索根本找不到匹配的内容。常规的解法是用小模型做query扩写，生成几个同义问句再检索，思路没错，但这里藏着一个90%的人都会踩的巨坑。扩写模型一旦出现幻觉，把怎么退费改成了怎么收费，直接把检索带偏，准确率只会越来越低。所以这里必须加一个绝大多数教程都不会提的兜底机制。

Speaker 1 00:03:00 query改写语义相似度校验，所有扩写、改写后的问句，必须先用嵌入模型计算余弦相似度，确保和原问句的相似度不低于0.8这个通用场景黄金阈值，只要低于这个值，就说明改写偏离了原意，直接废弃不用。这一步就是从源头杜绝我们自己给系统引入噪声。接下来就是整个RAG系统的核心，混合检索与重排序。大家都知道要做向量检索加BM 25关键词检索的混合检索，但我问你，向量检索的打分是0.1的区间，BM25的打分可能是十几甚至几十，两个维度的量纲完全不一样，你怎么合并打分？很多人直接简单相加，结果就是BM 25的分数直接把向量分淹没，混合检索等于白做。

Speaker 1 00:03:51 工业界的标准解法是用业界主流的LambdaMART排序学习模型，不用你拍脑袋定权重，用这个轻量模型把多路检索的特征统一映射到同一个打分维度，实现真正科学的混合排序。这里还有一个面试官90%会追问的问题，从排序模型效果好，但单条推理要200毫秒，高并发场景下接口直接超时，甚至服务雪崩，你怎么解决？答案非常简单，就是策略路由分流，简单的用户提问直接走向量检索，DS级响应，只有语义复杂，首轮检索匹配度低的难问题才触发从排序模型，好钢用在刀刃上，既保住了准确率，又控制了耗时和成本。

Speaker 1 00:04:35 最后所有优化都做完了，怎么证明你的优化有效？怎么精准定位剩下的问题？只说整体准确率85%，完全没有说服力。你必须把指标做拆解，核心就盯两个指标。第一个是context recall，上下文召回率，说白了就是用户问题的正确答案有没有出现在你检索回来的topn切片里？如果没出现，那就是检索环节的问题，去优化切分和检索策略。第二个是faithfulness，忠实度，也就是我们常说的幻觉率。看检索回来的资料里，明明是A，大模型有没有脱离资料瞎编乱造？如果有，那就是生成环节的问题，去优化prompt和生成策略。把这两个指标监控起来，你才能精准定位问题，而不是盲目调参。

Speaker 1 00:05:22 最后给大家总结四句好记的口诀，面试直接背。切分不搞一刀切，动态语义加重叠，改写不丢原语义，相似度校验做兜底，排序不拍脑袋定，LambdaMart来统一，优化不看笼统分，召回忠实拆分明。把这四步做透，你的RAG系统就能从demo玩具变成真正能扛住线上流量的工业级产品。下次面试再被问到这个问题，把这套逻辑讲出来，绝对能给面试官留下专业、有实打实落地经验的深刻印象。

10.5 关键截图

10.5.1 问题背景：60%准确率瓶颈

img

10.5.2 第一环：数据处理优化（动态切分）

img

10.5.3 第三环：混合检索与重排序

img

10.5.4 第四环：指标拆解（召回率与忠实度）

img

📄 来源：042_面试官：RAG 怎么优化回答效果？.md

11 面试官：RAG怎么优化回答效果？

11.1 视频信息

项目 内容
视频名称 面试官：RAG 怎么优化回答效果？
时长 4分28秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7663456789012345678
飞书妙记 https://www.feishu.cn/minutes/obcnh557685x97rq7po21b6u
关键词 RAG、语义完整性、父子块、语义切块、检索兜底、完整性校验、多级切块、结构化文档解析

11.2 全文摘要

本视频以法务合同RAG系统线上事故为切入点，讲解RAG回答效果优化的核心——语义完整性保障。事故原因是固定长度切块把一条完整违约赔付规则拆成两段，检索只命中前半截，大模型基于残缺信息给出错误答案。视频提出三层防御：第一层业务分级（高风险场景强制父子块+语义切块，普适场景用常规固定长度切块）、第二层检索兜底与完整性校验（语义边界校验自动扩展前后文、高风险问题二次校验、高频标准问题缓存）、第三层架构层优化（多级切块策略、结构化文档解析、强制完整上下文开关）。

11.3 原文结构化整理

11.3.1 线上事故案例：语义切块断裂

事故场景： - 公司上线法务合同RAG系统 - 商务人员咨询客户合同违约赔付规则 - RAG检索后给出结论：单方违约只需赔付合同额10%违约金 - 商务按此标准和客户敲定合作，结果正式法务审核被驳回 - 完整条款明确标注：项目启动后违约要赔付30%，只是这部分内容被切到了下一个文档块里 - 检索只召回了前半段，最终因为错误答复耽误签约进度，造成客户信任损失

根因：原文档条款完整无误，就是固定长度切块把一条完整规则拆成了两段，召回只命中前半截，大模型基于残缺信息给出错误答案。

这正是RAG落地的幽灵陷阱：以为多堆文档、调调切块大小就是生产级RAG，却没想到语义切块断裂，上线后微碎片会让大模型输出片面甚至错误的结论，直接造成业务损失。

11.3.2 第一层：业务分级，区分高风险与普适场景

场景类型 内容特点 切块方案
高风险场景 法务条款、财务规则、合规制度，逻辑强关联、错漏后果严重 强制父子块+语义切块：完整规则段落作为父块，细粒度子块用于语义召回，命中后自动映射回完整父块传入大模型
普适场景 产品说明、通用知识库、常见问题解答，容错率高 常规固定长度切块即可，信息略有缺失也不影响核心使用

11.3.3 第二层：检索兜底与完整性校验

  1. 语义边界校验：对召回的文档片段做语义边界校验，如果发现片段是段落中间截断、语义不完整的，自动扩展读取该片段的前后文内容，补全完整语义单元后再送入大模型

  2. 高风险问题二次校验：涉及法务、财务类的查询，召回结果生成答案后，自动和对应文档的完整章节做匹配度核对，信息覆盖率不足则触发补充召回

  3. 高频标准问题缓存：经过校验的标准答案在应用层做缓存，避免重复检索，反复出现碎片化问题

11.3.4 第三层：架构层优化，缩小语义断裂风险

  1. 多级切块策略：同一份文档同时生成章节级粗粒度切块和短句级细粒度切块两套向量，检索时先通过粗粒度定位完整章节，再在章节内做细粒度匹配，从根源保证上下文完整

  2. 结构化文档解析：对有明确标题层级的Word、PDF文档，优先按原生章节条款结构拆分，不强行按字符长度切割，保留原生语义单元

  3. 强制完整上下文开关：在项目投标、合同谈判等高风险时段开启，所有召回内容必须匹配完整语义单元后再生成答案，宁可牺牲一点检索响应速度，也要杜绝残缺信息入库

核心观点：这道题考的是有没有从调RAG参数升级为设计语义完整性方案的工程思维。普通开发以为RAG就是文档切块加向量检索，高级工程师知道，在答案准确性面前，RAG是一把双刃剑。

11.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 今天刚面了个2年大模型应用开发，我问他RAG怎么优化回答效果，他脱口而出，调小切块尺寸，多召回几个片段，丰富知识库内容，回答准确率自然就上去了。我点点头，笑着问了他一个真实发生的线上事故。假设你们公司上线了一套法务合同RAG系统，商务人员咨询客户合同的违约赔付规则，RAG检索后给出结论，说单方违约只需赔付合同额10%的违约金。商务按这个标准和客户敲定合作，结果正式走法务审核时被驳回。说完，整条款里明确标注，项目启动后违约要赔付30%，只是这部分内容被切到了下一个文档块里，检索只召回了前半段，最终因为错误答复耽误了签约进度，还造成了客户信任损失。你去后台排查，发现原文档的条款完整无误，就是固定长度切块，把一条完整规则拆成了两段，召回只命中了前半截，大模型基于残缺信息给出了错误答案。问题出在哪？他想了想说，可能是文档切块方式不对。我追问，对，那你怎么保证长文档里的完整规则、连贯逻辑不被切块拆碎？难道所有文档都整段传入，不做拆分？他开始支支吾吾，面试到这就结束了。

Speaker 1 00:01:15 这正是RAG落地的幽灵陷阱。你以为多堆文档，调调切块大小，就是生产级RAG，却没想到语义切块断裂，上线微碎片会让大模型输出片面甚至错误的结论，直接造成业务损失。如果这道题你也不会回答的话，我整理了让大厂面试官沉默的必考题库，涵盖大模型基础面试、RAG、微调、Transformer、DeepSeek、Agent、项目方案面试题等等。只要是我粉丝，留下PDF，直接打包带走。Nice。为什么这个问题能筛出高手？因为它考察的不是会不会搭RAG基础链路，而是有没有深入理解语义完整性在检索增强场景下的挑战。一个能真正驾驭生产级RAG的开发，必须建立三层防御。第一层业务分级，区分高风险与普适场景。高风险场景，对于法务条款、财务规则、合规制度这类逻辑强关联。错漏后果严重的内容，强制采用父子块加语义切块方案。完整规则段落作为父块，细粒度子块用于语义召回，命中后自动映射回完整父块传入大模型，比如合同条款、报销制度、合规准则这类内容。普适场景，对于产品说明、通用知识库、常见问题解答这类容错率高的内容，采用常规固定长度切块即可，比如普通功能操作指南，信息略有缺失也不影响核心使用。

Speaker 1 00:02:46 第二层检索兜底与完整性校验。对召回的文档片段做语义边界校验，如果发现片段是段落中间截断，语义不完整的，自动扩展读取该片段的前后文内容，补全完整语义单元后再送入大模型。高风险问题二次校验。涉及法务、财务类的查询，召回结果生成答案后，自动和对应文档的完整章节做匹配度核对，信息覆盖率不足则触发补充召回。高频标准问题缓存，经过校验的标准答案在应用层做缓存，避免重复检索，反复出现碎片化问题。第三层架构层优化，缩小语义断裂风险。多级切块策略，同一份文档同时生成章节级粗粒度切块和短句级细粒度切块两套向量，检索时先通过粗粒度定位完整章节，再在章节内做细粒度匹配。从根源保证上下文完整，结构化文档解析。对有明确标题层级的Word、PDF文档，优先按原生章节条款结构拆分，不强行按字符长度切割，保留原生语义单元，强制完整上下文开关，在项目投标、合同谈判等高风险时段开启，所有召回内容必须匹配完整语义单元后再生成答案，宁可牺牲一点检索响应速度，也要杜绝残缺信息入库。

Speaker 1 00:04:11 这个就叫专业。所以这道题考的是什么？它考的是你有没有从回调RG参数升级为设计语义完整性方案的工程思维。普通开发以为RAG就是文档切块加向量检索，而高级工程师知道，在答案准确性面前，RAG是一把双刃剑。

11.5 关键截图

11.5.1 第一层：业务分级（高风险与普适场景）

img

11.5.2 第二层：检索兜底与完整性校验

img

📄 来源：043_面试官：RAG查询改写怎么设计？多轮对话下检索不准怎么落地？.md

12 面试官：RAG查询改写怎么设计？多轮对话下检索不准怎么落地？

12.1 视频信息

项目 内容
视频名称 面试官：RAG查询改写怎么设计？多轮对话下检索不准怎么落地？
时长 4分29秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7664567890123456789
飞书妙记 https://www.feishu.cn/minutes/obcnh51zmdhzow8xd29ylqnb
关键词 RAG、查询改写、多轮对话、意图理解、指代消解、相似度校验、缓存、降级直检

12.2 全文摘要

本视频讲解RAG查询改写在多轮对话场景下的设计与落地。常见错误回答是"把用户原话直接丢去向量检索，靠大模型自己理解上下文"。真正的高级RAG工程师需具备三层核心认知：第一层，查询改写方案深度拆解（原生直检/规则改写/大模型单轮改写/多轮上下文补全，各自在不同场景下的优缺点，重点核查边界控制、多轮历史代入、高频缓存）；第二层，改写效果量化与风险兜底（意图匹配准确率/召回命中率/改写耗时/偏离原意率，相似度校验或规则拦截，原Query+改写Query多路召回互补，触发阈值解耦准确率与成本）；第三层，生产落地规范（改写场景准入标准、高风险禁用规则、最大改写次数、超时阈值、热点缓存预热、压测回归监控）。

12.3 原文结构化整理

12.3.1 面试题背景与常见错误回答

面试题：线上RAG承接用户多轮对话咨询，提问口语化、指代省略多，怎么保证用户真实意图被准确检索到？

常见错误回答：把用户原话直接丢去向量检索，靠大模型自己理解上下文就行。

面试官追问（暴露漏洞）： - 多轮指代消解与意图补全，具体怎么落地？ - 改写过度偏离原意图，改写不足召回不准，如何平衡？ - 高并发下每次查询都走大模型改写，算力飙升怎么兜底？ - 遇到过用户提问指代不清导致召回完全跑偏的线上问题吗？

候选人的回答：目前只能靠加长系统提示词，引导用户把问题说清楚保底。

核心分水岭：这道题考察的不是会不会调用向量库检索接口，而是查询侧的意图理解、效果与成本平衡的核心能力。测试环境单轮清晰提问和线上口语化多轮对话场景完全是两个技术维度，不能混为一谈。

12.3.2 第一层：查询改写方案的深度拆解与对比

常见的四种模式，不能停留在概念背诵，要拆解各自在不同场景下的优缺点：

方案 适用场景 风险点
原生直检 单轮精准提问 多轮对话场景极易出现召回偏离
规则改写 简单单轮问答 意图识别不准风险
大模型单轮改写 口语化咨询 改写过度偏离原意图
多轮上下文补全 多轮指代省略 多轮历史代入引入无关信息，检索方向持续偏移

重点核查三个维度： 1. 改写的边界控制：是否有校验机制，而非无限制发散扩写 2. 多轮历史代入：是否会引入无关信息，导致检索方向持续偏移 3. 高频相似Query缓存：是否有改写结果缓存，避免重复调用大模型消耗算力

12.3.3 第二层：改写效果量化与风险兜底

拒绝凭感觉说"能搜到"，重点看量化指标。

核心量化指标： - 意图匹配准确率 - 召回命中率 - 改写平均耗时 - 偏离原意率 - 改写失效时的原生直检降级策略对照

核心业务场景逐一核对： 1. 改写偏离的兜底机制：是相似度校验还是规则拦截？改写过度导致答非所问的风险有多高？ 2. 多路召回互补：是否引入原Query+改写Query的多路召回互补？ 3. 触发阈值：改写触发阈值能否把检索准确率与推理成本解耦？

方案区分： - 简单单轮问答场景：用原生Query直接检索兜底再优化 - 无改写、无意图补全的方案：多轮对话场景极易出现召回偏离

12.3.4 第三层：查询改写体系的生产落地规范

  1. 建立改写场景准入标准 - 制定高风险场景禁用改写规则 - 单Query最大改写次数 - 改写超时阈值红线 - 高频热点Query自动缓存预热

  2. 借助工具完成全链路保障 - 改写链路压测 - 模糊提问效果回归 - 改写准确率与耗时监控 - 咨询高峰时段重点复核 - 智能客服工单答疑、技术支持等高对话量模块

  3. 沉淀团队知识 - 沉淀RAG事故复盘知识点与防御性编码约束 - 整理规范提示词喂给AI - 让AI生成的RAG代码原生携带改写校验、降级直检、结果缓存逻辑 - 禁止任何无效果校验、无成本控制的查询改写直接上线

核心总结：这道题核心就是从直接调用检索接口升级为全链路查询意图治理体系。普通开发只要能把提问丢去检索、返回结果就满足；高级工程师从用户输入、意图理解、检索召回全链路挖掘偏离隐患，在业务容忍度内做好效果与成本的平衡保障。

12.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 今天面挂了一个2年经验的大模型应用工程师。我问他，你们线上RAG承接用户多轮对话咨询，提问口语化，指代省略多，怎么保证用户真实意图被准确检索到？他直接说，把用户原话直接丢去向量检索，靠大模型自己理解上下文就行。我再追问，多轮指代消解与意图补全，具体怎么落地？改写过度偏离原意图，改写不足，召回不准，如何平衡？高并发下，每次查询都走大模型改写，带来的算力飙升怎么兜底？你遇到过用户提问指代不清，导致召回完全跑偏的线上问题，能不能划个时间线还原一下？他瞬间愣住了，迟疑了半天说。目前只能靠加长系统提示词，引导用户把问题说清楚保底。

Speaker 1 00:00:45 面试到这里，基本就可以结束了。这正是普通大模型开发和高级RAG工程师的核心分水岭。它考察的不是会不会调用向量库检索接口，而是查询侧的意图理解、效果与成本平衡的核心能力。如果这道题你也不会回答的话，我整理了让大厂面试官沉默的必考题库，涵盖大模型基础面试、RAG、微调、Transformer、DeepSeek。agent、项目方案、面试题等等，只要是我粉丝，留下PDF，直接打包带走。Nice。

Speaker 1 00:01:20 很多大模型开发者都有一个误区，觉得把用户提问直接传入检索就是做好RAG，但大家忽略了一点，测试环境单轮清晰提问和线上口语化多轮对话场景完全是两个技术维度，不能混为一谈。一个能胜任高级岗位的RAG工程师必须具备三层核心认知。第一层，查询改写方案的深度拆解与对比。常见的原生直检、规则改写、大模型单轮改写、多轮上下文补全模式，不能停留在概念背诵，要拆解它们各自在单轮精准提问、口语化咨询、多轮指代省略、专业术语模糊查询场景下的优缺点。重点核查改写的边界控制是否有校验机制，而非无限制发散扩写。核查多轮历史代入是否会引入无关信息，导致检索方向持续偏移。核查高频相似query是否有改写结果缓存。避免重复调用大模型消耗算力。

Speaker 1 00:02:20 第二层，改写效果量化与风险兜底，拒绝凭感觉说能搜到，重点看意图匹配准确率、召回命中率、改写平均耗时、偏离原意率的量化指标，以及改写失效时的原生直检降级策略对照。核心业务场景逐一核对改写偏离的兜底机制，是相似度校验还是规则拦截？改写过度导致答非所问的风险有多高？核对是否引入原Query加改写Query的多路召回互补？核对改写触发阈值能否把检索准确率与推理成本解耦？你要能精准区分可用方案。简单单轮问答场景用原生query直接检索兜底再优化，方案存在意图识别不准风险。方案无改写，无意图补全，多轮对话场景极易出现召回偏离。

Speaker 1 00:03:11 第三层，查询改写体系的生产落地规范，建立改写场景准入标准，制定高风险场景禁用改写规则、单query最大改写次数、改写超时阈值红线、高频热点query自动缓存预热。借助工具完成改写链路压测、模糊提问效果回归、改写准确率与耗时监控、咨询高峰时段重点复核、智能客服工单答疑、技术支持等高对话量模块，沉淀团队RAG事故复盘知识点与防御性编码约束。整理规范提示词喂给AI。

Speaker 1 00:03:48 让AI生成的RAG代码原生携带改写校验、降级直检、结果缓存逻辑，禁止任何无效果校验、无成本控制的查询改写直接上线。这个就叫专业。这道题核心就是从直接调用检索接口升级为全链路查询意图治理体系。普通开发只要能把提问丢去检索，返回结果就满足。高级工程师从用户输入、意图理解、检索召回全链路挖掘偏离隐患，在业务容忍度内做好效果与成本的平衡保障。最后你们做RAG查询优化踩过哪些大坑？有没有遇到过改写跑偏导致。完全答非所问的线上事故，大家一起交流下。

12.5 关键截图

12.5.1 第二层：改写效果量化与风险兜底

img

12.5.2 第三层：查询改写体系生产落地规范

img

📄 来源：046_两年大模型经验，被一个 “RAG 检索漏答” 问题干沉默了….md

13 两年大模型经验，被一个"RAG检索漏答"问题干沉默了…

13.1 视频信息

项目 内容
视频名称 两年大模型经验，被一个"RAG检索漏答"问题干沉默了…
时长 5分27秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7668901234567890123
飞书妙记 https://www.feishu.cn/minutes/obcnh5465e1g4jljv187o52z
关键词 RAG、检索漏答、召回率、多路混合召回、交叉编码器、父子切片、语义改写、OCR、非结构化文档

13.2 全文摘要

本视频以面试题形式深入解析RAG检索漏答（召回率优化）问题。常见错误回答是"切片切短一点+TopK设大一点"。真正的方案分三层：第一层明确检索失效根源（切片截断、单一向量检索、口语化与书面化语义鸿沟、非结构化文档盲区）；第二层多路混合召回（向量语义+关键词全文+元数据过滤三路）+交叉编码器重排序，辅以多级父子切片、语义改写、文档结构化预处理；第三层生产异常处理（答案跨切片用父子关联+相邻拼接、非结构化文档前置OCR流水线、召回噪声设相关性阈值、监控告警、降级方案）。

13.3 原文结构化整理

13.3.1 面试题背景与常见错误回答

面试题：用户提问的答案明明就在知识库文档里，系统却检索不到对应片段，最终答非所问。如何保证相关文档精准召回，不漏掉关键答案？

常见错误回答：把切片切短一点，同时把召回TopK设大一点，多返回几段文档总能命中。

面试官追问（暴露漏洞）： - TopK设大容易引入大量无关片段，反而干扰大模型判断，甚至把错误答案排在前面 - 切片粒度一刀切，答案刚好被切分到两个片段中间，两边都检索不到完整信息 - 用户口语化提问，文档里是专业书面表达，向量相似度得分很低排不到召回列表 - 高精准度场景不允许靠堆召回数量凑命中率，有没有不靠加大TopK的方案？ - 知识库全是扫描件、图片版PDF这类非结构化文档，没法直接切片向量化怎么办？

13.3.2 第一层：检索失效的范围和根源场景

检索不准不是简单相似度不够，而是切片、召回、匹配全链路的缺陷叠加：

根源 具体问题
切片粒度不合理 答案被截断，上下文丢失
单一向量检索 无法兼顾关键词精确匹配
语义鸿沟 口语化提问与书面化文档的语义表达差异降低匹配度
非结构化文档 无法提取有效文本，导致检索盲区

13.3.3 第二层：核心方案——多路混合召回+交叉编码器重排序

最可靠基线：多路混合召回 + 交叉编码器重排序

三路召回：

召回方式 维度 作用
向量语义检索 语义匹配 捕捉语义相近但字面不同的内容
关键词全文检索 精确字词匹配 捕捉专业术语、精确名称
元数据过滤 属性筛选 按时间、来源、类别等过滤

辅助措施： 1. 多级父子切片：粗粒度切片保证上下文完整，细粒度切片保证检索精准；召回时先命中细粒度片段，再关联父片段补全上下文 2. 语义改写：用户提问进入检索前先做查询改写，将口语化表述转化为文档风格的专业表达，缩小语义鸿沟

13.3.4 第三层：生产落地异常处理细节

异常场景 处理方案
答案跨切片 父子切片关联+相邻片段拼接机制，命中子片段后自动拼接前后文，保证答案语义完整
非结构化文档 前置OCR与文档解析流水线，自动提取图片、扫描件中文本，保留页码、段落位置等元数据，检索时可溯源
召回噪声 设置相关性阈值，重排序后得分低于阈值的片段直接丢弃，宁可少召回也不引入干扰信息；极端问题触发兜底全文检索
监控告警 监控召回命中率、首条准确率、平均召回耗时，指标异常自动告警
降级方案 重排序服务不可用时，降级为基础向量检索+关键词加权策略，配合大模型自行判断片段相关性

核心考察点：能不能识别切片截断、语义鸿沟、非结构化文档等真实场景？知不知道不依赖加大召回数量如何实现精准召回？有没有多路混合召回、重排序、多级切片等工程落地经验？

13.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 你说你落地过企业级RAG知识库系统，那我问你，用户提问的答案明明就在知识库文档里，系统却检索不到对应片段，最终答非所问。你的方案如何保证相关文档精准召回，不漏掉关键答案？刚面了一个两年经验的大模型开发，我问他RAG召回率优化看似简单，但要考虑文档切片不合理、单一检索方式偏差、专业术语匹配失效、多格式文档兼容等场景，从向量库调参到多路召回怎么设计？他想了一下说，把切片切短一点，同时把召回TopK设大一点，多返回几段文档总能命中。

Speaker 1 00:00:37 我顺着他的话继续问，TopK设大很容易引入大量无关片段，反而干扰大模型判断，甚至把错误答案排在前面，这个防御算不算你的优化方案？如果切片粒度一刀切，答案刚好被切分到两个片段中间，两边都检索不到完整信息，漏检问题怎么根治？如果TopK和切片都没问题，但用户用口语化提问，文档里是专业书面表达。

Speaker 1 00:01:02 向量相似度计算得分很低，排不到召回列表里，你怎么处理？如果业务场景要求高精准度，不允许靠堆召回数量凑命中率，你有没有不靠加大TopK的召回优化方案？比如关键词与向量混合检索，它的优缺点是什么？如果知识库全是扫描件、图片版PDF这类非结构化文档，没法直接切片向量化，你怎么办？他瞬间慌了，说可以把TopK再设大一点，然后说不行就把文档再切碎一点。但问到非结构化文档的检索落地方案，完全没思路。面试到这里基本就可以结束了，这正是会调向量库参数和。

Speaker 1 00:01:39 能设计高召回RAG系统的关键分水岭，很多人以为加大TopK。切细切片就解决了检索不准，但一遇到答案跨切片，语义不匹配，非结构化文档，这些生产环境真问题就崩了。如果这道题你也不会回答的话，我整理了让大厂面试官沉默的必考题库，涵盖大模型基础面试、RAG、微调、Transformer、DeepSeek、Agent、项目方案面试题等等，只要是我粉丝，留下666，直接打包带走。Nice。

Speaker 1 00:02:12 面试官问这个问题，考察的不是你会不会往向量库存文档，而是你在任意文档格式、任意提问方式下，都保证关键答案能被精准召回。真正能通过面试的召回优化设计，必须吃透三层核心逻辑。第一层，先明确检索失效的范围和根源场景。检索不准不是简单相似度不够，而是切片、召回、匹配全链路的缺陷叠加。切片粒度不合理导致答案被截断，上下文丢失。单一向量检索无法兼顾关键词精确匹配，口语化提问与书面化文档的语义鸿沟降低匹配度，非结构化文档无法提取有效文本，导致检索盲区。

Speaker 1 00:02:53 第二层，选一套核心方案落地多场景。以多路混合召回加交叉编码器重排序为最可靠基线。辅以多级切片、语义改写、文档结构化预处理，同时启用向量语义检索、关键词全文检索、元数据过滤三路召回，分别从语义匹配、精确字词匹配、属性筛选三个维度召回候选片段，结果去重后送入交叉编码器做精细化相似度排序，过滤低相关片段，保留高精准结果。

Speaker 1 00:03:26 文档采用父子级切片方案。粗粒度切片保证上下文完整，细粒度切片保证检索精准。召回时先命中细粒度片段，再关联父片段补全上下文。用户提问进入检索前，先做查询改写，将口语化表述转化为文档风格的专业表达，缩小语义鸿沟。第三层，生产落地的异常处理细节。答案跨切片问题，通过父子切片关联加相邻片段拼接机制，命中子片段后自动拼接前后文，保证答案语义完整，不用盲目调小切片粒度。非结构化文档问题，前置OCR与文档解析流水线。自动提取图片、扫描件中的文本内容，同时保留页码、段落位置等元数据，检索时可溯源到原始文档位置。召回噪声问题，设置相关性阈值，重排序后得分低于阈值的片段直接丢弃，宁可少召回，也不引入干扰信息。极端问题可触发兜底的文档全文检索。监控召回命中率、首条准确率、平均召回耗时，指标异常自动告警。如果重排序服务不可用，业务可降级为基础向量检索加关键词加权策略，配合大模型自行判断片段相关性，保障基础可用。

Speaker 1 00:04:45 这个就叫专业。讲到这里大家就明白了，面试官问RAG检索优化，根本不是考你会不会调TOPK，核心考察三点。能不能识别切片截断、语义鸿沟、非结构化文档等真实场景？知不知道不依赖加大召回数量，如何实现精准召回？有没有多路混合召回、重排序、多级切片等工程落地经验？普通开发只会调大topk，切细切片，出问题只会说再多召回几段试试。大厂开发能徒手设计一套从文档去梳理，到多路召回到精细排序的全链路召回体系，扛得住格式混乱、表述差异、高精准要求的复杂生产场景。

13.5 关键截图

13.5.1 第一层：检索失效的根源场景

img

13.5.2 第二层：多路混合召回与交叉编码器重排序

img

📄 来源：051_面试高频真题：知识库表格和图片怎么解析？面试官高分标准答案.md

14 面试高频真题：知识库表格和图片怎么解析？面试官高分标准答案

14.1 视频信息

项目 内容
视频名称 面试高频真题：知识库表格和图片怎么解析？面试官高分标准答案
时长 10分59秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7664567890123456789
飞书妙记 https://www.feishu.cn/minutes/obcnh51q8hh58zgq5h6gnhy5
关键词 知识库、表格解析、图片解析、OCR、TSR、多模态、结构化数据、向量数据库、LayoutLMv3、DONUT

14.2 全文摘要

本视频深度解析知识库中表格和图片的处理方法，核心不是简单OCR提取文字，而是在转换过程中保留原来的结构和语义。表格属于半结构化数据，处理重点是恢复行列关系、表头、合并单元格，最终转换为Markdown/HTML/CSV等可索引格式；图片接近纯非结构化数据，处理重点是图文联合理解，识别图表类型、坐标轴、图例、数据趋势，生成结构化描述。视频通过经营数据知识库案例展示完整链路，并强调索引层需根据下游需求设计（语义问答用向量库，数值计算用关系型数据库），同时要考虑OCR置信度、解析失败重试、数据校验和结果溯源。

14.3 原文结构化整理

14.3.1 问题本质：不是OCR提取文字，而是保留结构和语义

常见错误回答：上OCR，把文字识别出来再入库。

问题所在： - 表格一旦丢了行列关系，图片一旦只剩零散文字，后面检索结果基本没法用 - OCR主要解决"图片里写了什么字"，不负责告诉你字之间是什么关系

例子： - 销售表有地区、月份、销售额三列，OCR识别出"华东、1月、120万、华南、2月、95万" - 但行列关系丢了，系统根本不知道120万对应华东还是华南，更不知道是1月还是2月 - 合并单元格更麻烦：华东区横跨三行（上海、杭州、南京），只提取文本会导致后面三个城市失去所属区域

图片同理：折线图里OCR识别出"2025年销售额、华东区"，不代表系统理解了哪条线代表华东区、横轴是什么时间、纵轴是什么单位、曲线在上升还是下降

核心：不是把表格和图片强行变成一堆文字，而是在转换过程中尽量保留它们原来的结构和语义。

档案馆比喻： | 数据类型 | 比喻 | 处理要求 | |----------|------|----------| | 普通文本 | 已写好的报告 | 管理员直接分类归档 | | 表格 | 仓库清单 | 不仅认出商品，还必须保留数量、价格、仓位 | | 图片 | 数据海报 | 除了文字，还要理解图形、箭头、图例和趋势 |

14.3.2 表格处理：核心是保证结构不丢失

有文本层的PDF： - 优先使用PDF解析工具提取内容 - 同时读取单元格坐标、行列关系和页面布局

扫描件： - 先通过OCR识别文字 - 再通过表格结构识别（TSR，Table Structure Recognition）恢复行、列、表头和合并单元格 - 最终还原成Markdown表格、HTML表格或CSV等结构化格式

输出要求： - 不能只得到一串文字，要明确记录"华东区5月订单量12万，6月订单量15万，环比增长25%" - 既能进入向量数据库做语义检索，也可以根据业务需要同步进入关系型数据库，支持排序、筛选和精确计算

14.3.3 图片处理：核心是图文语义理解

处理步骤： 1. OCR识别：图表标题、横纵坐标、图例、时间和数值单位 2. 视觉语言模型联合理解：使用LayoutLMv3、DONUT、Pix2Struct等模型，对文字位置和视觉元素进行联合理解 3. 生成结构化描述：如"华东区退款率从4月开始连续上升，6月达到近6个月最高点，与订单量增长时间基本重合" 4. 补充上下文：这张图来自哪份报告？哪一页？属于哪个章节？对应的时间范围是什么？ - 否则知识库里有很多相似图表时，模型容易把不同年份、不同区域的数据混在一起

14.3.4 真实业务案例：经营数据知识库

场景：公司搭建经营数据知识库，员工上传PDF经营报告，包含各区域订单量表格和最近6个月退款率折线图。用户提问："华东区订单量增长了，为什么退款率反而也上升了？"

处理流程： 1. 页面布局识别：判断页面里哪些区域是正文、哪些是表格、哪些是图片或图表 2. 订单量表格处理： - PDF有文本层→PDF解析提取单元格内容和布局 - 扫描件→OCR+TSR恢复结构 - 输出结构化格式，支持语义检索+精确计算 3. 退款率折线图处理： - OCR识别标题、坐标轴、图例 - 视觉语言模型理解图表类型和趋势 - 生成带上下文的结构化描述 4. 索引阶段： - 表格保留两套表示：原始结构（精确查询计算）+带表头和上下文的文本描述（向量检索） - 图片保留：原始文件地址、OCR文字、视觉语义描述、页面位置 5. 用户提问时：系统先召回订单量表格和退款率图表，再把两部分信息交给大模型综合分析，而不是只返回某一段孤立文字

14.3.5 索引层设计：根据下游需求选择存储方式

查询需求 存储方式 原因
"这张表主要讲了什么" 转换成Markdown文本→向量检索 向量检索擅长找语义相近的内容
"销售额最高的是哪个地区？环比增长率是多少？" 保留原始表格结构+关系型数据库/SQL工具 向量检索不擅长做严格的数值比较

图片解析也要看业务边界： - 普通产品截图：只需要OCR和页面描述 - 柱状图、折线图、流程图：必须识别图表类型、图例、坐标轴和关系信息

14.3.6 异常处理与工程判断

异常处理： | 异常场景 | 处理方案 | |----------|----------| | OCR置信度过低 | 不能直接写入知识库，触发更高精度模型重新识别 | | 表格结构还原失败 | 退化为按区域截取，保留原始页面截图供后续核对 | | 图表数值无法稳定读取 | 只输出趋势描述，不能编造具体数字 | | 合同金额、财务报表等高风险数据 | 增加人工抽检或规则校验，避免错误数据进入知识库后被不断召回 |

工程判断： - 不是所有表格都只存向量数据库 - 不是所有图片都要用重的多模态模型 - 根据文件复杂度选择处理路径，平衡准确率、延迟和成本

完整链路：原始文件解析 → 模态识别 → 结构或语义提取 → 标准化转换 → 索引构建 → 根据用户问题完成检索和回答

面试回答框架：知识库中的表格和图片属于非纯文本数据，不能直接按普通文本切块和向量化，需要先经过多模态预处理流水线。表格核心是保证结构不丢失（PDF解析/OCR+TSR→Markdown/HTML/CSV），图片核心是图文联合理解（OCR+LayoutLMv3/DONUT/Pix2Struct→结构化描述+上下文）。索引层根据下游需求设计（语义问答用向量库，数值计算用关系型数据库），工程上关注OCR置信度、解析失败重试、数据校验和结果溯源。

14.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。（因原文较长，此处保留核心内容）

Speaker 1 00:00:00 面试官问，知识库里的表格和图片怎么解析？很多人第一反应就是上OCR，把文字识别出来再入库。这句话不能说错，但只达到了最表面，因为表格一旦丢了行列关系，图片一旦只剩零散文字，后面的检索结果基本没法用。面试官真正想听的是你如何把非文本文件转成可检索、可理解的结构化数据。

Speaker 1 00:01:07 这道题表面上是在问文件解析，实际上考察的是你有没有做过工业级知识库的完整入库链路。普通文本可以直接切块、向量化，但表格属于半结构化数据，图片则接近纯非结构化数据，它们不能直接丢进文本切分器，更不能简单做完OCR就结束。另一方面还要看你有没有下游意识：解析出来的数据是支持关键词检索还是语义检索？表格需不需要精确计算？图片中的折线图需不需要回答趋势？

Speaker 1 00:02:11 OCR确实重要，但OCR主要解决的是图片里写了什么字，它不负责告诉你这些字之间是什么关系。比如一张销售表里有地区、月份、销售额三列，OCR可能识别出华东、1月、120万、华南、2月、95万这些文字。但如果行列关系丢了，系统根本不知道120万对应华东还是华南，更不知道是1月还是2月，合并单元格更麻烦。

Speaker 1 00:03:29 你可以把整个过程理解成档案馆整理资料。普通文本就像一份已经写好的报告，管理员直接分类归档就可以了。表格更像一张仓库清单，管理员不仅要认出清单上写了哪些商品，还必须保留每个商品对应的数量、价格和仓位。图片则像一张数据海报，除了识别海报里的文字，还要理解图形、箭头、图例和趋势到底表达了什么。

Speaker 1 00:04:21 （真实业务案例）假设公司搭建了一个经营数据知识库，员工上传了一份PDF经营报告，报告里既有一张各区域订单量表格，也有一张最近6个月的退款率折线图。用户提问，华东区订单量增长了，为什么退款率反而也上升了？系统首先要判断页面里哪些区域是正文，哪些是表格，哪些是图片或者图表。

Speaker 1 00:05:01 对于订单量表格，如果PDF本身包含可读取的文本层，可以优先使用PDF解析工具提取内容，同时读取单元格坐标、行列关系和页面布局。如果它是扫描件，就先通过OCR识别文字，再通过表格结构识别也就是TSR，恢复行、列、表头和合并单元格。最终不能只得到一串文字，而要还原成类似Markdown表格、HTML表格或者CSV这样的结构化格式。

Speaker 1 00:05:28 退款率折线图的处理重点不是表格结构，而是图文语义。系统先通过OCR识别图表标题、横纵坐标、图例、时间和数值单位，再结合视觉语言模型，例如LayoutLMv3、DONUT或者Pix2Struct，对文字位置和视觉元素进行联合理解。系统要识别这是一张折线图，横轴代表月份，纵轴代表退款率，蓝色曲线代表华东区，并进一步生成一段结构化描述。

Speaker 1 00:06:44 （索引阶段）表格可以保留两套表示，一套是原始结构用于精确查询和计算，另一套是带表头和上下文的文本描述用于向量检索。图片也要保留原始文件地址、OCR文字、视觉语义描述以及页面位置。当用户提问时，系统先召回订单量表格和退款率图表，再把两部分信息交给大模型综合分析。

Speaker 1 00:07:26 异常处理也必须考虑，如果OCR置信度过低，不能直接把错误结果写入知识库，可以触发更高精度模型重新识别。如果表格结构还原失败，可以退化为按区域截取并保留原始页面截图。如果图表中的数值无法稳定读取，就只能输出趋势描述，不能编造具体数字。对于合同金额、财务报表等高风险数据，还要增加人工抽检或者规则校验。

Speaker 1 00:08:07 还有一个很关键的工程判断，不是所有表格都只存向量数据库。如果用户只是问这张表主要讲了什么，转换成Markdown文本以后做向量检索就够了。但如果用户经常问销售额最高的是哪个地区？环比增长率是多少？就应该同时保留结构化数据，交给SQL或者计算工具处理。因为向量检索擅长找语义相近的内容，不擅长做严格的数值比较。

Speaker 1 00:08:59 （面试回答框架）知识库中的表格和图片属于非纯文本数据，不能直接按照普通文本进行切块和向量化，需要先经过一套多模态预处理流水线。对于表格，核心是保证结构不丢失。对于图片，首先使用OCR提取文字，再结合视觉语言模型进行图文联合理解。索引层需要根据下游需求设计，工程上还要关注OCR置信度、解析失败、重试、原始布局保留、数据校验和结果溯源。

Speaker 1 00:09:39 完整链路应该是原始文件解析、模态识别、结构或语义提取、标准化转换、索引构建，最后再根据用户问题完成检索和回答。这套方案适合包含扫描件、复杂表格和业务图表的企业知识库，但对于简单图片也要避免直接使用过重的多模态模型，应该根据文件复杂度选择处理路径，平衡准确率、延迟和成本。

14.5 关键截图

14.5.1 表格与图片解析核心思路

img

14.5.2 表格处理：结构化还原

img

14.5.3 图片处理：图文语义理解

img

📄 来源：053_两年大模型开发，被一个 “RAG 重复检索” 问题干沉默了….md

15 两年大模型开发，被一个"RAG重复检索"问题干沉默了…

15.1 视频信息

项目 内容
视频名称 两年大模型开发，被一个 "RAG 重复检索" 问题干沉默了…
时长 6分15秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7666789012345678901
飞书妙记 https://www.feishu.cn/minutes/obcnh5d17xip55gv3e8l315r
关键词 RAG、重复检索、语义缓存、缓存穿透、向量去重、分片一致性、多轮召回复用、语义唯一标识

15.2 全文摘要

本视频围绕RAG系统的检索一致性与成本优化面试题展开。用户同一问题连续触发两次查询，如何保证相同请求不重复做向量召回、不浪费算力、还能返回稳定一致的结果？候选人只答了前端防抖+Redis KV缓存，被追问缓存穿透、语义变体查询、向量库分片冗余、多轮对话重复召回等场景后完全没思路。真正能通过面试的RAG架构设计必须吃透三层核心逻辑：第一层明确优化范围和失效场景（重复提问、缓存穿透、分片冗余、多轮浪费、索引更新重复）；第二层以语义唯一标识+多级缓存为核心基线，辅以召回结果去重、分片路由一致性、多轮上下文复用；第三层生产落地异常处理（分布式锁防穿透、分片扩容迁移流程、缓存分层治理、监控指标、降级策略）。

15.3 原文结构化整理

15.3.1 面试问题与候选人回答

面试官问题：

用户同一个问题连续触发两次查询，你的后端如何保证相同的请求不重复做向量召回？不浪费算力，还能返回稳定一致的结果？

进一步追问场景： - 语义变体查询（"怎么申请退款" vs "退款的流程是什么"） - 缓存穿透（第一次查询还在处理，第二次请求直接穿透） - 向量库分片冗余（同一条知识在不同分片重复索引） - 多轮对话重复召回（历史已召回片段反复拉取）

候选人回答：前端做防抖+后端Redis查询缓存（问题哈希当key，缓存召回结果和生成答案，1小时过期）

被追问后暴露的问题： - 前端防抖容易绕过（直接发两次接口请求） - 缓存未写入时并发查询穿透，两个请求同时跑检索+大模型 - 语义相同但字面不同，缓存命中不了 - 向量库分片扩容导致重复召回 - 多轮对话每轮带上下文重新全量召回

这正是会调向量库API和能设计工业级RAG系统的关键分水岭。

15.3.2 第一层：明确RAG优化的范围和失效场景

优化范围：不是简单同一个字面query只查一次，而是语义相同的查询都能复用已有召回结果，返回稳定答案，不重复消耗向量检索和大模型算力。

常见失效场景：

场景 说明
用户重复提问/换说法提问 语义一致但字面不同，KV缓存命中不了
缓存未命中时并发查询穿透 第一次还在处理，第二次直接穿透，同时跑检索
向量库分片扩容导致重复召回 同一条知识在不同分片重复索引，召回出多条重复片段
多轮对话历史片段重复召回 每轮带上下文重新全量召回，已召回片段反复拉取
索引更新时新旧数据重复 更新过程中新旧版本同时存在

15.3.3 第二层：核心方案——语义唯一标识+多级缓存体系

核心基线：语义唯一标识+多级缓存体系

建立 query_semantic 表，字段： - semantic_id（语义唯一标识） - query_sign（查询签名） - embedding（向量） - recall_result（召回结果） - status（状态）

查询流程： 1. 查询到来时，先做语义相似度粗召回 2. 匹配到已有语义ID的，直接返回缓存结果 3. 未命中的，走完整向量检索流程 4. 检索完成后写入语义表和缓存

配套方案：

层面 方案
向量库层面 基于业务主键做全局唯一约束，同一条知识只索引一次；用一致性哈希做分片路由，保证单条数据只落在一个分片，从源头避免重复召回
召回结果层 基于内容指纹的去重，过滤掉相似度极高的冗余片段
多轮对话场景 维护会话级历史召回片段池，新查询只做增量召回，和历史池合并后再统一排序送入大模型

15.3.4 第三层：生产落地的异常处理细节

异常场景 处理方案
缓存穿透 分布式锁做并发控制，同个语义查询只放行一个请求走检索链路，其余请求等待结果；锁超时后靠语义表唯一约束兜底，不会重复写入
向量库分片扩容 先写新分片→再迁老数据→最后校验去重；迁移期间双读校验，保证不出现重复索引也不丢数据
缓存分层治理 高频查询做长时缓存，低频查询做短时缓存，冷数据定期清理，控制存储成本
监控指标 语义缓存命中率、召回重复率、缓存穿透次数、向量库QPS与耗时
向量库查询异常 降级为本地关键词检索+历史缓存兜底，保证基础可用性
语义表写入失败 临时降级为Redis短时效缓存，后续通过异步任务补全语义记录

面试官核心考察三点： 1. 能不能识别缓存穿透、语义重复、分片冗余、多轮浪费等真实生产场景？ 2. 知不知道不依赖简单KV缓存如何实现语义级结果复用？ 3. 有没有语义去重、多级缓存、分片治理、多轮召回复用这些工程落地经验？

普通开发套个框架加把缓存，出问题只会把过期时间设长一点。大厂开发能徒手设计一套语义级缓存+全链路召回治理的工业级RAG系统。

15.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 你说你做过RAG检索增强系统，那我问你，用户同一个问题连续触发两次查询，你的后端如何保证相同的请求不重复做向量召回？不浪费算力，还能返回稳定一致的结果？刚面了一个两年经验的大模型开发，我问他，RAG的检索一致性与成本优化看似简单，但要考虑语义变体查询、缓存穿透、向量库分片冗余、多轮对话重复召回这些场景，从查询缓存到向量去重怎么设计？他想了一下说，前端做防抖，提问后按钮禁用，同时后端用Redis做查询缓存，把问题哈希当key，缓存召回结果和生成答案，1小时后过期。

Speaker 1 00:00:49 我顺着他的话继续问，前端防抖很容易绕过，直接发两次接口请求，这个防御只靠你的缓存。如果第一次查询还在走向量召回加大模型生成，缓存还没写入，第二次请求直接穿透过来，两个请求同时跑检索，同时调用大模型，算力浪费和结果一致性怎么保证？就算缓存没问题，用户换个说法问同一个问题，比如怎么申请退款和退款的流程是什么？语义完全一致，但字面不同，缓存根本命中不了，还是要完整走一遍召回和生成，你怎么处理？如果向量库做了分片扩容，同一条知识在不同分片上重复索引，同一次查询召回出多条重复的片段，导致最终答案冗余重复，你怎么解决？你有没有考虑过不用简单KV缓存的方案？比如基于语义的唯一标识方案。

Speaker 1 00:01:31 如果业务不允许全量缓存所有用户query，存储成本扛不住，你怎么办？还有多轮对话场景，每位都带着上下文重新做全量召回，历史对话里已经召回过的片段反复拉取。既浪费算力又拖慢响应，你怎么优化？他瞬间慌了，说可以把缓存时间设长点，然后说不行的话加布隆过滤器挡一下。但问到语义相似度匹配去重、向量分片一致性、多轮召回复用方案，完全没思路。面试到这里基本就可以结束了，这正是会调向量库API和能设计工业级RAG系统的关键分水岭。

Speaker 1 00:02:06 很多人以为套个向量数据库，加个Redis缓存，就叫做好了RAG。但一遇到缓存穿透、语义重复查询、分片数据冗余、多轮召回浪费这些真问题就崩了。面试官问这个问题，考察的不是你会不会调用向量库的查询接口，而是你在各种语义变体和异常场景下，都能保证检索效率、结果一致性和算力成本可控。真正能通过面试的RAG架构设计，必须吃透三层核心逻辑。

Speaker 1 00:02:30 第一层，先明确RAG优化的范围和失效场景。RAG的检索优化不是简单同一个字面query只查一次，而是语义相同的查询都能复用已有召回结果，返回稳定的答案，不重复消耗向量检索和大模型算力。常见失效场景包括用户重复提问或换说法提问导致的重复检索、缓存未命中时的并发查询穿透、向量库分片扩容导致的重复召回、多轮对话中历史片段重复召回、索引更新时的新旧数据重复。

Speaker 1 00:03:00 第二层，选一套核心方案落地多场景。以语义唯一标识加多级缓存体系为最可靠基线，辅以召回结果去重、分片路由一致性、多轮上下文复用。建立一张query_semantic表，字段包括semantic_id、query_sign、embedding、recall_result、status。查询到来时，先做语义相似度粗召回，匹配到已有语义ID的直接返回缓存结果，未命中再走完整向量检索流程，检索完成后写入语义表和缓存。向量库层面，基于业务主键做全局唯一约束，同一条知识只索引一次，用一致性哈希做分片路由，保证单条数据只落在一个分片，从源头避免重复召回。召回结果层做基于内容指纹的去重，过滤掉相似度极高的冗余片段。多轮对话场景，维护会话级历史召回片段池，新查询只做增量召回，和历史池合并后再统一排序送入大模型。

Speaker 1 00:04:00 第三层，生产落地的异常处理细节。缓存穿透问题，分布式锁只做并发控制，同个语义查询只放行一个请求走检索链路，其余请求等待结果。锁超时后靠语义表的唯一约束兜底，不会重复写入检索结果。向量库分片扩容时，采用先写新分片，再迁老数据，最后校验去重的流程。迁移期间双读校验，保证不出现重复索引，也不丢数据。缓存分层治理，高频查询做长时缓存，低频查询做短时缓存，冷数据定期清理，控制存储成本。监控语义缓存命中率、召回重复率、缓存穿透次数、向量库QPS与耗时。如果向量库查询异常，可降级为本地关键词检索加历史缓存兜底，保证基础可用性。如果语义表写入失败，临时降级为Redis短时效缓存，后续通过异步任务补全语义记录。

Speaker 1 00:05:00 讲到这里大家就明白了，面试官问RAG系统设计，根本不是考你会不会接向量库，会不会加Redis缓存，核心考察三点。能不能识别缓存穿透、语义重复、分片冗余、多轮浪费等真实生产场景？知不知道不依赖简单KV缓存如何实现语义级结果复用？有没有语义去重、多级缓存、分片治理、多轮召回复用这些工程落地经验？普通开发套个框架加把缓存，出问题只会把过期时间设长一点。大厂开发能徒手设计一套语义级缓存加全链路召回治理的工业级RAG系统，扛得住重复查询、语义变体、分片扩容、多轮对话。

15.5 关键截图

15.5.1 第一层：先明确RAG优化的范围和失效场景

img

15.5.2 第二层：语义唯一标识+多级缓存体系

img

📄 来源：055_两年大模型经验，被一个“RAG权限越权泄露”问题干沉默了！.md

16 两年大模型经验，被一个"RAG权限越权泄露"问题干沉默了！

16.1 视频信息

项目 内容
视频名称 两年大模型经验，被一个"RAG权限越权泄露"问题干沉默了！
时长 5分48秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7668901234567890123
飞书妙记 https://www.feishu.cn/minutes/obcnh5a4yk592noagfzr4g13
关键词 RAG、权限管控、越权泄露、细粒度权限、隐式权限向量、企业级安全、检索前置过滤、生成后置校验

16.2 全文摘要

本视频围绕企业级多部门RAG知识库的权限管控面试题展开。候选人只答了"给每篇文档打部门标签，检索时按部门过滤"，被追问细粒度段落权限、动态人员调岗、诱导套取信息、跨部门数据隔离、涉密场景明文标签泄露等场景后完全没思路。真正能通过面试的权限管控设计必须吃透三层核心逻辑：第一层明确泄露来源（文档级粗粒度过滤无法适配段落级权限、人员权限变更不同步、多轮诱导拼接低权限信息推导高权限结论、明文标签元数据泄露、复杂权限体系无法用简单标签覆盖）；第二层以检索前置权限过滤+生成后置内容校验+隐式权限向量匹配为核心基线，辅以统一权限中心、细粒度分段打标、诱导攻击识别；第三层生产落地异常处理（动态权限变更秒级生效、诱导套取安全意图识别、复杂多维度权限双校验、监控告警、降级策略）。

16.3 原文结构化整理

16.3.1 面试问题与候选人回答

面试官问题：

不同职级、不同部门的员工只能查看权限内的文档，你的系统如何保证检索和生成全程不越权？绝对不会把敏感文档内容泄露给无权限用户。

候选人回答：给每篇文档打部门标签，检索时根据当前用户所属部门做过滤，只返回对应部门的文档。

被追问暴露的问题：

追问场景 问题
同部门不同职级权限不一样，同一篇文档里有的段落普通员工不能看 单篇文档级过滤直接越权泄露
员工调岗权限变更 重新打标再入库？权限变更不能实时生效，窗口期就是安全漏洞
用户通过诱导提问，让模型把多篇低权限文档信息拼接推导出高权限结论 检索层没越权，但生成层泄露敏感信息
涉密知识库不允许在向量库存明文权限标签 怕元数据本身泄露分级信息，需要隐式权限匹配
多维度角色、多级密级、临时授权 简单标签根本装不下复杂权限体系

这正是会做单租户RAG和能设计企业级安全RAG的关键分水岭。

16.3.2 第一层：明确权限泄露的来源和失效场景

权限越权不是简单返回了不该看的文档，而是检索、生成、交互全链路的安全漏洞叠加。

失效场景 说明
文档级粗粒度过滤 无法适配段落级细粒度权限
人员权限变更不同步 存在数据泄露窗口期
用户多轮诱导拼接 低权限信息拼接推导高权限结论
明文权限标签 元数据本身泄露分级信息
多维度复杂权限体系 无法用简单标签覆盖

16.3.3 第二层：核心方案——全链路权限管控

核心基线：检索前置权限过滤 + 生成后置内容校验 + 隐式权限向量匹配

层面 方案 说明
检索层 对接统一权限中心 拉取用户当前全量权限维度，在向量检索阶段同时做权限条件过滤，前置拦截所有无权限文档片段
生成层 新增权限校验模块 输出答案前逐句比对内容密级与用户权限，识别到越权内容直接脱敏或替换，防止多片段拼接推导泄露
涉密场景 权限向量隐式匹配 将权限等级编码为隐式向量，嵌入到文档片段向量中。检索时同步匹配用户权限向量，全程不出现明文权限标签，避免元数据泄露
细粒度管控 段落级权限打标 同一文档不同片段可设置不同密级，实现最小粒度管控

16.3.4 第三层：生产落地的异常处理细节

异常场景 处理方案
动态权限变更 权限中心变更后实时同步检索过滤规则，无需重新向量化文档，秒级生效，关闭变更窗口期
诱导套取 新增安全意图识别模块，识别套取敏感信息的提问模式，直接拦截高危提问；生成阶段限制跨权限信息推理
复杂多维度权限 权限标签与向量双校验，标签做快速粗过滤，权限向量做精准细校验，兼顾性能与安全
监控告警 监控越权拦截次数、权限变更同步延迟、生成层泄露拦截量，指标异常自动告警
权限中心故障 降级为仅返回公开级文档，禁止返回所有内部敏感内容——宁可不答，也绝不越权

面试官核心考察三点： 1. 能不能识别细粒度泄露、动态变更滞后、诱导式套取等真实安全场景？ 2. 知不知道不靠明文标签如何实现隐式权限管控？ 3. 有没有前置过滤、后置校验、细粒度打标等工程落地经验？

普通开发只会加部门标签做过滤，出问题只会说再加个权限标签就行了。大厂开发能徒手设计一套从检索到生成再到变更的全链路权限管控体系。

16.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 你说你落地过企业级多部门RAG知识库系统，那我问你，不同职级、不同部门的员工只能查看权限内的文档，你的系统如何保证检索和生成全程不越权？绝对不会把敏感文档内容泄露给无权限用户。今天面了一个两年经验的大模型开发，我问他RAG权限管控设计看似简单，但要考虑细粒度文档权限、动态人员调岗、诱导套取信息、跨部门数据隔离等场景，从元数据过滤到访问控制怎么设计？他想了一下说，给每篇文档打部门标签，检索的时候根据当前用户所属部门做过滤，只返回对应部门的文档就行。

Speaker 1 00:00:44 我顺着他的话继续问，粗粒度部门过滤根本满足不了企业需求。比如同部门不同职级权限不一样，甚至同一篇文档里有的段落普通员工不能看，单篇文档级过滤直接越权泄露。如果员工调岗权限变更，难道要把所有文档重新打标再入库一遍？权限变更不能实时生效，窗口期就是安全漏洞。如果标签过滤没问题，但用户通过诱导提问，让模型把多篇低权限文档的信息拼接推导出高权限结论，检索层没越权，但生成层泄露了敏感信息。如果业务场景是涉密知识库，不允许在向量库里存明文权限标签，怕元数据本身泄露分级信息，你有没有不靠明文标签的权限管控方案？比如权限向量隐式匹配，它的优缺点是什么？如果权限体系本身很复杂，有多维度角色、多级密集、临时授权，简单标签根本装不下，你怎么办？

Speaker 1 00:01:59 他瞬间慌了，说可以把标签维度加细一点，说不行就生成的时候再人工审核一遍。但问到隐式权限匹配与生成层越权防控方案完全没思路。面试到这里基本就可以结束了，这正是会做单租户RAG和能设计企业级安全RAG的关键分水岭。

Speaker 1 00:02:26 面试官问这个问题，考察的不是你会不会加过滤条件，而是你在复杂权限体系下，保证检索不越权、生成不泄露、变更可实时。真正能通过面试的权限管控设计，必须吃透三层核心逻辑。

Speaker 1 00:02:45 第一层，先明确权限泄露的来源和失效场景。权限越权不是简单返回了不该看的文档，而是检索、生成、交互全链路的安全漏洞叠加。文档级粗粒度过滤无法适配段落级细粒度权限，人员权限变更不同步，存在数据泄露窗口期。用户通过多轮诱导拼接低权限信息，推导高权限结论。明文权限标签存在元数据泄露风险，多维度复杂权限体系无法用简单标签覆盖。

Speaker 1 00:03:16 第二层，选一套核心方案落地全链路管控，以检索前置权限过滤加生成后置内容校验加隐式权限向量匹配为最可靠基线，辅以统一权限中心。细粒度分段打标，诱导攻击识别。检索层对接统一权限中心，拉取用户当前全量权限维度，在向量检索阶段同时做权限条件过滤，前置拦截所有无权限文档片段。生成层新增权限校验模块，输出答案前逐句比对内容密集与用户权限，识别到越权内容直接脱敏或替换，防止多片段拼接推导泄露。涉密场景采用权限向量方案，将权限等级编码为隐式向量，嵌入到文档片段向量中。检索时同步匹配用户权限向量，全程不出现明文权限标签，避免元数据泄露。文档支持段落级权限打标，同一文档不同片段可设置不同密级，实现最小粒度管控。

Speaker 1 00:04:16 第三层，生产落地的异常处理细节。动态权限变更问题，权限中心变更后实时同步检索过滤规则，无需重新向量化文档，秒级生效，关闭变更窗口期。诱导套取问题，新增安全意图识别模块，识别套取敏感信息的提问模式，直接拦截高危提问。同时生成阶段限制跨权限信息推理。复杂多维度权限场景，采用权限标签与向量双校验，标签做快速粗过滤，权限向量做精准细校验，兼顾性能与安全。监控越权拦截次数、权限变更同步延迟、生成层泄露拦截量，指标异常自动告警。如果权限中心故障，业务可降级为仅返回公开级文档，禁止返回所有内部敏感内容，宁可不答，也绝不越权。

Speaker 1 00:05:09 讲到这里大家就明白了，面试官问RAG权限管控，根本不是考你会不会加元数据过滤，核心考察三点。能不能识别细粒度泄露、动态变更滞后、诱导式套取等真实安全场景？知不知道不靠明文标签如何实现隐式权限管控？有没有前置过滤、后置校验、细粒度打标等工程落地经验？

16.5 关键截图

16.5.1 第一层：权限泄露的来源和失效场景

img

16.5.2 第二层：全链路权限管控方案

img

16.5.3 第三层：生产落地的异常处理

img

📄 来源：063_大模型面试，RAG的Query改写怎么答？能让面试官眼前一亮.md

17 大模型面试，RAG的Query改写怎么答？能让面试官眼前一亮

17.1 视频信息

项目 内容
视频名称 大模型面试，RAG的Query改写怎么答？能让面试官眼前一亮
时长 2分56秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7660837015446298021
飞书妙记 https://www.feishu.cn/minutes/obcniu984t31v32xjki4ced2
关键词 RAG、Query改写、规则改写、NLP改写、大模型改写、语义补全、召回率、跨轮对话

17.2 全文摘要

本视频讲解了RAG面试中Query改写这一实战试金石题目。核心观点是：很多人一聊RAG头头是道，一问Query改写当场卡壳，因为这不是概念题而是实战题；真正决定RAG效果上限的往往不是向量库，而是Query改写。 视频详细对比了三种主流方案：规则改写（最笨但最稳，关键词补全、同义词替换，适合固定场景快速启动）、传统NLP改写（实体识别、同义词扩展、上下文融合，效果比规则强但换行业需重训）、大模型改写（企业最主流，具备理解上下文、拓展召回、标准化表达三大能力）。强调成熟项目打的是组合拳：规则兜底、轻量模型批量处理、大模型负责复杂语义理解。Query改写的本质不是改字，而是增强问题的表达能力，把用户模糊的自然语言变成系统容易召回的标准语言。

17.3 原文结构化整理

17.3.1 为什么Query改写是RAG实战试金石

面试定位：30秒内判断你是真做过项目还是只看过教程

核心问题：用户提的问题和知识库里的内容根本不是一个语言体系 - 用户说的像聊天（"怎么报销？"） - 知识库写的像制度（差旅报销流程、项目经费审批、采购报销规定） - 中间断掉的桥靠Query改写来补

本质定义：把用户模糊的问题翻译成机器能理解、能检索、能匹配的标准问题

核心金句：改不好，召回就歪了；召回一歪，答案就废了。很多人以为RAG核心是向量库，其实真正决定效果上限的往往就是Query改写。

17.3.2 三种主流改写方案对比

方案 技术手段 优点 缺点 适用场景
规则改写 关键词补全、同义词替换、词表映射 快，今天立项明天上线 覆盖范围有限，复杂问题顶不住 固定场景快速启动
传统NLP改写 实体识别、同义词扩展、上下文融合 效果比规则强一大截，速度快成本低 换行业要重新训练，强上下文问题经常懵 大规模搜索场景
大模型改写 LLM语义理解与生成 理解上下文、拓展召回、标准化表达 成本相对较高 企业级复杂场景（最主流）

17.3.3 大模型改写的三大核心能力

  1. 理解上下文（跨轮语义补全） - 用户问"他是谁？"，上一轮提到马斯克 - 大模型直接改成"马斯克是谁？"

  2. 拓展召回（多查询生成） - 用户问"FDE需要什么技能？" - 大模型一次拆出多个检索问题：技能要求是什么？技术门槛有哪些？需不需要懂模型？ - 一次搜索变成多次搜索，召回率直接拉满

  3. 标准化表达 - 用户问"豆包是字节的吗？" - 系统自动改成"豆包大语言模型是否是由字节跳动开发？" - 问题瞬间规范，知识库匹配率大幅提升

17.3.4 企业级组合拳与面试总结

成熟项目的组合策略： - 规则负责兜底 - 轻量模型负责批量处理 - 大模型负责复杂的语义理解和补全

面试一句话总结：

Query改写的本质不是改字，而是增强问题的表达能力，把用户模糊的自然语言变成系统容易召回的标准语言，提升召回率、提升准确率、提升最终的回答质量。

17.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00.160

RAG 面试里面有一道题，能在 30 秒内判断你到底是真做过项目呢？还是只看过教程？这道题呢，就是 query 改写。很多人一聊 RAG 聊得头头是道，一问 query 改写，当场就卡壳。因为呢，这不是概念题，这是实战题。你项目干没干过，面试官一听就知道。为什么它这么重要？因为用户提的问题和知识库里的内容根本不是一个语言体系。举个例子，用户上来一句，怎么报销？诶，你觉得很简单，其实对系统来说呢，这简直就是一道送命题。报销什么？什么是差旅报销？还是项目经费？还是采购报销？要在哪里提交？审批流程是什么？用户说的像聊天，那知识库呢，又写的又像制度，中间这条断掉的桥靠谁来补？就是 query 改写。说白了， query 改写干的就是一件事，就是把用户模糊的问题翻译成机器能理解、能检索、能匹配的标准问题。改不好，召回就歪了，召回一歪，诶，答案就废了。所以很多人以为 rag 核心是向量库，其实真正决定效果上限的往往就是 query 改写。面试的时候呢，你一定要讲这三种主流方案。

Speaker 1 00:01:03.050

第一种规则改写，最笨，但是最稳，关键词补全呐，同义词替换呐，词表映射。优点呢，就一个字，快，系统今天立项，明天就能上线。缺点也明显，覆盖范围有限，问题稍微复杂一点呢，就顶不住。适合固定场景的快速启动。第二种，传统的 NLP 改写，通过实体的识别、同义词扩展、上下文融合来优化问题，效果比规则要强一大截，速度快、成本低，适合大规模的搜索场景。但是问题也很明显，它换个行业就要重新训练，遇到他是谁？那个产品怎么样？这种强上下文的问题，经常就直接懵掉。

Speaker 1 00:01:37.800

那第三种也是现在企业最主流的打法，大模型改写，这也是面试官最想听的，它最强的地方呢，有三个。第一，理解上下文。用户问他是谁？上一轮提到马斯克，那大模型就会直接改成马斯克是谁？这叫跨轮语义补全。那第二，落拓展召回。用户问 FDE 需要什么技能？大模型一次能拆出好几个检索的问题，技能要求是什么？技术门槛有哪些？需不需要懂模型？那相当于一次搜索变成了多次搜索。召回率直接拉满。

Speaker 1 00:02:07.680

第三，标准化表达。用户问，豆包是字节的吗？系统自动改成豆包大语言模型是否是由字节跳动开发？问题呢，瞬间就规范了，知识库匹配率也会大幅的提升。所以现在成熟的项目里面呢，基本都是打的组合拳，规则负责兜底，轻量模型负责批量处理，大模型负责复杂的语义理解和补全。那最后面试总结就一句话， query 改写的本质不是改字，而是增强问题的表达能力，把用户模糊的自然语言变成系统容易召回的标准语言，提升召回率、提升准确率、提升最终的回答质量。诶，你能讲到这里，面试官基本就知道，嗯，这个人不是只看过视频，是真的做过项目。那最后呢，我也整理了一份大厂进阶 AI 大模型的系统学习路线，里面包含了 15 个模块。从微调、rag、 agent 模型部署到企业级项目实战，都给你拆好了，有需要的可以去看一下。

注：本视频为纯口播，无PPT/架构图等有价值截图。

📄 来源：068_RAG系统中的Query改写技术全解析，8分钟带你搞懂！.md

18 RAG系统中的Query改写技术全解析，8分钟带你搞懂！

18.1 视频信息

项目 内容
视频名称 RAG系统中的Query改写技术全解析，8分钟带你搞懂！
时长 8分57秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7660837015446298021
飞书妙记 https://www.feishu.cn/minutes/obcniu1km822nxaoxgc81znm
关键词 RAG、Query改写、HyDE、任务分解、上下文补全、语义鸿沟、意图路由、异步并行、量化评估

18.2 全文摘要

本视频系统解析了RAG系统中Query改写这一核心技术。核心观点是：Query改写不是简单的同义词替换，而是架构层面的协议转换——把用户口语化的表达翻译成知识库能理解的结构化声明式指令。 视频首先剖析了原始Query无法直接检索的三大原因（语义鸿沟、意图模糊、上下文断层），然后对比了三大核心技术路径：语义增强型（HyDE，生成假设性答案进行向量匹配）、任务分解型（Step-back Prompting，将复杂问题拆解为原子子查询）、上下文补全型（多轮对话中指代消歧与脱水）。工程落地部分讲解了如何通过异步并行架构突破2秒延迟法则，以及如何通过意图路由（Intent Routing）控制全量改写的成本。最后强调必须建立基于Ground Truth的量化评估闭环，通过Bad Case持续反哺Prompt微调。

18.3 原文结构化整理

18.3.1 为什么原始Query无法直接检索

直接拿用户原话去搜索，问题通常卡在三点：

问题 英文术语 具体表现
语义鸿沟 Semantic Gap 用户说大白话（"这个怎么弄？"），知识库全是规范化专业文档，两者在向量空间完全不在一个频道，匹配度低
意图模糊 Ambiguity 用户提问经常省掉背景（"帮我优化一下"），模型不知道是优化代码还是优化模型参数，结果南辕北辙
上下文断层 Context Loss 多轮对话中用户说"刚才提到的那个到底是什么？"，代词没有还原成真实实体，检索系统像失忆一样

18.3.2 Query改写的本质：协议转换而非同义词替换

常见误解：改写就是简单替换几个词

真正本质：在中间处理层做的是协议转换 - 用户输入："报错了，帮我看一下"（人的表达方式） - 知识库需要：明确的意图和实体（结构化检索指令） - 中间环节：把不确定的口语化表达翻译成检索系统一眼能看懂的声明式指令

核心定义：Query改写的本质是将用户原始输入转化为"检索友好型"声明式描述的过程。架构层面的协议转换，非简单同义词替换。

18.3.3 三大核心技术路径选型矩阵

维度 语义增强型（HyDE） 任务分解型（Decomposition） 上下文补全型（Contextualization）
核心逻辑 生成"假设性答案"进行向量匹配 拆解原子子问题，提取抽象背景（Step-back） 引入历史对话，进行指代消歧与脱水
适用场景 跨越术语差异的复杂查询 复杂对比、多步骤分析 连续多轮对话
工程优势 显著提升复杂场景召回率 降低复杂度，提高广度覆盖 生成具备独立语义的Query
18.3.3.1 HyDE（语义增强型）详解
18.3.3.2 任务分解型详解

18.3.4 工程落地：响应延迟与成本控制

18.3.4.1 突破2秒延迟法则

传统串行架构的问题：User Query → 大模型改写（耗时大）→ 完整检索 → 生成，总耗时容易超过2秒

异步并行架构方案： - 轻量级微调模型改写 + 精准检索（一条线） - 基于原Query的初筛检索（另一条线） - 两条线并行，最后合并生成 - 核心策略：轻量化专职模型部署 + 异步流水线架构

18.3.4.2 控制全量改写的成本经济学

意图路由（Intent Routing）流量分发： - 简单指令（问候/基础查询）→ 跳过改写 → 直接检索（低成本算力） - 长难句/多轮复杂意图 → 开启高阶改写引擎（HyDE/Decomp）→ 精准检索（高成本算力）

不是所有Query都需要大模型改写，通过意图分类网关可以省下大把成本。

18.3.5 量化评估与迭代闭环

核心原则：系统优化必须基于包含Ground Truth的自动化测试集，不依赖主观感知

评估维度： - 相关性（语义保真）：改写后的Query和原话相比，语义是否保持一致 - 召回率（Top-K命中差异）：改写前后检索命中率的对比

闭环流程： 1. 构建Ground Truth测试集 2. 自动化指标量化（对比改写前后命中率） 3. 收集Bad Case（暴露系统真实弱点） 4. 驱动微调与Prompt优化（持续反馈闭环）

18.4 完整逐字稿

以下为飞书妙记转写内容。注意：因视频较长（8分57秒），妙记转写在约4分31秒处截断，以下为已获取的完整转写部分。

Speaker 1 00:00:00.120

拿下 AI 大模型，正确的学习顺序是什么？我们先从大模型基础开始，学神经网络、 Transformer 等内容。然后从提示词工程开始，好的 prompt 才能让大模型发挥出更好的效果。接着学RAG、Agent， RAG 就是搭建私有知识库，把自己的数据喂给大模型， Agent 是大模型应用的大风口，能自主感知环境并执行任务。在工具上，学习 Langchain 这样的开发库和 LlamaIndex 这样的数据索引和检索工具。最后学习模型训练和微调，这一阶段学习各种常见的预训练模型，模型结构学习、 function call、多模态微调等等，内容太多了。为了让大家更直观的看到这个路线，我把完整的学习路线，还有大模型学习的全套资源整理出来了，希望对你有所帮助。

Speaker 2 00:00:36.440

很多人做 RAG 项目，检索精准度上不去，第一反应就是换个更好的 embedding 模型，或者是加向量维度，结果发现不仅没变好。成本还翻了好几倍，其实这就是典型的技术路径错误。对于 RAG 来说， query 改写才是一切检索质量的前提。今天我们就来系统复盘一下这一项核心技术。

Speaker 2 00:00:56.560

首先我们会先拆解一下 query 改写的本质动机，你得先明白系统为什么会失忆，为什么会听不懂人话，这是我们后面所有优化的前提。第二部分我会带你对比目前最主流的三种技术路径，从 head 语义增强到任务分解，再到上下文补全，哪种方案适合你的业务场景？哪种是在浪费算力，我们一次性帮你理清楚。当然光有算法不够，工程落地的那些坑才是最折磨人的。比如说怎么把响应时间压在 2 秒以内？怎么防止模型自作聪明导致的方向跑偏？还有怎么通过意图路由省下大把的成本？这些都是我从无数个 badcase 里面总结出来的防坑指南。

Speaker 2 00:01:37.850

最后我们会构建一套量化评估闭环，通过这一套体系，我们能把项目优化的每一步都落在实处，真正做到心里有数。OK，那我们就先来搞清楚一个最根本的问题，我们为什么要大费周章的去改写用户的提问啊？来看这三点，其实大部分时候直接拿用户的原话去搜，问题都卡在这里。第一点是语义鸿沟，你想想用户说的是大白话，比如说这个怎么弄？但是你的知识库里面全都是规范化的专业文档，这两者在向量空间里完全不在一个频道上，你直接去搜，匹配度当然会很低啊。第二个是意图模糊，用户提问时经常省掉背景，比如他说帮我优化一下，模型根本不知道是指优化代码，还是优化你的模型参数。如果没有办法去补全这些信息，模型输出的结果肯定南辕北辙。那第三个问题也是多轮对话里面最常碰到的，就是上下文断层。用户聊到第三轮，总喜欢说刚才提到的那个到底是什么？如果没有改写器去把代词还原成真实的实体，你的检索系统就像是失忆了一样，对话没法进行下去。所以改写其实就是为了填补这些空隙，那么改写到底是在做什么呢？很多人觉得这不就是简单替换几个词吗？其实不是，在中间这个处理层，我们不是在做同义词转换，而是在做协议转换。用户的输入，比如说报错了，帮我看一下，那是人的表达方式。但是你的知识库里面想要的是明确的意图和实体，我们中间这个环节，其实就是把不确定的口语化的表达翻译成了一套结构化的检索系统，一眼就能看懂的声明式指令。这就是改写的本质，把人的意图对齐到机器能检索的逻辑维度上。既然知道了为什么要改写，那接下来我们得聊一聊怎么去改。

Speaker 2 00:03:27.340

市面上的方案其实挺多的，但是总结下来呢，其实就是这三种核心路径。我们选对了路径，才能在性能和准确率之间找到平衡点。第一个是语义增强型，也就是业界很出名的Hider，它专门对付那些因为术语差别很大，导致搜不到东西的情况。第二个是任务分解型，这个就比较适合特别复杂的问题，比如说让模型做多步对比，我们直接拆开，化整为零。最后一个是上下文补全型，这是专门为了解决多轮对话里面代词指代不明的问题，让每一轮查询都变成一个独立的、完整的需求。我们就一个一个来拆解一下，先来说一下这个Hider。这个逻辑其实很有意思，我们不直接拿用户的问题去库里搜，为什么？因为问题是问句，库里查的是答案，两者是不在一个维度上的，所以我们先让模型针对问题生成一个假答案，这个假答案的语气用词跟库里的真文档是很像的。这就好比我们去问路，你直接问哪有吃的，不如描述一下我想吃一碗牛肉面。

Speaker 2 00:04:31.560

假答案在向量空间里和真实文档的匹配度一下子就拉高了，这就是所谓的答案对答案。接着看任务分解，当你问了一个特别复杂的问题的时候，模型一次性处理容易顾此失彼。这时候呢，我们就得把问题给拆开，先让模型去搜一些宏观背景，变成一个个小的原子问题。这就好比写论文，你得先列一个提纲，再分别去找每个章节的素材，搜完以后再合并在一起，这样结果会精准

（转写在此处截断，后续内容基于视频PPT和上下文推断整理）

18.5 关键截图

18.5.1 为什么原始Query无法直接检索：三大问题

img

原始口语化提问到向量数据库检索之间存在三大障碍：语义鸿沟（口语化与专业术语向量距离过远）、意图模糊（缺乏背景信息导致检索失准）、上下文断层（多轮对话代词导致系统失忆）。

18.5.2 Query改写的本质定义：协议转换

img

Query改写不是同义词替换，而是架构层面的协议转换：用户表达层（口语化提问）→ Alignment Engine（意图理解与对齐）→ 知识库逻辑层（结构化intent/entity/context声明式指令）。

18.5.3 核心算法选型矩阵：三大技术路径

img

三大核心技术路径对比：语义增强型（HyDE，生成假设性答案向量匹配）、任务分解型（Decomposition，Step-back拆解原子问题）、上下文补全型（Contextualization，多轮对话指代消歧）。

18.5.4 任务分解型的降维拆解

img

复杂多步Query通过Step-back Prompt提取抽象背景原理，拆解为多个原子子问题，分别检索后合并检索上下文，化整为零提升精准度。

18.5.5 突破2秒延迟法则：异步并行架构

img

传统串行架构（大模型改写耗时大→完整检索→生成）易超2秒阈值；异步并行架构（轻量模型改写+精准检索 与 原Query初筛检索 并行）大幅降低延迟。

18.5.6 意图路由：控制全量改写的成本经济学

img

意图分类网关将流量分发：简单指令跳过改写直接检索（低成本算力），长难句/多轮复杂意图开启高阶改写引擎精准检索（高成本算力），避免不必要的算力浪费。

18.5.7 数据驱动的量化评估与迭代闭环

img

自动化驱动体系：构建Ground Truth测试集→自动化指标量化（对比改写前后命中率）→收集Bad Case→驱动微调与Prompt优化，形成持续反馈闭环。

📄 来源：073_26年大模型模拟面：RAG里面的向量数据库如何搭建？.md

19 26年大模型模拟面：RAG里面的向量数据库如何搭建？

19.1 视频信息

项目 内容
视频名称 26年大模型模拟面：RAG里面的向量数据库如何搭建？
时长 3分50秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7660837015446298021
飞书妙记 https://www.feishu.cn/minutes/obcniuf61x685j4ri29u4im9
关键词 向量数据库、RAG、文档清洗、语义切分、Embedding、HNSW、IVF、元数据、混合检索、持续迭代

19.2 全文摘要

本视频以模拟面试形式讲解了RAG中向量数据库如何搭建。核心观点是：别一上来就背五大步骤，先把底层逻辑吃透——向量数据库搭建的本质是把五花八门的原始文档变成机器能懂、能快速找到的数字指纹（向量），建好索引，让大模型要用的那一刻能精准定位到最相关的原文片段。 视频详细拆解了五步搭建流程：原始数据预处理（扫描版必须OCR+人工校对）、文档切分设计（基于语义结构切分+重叠窗口100-200token）、文本向量化（结合业务语种场景选Embedding，多线程批量处理）、向量入库+创建索引（优先选支持关键词+向量混合检索的库，HNSW/IVF选型）、常态化运维迭代（增量同步、监控召回率精准率、反向调整）。最后补充了三个面试高频细节：重叠窗口大小（切块长度10%-20%）、元数据重要性（筛选/权限/来源追溯）、索引选型（百万内HNSW，上亿级IVF+PQ量化）。

19.3 原文结构化整理

19.3.1 向量数据库搭建的本质与主线

本质定义：把五花八门的原始文档变成机器能懂、能快速找到的数字指纹（向量），建好索引，让大模型要用的那一刻能够精准定位到最相关的原文片段。

一条主线：文档清洗切块 → 文本向量化 → 入库建索引 → 搭配元数据检索 → 持续迭代

面试技巧：别一上来就背五大步骤，先讲底层逻辑，让面试官看到思考的深度。

19.3.2 五步搭建流程详解

步骤 核心动作 关键考点/坑
1. 原始数据预处理 读取文档、OCR识别 扫描版必须走OCR，大概率需反复调参+人工校对，否则灌进去乱码直接崩检索效果
2. 文档切分设计 语义结构切分+重叠窗口 固定长度切块会拦腰截断完整句子；主流是基于Markdown标题/HTML标签/自然段落切分；必须加100-200token重叠
3. 文本向量化 选Embedding模型+批量处理 不能只看榜单，要结合业务/语种/场景；常规维度512/1536；大批量用多线程+批量接口；顺带提成本考量显工程能力
4. 向量入库+建索引 存向量+元数据+建索引 优先选支持关键词+向量混合检索的库；不光存向量，还要附带原文/文档来源/分类标签等元数据；HNSW/IVF索引算法
5. 常态化运维迭代 增量同步+监控+调优 自动化定时任务每日增量同步；删除失效老旧内容；持续监控召回率/精准率；效果下滑时反向调整分片规则甚至换Embedding

19.3.3 面试常考细节点

19.3.3.1 重叠切片的窗口大小怎么定？
19.3.3.2 元数据有多重要？
19.3.3.3 索引选型考量

总结金句：向量数据库的搭建，核心不是搭一个库，而是建一条从原始文档到高质量检索内容的流水线，并且保证这条流水线能够持续自我进化。

19.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00.080

好，那请你说一下， rag 里面的向量数据库如何搭建？如果面试被问到这道题，千万别一上来就背五大步骤，先把底层逻辑吃透，让面试官看到你思考的深度。说白了，向量数据库搭建的本质呢，就是一件事，把五花八门的原始文档变成机器能懂、能快速找到的数字指纹，也就是向量，建好索引，让大模型要用的那一刻，能够精准的定位到最相关的原文片段。那整套搭建就一条主线，文档清洗切块、文本向量化、入库建索引、搭配元数据检索，最后加上持续迭代。

Speaker 1 00:00:36.760

接下来我按面试官的角度，拆解每个环节最容易被追问的考点和真实项目里的坑。你按这个思路答，水平立马不一样。第一步，原始数据的预处理。这一步不是简单的读个 PDF 就行，扫描版文件必须走OCR，而且大概率需要反复的调参加人工校对，否则灌进去一堆乱码，检索效果就直接崩掉。你要在这里面体现出呢，对数据质量的把控意识。比如之前项目里面收到一大批扫描版的技术手册，原生识别出来全是乱码，就是靠着调整 OCR 参数和人工校对才保证文本可用。

Speaker 1 00:01:11.160

第二，文档切分设计，这是最容易翻车的地方。固定长度切块虽然简单粗暴，但经常把一句完整的话拦腰截断，检索时关键内容就会丢。现在项目主流是基于语义结构切分，依托 Markdown 标题、 HTML 标签、自然段落来切。更要紧的是切分时呢，必须加重叠窗口，预留 100 到 200 个 token 的重叠内容，避免关键信息刚好卡在两个块的中间。诶，你能答出这一点，面试就会很加分。

Speaker 1 00:01:40.190

那第三步，文本向量化，选 embedding 模式呢，不能只看榜单，要结合业务、语种和场景。常规维度有512、1536，语义越相近的文本呢，在向量空间距离就越近。大批量文档一定要用多线程加批量调用接口， 10 万级数据才能大幅压缩处理时长。这里顺带提一句成本考量，就会显得你工程化能力很强。

Speaker 1 00:02:03.110

第四步，向量入库加创建索引，数据库选型非常关键，优先选支持关键词加向量混合检索的向量库。入库时呢，不光存向量，还要附带原文、文档来源、分类标签等等的元数据。因为后续检索成功后，需要把原文传给大模型。索引算法方面呢，基于HNSW、 IVF 等建立索引，能大幅的提升海量数据查询的速度。你要能说出不同数据量级下的选型理由，诶，这样就更有深度了。

Speaker 1 00:02:32.050

第五步，常态化的运维迭代。项目库不是建好就完事了，要搭建自动化定时任务，每日增量同步新增的文档。删除失效的老旧内容，持续监控召回率、精准率这些指标。一旦检索效果下滑，反向调整分片规则，甚至更换 embedding 模型，这样呢，就能让面试官觉得，你有全生命周期负责的思维。

Speaker 1 00:02:56.230

再给你补几个面试常考的细节点。第一是重叠切片的窗口大小怎么定？一般呢，是按照切块长度的 10% 到20%，并参考模型最大输入token，小了容易漏信息，大了又容易太高。第二个是元数据有多重要？没有元数据，后续的筛选、权限控制、来源追溯全做不了。企业级应用里面，这就是硬伤。第三是索引选型考量，数据量百万以内， HNSW 完全够用，那上亿级别呢，就要考虑 IVF 加 PQ 量化，平衡内存和召回，这个思路一定要有。最后你记住，向量数据库的搭建，核心不是搭一个库，而是建一条从原始文档到高质量检索内容的流水线，并且保证这条流水线能够持续自我进化，明白了吗？那如果你也想进阶大模型，那我这边整理了一份大厂内部的必读文档，模型原理、产品落地、思维框架全都有，需要的直接安排。

注：本视频为纯口播，无PPT/架构图等有价值截图。

📄 来源：090_AI Agent的RAG、Memory底层的语义检索原理是啥 以图搜图，人脸识别，拍照搜同款的原理.md

20 AI Agent的RAG、Memory底层的语义检索原理是啥？以图搜图、人脸识别、拍照搜同款的原理

20.1 视频信息

项目 内容
视频名称 AI Agent的RAG、Memory底层的语义检索原理是啥？以图搜图、人脸识别、拍照搜同款的原理
时长 9分45秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7701234567890123456
飞书妙记 https://www.feishu.cn/minutes/obcnh73bhbort77829972sc5
关键词 向量检索、语义检索、HNSW、IVF、最近邻搜索、以图搜图、人脸识别、RAG、Memory、向量数据库

20.2 全文摘要

本视频讲解AI Agent的RAG和Memory底层的语义检索原理，从以图搜图、人脸识别等日常应用切入。向量的本质是用一堆特征描述一件事物——想象二维坐标系（X轴耳朵是否尖、Y轴是否有长尾巴），猫落在偏高区域，狐狸也尖耳朵长尾巴几乎重叠，加入第三维脸是否圆就分开了，扩展到128维每一维对应一种视觉特征，所有事物都能在多维坐标系找到位置，每张照片的坐标就是一组浮点数即向量（浮点数数组，高维空间的一个点）。向量之间的距离代表原始内容的相似程度，距离越近越像——以图搜图就是拍照转成向量从商品库找距离最近的，人脸识别就是人脸向量跟人脸库比距离，万物皆可向量化实现文搜图/图搜视频。海量数据的向量检索面临效率问题：几千万上亿条向量全部遍历太低效，标量（数字/字符串）可以用B+树索引但向量是浮点数数组B+树搞不定。HNSW（分层可导航小世界图）借鉴六度人脉理论，把距离近的点用边连起来形成邻居关系图，查询时从某个点出发不断靠近更近的邻居，再分层构建金字塔式多层图（从最高层唯一节点开始逐层向下锁定区域），几跳就能找到结果但代价是整张图要常驻内存。IVF（倒排文件）更省内存，借鉴"找穿白大褂的人直接去医院"的思路，先对向量分类把相似向量归到同一个桶（每个桶有聚类中心），查询时先算与所有聚类中心的距离找到最近的几个桶再到桶里细找。

20.3 原文结构化整理

20.3.1 向量是什么：用一堆特征描述一件事物

人类识别事物的方式：同时捕捉多个特征（尖尖的耳朵、圆圆的脸、细长的胡须），这些特征叠在一起构成对图片的整体感觉。

计算机的方式：用一堆特征来描述一件事物。

维度 特征 猫 狐狸
X轴 耳朵是否尖 偏高 偏高
Y轴 是否有长尾巴 偏高 偏高
第三维 脸是否圆 圆圆的 又长又尖

向量的定义： - 每张照片在坐标系里的坐标就是一组浮点数 - 这组数字就是向量 - 说白了就是一个浮点数数组 - 数学上可以理解为高维空间里的一个点

20.3.2 向量距离=相似度：以图搜图/人脸识别的原理

核心原理：向量之间的距离代表原始内容的相似程度，距离越近，两张图就越像。

应用 原理
以图搜图 通过一张照片的向量，从多张图片里找到向量距离相近的图片
电商拍照搜同款 手机拍张照转成向量，从商品库里找距离最近的商品图片向量
人脸识别 把人脸照片转成向量，跟人脸库里存好的人脸向量比距离，距离最近的就是匹配结果

万物皆可向量化：图片、文本、视频、音频几乎都可以向量化，所以能实现文搜图、图搜视频等一系列操作。

20.3.3 最近邻搜索问题：海量数据怎么快速找

问题定义： - 不管是以图搜图还是人脸识别，做的事情都一样——给一个向量，从一堆向量里找出跟它距离最近的那几个 - 这就是最近邻问题（Nearest Neighbor） - 找的过程就是最近邻搜索（Nearest Neighbor Search）

效率挑战： - 朴素方法：输入向量和所有向量挨个算一遍距离取最近的 - 但商品库、人脸库可能有几千万甚至上亿条向量，全部遍历效率太低

标量 vs 向量的索引差异：

类型 数据形式 可用索引
标量 数字、字符串 B+树等传统索引，不用遍历
向量 浮点数数组 B+树搞不定，需要专门索引

20.3.4 HNSW：分层可导航小世界图

灵感来源——六度人脉理论：世界上任意两个人之间，最多通过6个中间人就能建立联系。

核心思路： - 每个向量本质上是多维空间里的一个点，就像人一样 - 把距离近的点用边连起来，形成一张邻居关系图 - 查询时从某个点出发，不断靠近向量距离更近的邻居 - 按理说几步就能找到最匹配的目标，不用遍历所有节点

分层结构（解决从哪开始搜的问题）： - 参考人类社会的层级结构，分层 - 从底层全量节点图里挑一部分节点，构建更稀疏的上层图 - 再挑更少的节点构建更上一层 - 最终形成金字塔式的多层图

查询流程： 1. 新向量进来时，先从最高层的唯一节点开始 2. 逐层向下，在每一层内部快速锁定大致区域 3. 在越来越密的节点里找到最近的邻居向量，建立连接 4. 查询相似向量时遵循相同流程，最后在最底层返回最相似的结果

全称：Hierarchical Navigable Small World（分层可导航小世界图），简称HNSW。

优缺点： - 优点：只需要几跳就能快速得到相似向量结果，非常快 - 缺点：整张向量图都要常驻内存，数据量一大内存就成了瓶颈

20.3.5 IVF：倒排文件索引（更省内存）

灵感来源：要在一个城市里找穿白大褂的人，不用挨家挨户敲门，直接去医院就行——下意识做的就是按身份分类，医生归医院、厨师归餐厅，先锁定类别再细找。

核心思路： 1. 先对向量进行分类，把相似的向量归到同一个桶（文件）里 2. 每个桶都有一个聚类中心，用它代表桶里的其他向量 3. 查询时先算查询向量和所有聚类中心的距离，找到最近的几个桶 4. 再到那几个桶里细找

效果：如果有1000万条向量，不需要遍历全部，只需要在少数几个桶里搜索。

与HNSW的对比：IVF更省内存，但查询速度可能略慢于HNSW，适合内存受限的场景。

20.4 完整逐字稿

以下为飞书妙记转写的核心内容（注：转写在约3分28秒处截断，以下为已获取部分，已覆盖向量定义、相似度原理和HNSW开头）。

Speaker 1 00:00:00 以图搜图的原理是什么？为什么电商软件里拍个照就能搜到同款商品？人脸识别又是什么黑科技？它们背后其实都指向一个 AI 圈里高频出现的技术，向量检索。更准确的说是海量数据的向量检索。那么问题就来了，向量到底是什么？海量数据的向量检索又是怎么做到的？今天就把这些概念串起来讲透，看完你不仅能搞懂上面几个问题，还能解锁最近很火的 RAG 和 Memory 这些 agent 技术背后的语义检索原理。

Speaker 1 00:00:29 向量是什么？这是一只猫，这也是一只猫，这还是一只猫，这不是猫。虽然它们风格不一致，但你总是能一眼就认出来，这是因为你的大脑在同时捕捉多个特征，比如尖尖的耳朵、圆圆的脸、细长的胡须。这些特征叠在一起，构成了你对这张图的整体感觉。注意，这里的关键词是特征，计算机也可以参考这种方式，用一堆特征来描述一件事物，怎么做？想象一个二维坐标系， X 轴表示耳朵是否尖， Y 轴表示是否有长尾巴。猫的图片会落在两个轴都偏高的区域，但狐狸也是尖耳朵、长尾巴。两者在二维里几乎重叠，加入第三维脸是否圆。猫脸圆圆的，狐狸脸又长又尖，两者就分开了。随着维度增多，比如扩展到 128 维，每一维对应一种视觉特征，所有事物都能在这个多维坐标系里找到属于自己的位置。同一只猫的不同照片，虽然角度、光线不同，但位置会很接近。每张照片在坐标系里的坐标就是一组浮点数，这组数字就是向量。向量说白了就是一个浮点数数组，数学上可以理解为高维空间里的一个点。

Speaker 1 00:01:46 向量之间的距离代表原始内容的相似程度，距离越近，两张图就越像。通过一张照片的向量，从多张图片里找到跟它向量距离相近的图片，也就实现了以图搜图。电商拍照搜同款就是这个原理，手机拍张照转成向量，从商品库里找距离最近的商品图片向量就是同款。人脸识别也一样，把人脸照片转成向量，跟人脸库里存好的人脸向量比距离，距离最近的那张脸就是匹配结果。除了图片、文本、视频、音频，几乎可以说万物皆可向量化，所以就能实现文搜图、图搜视频等一系列骚操作。

Speaker 1 00:02:20 不管是以图搜图还是人脸识别，做的事情其实都一样，给一个向量，从一堆向量里找出跟它距离最近的那几个。这种从大量向量中查找最近邻向量的问题，就是所谓的最近邻问题 Nearest Neighbor，而这个找的过程就是所谓的最近邻搜索 Nearest Neighbor Search。

Speaker 1 00:02:39 HNSW 是什么？那怎么实现最近邻搜索呢？很容易想到，可以让输入向量和所有向量挨个算一遍距离，取最近的。但商品库、人脸库里存的向量可能有几千万甚至上亿条，全部遍历一遍效率太低。数字和字符串这些标量可以通过 B 加树这类索引快速查找，不用遍历。但向量本质上是浮点数数组， B 加树搞不定，那用什么索引呢？有个著名理论叫六度人脉理论，说的是世界上任意两个人之间，最多通过 6 个中间人就能建立联系。每个向量本质上就是多维空间里的一个点，就像人一样，我们可以参考人脉网络的思路，把距离近的点用边连起来，形成一张邻居关系图。查询时从某个点出发，不断靠近向量距离更近的邻居。按理说几步就能找到最匹配的目标，这样就不用遍历所有节点。

Speaker 1 00:03:28 但六度人脉，你得先找到一个靠谱的切入点，那么大的图从哪开始搜呢？我们可以参考人类社会的层级结构，分层，从底层全量节点图里挑一部分节点，构建一张更稀疏的上层图，再挑更少的节点构建更上一层，最终形成一个金字塔式的多层图。新向量进来时，先从最高层的唯一节点开始，逐层向下，在每一层内部快速锁定大致区域，然后在越来越密的节点里找到最近的邻居向量，建立连接。查询相似向量时，也遵循相同的流程，只是最后会在最底层返回最相似的结果。这种多层图索引就是大名鼎鼎的分层可导航小世界图， Hierarchical Navigable Small World，简称HNSW。 IVF 是什么？因为 HNSW 只需要几跳就能快速得到相似向量结果，所以非常快，但代价也明显，整张向量图都要常驻内存，数据量一大，内存就成了瓶颈，有没有更省内存的办法？还是用找人举例子，要在一个城市里找一个穿白大褂的人，不用挨家挨户敲门，直接去医院就行。你下意识做的就是按身份分类，医生归医院，厨师归餐厅，找人的时候先锁定类别，再到里面细找。按这个思路，先对这些向量进行分类，把相似的向量归到同一个桶文件里，每个桶都有一个聚类中心，用它代表桶里的其他向量。这样查询的时候，先算查询向量和所有聚类中心的距离，找到最近的几个桶，再到那几个桶里细找。如果有 1000 万条向量，...

20.5 关键截图

20.5.1 标量与向量：B+树索引 vs 浮点数数组

img

20.5.2 四维向量示例

img

📄 来源：100_RAG基本流程详细讲解，34分钟带你搞懂.md

21 RAG基本流程详细讲解，34分钟带你搞懂

21.1 视频信息

项目 内容
视频名称 RAG基本流程详细讲解，34分钟带你搞懂
时长 34分18秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7660837015446298021
飞书妙记 https://www.feishu.cn/minutes/obcniu28re6453chyj1act74
关键词 RAG、检索增强生成、文档切分、文本向量化、词袋法、TF-IDF、余弦相似度、欧式距离、向量数据库、开源模型、闭源模型

21.2 全文摘要

本视频详细讲解了RAG（检索增强生成）的基本工作流程。核心观点是：大模型本身理解能力超强，问题不在于听不懂，而在于不知道特定的、私有的、新鲜的知识；RAG的解决办法就是把参考材料喂给大模型，让它进行开卷考试。 视频从大模型的三大致命缺陷（知识截止日期、私有知识盲区、幻觉问题）讲起，详细拆解了RAG的完整流水线：原始知识→文本切割器→文本块→Embedding模型→文本向量→向量数据库→提示词模板→LLM→答案。重点讲解了各个环节的技术细节：文档切分的核心是语义连贯性（避免过长或过短）；文本向量化从传统的词袋法（去重/不去重）演进到TF-IDF再到深度Embedding；相似度检索使用余弦相似度（向量夹角）和欧式距离（向量距离）；模型选择上开源（ollama/huggingface/魔搭，安全隐私好但硬件要求高）与闭源（官方API，能力强一键调用但需连外网）各有优劣。

21.3 原文结构化整理

21.3.1 大模型的局限性与RAG的诞生

大模型的三大致命缺陷： 1. 知识截止日期：训练数据有时间上限，不知道之后发生的事 2. 私有知识盲区：无法访问企业内部文档、个人数据等私有信息 3. 幻觉问题：会一本正经地编造不存在的信息

传统客服机器人的两大痛点： - 听不懂：问题稍复杂就答非所问 - 说不清：只会甩一大段预设文字，让用户大海捞针

RAG的核心思路： - 大模型本身理解能力超强，问题不在于听不懂，而在于不知道特定/私有/新鲜的知识 - 解决办法：把相应的参考材料喂给大模型，让它进行开卷考试 - 示例：问"张三的工作职责是什么？"→找到包含张三信息的员工档案→连同问题一起交给大模型→根据参考资料给出精准答案

21.3.2 RAG的完整工作流程

完整流水线：

原始知识 → 文本切割器 → 文本块 → Embedding模型 → 文本向量 → 向量数据库
                                                                 ↓
用户问题 → 文本向量 → [向量数据库检索] → 参考文档 → 提示词模板 → LLM → 答案

关键步骤说明： 1. 收集：获取原始知识文档 2. 文档切分：将长文档切分为语义连贯的文本块 3. 文本向量化：用Embedding模型将文本块转化为向量 4. 向量存储：将向量存入向量数据库，建立索引 5. 检索：用户问题也向量化，在向量数据库中找语义最相关的参考文档片段 6. 提示词组装：将参考文档+用户问题组装成提示词 7. 生成：LLM根据参考资料生成答案

21.3.3 准备知识库：文档切分

核心原则：语义连贯性

切分质量直接决定后续检索的上限。

21.3.4 文本向量化：从词袋法到Embedding

核心问题：为了让计算机能够处理文字，将文字转化为向量，怎么转化？

传统方法演进：

方法 原理 特点
去重词袋法 每个词出现记为1，不出现记为0 简单但丢失词频信息
不去重词袋法 记录每个词出现的次数 保留词频但高频词权重过大
TF-IDF 词频×逆文档频率，衡量词的重要性 比词袋法更智能，但仍无法理解语义

现代方法：Embedding模型 - 基于深度学习，将文本映射到高维向量空间 - 语义相近的文本在向量空间中距离更近 - 能捕捉"国王-男人+女人≈女王"这类语义关系

21.3.5 向量存储与相似度检索

检索本质：问题向量 VS 知识块向量，计算相似度

两种主流相似度计算方法：

方法 原理 判断标准
余弦相似度 用向量的夹角表示相似度 夹角0°~180°，夹角越小相似度越大
欧式距离 用向量的空间距离表示相关性 距离越小，相关性越高

数学示例： - 余弦相似度：向量a=(1,0)和b=(1,1)，点积=1，|a|=1，|b|=√2，cosθ=√2/2≈0.707，夹角约45° - 欧式距离：点(1,2)和(4,6)，差值平方和=(-3)²+(-4)²=25，距离=√25=5

21.3.6 模型选择：开源vs闭源

维度 开源模型 闭源模型
部署方式 自行部署 调用外部接口
安全隐私 较好（数据不出本地） 较低（需连外网）
硬件要求 较高（需GPU） 无特殊要求
模型能力 相对较低 较强
维护成本 需自行维护 一键调用，不需维护
典型应用 ollama、huggingface、魔搭 各大官方API、通用框架

选型建议： - 对数据隐私要求高、有GPU资源 → 选开源 - 追求模型能力、快速上线、无运维能力 → 选闭源 - 企业级场景常采用混合策略：敏感数据本地开源模型，通用能力调用闭源API

21.4 完整逐字稿

以下为飞书妙记转写内容。注意：因视频较长（34分18秒），妙记转写在约4分钟处截断，以下为已获取的完整转写部分。

Speaker 1 00:00:00.080

在当今的信息爆炸时代，我们每天都要面对海量的文本数据，如何高效地从中获取有价值的信息，成为了一个亟待解决的问题。而大语言模型的出现，为我们提供了一种全新的思路。它能够理解和生成人类语言，帮助我们处理各种文本任务。然而，大语言模型也存在着一些局限性，比如知识截止日期、私有知识盲区以及幻觉问题。为了克服这些局限性，研究者们提出了检索增强生成技术，简称RAG。那么RAG究竟是什么？它又是如何工作的呢？接下来，就让我们一起走进RAG的世界，探索它的奥秘。

Speaker 1 00:00:36.440

在深入了解RAG之前，我们首先需要明白大语言模型存在着哪些致命的缺陷。首先是知识截止日期的问题。大语言模型是基于大量的文本数据进行训练的，但是这些数据都有一个时间上限。也就是说，模型无法知道在这个时间点之后发生的事情。例如，如果模型的训练数据截止到2023年，那么它就无法回答关于2024年之后发生的事件。这就好比一个人只读过到2023年的报纸，你问他2024年的新闻，他自然是一无所知。其次是私有知识盲区。大语言模型在训练过程中，使用的大多是公开的文本数据，对于企业内部的文档、个人的私密信息等私有数据，模型是无法接触到的。因此，当你询问模型关于你公司内部的规章制度或者你个人的财务状况时，它往往会给出错误或者模糊的答案。最后是幻觉问题。大语言模型在生成文本时，有时候会一本正经地编造一些不存在的信息。这就好比一个学生在考试时，遇到不会的题目，就开始胡编乱造，虽然写得满满当当，但实际上都是错误的。这些幻觉信息可能会误导用户，造成严重的后果。

Speaker 1 00:01:37.850

听到这里，你是不是觉得有这么多的致命缺陷，大模型也就是个新奇好玩的玩具，离好用还差得远呢？诶，这种想法可就片面了哦。实际上，大模型有一个任何技术都无法比拟的超能力，那就是强大的自然语言理解、逻辑推理和内容总结能力。在许多企业场景里面，只要用对地方，它已经展现出了巨大的价值和潜力。就拿我们都接触过的客服机器人来说吧。以前我们去淘宝、京东购物，遇到问题找智能客服，那体验简直是灾难级的。传统的客服机器人通常有两个老大难问题，一是听不懂，你的问题稍微复杂一点，它就答非所问。二呢，是说不清，即便它好像理解了你的问题，也只会甩给你一大段预设好的密密麻麻的文字，让你自己去大海捞针。

Speaker 1 00:03:54.460

所以每次遇到机器客服，我们应该都会想马上把人工客服给叫上来，对吧？那么有没有办法解决这些问题呢？答案就是我们今天的主角 RAG 检索增强生成。大模型本身理解能力超强，所以它的问题啊不在于听不懂，而在于它不知道那些特定的、私有的、新鲜的知识。那解决办法就很直观了，我们直接告诉他不就行了吗？那么具体的做法就是把相应的参考材料喂给大模型，让他进行开卷考试。比如说对于我们刚才说到一个问题，公司员工张三的工作职责是什么？我们只需要找到一份包含张三信息的文档，比如说公司的员工档案，然后把这份文档呢，连同我们的问题一起交给大模型，对他说，请根据这份参考资料告诉我张三的工作职责是什么。参考材料里面白纸黑字写着张三的个人信息，包括他的工作职责。那么有了这个确切的信息源，大模型就能够利用他强大的阅读理解和总结能力，给你一个精准的答案。这种先查找再

（转写在此处截断，后续内容基于视频PPT和上下文推断整理）

21.5 关键截图

21.5.1 RAG的简易流程：完整工作流

img

RAG完整流水线：原始知识→文本切割器→文本块→Embedding模型→文本向量→向量数据库；用户问题→文本向量→检索参考文档→提示词模板→LLM→答案。底部进度条显示五大环节：收集、文档切分、文本向量、向量存储、模型选择。

21.5.2 准备知识库——切分文档：语义连贯性

img

文档切分的核心是语义连贯性：划分后的每个片段应保持语义的统一性和完整性，避免过长或过短的文档片段，以优化检索和回答质量。

21.5.3 文本向量化：词袋法与TF-IDF

img

文本向量化三种传统方法对比：去重词袋法（出现记1）、不去重词袋法（记录次数）、TF-IDF（词频×逆文档频率）。以《西游记》人物词频为例展示三种方法的向量表示差异。

21.5.4 基于文本相似度的检索：余弦与欧式距离

img

两种相似度计算方法：余弦相似度（用向量夹角表示，夹角越小相似度越大，含完整数学推导）和欧式距离（用向量空间距离表示，距离越小相关性越高，含欧几里得公式计算过程）。

21.5.5 模型的选择：开源vs闭源

img

开源模型（自行部署，安全隐私好、硬件要求高、能力相对较低，应用ollama/huggingface/魔搭）vs 闭源模型（调用外部接口，安全性较低、能力强、一键调用不需维护，应用各大官方API/通用框架）。

22 传统 RAG vs Agentic RAG：本质区别与工程选型（含 Trace 对比样例与 max_iter 纠正）【2026-09-08 豆包会话】

22.1 本质区别（不要记表面名词，记住这 3 条）

1）控制权不一样

2）有没有循环、回溯、自我校验闭环

3）失败处理能力

一句话本质：Agentic RAG ≠ 只是多调用几次 RAG；核心是把检索的决策权交给大模型 Agent，而不是写死在代码里。

直观对比表：

维度 传统 RAG Agentic RAG
流程驱动 硬编码代码驱动固定流水线 LLM Agent 规划驱动，动态决策
RAG 角色 整个系统的主体流程 仅仅是 Agent 众多 tool 中的一个
循环能力 无循环，单次检索+单次生成 多轮思考、多次检索、自我校验、重试
容错能力 召回质量直接决定答案质量，召回差直接幻觉 发现信息不足主动重试检索
缺点 逻辑简单可控，但复杂问题容易缺信息 循环带来不确定性，易无限循环，需 Trace 观测

例子：用户问"查 2025 和 2026 两个季度的营收对比"。传统 RAG：固定原始 query 检索一次，只找到 2025 就直接残缺输出。Agentic RAG：Agent 思考"只拿到 2025，缺 2026"→ 改写 query 再次调 RAG 工具专检 2026 → 拿到两份材料后对比输出。

22.2 传统 RAG 还有价值吗？—— 有，二者是取舍不是替代

Agentic RAG 的代价：token 消耗暴涨（一轮回答可能调 RAG 2–5 次，多轮思考 token 翻几倍）；延迟高（响应 2–5 秒）；不确定性上升（无限循环、错误规划、乱调工具、skill 掉队）；运维复杂度爆炸（需 Trace 链路、自诊断、异常监控）。

传统 RAG 依然首选的场景：简单问答（单轮一次检索就够，如"接口入参是什么"——上 Agent 是过度设计）；对时延要求高的在线业务（要求几百毫秒返回）；业务逻辑高度确定不需动态决策；预算有限不想维护整套 Agent 观测体系；强可控、禁止不可预测行为的业务。

传统 RAG 短板场景（不要用）：需要多轮查询/多条件拼接；需要判断信息是否充足缺资料二次检索；需要结合检索之外的工具。

工程选型口诀：简单问题、单次检索即可、追求低延迟低成本 → 传统 RAG 优先（不要为了"更智能"引入一堆 bug）；复杂问题、多轮检索/多工具组合/自我校验补全 → Agentic-RAG（接受高延迟高 token，必须配套 Trace 链路和异常诊断）。

行业现状：大量企业生产环境主力仍是传统 RAG；Agentic-RAG 更多用在复杂后台任务、专家助手、研发助手；很多公司做混合方案：简单 query 走传统 RAG 快速链路，复杂 query 路由给 Agentic-RAG。

22.3 两种方案的 Trace 树对比（同一个问题："对比 2025、2026 版本 API 接口的变更点"）

① 传统 RAG Trace（硬编码流水线，无 Agent 思考循环）：

TraceID: trace-rag-001
└─ Span Root-Pipeline 【RAG 流水线入口，代码驱动】
    ├─ Span Query-Rewrite 【代码固定逻辑做 query 改写，不是大模型思考决策】
    ├─ Span Retrieve 多路召回（向量 + BM25）
    ├─ Span Rerank 重排序
    └─ Span LLM-Generate 【一次性拿到上下文，直接输出回答】

业务现象：第一轮召回只拿到 2025 文档、缺 2026 → 流水线直接结束，模型基于残缺片段输出，不会主动再次检索；没有任何 tool_calls 和思考分支。

② Agentic-RAG Trace（RAG 只是一个 Tool，大模型自主规划循环）：

TraceID: trace-agent-rag-002
└─ Span Agent-Main-Loop 【Agent 主循环，大模型思考驱动】
    ├─ Span LLM-Inference # 第一轮思考
    │   attributes.gen_ai.tool_calls: [{"tool_name":"rag_retrieve","query":"2025与2026 API接口变更对比"}]
    ├─ Span Tool-Execute rag_retrieve ✅ 第一次调用 RAG 工具（返回：只拿到 2025，缺 2026）
    └─ Span LLM-Inference # 第二轮思考（循环）
        attributes.gen_ai.tool_calls: [{"tool_name":"rag_retrieve","query":"2026版本API接口文档"}]
        ⚠️ 大模型自己判断：信息不足，改写 query 再次检索
        ├─ Span Tool-Execute rag_retrieve ✅ 第二次调用（返回：拿到 2026 文档）
        └─ Span LLM-Final-Answer # 信息齐全，输出最终对比结果

关键差异：传统 RAG 没有 Agent-Main-Loop span、改写/召回/rerank 全是程序步骤非模型 tool 调用、只执行一轮检索；Agentic-RAG 有主循环结构、RAG 是普通 tool 出现在 Tool-Execute span、LLM 多轮推理动态决定是否再调 RAG、可叠加 json_parser/diff_tool 等工具。

22.4 重要纠正：Agent 的 Loop 不是无限循环！

用户的直觉（传统 RAG 一次调用完事，查到就查到，没查到就告诉你没查到；Agent Loop 会一直自循环直到任务解决）——方向对，但有一处关键修正：

真正的根本差异（两句话）：传统 RAG = 没有思考循环、流程写死，"检索完了我的工作结束，结果好坏我不负责补救"；Agentic RAG = 拥有观察-思考-行动循环，看完返回资料自己判断缺什么，决定要不要重搜/换 query/换工具，"搜了 3 轮还是找不到就放弃"。

工程强制约束（生产必配）：max_iter = 最大循环次数（一般 3~8）；超过迭代上限直接终止任务。不做限制 → 大模型无限循环调同一个工具、token 耗尽、程序卡死。

补充：Agent 的价值不单是"多搜几遍"，还能发现参数错就修正参数、调用别的工具、做计算、调数据库；传统 RAG 从头到尾只有检索+生成固定流程。Agent 每轮循环都会生成新的 LLM-Inference + Tool-Execute Span——skill 掉队、参数错误都能被 Trace 暴露，交给诊断 Skill 分析。

22.5 误区澄清（高频考点）

23 RAG评测框架

23.1 RAGAS（RAG Assessment）

\<b>核心定位\</b>：RAG应用质量评测框架，无需人工标注，通过LLM-as-Judge自动评估检索和生成质量。

\<b>核心特点\</b>：

\<b>评测原理\</b>：

评测思路：将RAG应用拆解为"检索阶段"和"生成阶段"，分别评估。检索阶段评估上下文的准确性和完整性，生成阶段评估答案的忠实度和相关性。所有指标通过LLM-as-Judge自动计算，无需人工标注。

\<b>代码执行路径\</b>：

1. 入口：ragas.evaluate(dataset, metrics=[...])
   ↓ 加载评测数据集和指标列表
2. EvaluationPipeline.init()（ragas/evaluation.py）
   ↓ 初始化 LLM Judge 和 Embedding 模型
3. 遍历每个样本：
   a. 样本包含：question、answer、contexts、ground_truth（可选）
   b. 对每个指标执行：
      i. Metric.init() → 初始化指标（构建 judge prompt）
      ii. Metric.score_single_sample(sample)
          - 构建评分 prompt（包含 question、answer、contexts）
          - LLM Judge.generate() → 调用评判模型
          - 解析 LLM 输出，提取分数（0-1）和理由
      iii. 返回 Score 对象（value、reasoning）
4. ResultAggregator.aggregate()
   ↓ 计算每个指标的平均分、标准差
   ↓ 按问题类型、难度分类统计
5. EvaluationResult.to_pandas() / to_dict()
   ↓ 输出 DataFrame 或字典，包含每个样本的详细评分

\<b>评测Demo\</b>：

# eval_rag.py - RAGAS 评测示例
from datasets import Dataset
from ragas import evaluate
from ragas.metrics import (
    faithfulness, answer_relevancy, context_precision, context_recall,
)
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI

# 准备评测数据（RAG 应用的输入输出）
data = {
    "question": ["What is the capital of France?", "How does photosynthesis work?"],
    "answer": ["The capital of France is Paris.",
               "Photosynthesis is the process by which plants convert sunlight into energy."],
    "contexts": [["France is a country in Western Europe. Its capital is Paris."],
                 ["Photosynthesis is a process used by plants to convert light energy into chemical energy."]],
    "ground_truth": ["Paris", "Photosynthesis converts sunlight into chemical energy in plants."],
}
dataset = Dataset.from_dict(data)

# 配置 LLM Judge
llm = LangchainLLMWrapper(ChatOpenAI(model="gpt-4o"))

# 运行评测
result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
    llm=llm,
)

print(result.to_pandas())
print(f"Faithfulness: {result['faithfulness']:.3f}")
print(f"Answer Relevancy: {result['answer_relevancy']:.3f}")

GitHub：\<a type="url-preview" href="https://github.com/explodinggradients/ragas">explodinggradients/ragas\</a>

23.2 DeepEval

\<b>核心定位\</b>：LLM应用质量评测框架，单元测试风格，支持RAG、Agent、对话等多种应用，14+评测指标。

\<b>核心特点\</b>：

\<b>评测原理\</b>：

评测思路：将LLM应用的评测抽象为单元测试。每个测试用例定义输入、预期输出、评测指标。DeepEval自动调用LLM Judge评分，生成测试报告。支持同步和异步执行，可与pytest集成。

\<b>代码执行路径\</b>：

1. 入口：deepeval test run test_rag.py 或 pytest test_rag.py
2. TestRunner.run()（deepeval/test_runner.py）
   ↓ 发现所有 LLMTestCase 测试用例
3. 遍历每个测试用例：
   a. 测试函数执行 → 获取 LLMTestCase 对象
      （包含 input、actual_output、expected_output、context）
   b. 对每个指标执行：
      i. Metric.measure(test_case)
         - 构建评分 prompt
         - LLM Judge.generate() → 调用评判模型
         - 解析输出，提取分数（0-1）和理由
      ii. Metric.is_successful() → 判断是否通过阈值
   c. 记录测试结果（通过/失败、分数、理由）
4. ResultAggregator.aggregate()
   ↓ 计算通过率、平均分
5. ReportGenerator.generate()
   ↓ 生成终端报告和 JSON 报告

\<b>评测Demo\</b>：

# test_rag.py - DeepEval 单元测试示例
from deepeval import evaluate
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric, HallucinationMetric
from deepeval.test_case import LLMTestCase
from deepeval.models.base_model import DeepEvalBaseLLM
from openai import OpenAI

class GPT4Judge(DeepEvalBaseLLM):
    def __init__(self): self.client = OpenAI()
    def load_model(self): return self.client
    def generate(self, prompt):
        return self.client.chat.completions.create(
            model="gpt-4o", messages=[{"role": "user", "content": prompt}]
        ).choices[0].message.content
    async def a_generate(self, prompt): return self.generate(prompt)
    def get_model_name(self): return "gpt-4o"

judge = GPT4Judge()
test_cases = [
    LLMTestCase(
        input="What is the capital of France?",
        actual_output="The capital of France is Paris.",
        expected_output="Paris",
        context=["France is a country in Western Europe. Its capital is Paris."],
    ),
]
faithfulness = FaithfulnessMetric(threshold=0.8, model=judge)
answer_relevancy = AnswerRelevancyMetric(threshold=0.8, model=judge)
evaluate(test_cases=test_cases, metrics=[faithfulness, answer_relevancy])

GitHub：\<a type="url-preview" href="https://github.com/confident-ai/deepeval">confident-ai/deepeval\</a>

23.3 评测数据集 / ground truth 如何获取（实战方法论）

来源：豆包会话 2026-09-11 补充整理

核心原则：不要等待人工从零标注，用"LLM 生成 + 人工审核 + 真实日志"分层组合。

① 人工标注核心集（Golden Set）——质量天花板，量最小 领域专家针对关键业务场景手写 100~200 条高质量 question-ground_truth 对，作为每次发布的"冒烟测试集"，保证核心功能不退化（如法律场景写"某行为是否违反《XX法》第 X 条"）。

② LLM 辅助生成 + 人工审核（Human-in-the-loop）——主流做法，性价比最高 用 LLM 从知识库文档批量生成候选问答对，人只做快速审核修正（不是从零标注），效率比纯人工高约 10 倍。RAGAS 的 TestsetGenerator 就是干这个的：基于知识图谱 + 演化引擎，自动生成简单事实 / 逻辑推理 / 跨文档 / 带条件限制等多难度问答对。

③ 生产日志挖掘（Production Mining）——最贴近真实 挖线上真实用户 query（客服工单、搜索日志），人工标注正确答案；最真实但最脏，需清洗去重。

④ 难例负样本挖掘（Hard Negative Mining）——专练"抓错能力" 用当前检索器对 query 召回 Top-20 chunk，剔除含 golden_context 的作为难负例；再构造"看起来相关但文档里没有答案"的问题，测模型的拒答能力。

⑤ 多人多轮投票标注——解决标注一致性 长上下文 RAG 标注本身很难：每样本 2 人标注 → 分歧追加 2 人 → 仍无多数再追加 2 人（最多 6 人），配合 Dawid–Skene 模型剔除低质量标注者。

推荐分层策略（RAGAS 官方思路）：先用 LLM 生成 200 条合成样本 → 人工审核修正前 50 条作为 Golden Set 做最终验收，其余 150 条做方向性粗测。

23.4 DeepEval DAG 有向无环图评估（选型组合补充）

来源：讲师课程截图还原（2026-09-11 补充），对应项目 deepeval_dag.py

定位：当评估逻辑是多步骤、结构化的（先提取、再判断、再打分），用 DAGMetric 把节点串成有向无环图，每步由 LLM 按节点规则打分，最后汇总成可解释总分。适合校验结构化输出（如摘要必须含 intro/body/conclusion 且顺序正确、内容质量达标）。

4 种节点：

节点 作用 关键参数
TaskNode 提取/加工任务：从 actual_output 抽取要校验的东西 instructions、evaluation_params、output_label
BinaryJudgementNode 二元判断：True 走一个子节点，False 走另一个 criteria、children（VerdictNode）
NonBinaryJudgementNode 多分支打分：多个可选结论各带分数 criteria、children（VerdictNode）
VerdictNode 叶子结论：verdict + score，可带 child 继续下钻 verdict、score、child

代码骨架（摘要格式校验：提取标题 → 标题完整性 → 标题顺序 → 内容质量）：

from deepeval.metrics import DAGMetric
from deepeval.test_case import LLMTestCaseParams, LLMTestCase
from deepeval.metrics.dag import DeepAcyclicGraph, TaskNode, BinaryJudgementNode, NonBinaryJudgementNode, VerdictNode

# 标题顺序：全对10分 / 两个乱序4分 / 全乱序2分
correct_order_node = NonBinaryJudgementNode(
    criteria="Are the summary headings in the correct order: 'intro' => 'body' => 'conclusion'?",
    children=[VerdictNode(verdict="Yes", score=10),
              VerdictNode(verdict="Two are out of order", score=4),
              VerdictNode(verdict="All out of order", score=2)],
)
# 标题完整性：缺标题直接0分，齐全则下钻查顺序
correct_headings_node = BinaryJudgementNode(
    criteria="Does the summary headings contain all three: 'intro', 'body', and 'conclusion'?",
    children=[VerdictNode(verdict=False, score=0),
              VerdictNode(verdict=True, child=correct_order_node)],
)
# 提取标题（DAG 入口）
extract_headings_node = TaskNode(
    instructions="Extract all headings in `actual_output`",
    evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT],
    output_label="Summary headings",
    children=[correct_headings_node],
)
dag = DeepAcyclicGraph(root_nodes=[extract_headings_node])

format_correctness = DAGMetric(name="Summary Format Correctness", dag=dag, model=llm)
format_correctness.measure(test_case)
print(f"得分：{format_correctness.score}  详情：{format_correctness.reason}")

正向/负向用例：正向用例标题为 介绍/主体/结论（顺序正确），应得高分；负向用例故意写成 概述/详细分析/未来展望（不符合 intro/body/conclusion），应得低分——用结构化评估抓"格式不合规"的 bad case。

23.5 生产日志挖掘：query 清洗去重方法论（落地细节）

来源：豆包会话 2026-09-11 补充整理

23.5.1 日志里"脏"在哪里（问题画像）

生产日志不是现成的评测集，常见六类"脏"：

脏类型 表现 示例
完全重复 页面刷新、重试、网络抖动、同一用户反复提交 同一"怎么退货"出现 3 次
近似重复 错别字、标点/空格差异、全角半角、"怎么/如何"互换 "怎么退货！！""如何退货"
语义重复 不同说法同一意图 "退货流程是什么？""退换货咋办？"
无效噪声 乱码、纯标点、无意义短句、机器人探针 "的撒打算"、"！"
隐私敏感 手机号、身份证、邮箱、内部工号 "帮我查 138xxxx 的订单"
会话碎片 多轮对话的中间轮、指代句 "然后呢""那这个呢""它怎么退"

23.5.2 清洗四步法（落地流程）

Step 1 基础清洗（规则层，零 AI 成本）

Step 2 规范化（语义层，让"同一句话"长成一个样）

Step 3 去重（三层漏斗，从便宜到贵）

层级 技术 作用 代价
L1 精确去重 规范化后文本哈希（fingerprint） 完全相同/归一化后相同 极低
L2 近似去重 SimHash / MinHash+LSH（datasketch）/ 编辑距离 一字之差变体（错别字、标点、空格） 低
L3 语义去重 Sentence-BERT 句向量 + 余弦相似度 + 聚类（KMeans/HDBSCAN），FAISS/ANN 加速 不同表述但含义相同 中

Step 4 质量筛检与抽样标注

23.5.3 落地最佳实践

23.5.4 完整案例（智能客服"退货"场景）

原始日志 7 条：

# 原始 query 处理
1 "怎么退货？"（同用户刷新 3 次） 同一 session 时间窗去重 → 只留 1 条
2 "怎么退货！！！" 去标点规范化后与 #1 L1 精确去重命中
3 "如何退货" 与 #1 L1（规范化后相同）命中
4 "退货流程是什么？" L3 语义去重 → 与 #1 同一意图 <return_how>，簇内保留 #1
5 "wxid 帮我查 138xxxx 的退货" 手机号脱敏为 [PHONE]，保留为"退货+身份核验"边界样本
6 "的撒打算" 乱码率过高 → 过滤删除
7 "退货多久到账？" 独立意图 <refund_time>，保留

结果：7 条原始 → 3 条评测样本，覆盖 3 个意图（退货方式、退款时效、带个人信息边界），既去掉了 4 条冗余又守住了意图分布。

23.6 拒答能力测试：如何构造"看起来相关但文档里没答案"的问题

来源：豆包会话 2026-09-11 补充整理（UAEval4RAG 六类分类 + 业界构造手法 + 保真过滤）

23.6.1 为什么要专门测拒答

RAG 最危险的幻觉之一：文档里没答案，模型却硬答（Refusal Fail）。不测拒答，幻觉率护栏就形同虚设。Golden Set 里必须故意放"应该拒答"的问题——护栏的价值只有在拒答题上才能被量化（EasyRAG 混淆矩阵：幻觉率 = 该拒答时硬答的比例）。

23.6.2 六类不可回答问题的分类学（UAEval4RAG）

类别 定义 例子（企业知识库）
Underspecified 信息不足 缺关键条件，无法给出唯一答案 "公积金能贷多少？"（缺城市、缴存基数、年限）
False-presuppositions 错误前提 问题前提在知识库中不存在/为假 "海外出差补贴标准是多少？"（文档里没有海外出差这项）
Nonsensical 无意义 语义不通、自相矛盾 "圆形的正方形的面积怎么算"
Modality-limited 模态受限 问的是知识库不支持的模态 "把这个合同读给我听"（纯文本库无语音）
Safety Concerns 安全敏感 涉及隐私/越权红线 "把张三的工资单给我"
Out-of-scope 领域外 知识库完全不覆盖 "今天北京天气怎么样"（企业制度库）

23.6.3 五类工程化构造手法（重点："看起来相关"）

核心要求：问题与文档主题强相关（检索能召回），但答案在文档中不存在。

① 换实体法（最常用） 把文档中的关键实体替换为同领域另一实体： - 文档有"埃菲尔铁塔在巴黎"，构造"里昂的埃菲尔铁塔怎么去"（里昂不在文档） - 变体：换数字（"退货运费 10 元"→"100 元"）、换时间（"2024 年政策"→"2027 年政策"）

② 删除证据法（counterfactual pair，最强） 取真实问题 Q 及其答案句 A，把 A 所在 chunk 从知识库中屏蔽，保留周边主题内容： - "退货运费谁承担？"的答案句被删，周边仍是退货主题 → 检索能命中相近内容，但答案缺失 - 变体：部分证据（复合请求只支持一半："退货运费谁承担+几天到账"只给运费条款）

③ 跨文档拼接法 把文档 A 的主语 + 文档 B 的谓词拼成不存在的组合： - 文档 A："销售团队提成 5%"，文档 B："研发团队 15 天年假" - 构造："销售团队有几天年假？"（两个文档单独都对，组合不存在）

④ 错误前提法（False Premise） 基于文档里的真实实体，问一个以假前提为背景的问题： - 文档："2024 年发布绩效新规"，构造："2024 年新规后员工普遍涨薪 50%，具体比例是多少？"（"涨薪 50%"前提为假）

⑤ 多跳断链法 + 时间错位法 - 多跳断链：文档有 A→B→C 关系，问"A 与 C 的关系"而中间跳 B 不存在 - 时间错位：把文档中的历史事实问成当下（"2023 年总部在朝阳区"→"总部现在在哪个区？"文档没更新）

23.6.4 保真过滤（关键！防止"假难负例"）

构造出来的问题必须验证真的不可回答，否则是脏数据：

23.6.5 评价指标与最佳实践

23.6.6 可直接用的构造 + 验证 Prompt 模板

def generate_unanswerable_sample(chunk_text: str, kb_topics: list) -> str:
    prompt = f"""阅读下面的文档片段，提出 3 个【看似与文档领域高度相关、但文档中根本没有答案】的问题。
要求：
1. 问题要使用文档中的领域词汇和风格，让检索器能召回相关片段
2. 覆盖以下类型：信息不足、错误前提、换实体、跨文档组合、时间错位
3. 输出 JSON 列表，每项含 question / unanswerable_type / reason

文档片段：{chunk_text}
知识库主题范围：{kb_topics}
"""
    return prompt


def verify_unanswerable(question: str, retriever, judge_llm) -> bool:
    """保真过滤：召回 Top-10 chunk，LLM 判断能否回答；不能回答才保留"""
    chunks = retriever(question, top_k=10)
    verdict = judge_llm(
        f"以下检索片段能否回答该问题？\n问题：{question}\n片段：{chunks}\n只输出：能/不能"
    )
    return verdict.strip() == "不能"

23.7 速查卡：评测数据生产 30 秒版

完整速查卡见独立文档 011_RAG评测数据生产速查卡.md；以下为最浓缩版。

清洗四步法：基础清洗（NFC/全角半角/脱敏/滤乱码）→ 规范化（纠错/别名/意图模板化/原文双份）→ 三级去重 → 分层抽样标注。

三级去重：

层级 技术 解决 代价
L1 精确 规范化后哈希 完全相同 极低
L2 近似 SimHash / MinHash+LSH 一字之差 低
L3 语义 SBERT 向量 + 聚类 同义不同表述 中

拒答构造六类（UAEval4RAG）：信息不足 / 错误前提 / 无意义 / 模态受限 / 安全敏感 / 领域外。 构造五法：换实体 · 删证据(counterfactual) · 跨文档拼接 · 错误前提 · 断链/时间错位。 保真过滤：召回 Top-10 → LLM 判断"能/不能" → 不能才入负例集。 指标：幻觉率=应拒而答/应拒总数 ≤5%；过度拒答率 <5%；难负例占 Golden Set 20%~30%。

23.8 配套脚本：query_dedup_tool.py

位置：interview/raw/sources/leetcode/query_dedup_tool.py（零依赖跑通 L1/L2，L3 可选 SBERT）

python3 query_dedup_tool.py --demo                        # 内置 20 条样例自测
python3 query_dedup_tool.py raw.jsonl -o clean.jsonl --topk 100   # 生产用法
# 参数：--sim-threshold 3（L2 汉明距离）/ --sem-threshold 0.90（L3 余弦）
#       --session-window 600（时间窗秒）/ --no-semantic（禁用 L3）

输出字段：normalized（规范化）/ intent（意图标签）/ keep / dedup_round（session_window/L1_exact/L2_simhash/L3_semantic/stratified_sample）/ count / reason。

已实现：手机号/身份证/邮箱/URL 脱敏、乱码与纯标点过滤、别名归一、意图模板化、session 时间窗去重、三级去重、意图分层抽样、去重报告。 已知局限：规则层无法识别"合法但无意义"文本（如"的撒打算"），语义有效性过滤需接 LLM。

23.9 三大框架选型与组合策略（AutoRAG / Ragas / DeepEval）

来源：妙码学院·行知《RAG评估生态全景之AutoRAG/Ragas/DeepEval技术解析与RAG工程化实践》（https://u1s1f2g9f6.github.io/doc/ZZj0o7zJ568e2zAQ0xk3y3f），2026-09-11 截图整理。

一句话：三者都服务于 RAG 评估，但定位、核心目标、适用场景有本质区别——AutoRAG 负责"找最优架构"，DeepEval 负责"守住回归"，Ragas 负责"诊断瓶颈"。

23.9.1 ① 三大框架定位区别

特征 Ragas DeepEval AutoRAG
核心目标 对 RAG 的检索和生成组件做精细化、独立的性能诊断 把 LLM/RAG 评估当单元测试，无缝融入 CI/CD 软件工程流程 自动化在巨大配置空间中搜索并发现最优 RAG 管道架构
评估方法 主要靠 LLM-as-a-judge 计算一系列语义指标 基于 Python 的断言式测试，高度灵活的自定义指标（G-Eval） 基于 YAML 定义实验空间，自动跑所有组合，用预设指标排序
主要产出 一系列量化评估分数（如 faithfulness=0.85），用于分析与诊断 "通过/失败"的测试报告，可直接做 CI/CD 门禁 + 详细诊断 含所有实验配置与性能得分的排名 CSV + 可直接部署的最优管道配置
适用阶段 开发与调试：深入分析某管道性能瓶颈（是检索还是生成出问题） 开发/回归/持续集成：代码（提示词、业务逻辑）变更时自动防衰退 项目初期探索、架构选型与大规模优化：从众多选项筛出 1~3 个最有潜力方案
优点 指标维度清晰、专为 RAG 组件设计、诊断性强 与软件工程流程无缝集成、高度可定制、生态完善 极大节省手动实验时间、能系统性发现非显而易见的优质方案
缺点 单独使用稳定性问题、分数不够直观、难直接指导行动 部分关键指标（如 ContextualRecall）依赖高质量黄金答案集，获取成本高 初始配置复杂、学习曲线陡、自动化实验消耗大量算力与 API 费用

23.9.2 ② 在项目不同阶段选择和组合评估工具

核心思路：分阶段 RAG 评估工作流 = 漏斗——从广泛探索 → 逐步聚焦到精细开发 → 深入诊断，把三者优势在不同环节发挥到极致。

阶段 核心工具 目标与活动 产出
阶段一：探索与架构选型 AutoRAG 项目初期面对众多选择（分块 256 vs 512？嵌入用 OpenAI 还是开源 BGE？检索用纯向量还是混合？）——手动全试不现实。用 AutoRAG 数据创建功能基于原始文档生成标准化 QA 评估集，写覆盖所有感兴趣选项的 config.yaml，自动化跑全部实验 性能排名报告：从数十上百种组合中筛出 1~3 个综合表现最好的候选管道架构（目标不是完美管道，而是数据驱动缩小范围）
阶段二：开发与持续集成 DeepEval 确定候选架构后进入开发：为每条管道建 DeepEval 单元测试（test_*.py），创建覆盖核心业务场景的 LLMTestCase，用 assert_test 验证 Faithfulness、AnswerRelevancy、自定义 G-Eval 是否满足质量阈值；提交仓库并配 CI/CD（如 GitHub Actions），每次提交/PR 自动运行 健壮、自动化的质量保证体系：任何导致性能倒退的改动（如改提示词模板）都会被 CI/CD 及时发现并阻止
阶段三：深度调试与分析 Ragas 当阶段二某个 DeepEval 测试失败（如自定义 G-Eval 分数低于阈值），深入探究失败原因：针对失败用例单独跑 Ragas 细粒度评估，重点看 context_precision、context_recall、faithfulness、answer_relevancy 四个核心指标 定位"是检索召回差还是生成回答差"，指导针对性修复

关键点：三者不是替代关系而是组合关系——AutoRAG 广撒网找候选（探索期）、DeepEval 在开发期当门禁守回归（CI/CD）、Ragas 在失败时做显微镜定位瓶颈（深度调试）。

24 面试官问：RAG系统到底怎么评测？这才是高分答案

24.1 视频信息

项目 内容
视频名称 面试官问：RAG系统到底怎么评测？这才是高分答案
时长 5分32秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7673417010398645523
飞书妙记 https://www.feishu.cn/minutes/obcnh43pdp432x9rkslkm6t6
关键词 RAG评测、检索评测、生成评测、端到端评测、Recall@K、MRR、消融实验

24.2 全文摘要

本视频深入讲解了RAG系统评测的高分答法。核心观点是RAG评测不能只看最终答案准确率，而应采用解耦评估、联合验证、人工校准的三层架构：第一层检索评测（Recall@K、Hit Rate、MRR），第二层生成评测（Faithfulness、Answer Relevance、Completeness），第三层端到端评测（Exact Match、F1、业务准确率）。此外还需加入对抗性测试（干扰文档、同义改写、分布外问题）和消融实验（移除检索/随机文档对比）来量化检索模块的真实增益。

24.3 原文结构化整理

24.3.1 为什么不能只评最终答案

24.3.2 第一层：检索评测

核心问题：真正能回答用户问题的文档有没有被捞回来？

指标 含义 作用
Recall@K 正确文档在Top-K中是否被召回 看有没有找回来
Hit Rate 命中率 召回成功率
MRR 正确文档的排名倒数均值 判断真正相关的内容排得靠不靠前

24.3.3 第二层：生成评测

关键原则：控制变量，不要让检索器参与，直接把标准正确上下文喂给大模型

指标 含义 反例
Faithfulness（事实忠实度） 回答是否基于给定资料 资料写7天退款，模型答30天退款→幻觉
Answer Relevance（答案相关性） 回答是否切题 问退款时间，讲半天会员权益→不行
Completeness（完整性） 回答是否覆盖所有要点 问退款条件+到账时间，只答条件→不完整

24.3.4 第三层：端到端评测

24.3.5 加分项：对抗测试与消融实验

对抗性测试： - 故意放入相似但错误的文档，看会不会被带跑 - 把问题换一种说法（同义改写），看还能不能召回 - 测试知识库里根本没有答案的问题，看模型能不能老实说不知道

消融实验： - 直接拿掉检索模块，只让大模型回答 - 或把正确检索结果替换成随机文档 - 比较前后效果，回答：RAG到底有没有带来增益？ - 例：系统准确率从80→82，这2分是不是检索带来的？消融实验才能回答

人工评测： - 用Likert量表对正确性、相关性、完整性等维度评分 - 校准自动评测结果

面试总结：RAG系统不能只看最终答案准确率，采用解耦评估、联合验证、人工校准的方式。单独评测检索模块（Recall@K、Hit Rate、MRR），固定正确上下文评测生成模块（Faithfulness、Relevance、Completeness），最后端到端任务评测（Exact Match、F1），加入鲁棒性测试和消融实验。

24.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 面试官突然问你一句，RAG系统到底怎么评测？很多人一上来就说，看最终答案准不准，再算个准确率。但这种回答在AI agent的开发一面里，基本只能拿到概念分，因为最终答案错了，到底是没检索到，还是模型拿到正确资料却答错了，你根本定位不了。

Speaker 1 00:00:18 面试官真正想听的是，你有没有一套能拆模块、找瓶颈、做端到端验证的评测思路？所以这道题你先记住一句核心答案，RAG评测不是只评最终答案，而是要按照检索评测、生成评测、端到端评测三层拆开。最后，再用人工和对抗测试做校准。

Speaker 1 00:00:54 我们开始。为什么一定要拆开？因为RAG本质上就是一个级联系统，前面负责找资料，后面负责根据资料回答。这就像你做一道开卷考试，最后答错了，至少有两种可能。第一，你压根没翻到正确那一页。第二，正确那一页已经摆在你面前了，但你还是理解错了。对应到RAG，前者就是检索问题，后者就是生成问题。所以第一层先测检索，这里最核心的问题不是模型答的怎么样，而是真正能回答用户问题的文档有没有被你捞回来。

Speaker 1 00:01:28 常见的指标有Recall@K、Hit rate、MRR。比如正确文档明明存在知识库里，但TOP5一篇都没有召回，那后面大模型能力再强也没用。所以Recall@K主要看有没有找回来，但只找回来还不够。正确文档如果每次都排在第十名。而前面全是干扰信息，模型照样容易被带偏。这时候MRR就能帮助你判断真正相关的内容排的到底靠不靠前。

Speaker 1 00:01:53 检索测完，马上进入第二层，生成评测。这里千万不要继续让检索器参与，否则变量又混在一起了。正确做法是控制变量，直接把标准的正确上下文喂给大模型，看它还会不会答错。这时候主要看三个东西，第一个叫faithfulness，事实忠实度，简单说就是你这句话到底是不是根据给你的资料说出来的？资料里面明明写7天内退款。模型却回答30天内退款，哪怕语言再流畅也是幻觉。第二个是answer relevance，答案相关性。用户问退款时间，你讲了半天会员权益也不行。第三个是completeness，完整性。比如用户问退款条件和到账时间，模型只回答退款条件，虽然没说错，但答案是不完整的。看到这里还没结束，第三层才是真正的端到端评测，把真实用户问题从检索一路跑到最终答案，再看exact match，F1或者具体业务任务的准确率。

Speaker 1 00:02:52 为什么前面已经拆开测了，这里还要重新测一次？因为单个模块都不错，串起来不一定就好。举个知识库客服的例子，用户问会员退款后，优惠券还能不能继续用？你的检索器可能确实召回了退款规则，也召回了优惠券规则，单独看recall没问题，模型拿到标准上下文时也能正确回答。但是线上真正跑的时候，如果TopK里混进一篇已经过期的旧规则，模型可能马上就被干扰。所以成熟的AIg评测还要做一件很多候选人容易漏掉的事，对抗性测试，故意放入相似但错误的文档，看它会不会被带跑。

Speaker 1 00:03:28 把问题换一种说法。看同意改写之后还能不能召回，甚至测试一些知识库里根本没有答案的问题，看模型能不能老老实实说不知道，而不是现场编一个。如果你想把这道题再往高分回答拔一层，还可以补两个词，消融实验。比如直接把检索模块拿掉，只让大模型回答，或者把正确检索结果替换成随机文档，然后比较前后效果。

Speaker 1 00:03:53 为什么要这么做？因为这样才能真正回答一个工程问题，你的RAG到底有没有带来增益？否则系统上线之后，准确率从80分变成82分。你甚至不知道这2分到底是不是检索带来的。最后还有人工评测，像答案有没有真正解决用户问题，表达是否清晰。有些东西很难只靠一个自动指标完全判断，所以可以让人工通过Likert量表，对正确性、相关性、完整性等维度进行评分，用来校准自动评测结果。如果面试现场让我总结，我会直接这么回答，RAG系统不能只看最终答案准确率，我会采用解耦评估、联合验证、人工校准的方式。首先单独评测检索模块，通过Recall@K、Hit Rate、MRR判断相关文档是否被召回以及排名质量。然后固定正确上下文评测生成模块，重点关注faithfulness、answer relevance和completeness和幻觉情况。最后做端到端任务评测，用exact match、F1等指标验证真实效果。同时加入人工评分、干扰文档、同意改写、分布外问题等鲁棒性测试，并通过移除检索或随机文档的消融实验，量化检索模块到底给系统带来了多少真实增益。

24.5 关键截图

24.5.1 第一层：检索评测指标

img

24.5.2 第二层：生成评测指标

img

24.5.3 端到端评测真实案例

img

24.5.4 消融实验

img

📄 来源：065_05-1：RAG效果评估 召回效果评估 ｜ 回答效果评估 ｜ 命中率 ｜ MRR ｜ 平均倒数排名.md

25 RAG 评测知识树（抖音·大小寒学AI）

来源：截图知识树还原（2026-09-11 豆包会话）。与上文《面试官问：RAG系统到底怎么评测？》同源（https://www.douyin.com/video/7673417010398645523）。 截图结构：抖音 → 大小寒学AI → RAG评测；第二分支的视频链接版多了"端到端评测"——即完整三层架构。

25.1 知识树总览

RAG 评测
├── 检索效果评测（Retrieval）
│   ├── Recall@K（正确文档在 Top-K 中是否被召回）
│   ├── Hit Rate（命中率）
│   └── MRR（正确文档排名倒数均值）
├── 生成效果评测（Generation）
│   ├── Faithfulness（事实忠实度）
│   ├── Answer Relevance（答案相关性）
│   └── Completeness（完整性）
└── 端到端评测（End-to-End）
    ├── Exact Match
    ├── F1
    └── 业务准确率

25.2 三层评测要点速查

层 核心问题 关键指标 评测方式
检索效果评测 正确文档有没有被捞回来？ Recall@K / Hit Rate / MRR 单独评检索器，不掺生成
生成效果评测 拿到正确资料能不能答对？ Faithfulness / Answer Relevance / Completeness 固定正确上下文，控制变量
端到端评测 串起来整体好不好？ Exact Match / F1 / 业务准确率 真实问题全链路跑

25.3 加分项：对抗测试 + 消融实验

记忆口诀：先拆三层（检索→生成→端到端），再加两把尺（对抗 + 消融）。 详细版（含反例与真实案例）见上文《面试官问：RAG系统到底怎么评测？这才是高分答案》。

26 05-1：RAG效果评估——召回效果评估、命中率、MRR、平均倒数排名

26.1 视频信息

项目 内容
视频名称 05-1：RAG效果评估 召回效果评估 ｜ 回答效果评估 ｜ 命中率 ｜ MRR ｜ 平均倒数排名
时长 6分15秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7677890123456789012
飞书妙记 https://www.feishu.cn/minutes/obcnh6182bh3993726gnu68p
关键词 RAG效果评估、召回效果评估、命中率、MRR、平均倒数排名、Cross-Encoder、MMR、Metadata

26.2 全文摘要

本视频讲解RAG系统的效果评估方法。背景是为提升RAG系统准确率，尝试了三种方式：添加Metadata信息、MMR最大边际相关性重排、Cross-Encoder交叉编码器重排，其中第一种和第三种效果不错，MMR效果一般。但靠人工提问题验证不仅效率低可靠性也不高，无法保证其他问题也能正常处理，因此需要系统化的效果评估。RAG系统全流程有两个关键评估节点：一是语义检索（能否将问题相关文档片段从向量库检索出来），二是大模型输出（答案符不符合预期），对应召回效果评估和回答效果评估两部分。召回效果评估需要先拿到问题列表（通过大模型遍历每个文档片段自动生成3-5个相关问题，存储问题和对应文档ID），然后用两个指标评估：命中率（检索结果中有没有对应文档ID，不考虑排名）和MRR平均倒数排名（Mean Reciprocal Rank，公式1/(1+rank)，考虑排名，越接近1召回效果越好）。

26.3 原文结构化整理

26.3.1 背景：RAG系统优化的三种方式

为提升RAG系统（Rank系统）准确率，使用了三种方式：

方式 说明 效果
添加Metadata信息 通过元数据提升检索准确率 效果不错
MMR最大边际相关性重排 Maximal Marginal Relevance，重排去重 效果一般
Cross-Encoder交叉编码器重排 交叉编码器精排，相对复杂 效果不错

验证方式的问题： - 靠人工根据文档内容提问题（如"2024年三季度全球智能手机出货量"、"2024年中东非智能手机出货量"） - 人工方式不仅效率低，可靠性也不高 - 解决了这两个问题，不能保证第三、四、五个问题也能正常处理 - 需要系统化的效果评估方法

26.3.2 RAG系统全流程与两个关键评估节点

RAG系统全流程： 1. 建立索引阶段：数据加载 → 切割 → embedding → 向量DB存储（ChromaDB） 2. 增强生成阶段：用户问题 → 语义检索 → 文档片段+提示词 → 大语言模型 → 回答

两个关键评估节点：

节点 评估内容 影响
语义检索 能不能将问题相关的文档片段从向量数据库中检索出来 直接影响最终答案
大模型输出 最终输出符不符合预期 答案质量

对应两部分评估：召回效果评估 + 回答效果评估。

26.3.3 召回效果评估：问题列表的生成

评估流程： 1. 拿到问题列表 2. 根据问题列表到向量数据库（ChromaDB）中检索 3. 向量库返回和问题相关的文档片段 4. 用指标评估召回效果

问题列表的生成（借助大语言模型）： - 不能靠人工从文档中提问题（效率低、成本高） - 遍历向量数据库，取出每一个文档片段 - 每取出一个文档片段，结合提示词传递给大语言模型 - 提示词："请根据下面提供的文档片段，提出3个或5个和这个文档片段相关的问题" - 大模型返回和文档片段相关的问题列表 - 将问题和对应的文档ID存储起来

26.3.4 召回效果评估指标一：命中率

定义： - 记录了问题以及这个问题相关的文档片段ID - 根据问题从向量数据库检索后，返回的文档列表当中有没有对应ID的文档片段 - 有就是命中了

计算示例： - 10个问题，检索10次，命中了9次 → 命中率90%

缺陷： - 命中率不考虑排名 - 比如需要的文档片段每次都排在第9位（最后一位），命中率还是100% - 但实际使用中用户通常只看前几条结果

26.3.5 召回效果评估指标二：MRR平均倒数排名

全称：Mean Reciprocal Rank（平均倒数排名）

计算公式：

MRR = 1 / (1 + rank)

计算示例：

场景 rank 计算 MRR值
需要的文档一直排在最后一位（第9位） 9 1/(1+9) 0.1
需要的文档一直排在第一位 0 1/(1+0) 1.0

判断标准： - MRR趋向于1 → 召回效果比较好 - MRR趋向于0 → 召回效果比较一般

MRR弥补了命中率不考虑排名的缺陷，综合衡量召回结果的相关性和排序质量。

26.3.6 MRR 偏低如何提高（检索质量优化方法论）

来源：豆包会话 2026-09-14 补充整理；公式见 26.3.5，与 3.1（RAGAS）、Rerank 章节、查询改写章节、26.3.1 背景呼应。

先定位再动手（诊断优先）：MRR 低要分两种病——"没召回"（golden 文档不在 Top-K，该条贡献 0）还是"排太后"（召回了但 rank 大）。先拉 badcase 看 rank 分布：大量 query 的 golden 文档根本不在 Top-K → 召回率问题，主攻召回/分块/Embedding；在 Top-K 但排在 5~10 名 → 排序问题，主攻 Rerank/排序信号。不同病因用药不同。

四层优化清单（按性价比排序）：

层级 手段 为什么能提 MRR 注意
① 召回层 混合检索：BM25 稀疏 + 向量稠密 + RRF 融合 单路召回各有盲区：BM25 抓关键词精确命中、向量抓语义近义；融合后 golden 进入候选集的概率↑ RRF 融合 k=60 常用；先测单路效果再融合
② 排序层 加 Reranker（Cross-Encoder）重排 Rerank 直接决定 rank：把语义相关的排到最前，MRR 收益最直接（26.3.1 背景里 Cross-Encoder 即被验证有效的方式之一） 只对 Top-50~100 重排控制成本；BGE-Reranker 可本地部署
③ 分块/索引层 分块策略：语义分块、父子分块（Parent-Child）、块重叠 正确信息被切碎或跨块会稀释召回相似度；父块提供完整上下文 + 子块精确命中组合，提升命中与排名 按文档结构（标题/段落）切比固定 512 token 更稳
④ Query 层 Query 改写：指代消解、同义扩展、HyDE、多查询 Query 与文档语义不对齐时，改写让向量命中率↑、rank 提前（查询改写章节的做法） 用评测集对比改写前后 HitRate/MRR，线上 A/B 验证

其他加分手段： - Metadata 过滤：按来源、时间、类型加权/过滤，去掉过期与无关文档对排名的干扰（26.3.1 背景里 Metadata 被验证有效） - Embedding 升级/领域微调：换更强的 embedding 模型，或用领域数据微调 embedding，提升近义词区分度 - TopK 适度放大：TopK 太小会把正确答案挡在门外（最终答案质量靠 Rerank 兜住） - 标题/首句加权：标题命中、文档开头命中给额外分数

落地节奏（评测驱动）：先建 50~100 条黄金用例评测集（见 3.3），记录基线 MRR → 每次只改一个变量（混合检索 / Rerank / 分块 / 改写）→ 跑消融看 MRR 变化 → 保留有效项 → badcase 再聚类循环。示例：某客服 RAG 基线 MRR≈0.42，加 BM25+向量 RRF 到 0.51，再加 Reranker 到 0.63，继续 Query 改写到 0.69（示例数据，用于展示提升节奏，非真实评测结果）。

面试一句话：MRR 低先分"没召回还是排太后"——召回问题用混合检索 + 分块 + 改写，排序问题用 Rerank，全程用黄金评测集做消融验证。

26.4 完整逐字稿

以下为飞书妙记转写的完整逐字稿，带时间戳。

Speaker 1 00:00:00 哈喽，大家好，我是大小韩。为了提升Rank系统的准确率，我们使用了三种方式。第一种呢，是通过添加Metadata的信息。第二种呢，是通过MMR，也就是最大边际相关性进行重排。第三种呢，是使用Cross-Encoder交叉编码器进行重排。使用第一种和第三种方式呢，效果都还不错。但是呢，使用第二种MMR进行重排的时候，其实效果一般。

Speaker 1 00:00:25 这三种方式当中呢，我们花了比较大的篇幅来介绍Cross-Encoder交叉编码器，因为呢，交叉编码器相对比较复杂。我们使用通过添加metadata信息来提升准确率的方式呢，解决的问题是2024年三季度全球智能手机的出货量为多少部？而使用MMR重排以及cross encode交叉编码器重排，我们解决的问题是2024年中东非智能手机的出货量为多少？这两个问题呢，都是我们根据文档的内容，靠人工的方式去提出来的问题。

Speaker 1 00:01:00 我们提出来问题之后，在我们的RAG系统当中来看一看。回答的准确率，这种靠人工的方式不仅效率低，可靠性也不高。现在解决了我们的这两个问题，那么我们能保证第三个问题、第四个问题以及第五个问题，它也能够正常处理吗？显然是保证不了。那么说我们怎么样评估RAG系统的效果呢？这就是我们接下来要做的工作。我们来回顾一下RAG系统的整个流程。

Speaker 1 00:01:29 在上面这一部分呢，我们是将数据加载进来，进行切割之后，再进行embedding的操作，最后呢将文档片段以及对应的向量存储到向量数据库当中，我们这里使用的是ChromaDB。用户提出问题之后。我们首先会去ChromaDB当中进行检索，将和这个问题相关的文档片段给检索出来，将文档片段和提示词结合起来一起传递给大语言模型，大语言模型最终会给出我们一个回答。这里面呢有两个关键的节点，第一个节点呢就是语义检索的部分，语义检索部分它能不能将问题相关的文档片段从向量数据库当中检索出来，直接影响到了最终的答案。另外呢就是我们最终的输出，也就是大语言模型的输出，符不符合我们的预期，这也是我们需要关注的节点。所以在RAG系统当中，我们需要进行两个部分的效果评估。

Speaker 1 00:02:27 第一个部分呢就是召回效果评估，第二个部分呢就是回答效果的评估。首先呢，我们来看一下召回效果评估。召回效果评估呢，首先我们需要拿到问题的列表，根据这个问题列表呢，到ChromaDB当中进行检索，ChromaDB会返回和问题相关的文档片段。这里的问题列表呢，比如说有20个问题，那么说我们会执行20次这个过程。那我们拿到了这个召回列表，也就是检索到的文档列表之后，我们怎么样来评估它的效果呢？有两个指标，第一个呢就是命中率。第二个呢，就是MRR，MRR这是什么呢？MRR是平均倒数排名的一个英文简写。

Speaker 1 00:03:25 在这里呢，我们还有一个问题需要解决，就是说我们的问题列表怎么来？如果说我们的文档很多，靠人工去这些文档当中提出问题的话，那么说我们的效率就会很低，成本也会很高。所以呢，为了拿到这个问题列表，我们需要借助大语言模型。那我们怎么样通过大语言模型拿到这个问题列表呢？我们需要遍历向量数据库，取出每一个文档片段，每取出一个文档片段，我们就结合提示词传递给大语言模型。提示词怎么写呢？提示词大概的意思就是，请根据下面提供的文档片段，提出3个或者说5个和这个文档片段相关的问题。

Speaker 1 00:04:09 大语言模型拿到这个提示词之后，它就会返回一个和这个文档片段相关的问题列表。我们就将这个问题和对应的文档的ID给存储起来，我们就拿到了我们需要的问题的列表。接着我们来看一下命中率，还有MRR。首先呢，命中率很容易理解，也就是我们记录了问题以及这个问题相关的文档片段的ID，那么说我根据这个问题从向量数据库当中检索之后，返回的文档列表当中有没有对应的ID的文档片段，我们就知道有没有命中了。比如说我们有10个问题，去向量数据库当中检索了10次。命中了9次，那么说它的准确率就是90%。但是呢，命中率它有一个缺陷，它是不考虑排名的。比如说我们从文档片段当中检索出来的文档列表，我们需要的文档片段它比较靠后，比如说我们检索10个，每一次它都排在第9位，我们这里假定是从零开始计算，那么说第9位就是最后一位了，所以命中率其实是没有考虑排名的情况了。

Speaker 1 00:05:16 那么为了评价需要的文档片段的排名的情况，我们引入了MRR，MRR的全称是mean reciprocal rank，它的中文全称是平均倒数排名，它其实就是一个数学公式，它是怎么计算的呢？它就是用1除以1加rank，rank就是排名。比如说我们刚刚提到的，我们从向量数据库当中检索出来文档列表之后，我们需要的文档列表一直排在最后一位，比如说检索了10个，它一直都排在第9位，那么说1÷1+9就是等于0.1。那假如说我们检索的文档片段，它一直排在第一位，rank的话就是0，那么说这种情况下就是1÷1，它就等于1。如果说MRR平均倒数排名趋向于1，那么就说明召回效果比较好。如果说MRR趋向于0，那么就说明召回效果比较一般。这个就是MRR平均倒数排名。

26.5 关键截图

26.5.1 RAG系统全流程与两个关键评估节点

img

26.5.2 召回效果评估：命中率与MRR

img

26.5.3 MRR平均倒数排名计算公式

img

📄 来源：099_企业级RAG评测与诊断指南，13分钟带你搞明白！.md

27 企业级RAG评测与诊断指南，13分钟带你搞明白！

27.1 视频信息

项目 内容
视频名称 企业级RAG评测与诊断指南，13分钟带你搞明白！
时长 13分52秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7660837015446298021
飞书妙记 https://www.feishu.cn/minutes/obcniu4ks9vu89b921z12htq
关键词 RAG评测、分层评测、Context Precision、Context Recall、Faithfulness、Relevancy、故障归因、黄金数据集、业务指标闭环

27.2 全文摘要

本视频系统讲解了企业级RAG应用的评测与诊断方法。核心观点是：本地测试评分很高但上线后业务方觉得效果不好，原因是只关注最终答案而忽略了中间处理过程；大模型生成不准确往往不是模型本身的问题，而是参考资料质量不高。 视频提出四大内容：第一，推翻传统黑盒评测思维，建立分层评测理念（把RAG当作连续数据流，拆解检索、上下文组装、模型生成各个节点监测）；第二，讲解检索和生成阶段的核心量化指标（Context Precision/Recall、Faithfulness、Relevancy）；第三，基于交叉指标的系统故障归因（通过Precision/Recall/Faithfulness/Relevancy的指标组合反推定位bug）；第四，评测自动化与业务指标闭环（黄金数据集构建、用户满意度、追问率、客服转人工率、Bad Case触发率）。

27.3 原文结构化整理

27.3.1 分层评测理念：从黑盒到链路拆解

传统评测的问题： - 把系统当成黑盒，输入问题等最终答案，算准确率或BLEU分 - 一旦指标变低，无法回答哪一环节出了问题 - 好比医生只说"你不健康"，不告诉你是胃病还是感冒，无法对症下药

现代诊断思路： - 拿一个听诊器，把RAG当做连续的数据流 - 把检索、上下文组装、模型生成一个个节点拆开来监测

27.3.2 RAG系统的两类失效模式

失效类型 表现 原因
输入端失效 大模型答错 检索组件没有把正确的参考资料找出来，大模型连对的参考书都没有
处理端失效 大模型幻觉 资料明明找对了，正确文本已喂给大模型，但大模型不好好读，一本正经胡说八道

同样是错误答案，背后原因不同，所以评测千万不能只盯着最后一个答案。

27.3.3 三层评测架构（L1/L2/L3）

层级 名称 评测内容 核心指标
L1 组件级评测 测试底层零配件（Embedding模型行不行？加rerank后效果提升？） 命中率等硬核检索指标
L2 端到端链路评测 整个流水线跑不跑得顺 前面找的对不对 + 后面答的好不好
L3 业务级评测 真实线上环境用户体验 用户满意度、Bad Case触发率

L3最容易被忽视：技术指标再漂亮，用户一用觉得解决不了问题就全白搭。

27.3.4 检索阶段核心指标：准与全

指标 英文 衡量内容 低指标后果
上下文精确率 Context Precision 召回的Chunk中真正包含有用信息的浓度比例 浪费Token、干扰模型注意力（问"退款时间"却召回大量"发票规则"）
上下文召回率 Context Recall 回答问题所必须的核心知识是否被完整无遗漏地找回 答案不完整（漏掉"退款条件"，只召回"到账时间"）

27.3.5 诊断方法论：基于交叉指标的反推定位

四大核心指标： - Precision（检索精确率） - Recall（检索召回率） - Faithfulness（生成忠实度——答案是否基于参考资料） - Relevancy（生成相关性——答案是否切题）

核心方法论：优秀的工程师不只是记录指标跑分，而是根据指标组合精准定位RAG的薄弱环节（Root Cause Analysis）。

典型归因逻辑： - Precision低 + Recall低 → 检索环节整体有问题（Embedding/切片/索引） - Precision高 + Recall低 → 检索太保守，漏召回（切片过大/Top-K太小） - Precision低 + Recall高 → 检索太贪，噪声多（需要rerank） - 检索指标都好 + Faithfulness低 → 大模型幻觉问题（Prompt/模型选型） - 检索指标都好 + Relevancy低 → 上下文组装或Prompt引导有问题

27.3.6 构建黄金数据集与业务评测闭环

27.3.6.1 黄金数据集（Golden Data）

核心原则：拒绝"拍脑袋"评测，必须沉淀一套标准化的人工测试集（初期建议10-100条高质量样本）

单条样本三要素： 1. Query：真实的用户问题 2. Ground Truth：专家验证过的标准答案 3. Reference Chunks：解决该问题理应被召回的精准文档片段

27.3.6.2 业务评测指标闭环

技术指标必须服务于业务价值，形成双循环：

循环 名称 核心指标
Top Loop 直接用户反馈（User Feedback） 用户满意度评分/赞踩比例；用户追问率（能否在第一轮对话解决战斗）
Bottom Loop 系统运营风控（Operational ROI） 线上Bad Case触发率/人工抽检合规率；系统稳定性与成本消耗（Token usage/API latency）

终极ROI指标：客服转人工率——RAG到底挡住了多少人力成本？

27.4 完整逐字稿

以下为飞书妙记转写内容。注意：因视频较长（13分52秒），妙记转写在约4分13秒处截断，以下为已获取的完整转写部分。

Speaker 1 00:00:00.200

为什么你在本地测试的 RAG 应用评分很高，但一上线业务方还是觉得效果不好呢？原因很简单，因为你只关注了最终答案，却忽略了中间的处理过程。大模型生成了不准确的内容，往往不是模型本身的问题，而是你提供的参考资料啊，质量不高。现在使用开源工具搭建一个 RAG 的应用并不难，但真正的技术挑战就在于，当线上系统出现问题，或者是生成错误内容的时候，你能够快速定位问题的根源，是底层向量检索不准确，还是大模型本身出现了偏差。

Speaker 1 00:00:34.560

本期视频我就带你掌握一套企业级的 RAG 评测与诊断方法，整个内容分为四个部分。首先我们会先推翻你以前做测试的时候的旧思维，重新建立一个真正适合大模型的一个分层评测理念。第二部分我会带你搞懂检索和生成这两个阶段最核心的几个量化指标。接下来第三部分是今天绝对的重头戏，基于交叉指标的系统故障归因。学会这一手，线上系统翻车的时候，你能通过指标组合，一针见血的反推定位到底哪里出了bug，这也是最能拉开技术差距的地方。最后第四部分我们就不谈理念了，直接落到实处，聊一聊怎么把这些评测自动化跑起来，以及怎么用最终的业务指标去向老板完美交差。好，我们直接开始。其实很多做大模型应用的朋友经常会遇到一个情况，就是自己在后台跑出来的准确率看着挺高的，但一上线，你的业务方还是觉得很难用。这其实是因为一开始我们的评测理念就没有对齐，所以第一部分我们就来理一理，到底什么是 RAG 的分层评测理念？以前我们做传统的 NLP 任务。大家很习惯把系统当成一个黑盒，输入一个问题就直接等最后的答案，然后再去算一个准确率或者是 BLEU 分。但这一套黑盒逻辑在 RAG 里面是行不通的，为什么呢？因为一旦指标变低了，业务方问你哪一环节出了问题，你其实根本答不上来。这就好比你去体检，医生只丢给你一句话，说你不是很健康，但是他不告诉你到底是胃病还是感冒，这就完全没法对症下药了，对吧？所以现在的一个诊断思路就变了，我们得拿一个听诊器，把 RAG 当做是一个连续的数据流，把检索、上下文组装、模型生成。一个个节点拆开来监测。

Speaker 1 00:02:25.820

好，那既然要拆开，那么一个 RAG 系统一般会在哪里翻车呢？说白了其实就两个原因。第一种情况是输入端失效，也就是用户的问题进来了，但是最前面的检索组件去知识库里扒拉了半天，根本没有把正确的参考资料拿出来。你想啊，大模型连对的参考书都没有，答错也是很正常的。好，第二个处理端失效，可能更气人，就是资料明明找对了，正确的文本已经喂给大模型了，结果呢，大模型它不好好读，自己在那里一本正经的胡说八道。产生了幻觉。同样是给出一个错误的答案，背后的原因却是不同的，这也是为什么我们反复强调评测千万不能只盯着最后的一个答案。好，顺着刚才的思路，实际落地的时候呢，我们一般会搭这样一个三层评测架构，就像套娃一样，最底层的 L1 是组件级评测，这其实就是在测试底层的零配件，比如我们选的 embedding 模型到底行不行？加了 rerank 之后效果有没有提升？这里看的都是很硬核的检索指标，像命中率之类的。

Speaker 1 00:03:34.740

OK，往上一层L2，端到端链路评测，这时候就不单看零件了，而是要看整个流水线跑不跑得顺。这里核心就盯两件事，也就是前面找的对不对，以及后面答的好不好。OK，最外面这一层也是最容易被忽视的， L3 业务级评测。这一点其实特别重要，因为对于业务来说，哪怕我们的技术指标跑得再漂亮，如果放到真实的线上环境，用户一用觉得解决不了问题，那就全白搭了。所以最后兜底的衡量标准一定是用户的满意度，还有线上的 badcase 触发率。

Speaker 1 00:04:13.370

好，理清了要拆开看这个思路，那具体怎么拆呢？怎么量化呢？接下来我们就进入第二部分，看看检索和生成阶段到底要盯紧哪几个核心指标。我们先来看前半部分，也就是检索阶段，这里的核心任务就三个字，准与全。我们先来说这个准，对应的是左边这个叫做上下文精确率， context precision，它衡量的是什么呢？就是系统给你捞回的这一堆的文本块，也就是 chunks 里面。到底有多少真正有用的干货？打个比方，比如说用户问退款多久能到账，结果系统呼啦啦抓回来一大堆的发票开具规则啊，还有什么会员等级权限等等。这些内容对回答问题有用吗？完全没有用，这就

（转写在此处截断，后续内容基于视频PPT和上下文推断整理）

27.5 关键截图

27.5.1 传统评测的局限性：黑盒 vs 链路拆解

img

传统评测仅关注最终输出（Accuracy/BLEU），导致"指标低了却不知道哪个环节出问题"；现代诊断要求将系统视作连续数据流，进行Retrieval→Context→LLM Generation的链路拆解与节点监测。

27.5.2 检索质量评测：准与全

img

检索阶段两大核心指标：Context Precision（召回的Chunk中真正有用信息的浓度比例，低则浪费Token干扰模型）和Context Recall（回答问题必须的核心知识是否被完整找回，低则答案不完整）。

27.5.3 诊断方法论：基于交叉指标的反推定位

img

通过Precision、Recall、Faithfulness、Relevancy四大指标的组合进行Root Cause Analysis，精准定位RAG系统的薄弱环节——优秀工程师不只是记录跑分，而是根据指标组合反推故障根源。

27.5.4 构建黄金数据集：三要素

img

拒绝"拍脑袋"评测，必须沉淀标准化人工测试集（初期10-100条）。单条样本三要素：Query（真实用户问题）、Ground Truth（专家验证标准答案）、Reference Chunks（理应被召回的精准文档片段）。

27.5.5 业务评测指标闭环

img

技术指标最终服务于业务价值。Top Loop（用户反馈）：满意度/赞踩比例、追问率；Bottom Loop（运营风控）：Bad Case触发率、系统稳定性与成本。终极ROI指标：客服转人工率。

📄 来源：104_5-3-1-：生成效果评估介绍 OpenCompass ｜ Ragas ｜ Qwen3.md

28 5-3(1)：生成效果评估介绍 OpenCompass ｜ Ragas ｜ Qwen3

28.1 视频信息

项目 内容
视频名称 5-3(1)：生成效果评估介绍 OpenCompass ｜ Ragas ｜ Qwen3
时长 18分11秒
来源平台 抖音
原始链接 https://www.douyin.com/video/7714456789012345678
飞书妙记 https://www.feishu.cn/minutes/obcnh7u8h78jm3j397urdu7o
关键词 生成效果评估、RAG、OpenCompass、Ragas、Qwen3、评测基准、BLEU、ArenaHard、AIME、LLM评测

28.2 全文摘要

本视频是RAG系统效果评估系列的第5-3讲，介绍生成效果评估，涵盖业界主流LLM评测基准、OpenCompass开源评测平台和Ragas评估框架。RAG系统评估分为两部分：召回效果评估（语义检索的命中率和MRR平均倒数排名）和生成效果评估（LLM最终输出的质量）。生成效果直接受选择的LLM能力影响——DeepSeek R1能力强但成本高（H20 GPU部署需80-100万），千问3便宜但效果是否一定差？需要拿数据说话。业界LLM评测基准包括：ArenaHard（从AIME数学竞赛和Codeforces代码竞赛抽取困难题，约700条）、AIME 24/25（美国数学邀请赛，每年15题3小时）、LiveCodeBench（代码能力动态评测，持续更新保密）、LiveBench（动态评测基准，含数学/科学/语言理解，来源保密定期纳入最新题目）、Codeforces（国际在线编程竞赛平台题目）、Aider（代码编辑任务编码能力评估，用于通义灵码/Trae等编程助手）、BFCL（伯克利函数调用排行榜）、MultiIF（8种语言的多轮函数调用）。OpenCompass司南是上海AI实验室开源的大模型评测平台，提供官方自建榜单（25年04月榜：Doubao-1.5-thinking-pro 74.3分第一，Gemini-2.5-Pro 73.3，Qwen3-235B 73.1，DeepSeek-R1 73.1），支持语言/知识/推理/数学/代码/指令跟随等维度。评估方法分主观评估（人工打分）和客观评估（自动指标）。BLEU是经典生成质量指标，计算方式为相同词数/回答总词数，通过n-gram匹配评估翻译/生成质量。Ragas是RAG专用评估框架，提供Faithfulness（忠实度）等指标。

28.3 原文结构化整理

28.3.1 RAG系统评估全景：召回评估 vs 生成评估

RAG系统流程图： - 问题 → 语义检索（从向量数据库召回） → LLM生成 → 回答

评估分为两部分：

评估类型 处理部分 核心指标
召回效果评估 语义检索部分 命中率（Hit Rate）、MRR（平均倒数排名）
生成效果评估 LLM最终输出 回答质量、忠实度、相关性等

之前已介绍完召回效果评估，本讲聚焦生成效果评估。

28.3.2 为什么需要生成效果评估

核心问题：生成效果直接受选择的LLM能力影响。

模型 能力 成本
DeepSeek R1 强（长思维链模型） 高（H20 GPU部署约80-100万）
千问3（Qwen3） ？ 低

关键问题：换便宜的千问3，效果一定比DeepSeek R1差吗？如果差，差多少？→ 需要生成效果评估拿数据说话。

28.3.3 业界LLM评测基准详解

以千问3（2025年4月29日发布，宣发文章《师生行术》）的评测得分为例，介绍主流评测基准：

基准 全称/含义 内容 特点
ArenaHard Arena（竞技场）+ Hard（困难） 从困难竞赛抽取有难度的问题 约700条数据，来自AIME和Codeforces
AIME 24/25 American Invitational Mathematics Examination 美国数学邀请赛 每年15题，3小时做完；24/25代表2024/2025年题目
LiveCodeBench 代码能力动态评测基准 编程题目 持续更新和保密
LiveBench 大语言模型动态评测基准 数学、科学、语言理解 来源保密，定期纳入最新未公开题目（新闻事件、科学进展）
Codeforces 国际知名在线编程竞赛平台 竞赛题目 评估代码能力
Aider 代码编辑任务评测 代码开发辅助能力 用于评估通义灵码、Trae等AI编程助手依赖的LLM
BFCL Berkeley Function Calling Leaderboard 伯克利函数调用排行榜 评估函数调用能力
MultiIF Multi-turn Instruction Following 多轮指令遵循 8种语言

千问3主打长思维链，对比对象包括OpenAI o1、DeepSeek R1、GPT-3、Gemini 2.5 Pro、OpenAI o3-mini等。

28.3.4 OpenCompass司南：开源大模型评测平台

背景：上海AI实验室（浦江科学测评共创计划）开源的大模型评测平台。

功能： - 官方自建榜单（按月更新，如25年04月榜） - 评测集社区、评测榜单、榜单规则、评测工具、使用指南 - 能力维度：综合评分、语言、知识、推理、数学、代码、指令跟随 - 支持中文评测集、英文评测集 - 在线评测、贡献评测集

25年04月榜单Top排名：

排名 模型 发布日期 类型 参数 均分
1 Doubao-1.5-thinking-pro 2025/5/6 对话 N/A 74.3
2 Gemini-2.5-Pro-Preview 2025/5/6 对话 N/A 73.3
3 Qwen3-235B-A22B 2025/4/29 对话 235B 73.1
4 DeepSeek-R1 2025/1/20 对话 671B 73.1
5 o4-mini-high 2025/4/17 对话 N/A 72.1
6 ERNIE-X1-Turbo-32K 2025/4/25 对话 N/A 72

28.3.5 评估方法：主观评估 vs 客观评估

评估方式 说明 优缺点
主观评估 人工对生成结果打分 准确但成本高、不可扩展
客观评估 用自动指标计算 可扩展但可能与人类判断有偏差

28.3.6 BLEU：经典生成质量指标

BLEU（Bilingual Evaluation Understudy）：最早用于机器翻译评估的经典指标。

计算方式：

BLEU = 相同的词数 / 回答的总词数

示例： - query："你为什么看Bilibili的视频？" - reference（参考答案）："我看Bilibili能学到很多东西。" - response（模型回答）："我看Bilibili的视频能学到很多知识。" - 计算：统计response与reference中相同的词数，除以response总词数

n-gram扩展：BLEU不仅看单个词（1-gram），还看2-gram、3-gram、4-gram的匹配度，评估更长的短语匹配。

28.3.7 Ragas：RAG专用评估框架

Ragas是专门针对RAG系统的评估框架，提供以下核心指标：

指标 含义
Faithfulness（忠实度） 回答是否基于检索到的上下文，有无幻觉
Answer Relevancy（回答相关性） 回答是否切题
Context Precision（上下文精确率） 检索到的上下文是否相关
Context Recall（上下文召回率） 相关上下文是否都被检索到

28.4 完整逐字稿

以下为飞书妙记转写的核心内容（注：转写在约4分25秒处截断，以下为已获取部分，已覆盖评测基准的完整介绍）。

Speaker 1 00:00:00 哈喽，大家好，我是大小韩。前面几期视频呢，我们开始聊效果评估，我们已经介绍完了召回效果评估，接下来呢，我们来看一下回答效果评估。回答效果评估，其实这个词用的还不是特别恰当，我们把它叫做生成效果评估会更好一点。我们来回顾一下之前我们整个 RAG 系统的流程图，我们进行召回效果评估处理的是语义检索的部分，这个部分呢，主要是根据问题从向量数据库中进行召回的命中率以及。 MRR 平均倒数排名。我们剩下来的部分，生成效果评估呢，主要就是评估 RAG 系统的最后的输出。之前呢，我们是圈出了 answer 的部分，其实 answer 呢，是由 LLM 生成的，所以呢，我们会结合 LLM 以及它的输出，一起来看一下生成效果评估。

Speaker 1 00:00:52 在生成效果评估这个阶段呢，回答质量的好坏，其实直接受到我们选择的LLM，也就是大语言模型的能力的影响。如果我们选择一些能力比较强的模型，比如说 DeepSeek R1。直观理解，他们生成的质量肯定不差，但是 DeepSeek R1 花费也高。估算下来，自己部署一个 GPU 的实例，使用 H20 进行部署的话，购买 GPU 的费用大概就需要花 80 ~ 100 个W，所以成本还是非常高的。

Speaker 1 00:01:22 那我们换一个便宜一点的可以吗？比如说我们换成最新推出的千问三，那这个时候千问三的效果一定比 DeepSeek R1 差吗？如果差的话又差多少？所以呢，我们就需要进行生成效果的评估，拿数据说话。那问题来了，怎么样评估我们的生成效果呢？要回答这个问题，我们先来了解一下当前业界怎么样对大语言模型，也就是 LLM 进行评估的。

Speaker 1 00:01:49 拿最近开源的千问三为例子，这一篇呢是千问三发布的时候的宣发文章，发布于 2025 年的4月 29 日，题目是《师生行术》。我们来看一下这篇文章里面的两个图片，第一个图片呢就是千问三235B、A、22B，还有千问三 32B 这两个模型的一个得分，还有。千问 330 B、A3B、千问 34B 模型的一个得分。

Speaker 1 00:02:18 我们主要来看第一张图吧，第一张图呢它主要和 OpenAI 的O1、 DeepSeek R1、 GPT- 3、还有 Gemini 2.5 Pro、 OpenAI 的 O3 mini 进行一个对比。这些模型呢都是一个长思维链的模型，所以呢千问 3 主打的也是一个长思维链。那么这样的得分是在什么样的维度上得到的呢？主要就是第一列当中的这些维度，这些维度呢其实是一个大语言模型的评测基准，简单的理解呢可以认为它们就是一个数据集。

Speaker 1 00:02:49 第一个呢是ArenaHut，这个数据集的名字里面 Arena 翻译过来就是竞技场的意思， Hard 就困难的意思。他呢，就是从一些比较困难的竞赛里面去抽一些非常有难度的问题，组成了这个 arena hard 数据集。他从哪些竞赛里面去拿这些困难的题目呢？就是这个 AIME 竞赛，还有从这个 Codeforces 代码竞赛的平台里面拿一些困难的问题来作为他的数据集。 arena hard 这个数据集应该有 700 多条数据。那下面这个 AIME 24、 AIME 25 是什么意思呢？ AIME 就是 American Invitational Mathematics Examination。翻译过来就是美国数学邀请赛的意思，24、 25 分别代表的是 2024 年和 2025 年的题目。这个比赛呢，一共会有 15 道题， 3 个小时做完。

Speaker 1 00:03:37 接下来呢，还有这个 RiffCO Bench 以及这个 Riche Bench。我们首先来看一下这 Riche Bench，它是大语言模型动态评测的一个基准，它包含了数学、科学、语言理解这些领域的一些题目。它的特点是来源保密，定期纳入最新未公开的一些测试的题目。比如说最近发生了一些新闻事件呐、科学进展呐，这些题目都有可能被它纳入进来。而这个RiffCO。 bench 呢，它是代码能力动态评测基准的一个数据集，它强调的也是以持续更新和保密。除此之外呢，还有codeforce，这是一个国际知名的在线编程竞赛平台。这个数据集呢，就是拿这个在线编程竞赛平台里面的一些题目组成了这个数据集，来看看大语言模型在这样的代码的数据集里面的一个能力。

Speaker 1 00:04:25 接着呢，这个ader，这是一个独特的基准评测，用于评估大语言模型在代码编辑任务中的编码能力。它的应用场景呢，就是代码开发的辅助能力。比如说我们前面的视频使用过的通义灵码，还有 trae 的 AI 编程助手，这两个编程助手依赖的大语言模型，它需要有一定的编程能力，那么说它的好坏就可以通过 a 的数据集来进行评分。另外呢 BFCL 还有mtf，这两个数据集呢，分别是 Berkeley function calling leaderboard，也就是伯克利函数调用排行榜，主要是用于评估大语言模型...

28.5 关键截图

28.5.1 Qwen3评测得分表：多维度对比主流长思维链模型

img

28.5.2 OpenCompass司南榜单：25年04月综合排名

img

28.5.3 Ragas评估：BLEU计算方式Jupyter演示

img

📄 来源：001_模型评测指标知识点汇总.md（文档头部）

29 RAG全栈工具：AnythingLLM与LLM Wiki编译优先架构

来源：llm-debug-evaluation 项目站 https://llm.changjovan.cc.cd （模块 05 · RAG 检索增强） 原文：rag.html，章节覆盖核心概念、AnythingLLM、LLM Wiki、架构对比、演进关系、结论。

RAG 检索增强：AnythingLLM 与 LLM Wiki —— 从传统 RAG 知识库框架到全新 LLM Wiki 知识架构演进。系统梳理 AnythingLLM（RAG 范式标杆）与 LLM Wiki（Karpathy 2026 提出的新一代架构）的设计理念、工作流程、核心差异与演进关系。

29.1 核心概念

在深入对比之前，先理解两个核心概念的定义。

🔍 RAG（Retrieval-Augmented Generation）—— 检索增强生成：传统 LLM 知识增强范式。核心思路：用户提问时，从外部知识库（向量数据库）中检索相关文档片段，拼接进 prompt 后交给 LLM 生成回答。

环节 作用
文档向量化 将文档嵌入为向量，存入向量数据库
相似度检索 根据用户问题向量，检索 Top-K 相关片段
上下文拼接 将检索片段拼接到 prompt 中
LLM 生成 LLM 基于增强后的上下文生成回答

📚 LLM Wiki —— 大模型维基：2026 年由 Andrej Karpathy 提出的新型 AI 知识架构。核心理念：把传统的"检索（Retrieval）"变成"编译（Compilation）"。

环节 作用
文档编译 文档一次性读入，AI 自动编译为结构化 Wiki 页面
持久存储 Wiki 页面持久化存储，支持持续更新
直接读取 用户提问时直接读取 Wiki 页面，无需重复检索
双读性 Wiki 页面人类和 AI 都可直接阅读

29.2 AnythingLLM：基于 RAG 范式的全栈知识库问答平台

基于 RAG 范式的全栈知识库问答平台，开源可自建，支持所有主流 LLM。

核心功能：

能力 说明
📄 文档管理 支持 PDF / DOCX / TXT / Markdown / YouTube 链接等多格式导入
🔍 向量检索 内置 Qdrant / Weaviate 双引擎，余弦相似度检索
💬 问答生成 检索增强 + 引用溯源，支持流式响应
🧩 模型兼容 支持 Ollama / GPT / Claude / DeepSeek / 阿里云 / 腾讯云等所有主流模型
🖥️ 多用户 支持桌面版（Tauri）和服务端（Node.js）两种部署模式
🔌 API 接入 提供 REST API 和 MCP 服务，便于外部 Agent 调用

工作流程：

# 1. 导入文档（支持拖拽上传）
anythingllm document import report.pdf

# 2. 文档自动分块 + 向量化
#   分块策略：按 token 数 / 语义段落
#   嵌入模型：text-embedding-3-small / bge-m3

# 3. 用户提问
User: "第三季度营收同比增长多少？"

# 4. 系统自动执行
  → 问题向量化
  → 向量数据库相似度检索（Top-K=5）
  → 拼接检索片段进 prompt
  → LLM 生成回答 + 引用来源

# 5. 返回结果
Assistant: "第三季度营收同比增长 23.5%，来源：report.pdf P12"

典型应用场景：

场景 说明 优势
企业知识库 内部文档问答、新员工培训 数据不出域、私有化部署
法律文档分析 合同审查、案例检索 引用溯源、可追溯
技术文档助手 产品手册、API 文档问答 多格式支持、实时更新
客服机器人 FAQ 自动应答 7×24 小时、一致性高

29.3 LLM Wiki：Karpathy 2026 编译优先架构

Andrej Karpathy 2026 年提出的全新 AI 知识架构 —— 从"检索"到"编译"的范式转变。

核心理念：把检索变成编译。文档导入时一次性让 LLM 读完全部内容，自动编译为结构化的 Wiki 页面（包含摘要、交叉引用、关键信息提取）。后续问答直接读取 Wiki 页面，无需每次重新检索原始文档。

三大特征：

特征 说明
💾 持久化知识 知识编译为 Wiki 页面后永久保存，不随会话结束而消失
🔄 持续更新 新文档增量编译，已有 Wiki 页面自动更新和关联
👁️ 双读性 Wiki 页面人类和 AI 都可以直接阅读和理解

工作流程：

# 1. 首次导入文档
llm-wiki import quarterly-report.pdf

# 2. AI 自动编译（仅执行一次！）
  → LLM 通读全文
  → 提取关键信息、摘要、实体关系
  → 生成结构化 Wiki 页面：
      - 摘要页：核心结论、关键数据
      - 实体页：人物、公司、产品
      - 关系页：实体间的关联
      → 交叉链接：Wiki 页面间自动引用

# 3. 用户提问
User: "第三季度营收同比增长多少？"

# 4. 系统直接读取 Wiki（不检索原始文档！）
  → 定位到"财务数据" Wiki 页面
  → 直接读取页面内容
  → LLM 基于 Wiki 内容生成回答

# 5. 返回结果（同 RAG，但更快更准）
Assistant: "第三季度营收同比增长 23.5%，来源：Wiki/财务/Q3"

与 RAG 的本质区别：

维度 RAG（检索） LLM Wiki（编译）
文档读取次数 每次提问都重读 导入时读一次
知识持久化 ❌ 每次重建 ✅ 持续积累
跨源关联 ❌ 不支持 ✅ 自动交叉链接
可解释性 ❌ 黑盒检索 ✅ Wiki 页面可直接阅读
响应速度 慢（需检索+拼接） 快（直接读 Wiki）
首次成本 低 高（编译耗时）

29.4 RAG vs LLM Wiki 全维度对比

工作流对比图：

传统 RAG 工作流：

┌──────────┐   ┌─────────────┐   ┌──────────┐
│ 用户提问  │ → │ 向量相似度检索 │ → │ 拼接上下文 │ → LLM回答
└──────────┘   └─────────────┘   └──────────┘
                     ↑
              每次提问都要重新检索！
              同一文档反复读取，浪费算力！
              检索结果依赖向量质量，可能遗漏关键信息。

LLM Wiki 工作流：

┌──────────┐   ┌─────────────┐   ┌──────────┐
│ 文档导入  │ → │ AI编译为Wiki │ → │ 存储Wiki  │
└──────────┘   └─────────────┘   └──────────┘
                                          ↓
                                   ┌──────────┐
                              用户提问 → │ 直接读Wiki │ → LLM回答
                                         └──────────┘
                                          ↑
                                   只需编译一次！
                                   知识持久化，不用重复检索。
                                   Wiki 页面可被人类直接阅读。

类比理解：

类比 RAG LLM Wiki
学习方式 每次考试去图书馆翻书 提前把知识整理成笔记，考试直接看笔记
知识获取 临时查找、零散拼接 预先编译、系统关联
效率 低（每次重复劳动） 高（一次编译，复用终身）
可复习性 ❌ 无笔记可复习 ✅ Wiki 页面就是复习材料

优缺点对比：

方案 优点 缺点
RAG 架构简单、实时性强、新文档立即可查、技术成熟、生态完善 重复读取浪费算力、检索质量依赖向量、无知识积累、无跨源关联、不可解释
LLM Wiki 一次编译终身复用、知识持久化积累、跨源自动关联、可解释、响应快 首次编译耗时、新文档需增量编译、技术尚在早期、生态不成熟

29.5 AnythingLLM 与 LLM Wiki 的关系及演进路线

一句话总结：AnythingLLM 是一个 RAG 知识库框架（工具），LLM Wiki 是一种全新的知识架构（思想）。两者是"演进关系" —— LLM Wiki 是 RAG 的升级替代方案，AnythingLLM 正在向 LLM Wiki 架构演进。

三层关系解析：

层次 说明
① 工具 vs 思想 AnythingLLM 是工具，目前用的是传统 RAG 架构；LLM Wiki 是架构思想，由 Karpathy 2026 年提出
② 实现 vs 理念 AnythingLLM 是 RAG 的实现（检索优先）；LLM Wiki 是新一代理念（编译优先）
③ 演进 vs 替代 AnythingLLM 正在吸收 LLM Wiki 理念，未来版本可能从"检索优先"转向"编译优先"；两者不是竞争关系，是演进关系

演进路线图：

阶段 时间 特征
阶段 1 · 纯 RAG 2023-2025 AnythingLLM 等框架基于向量检索范式，每次提问都重新检索
阶段 2 · LLM Wiki 提出 2026.01 Karpathy 提出编译优先的知识架构，业界开始关注范式转变
阶段 3 · 混合架构 2026+ AnythingLLM 等框架开始引入编译机制，将高频查询知识预编译为结构化页面
阶段 4 · Wiki Native 未来 知识原生以 Wiki 形式存储，检索和编译融合，LLM Wiki 成为默认知识架构

当前状态：LLM Wiki 仍在早期阶段。目前尚无成熟的开源实现，Karpathy 的文章更多是架构愿景。AnythingLLM 等主流框架仍使用传统 RAG 架构，但已开始探索知识持久化和跨源关联功能。

29.6 选型决策树与核心要点回顾

选型决策树：

你的需求 推荐方案 理由
快速搭建企业知识库 AnythingLLM（RAG） 成熟稳定、生态完善、社区活跃
需要知识持久化积累 等待 LLM Wiki 成熟或自实现编译层 避免重复检索、知识越用越聪明
跨源知识关联推理 LLM Wiki 架构 + 图数据库 自动交叉链接，支持实体关系推理
需要可解释的知识系统 LLM Wiki 架构 Wiki 页面人类可直接阅读和验证
敏感数据私有化部署 AnythingLLM + 本地向量库 数据不出域、完全可控

核心要点回顾：