- [RAG完整原理概念总结](https://dkblog.guosgbin.cn/article/llm-rag-question#rag-完整原理概念总结) - [RAG解决什么问题？](https://dkblog.guosgbin.cn/article/llm-rag-question#rag-解决什么问题) - [RAG文档是怎么存？粒度是多大？文档切割策略？](https://dkblog.guosgbin.cn/article/llm-rag-question#rag-文档是怎么存粒度是多大文档切割策略) - [怎么规避语义被切割掉的问题？](https://dkblog.guosgbin.cn/article/llm-rag-question#怎么规避语义被切割掉的问题) - [Embedding是什么？如何选择和评估Embedding模型？](https://dkblog.guosgbin.cn/article/llm-rag-question#embedding-是什么如何选择和评估-embedding-模型) - [向量数据库？向量数据库的对比选型？](https://dkblog.guosgbin.cn/article/llm-rag-question#向量数据库向量数据库的对比选型) - [使用RAG给大模型一个输入，系统的工作流程？](https://dkblog.guosgbin.cn/article/llm-rag-question#使用-rag-给大模型一个输入系统的工作流程) - [向量检索与关键词检索](https://dkblog.guosgbin.cn/article/llm-rag-question#向量检索与关键词检索) - [润色用户的Query（QueryRewrite）？目的？](https://dkblog.guosgbin.cn/article/llm-rag-question#润色用户的-queryquery-rewrite目的) - [什么是多路召回？具体怎么做？](https://dkblog.guosgbin.cn/article/llm-rag-question#什么是多路召回具体怎么做) - [RAG检索优化策略有哪些？](https://dkblog.guosgbin.cn/article/llm-rag-question#rag-检索优化策略有哪些) - [了解哪些更复杂的RAG范式？](https://dkblog.guosgbin.cn/article/llm-rag-question#了解哪些更复杂的-rag-范式) - [在什么场景下，图数据库来增强传统的向量检索？](https://dkblog.guosgbin.cn/article/llm-rag-question#在什么场景下图数据库来增强传统的向量检索) - [如何规避RAG系统中大模型的幻觉？](https://dkblog.guosgbin.cn/article/llm-rag-question#如何规避-rag-系统中大模型的幻觉) - [怎么量化你的RAG效果？](https://dkblog.guosgbin.cn/article/llm-rag-question#怎么量化你的-rag-效果) - [Hit@K和MRR是什么](https://dkblog.guosgbin.cn/article/llm-rag-question#hitk-和-mrr-是什么) - [RAGAS框架是什么](https://dkblog.guosgbin.cn/article/llm-rag-question#ragas-框架是什么) - [RAG知识库如何实现动态与持续更新？](https://dkblog.guosgbin.cn/article/llm-rag-question#rag-知识库如何实现动态与持续更新) - [RAG你觉得最难的地方是哪里](https://dkblog.guosgbin.cn/article/llm-rag-question#rag-你觉得最难的地方是哪里) ## RAG 完整原理概念总结

RAG 全称检索增强生成，核心思想是不修改大模型的权重参数，通过外部知识库检索，为大模型提供私有或者最新的参考资料，以此弥补大模型知识截止的缺陷。 RAG 整体分为**离线预处理和在线推理**两个阶段。离线阶段主要用来构建知识库。首先加载各类原始文档，之后对文档做分块处理，得到文本片段。分块需要控制块大小，同时设置块重叠，避免语义被切断。**接下来使用 Embedding 模型**，把每一个文本片段转化为高维向量，语义相近的文本向量距离更近。最后把向量、原文和元数据存入向量数据库，完成知识库构建，支持增量更新。在线阶段是用户提问时实时执行。首先对用户的查询做预处理改写，优化检索效果。之后把查询向量化，在向量库做相似度检索，粗排召回一批候选片段**。粗排速度快，但会引入噪声，因此会经过 Rerank 精排，使用 Cross‑Encoder 模型计算查询和片段的真实相关性，过滤无效内容，保留高相关片段。** 最后把用户问题和筛选后的参考上下文组装成 Prompt 交给大模型，由大模型基于检索到的资料生成答案。 RAG 的优势是知识更新成本低，不需要重训模型，同时回答可以溯源；但 RAG 只能缓解幻觉，不能彻底消除幻觉。

**一、定义** RAG（Retrieval‑Augmented Generation，检索增强生成），是一种大模型应用架构。**不修改大模型权重参数**，在推理阶段引入外部知识库检索得到参考上下文，将检索上下文与用户问题共同送入大模型，辅助模型生成答案。用于解决大模型训练数据截止、缺少私有领域知识、知识更新成本高的问题。 RAG 分为**离线预处理阶段**、**在线推理阶段**两个独立阶段。 --- **二、离线预处理阶段（知识库构建，可增量执行）** 1. **文档加载**：解析 PDF、Word、Markdown、网页等异构数据源，提取原始文本内容。 2. **文档分块** Chunking：将长文档切分为多个文本片段 chunk。 - 约束：Embedding 模型存在 token 上限；完整长文本向量化会造成语义信息被平均稀释。 - 参数：chunk_size 控制单块 token 长度；chunk_overlap 块重叠，避免语义被切分边界截断。 3. **Embedding 向量化**：使用 Embedding 模型将文本 chunk 转换为高维数值向量。基于对比学习训练，语义相近的文本，向量空间距离更近，实现语义层面的匹配，而非关键词匹配。 4. **向量入库**：将向量、原始 chunk 文本、文档元数据（来源、页码等）存入向量数据库。向量数据库针对高维向量的相似度检索做专门优化，支持大规模向量快速检索，支持增量更新知识库。 --- **三、在线推理阶段（用户每次提问执行）** 1. **Query 预处理**：对用户输入查询做处理，包含查询改写、补全对话上下文、多查询生成，优化查询，提升检索召回质量。 2. **粗排（向量召回）**：将用户查询向量化，在向量数据库执行相似度检索，返回 Top‑K 候选 chunk。 - 特点：速度快；仅计算向量空间距离，无法深度理解语义，召回结果存在噪声。 3. **Rerank 精排**：采用 Cross‑Encoder 重排模型，将查询与候选 chunk 成对输入模型，计算真实语义相关性分数，重新排序，过滤无关内容，保留少量高相关性片段。 - 特点：精度高，计算开销大；仅对粗排输出的小候选集执行，不对全库运算。 4. **Prompt 组装与生成**：将用户原始问题、筛选后的参考 chunk 组装为 Prompt，增加约束指令，送入大模型生成最终回答。可携带元数据实现回答内容溯源。 --- **四、RAG 核心特性** 1. 知识热更新：新增、删除知识仅操作向量库，无需重新训练或微调大模型。 2. 可溯源：生成答案可关联原始文档片段，便于定位错误来源。 3. 无法完全消除大模型幻觉，仅能通过流程手段缓解。 ## RAG 解决什么问题？

RAG 全称检索增强生成，核心作用是**解决大模型知识冻结带来的三类核心问题**，整体设计思路是**实现知识与模型参数的解耦**，全程不修改大模型权重参数。首先，大模型的知识全部编码在预训练参数中，训练完成后参数固定，存在天然的知识局限性，具体分为三点。第一是**知识时效性缺陷**，模型训练数据有明确截止时间，无法获取后续新增、迭代的知识，容易输出过期内容。第二是**私有知识空白**，企业内部业务文档、行业专属数据不会进入公开训练集，模型天生不具备私有领域知识，无法应答专属业务问题。第三是**模型幻觉问题**，这一问题的本质是知识缺失的副产品，大模型基于 Token 预测机制生成内容，在无对应知识支撑时，会自主编造看似合理的错误答案。而 RAG 针对性解决了以上问题，核心方案是**将知识外置存储、实时检索注入上下文**。我们将各类业务文档、最新知识预处理后存入向量数据库，构建外部知识库。用户发起提问时，系统会实时检索匹配的相关知识片段，将用户问题与检索到的真实资料拼接为规范 Prompt，输入大模型生成答案。这种架构的核心优势有三点：**知识可动态热更新**，无需重训模型，成本极低；**补齐私有与实时知识短板**，适配企业业务场景；**从根源缓解模型幻觉**，答案可溯源、可校验，大幅提升生成内容的准确性和可信度。

**一、核心根因：LLM 知识冻结特性** 大模型的所有知识均在预训练阶段编码至模型参数权重中，模型训练完成后，参数固定不可自动更新，该特性被称为知识冻结。重新训练或微调模型成本极高、周期长，且微调知识无法溯源，无法高效解决模型知识缺陷问题。知识冻结会衍生三大核心问题，也是 RAG 针对性解决的问题： - **知识时效性问题**：模型训练数据存在固定截止日期，无法获取截止日期之后的新增、更新知识，会基于过期信息输出结果，准确性不足。 - **私有知识空白问题**：企业内部文档、行业专属规范、私有业务数据等未纳入公开预训练数据集，模型天生不具备此类知识，无法应答私有业务问题。 - **模型幻觉问题**：幻觉并非模型固有缺陷，而是知识缺失的副产品。大模型核心运行机制为预测下一个 Token，无内置“未知即停止”的逻辑。当模型参数内无对应知识时，会自主拼凑看似合理、实际错误的内容，造成输出失真。 --- **二、RAG 核心解决思路** RAG（检索增强生成）核心原理是**将知识与模型参数解耦**，不修改、不微调大模型权重参数。将所有知识存储于外部向量知识库，用户提问时，实时检索知识库中的相关内容片段，将检索上下文与用户问题拼接为 Prompt 输入大模型，让模型依托真实参考资料生成答案。 --- **三、RAG 对应的解决方案价值** - 解决时效性问题：支持知识库动态增量更新，新增、更新知识直接入库，无需重训模型，实时生效。 - 解决私有知识问题：私有业务文档预处理入库后，模型可依托检索内容应答专属业务问题，填补知识空白。 - 缓解模型幻觉：为模型提供真实、可溯源的参考依据，约束模型基于资料生成内容，大幅降低凭空编造的概率，同时支持答案溯源校验，提升输出可信度。 ## RAG 文档是怎么存？粒度是多大？文档切割策略？

RAG 的文档**不能整篇直接存入向量数据库**，需要先切分成多个 chunk 片段，每一个片段作为向量库的一条记录。每条记录包含三部分：**向量、原始文本、元数据**。向量用于相似度检索，原始文本检索后交给大模型读取，元数据用于过滤和溯源。 chunk 的粒度是权衡的结果，chunk 过大语义混杂，过小语义残缺。工程上一般以**500‑1000 token**作为基准起点，再结合文档类型调整。最基础的策略是**固定大小切割搭配 overlap 重叠**，按 token 长度切分，相邻块保留部分重叠内容，避免语义被边界切断，适合无结构纯文本，缺点是可能截断句子。更好的方案是**语义边界切割**，顺着段落、句子、标题等天然断点切分，保证每个 chunk 语义完整，Markdown 文档可以直接按标题层级切分。针对代码、表格这类特殊内容要单独处理，代码基于 AST 按函数、类切分，表格整体保存不截断。追求更高质量可以使用**父子切割**，存储大小两套 chunk：小块做检索保证精准，命中后取出关联的大块完整上下文交给 LLM，代价是存储和复杂度上升。还有 Late Chunking 延迟切分，先全文编码再切分，让 chunk 向量继承全文上下文，但对 Embedding 模型能力要求高。

**一、文档如何存入向量数据库** 原始完整文档**不直接入库**，必须先切割为若干文本片段`chunk`，每一个 chunk 单独处理为向量库的一条记录。单条向量库记录由三部分组成： 1. **向量**：chunk 文本经过 Embedding 模型输出的高维浮点数向量，仅用于向量相似度检索，大模型无法读取向量。 2. **原始文本 chunk**：检索命中后取出，直接送入 Prompt 给大模型阅读。 3. **metadata 元数据**：来源文件名、页码、章节、时间等信息；用于检索过滤、答案溯源。 > 核心分工：向量负责**找到相关片段**，原始文本负责**给 LLM 阅读**，元数据负责过滤与溯源，三者缺一不可。为什么不能整篇文档直接入库： 1. Embedding 模型存在 token 输入上限，长文档无法直接输入； 2. 整篇文档压缩为单一向量，大量细节语义被平均稀释，检索无法定位到局部关键信息。入库流程：原始文档 → 文档加载 → Chunking 切分 → 每个 chunk 做 Embedding → 向量 + 原文 + 元数据写入向量数据库。 --- **二、Chunk 粒度选择** 粒度是权衡取舍： - chunk 过大：语义混杂笼统，容易召回部分相关的噪声内容，容易触发 Embedding 输入超限； - chunk 过小：语义残缺，片段脱离上下文无法理解，引入检索噪声。工程基准起点：**500‑1000 token**，实际需要结合文档类型、业务场景动态调整。 --- **三、各类 Chunking 切割策略** **① 固定大小切割 Fixed‑size Chunking** 按照 token / 字符固定长度切分，不考虑语义边界。一般搭配`overlap块重叠`使用。 - overlap：相邻 chunk 首尾保留一段重复文本，避免完整语义被切分边界切断。示例：chunk_size=500，overlap=100。 - 优点：实现简单，块大小可控； - 缺点：可能在句子、语义中间截断； - 适用：无明显结构的普通纯文本，作为保底方案。 **② 语义边界切割（基于文档结构）** 按照文本天然语义断点切分：**段落、句子、标点、标题层级**。执行逻辑：优先按大的语义单元切分，如果超出 size 上限，降级到更小单元切分。子类：**标题层级切割**，针对 Markdown、HTML，以章节标题作为切分边界，元数据可以记录完整路径，溯源过滤友好。 - 优点：每个 chunk 语义完整独立； - 缺点：实现复杂度上升，chunk 实际大小不均匀； - 适用：文章、手册、有层级结构的文档。 **③ 特殊内容专项处理** 通用切分策略对代码、表格效果差，需要单独处理： 1. **代码**：基于 AST 语法树，以函数、类作为切分单元，保证代码逻辑完整，禁止在函数中间截断； 2. **表格**：整张表格完整保留，转为 Markdown 表格，不按行切割，保留表头与行间关联关系。 **④ 父子切割 Parent‑child Chunking** 同一份内容存储两份 chunk： - 子 chunk（小块，200token 左右）：用于向量检索，粒度小、语义聚焦，提升检索精准度； - 父 chunk（大块，1000token 左右）：保存完整上下文，通过 ID 与子 chunk 关联；流程：检索匹配子 chunk，拿到关联 ID，取出对应的父 chunk 原文交给 LLM。 - 优点：同时兼顾检索精度与上下文完整性； - 缺点：存储翻倍，索引逻辑复杂； - 适用：对回答质量要求高的业务系统。 **⑤ Late Chunking（延迟切分）** 传统流程：**先切分，再 Embedding 编码**； Late Chunking：**先全文 Embedding，后切分**。 1. 将完整文档输入长上下文 Embedding 模型，得到全部 token 的向量； 2. 根据 chunk 边界，对对应位置 token 向量做均值池化得到 chunk 向量。特点：chunk 向量继承全文注意力上下文，缓解跨块代词、上下文丢失问题；约束：Embedding 模型必须支持超长输入，计算开销更大。 ## 怎么规避语义被切割掉的问题？

语义截断指完整语义单元被切分边界拆分到多个 chunk，拆分后的片段各自语义残缺，向量相似度下降，导致检索阶段全部无法召回。解决分为切分阶段、检索阶段、向量化前置增强三类思路。第一类是切分阶段处理。最基础是**overlap 重叠切割**，相邻 chunk 保留 10%‑20% 的重叠，作为兜底方案，但它只能保证文字不丢失，不能彻底解决完整语义被拆散的问题。更进一步使用**语义边界切割**，借助 NLP 工具识别句子、段落断点，不在句子中间截断，保证每个 chunk 原生语义完整，适合结构清晰的文档。第二类是检索阶段动态补全上下文。**句子窗口检索**把文档拆成单句做检索，命中句子之后，把前后若干句子一起返回，动态补齐上下文。还有**父子切割**，预存大小两套 chunk，小 chunk 做检索保证精度，命中后取出关联的大 chunk 给大模型阅读。第三类是向量化前做增强，代表是**Contextual Retrieval**。利用 LLM 读取完整文档，为每个 chunk 生成背景说明，将背景说明和原始 chunk 拼接后再做向量化，解决 chunk 脱离原文丢失语境的问题，可以配合 Prompt Caching 降低调用成本。还有命题化切割，使用 LLM 把文档拆成独立完整的事实命题，检索质量最高，但 LLM 开销大，适合高要求场景。

语义被切割（语义截断）：完整的语义单元被切分边界拆分到多个不同 chunk。不是文本信息丢失，而是拆分后的每一个片段单独语义不完整，向量相似度降低，检索阶段全部无法召回，造成信息缺失。 --- 规避方案（分为切分阶段处理、检索阶段补全上下文、向量化前置增强三类） **① Overlap 重叠切割（兜底基础方案）** 相邻 chunk 设置部分重复内容，跨边界的语义片段至少完整保存在某一个 chunk。 - 配置：一般为 chunk_size 的 **10%‑20%**；重叠过大，会带来存储冗余、重复片段干扰检索与 LLM 生成；重叠过小起不到保护效果。 - 局限：只能保证文字不丢失，**无法解决完整语义被拆散的问题**，属于兜底，不能单独依赖。 - 适用：全部 RAG 系统，作为基础配置。 --- **② 语义边界切割（切分阶段规避截断）** 不在句子、段落中间切分，识别自然语义断点再分割。 - 实现：借助 NLP 工具识别句子终止符，以完整句子为最小单元组装 chunk；优先段落边界，超出 token 上限再降级到句子。Markdown/HTML 优先按标题层级切分。 - 优点：产出的 chunk 本身语义完整； - 缺点：需要 NLP 工具支持，chunk 实际 token 大小不均匀。 - 适用：有明确段落、章节结构的文档。 --- **③ 句子窗口检索 Sentence‑window Retrieval（检索阶段补上下文）** 思路：切分粒度与交给 LLM 的粒度解耦。 - 存储：拆分为单句，单句做向量，用于细粒度检索； - 检索：命中目标句子后，不单独返回该句子，取出该句子前后 N 句，拼接成完整上下文窗口送入 Prompt。优点：检索定位精准，同时保证给到 LLM 的上下文完整；缺点：向量库记录数量等于句子总数，存储开销上升； --- **④ 父子切割 Parent‑child Chunking（检索阶段补上下文）** 同一份文档维护两套 chunk： - 子 chunk（小粒度）：用于向量检索，语义聚焦，提升召回精度； - 父 chunk（大粒度）：包含子 chunk 的完整上下文，通过 ID 与子 chunk 绑定；检索命中子 chunk，取出关联父 chunk 原文交给 LLM。 - 优点：检索精度与上下文完整性兼顾，父 chunk 大小可控； - 缺点：存储量翻倍，需要维护 ID 关联关系，索引逻辑复杂。 --- **⑤ 命题化切割 Propositions‑based Chunking（LLM 重构语义单元）** 使用大模型把原文拆解成多条独立完整的事实命题，每一条命题自包含全部必要信息，脱离原文也可以独立读懂。 - 优点：chunk 语义密度最高，检索质量最优； - 缺点：需要大量 LLM 调用，成本高； - 适用：对准确性要求极高的核心知识库。 --- **⑥ Contextual Retrieval（Anthropic，向量化前增强）** 核心痛点：chunk 脱离原文之后，丢失文档全局背景，孤立片段向量化时缺少主题信息，向量表达失真。执行两步： 1. 将完整文档输入 LLM，为每一个 chunk 生成简短背景说明，描述该片段在全文中的定位、主题； 2. 将「背景说明 + 原始 chunk」拼接，整体做 Embedding 与 BM25 索引入库。 > 优化手段：Prompt Caching，复用完整文档的缓存，大幅降低 LLM 调用成本。 - 优点：显著降低检索失败率，实测提升召回效果； - 缺点：存在 LLM 调用开销，可通过缓存降低成本； - 适用：大量 chunk 存在指代、上下文强依赖的业务文档。 ## Embedding 是什么？如何选择和评估 Embedding 模型？

Embedding 本质是语义压缩，**把文本映射为固定长度浮点数向量；语义相近文本余弦相似度高。**我们用余弦相似度而不是欧氏距离，是因为余弦只看向量方向，不受文本长短干扰。和关键词检索不同，它做语义层面匹配，可以识别同义改写。选型要看四点：**文档语言、数据合规是否允许外发、向量维度带来存储速度开销、模型最大输入窗口。主流分为 OpenAI 闭源 API、BGE 开源系列，还有 Qwen3‑Embedding 这类新一代开源模型。** 要构造业务测试集，用**Hit@K**指标离线测评，Hit@5 低于 0.7 就要优化模型或者 chunk 策略。

**一、Embedding 是什么** Embedding 本质是**语义压缩**：把不定长的自然语言文本，映射成一段**固定长度的浮点数向量**。 > 例子：1024 维模型，不管输入是 10 个字还是 500 个字，输出永远是 1024 个浮点数组成的向量。 **核心特性**：语义越接近的两段文本，向量的**余弦相似度越高（越接近 1）**。为什么用余弦相似度，不用欧氏距离（直线距离）高维空间中，向量的模长会被**文本长度、句式强弱**干扰，欧氏距离会把 “文本长短” 和 “语义相似度混在一起”。余弦相似度只关心向量**方向（夹角）**，不关心向量长度。 > 通俗理解：只要两段话表达同一个意思，向量箭头朝向同一个方向，箭头长短无关紧要。和关键词检索的本质区别 - 关键词检索：字面字符匹配，同义词、不同表达方式很难命中； - Embedding 语义检索：从**语义含义层面匹配**，可以识别同义转述。 > 示例：`苹果手机怎么截图`与`iPhone如何截屏`字面完全不同，向量相似度很高；`苹果手机`和`苹果汁`字面都有苹果，但语义差距大，向量相似度低。 --- **二、主流 Embedding 模型分类** 1. OpenAI text‑embedding 系列（闭源 API） - text‑embedding‑3‑small：1536 维，支持 Matryoshka 降维，性价比高，英文效果优秀； - 缺点：调用付费，数据外发，企业有数据出境合规风险。 2. BGE 系列（智源，开源本地可部署） - `bge‑large‑zh‑v1.5`：中文经典，1024 维，纯中文知识库首选； - `bge‑m3`：多语言，支持稠密向量、稀疏向量、ColBERT 多向量三种模式，适合中英混杂文档。 3. 新一代开源 / 闭源高性能模型（2025‑2026 新项目优先测评） - Qwen3‑Embedding：阿里通义，中文、多语言能力强，开源本地部署； - Voyage‑3‑large：闭源 API，英文检索精度强； - Cohere embed‑v4：支持 128K 超长上下文，适配长文档； - Gemini Embedding：Google，综合表现均衡。 --- **三、如何选择 Embedding 模型，四大选型维度** 1. 语言占比 - 纯中文知识库：`bge‑large‑zh‑v1.5` / Qwen3‑Embedding； - 中英混杂文档：`bge‑m3`； - 纯英文快速开发：text‑embedding‑3‑small。 2. 数据合规 - 禁止数据出境：选开源可本地部署模型（BGE、Qwen3‑Embedding）； - 无出境限制：可以使用 OpenAI/Voyage 等 API。 3. 向量维度、存储、速度权衡 - **维度越高，理论精度越高，但存储开销、检索耗时同步上涨；** - 百万级知识库：**1024 维是黄金平衡点**； - 小规模知识库：1536 维也可接受； - 部分模型支持 Matryoshka 嵌套降维，可以降低维度，平衡精度与存储成本。 4. **上下文窗口**：chunk 的 token 不能超过 Embedding 模型最大输入窗口，否则无法编码。 --- **四、如何评估** 正确的评估方法是在自己的业务数据上测：**准备几百条业务相关的「问题 + 正确答案 chunk」对，分别用候选模型做检索，看正确的 chunk 有没有出现在前 K 条结果里。这个指标叫 Hit@K**，Hit@5 = 0.8 的意思就是，80% 的问题，它对应的答案都出现在了检索结果的前 5 条里。通常 Hit@5 低于 0.7 就要考虑换模型或者改进 Chunking 策略了。这种贴近真实场景的评估，比排行榜分数更有参考价值。 ## 向量数据库？向量数据库的对比选型？

向量数据库是**专门用于存储和检索高维语义向量的专用数据库**，核心核心能力是**ANN近似最近邻搜索**，能够在海量向量中快速匹配语义相似的内容，是RAG检索环节的核心底座。它和传统数据库有本质区别，MySQL依靠B-tree索引做**精确等值匹配**，无法处理高维向量的空间距离计算，暴力检索延迟极高，完全无法适配RAG业务。而向量数据库通过专属索引算法，在可控精度损耗下，将检索延迟优化至毫秒级。行业主流的ANN索引分为两种，第一种是**HNSW分层导航小世界图**，优势是**检索速度快、召回率高**，适合中小规模数据集，也是主流向量库的默认索引；缺点是内存开销较大。第二种是**IVF聚类倒排索引**，通过向量分桶缩减检索范围，**内存占用极低**，适配亿级超大规模数据，但召回精度略低，需要人工调参。生产环境的向量数据库必须具备三个核心能力：**元数据前置过滤**，保证检索结果有效；**实时增量更新**，适配知识库动态迭代；**稠密稀疏混合检索**，弥补纯向量检索对精准术语匹配的短板。在选型上，原型开发优先用**Chroma**，上手零成本；中小规模生产首选**Qdrant**，性能稳定、运维简单；亿级超大规模分布式场景选用**Milvus**；已有PostgreSQL架构可用**pgvector**简化部署；云上无合规限制的场景可选用全托管的**Pinecone**。

**一、向量数据库核心定义** 向量数据库是专门用于存储和检索高维语义向量的专用数据库。其中向量是Embedding模型将文本、图片、音频等非结构化数据转换生成的固定维度浮点数数组，向量可表征数据的语义含义，语义相近的数据，在高维向量空间中的距离更近。向量数据库的核心能力为**近似最近邻搜索（ANN）**：输入查询向量，在海量向量数据中快速匹配并返回语义最相似的Top-K向量及对应的原始文本、元数据，是RAG检索环节的底层核心支撑。向量数据库与普通关系型数据库存在本质区别：MySQL等关系型数据库基于B-tree索引实现**精确匹配**，适配结构化数据等值查询；向量数据库专注**语义相似度匹配**，解决高维向量的相似性检索问题，二者并非替代关系。 --- **二、专用向量数据库的必要性** 1. **高维向量无法使用传统索引加速**：B-tree索引仅支持一维有序数据排序检索，无法适配1024维等高维向量的空间距离计算逻辑，索引完全失效。 2. **暴力检索性能极差**：若不使用专用索引，需遍历全量向量逐一计算余弦相似度，百万级、亿级数据场景下查询延迟极高，无法落地生产。 3. **传统数据库/中间件向量能力为后置扩展**：Elasticsearch、普通PostgreSQL的向量检索能力均为后续补丁功能，非原生架构设计，海量数据场景下的性能、内存占用、召回精度远不如专用向量数据库。向量数据库通过专属索引算法，在可控的小幅精度损耗下，将高维向量检索延迟压缩至毫秒级，满足业务实时性要求。 --- **三、主流ANN索引算法原理（HNSW / IVF）** 1. **HNSW 分层导航小世界图** 通过构建多层稀疏图结构实现检索加速，**查询时从顶层稀疏图粗粒度定位方向，逐层向下收窄检索范围**，最终在底层精准匹配最近邻向量。核心优势：**检索速度快、召回率高，同等延迟条件下召回率可达95%以上**，是Qdrant、Milvus、Chroma的默认索引算法。核心劣势：索引构建内存开销大，内存占用与向量数量正相关，不适合内存资源受限及亿级超大规模场景。 2. **IVF 倒排聚类索引** 基于聚类思想，**将全局相似向量聚合划分至多个向量桶，检索时仅遍历匹配度最高的少量向量桶**，规避全量遍历，大幅缩减计算量。核心调参参数为聚类数量nlist、检索桶数量nprobe。核心优势：**内存占用极低，适配千万、亿级超大规模向量数据集**。核心劣势：同等硬件条件下召回精度略低于HNSW，需要人工调参优化效果，稳定性依赖参数配置。算法选型逻辑：中小规模数据集优先HNSW，保证检索精度与速度；超大规模海量数据集优先IVF，以小幅精度损耗换取内存资源优化。 --- **四、生产级向量数据库核心工程能力** 1. 元数据过滤（混合检索） **支持为每条向量挂载自定义元数据，包含文档来源、部门、时间、标签等信息。检索时优先执行元数据过滤，在合规数据子集内执行ANN检索**，规避先检索后过滤导致的有效Top-K结果缺失问题，保障检索有效性。 2. 实时增量更新支持向量的在线新增、修改、删除，可增量构建索引，无需停机重建全量索引，适配知识库动态迭代更新的业务场景。 3. 稠密稀疏混合检索融合向量稠密检索与BM25、SPLADE稀疏关键词检索，弥补纯向量检索对专有名词、产品型号、精准术语匹配效果差的缺陷，提升整体召回质量。 --- **五、主流向量数据库选型对比与适用场景** 1. Chroma 部署方式：本地嵌入式、Client-Server、云托管；支持混合检索。优势：零配置、开箱即用，原生适配LangChain生态，开发调试效率极高。劣势：分布式能力不成熟，千万级以上超大规模生产场景稳定性、性能不足。适用场景：算法原型验证、中小规模知识库生产。 2. Qdrant 部署方式：自托管、云服务，支持分布式分片与副本；支持混合检索。优势：Rust底层开发，性能稳定、API简洁，文档完善，支持亿级向量生产落地。劣势：超大规模集群场景需要深度调优。适用场景：中小至亿级大规模生产环境，主流生产选型。 3. Milvus 部署方式：分布式自托管集群；支持混合检索。优势：国内大厂广泛落地，集群扩容能力强，支持多类型索引，适配海量数据。劣势：部署运维复杂度高，需要专人维护集群。适用场景：千万至亿级超大规模分布式生产场景。 4. Pinecone 部署方式：全托管SaaS云服务；支持混合检索。优势：无需运维、开箱即用，按量付费。劣势：服务收费高，存在数据出境合规风险。适用场景：云上快速落地、无数据出境限制的商业化项目。 5. pgvector 部署方式：PostgreSQL插件；可结合全文检索实现混合能力。优势：无需新增中间件，向量数据可与业务数据SQL联查，运维成本极低。劣势：检索性能弱于专用向量数据库，不适合千万级以上海量向量场景。适用场景：已使用PostgreSQL、中小数据量级、希望简化架构的业务。 ## 使用 RAG 给大模型一个输入，系统的工作流程？

用户输入问题之后，RAG 不是简单直接检索再加生成，而是一套完整流水线。 - 第一步做**Query 预处理 Query Rewrite**，用户原始提问经常有口语、指代、歧义，会通过改写、HyDE、多角度扩写等方式，生成更适合检索的查询，原始 query 的质量决定整条链路的检索上限。 - 第二步做**Query 向量化**，这里有一个关键点，**检索的 Embedding 模型必须和建库时完全一致**，不同模型向量空间不兼容，换模型就要重建整个知识库。 - 第三步执行**多路召回**，并行做向量 ANN 检索和 BM25 关键词检索，使用**RRF 算法融合两路结果**，向量擅长语义匹配，BM25 擅长专有名词、关键词精确匹配，互补提升召回效果。 - 第四步是**Rerank 精排**，向量检索属于粗排，结果存在噪声；Cross‑Encoder 结构的 Rerank 模型对候选重新打分过滤。这里采用两阶段策略：粗排先筛出几十条候选，精排再选出少量高质量片段，平衡计算开销和匹配精度。 - 第五步**Prompt 拼装**，把筛选后的参考片段和用户问题组装 prompt，通过指令约束大模型，资料不存在就如实告知，用来抑制幻觉；片段带上编号用于溯源。最后一步交给大模型生成答案，并且做**引用溯源**，方便校验答案可靠性。整体链路可以做并行、缓存等工程优化，降低整体响应耗时。

**步骤 1：Query 预处理（Query Rewrite）** 原始用户 query 质量决定整条链路的检索上限。 - 处理场景：口语化表达、上下文指代、歧义问题、问题与文档用词不一致。 - 常用方案： 1. 简单改写：将口语化问题改写为独立、正式、适合检索的问句。 2. HyDE：让大模型生成一份假想的答案，使用假想答案做向量检索；假想答案和知识库文档用词更贴近，提升召回。 3. 多角度扩写：把原始问题扩展为多条不同表述，分别检索后合并结果，扩大召回覆盖面。 --- **步骤 2：Query Embedding 问题向量化** 将预处理后的查询文本通过 Embedding 模型转换为向量。 > 关键约束：**检索使用的 Embedding 模型，必须和离线构建向量库时使用的模型完全一致**。不同 Embedding 模型向量空间、维度、语义映射逻辑不兼容；跨模型检索等价于两套不同坐标系做距离计算，检索结果完全失效。更换 Embedding 模型必须全量重建向量知识库。 --- **步骤 3：向量检索 & 多路召回** 1. 将查询向量送入向量数据库执行 ANN 近似最近邻搜索，得到余弦相似度最高的粗排 Top‑K 候选片段。 2. 多路召回：并行执行稠密向量检索 + BM25 稀疏关键词检索 - 向量检索：擅长语义层面匹配；对专有名词、产品型号、精确术语效果弱。 - BM25：擅长字面关键词精确匹配。 3. 多路结果使用**RRF 互倒排名融合**算法合并，提升召回的覆盖面。 --- **步骤 4：Rerank 精排** 向量检索输出为粗排结果，候选集合中会混入低相关噪声片段。 - Rerank 为 Cross‑Encoder 模型，输入为【用户问题 + 单条候选 chunk】，对每一条候选重新计算语义匹配分数，重新排序。 - 两阶段策略：先粗排召回较多候选（如 20 条），再通过 Rerank 筛选出少量高质量片段（3‑5 条）。 > 原因：Cross‑Encoder 计算开销大，不能直接对全量库做检索；粗排做大规模过滤，精排做小集合高精度打分，平衡延迟与检索质量。 --- **步骤 5：Prompt 拼装** 将经过 Rerank 筛选后的参考片段、原始用户问题组装成 Prompt。模板中关键指令的作用： 1. 强制要求大模型依据参考资料作答，抑制模型固有参数知识带来的幻觉。 2. 资料无对应信息时，要求输出无法回答，禁止自行编造内容。 3. 参考片段增加编号，为后续溯源引用做准备。 --- **步骤 6：大模型生成与溯源** 大模型接收 Prompt，基于提供的参考资料输出答案。工程实践中要求大模型输出携带资料编号引用溯源，使用者可以定位原始文档，校验答案可靠性；即使有参考资料，大模型仍存在误读、过度发挥的风险。 --- **链路耗时与工程优化** 1. 耗时分布：Query 改写几十 ms；向量检索几十 ms；Rerank 几百 ms；Prompt 组装可忽略；大模型生成 1‑10 秒（取决于输出长度）。 2. 优化：高频查询缓存；向量检索与 BM25 并行执行，避免串行叠加延迟。 ## 向量检索与关键词检索

关键词检索以**BM25算法**为核心，基于**倒排索引**和文本统计特征实现检索，依靠词频TF和逆文档频率IDF打分，仅做**字面词汇重叠匹配**。它的核心优势是**精准词汇匹配能力极强**，非常适合专有名词、产品型号、代码等精准查询，但无法识别同义词和转述句式，语义匹配能力完全缺失。而向量检索是**语义层面的匹配**，通过Embedding模型将文本转为高维向量，依托**ANN近似最近邻算法**计算向量余弦相似度，判断语义远近。它天然支持**同义词、不同句式、口语化模糊查询**，解决了关键词检索的语义盲区，但对精准专有名词不敏感，容易出现精确词汇漏召的问题。简单来说，两者能力完全互补：**BM25擅长字面精准匹配，向量检索擅长语义模糊匹配**，无法互相替代。因此生产环境的RAG系统都会采用**混合检索方案**，两路检索并行执行，通过**RRF互倒排名融合算法**合并结果。RRF不依赖不同量纲的分数，只根据排名权重融合，在几乎无性能损耗的前提下，最大化提升检索召回质量。

**关键词检索（代表算法 BM25）** 关键词检索是基于文本统计特征的稀疏检索方式，核心依托**倒排索引**实现。通过统计查询词汇与文档的词汇重叠度完成相关性打分，核心依赖两个核心指标：词频（TF）：关键词在单篇文档中的出现频次，频次越高相关性权重越高。逆文档频率（IDF）：关键词在全局文档库中的稀缺程度，高频通用词汇自动降权，稀缺专有词汇自动加权，规避通用无意义词汇干扰。 BM25 算法在 TF-IDF 基础上增加饱和度限制，避免单一词汇无限叠加权重，是传统搜索引擎的核心检索算法。核心特性：仅匹配**字面词汇重叠**，不具备语义理解能力。 --- **向量检索** 向量检索是基于语义空间的稠密检索方式。通过 Embedding 模型将文本转换为高维浮点向量，将文本语义映射至高维空间坐标。语义相近的文本向量空间距离更近、余弦相似度更高。依托 ANN 近似最近邻算法，快速匹配查询向量与知识库向量的相似 Top-K 结果，核心依据**语义相似度**完成匹配，与字面词汇是否重叠无关。核心特性：具备**语义理解、跨句式、同义词匹配**能力。 --- **二、两种检索方式的优势与盲区** **BM25 关键词检索** - 优势：对**专有名词、产品型号、代码、缩写、精准术语**等固定文本匹配精度极高，可实现精准命中，可解释性强。 - 盲区：无法识别同义词、近义词、转述句式，无词汇重叠的语义相似文档无法召回，存在严重的字面匹配局限性。 **向量检索** - 优势：突破字面限制，天然支持同义词、不同句式、模糊语义匹配，适配自然语言问答、口语化查询场景。 - 盲区：对精准专有名词、版本号、型号等离散精确词汇不敏感，易出现精确词汇漏召、混淆匹配的问题，无法替代关键词检索的精准匹配能力。 --- **混合检索（Hybrid Search）原理** 由于关键词检索与向量检索能力互补、盲区互斥，生产级 RAG 系统均采用**混合检索方案**。核心流程：并行执行 BM25 关键词检索与向量检索，得到两路独立召回结果，通过 **RRF 互倒排名融合算法** 合并排序，输出最终候选文档。 RRF 算法核心原理：摒弃两路无法统一的分数量纲，仅依据结果排名倒数计算权重，排名越靠前权重越高。规避向量余弦分与 BM25 分数量纲不统一、无法加权求和的问题，同时保留两路检索的优质结果，大幅提升召回覆盖面与准确率。工程优势：两路检索并行执行，整体延迟取最大值，无额外耗时损耗，性能优异。 ## 润色用户的 Query（Query Rewrite）？目的？

Query Rewrite 的核心目的是消除**用户提问和知识库文档之间的表述鸿沟**。用户输入经常存在口语化、代词指代、问句和文档文体不一致、问题过于具体等问题，直接拿去检索，向量空间距离偏大，会出现召回失败。常见四种实现方式。 - 第一种是**直接改写**，调用 LLM 把口语、有指代的问题改写为正式完整的检索问句，适合多轮对话场景，但无法解决问句和陈述句文体差异。 ``` 请将用户的问题改写成更适合知识库检索的表述。要求：去掉口语化表达、补全缩写和指代、使用更正式的书面语、保留核心意图。对话历史：{最近几轮对话} 用户问题：{原始问题} 只输出改写后的问题，不要解释： ``` - 第二种是**HyDE 假设文档嵌入**，针对问句和知识库文档文体不同的问题。让大模型生成一段风格贴近知识库的假想文档片段，**不需要保证内容正确**，只用这个片段做 embedding 检索。因为假想文档和知识库文档向量距离更近，检索效果更好，注意假想文档本身不会参与最终 prompt。 ``` 请根据以下问题，生成一段可能的答案。注意：不需要完全准确，只需要用于辅助检索，风格尽量像知识库文档。问题：{用户问题} 假设答案： ``` - 第三种是**Step‑back 后退提问**，当用户问题过于具体，知识库没有直接答案但有背景原理，把具体问题抽象成通用背景问题。工程上一般原始 query 和后退生成的 query 同时检索，不能直接替换原始问题。 ``` 请将以下具体问题转化为一个更通用的背景问题，用于检索相关背景知识。具体问题：{原始问题} 背景问题： ``` - 第四种是**多‑Query 扩展**，生成 3‑5 个不同角度的查询分别检索，合并结果，提升覆盖度，但会带来多次 LLM 调用，token 和时延开销更大。同时 Query Rewrite 也存在风险，大模型有可能改写偏离用户意图，生产上会拿原始 query 做检索兜底；简单查询也可以直接跳过改写步骤。

**Query Rewrite 目的** 用户原始查询与知识库文档存在表述鸿沟**：口语化、代词指代、问句 / 陈述句文体差异、问题过于具体缺少背景、查询角度单一**。原始 query 直接 embedding 检索，向量空间距离偏大，造成召回失效。 Query Rewrite 在检索前对用户输入做加工，让检索输入在向量空间更贴近知识库文档，提升召回效果。 --- **四种主流方案** ① **直接改写 Query Rewriting** - 解决：口语化、指代、缩写、多轮对话指代丢失 - 做法：LLM 把原始问题转为书面、完整、无歧义检索问句，保留核心意图。 - 开销：1 次 LLM 调用 - 局限：无法解决问句与陈述句文体差异。 ② **HyDE (Hypothetical Document Embeddings) 假设文档嵌入** - 解决：查询是问句，知识库是陈述句，文体带来的向量距离。 - 做法：LLM 基于用户问题生成一段**风格贴近知识库的假想文档片段，不需要事实正确**；拿该片段做 embedding 用于检索。假想答案本身不送入最终 prompt。 > 核心逻辑：答案和知识库文档的向量距离，比问题到知识库文档更近。 - 开销：1 次 LLM 调用 ③ **Step‑back Prompting 后退提问** - 解决：用户问题过于具体，知识库没有直接答案，但存在相关背景原理文档。 - 做法：将具体问题抽象，生成一条更通用的背景问题。 > 工程最佳实践：**原始 query + step‑back 生成的背景 query 同时检索，合并结果，不能直接替换原始 query**。 - 开销：1 次 LLM 调用 ④ **多‑Query 扩展** - 解决：单条查询视角单一，覆盖不全。 - 做法：LLM 生成 3‑5 个不同角度的查询，分别检索，结果合并去重。 - 开销：N 次 LLM 调用，成本更高。 --- **选项参考** | 方法 | 解决问题 | 额外开销 | 适用场景 | | ------------- | ---------------------------------- | ------------- | ---------------------------------- | | 直接改写 | 口语化、指代不清、上下文丢失 | 1 次 LLM 调用 | 多轮对话、普通用户提问 | | HyDE | 问句与知识库文档文体差异 | 1 次 LLM 调用 | 专业知识库，问句多、文档多为陈述句 | | Step‑back | 具体问题缺少直接答案，需要背景原理 | 1 次 LLM 调用 | 技术类知识库，参数、原理类查询 | | 多‑Query 扩展 | 单一查询角度覆盖不足 | N 次 LLM 调用 | 复杂多维度问题 | ## 什么是多路召回？具体怎么做？

多路召回就是同时使用多种检索策略，分别召回候选 chunk，合并融合之后再交给精排，再送入 LLM，用来解决单路召回存在固有盲区的问题。工业界最常用的是三路组合。第一路是**向量稠密检索**，依靠 Embedding 和余弦相似度，擅长同义词、语义转述，但对专有名词、型号召回能力弱。第二路是**BM25 稀疏关键词检索**，基于倒排索引和词频统计，擅长精确词、产品型号匹配，但无法理解语义同义词。向量加 BM25 这两路，又叫做混合检索。第三路是**多‑Query 扩展召回**，调用 LLM 生成 3‑5 个不同视角的查询变体，每个变体分别做向量检索，本路内部合并去重，用来解决用户提问视角和文档视角不一致的问题，但会带来额外 LLM 与向量库开销。多路返回的候选分数的量纲完全不一样，不能直接加权，工程普遍使用**RRF 互倒排名融合**。它抛弃原始分数，只依靠各路内部的排名计算综合得分，k 是平滑参数。文档在越多路排名靠前，综合分数越高。要注意 RRF 属于粗排，**不能替代 Rerank 精排**；多路结果要先做去重。业务上不需要无脑上三路，专有名词多的场景向量 + BM25 双路就够用；用户提问多变的场景，再开启多‑Query 扩展。多路会扩大候选池，噪声也会增加，依赖 Rerank 过滤无关内容。

**一、什么是多路召回** 多路召回，指同时使用多种不同检索策略，各自召回一批候选 chunk，再对多路候选做去重、结果融合，再交给精排，最终送入 LLM。与之对应的是单路召回，例如只使用向量检索。核心出发点：**没有单一检索方式可以覆盖全部场景，不同检索存在互补的盲区，多路组合提升召回覆盖率**。 --- **二、常用三路召回组成** - **向量检索（dense 稠密检索）** 对文本做 Embedding，余弦相似度检索 Top‑K。擅长语义、同义词、不同表达方式；短板：专有名词、型号、缩写召回效果差。 - **BM25 关键词检索（sparse 稀疏检索）** 基于倒排索引，依靠词频 TF、逆文档频率 IDF **打分**；中文需要分词。擅长专有名词、产品型号、数字等精确字面匹配；短板：无法处理同义词、语义转述。 > 向量 + BM25 两路，就是常说的混合检索 Hybrid Search。 - **多‑Query 扩展召回** 调用 LLM，基于原始 query 生成 3‑5 个不同视角的查询变体；每一个变体分别执行向量检索，本路内部完成结果合并去重，输出这一路的候选集合。解决用户提问视角与文档视角差异的问题；代价：多次 LLM 调用、多次向量库查询，带来 token 与时延开销。适合用户提问风格多变场景。 --- **三、结果融合：RRF 互倒排名融合** 各路检索分数的量纲完全不同，向量是余弦相似度 0‑1，BM25 分数无固定范围，不能直接加权求和；归一化方案稳定性差。 RRF 只使用文档在每一路的排名计算分数： > 值得注意的是，RRF 本质上还是粗排，适合在 Rerank 之前做候选集合并。如果对最终召回精度要求很高，还是要在 RRF 融合之后接一个 Cross-Encoder 结构的精排模型（比如 `bge-reranker-v2-m3`）做深度打分，把真正相关的内容筛到最前。 --- **四、业务选型** - 知识库包含大量型号、专有名词：**向量 + BM25 双路（混合检索）为标配**。 - 用户提问角度多变、客服类场景：在双路基础上增加多‑Query 扩展，组成三路多路召回。 - 高要求场景：三路召回 + RRF 融合 + Rerank 精排完整链路。 - 不建议无脑堆召回路数，新增路径会引入噪声，增大候选池，加重精排压力。 --- **五、关键风险** - 多‑Query 扩展带来 LLM 调用、向量库查询次数上涨，高 QPS 场景成本压力大。 - 多路合并后候选池膨胀，需要管控候选数量，否则 Rerank 耗时飙升。 - RRF 只做粗排，无法过滤语义噪声，Rerank 不能随意省略。 ## RAG 检索优化策略有哪些？

> RAG 检索优化分为**索引层、查询层、召回层、重排序层**四层。索引层解决**检索粒度和阅读粒度的矛盾**，检索需要小块保证语义聚焦，LLM 阅读需要大块保证上下文完整。主流方案是**Parent‑Child 父子块**，子块构建向量索引做检索，命中后取出父块交给大模型；同时还有摘要索引、多粒度分层索引，要注意父块 token 管控与重复去重。查询层在检索前处理用户 query，解决提问和知识库表述不一致。包含**Query 改写、Multi‑Query 扩展、HyDE、Step‑back 后退提问**。所有 LLM 生成的查询变体都有跑偏风险，**原始 query 必须保留兜底**；HyDE 生成假想文档，只用于向量检索，不要跑 BM25。召回层采用**多路召回**，向量检索擅长语义匹配，BM25 擅长精确词匹配，两者能力互补。多路结果使用**RRF 倒数排名融合**，只依靠排名计算综合得分，规避分数量纲不一致问题，RRF 属于粗排。重排序层使用**Cross‑encoder 结构的 Rerank 精排**。Bi‑encoder 向量检索是两边独立编码，速度快但精度有限；Cross‑encoder 把 query 和 chunk 成对输入，能够看到交互信息，打分精度更高，但仅适合小规模候选集。经过 Rerank 筛选少量 top 结果送入 LLM，也能缓解 Lost‑in‑the‑Middle 长上下文问题。生产环境不需要全部开启，高收益标配：**父子块索引 + 向量 BM25 多路召回 + Rerank**；用户提问口语化严重，再追加查询层优化。

RAG 检索是系统能力上限，检索没召回相关文档，生成层无法弥补。检索优化分为四层：**索引层、查询层、召回层、重排序层**。 --- **一、索引层：知识如何存储** 解决核心矛盾：检索需要小块 chunk 保证语义聚焦；LLM 阅读需要大块 chunk 保证上下文完整。 - Parent‑Child（父子块）：细粒度子块建立向量索引做检索，命中后通过 parent_id 取出粗粒度父块交给 LLM；父块不建向量；风险：父块 token 不可控，多子块命中同一父块需要去重。 - 摘要索引：对文档生成摘要，用摘要构建向量索引，命中后返回原文；缺点：摘要生成消耗 token，存在摘要幻觉风险。 - 多粒度分层索引：同时维护多套不同粒度索引，根据问题类型自动选择索引检索；缺点：存储膨胀，业务逻辑复杂。 --- **二、查询层：检索前对用户 Query 预处理** 解决用户提问表达方式与知识库文本不一致问题，**原始 Query 必须保留做兜底，不能完全依赖 LLM 加工结果**。 - **Query 改写**：LLM 将口语、歧义、指代不清的 query 改写为精准书面 query，输出 1 条查询。 - **Multi‑Query 多查询扩展**：生成 3‑5 个不同角度 query，全部参与检索，结果合并去重。 - **HyDE 假设文档嵌入**：LLM 根据问题生成假想答案文档，使用假想文档的向量检索；**仅用于向量检索，不用于 BM25**；风险：假想文档跑偏会误导检索，必须保留原始 query 向量兜底。 - **Step‑back 后退提问**：对具体问题向上抽象，生成通用背景 query 参与检索；原始 query 仍然保留。 --- **三、召回层：多路召回** 单路检索存在固有盲区，多路并行检索，结果融合，提升召回覆盖率。 - **向量检索（稠密检索）**：擅长语义、同义词；短板：专有名词、型号召回弱。 - **BM25 关键词检索（稀疏检索）**：基于词频统计，擅长专有名词、精确字面匹配；短板：无法理解语义同义转述。 - **RRF 倒数排名融合**：各路分数量纲不同，不使用原始分数，仅依靠文档排名计算综合分，公式：\(score=\sum \frac{1}{rank+k}\)，k 为平滑参数；无需训练，计算量小；属于粗排，无法过滤语义噪声。 - **工程约束**：多路召回会造成候选池膨胀，需要管控候选集大小，避免后续 Rerank 耗时过高。 --- **四、重排序层 Rerank 精排** - Bi‑encoder：向量检索模型，query、chunk 独立编码，可预计算 chunk 向量；速度快，适合大规模召回；无法看到 query 与 chunk 交互，相关性判断精度有限。 - **Cross‑encoder**：将 query+chunk 成对输入模型，可看到词与词交互，打分精度高；**不能预计算，只能处理小规模候选集，不可做大库召回**。 - 流程：多路召回输出 20‑30 候选，Rerank 打分，取 top‑3~top‑5 送入 LLM；缓解 Lost‑in‑the‑Middle 长上下文信息丢失问题。 - 约束：Rerank 模型存在输入长度上限，过长 chunk 会截断导致打分失真。 ## 了解哪些更复杂的 RAG 范式？

> RAG 一共分为**Naive RAG、Advanced RAG、Modular RAG**三代。 Naive RAG 就是简单的提问、向量检索、拼接 Prompt 生成；**Advanced RAG 属于固定流水线**，增加 Query 改写、多路召回、Rerank，是目前线上最常用方案，但流程是写死的。**Modular RAG 把链路拆解成独立可替换模块，支持运行时分支跳转，LangGraph 就是这套思路的工程落地**，四大高级范式都基于 Modular RAG 实现。 **Self‑RAG 让模型自主判断要不要检索，评估检索片段相关性，校验答案幻觉**。论文原版需要微调引入反射 token；通用大模型只能靠 Prompt 模拟行为，适合问题混杂的场景，落地成本偏高。 **CRAG 做检索质量兜底**，检索后对结果做质量评估，分为三档：质量高直接使用本地知识库；质量模糊就本地结果与网络搜索合并；质量差直接降级调用外网搜索，解决知识库覆盖不全的问题。 **GraphRAG 结合知识图谱、社区发现和层次摘要**，预处理抽取实体关系构建图谱，聚类生成社区摘要；局部问题做实体遍历，全局问题用 Map‑Reduce 聚合摘要。它擅长跨文档关联、全局主题归纳，但预处理 token 开销大，效果受实体抽取质量影响。 **Agentic‑RAG 将 RAG 嵌入 Agent 循环**，运行时由 LLM 自主决定检索关键词、检索次数，信息不足继续检索，信息足够再输出答案，适合多步骤复杂推理；需要设置最大迭代次数，避免死循环与上下文膨胀。实际业务落地中，高级范式一般叠加 Advanced RAG 组件，不是互相替代，需要结合业务成本、场景选型。

**RAG 范式**：用户提问到生成答案全链路，各环节的组织逻辑与处理流程。朴素 RAG 的三类核心痛点： 1. 检索质量不可控，无论好坏全部送入 LLM，容易产生幻觉； 2. 流程固化，所有请求执行完全相同链路，无需检索的问题浪费资源，复杂问题无法做多轮检索； 3. 知识库存在盲区，检索无有效信息时缺少兜底策略。 --- **三代 RAG** 1. **Naive RAG**：用户提问→向量检索→拼接 Prompt→LLM 生成。链路极简，无任何优化，召回结果全部投喂大模型，幻觉风险高。 2. **Advanced RAG**：**固定流水线**，检索前做 Query 改写、Query 扩展；检索后做 Rerank 重排、上下文压缩。工程改动小，线上使用广泛；缺陷是流程硬编码，无法运行时动态改变逻辑。 3. **Modular RAG**：将检索、改写、重排、生成拆成独立可替换模块，支持条件分支、按需组合；LangGraph、LlamaIndex Workflow 是该思想的工程实现。在模块化基础上衍生各类高级 RAG 范式。 --- **四大高级 RAG 范式原理** **① Self‑RAG** 解决痛点：流程固化，无法自主判断是否需要检索、无法评估检索片段与答案质量。 - 论文原版：对基座 LLM 微调，引入 4 种专用反射 token：判断是否检索、评估片段相关性、校验答案是否有文档支撑、评估答案可用性。 - **执行流程：①评估问题，无需检索直接输出；②检索，逐条评估 chunk 相关性；③基于有效 chunk 生成候选答案；④校验候选答案幻觉与可用性；⑤输出最优答案。** - 工程现实：通用开源 / 闭源大模型无法直接跑论文原版；工业界大多通过 Prompt 做行为模拟，效果弱于微调版本。 - 适用：问题混杂，部分问题不需要外部知识库；代价高，业务落地较少。 **② CRAG（Corrective‑RAG）** 解决痛点：知识库覆盖不全，检索结果质量差没有兜底。 - **执行流程：①本地知识库检索；②评估检索结果质量；③三级路由：高质量直接使用本地结果；模糊则合并本地结果 + 网络搜索；质量差丢弃本地，降级调用网络搜索；④基于最终上下文生成答案。** - 评估器：可训练分类模型；工程常用 Rerank 打分、相似度分数做近似，阈值业务调参。 - 核心：本地知识库为主，网络搜索做备胎兜底。 **③ GraphRAG** 解决痛点：普通向量检索擅长局部片段匹配，不擅长跨文档实体关联、全局主题归纳。 - **预处理阶段：LLM 抽取文档实体、关系构建知识图谱；Leiden 算法做社区聚类，对每个社区生成层次化摘要。** - 查询模式：局部查询做实体关系遍历；全局查询使用 Map‑Reduce 聚合各个社区摘要，输出全局结论。 - 局限：预处理消耗大量 LLM token；实体抽取的幻觉会污染图谱；简单局部查询场景，普通向量 RAG 性价比更高。 **④ Agentic‑RAG** 解决痛点：复杂问题需要多轮、差异化检索，预先写死的流程无法满足。 - 核心：把 RAG 嵌入 Agent 循环，**运行时由 LLM 自主决策**：是否继续检索、检索关键词、何时停止检索输出答案；设置最大迭代次数防止死循环。 - 执行流程：接收问题→LLM 判断信息是否充足→不足则生成检索词执行检索，累积上下文；循环直到信息充足，生成最终答案。 - 工程问题：会出现无效检索词、重复检索、上下文膨胀，需要做去重、迭代次数限制。 ## 在什么场景下，图数据库来增强传统的向量检索？

> **向量检索依靠 Embedding 相似度做召回，擅长模糊语义匹配，但是没有实体和关系的结构化存储**。虽然 Agent 可以做多轮向量检索，但是下一跳检索什么需要 LLM 去猜测，长链路多跳查询可靠性差。 **图数据库用节点存储实体、边存储关系，擅长确定性多跳图遍历，能够沿着关系链拿到分散在不同位置的信息**，但它本身不擅长语义模糊匹配。两者是互补，不是替代关系。工程上经典流程：先用向量检索拿到相关文本，提取实体，经过**实体对齐消歧**，定位图数据库节点，执行多跳遍历，最后把向量召回的文本和图遍历得到的结构化信息一起交给 LLM。现在也有一体化图向量库，直接在节点上挂载向量，一套库完成语义匹配和图遍历。典型适用场景是金融股权、医疗知识、代码依赖、供应链溯源，这类场景需要跨实体多跳推导。但图 RAG 成本很高，实体关系抽取、实体消歧、图谱维护工作量远大于普通向量库。如果只是查询概念、教程文档，向量 + Rerank 就够用，属于过度设计。另外要注意，**图数据库无法根治幻觉，建图阶段抽取出来错误的实体关系，查询输出的结果本身就是错误的**。

**一、核心原理** - **向量检索的能力与局限** 向量检索依靠 Embedding 相似度召回文档片段，擅长语义模糊匹配。底层没有实体、关系的结构化存储；虽然可以通过 Agent 做多轮向量检索，但下一跳查询目标需要 LLM 自行推理，长链路多跳查询容易漏实体、编造实体，可靠性差。适合答案直接存在单段文档中的问题。 - **图数据库的能力与局限** 图数据库以**节点代表实体，边代表实体间关系**，擅长确定性的图遍历，可以从某一实体出发，沿着关系边做多跳路径查询，收集分散在多处的关联信息。原生不擅长语义模糊匹配；图数据库≠知识图谱，知识图谱是数据模型，图数据库是存储查询引擎。 **两者是互补而非替代** - 向量检索：解决语义模糊匹配，定位实体入口； - 图数据库：解决实体之间多跳关系推导；现代方案分为两套存储分离架构、图向量一体化架构（节点挂载向量索引）。 **标准工作流程** - 向量检索召回文本片段，从中提取关键实体； - 做**实体对齐 / 消歧**，映射到图数据库的节点； - 执行图遍历，沿着关系边获取多跳关联实体与关系； - 把向量召回文本 + 图遍历结构化结果合并，送入 LLM 生成回答。 > 工程瓶颈：不在查询阶段，而在图谱构建：实体抽取、关系抽取、实体消歧、图谱更新维护。抽取错误会直接带来错误结果，**图 RAG 不能根治幻觉**。 --- **二、适合引入图数据库的业务场景** 满足：需要多跳关系推导，答案不存在于单篇文档，业务可以承担图谱构建维护成本。 1. 金融投资：企业股权、任职、竞争关系分析； 2. 医疗领域：疾病、药物、基因、症状之间的多关联查询； 3. 代码知识库：函数、模块之间直接 / 间接依赖链路查询； 4. 供应链溯源：原材料、供应商、成品、分销商链路追溯。 --- **三、不适合使用图数据库的场景** 1. 业务以概念解释、教程、故障排查类问答为主，答案存在于文本片段中，向量检索 + Rerank 即可满足； 2. 数据是纯非结构化散文，很难抽取可靠实体与关系，建图成本极高收益低。 > 选型判断原则：问题是否涉及多个实体，需要查询实体之间的关联 / 传导关系；同时可以承担图谱构建治理成本。 ## 如何规避 RAG 系统中大模型的幻觉？

> 在 RAG 系统中，幻觉主要分为**检索层幻觉**和**生成层幻觉**。检索层是没有召回有效文档，大模型直接使用预训练知识编造；生成层是拿到参考上下文，但模型自行推断拼接，输出原文不存在的内容。同时还要注意，**幻觉也会来自上游链路**，比如知识库原始脏数据、OCR 错误；GraphRAG 场景实体关系抽取出错，源头出错，后续所有约束都无法修复。工程上有四层递进防控手段。第一是**Prompt 强约束**，明确规定模型只能使用给定参考资料，没有信息就如实告知。但 Prompt 只能降低概率，不能彻底消除幻觉。第二是**检索质量门控**，使用 Rerank 做相关性打分，这里不能只看最高分一刀切，要结合最高分和有效片段数量综合判断；质量不达标直接拒答，答错比不答风险更高。**Prompt 约束 + 检索门控，是所有 RAG 系统的基础基线**。针对金融这类高可信业务，可以增加**结构化输出强制溯源**，每条结论绑定来源编号。但不能完全信任 LLM 输出的 source_id，系统层面还需要做一轮相关性校验，防止编造来源。医疗、合规这类零容错场景，再加**生成后二次事实校验**。要注意，复用同一个模型自校验会存在偏见漏检问题，高危场景建议使用独立事实核查模型，代价是增加 token 开销和延迟。整体没有银弹，**治理幻觉优先治理知识库和检索，生成层手段只是兜底**；拒答策略也要结合产品业务权衡，不能无脑全部拒答。

**一、RAG 幻觉的来源** 1. **检索层幻觉**：没有召回相关参考片段，LLM 使用预训练固有知识编造答案。 2. **生成层幻觉**：已经召回相关上下文，但 LLM 自行推断、拼接、补充原文不存在信息。 --- **二、四层防控方案（成本从低到高）** **方案 1：System Prompt 强约束（事前，低成本基线）** 明确规则：只能使用参考资料内容；资料无信息则直接说明无法回答；禁止猜测、额外推断。 - 优点：接入简单，降低生成层幻觉概率。 - 局限：**无法彻底根除幻觉**；对检索层幻觉几乎无效，检索内容完全无关时，再强 prompt 也拦不住编造。 **方案 2：检索质量门控（事前，基线必做）** Rerank 对召回 chunk 打相关性分数，不直接使用**单最高分一刀切**；同时参考最高分 + 高于有效阈值的片段数量。 - 分数不达标：直接拒答，不送入 LLM 生成；答错风险大于不回答。 - 分数达标：过滤低相关片段再送入大模型。 - 调参：离线测试集划分阈值，线上持续回流 badcase 迭代；Rerank 模型本身会出错，不能迷信打分。 - 业务权衡：不是所有业务都适合直接拒答，部分场景改为降级提示信息不足。 **方案 3：结构化输出 + 来源溯源（事中，高可信业务启用）** 强制 LLM 输出 JSON 结构化结果，每一条结论 claim 绑定对应 source_ids 来源编号。 - 作用：迫使模型生成时主动对照参考资料；对外可展示来源。 - ⚠️工程坑：LLM 会编造虚假 source_id；**必须系统侧二次校验 claim 和对应 chunk 的相关性，不能完全信任模型输出的编号**。 **方案 4：生成后二次事实校验（事后，零容错高危场景）** 拿到大模型输出答案后，再次调用模型逐条校验每条结论是否能在参考 chunk 找到依据，剔除无依据内容。 - 代价：双倍 token 消耗、响应时延上升。 - 局限：复用同一个模型做自校验，会继承原有模型偏见，容易漏检幻觉；高危场景优先选用独立事实核查模型。 --- **三、业务组合策略** 1. 普通知识库、客服问答：**方案 1 + 方案 2（强制基线）**，解决大部分幻觉。 2. 金融、文档审核等高可信业务：基线之上叠加**方案 3 来源溯源**。 3. 医疗、合规审核等零容错场景：四层全部启用，牺牲时延、成本换取可信度。 ## 怎么量化你的 RAG 效果？

RAG 评估的目的，就是把主观的回答好坏变成可量化、可对比的指标。在修改知识库、向量模型、分块策略之后，用来验证优化有没有效果，并且定位问题出在检索还是生成环节。只靠人工抽样测试属于盲调，样本太少，找不到根因，很难判断迭代收益。 RAG 评估有几个难点：答案不唯一、故障链路难以区分、人工标注成本高。工程上一般分成三层评估：检索层、生成端到端评估，再加上线上指标，形成闭环。首先是**检索层评估**，不需要调用大模型，**用 Hit@K 和 MRR 两个指标。Hit@K 看 TopK 里能不能找到正确文档，代表有没有找到材料；MRR 看正确文档排得够不够靠前。Hit@K 差说明召回策略、分块或者 Embedding 有问题；MRR 偏低，通常需要优化重排 Rerank。** **第二层是端到端生成评估，常用 RAGAs，用大模型当裁判打分，只能做版本对比，不能当成绝对标准答案**。四个核心指标：忠实度衡量幻觉，判断每句话是否能在上下文找到依据；答案相关性判断会不会答非所问；上下文召回率看关键信息找没找全；上下文精确率看检索结果噪声多不多。没有标准答案的情况下，只能做忠实度和相关性的弱评估。根据指标短板，我们就能定位是召回不全、噪声太多，还是大模型产生幻觉、回答跑题。 **最后离线指标不能代表真实线上效果，必须配合线上业务指标，比如点踩率、追问率、转人工率、会话解决率。**完整的迭代流程就是离线测评调参，上线采集数据，收集坏案例回流扩充测试集，再离线验证修复。还要注意，测试集尽量取自真实用户提问，并且指标之间存在取舍，不能全部同时做到最优。

RAG 评估目的：将主观的 “回答好不好” 转化成可追踪、可对比的量化指标；知识库、Embedding、Chunk 策略改动后，用来验证优化收益，定位故障发生在检索还是生成链路。 > 仅靠人工抽样测试属于盲调，样本量小，无法定位根因，无法验证迭代收益。 RAG 评估难点：自然语言无唯一标准答案；故障链路难区分；人工标注成本高。工程上分层评估：**检索层评估、生成层端到端评估、线上业务指标**，形成完整迭代闭环。 --- ① 检索层评估（不调用生成大模型，输入：query、检索返回 chunk，需要标注`query‑正确chunkID`） - Hit@K：Top‑K 返回列表是否包含至少一条正确 chunk；衡量能不能找到正确材料 - K 必须对齐线上送入 LLM 的 chunk 数量，不能固定写死 K=5； - 经验参考：Hit@5>0.8 代表检索能力合格；指标低代表 Embedding、Chunking 策略存在问题。 - MRR（平均倒数排名）：\(\displaystyle MRR=\frac1N\sum\frac1{rank_i}\)，取第一条正确 chunk的排名计算分数；衡量正确内容排得有多靠前。 - 局限：只关心第一条正确片段；如果回答需要多段文档，MRR 无法完整表征检索质量； - 指标低，说明召回了正确内容，但排序差，一般需要优化 Rerank。 > 区分：Hit@K 回答 “找到没”；MRR 回答 “多快找到”。 --- **② 生成层端到端评估（RAGAs，LLM‑as‑a‑Judge，大模型充当裁判自动打分）** > 重要约束：RAGAs 输出是**相对参考值，用于版本 A/B 对比，不是绝对真值；评判模型自身会带来偏差**；大规模评测 token 开销大；工程一般抽样 200‑500 条样本，或降级评判模型控制成本。 4 个核心指标： 1. **Faithfulness 忠实度**：答案的每一条陈述，是否可以在检索上下文找到依据；直接衡量幻觉程度。参考目标 > 0.8。 2. **Answer Relevancy 答案相关性**：生成答案是否回应用户原始问题；衡量是否跑题。参考目标 > 0.8。 > 区分：Faithfulness 看内容是否有据；Answer Relevancy 看是否答非所问；可以出现忠实度很高，但是完全跑题的答案。 1. **Context Recall 上下文召回率**：回答该问题全部必需信息，多大比例被检索到；依赖 ground‑truth 标准答案；衡量检索有没有漏关键信息。参考 > 0.7。 2. **Context Precision 上下文精确率**：检索返回结果中，有用信息是否排在靠前位置；衡量检索返回结果噪声多少；依赖 ground‑truth 标准答案。 > 区分：Context Recall 看该找的信息找全没有；Context Precision 看找到的内容里有效信息排序。无 ground‑truth 标注集：Context Recall、Context Precision 无法计算；Faithfulness、Answer Relevancy 仍然可以做弱评估。 --- **指标故障定位** | 指标偏低 | 根因 | 优化方向 | | -------------------- | -------------------- | ----------------------------------------- | | Hit@K / MRR 低 | 检索没找到、排序差 | 调整 Chunk、Embedding、多路召回、Rerank | | Context Recall 低 | 缺少回答问题必需信息 | 提升召回覆盖面，多路召回、调 chunk | | Context Precision 低 | 召回混入大量噪音 | 优化 Rerank，减少送入 LLM 的 chunk 数量 | | Faithfulness 低 | LLM 幻觉 | Prompt 约束、检索质量门控、生成后事实校验 | | Answer Relevancy 低 | 答案跑题 | 优化 Prompt 指令，约束回答聚焦问题 | --- **线上业务指标（最终验收标准）** 离线指标不能等价线上效果，存在分布漂移；需要线上指标做最终校验： - 点踩率：用户负反馈，直接反映回答质量 - 追问率：反映答非所问 - 转人工率：知识库覆盖不足；注意开启检索质量门控后该指标上升不一定是坏事 - 空回答率：系统返回 “不知道” 占比，过高代表知识库缺失内容 - 会话解决率：综合指标，单次会话是否解决用户诉求 --- **完整评估闭环** 离线测评迭代调参 → 上线采集线上指标 → 收集 badcase 回流补充测试集 → 离线复现验证修复效果。注意事项： 1. 测试集尽量从真实线上 Query 抽样，人工编造测试集会出现线上线下效果割裂； 2. 知识库迭代，测试集也需要持续更新； 3. 指标之间存在权衡取舍，无法全部同时拉满。例：增大 Top‑K 提升 Context Recall，会降低 Context Precision，同时引发 Lost‑in‑the‑Middle；过强 Prompt 提升忠实度，会降低答案相关性。 --- ## Hit@K 和 MRR 是什么 > Hit@K 是**检索任务的指标**，专门看：给用户返回前 K 条检索结果，**里面有没有包含我们想要的正确文档 (chunk)**。 - **K**：取检索结果的前 K 条，比如 K=5，就是看 Top‑5 返回结果 - **Hit（命中）**：前 K 条里面，**至少出现 1 条正确 chunk → 记 1 次命中** - **Hit@K = 命中的样本数 ÷ 全部样本总数**，得到 0~1 之间的命中率。举例子：一共 100 道测试 query，K=5。其中 80 个问题，在返回的前 5 条里面找到了正确 chunk。 👉 Hit@5 = 80/100 = 0.8 > Hit@5=0.8：80% 的查询，正确文档出现在检索结果前 5 条。其他 | 指标 | 关心什么 | 解决什么问题 | | ----- | --------------------------- | ---------------------------------------- | | Hit@K | 前 K 条里面有没有正确 chunk | 能不能找得到（有无） | | MRR | 第一个正确 chunk 排第几 | 找得到，但是排得靠前还是靠后（排序质量） | ## RAGAS 框架是什么核心思想：**LLM‑as‑a‑Judge（大模型充当裁判）**，不用大量人工打分，让大模型自动给 RAG 输出打 0‑1 分，区分问题出在**检索环节还是生成环节**。需要输入的数据 1. `question` 用户原始问题（必填） 2. `contexts` RAG 检索返回的 chunk 列表（必填） 3. `answer` RAG 生成出来的答案（必填） 4. `ground_truth`人工标准答案（**部分指标才需要**） --- 四大核心指标（0~1，越高越好） **✨生成层指标（不需要 ground_truth）** **Faithfulness 忠实度**：衡量**幻觉**。把生成答案拆成一条条事实陈述，逐条检查能不能在检索上下文找到依据。 - 1.0：每一句话都有来源，没有编造； - 低分：模型自己瞎编内容。 **Answer Relevancy 答案相关性**：衡量**会不会跑题**：生成答案是不是在回答用户的问题。经典案例：问 “北京今天天气”，AI 输出一大段北京历史，文字全部真实有据，但完全不回答天气。 👉Faithfulness 很高，Answer Relevancy 很低。 **✨检索相关指标（需要 ground_truth 标准答案）** **Context Recall 上下文召回率**：回答这个问题**必须要的全部信息**，有多大比例被检索回来了。看：该找到的信息，找全了没有。低分 = 关键信息漏掉。 **Context Precision 上下文精确率**：检索出来的 chunk 里面，有用的内容是不是排在靠前位置。看：召回结果噪声多不多。低分 = 正确内容混一堆无关文档，排在后面，容易被大模型忽略。 --- **指标联合定位故障** - Context Recall 低 → 检索漏关键信息，优化 Embedding、Chunk、多路召回 - Context Precision 低 → 召回噪音太多，优化 Rerank，减少送入 LLM 的 chunk 数量 - Faithfulness 低 → 幻觉严重，加强 Prompt 约束、检索质量门控 - Answer Relevancy 低 → 答案跑题，优化 Prompt 指令 ## RAG 知识库如何实现动态与持续更新？

RAG 知识库动态更新，最大的难点是**一篇文档会切分成多个 Chunk，文档修改之后会发生切片边界漂移，**所以不能像普通数据库直接更新单条向量，通用生产方案采用**文档粒度的增量更新**。首先我们会维护一套独立的元数据表，记录每个文档的`doc_id、修改时间、文档内容hash`。先用修改时间做粗筛，时间发生变化的文档，再重新计算 hash，对比判断文档是否真正变更。变更触发分两种方式，**定时轮询实现简单，但是有延迟，适合低频更新；事件驱动基于 Webhook 或者消息队列，能够做到秒级更新，但是要处理消息丢失、重复，做幂等与重试，同时搭配轮询做兜底补偿。** 对于文档新增，直接切片、向量化写入向量库。文档修改，**不做 Chunk 局部更新，优先灰度版本方案，并行写入带 version 标记的新版本 Chunk，验证答案质量没问题之后，切换检索过滤条件，再清理旧版本数据，规避先删后增带来的数据真空窗口。**文档删除，就根据 metadata 里的 source_doc_id 批量清除全部关联 Chunk，防止出现僵尸数据。全量重建作为兜底手段，只有更换 Embedding 模型、修改切分策略的时候使用，大规模场景要双实例部署，建好之后再切流量。

**核心痛点**：原始文档与向量 Chunk 是**一对多关系**。文档修改后，切片边界发生漂移，Chunk 数量、内容、分割位置全部改变，**不能像普通数据库直接 Update 单条记录，无法做 Chunk 粒度局部补丁更新**。 --- **三种基础变更操作** - 新增：文档不存在，执行切片‑Embedding‑入库。 - 修改：生产通用方案为**文档粒度先删旧 Chunk，再重新切片入库**；特殊可控场景（文档仅追加、不修改中间）才可尝试 Chunk 局部更新。 - 删除：清除该文档全部关联 Chunk，避免检索僵尸失效数据。 --- **变更检测机制** - 维护独立元数据库（MySQL/Redis），存储`doc_id、文档hash(SHA256/MD5)、modify_time`。 - 修改时间戳粗筛，仅对时间变化文档计算内容 hash；hash 对比判断文档是否真实变更。 - 向量库仅保存检索数据，**不负责元数据管理**；Chunk 元数据携带`source_doc_id`，用于批量过滤删除。 --- **变更事件感知两种模式** - 定时轮询 Polling：实现简单，分钟‑小时级延迟；适合低频更新场景。 - 事件驱动：Webhook / Kafka/RabbitMQ 消息队列，秒级生效；Webhook 需处理丢消息、重复推送，做幂等、重试、死信，搭配轮询兜底。 --- **兜底方案：全量重建** 全部文档重新切片向量化入库；适用于切换 Embedding 模型、修改切分策略；大规模知识库采用双实例，构建完成再切流量，避免线上抖动；不作为日常更新手段。 **灰度版本更新（蓝绿思想，高可靠生产）** 新版本 Chunk 打上 version 标签并行写入，新旧版本共存；完成质量验证后，切换检索过滤条件，再清理旧版本；支持秒级回滚；代价是存储开销提升，验证完成必须清理旧数据。 --- **工程风险点** - “先删后增” 存在短暂数据真空窗口，优先采用**先写新版本，验证完成再删旧版本**规避。 - 多数向量库删除为逻辑标记，后台异步 GC，删除后短时间仍可检索旧数据。 ## RAG 你觉得最难的地方是哪里

RAG 搭建 Demo 很简单，**真正落地生产最大难点是全链路调优，各个环节互相耦合，一处出错整体效果就下降，主要分为三块。** 第一块是**文档预处理，属于地基型瓶颈**。真实业务文档格式复杂，PDF 双栏、表格、扫描件、内嵌图片信息，普通解析工具很容易解析乱序乱码。一旦输入脏数据，后面 Embedding 和大模型都无法补救。简单 PDF 用基础库，复杂版面用 pdfplumber、unstructured；少量高价值文档可以用多模态模型解析，但 token 成本很高，不适合海量文档，同时还要做页眉页脚、重复内容的清洗降噪。第二块是**检索质量调优，检索是 RAG 的效果天花板**。如果检索召回不到需要的内容，大模型能力再强也没用。检索效果差的诱因很多：Chunk 切分把完整语义切碎；用户口语提问和知识库书面文档存在语义鸿沟；向量检索对专有名词、型号召回效果差。工程上一般做 Query 改写、Chunk 问题增强，采用**向量加 BM25 关键词混合检索，再通过 Rerank 做重排**，提升召回质量。第三块是**效果评估困难**。人工评估成本高，标准主观；业务端到端指标反馈周期长，出问题很难定位是预处理、检索还是生成环节导致。我们采用分层评估：检索层用**Hit@K**，只评估召回能力；端到端使用 RAGAs 做 LLM‑as‑Judge 自动评估，通过 Faithfulness、Answer Relevancy、Context Recall 这几个指标区分是检索问题还是生成幻觉问题。同时要注意，自动打分仅用于迭代对比，不能完全替代线上真实业务指标。除此之外生产环境还要额外处理知识库动态更新、无法彻底根除的幻觉这类 Demo 不会遇到的问题。

**Demo 与生产的鸿沟**：RAG 原型 Demo 可快速搭建，**生产落地难点不在于跑通流程，而在于全链路调优**。预处理、分块、Embedding、检索、重排、提示词多环节互相耦合，任意环节劣化都会拉低整体效果。 --- **第一大难点：文档预处理（地基瓶颈）** - 原理：RAG 输入数据源质量决定上限，脏输入无法被后续 Embedding、LLM 修复。 - 现实问题：业务文档格式异构；普通 PDF 库对双栏、表格解析错乱；扫描件依赖 OCR；图片内嵌关键文本无法提取；页眉页脚、重复冗余噪声；代码文档切分破坏逻辑。 - 工具选型：简单纯文本 PDF 用 pypdf；复杂版面、表格用 pdfplumber、unstructured；高价值少量文档使用多模态 Vision 模型解析；Vision 成本高，不适合海量文档。 --- **第二大难点：检索质量调优（效果天花板）** - 原理：若检索阶段召回不到相关上下文，大模型能力再强也无法输出正确答案。 - 故障来源：Chunk 切分策略不合理，语义被切割碎片化；用户口语化 Query 和知识库书面文档存在语义鸿沟；纯向量检索对专有名词、型号、缩写召回弱。 - 工程解法：Query 改写、Chunk 假设问题增强；**向量 + BM25 混合检索**，搭配 RRF 加权融合；粗召回后送入 Rerank 重排，控制送入重排的候选数量控制开销。 --- **第三大难点：效果评估困难** - 原理：人工评估成本高、主观标准不一致；业务端到端指标反馈慢；故障难以定位属于预处理 / 检索 / 生成哪一层。 - 分层评估体系 1）检索层评估：Hit@K 指标，只校验目标知识是否出现在前 K 条召回结果，定位检索能力。 2）端到端自动评估：RAGAs，LLM‑as‑Judge。核心指标：Faithfulness 忠实度（检测幻觉）、Answer Relevancy 答案相关性、Context Recall 上下文召回率。 - 局限：LLM‑as‑Judge 打分存在波动，只适合版本迭代对比，不是绝对真值；需要标注测试集，离线指标不等同线上真实体验。 --- **生产环境额外两大难点** - 知识库动态更新：文档增删改、版本管理、过期数据清理，处理 Chunk 切片漂移问题。 - 幻觉无法彻底消除：检索正确也会出现摘要错误、过度推理；需要处理无匹配知识库内容时的拒绝回答逻辑。

RAG相关问题.

Dylan Kwok

RAG相关问题