AI 如何读懂 Word、Excel、PDF 与图片?联犀多模态检索与关联实战

⬆️ 关注 联犀，最及时最干货的 AI + IoT 分享

一份作业卡里有巡检周期、处理步骤和流程图，另一个 Excel 保存原始记录。问 AI“多久查一次、异常怎么记录、读数在哪里”，它需要把这些资料接起来。

联犀知识库把文档解析、图表处理、双路检索、全文补读和来源引用串在同一个工作台里。底层用内置纯 Go docling保留结构，回答时先找证据，内容不够就继续读，最后能回到对应的文件和章节。

机制示意：从文档结构到检索证据，再到全文与原件回查；上下文扩展使用实际已有关系。

下面用一份带表格和流程图的《配电室巡检作业卡》，加一份《巡检记录》Excel，走完这条链路。资料为人工构造的教学样例，产品截图来自本机隔离环境的实际操作。

一张表，为什么会让 AI 答错？

企业知识库里的文档从来不是纯文本：规范标准里有表格，作业指导书里有流程图和照片，检测报告是 Excel/PDF，论文里有公式和实验图。纯文本处理会带来三种失效：丢信息、丢结构、丢关联。支持多模态不是炫技，而是让知识库能处理真实业务文档。

假设一张作业卡写着：QF-01 每日巡检、QF-02 每周巡检、QF-03 每月巡检。人看一眼就知道，周期必须和同一行的柜号对应。

纯文本 RAG 的做法是把 PDF 抽成文字，再切成一段段小文本（俗称 chunk）做向量检索。问题来了：表格被抽成文字后，行和列的对齐关系丢了。

如果只剩下“QF-01、QF-02、QF-03、每日、每周、每月”这一串文字，即使命中了“每周”，也未必保留了它与 QF-02 的对应关系。

即使你换用更大的模型、更好的向量库，输入本身已经丢失了“表格结构”和“模态语义”。图片、公式、扫描件同理。多模态知识库要做的，是让输入保留足够多的原始信息。

这个拆散表格的例子用于解释问题。后面的真实样例会同时展示解析表格、检索片段和原件，看看这条对应关系是否还在。

多模态 RAG 到底难在哪里

把 Word、Excel、PDF、图片接入知识库，至少要在四个层面解决问题：

解析层。不同格式解析结果差异极大：PDF 可能是扫描图，Excel 有多个 sheet 和合并单元格，Word 里图文混排。

表示层。文本可直接切成 chunk，但图片、表格、公式不行。把图片 OCR 成文字会丢失布局；把表格拍平会丢失行列关系；把公式当成普通字符会丢失数学语义。

关联层。文档里“如图 1 所示”和图 1 之间的联系、表格与说明段落之间的联系，需要保留并能核查。没有这些关系，检索到的内容就容易成为孤立碎片。

检索层。问“图 1 说明了什么”，需要拿到图；问“表 2 最大值”，需要拿到相应数据和单位。只找到文件名或所在页，还没完成任务。

几个术语，先对上含义：

RAG：检索增强生成，先从知识库找到相关内容，再交给 AI 生成回答。chunk：用于检索的内容片段。

embedding / 向量：语义的压缩编码，意思相近的内容在向量空间里距离更近。VLM：视觉语言模型，能同时处理图片和文字。

先读懂文档：结构、表格和图片分别留下什么

在文档工作台打开“解析阅读”，可以查看组织后的正文、表格和图片；“原文件”则保留原始资料的查看入口。

真实界面：作业卡的解析阅读。标题、巡检安排和异常记录步骤可以按内容顺序检查。

联犀内置的解析器是纯 Go 实现的 docling。它把不同格式组织成结构化文档，再交给阅读、分块和索引链路；图片理解与 OCR 根据文件和配置使用相应能力。

先统一内容表示，再做索引

content_list 把 PDF、Word、Excel 等不同格式统一转成“带类型、带位置、带顺序”的标准描述。它的作用是把“解析”和“索引”解耦：后面的内容处理面对结构化元素，不必为每一种输入文件重写整条链路。

这也决定了不同内容应该怎样处理。

正文保留标题与上下文。 “异常记录顺序”属于哪一节，片段从哪里开始，要能对应起来。长文档可以先看结构、再读章节；查询时先取相关片段，必要时补全文。

表格保留行列关系。 设备编号、周期、单位和备注要放在一起看。表格体用于核对具体内容，AI 描述帮助用自然语言找到它。

真实界面：源文件表格与 AI 描述分开展示。QF-02 所在行写着“每周一次”和“三次读数及照片”。

多模态描述生成：上下文比模型更重要

多模态内容如果没有上下文，描述很容易泛泛而谈。同一张流程图放在“正常巡检”还是“异常处置”章节，关注点就不同。标题、图注和相邻说明，能帮助判断描述有没有偏离原意。

图片保留原图，再按条件补描述。 流程图和设备照片可以通过描述进入搜索；命中原媒体时，还可以按条件结合图片理解具体问题。生成的描述与原图分开展示，便于对照。

真实界面：从作业卡提取的记录流程图及视觉描述。本次环境配置了图片输入模型。

扫描件按条件启用 OCR。 原生文本 PDF 和扫描 PDF 的处理条件不同。扫描页、图片没有可直接提取的文本时，需要相应的 OCR 或视觉配置；识别结果仍受清晰度、版式和模型影响。

再找证据：两路召回怎样配合？

把问题放进检索测试：

QF-02 柜多久巡检一次？发现异常后按什么顺序记录？

“QF-02”是具体编号，“多久巡检”“按什么顺序记录”是自然语言任务。用户未必使用资料中的原词，编号却又不能找错。

向量召回负责找相近的意思。 问“多久检查一次”，资料可能写“巡检周期”；表达不同，仍有机会找回相关片段。

SQL 词法召回补充文字线索。 柜号、型号和术语可以帮助对上具体对象，弥补只看语义相近时容易混淆的地方。

两路的原始分数尺度不同，不能直接比大小。联犀用 RRF 融合汇总排名：先在每路中取各文档得分最高的片段，再按文档排名融合，为每份文档保留一个代表片段。

计算时把各路的 1 /（60 + 名次）相加。60 是平滑常数，用来缓和单路名次变化；融合分数表达排序，不是正确概率。

还有一道文档多样性排序：通过轮流从不同文档取候选来安排结果，为其他相关资料保留位置。查作业要求时，长手册中的相似片段不能把配套记录全部挤出去。

检索机制示意：向量与 SQL 词法两路召回，经 RRF 融合和文档多样性排序；相邻片段与已有关系按条件补充。

这里的关联扩展用于补上下文。它要有实际已有关系作依据，与前面的两路召回分工不同。

片段不够，继续读完这道题

这次查询的实际结果如下。

真实查询：问题同时包含巡检周期和异常记录顺序，界面显示中置信度。

首轮直接找回了“每周一次”的说明，也召回了配套记录资料；完整异常记录步骤还需要补读。

周期找到了，第二问还没答全。接下来可以缩小问题查“异常记录顺序”，或者直接读取作业卡全文，定位第二节。

这份作业卡的第二节写明：先记录编号、发现时间和现象，再核对作业卡与历史记录，补充照片和三次读数，最后交负责人复核。从一个周期片段，补到一个完整章节，回答才有了第二问的依据。

在 AI 的工具流程里，检索负责找相关证据，全文工具负责补读文档，关联工具负责查看实际存在的相关内容。它们可以配合使用，资料不足时也可以改写问题继续查。

使用时可以这样交代任务：

先查 QF-02 的巡检周期，列出来源。再查异常记录步骤；片段不足时读取作业卡全文。把原文要求和解释分开，缺少依据的项目直接指出。

这是一条可复制的任务问法。它把“检索—补读—列来源”放进同一个要求，让后续核对有明确入口。

Agent 怎样决定下一步查什么？

检索测试展示的是一次查询；Agent 需要继续判断，这些证据够不够回答用户的问题。没有找到关键对象，就改写或拆分问题再搜；关键步骤被截断，就根据文档 ID 读取全文；还需要相关说明，就根据切片 ID 查看已有关系。

机制示意：Agent 按证据缺口选择工具，可改写问题继续检索，也可补全文或已有切片关系；仍无依据时说明缺口。不是一次实际对话记录，也不是每题必经的固定流程。

检索范围限定在助手已绑定的知识库中。图中的关联工具读取已有切片关系；后文的人工字段引用演示，仍用于展示另一种明确记录来源位置的方式。

把两份资料连起来：从作业卡找到原始记录

回答“要补三次读数”之后，下一步自然是：记录到底在哪份文件？

作业卡第三节已经写出依据：配套文件《巡检记录（教学样例）.xlsx》的“本周记录”工作表保存 QF-02 三次示例读数。 这句话明确指出了文件、工作表与对象，正适合建立一条可核查的引用。

我们根据这段原文，在隔离环境中人工建立了从作业卡第三节到《巡检记录》工作表的字段级引用。保存后，在“文档关联—字段引用”中可以查看正向引用，展开看到人工备注与两侧定位。

真实界面：作业卡引用《巡检记录》的“本周记录”工作表，来源标记为“人工”，并保留建立引用的文字依据。

再切到《巡检记录》，同一条引用出现在反向列表：可以知道哪份作业卡、哪个章节引用了这份记录。

真实界面：从被引用的记录表反查作业卡，两侧文档与章节定位对应同一条引用。

这条引用把“要求在哪里”和“记录在哪里”连了起来。 看作业卡时能找配套记录，检查记录时也能找到使用它的文档。

这里要分清两类关联：检索中的语义关系扩展用于补充相关片段；字段级引用用于明确记录某处内容引用了哪里。本例验证的是后者的人工建链与正反向查看，不能据此推断 AI 自动识别或检索扩展也已经生效。

引用记录提供定位、依据和来源版本，便于回查与判断影响；它不会自动修改原文件，也不等于重新计算了 Excel 公式。

回到原件，核对最后一处对应关系

最后把“QF-02 每周一次”放回原表看一眼。

真实原文件局部：QF-02 与“每周一次”在同一行，记录要求也与该设备对应。

解析阅读方便查看组织后的内容，原文件用来确认排版、单位、备注和图表关系。引用则帮助找到相关资料的位置。这几个入口配合起来，查资料才能从“找到了一个答案”走到“知道答案依据什么”。

做方案时，留下这几条工程判断

统一协议先于多模态算法。 先保留内容类型、位置和顺序，再讨论切片与索引。否则输入丢失的结构，会把问题一路传到回答环节。

跨模态关系是检索质量的放大器，不是替代品。 向量与词法召回负责找证据，有依据的关系负责补上下文；明确的来源引用帮助人回查。分别验证，才能知道哪一步起了作用。

多模态描述生成按需触发，控制成本。 保留原图、生成描述、查询时结合原媒体理解，是不同动作，按文件、问题和配置使用相应能力。

把检索质量和回答质量分开测。 排名靠前，不代表答案完整。用一张带备注的表、一份含图作业卡、一份扫描件，再加一道跨章节问题，逐项检查：读出了什么、找回了什么、补读了什么、来源在哪里。

遇到结果不对，就沿这四步回看：原件有无依据，解析是否保留，检索是否命中，上下文是否完整。实时设备状态另查业务数据，不拿手册内容代替现场读数。

把原件、问题、检索片段和来源位置一起留给业务与开发，比只保存最终答案更有用。拿一份团队反复翻找的作业卡开始，试一道需要跨章节、跨文件才能答全的问题。

技术来源

内置解析组件：联犀纯 Go docling，源码与使用说明见 https://github.com/unitedrhino/docling。

⬆️ 关注 联犀，最及时最干货的 AI + IoT 分享