文档智能处理与ReAct推理链：RAG系统的两个"隐形引擎"

在前面两篇文章中，我们分别聊了零代码RAG构建和AgentRAG vs传统RAG的对比。这篇文章，我想把焦点放在两个经常被忽视但至关重要的环节上：文档智能处理和ReAct推理链。

这两个环节有一个共同点——它们都是"幕后英雄"。用户感知不到它们的存在，但它们直接决定了RAG系统的回答质量。文档处理不好，知识库里存的就是一堆碎片化的垃圾；推理链设计不好，AI就算有好的资料也可能答不到点子上。

一、文档智能处理：从"文件"到"知识"的关键一步

很多人以为RAG的文档处理就是"把PDF读出来，切成小块，存进去"。这个理解不能说错，但太粗糙了。在实际工程中，文档处理是一个多阶段、多策略的精密工程。

1.1 文档解析：不只是"读文本"

我们先看一个现实场景：一份50页的产品手册，里面有文字、有表格、有流程图、有截图、有页眉页脚。

最简单的解析方式——直接提取所有文字，忽略其他。但这样做会丢失大量信息：表格中的结构化数据没了，流程图的逻辑关系没了，截图中的UI标注没了。

更完善的文档解析需要处理几个问题：

• 格式兼容：PDF、Word、Excel、PPT、TXT、Markdown……每种格式的内部结构完全不同。PDF有扫描版和文本版的区别，Word有嵌入对象，Excel有多Sheet。一个好的文档解析引擎需要能统一处理这些格式。
• 资源提取：文档中的图片、表格等资源，要么上传到对象存储并在文本中保留引用链接，要么通过OCR识别其中的文字。
• OCR识别：对于扫描版PDF或文档中的图片，需要OCR来提取文字。OCR本身也有两种模式——基础OCR（速度快，适合清晰文字）和视觉模型OCR（用多模态大模型识别，精度高，适合复杂场景）。用户可以根据文档类型灵活选择。

1.2 文本分片：切在哪里，决定了检索质量

文档解析拿到纯文本后，下一步就是分片。分片是RAG系统中影响最大的环节之一，也是最容易被低估的。

通用分片模式

最常见的分片方式是按固定token数切分。比如设置分块大小为2000 token，重叠为100 token。但固定大小切分有一个明显的问题——它可能在句子中间、段落中间甚至一个表格中间切断。更成熟的实现会优先在自然分隔符处切割——句号、问号、感叹号、换行符等。

父子分段模式

父子分段是一种更精细的策略：先把文档切成较大的"父段"（比如2000 token）保留完整上下文，再把每个父段细分成较小的"子段"（比如200 token）用于精确匹配。向量化入库时只存子段，检索时匹配子段但返回对应的完整父段内容。这样既保证了检索精度，又保证了回答的上下文完整性。

文档摘要注入

这是一个容易被忽视但很有用的技巧。在分片完成后，系统可以用LLM生成一份整篇文档的摘要，然后注入到每个分片的开头作为"语义前缀"。这样即使分片本身的内容比较片段化，检索时也能通过摘要前缀建立语义关联，避免遗漏本该命中的内容。

1.3 QA抽取：让非结构化文档变成结构化知识

对于FAQ类场景，还有一种更高级的处理方式——用AI自动从非结构化文档中抽取问答对。系统先把文档按较大的块切分，用AI识别出独立的语义段落，再从每个段落中提取问答对，直接作为分片存入知识库。每个分片都是一个完整的"问题-答案"对，语义非常聚焦，检索精度更高。但代价是需要多次调用LLM，成本和时间开销都比较大。

二、ReAct推理链：让AI学会"思考-行动-观察"

2.1 ReAct到底是什么？

ReAct（Reasoning + Acting）是一种让LLM进行推理和行动交替循环的框架。核心思想很简单——先思考（我需要什么信息？），再行动（调用一个工具去获取），然后观察（工具返回了什么？结果够不够？），如果信息不够就回到思考阶段再来一轮。

在RAG场景中，ReAct的价值在于：如果第一次检索的结果不够好，AI可以自己分析原因，换个角度再检索一次，而不是直接将就着不完美的结果生成回答。

2.2 工程实现中的ReAct推理循环

第一轮：查询分析和规划

在进入循环之前，系统会先做一次全面的查询分析——识别用户意图（闲聊、事实查询、对比、分析、流程、故障排查等），对查询进行改写，如果是复合查询则拆分成多个子查询，并根据意图类型生成执行计划。

进入循环：每一轮做什么

每一轮推理中，系统会做以下几件事：检查超时和中止状态、构建包含历史信息的推理提示词、调用LLM让它选择调用哪个工具、执行被选中的工具、将工具结果反馈给LLM。如果LLM判断信息已经足够，就调用结束工具退出循环。

这里有几个关键的设计决策：

• 工具选择的自主性：每一轮调用哪个工具不是系统预先决定的，而是由LLM自主选择的。系统只是把可用的工具列表（知识库检索、数据库查询、Excel查询、用户自定义函数等）和当前的状态信息告诉LLM，让LLM判断下一步该做什么。
• 推理提示词的逐轮累积：每一轮给LLM的提示词包含用户问题、已执行步骤、工具调用历史、已检索信息摘要、可用工具列表、建议的备选查询等。这些信息是逐轮累积的——第一轮时历史记录是空的，到了第三轮LLM能看到前两轮的完整记录，从而做出更明智的决策。
• 相似度守卫：在多轮推理中，LLM有时候会用几乎相同的查询反复检索。相似度守卫会在每次检索前计算新查询与历史查询的相似度，如果超过阈值就直接拦截，避免无效的重复检索。

2.3 退出机制：什么时候该停？

ReAct循环不能无限运行。最理想的退出方式是LLM主动判断信息充足后调用结束工具，并附上一段推理摘要供最终生成回答时使用。同时需要设置兜底条件——最大迭代次数和总超时时间，防止意外情况。

2.4 经验库与并发预查询

• 经验库：对于高频问题，运维人员可以预先配置"经验"——包括触发关键词、推荐的检索策略和回答格式要求。当用户的问题匹配到经验时，系统会在推理提示词中注入指导信息，引导LLM用更合适的策略检索和回答。
• 并发预查询：在ReAct循环正式开始之前，系统会同时检索知识库、查询数据库等，把预查询结果作为"初始信息"注入到第一轮推理中。对于很多简单问题，预查询的结果已经足够，LLM在第一轮就可以直接结束循环，省去多轮推理的开销。
• 工具注册的并发安全：多用户同时使用AgentRAG时，临时工具的注册和注销通过引用计数机制保证安全——只有当所有用户都完成推理后，工具才真正从系统中移除。

三、两个"隐形引擎"如何协同工作

文档智能处理和ReAct推理链，虽然分别属于RAG系统的"建库"和"问答"两个阶段，但它们之间存在紧密的关联。

文档处理的质量直接决定了推理链的效率——分片太大会导致检索噪音多，分片太小会导致上下文不足，没有父子分段则检索精度和回答完整性之间存在固有矛盾。反过来，推理链的能力也决定了文档处理的策略选择——如果有AgentRAG的多轮检索能力，就可以放心使用更小的分片，即使第一次检索不够全面，系统可以自己补充。

写在最后

文档智能处理和ReAct推理链，是RAG系统中两个"看不见但少不了"的核心环节。前者决定了知识库中存储的内容质量，后者决定了AI利用这些内容的能力上限。

对于正在建设RAG系统的团队来说，我的建议是：先确保文档处理的基本质量（合理的分片、必要的OCR、正确的向量化），再逐步引入更高级的能力（父子分段、摘要注入、QA抽取），同时配合AgentRAG的多轮推理来弥补文档处理中不可避免的瑕疵。这也是JBoltAI平台在实际迭代中走过的路径——先把基础打牢，再逐步加能力。这种渐进式的优化路径，比追求一步到位要务实得多。