从正则到视觉模型：哪种 RAG 技术适合你的问题

标题：从正则表达式到视觉模型：哪种 RAG 技术适合哪种问题

来源网址：https://towardsdatascience.com/from-regex-to-vision-models-which-rag-technique-fits-which-problem/

发布时间：2026-06-02T13:30:00+00:00

Markdown 内容： 女士们不值得使用经典的方案。文章第 3 部分提到，不存在唯一的RAG 技术。你仍然需要做出选择。本文就是那个帮你判断该选哪一种的诊断工具。

大多数构建 RAG 系统的团队都会采用相同的方案：将文档解析为片段，对每个片段进行嵌入，存入向量数据库，对问题进行嵌入，通过余弦相似度检索 top-k 结果，再将结果交给大语言模型（LLM）。我们称之为“经典 RAG 方案”。每一个教程都教这个，每一个演示也都基于它运行。

但实际问题的多样性远超这一套方案所能涵盖的范围。以下是几个真实案例。

三个极端情况下的典型场景。

模板化、高流量文档。 保险证书、KYC 表格、监管申报文件、每月经纪账户报表等。每份文档都由同一软件生成，布局完全一致。只需几百行正则表达式即可在微秒级别提取字段。虽然经典方案也可以在这里运行，但它却让 LLM 去做本可以免费获得的布局信息工作。

_跨行业的共性模式：工资单、银行账单、实验室检测报告、税务申报表、合规声明、来自单一 ERP 系统的供应商发票。只要是由同一软件生成所有文档，其布局就相当于一份契约。_

客户服务对话中的讽刺语句。 _“找出本月通话录音中所有的讽刺言论。”_ 标准情感分析（愤怒、挫败、喜悦）基本可通过情感词典解决：_unacceptable_、_ridiculous_、_frustrated_ 等词汇都能明确标记出来。而讽刺则是典型的例外。例如：“哦，太棒的服务了，只等了45分钟”——在所有词典中都被标记为正面情绪，且嵌入向量会将其与真诚表达聚类在一起，因为表面词汇几乎相同。唯一可靠的方法是让 LLM 完整阅读每段通话，判断所说内容与实际含义之间的差距。

_跨职能的共性模式：人力资源离职面谈中寻找隐藏的不满情绪；并购前内部聊天记录中识别文化风险信号；财报电话会议转录中发现 CFO 的模糊表述；销售通话录音中查找合同未授权的承诺。语气和意图无法从文本中直接锚定。_

工程图纸（完全不同的维度）。 图纸、数据存在于图表中的幻灯片、包含嵌入图像的技术规格书。纯文本 RAG 只能返回图注，却忽略了图纸本身。只有视觉模型适用于此类场景，且仅适用于此类场景。

_共性模式：建筑设计图纸、扫描的手写记录、数据藏于图表中的幻灯片、实验笔记页面、医学影像报告。只要意义存在于像素之中。_

经典方案在模板化文档上属于过度设计（正则表达式即可胜任），在通话转录中维度错误（缺乏锚点），在工程图纸上则存在模态盲区（必须依赖视觉模型）。它仅适用于中间范围的问题，并被当作万能方案推广。这个中间范围确实存在，第 3.3 节对此进行了分类；而本文存在的目的正是为了防止其他场景下因技术错配带来的代价。

本文即为诊断工具。分为三个步骤：

1. 识别两个维度： RAG 问题并非单一类型。它们分布在二维图谱上：文档结构化程度，以及问题的可控程度。每种组合都需要不同的技术栈。
2. 识别各区域的技术方案： 图谱的每个区域都有其专属技术栈：正则表达式、章节检索、混合检索（关键词搜索 + 嵌入相似度）、视觉模型、SQL 聚合。第三个维度（代理维度，见第 2.4 节）叠加在这些之上，决定 LLM 在运行时拥有多少控制权。文章后半部分的目录将每个区域映射到对应的技术区域。
3. 定位你的具体场景： 你的文档在复杂性轴上的位置？你的问题在可控性轴上的位置？两者的交点指向一个特定区域，也指向适合该区域的技术方案。

你来这里不是为了构建所有东西，而是为了找到自己的位置，然后阅读系列中与之匹配的部分。大多数读者会跳过一半内容。

在进入技术细节之前，先说明一点：大多数企业级 RAG 应用可分为两种形态：一是从模板化文档中提取字段（开篇提到的正则表达式场景），二是针对合同、报告等异构文档回答自由形式的问题（这也是本系列其余部分的重点）。对话转录是第三种真实形态，常见于客户服务、人力资源和合规领域；其中讽刺是最具挑战性的问题。纯粹的视觉内容（如图纸、幻灯片）和全库级问题（第四部分）出现频率较低。你可能会遇到一两种。下方网格可帮助你快速定位自身场景。

此诊断工具是更大框架的一部分：_企业文档智能_第一卷 逐步构建企业级 RAG 系统，本文所划分的网格区域对应系列中每种技术的具体实现文章。

1. 两个维度：文档复杂度与问题可控性[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#two-axes-document-complexity-and-question-control)

本系列中遇到的每一个问题都位于两个维度的交汇处：

• 文档复杂度： 你的文档结构有多冗余？解析器能否通过位置或标题来定位字段，还是你需要一个能“看到”页面的模型？
• 问题控制： 谁来提出问题？是工程师编写固定提示词，还是用户在聊天框中自由输入，甚至可能不知道该问什么？

这两个维度几乎相互独立。唯一的耦合点在于：固定模板文档（下文中的第1级）通常会强制使用工程师预设的问题（第A级），因为用户根本不会输入问题。除此之外，任何文档级别都可以与任何问题级别组合。

1.1 文档维度：从固定模板到视觉模型[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#document-axis-from-a-fixed-template-to-a-vision-model)

第一卷仅限于 PDF 范围。多格式文档（Word、Excel、PowerPoint、邮件）属于第二卷的内容；以下所有描述均针对单个 PDF 文件。

文档在 _结构冗余性_ 上存在差异：即其布局在文档集合中重复的程度。五个层级涵盖了大多数企业场景。

_五级文档复杂度及其对应的技术方案 —— 图片由作者绘制_

第1级：固定模板：每份文档都具有相同的结构，相同字段位于相同位置，通常由同一软件生成：例如单一经纪商出具的保险证书、KYC 表格、税务申报表、内部合规声明等。结构高度可预测，可以直接通过页面上的坐标定位字段。_技术方案：正则表达式或基于坐标的提取，无需模型。_

第2级：模板家族：文档遵循可识别的模式但存在变体（不同供应商、不同软件、不同年份）：如来自不同供应商的发票、不同出租方的租赁合同、在同一法律框架下的不同公司之间的雇佣合同。_技术方案：每个模板使用一个正则表达式，当模板发生漂移时，使用少量样本的LLM作为备用方案。_

第3级：异构结构化文档：每份文档都有自己的结构（章节、标题、目录），但这些结构在不同文档之间不重复：如定制法律合同、不同供应商的技术手册、财务报告等。_技术方案：解析文档结构，并通过文档自身的目录进行检索。_

第4级：非结构化 / OCR 处理后：扫描的 PDF、纸质文件照片、电子邮件、自由形式笔记：文本内容存在，但布局已退化或缺失。_技术方案：使用带置信度评分的 OCR，然后对噪声文本进行混合检索（词法 + 向量嵌入）。_

第5级：视觉丰富型文档：文档的 _含义_ 主要存在于视觉元素中：如示意图、以图像形式嵌入的密集数据表格、带有图表的幻灯片、工程图纸等。纯文本解析会丢失答案。_技术方案：使用具备视觉能力的模型处理页面图像，通常结合文本侧的 RAG 技术。_

沿着这个维度越往下，每份文档的成本越高。正确的做法是尽可能将每个问题向上推至诚实分析所允许的最高层级。如果团队在未检查结构冗余性的情况下就断定其语料库“太复杂，无法用正则表达式处理”，那他们实际上是在默认选择昂贵的解决方案。

1.2 问题维度：从固定提示词到多轮对话机器人[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#question-axis-from-a-fixed-prompt-to-a-multi-turn-chatbot)

问题维度是大多数团队忽略的部分。两个问题在语法上可能看起来完全一样，却需要截然不同的技术栈。真正关键的维度是 _谁控制问题以及控制程度如何_。

_四个问题控制层级，从固定的工程师提示词到带有澄清的自由用户查询 —— 图片由作者绘制_

第A级：工程师预设问题：问题是系统的参数：_“提取生效日期。”_、_“保单号是多少？”_。工程师编写并校准了提示词，在上千份文档上进行了测试。如果有用户，也无需输入任何问题。_技术方案：字段提取、结构化输出，无需解析问题步骤。_

第B级：用户填充槽位：问题是带有用户输入值的模板：_“请显示本合同中关于 {主题} 的条款。”_ 用户从列表中选择主题，或输入标签。查询的结构是固定的，只有一个槽位变化。_技术方案：章节检索，基于已知分类体系进行查找。_

第C级：自由用户查询，单次响应：用户输入任意内容，系统一次性回答：_“为什么这份合同与去年的不同？”_ 这是典型的“与文档聊天”场景，流程必须解析问题、决定检索内容并生成答案。_技术方案：单文档 RAG 加问题解析。_

第D级：自由查询加澄清机制：与 C 相同，但当问题模糊时，系统可以向用户追问：_“您指的是哪一页？您是指次承租人还是主承租人？”_ 这正是真实聊天机器人的行为，能极大扩展系统可处理的问题范围。_技术方案：问题解析加上澄清循环。_

举一个小例子来具体说明澄清机制的价值。假设用户在一个保险合同上提问：“免赔额是多少？”而该合同在三个部分（房屋、汽车、旅行保障）中都提到了免赔额。一个简单的流程可能会检索出看似合理的内容，并返回一个自信但错误的答案。而一个能够反问系统（“您指的是哪种保障：房屋、汽车还是旅行？”）则能在源头解决问题。

这将约束条件向上推至解析阶段。为了检测用户是否提到了“第3页”或“第二个附录”，你的解析器必须在每个文本块上保留页码、章节索引和标题文本作为元数据。当你查看任何单个文档时，页码似乎微不足道，但它是最简单的例子，说明了问题侧所依赖的解析决策。文章5对此进行了详细阐述。

问题规模是另一个独立的问题，不属于该轴上的层级。“你的语料库中有多少PDF文件？它们是同质的还是异质的？”属于数据侧的关注点，由诊断部分的3.2节提出，并在第四部分（文章14-17）中深入展开。将其混入问题轴会模糊两个不同的概念，因此它被排除在外。

1.3 从具体案例到技术区域[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#from-case-to-technique-zone)

横跨这两个维度，每一个单一PDF的RAG问题都会落在图中的某个位置。每个区域需要不同的技术栈。大多数团队只为一两个区域构建系统，并假装其他区域不存在。下面的网格是一种思考工具，而非严格的分类体系：实际问题常常处于两种情况之间，而各区域之间的边界故意设计得模糊不清。

_每个案例（文档层级 × 问题层级）对应最简单的适用技术——作者供图_

左上角（第1-2行，A-B列）属于确定性领域。固定模板，受控问题。字段提取本身无需LLM参与；LLM最多仅在模板漂移时作为备用方案出现。开篇提到的保险经纪人的错误就发生在此区域。大多数企业文档流程都属于此类，而且其中大部分都被过度工程化了。开篇的经纪人案例就是典型代表：每年花费六万欧元部署一个LLM系统，而用一百行正则表达式就能解决。

中间区域（第2-4行，C-D列）属于单文档RAG。这是每个供应商演示中都会展示的“与你的PDF对话”场景。它真实存在，难度不小，本系列其余内容也主要围绕这一区域展开。当文档内容异质且问题开放时，分块（将文档拆分为可检索单元）、检索（选择合适的片段）、重排序（对候选集进行精度优化）以及评估（确认系统有效）都至关重要。

最底行（第5行，所有列）属于视觉处理领域。图表、示意图、密集表格等。无论检索多么智能，纯文本解析器都会丢失答案。只有视觉模型适用于此区域，且仅适用于此区域。文章10讨论了何时视觉处理步骤值得投入成本，何时不值得。

语料库级别的案例位于网格之外，因为该网格仅针对单个PDF。当问题同时指向多个PDF（例如“找出所有责任上限低于一百万的供应商合同”）时，诊断流程将导向第四部分（文章14-17）：摄入阶段的分类、结构化字段提取、结构化数据上的SQL查询，以及剩余非结构化问题上的RAG。

该网格并非配方手册，而是一种合理性检查工具。定位你的问题，查看对应的技术区域，然后问自己：你正在构建的系统是否匹配？如果你构建得比所需更深，那你就是在为多余功能买单；如果你构建得不够深，生产环境中就会暴露出差距。

2. 每种案例对应的技术，以及什么不是技术[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#the-techniques-per-case-and-what-isnt-a-technique)

一旦你将问题定位在网格上，你就大致知道应采用哪一类技术。本系列后续内容将逐一深入探讨每种技术。

_每张卡片代表一种技术及其对应的独立文章；只阅读与你案例匹配的文章，跳过其余——作者供图_

确定性技术家族（正则表达式、通过名称定位标题的章节锚点、基于坐标的提取方法，即从页面固定边界框中提取字段）没有单独的文章。这是每位工程师都应掌握的基础知识。阅读本系列的所有工程师都应该懂得如何编写正则表达式。将其标注在图中只是为了提醒你：这是一种选项。当输入结构固定时，这就是最佳选择。

单文档RAG技术家族是本系列第二、第三部分的核心内容。包括：布局感知解析（文章5）、问题解析与校准（文章6）、检索作为范围选择（文章7）、生成作为受控执行（文章8）、混合检索与目录路由（文章9）、自适应解析（含视觉处理）（文章10）、交叉引用（文章11）、列表与综合（文章12）、带反馈循环的复合流水线（文章13）。这些技术正是你在网格中央区域会频繁使用的方法。

语料库级技术家族属于第四部分。包括：语料库问题（文章14）、从PDF文件夹准备可查询语料库（文章15）、语料库本体（文章16）、先用SQL过滤再进行检索的查询方式（文章17）。当你从单个PDF扩展到整个PDF语料库时，这些技术才会派上用场。

如果你的问题位于网格的左上角，那么在读完文章5（解析）后即可停止阅读本系列，直接跳转至文章15（准备可查询语料库）。如果你的问题位于中间区域，则需要学习第二、第三部分。如果你的问题属于语料库级别，则需在基础之上学习第四部分。这张图会告诉你该走哪条路。

2.1 选择最简单但有效的技术[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#pick-the-simplest-technique-that-works)

每个工程团队的本能都是构建他们能合理化的最强大的处理流程。但在这里，这种本能是错误的。正确的本能是选择最弱的技术来解决实际问题。原因有三：

• 成本： 每年处理两百万份文档，VM 上的正则表达式几乎可以忽略不计；而每份文档使用 LLM 的成本高达六万欧元。
• 延迟： 微秒级与秒级的区别，决定了“感觉即时”还是“感觉像在等待”。
• 可靠性： 正则表达式要么匹配，要么不匹配，工程师可以直接阅读规则；而 LLM 生成的答案有时会微妙地出错，且失败模式更难察觉，这使其不适合用于审计级别的信息提取。

大多数生产环境中的文档工作流最终都会采用一种混合方案：一个确定性的核心处理大部分内容，而当格式出现问题时，由 LLM 作为备用方案。这种混合模式几乎总是正确的架构，却几乎从不是团队最初构建的方案。

2.2 长上下文并非出路[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#long-context-isnt-a-way-out)

每隔几个月，就会有人宣布“RAG 已死”，因为上下文窗口变大了。其论点是：把整篇文档都放入提示中，让模型自行理解。

这种方法对单个文档和单个用户有效。但在生产环境中却行不通，原因有四：

• 浪费资源： 典型的问题并不需要整个文档。合同的有效日期只出现在一页上；发送其余三十九页只会消耗不会被使用的 token。
• 遗漏信息： Transformer 模型在长上下文中可靠地读取开头和结尾的内容，却常常跳过中间部分，因此即使相关页面在提示中，也可能从未被读取。
• 无法扩展： 真实场景涉及大量文档。没有任何上下文窗口能容纳企业级档案；在任何有意义的规模下，你必须选择发送哪些内容，而这个选择就是检索。
• 答案不可追溯： 没有显式的检索和引用，你无法知道答案来自文档的哪一部分，无法验证它，也无法审计它。对于任何需要可追溯答案的企业应用场景，这一点是致命缺陷。

长上下文作为一种工具是有用的，尤其是在单文档深度分析方面。但它不能替代检索。任何告诉你它可以的人，很可能是在推销某种产品。

2.3 花哨的技术通常只是关键词工作的伪装[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#fancy-techniques-are-usually-keyword-work-in-disguise)

那些被宣传为“高级”的技术，往往只是以另一种形式存在的关键词匹配，而且通常是错误的形式。HyDE（假设性文档嵌入，Gao 等人，2022）是最清晰的例子。该方法要求 LLM 写出一个能回答查询的假设性文档，然后基于该假设文档的嵌入进行检索。其宣传点是：假设性文档包含了真实答案可能使用的词汇，从而扩大了余弦相似度的范围。

配套的笔记本在《Attention》论文上测试了这一点：提问“为什么使用多头注意力”，让 HyDE 生成一段文字，再将其与第 3.2.2 节的实际词汇进行对比。两个列表仅在一个短语上重合——即章节标题。HyDE 使用的是机器学习教科书风格的词汇（如 semantic relationships、contextual dependencies、parallel processing、attention patterns）；而论文使用的是操作性词汇（如 attention layers、encoder-decoder attention、different positions、linear transformations）。

HyDE 理解了问题，但它从未读过文档。在企业环境中，关键词存在于页面的某个位置，而已经读过该页面的领域专家知道这些词。HyDE 每次查询都要花费代价去发明词汇，而这些词汇甚至可能根本不在页面上。相比之下，专家词典（文章 6）——由领域专家一次性构建的、针对语料库实际词汇的精选列表——以极低的成本完成相同任务，并可在未来所有问题中重复使用。

2.4 让 LLM 来选择案例[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#letting-the-llm-pick-the-case)

每种文档层级与问题层级的组合构成一个基本案例，对应一种匹配的技术。在第一卷中，工程师在编译时选择案例并部署相应技术。调度器（文章 13）用 Python 编码团队的路由逻辑；LLM 在固定循环内评估输出结果；每一个组件都可审计。这对绝大多数企业 RAG 应用来说已足够。

一个自然的延伸是让 LLM 本身在运行时选择案例：观察问题，将其分类到某个案例中，并选择适用的技术。这就是 2026 年行业所称的 代理式 RAG（Agentic RAG）。第三卷《代理式组件》在第一卷产生的组件之上构建这一运行时选择层。转变的关键在于谁在何时做决定，而非组件本身：代理式架构仍然依赖第一卷中经过审计和测试的相同解析、检索和生成基础组件。

3. 实践中定位你的案例[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#locate-your-case-in-practice)

3.1 围绕已存在的专家构建系统[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#position-the-system-around-the-expert-who-exists)

以下诊断需要一个大多数团队会忽略的输入：这个系统的用户是谁？

对于几乎所有企业级 RAG 应用，答案是已经熟悉这些文档的专家。不是随意提问的开放域用户，也不是探索公共档案的好奇浏览者。而是阅读合同的律师、核保员检查报价、合规官审计条款的人——这些人多年来一直阅读类似文档，熟悉其中的术语、某些术语的多重含义，以及需要注意的失败模式。

系统的职责因此变得清晰：放大专家的能力，而非取代他们。将他们的术语体系、歧义澄清方式以及逐年积累的启发式规则进行编码化。让处理流程承担数据量的压力，而让专家继续作为事实的源头。

这一点在进入网格分析之前就至关重要，因为它决定了哪些场景是现实可行的。一个团队若声称“任何人都可以针对整个归档库提出任何问题”，那实际上默认选择了右下角的案例：开放性问题、混合语料库，最难的一类。而一个团队若说“我们的承保人员检查特定文档类型中的已知字段”，则选择了左上角的案例，通常属于正则表达式（regex）的范畴。

这种框架选择很少由文档或问题本身决定，而是团队主动做出的选择。大多数团队在不知不觉中继承了消费者聊天机器人带来的模式。首先，围绕现有的专家来定位系统；然后，根据答案指向的网格案例来判断。

3.2 诊断性问题[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#the-diagnostic-questions)

在编写任何代码之前，请先逐条思考以下问题。最好大声说出来，在白板前与领域专家一起讨论。

关于文档：语料库中的文档彼此相似程度如何？是原生文本还是OCR识别结果？你们有多少个PDF文件？它们是同质的还是异质的？（这是语料库规模问题首次进入诊断环节——它将引导你进入第四部分）。是静态导入还是每日持续摄入？它们在文档维度上处于哪个位置？

关于问题：谁来提出这些问题？是设计阶段的工程师，还是运行时的用户？系统是一次性回答，还是可以追问以获取澄清？答案是否总在一个文档中，还是分布在多个文档中？“无答案”意味着什么：可接受，还是不可接受？它们在问题维度上处于哪个位置？

关于约束条件：答案是否需要追溯到原始来源？精度要求如何（尽力而为，还是“审计级”：每一条引用都可追溯至源行，每个答案均可复现）？每份文档的成本预算是多少？有时，正则表达式和大语言模型（LLM）之间的差异，直接决定了项目是否盈利。

这些问题的答案会指引你找到网格上的某个具体案例。该案例会指向一个技术区域，而该区域又会告诉你后续系列文章中需要阅读哪些内容。

3.3 网格上的常见企业案例[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#common-enterprise-cases-on-the-grid)

在实际项目中，有几种典型模式反复出现。大多数读者都能在其中找到自己的影子。

从固定模板表单中提取字段：例如某一家经纪公司的保险证书、某一家银行的KYC表格、某一行政机构的税务申报表：相同的软件在每一页上生成完全一致的布局。_案例：文档层级1，问题A，左上角_。技术栈：基于坐标可寻址字段的正则表达式，辅以LLM作为罕见偏差情况下的备用方案。在此类场景中使用完整的经典RAG方案属于过度设计，这也是我们在真实项目中最常见的错误。

跨模板变体的字段提取：例如数百家供应商的发票、多家出租方的租赁合同、同一法律框架下不同公司的雇佣合同：每份文档遵循少数几种可识别的模式之一。_案例：文档层级2，问题A或B_。技术栈：为每种已识别模板配置独立的正则表达式，并在文档不匹配任何注册模板时采用少样本LLM提取。先分类，再提取。

对长篇定制合同进行问答：每份合同结构不同，章节各异，十页的术语表不会重复。用户会对眼前的合同提出自由形式的问题。_案例：文档层级3，问题C或D，中间区域_。技术栈：完整的单文档RAG，结合目录导航、混合检索和基于模式的生成。这里，本系列的四个核心模块各自发挥关键作用。

阅读幻灯片或示意图：例如工程图纸、数据嵌入图表的财务演示文稿、包含内嵌图像的技术规格书：纯文本解析会彻底丢失答案。_案例：文档层级5，任意问题列，最下方一行_。技术栈：具备视觉能力的模型处理页面图像，同时结合文本侧RAG处理图像周围的文字描述。

超出网格范围——语料库级别场景：在数百甚至数千份合同中查找“所有责任上限低于一百万美元的供应商合同”。此时单PDF网格不再适用，问题目标是整个语料库，而非单一文档。技术栈：在导入时进行字段提取，将结构化字段存储于数据库中，通过SQL查询结构化数据，仅将RAG作为剩余非结构化问题的备选方案。_第14-17篇文章（第四部分）深入探讨此类场景_。

超出网格范围——无结构可依：如小说分析、意图分类、讽刺检测。文档本身没有结构，词汇缺乏特征性术语，问题需要理解语气或意图，而非定位某段文字。技术栈：一个LLM逐段扫描全文，判断应标记的内容。这不属于第一卷意义上的RAG问题；第2.4节暗示了这类运行时决策应归属于第三卷的范畴。

如果你的情况并不完全匹配上述任一模式，请按照第3.2节的诊断流程走一遍，结果将告诉你哪一个模式最为接近。

4. 结论[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#conclusion)

在开始写代码之前，务必对你自己的语料库进行一次诊断，理想情况下应与领域专家共同完成。诊断的结果就是你需要阅读的后续文章列表，以及可以跳过的文章列表。那些成功将RAG部署到生产环境的团队，都是先在网格上准确定位了自身问题的团队；而那些六个月后仍在调参的团队，往往是因为一开始就盲目搭建系统，而未做前期诊断。

下一章将开启第二部分，介绍第一个核心模块：文档解析。一旦在此阶段丢失的信息，无论后续检索多么巧妙，也无法恢复。

5. 参考资料与进一步阅读[](file:///C:/Users/shike/Documents/Github/rag/book/04_rag_problems.html#sources-and-further-reading)

二维网格图展示了每种方法在单个 PDF 文档的复杂度和问题控制维度上的定位。该网格所依赖的“长上下文无法取代检索”这一观点，由 Liu 等人（Lost in the Middle，TACL 2024）和 Lee 等人（长上下文基准测试，2024）的研究支持。视觉行对应 Faysse 等人（ColPali，2024）的工作。HyDE 演示使用了 Gao 等人（HyDE，2022）提出的技术。第 2.4 节中提到的代理式扩展（即 LLM 在运行时选择案例）是第三卷在本卷构建的基础之上进一步发展的方向。

与本文方向一致：

• Liu 等人，_Lost in the Middle: How Language Models Use Long Contexts_，TACL 2024 (arXiv:2307.03172)。模型系统性地忽略输入中间的信息，支持“长上下文并非出路”的观点。
• Lee 等人，_Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?_，2024 (arXiv:2406.13121)。提供了具体数据，说明在哪些场景下长上下文可以替代检索，而在哪些场景下会失效。
• Faysse 等人，_ColPali: Efficient Document Retrieval with Vision Language Models_，2024 (arXiv:2407.01449)。基于页面图像本身的视觉语言检索，为网格中的视觉行提供支撑。
• Gao 等人，_Precise Zero-Shot Dense Retrieval without Relevance Labels_（HyDE），2022 (arXiv:2212.10496)。第 2.3 节中测试的假设文档嵌入技术。

不同角度、不同背景：

• Yao 等人，_ReAct: Synergizing Reasoning and Acting in Language Models_，ICLR 2023 (arXiv:2210.03629)。提出 LLM 在运行时选择工具这一方向的奠基论文。第三卷在此基础上，继续发展第一卷构建的基础。
• Schick 等人，_Toolformer: Language Models Can Teach Themselves to Use Tools_，NeurIPS 2023 (arXiv:2302.04761)。与 ReAct 方向一致。
• Gao 等人，_Retrieval-Augmented Generation for Large Language Models: A Survey_，2024 (arXiv:2312.10997)。RAG 综述文章，将 RAG 视为一个具有共同关注点（如检索器质量、生成器忠实度）的统一范式。