扫描版手册与附照片工单：知识图谱如何终结 22 分钟的客服搜索

关键要点

• 12,000 份文档的客服语料库中有 70% 没有文字层——对一家 460 人的泵业制造商来说，约 126,000 页内容对关键词搜索和纯文本向量索引同样不可见。
• Perplexity 的 pplx-embed-v2-late 在 MADQA 上达到 92.4% 的回答准确率——2026 年 10 月 7 日发布的这组模型无需 OCR 流水线即可直接检索渲染后的 PDF 页面；一个智能体在 800 份真实 PDF、超过 18,000 页的语料上回答了 500 个问题。
• 0.6B 的查询编码器可以查询用 9B 模型构建的索引——共享的 embedding 空间把离线的高成本页面索引与低成本的在线查询配对；0.6B 模型为 594M 参数，MIT 许可。
• LinkedIn 的 GraphRAG 生产部署将检索准确率提升 77.6%——知识图谱的结构化边，是向量索引看不到的东西。
• 页面引用规则改变了失败模式——没有文档页码、件号和序列号范围的回答一律不得发出；凡无法核实的，升级给人工处理，而不是发给客户。

一家中型泵与供水设备制造商每周收到的 950 张工单里，有 300 张不是产品投诉，而是文档问题：什么样的叶轮适配 1998 年制造、序列号为 43-11092 的 SP-200；哪份服务公告取代了 O&M 手册中的扭矩表；2014 年修订版指定哪种垫圈材料——每一条都附有铭牌照片或手册页扫描件。这些问题背后的技术语料库保存着 12,000 份文档、约 180,000 页，其中约 70% 是七十年代以来没有文字层的扫描纸，Zendesk 的搜索索引一页也读不了。

成本体现在两条队列里。对内，6 名技术支持人员平均为每个文档问题进行 22 分钟的人工查找——一份份打开 PDF，用肉眼把手机照片与泵性能曲线对照。对外，经销商和分销商把邮件发进支持邮箱，回复的中位等待时间是 14 小时。两名资深技术员承接了 55% 的升级文档问题，每周替别人的查找工作吸收约 19 个小时。而最坏的失败并不是慢：读错一张原理图会发错备件，引来一轮补货加一次二次上门，去年仅运费和补货处理就花了这家公司约 3.8 万美元。

本文梳理这个三层修复方案——覆盖文档语料库的页面级知识图谱、不做 OCR 步骤、直接检索渲染后 PDF 页面的迟交互嵌入，以及带着正确的页面附件回答问题的智能体流程——每一层都锚定其原始来源：Perplexity 2026 年 10 月 7 日的发布和 LinkedIn 的 GraphRAG 生产部署。

问题：所有人都放弃搜索的那座语料库

凡是经历过纸质时代的制造商都有这样一座语料库。最近五年的手册是数字原生；更早的一切都是扫描进来的——泵性能曲线、接线原理图、爆炸图、尺寸表。有些页面文字尚可辨认；很多则是带打孔、折痕和页边手写批注的低质扫描件。可搜索的 30% 是容易的部分，剩下的 70%是一堵只能靠文件名标识的图像墙。正因如此，关键词搜索和纯文本向量索引的失败方式一模一样：它们都需要一段不存在的文字。

那个显而易见的修复——"给档案做 OCR"——走的是老路上的死法。OCR 的错误在低质扫描上层层叠加，偏偏落在业务价值所在之处：泵曲线的坐标轴变成乱码，尺寸表错位，零件表的列粘连在一起。这正是 Perplexity 团队所说的"昂贵且有损"的先解析再搜索流水线——在检索看到页面之前，就丢掉了"版面、表格结构、插图和空间关系"。对这座语料库做一次 OCR 重建的报价高达六位数，而且没有第二次拨款。

向量搜索试点因另一个原因失败：嵌入文本返回了正确"形状"的泵曲线，却属于错误的修订版；返回了垫片规格，却来自客户的机器所不匹配的手册。向量索引里没有任何东西知道某个叶轮取代了另一个叶轮，或某张扭矩表已在某段序列号范围内作废——结果看起来合理、自信地错误，恰恰是把错误备件发出去的那类回答。助手被搁置，两名资深技术员继续充当事实上的档案系统。本站此前的客服知识图谱文章在软件文档上展示了同样的失败模式；而在扫描的硬件语料库上，它选错的是页码，而不是权宜之计。

智能体编排的方案：页面之下是图谱，页面之上是嵌入

有效的模式让每一层只做它擅长的事。

**第一层——页面级知识图谱。**每份文档是一个节点，文档里的每一页也是一个节点，渲染后的页面图像只存一份。零件、泵型号、序列号范围、修订版都是节点，而边就是回答问题的事实：手册 4412 记录了 SP-200 型号；第 118 页包含叶轮表；叶轮 88-114 在序列号大于 43-0850 时取代 88-114A；公告 91-07 作废了第 40 页的扭矩表；还有——来自 NetSuite 订单历史——序列号 43-11092 于 1998 年发给了某一家经销商，机器的主人持有服务协议。这里没有任何一条要求页面必须是文字。图谱由该公司已经在维护的产品目录、订单记录和修订卡构建而成。

**第二层——渲染页面上的页面级嵌入。**那 70% 的扫描件不需要 OCR：Perplexity 于 2026 年 10 月 7 日发布的 pplx-embed-v2-late 系列"处理文本到图像的检索，可以直接搜索渲染后的 PDF 页面，而无需 OCR 或已解析的文本"。两个规格——0.6B 与 9B，以 MIT 许可发布在 Hugging Face——为每个 token 生成一个 128 维向量，并按 ColBERT 风格的 MaxSim 打分，从而保住泵类问题需要的细节："叶轮"、"SP-200"与一条手绘的轴径，会匹配同一渲染页面的不同区域。在 MADQA——800 份真实异构 PDF、超过 18,000 页、500 道按通用知识无法回答来编写的题目——上，9B 模型答对 92.4%，0.6B 模型答对 90.1%；在视觉文档基准 ViDoRe(v3) 上，0.6B 模型能达到活跃参数五倍于它的模型的水平。由于两个模型共享同一个 embedding 空间，语料库用 9B 模型索引一次，而工单的实时查询走 0.6B 编码器——它可以完全跑在制造商自己控制的硬件上。当手册带着客户现场的保密要求时，这一点很重要。

**第三层——以引用而非段落收尾的智能体流程。**讲 Model Context Protocol（MCP）的连接器模块包住 Zendesk（工单、请求人、附件）、NetSuite（订单、序列号历史、保修状态）和图谱查询工具。流程是：智能体读取工单及照片附件，向嵌入选出候选的渲染页面，再遍历图谱确认候选页面所主张的内容——正确的修订版、正确的序列号范围、正确的取代关系——然后附上真实的 PDF 页面，正文里写明件号与依据（"依公告 91-07，第 40 页的页面表格"）作答。治理规则只有一行，却是承重的那一行：没有页面引用，就不发送——工单升级给人工。买断类问题交给一个保持着实时可售性的 RFQ 引擎处理替代件，以带价格的报价完成闭环；经销商侧的请求通过有作用域的 A2A 智能体代理委派，检索与图谱的每一步都按模块代码标准的模式留痕。实施指南覆盖图谱本身怎么建；这里讲的是运营模式，不是对所有档案都成立的保证。

两名资深技术员仍在环内，只是换了一个高度：他们批准一切安全相关的回答、复核被标记的低置信队列，并处理图谱无法落地的问题。他们不再是语料库的索引。

结果

同一张工单，两种解法——今天的人工查找，对比带着正确页面附件回答的智能体编排流程：

在该公司的规模上部署这类方案所对应的代表性目标，以及该模式所依赖的基准证据:

指标	之前	智能体编排目标
文档问题首响应	14 小时（经销商邮件中位数）	2 分钟以内，页面引用 + 渲染件附上
内部处理中位时长	22 分钟人工查找	3 分钟——技术员核对该页
资深技术员升级负载	文档问题的 55%（约 19 小时/周）	文档问题的 20% 以下
发错备件	季度 9 次（每年 3.8 万美元）	试点季度 1 次
可搜索页数	54,000（有文字层的 30%）	约 180,000，渲染页面原样可用

模式背后的证据：在真实世界的扫描 PDF 上做智能体问答，无 OCR 流水线也能达到 92.4% 的准确率；图谱结构化检索在 LinkedIn 拿到实测 77.6% 的检索准确率提升；而客服知识图谱部署已从软件侧实证了这个画像（解决时长 28 小时降到 7；升级率 45% 降到 18%）。诚实的范围声明：MADQA 是基准，不是对每个档案的承诺——所以才要引用规则和人工复核留在环内。

更深的改变是语料库停止腐化：哪份文件取代了哪份、哪个零件替代了哪个零件、哪台机器换到哪个修订版，如今记在图谱里，而不是记在两颗终将退休的脑袋里。

相关阅读

• 7 小时解决率的客户支持：知识图谱如何将工单时间缩短 75%——软件侧的姊妹用例
• GraphRAG 实施指南：从文本文档到生产级知识图谱检索——构建页面级图谱的五阶段流水线
• 面向客户支持的 GraphRAG：知识图谱如何回答你的数据库无法回答的问题——结构化检索何时值得其成本

---

一家拥有 12,000 份文档、其中 70% 是扫描件的泵业制造商，每次文档查找损失 22 分钟，还会因为没有任何系统读得懂泵曲线而偶发误发货。页面级知识图谱、无需 OCR 即可检索渲染页面的嵌入，以及带着准确页面附件回答的智能体——以"无引用不发送"为闸门——让语料库重新可以回答问题，而 RFQ 引擎把"哪个零件适配"变成一笔带价格、有保留的报价。

申请限定范围的构建

为期一周的发现阶段。无论是否与我们合作，您都将获得系统清单、工作流图谱与固定范围。