rag retrieval-augmented-generation vector-database llm semantic-search evaluation

RAG的字段映射：从基本原理到实际应用中的故障问题

两条管线、三个步骤以及一系列有名称的故障：检索增强生成的工作原理、其失效点，以及哪些解决方案能解决相应问题。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 7 分钟1689 词

来源: The Complete RAG Roadmap: From “What Is It?” to Production

检索增强生成模型看似简单易展示，实则很难做到完美。一个可用的原型只需四十行代码和一个下午的时间就能完成。但随后就需要花费大量时间去排查为何它在十次尝试中有三次会给出错误答案，或是为何聊天机器人会自信地引用根本不存在的合同条款。本路线图涵盖了这两个方面：从完全不使用专业术语开始，最终介绍那些能将周末演示与人们愿意用于处理金钱事务的系统区分开来的技术。

用通俗的话解释这个概念

可以把语言模型想象成一位学识渊博的毕业生，但他从未见过你的文件。它已经掌握了互联网上的大量信息，但却不了解你的租赁协议、人力资源政策、产品目录或上个季度的董事会演示材料。

RAG将闭卷考试转变为开卷考试。系统不会依赖模型记住你的数据，而是首先查找相关页面，将其提供给模型，并要求模型仅依据这些内容作答。这一方法包含三个步骤：

检索：搜索文档并提取关键的几段文字。
增强：将这些段落放入问题旁边的提示语中。
生成：让模型根据所给内容撰写答案。

这就是其核心理念。从重新排序工具到图结构等后续优化措施，都是为了让这三个步骤中的某一个表现得更好。

对于非技术领域的读者而言，其价值在于能够解释工程团队正在开发什么、为何会出现现有问题，以及在供应商演示时该提出哪些问题。而对于工程师来说，则涉及其中的机制、权衡因素及故障模式，这就需要思考为何余弦相似度能被用作相关性的替代指标、为何512个标记的片段会破坏数据结构，以及为何评估集比模型选择更为重要。没有人会认为“直接使用向量数据库”就是完整的答案。

两个流程，而非一个

一个结构上的问题几乎让所有人都犯错：RAG系统并非单一流程，而是两个从不同时运行的流程。

A通道正在建立索引。这项工作会提前完成，通常以批处理方式执行。文档会被拆分成多个部分，每个部分都会被转换成一组能体现其含义的数字，这些数字随后会被存入可搜索的索引中。这是较为繁琐的环节，而最终答案的质量大约有80%是由这一环节决定的。

B通道负责查询。每当用户提出问题时，它就会立即启动工作。问题会通过完全相同的方法转换成数字，系统会找出最相近的存储内容，将其组合成提示语，进而生成答案并返回。

如果这两个环节在编码方式上存在分歧，一切都会失效，就好比按字母顺序整理文件后再按颜色查找一样。人们往往只关注B环节，也就是提示词、模型和温度参数，而大部分问题其实出在A环节。索引构建只需执行一次，查询则每次都需要进行，而大多数错误都隐藏在两者之间的缝隙中。

从基础到实际应用的各个阶段

基础知识

第一个主题是幻觉现象的真正来源，其实并非模型本身愚蠢所致。相关概念还包括上下文窗口是什么、为何不能将整个数据库直接导入其中，以及知识截止日期的含义。此外还有一个常被误解的问题：RAG、微调以及更大的上下文窗口其实是针对三种不同问题的三种独立工具，但却经常被建议用于解决彼此相关的问题。

那些每季度都更改保单条款的保险公司恰恰体现了这种差异。要进行微调就需要每季度重新训练模型，而RAG则只需更新相应文件夹即可。

数据导入与分块

首先就是文档的导入，这本身就充满挑战：有实际为扫描图像的PDF文件、表格、页眉页脚，还有没人需要的40页附录。接下来是分块，即决定如何将文档拆分。这听起来很简单，但实际上并非如此。如果拆分过细，每个块的内容可能只有“押金应可退还”这样一句话，却没有任何相关条件说明；如果拆分过粗，模型就会淹没在大量噪声中。主要的拆分方法包括固定大小拆分、考虑句子结构的拆分以及递归拆分，此外还有一种重叠技巧，可以避免句子被截断。

以一份60页的租赁协议为例，其违约金条款取决于40页之前给出的定义。分块边界决定了这些关联信息是否能保留下来。

嵌入与向量搜索

这一阶段看似有魔法般的效果，但实际上并非如此。文本会被转换成一组数字，其排列方式使得关于取消订单的短语会靠近关于退货的短语，而远离关于补充库存的短语。相关的概念包括维度、余弦相似度，以及向量空间中的接近度并不一定能带来正确答案这一事实。

接下来是存储问题：向量数据库的真正功能是什么，为什么暴力搜索在大规模数据下会失效，以及近似最近邻搜索为何要牺牲精度以换取速度。

检索循环

在这里，各个部分会被组合起来。选择要获取的块数——即top-k值——是其中的一部分，块数越多并非越好。元数据过滤功能可以让搜索仅覆盖2024年的文档，或仅限于孟买地区。提示词的编排也很重要，因为检索到的上下文如何排列以及顺序如何，都会影响最终答案。

接下来是依据说明和引用部分。模型应指出类似第4.2节这样的具体内容，而不仅仅是表现出自信的态度。同样重要的是，要让模型说明答案并不在文档中，这或许是所有RAG系统中最容易被忽视的功能。

评估

几乎所有人都跳过了这个阶段，这也解释了为何几乎所有推出的RAG系统都有缺陷。无法被测量的问题就无法被解决。质量评估包含两个问题：是否检索到了正确的材料，以及模型是否忠实于这些材料？这两个方面出现问题都需要单独处理。该工具包包含从实际用户那里收集的一组标准测试问题，检索能力通过精确度和召回率来评估，生成结果则根据其对问题的忠实度及相关性来评分，同时还有一款大型语言模型充当评判者，用以识别其中的错误之处。

有一个系统的检索准确率达到了90%，但内容忠实度仅为55%。它的搜索功能尚可，但给出的答案仍然是错误的。

升级措施，每项都针对某种缺陷

更出色的检索能力

混合搜索将基于语义的查找与传统的关键词匹配相结合，因为嵌入模型在处理模型编号和发票编号等精确标识符时表现极差。重排序功能可以低成本获取50个候选结果，再让速度较慢但更智能的模型从中选出最佳的5个。查询转换则可将模糊的问题改写为可搜索的形式，或将复合问题拆分成多个部分，或者使用HyDE技术，该技术会生成一个虚假的理想答案，然后用它来代替原问题进行搜索。

要求比较班加罗尔两个项目在持有日期和价格方面的差异，实际上是一个需要通过三次独立查询才能解答的问题。

更好的索引机制

正确处理A通道需要多种技术。父子检索会搜索小型且精确的文本片段，但同时也会向模型提供这些片段周围的更大范围内容。语义分块则是根据主题变化点进行分割，而非依据固定的字符数。摘要与层次索引则先搜索文档摘要，再逐步深入分析。图结构RAG存储的是实体之间的关系而不仅仅是文本，因此能够回答诸如哪些供应商同时也是客户之类的问题。

合规性查询就是一个很好的例子：它需要一条规则、该规则的2023年修订版以及一份豁免说明，即需要三份文档才能得到一个答案。

智能体行为

过了这个阶段，RAG就不再是一个固定的流程，而是开始做出决策。路由机制会将问题导向合适的索引、SQL数据库，或者直接不进行检索。多跳检索会在读取过程中发现信息缺失，于是再次进行检索。自我RAG与修正型RAG允许系统对自身检索到的内容进行评分，若发现无关则将其丢弃，继而转而进行网络搜索，或直接承认没有答案。

以“为何某项申请被拒”这样的问题为例，回答它需要依次检索政策文件、申请档案以及拒收代码。

杂乱无章的文档

真正的商业知识很少以整齐的段落形式呈现，而是以电子表格、扫描件、平面图、截图和图表等形式出现。相关技能包括考虑布局的解析、能够处理合并单元格的表格提取、图像嵌入，以及从包含答案的图表所在的文档中检索信息。典型的案例是定价问题，其具体数值仅存在于扫描版的价目表中。

生产相关问题

演示之后一切都会出问题。延迟指标能显示那些毫秒时间都用在了哪里。每次查询的成本很重要，真正有效的缓存机制同样关键。当文档每小时都在变化时，索引必须保持最新状态。访问控制机制必须确保用户A无法获取用户B的数据片段，这是常见且真实的数据泄露问题。被篡改的文档可能会注入恶意指令。通过监控和日志记录，可以发现质量何时在悄然下降。一个在200份文档上运行良好的系统，在20万份文档时就可能崩溃。

先了解故障原因

如果只记住一点的话，那就是：高级RAG并非基础RAG的升级版，而是一系列针对特定故障的解决方案，每一种解决方案都有对应的名称。一旦弄清楚了故障原因，接下来的步骤自然就是选择合适的匹配技术。

有三条原则确保这种方法的可靠性：

不盲目崇拜框架。概念先于工具，只要理解分块思路，就能在任何地方实现它。
不使用无法解释的复制粘贴代码。只有在明确代码如此设计的理由之后才会展示代码。
不假装它总是有效。某些情况下RAG并非最佳选择，更简单的方案反而更合适。

初学者应按顺序学习这些内容，因为每部分都以前面的知识为前提。那些已有系统但效果不佳的人可以直接进入评估阶段。