從文件到代理知識庫：完整的資料管道

企業 AI 代理因一個可預測的原因而失敗：知識庫很糟糕。不是「略微次優」——而是糟糕。文件在沒有清理的情況下被擷取。PDF 的 OCR 錯誤在整個管道中傳播。塊在句子中間分割，或將表格與其說明文字分離。元資料太稀疏，以至於檢索系統無法區分 2024 年的政策更新和 2019 年的草稿。

結果是一個自信地幻覺的代理。它檢索到損壞的塊，將其視為真相，並生成聽起來有權威但卻是錯誤的答案。在受監管行業，這不是尷尬——這是法律責任。

修復不是更好的檢索算法或更大的嵌入模型。修復是更好的資料管道。此處描述的五階段管道將原始企業文件轉換為結構化、檢索優化、代理就緒的知識。跳過任何階段，代理準確率就會明顯下降。

知識庫品質問題

Databricks 在 2025 年底的一項研究發現，67% 的 RAG 系統故障可追溯到資料品質問題——不是檢索失敗，不是模型限制，而是垃圾輸入。細分：28% 來自 OCR 和解析錯誤，19% 來自糟糕的分塊（相關資訊跨塊分割），12% 來自缺失的元資料，8% 來自重複或矛盾的內容。

這與我們在企業部署中看到的情況相符。團隊花費數週調整檢索參數和嵌入模型，而真正的問題是源資料從未被正確清理。

管道投資回報自身。實施所有五個階段的團隊通常看到檢索準確率從 55 至 65%（原始擷取）提高到 85 至 92%（完整管道）。代理答案準確率隨之提高：在特定領域問題上從 40 至 50% 提高到 75 至 85%。

階段 1：擷取

第一階段處理格式多樣性。企業文件以各種格式出現：PDF（掃描和原生）、Word（.docx、.doc）、PowerPoint、Excel、電子郵件（.eml、.msg）、HTML、Markdown、Slack 匯出、Confluence 頁面、SharePoint 文件和純文字。

每種格式需要專門的解析器：

• PDF（原生）：提取帶有版面保留的文字。Docling 或 PyMuPDF 等工具處理這個問題很好。保留表格結構、標題和頁碼。
• PDF（掃描）：使用 Tesseract 或本地視覺模型進行 OCR。乾淨掃描的字元準確率預計 95 至 98%，舊文件或低品質文件為 85 至 90%。
• Word/PowerPoint：直接解析 XML 結構。python-docx 和 python-pptx 處理大多數情況，但注意帶文字的嵌入圖片、文字框和 SmartArt——這些經常被遺漏。
• 電子郵件：提取正文、主題、發件人、收件人、時間戳和附件。附件作為單獨的文件重新進入管道，帶有父子元資料鏈接。
• Slack/Teams 匯出：帶有線程結構的 JSON 格式。保留線程上下文——沒有其線程的個別消息通常毫無意義。

第 1 階段的輸出是標準化的中間格式：帶有結構標記（標題、段落、表格、列表）和源元資料（文件名、格式、頁碼、提取日期、提取信心分數）的純文字。

量測基準：典型的企業知識庫項目從 10,000 至 50,000 個文件開始。在單個 16 核伺服器上的擷取吞吐量：原生格式每小時約 500 至 1,000 個文件，需要 OCR 的掃描 PDF 每小時約 100 至 200 個。

階段 2：清理

原始提取的文字是嘈雜的。清理去除會降低檢索品質的雜訊。

OCR 修正：常見的 OCR 錯誤遵循可預測的模式——「rn」被誤讀為「m」，「l」和「1」互換，連字符被破壞。建立特定領域的修正詞典。對於法律語料庫，這意味著識別「Artide」應為「Article」，「dause」應為「clause」。

去重：企業文件存儲中充滿了重複項——同一份備忘錄保存在三個文件夾中，相同的政策文件在共享硬碟和 wiki 中，電子郵件附件跨收件人重複。使用基於內容的去重（對正規化文字進行雜湊）而非文件名匹配。預計 15 至 30% 的文件是重複或近似重複的。

格式正規化：標準化 Unicode 編碼、換行符、空白和特殊字元。將花引號轉換為直引號。正規化破折號（全形破折號、半形破折號、連字符全部變為標準連字符）。這防止了因字元編碼差異導致的檢索遺漏。

樣板去除：頁眉、頁腳、版權聲明、頁碼、「CONFIDENTIAL」水印、電子郵件簽名。這些在每個塊中增加噪音而不增加資訊。使用模式匹配偵測並去除它們。

語言偵測：在跨國企業中，文件可能是多種語言的。為每個文件標記其語言，用於下游處理（不同語言使用不同的嵌入模型，或將翻譯作為預處理步驟）。

第 2 階段的輸出是乾淨、正規化的文字，保留了結構標記並去除了雜訊。隨機 50 個文件的抽樣檢查應顯示零 OCR 雜訊、零重複和零樣板殘留。

階段 3：結構化

乾淨的文字在能有效分塊之前需要結構。結構偵測識別每個文件的語義組織。

章節偵測：識別標題、副標題和文件的層次結構。政策文件有章節、節和小節。技術手冊有編號的節。電子郵件線程有帶時間戳的個別消息。

元資料提取：從內容中拉取結構化資訊：日期、版本號、作者名稱、部門引用、產品名稱、法規引用。這些元資料成為檢索系統中的可過濾屬性。

實體識別：識別與領域相關的命名實體——產品名稱、客戶名稱、法規識別符（GDPR 第 6 條、ISO 27001 第 A.12 節）、內部項目代碼。實體標籤使精確檢索成為可能：「顯示所有提到 Phoenix 項目的文件」根據實體匹配而非關鍵字搜尋返回結果。

表格提取：文件中的表格包含密集的結構化資訊。將它們提取為結構化資料（行和列）而非將它們壓扁為文字。壓扁為文字的財務表格變成「Revenue Q1 2025 $4.2M Q2 2025 $4.8M」——對比較查詢毫無用處。保存為結構化資料，檢索系統可以精確回答「2025 年第二季度的收入是多少？」

交叉引用解析：文件引用其他文件。「如政策 4.2.1 所述」應鏈接到知識庫中的政策 4.2.1。解析內部交叉引用以創建代理可以遍歷的文件圖。

階段 4：分塊

分塊是大多數知識庫管道成功或失敗的地方。目標是將文件分割成足夠小以進行有效嵌入和檢索，但足夠大以保持語義連貫性的片段。

固定大小分塊

每 N 個標記（通常為 256 至 512）分割文字。快速、簡單且粗糙。固定大小分塊在句子中間分割，將問題與答案分開，並將表格一分為二。固定大小分塊的檢索準確率：通常為 60 至 70%。

使用案例：快速原型、低風險應用、速度比品質更重要的情況。

句子級別分塊

在句子邊界分割，然後將句子組合到目標塊大小。比固定大小更好，因為塊尊重句子結構。仍然存在問題，即在 5 至 6 個句子中構建論點的段落——在第 3 句後分割會失去結論。

檢索準確率：通常為 70 至 80%。

語義分塊

使用 LLM 或嵌入模型識別語義邊界——話題轉換的點。將語義相關的句子分組到塊中，無論其長度如何（在限制範圍內）。這保留了解釋、論點和程序的連貫性。

檢索準確率：通常為 80 至 90%。

語義分塊的成本是計算時間。本地 LLM 處理每個文件以識別語義邊界，為分塊階段增加 5 至 10 倍的時間。對於準確性重要的企業知識庫，這種取捨是值得的。

重疊策略

無論分塊方法如何，使用重疊——將每個塊的最後 1 至 2 個句子作為下一個塊的第一個句子。這防止了塊邊界處的資訊丟失。塊大小的 10 至 15% 的重疊是標準的。

保留上下文

每個塊必須攜帶其上下文：文件標題、節標題、頁碼和前面節摘要。沒有上下文，「閾值為 5%」的塊毫無意義。帶有上下文——「文件：風險政策 2026 > 第 3.2 節：信用風險限額 > 閾值為 5%」——檢索系統可以將其與正確的查詢匹配。

階段 5：匯出

最後階段產生您的代理系統消耗的輸出格式。大多數企業部署需要兩種輸出：

向量就緒嵌入：使用適合您領域和語言的模型嵌入每個塊。將嵌入與元資料（源文件、節、日期、實體）一起存儲在向量資料庫中。這為檢索增強生成（RAG）提供動力。

微調用 JSONL：以指令/響應對格式化的相同內容，用於微調。這使互補方法成為可能，模型直接學習領域知識，減少常見查詢對檢索的依賴。

從單個管道生成兩種輸出比運行兩個獨立管道更有效率。擷取、清理和結構化階段是相同的——只有匯出格式不同。

品質驗證

在部署知識庫之前，驗證它。

檢索準確率測試：準備 100 至 200 個具有已知答案的測試查詢。對知識庫運行每個查詢，並檢查正確的塊是否出現在前 5 個結果中。目標：生產部署超過 85%。

答案品質抽樣檢查：讓領域專家審查從知識庫生成的 50 個代理響應。根據準確性、完整性和來源歸屬為每個響應評分。任何引用不存在或不正確來源的響應都表明管道故障。

覆蓋率分析：知識庫是否涵蓋了代理預期處理的所有話題？將話題映射到文件並識別空白——這些是代理將幻覺的話題，因為它沒有源材料。

新鮮度審計：檢查文件日期。如果政策的最新版本是 2023 年的，但 2025 年的更新存在於另一個文件夾中，知識庫是陳舊的。實施一個新鮮度檢查，標記有更新版本可用的文件。

本地部署優勢

整個管道在本地基礎設施上運行。文件——通常包含專有業務資訊、客戶資料、個人資訊和商業秘密——永遠不會離開組織的網路。

這不只是合規核取方塊。這是形成企業知識庫的文件類型的實際要求：帶薪酬詳情的人力資源政策、帶訴訟策略的法律備忘錄、帶非公開資料的財務報告、帶商業秘密的工程文件。

本地部署也消除了供應商依賴。當您的文件管道在第三方雲端服務上運行時，該服務控制您的更新排程、您的格式支援和您的定價。當它在本地運行時，您控制這三者。

基礎設施要求很適中。單個帶 64GB RAM、16 個核心和 NVIDIA A100 或同等 GPU 的伺服器，可以處理多達 100,000 個文件的知識庫的所有五個管道階段。較大的語料庫受益於跨多個節點的並行化，但管道本身是令人尷尬地並行的——每個文件獨立流過各個階段。

延伸閱讀

• 為企業建立 AI 代理知識庫 — 企業知識庫架構和治理的戰略考量。
• 企業 AI 資料準備指南 — 企業 AI 部署的更廣泛資料準備格局。
• 非結構化文件作為 AI 訓練資料 — 如何處理企業資料中 80% 存在於非結構化格式的資料。