企業 AI 落地的殘酷真相：非結構化文檔才是最大敵人

呢排喺 V2EX 上面睇到好多做企業 AI 落地嘅 post，有一個共通焦慮：「點解 POC 做到 92% 準確率，一上生產就仆直？」有人話係模型揀錯，有人話係 RAG 架構唔掂，有人索性自己做一個文件解析工具放上嚟賣。但當你刨晒成串討論，會發現一個冇人願意直接講嘅事實：大多數企業 AI 項目嘅樽頸，根本唔喺模型層，而喺一個悶到極嘅老問題——你間公司啲 PDF、Word、Excel 從來都唔係設計俾電腦讀嘅。

Gartner 喺 2024 年已經出過一個震撼數字：到 2026 年，超過 60% 嘅 AI 項目因為缺乏「AI-ready 數據」而會被放棄。另一份研究更加直接：70-80% 嘅企業 RAG 項目連生產環境都入唔到。唔好以為係誇大，你隨便捉一個做過企業 AI 落地嘅工程師，佢都可以同你講三四個「POC 好靚仔，Production 好頭痛」嘅真實案例。

問題核心係一個殘酷嘅比例：企業 80-90% 嘅數據係非結構化——合約、審計報告、電郵附件、會議紀錄、規格書、Excel 表。呢啲文件嘅存在形式係「俾人睇」嘅排版設計，唔係「俾電腦 query」嘅結構化數據。你將一份裝嵌咗跨頁表格、SmartArt 圖形同多層級標題嘅 PDF 直接掟入 RAG pipeline，就等於叫一個人由一本撕爛咗嘅電話簿入面搵出一個地址。模型再做得好，input 係 garbage，output 就係 garbage。

文件唔係數據，係打印格式

呢個係最多團隊睇漏嘅認知謬誤。一份 PDF 之所以係 PDF，係因為 Adobe 三十年前設計佢嘅目的係「無論喺邊部機打印出嚟，睇起嚟都一樣」。呢個設計目標同「俾 AI query」完全相反。你諗下：一份排版靚仔嘅財務報告，入面有個跨三頁嘅合併儲存格表格、十幾個互相交叉引用嘅條款定義、仲有幾幅嵌入嘅 SmartArt 圖表。傳統 PDF parser 將佢 flatten 成 pipe-delimited 文字行嘅時候，表格結構冇咗，定義引用斷咗，圖片描述消失咗。Embedding 模型收到呢啲垃圾碎片，retrieve 返嚟嘅自然係垃圾。

V2EX 上有人分享佢哋做製造業知識庫嘅經驗：POC 嗰陣用 500 份乾淨嘅文字型 PDF，準確率 92%。一上生產接入 4.2 萬份真實文檔，第一星期準確率插水到 61%。點解？因為真實文檔入面有技術規格書嘅多級嵌套表格、掃描版合約嘅 OCR 偏差、PPT 匯出 PDF 入面 SmartArt 文字直接消失。同一套 parser，同一套 chunk 策略，喺唔同文件類型面前完全失效。

呢個現象唔係個別案例。BuiltIn 嘅分析文章提出一個重要觀察：「企業 RAG 項目有一個大約 65% 嘅準確率天花板。」唔係因為模型唔夠好——Claude、GPT-4o、Gemini 逐代進步，呢個天花板紋風不動。因為問題根本唔喺模型層，而喺 substrate——嗰層俾模型去讀嘅原材料本身就有結構缺陷。

三個結構性死穴：表格、交叉引用、版本漂移

如果你準備做企業 AI 落地，以下三個問題你避無可避，而且唔可以用「換個更勁嘅模型」解決。

第一個係表格崩潰。一份 pricing schedule、cap table 或者參數矩陣，係一份文檔入面數據密度最高嘅部分。但主流 PDF parser 將佢哋 flatten 成 pipe-delimited 嘅文字行之後，Embedding 模型根本認唔到邊個數值屬於邊個欄位。結果係：成份文檔最重要嘅數據，變成檢索系統最唔願意 retrieve 嘅 garbage。業界流行一句說話：「Table handling 係 RAG 系統最常見嘅靜默失敗原因。」

第二個係交叉引用斷裂。一份合約第三頁定義咗一個術語，第四十頁嘅修訂條款改咗個定義，第七十八頁嘅付款條款引用咗呢個定義。AI 要正確回答一條關於付款條件嘅問題，需要同時理解呢三個章節嘅上下文。但 RAG 嘅歸還機制係靠 cosine similarity 揀最似嘅 Top-K chunks——模型好大機會只拎到第三頁或者第七十八頁嘅某一段，中間嘅定義修改完全消失。輸出流暢、自信，但錯晒。

第三個係版本漂移。你將 policy v7 更新咗上生產系統，但 vector index 入面仲有 v6 嘅 chunks。AI bot 引用咗 v6 嘅內容，講足幾個月都冇人發現，直到 auditor 敲門。呢個唔係假設性風險，係已經有完整記錄嘅企業失敗模式。

呢三個問題嘅共同特徵係：你唔可以用更長嘅 prompt、更好嘅 fine-tune 或者更 sophisticated 嘅 re-rank 模型去解決。因為佢哋根本唔係 AI 問題，而係數據工程問題。

將工程精力從模型層移到數據層

呢個認知轉變，係企業 AI 落地最關鍵嘅一步。太多團隊嘅工程分配係：80% 精力揀模型、調 prompt、試 agent framework；20% 做 document ingestion。但事實係，injection pipeline 先係決定 accuracy 嘅主要變數。

做過生產級 RAG 嘅團隊都知：POC 階段用 50 份靚仔 PDF 測試，乜 parser 都得。但真實環境入面，你嘅文件來源包括：掃描件（要前置 OCR）、表格密集型 PDF（要專用 parser）、嵌入 SmartArt 嘅 PPT 匯出版（文字位置完全唔同）、Excel 試算表（有人當 database 用，有人當 formatting 用）。冇一個 parser 可以通食。你需要按文件類型做路由：文字型 PDF 行快速通道，表格密集行 LlamaParse，掃描件先過 OCR pipeline。前文提到果間製造業公司就係靠呢套組合拳，將解析準確率由 73% 拉到 94%。

同樣道理，chunk 策略唔可以一刀切。技術手冊 512 token 剛好 cover 一個完整步驟；會議紀錄核心資訊散落在多個短對話輪次，要用 800-1200 token 嘅語義邊界切分；合約要按條款編號切。再加上 metadata 注入——每個 chunk 帶住文檔標題、章節路徑、最後修改日期——檢索相關性可以即時提升十幾個百分點。

一句講晒：將 ingestion pipeline 當成你產品入面最貴、最重要嘅 engineering surface。 投資喺呢度嘅每一蚊，回報都比投資喺 model layer 高一個數量級。

香港團隊嘅實際行動點

如果你係香港嘅創業者、開發者或者知識工作者，準備或者正在幫客戶做 AI 落地，以下係幾個具體建議。

第一，喺傾報價嘅階段就要搞清楚對方嘅文檔生態。唔好聽完「我哋有文件管理系統」就信晒。問清楚：係原生 PDF 定掃描件？有冇表格？表格係簡單 list 定跨頁合併？有冇版本管理機制？如果對方答唔出，呢個本身就係危險信號。你應該主動提出做一個 document audit——抽 100 份真實文檔，逐份分析格式分佈同解析難度。呢個 audit 唔單止幫你估算工程成本，仲係建立客戶信任嘅第一步。

第二，做好「預期管理」嘅功課。而家市場上太多 AI 公司賣緊「plug and play」嘅幻象。你要同客戶講清楚：Document ingestion 唔係一次性功夫，而係需要持續營運嘅基礎設施。解析質量要監控、chunk 策略要迭代、向量庫要隨文檔增長而調整。唔好承諾「三個星期搞掂」，而係俾佢哋睇 Gartner 個 60% 失敗率，然後解釋你點樣透過工程紀律將成功率提高。

第三，認真審視自己團隊嘅 engineering allocation。你而家幾多人手喺 model layer，幾多人手喺 data layer？如果比例超過 50:50，你嘅風險好高。考慮用開源工具（Unstructured、LlamaParse、MinerU）砌一條混合 parsing pipeline，而唔好買一個號稱「乜都食到」嘅商業方案——我未見過任何商用 parser 可以喺真實企業環境達成 90%+ 嘅全格式準確率。

最後，唔好低估「將文件當作結構化數據」嘅思維轉變。而家出現咗一個新嘅 infrastructure category 叫 Unstructured Data Hub，專門處理 text-heavy、context-rich 嘅非結構化內容。呢類工具嘅核心思路係：文件唔應該被當作檔案，而應該被當作一個由 clause、definition、parameter、reference 組成嘅 typed graph。這個概念將會喺未來兩三年改變企業 AI 嘅遊戲規則。

結語

每一次同人傾企業 AI 落地，最常見嘅問題都係「用邊個 model」、「做唔做 fine-tune」、「使唔使 agent framework」。好少人會問「你啲文件得唔得」。但殘酷嘅現實係：喺你搞掂啲非結構化文檔之前，其餘一切討論都係浪費時間。

模型會繼續進化，token 成本會繼續下降，agent framework 會繼續成熟。但只要你嘅 input 仍然係一份為打印而設計嘅 PDF，65% 嘅準確率天花板就會一直喺度。真正嘅差異化競爭力，唔在於你用到邊個最新嘅模型，而在於你能否將公司入面最混亂嘅 80% 數據，變成 AI 可以可靠 query 嘅結構化資產。

文件係最後一個未解決嘅數據結構問題。邊個 solve 到呢個問題，邊個就贏。