在本地從企業文件構建 AI 代理商知識庫

AI 代理商的好壞取決於其背後的知識庫。您可以在最好的硬體上使用最好的代理商框架部署最好的模型，如果知識庫包含解析不佳的文件、分塊不好的文本、重複內容或過時信息，代理商仍然會給出錯誤的答案。

這不是理論上的問題。在企業代理商部署中，檢索品質——向量存儲返回的內容的準確性和相關性——是代理商輸出品質的最強預測指標。使用 7B 模型的構建良好的知識庫，始終優於使用 70B 模型的雜亂知識庫。瓶頸幾乎總是數據，而不是模型。

本指南詳細介紹了完全在本地從企業文件構建代理商知識庫的完整管線。沒有數據離開您的網路。沒有外部 API 被調用。每個組件都在本地運行。

管線概覽

原始企業文件
    ↓
步驟 1：文件攝入（解析）
    ↓
步驟 2：文字清洗
    ↓
步驟 3：帶元數據的分塊
    ↓
步驟 4：嵌入（本地模型）
    ↓
步驟 5：向量存儲索引
    ↓
步驟 6：檢索測試和驗證
    ↓
代理商 RAG 查詢

每個步驟都有特定的要求、常見的失敗模式和品質指標。跳過或簡化任何步驟都會降低最終知識庫的品質——以及代理商的輸出品質。

步驟 1：文件攝入

企業文件有幾十種格式：PDF（基於文字的和掃描的）、Word 文件（.docx、.doc）、Excel 試算表、PowerPoint 演示文稿、電子郵件（.eml、.msg）、HTML 頁面、純文本文件，以及有時來自企業系統的專有格式。

良好解析的樣子

良好的文件解析保留了原始文件的結構和含義：

• 節標題被識別和標記，不會被扁平化為正文文字
• 表格被提取為結構化數據（行和列保留），不轉換為文字流
• 列表保持其順序和嵌套
• 頁眉和頁腳被識別並與正文內容分開
• 頁碼從文字中移除，但作為元數據記錄
• 帶文字的圖片（帶標籤的圖表、示意圖）進行 OCR 並提取文字
• 傳達含義的格式提示（粗體、斜體、下劃線）被保留或注釋

特定格式挑戰

PDF 是最常見也是最麻煩的格式。從 Word 生成的基於文字的 PDF 很直接——文字層可以提取。掃描的 PDF 是需要 OCR 的圖像。從網頁生成的 PDF 可能有不尋常的列佈局。帶有表單字段的 PDF 在表單層中有簡單文字提取遺漏的數據。

Word 文件通常更容易解析，但複雜的格式——嵌套表格、文字框、SmartArt、嵌入對象——可能會迷惑提取器。修訂追蹤和批注可能相關或不相關，取決於用例。

Excel 試算表存在結構性挑戰：儲存格之間的關係（哪個標題與哪個值對應）是空間性的，而非文字性的。將試算表扁平化為文字會丟失這些關係。合併儲存格、多個工作表和公式增加了複雜性。

電子郵件的元數據（發件人、收件人、日期、主題）通常比正文文字對檢索更重要。電子郵件鏈有轉發文物、回覆標記和簽名塊，應該清理。附件需要單獨處理。

實際方法

使用具有格式特定邏輯的文件解析器處理多種格式。在您的文件語料庫樣本上運行解析器，並手動檢查輸出。標記未通過品質檢查的文件——超過閾值的 OCR 錯誤、缺失節、損壞的表格——以供人工審查或重新處理。

品質指標： 解析準確率——有多少百分比的文件在沒有重大結構錯誤的情況下被解析？目標：基於文字的文件 90% 以上，掃描文件 80% 以上（帶 OCR）。

步驟 2：文字清洗

解析的文字不是乾淨的文字。清洗移除了降低檢索品質而不增加信息價值的文物。

要移除的內容

• 樣板內容： 每頁重複的頁眉、頁腳、版權聲明、保密免責聲明。這些在不增加檢索價值的情況下向向量存儲添加噪音。
• 頁碼和頁眉： 每頁上的「第 47 頁，共 132 頁」和「Acme Corp — 機密」會污染嵌入空間。
• OCR 文物： 誤識別的字元、斷裂的詞語、來自差質掃描的亂碼文字。輕微的 OCR 錯誤（將「l」替換為「1」）可以通過後處理糾正。嚴重錯誤可能需要重新掃描或手動轉錄。
• 編碼問題： Unicode 標準化、智慧引號 vs 直引號、破折號 vs 連字符。這些看起來微不足道，但會導致重複檢測失敗（具有不同編碼的相同文字被視為不同的）。
• 重複內容： 相同文件存在於多個位置（電子郵件附件、共享硬碟、文件管理系統）。相同段落出現在多個文件中（標準條款、樣板部分）。

要保留的內容

• 領域術語： 不要「清理」技術術語、縮寫或行業術語。「ICD-10-CM」不應該被標準化為「ICD 10 CM」。
• 數值數據： 數字、測量值、日期、財務值。這些對檢索很有價值。
• 文件結構： 節分隔、標題層次、列表結構。這些為分塊提供信息。
• 元數據： 作者、日期、文件類型、版本、部門。這些支援過濾檢索。

去重策略

去重在兩個層面進行：

文件層面： 精確和近似重複偵測。基於哈希的比較捕捉精確重複。基於相似性的比較（MinHash、SimHash）捕捉近似重複——90% 以上相似但有輕微差異的文件（版本號、日期、格式）。

段落層面： 標準條款、樣板部分和頻繁複製的文字出現在許多文件中。應對這些進行去重，以防止向量存儲過度表示常見文字，而犧牲獨特的高價值內容。

品質指標： 去重率——有多少百分比的重複或近重複內容被移除？目標：95% 以上的重複被消除，同時保留零唯一內容。

步驟 3：帶元數據的分塊

分塊是大多數知識庫構建出錯的地方。默認方法——每 512 或 1,024 個字元分割文字——易於實現，但可靠地產生糟糕的結果。

為什麼字元數分塊會失敗

字元數分塊對文件結構沒有意識。它會分割：

• 標題行和數據行之間的表格，創建一個有列名但沒有數據的塊，以及另一個有數據但沒有列名的塊
• 條件和結果之間的條件語句（「如果患者有糖尿病...」在一個塊，「...那麼開立二甲雙胍」在下一個塊）
• 列表項目之間的編號列表，失去列表的上下文
• 段落中間的一個句子，創建以句子碎片開頭和結尾的塊

每個這樣的分割都創建了單獨無意義或誤導性的塊。當代理商檢索到說「那麼開立二甲雙胍」而沒有條件的塊時，它可能會無條件推薦二甲雙胍。

語義分塊

語義分塊在自然主題邊界處分割：

• 節標題： 在每個標題處分割。這保留了文件的邏輯單元。
• 段落邊界： 在一個節內，在段落分隔處分割。每個段落通常處理一個點。
• 表格邊界： 將表格作為單個塊完整保留。在每個表格塊中包含表格標題。
• 列表邊界： 完整保留列表。在列表項目中包含引導文字。

塊配置

元數據標記

每個塊必須攜帶支援過濾檢索和可追溯性的元數據：

• source_document： 原始文件的文件名或文件 ID
• source_path： 文件系統或 DMS 中原始文件的位置
• document_date： 文件的創建或最後更新時間
• document_author： 誰創建了文件
• document_type： 政策、程序、指南、合同、電子郵件、報告等
• section_title： 此塊所在節的標題
• chunk_index： 此塊在文件中的位置（用於排序）
• classification： 保密級別、部門、業務單元

這些元數據有三個用途：

1. 過濾檢索： 「查找關於出差政策的信息」→ 按 document_type=policy 過濾，搜索「出差」
2. 時效加權： 當多個版本存在時，優先考慮來自較新文件的塊
3. 稽核追蹤： 將任何代理商回應追溯到具體的塊和源文件

品質指標： 塊連貫性——對於樣本塊，每個塊是否包含完整的、獨立的信息片段？目標：80% 以上的塊是連貫的獨立單元。

步驟 4：嵌入

嵌入將文字塊轉換為捕獲語義含義的數值向量。相似的概念產生相似的向量，支援語義搜索。

選擇嵌入模型

對於本地部署，嵌入模型必須在本地運行。不調用外部 API。目前最佳選項：

對於大多數企業知識庫，E5-large-v2 或 BGE-large-en-v1.5 提供了最佳的品質和速度平衡。它們在 CPU 上批量嵌入運行良好，並為語義搜索產生高品質向量。

對於非常大的知識庫（50 萬個以上塊），其中檢索品質至關重要，E5-mistral-7b-instruct 提供了更好的語義理解，但需要 GPU 以獲得合理的嵌入速度。

批量處理

企業文件語料庫很大。逐一嵌入 100,000 個塊很慢。批量處理——一次嵌入 32-128 個塊——速度快 10-50 倍。

對於產生約 50 萬個塊的 100,000 個文件的語料庫：

計劃初始嵌入需要幾個小時，而非幾分鐘。後續更新（僅新增或修改的文件）是增量的，速度快得多。

一致性

使用相同的嵌入模型進行索引和查詢。如果您使用 E5-large-v2 嵌入文件，您的代理商查詢也必須使用 E5-large-v2 嵌入。混合嵌入模型會在不同空間中產生向量，使相似性搜索毫無意義。

步驟 5：向量存儲索引

嵌入的向量需要存儲在支援高效相似性搜索的向量數據庫中。對於本地部署：

對於大多數企業部署（10,000-500,000 個文件，50,000-250 萬個塊），Qdrant 是推薦的選擇。它能處理這個規模，支援元數據過濾（企業使用的關鍵），並在單台服務器上運行良好。

對於非常大的部署（超過 100 萬個文件），考慮使用 Milvus 的分佈式架構。

索引配置

• 距離指標： 餘弦相似性是默認值，對大多數文字嵌入模型效果良好
• 索引類型： HNSW（層次可導航小世界）用於近似最近鄰搜索——快速且準確
• ef_construction： 較高的值（128-256）以較長的構建時間為代價構建更好的索引。對於企業部署值得投資。
• m： HNSW 圖中每個節點的連接數。16-32 是典型值。較高的值以更多內存為代價改善召回率。

步驟 6：檢索測試和驗證

這是大多數團隊跳過的步驟，也是最重要的步驟。在連接代理商之前測試知識庫，可以將檢索品質問題與模型品質問題分離開來。

測試協議

1. 創建測試集： 50-100 個代表您的代理商將收到的查詢的問題。包括簡單問題（答案在單個明顯文件中）、中等問題（答案需要在許多文件中找到正確的文件）和困難問題（答案需要綜合多個文件的信息）。

2. 標記基礎真相： 對於每個問題，識別正確的源文件和正確的答案。這需要領域專家輸入。

3. 運行檢索： 用每個測試問題查詢向量存儲。記錄前 10 個檢索到的塊。

4. 評估：

   • 檢索精確率： 有多少百分比的檢索塊實際上是相關的？
   • 檢索召回率： 有多少百分比的相關塊被檢索到？
   • 答案覆蓋率： 檢索到的塊是否包含足夠的信息來回答問題？

5. 識別失敗： 對於檢索失敗的問題，診斷原因：

   • 塊不存在（文件未被攝入或被過濾掉）
   • 塊存在但未被檢索（嵌入不匹配，查詢措辭與文件語言不匹配）
   • 塊被檢索但過於碎片化（糟糕的分塊分割了相關信息）
   • 錯誤的塊被檢索（重複或誤導性內容排名高於正確塊）

6. 修復並重新測試： 解決根本原因並重新運行測試。迭代直到檢索品質達到您的閾值。

常見錯誤及修復

規模考慮

小型語料庫（1,000-10,000 個文件）

可以用半手動流程管理。單個數據工程師可以在 1-2 週內解析、清洗、分塊和驗證知識庫。品質問題可以通過手動檢查樣本來識別和修復。

基礎設施： 有 CPU 的單台服務器就足夠了。ChromaDB 或 Qdrant。在 CPU 上使用 all-MiniLM 或 E5-large 進行嵌入。

中型語料庫（10,000-100,000 個文件）

需要帶品質控制的自動化管線。手動檢查每個文件是不可行的。需要自動化品質評分、去重和帶抽樣驗證的分塊。

基礎設施： 建議使用帶 GPU 的服務器以提高嵌入速度。Qdrant 用於向量存儲。預計初始嵌入需要 1-2 天。

大型語料庫（超過 100,000 個文件）

需要帶有監控、錯誤處理、增量更新和品質指標儀表板的生產數據管線。新文件應該可以在不重新嵌入整個語料庫的情況下進行處理。

基礎設施： 專用 GPU 服務器或小型集群。Qdrant 或 Milvus。考慮按文件類型或部門對向量存儲進行分片以獲得更好的檢索性能。

稽核要求

知識庫中的每個文件都必須追溯到其來源。這不僅僅是良好做法——對於受監管行業，這是要求，對於調試，這是實際必要性。

稽核鏈：

1. 源文件 → 由文件 ID、文件路徑和哈希值識別
2. 解析文字 → 存儲帶有解析時間戳和解析器版本
3. 清洗文字 → 存儲帶有應用的清洗規則
4. 塊 → 存儲帶有塊 ID、父文件 ID 和塊位置
5. 嵌入 → 存儲帶有嵌入模型版本和時間戳
6. 檢索事件 → 記錄帶有查詢、檢索到的塊 ID、相關性分數和時間戳

當代理商給出錯誤答案時，這個鏈讓您向後追蹤：代理商檢索了哪些塊？那些塊是相關的嗎？它們來自哪個源文件？源文件是否正確且最新？塊是否被正確解析和清洗？

這種可追溯性是將生產知識庫與原型區分開來的東西。它也是使持續改進成為可能的東西——您可以系統地識別和修復導致代理商錯誤的數據品質問題，而不是猜測。

從哪裡開始

1. 盤點您的文件——您有什麼，存在哪裡，有多少，有多新？
2. 選擇一個有限的範圍——從一種文件類型或一個部門開始，而不是整個企業語料庫
3. 構建管線——解析、清洗、分塊、嵌入、索引。自動化每個步驟。
4. 測試檢索——50 個以上查詢，手動評估，識別失敗
5. 修復數據品質——解決檢索失敗的根本原因
6. 連接代理商——只有在檢索品質達到您的閾值後
7. 監控和迭代——隨時間追蹤檢索品質，更新文件，修復新發現的問題

知識庫不是一次性構建。文件會更改，新文件被創建，舊文件過時。生產知識庫有一個使其保持最新和準確的維護管線。從一開始就為持續維護做好計劃，而不是事後補救。