掃描版手冊與附照片工單：知識圖譜如何終結 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 引擎把「哪個零件適配」變成一筆帶價格、有保留的報價。

申請限定範圍的建置

為期一週的探索階段。無論是否與我們合作，您都將取得系統清單、工作流程圖譜與固定範圍。