企業 AI 代理的資料準備：為什麼您的代理只有您的資料那麼好

打開任何代理式 AI 教程，重點都在框架上。LangChain 的工具調用 API。CrewAI 的多代理編排。AutoGen 的對話模式。隱含的假設是資料是個已解決的問題——只需將代理指向您的文件，它就會自己弄清楚。

它不會自己弄清楚。

在與跨醫療保健、法律、金融服務和製造業部署 AI 代理的企業團隊合作後，一個清晰的模式出現了：資料品質是預測代理部署成敗的最強單一指標。 不是模型。不是框架。不是硬體。是資料。

這不是感覺良好的觀察。它有具體機制支撐：代理根據其檢索到的資訊和訓練期間學到的模式做出決策。如果檢索返回不相關的片段，代理就會根據錯誤的資訊做出決策。如果訓練資料包含不一致的工具調用模式，代理就會錯誤地調用工具。失敗是確定性的——錯誤的資料輸入，錯誤的決策輸出。

代理需要的三種資料類型

企業代理使用三種不同類別的資料，每種都有不同的準備要求：

1. 知識庫（用於 RAG 的文件）

這是代理在查詢時檢索以告知其回應的資訊。企業知識庫通常包括：

內部政策和程序
產品文件和規格
客戶記錄和歷史
監管指南
培訓手冊和 SOP
電子郵件存檔和會議記錄

「已準備好」的含義： 文件必須從其來源格式解析，去除樣板內容，去重複，在語義邊界分塊，用元資料標記，並使用本地嵌入模型嵌入。每個分塊必須可以追溯到其來源文件。

2. 工具架構（函數定義）

代理通過工具與企業系統交互——描述可用操作、接受哪些參數和返回什麼的函數定義。工具架構是代理和您的基礎設施之間的介面層。

「已準備好」的含義： 每個工具必須有清晰的名稱、關於它做什麼以及何時使用的精確描述、記錄了類型和約束的良好文件參數，以及防止格式錯誤調用的驗證規則。

3. 訓練資料（用於微調）

如果您正在微調基礎模型以改善代理行為（企業部署應該這樣做），您需要正確代理行為的標記示例。這包括與正確的推理步驟序列、工具調用和回應配對的用戶查詢。

「已準備好」的含義： 包含完整代理軌跡的指令/回應對——用戶的輸入、代理的推理、它應該進行的工具調用（帶有精確參數），以及最終回應。對於範圍明確的企業工作流，通常需要 500 到 2,000 個示例。

知識庫品質問題

這是大多數代理項目失敗的地方，因此值得詳細關注。

常見方法：取 10,000 個企業文件（PDF、Word 文件、電子郵件、試算表），通過攝取管道運行它們，將分塊轉儲到向量存儲中，並連接代理。團隊很興奮——代理可以訪問他們所有的企業知識。

然後他們進行測試。代理有 30% 到 40% 的時間給出錯誤答案。不是模型的幻覺——而是因為檢索系統返回了不相關或誤導性的分塊而給出錯誤答案。團隊責怪模型。他們嘗試更大的模型。它仍然有 25% 到 35% 的時間是錯誤的，因為問題從來都不是模型。

以下是問題所在：

問題 1：解析失敗

企業文件很雜亂。從掃描生成的 PDF 有 OCR 錯誤。Word 文件在文字提取過程中有複雜的格式被破壞。試算表有合併的單元格，在拼成文字時失去了意義。電子郵件鏈有轉發偽影和損壞的編碼。

如果您的文件中有 15% 有嚴重的解析錯誤，您的知識庫中就有 15% 包含損壞的資訊。代理檢索損壞的分塊，並根據亂碼文字生成回應。

修復方法： 使用具有特定格式邏輯的文件解析器處理多種格式。根據來源文件驗證解析輸出。標記品質檢查失敗的文件以供人工審查。

問題 2：重複內容

企業在多個地方擁有相同的資訊。假期政策存在於員工手冊、HR 入口網站 FAQ、三個不同的入職文件和幾十個電子郵件公告中。如果所有這些都在向量存儲中，關於假期政策的查詢可能會檢索到五個分塊，它們都說略有不同的話，因為它們是在不同時間寫的。

代理現在在其上下文視窗中有衝突的資訊。它可能對衝突的陳述取平均值，任意選擇一個，或幻覺出一個合成結果。這些都不是好的結果。

修復方法： 在文件級別（精確和近似重複檢測）和分塊級別（語義相似度閾值）進行去重複。保留最權威或最新的版本。

問題 3：糟糕的分塊

按字符數分塊——每 512 或 1,024 個字符分割一次——是大多數攝取管道的默認設置。這也是破壞文件意義的默認方式。

跨越兩個分塊的表格變成兩個無意義的片段。帶有介紹的有序列表在一個分塊，條目在下一個分塊，失去了其結構。條件語句（「如果患者有 X 病症，則應用 Y 治療」）在分塊之間分割，創建了說「應用 Y 治療」而沒有條件的分塊。

修復方法： 在主題邊界分割的語義分塊——章節標題、段落分隔、邏輯過渡。將表格、列表和條件邏輯保留為原子單位。在分塊之間包含重疊以保持上下文連續性。

問題 4：缺少元資料

沒有元資料，代理就無法過濾其檢索。如果用戶詢問「當前的差旅政策」，代理無法區分 2026 年版本和 2023 年版本。如果查詢是關於特定部門的程序，代理會從所有部門檢索程序。

修復方法： 用以下內容標記每個分塊：來源文件、文件日期、作者/所有者、部門/類別、版本，以及任何與您的用例相關的其他分類。

問題 5：沒有 PII/PHI 處理

如果您的企業文件包含個人可識別資訊或受保護的健康資訊，這些資料現在就在您的向量存儲中。每個檢索這些分塊的查詢都通過代理向用戶暴露該資料。即使在文件級別存在訪問控制，一旦內容被分塊和嵌入，它們就被繞過了。

修復方法： 在攝取管道中將 PII/PHI 檢測和去識別化作為其中一個步驟。在分塊和嵌入之前去識別化或遮蔽敏感資料。對於醫療保健部署，使用在臨床文字上訓練的 NER 模型進行去識別化。

準備工具架構

工具架構看起來很簡單——只需定義函數簽名。但定義不當的工具是代理失敗的第二常見來源。

出錯的地方

模糊的描述： 如果兩個工具有重疊的描述，代理就無法可靠地在它們之間進行選擇。「搜尋客戶記錄」和「查找客戶資訊」——代理應該調用哪個？

缺少參數約束： 如果工具接受 date 參數，但架構未指定格式，代理可能會傳遞「March 6, 2026」或「2026-03-06」或「03/06/2026」。如果後端期望 ISO 8601，其中兩個會靜默失敗。

沒有錯誤處理文件： 當工具調用失敗時，代理需要知道原因。如果架構未記錄錯誤條件，代理會重試相同的失敗調用、放棄或幻覺出一個結果。

如何準備工具架構

對於每個工具：

撰寫唯一、具體的描述——「按客戶 ID 檢索客戶合約詳情，包括合約開始日期、結束日期、計劃類型和月費」比「獲取客戶資訊」更好
記錄每個參數——類型、格式、必需/可選、有效值、示例
定義返回架構——工具成功和失敗時返回的內容
添加使用指南——何時使用此工具而非類似工具，常見的參數組合
用 50 個以上的代表性輸入進行測試——驗證工具行為正確，代理正確調用它

架構品質	代理工具調用準確率
最小（名稱 + 基本參數）	45% 至 55%
有文件（描述 + 類型）	70% 至 80%
完整（描述 + 約束 + 示例）	85% 至 92%
完整 + 在架構示例上微調	92% 至 97%

最小和完整工具架構之間的差距，就是一個有一半時間有效的代理和一個可靠運作的代理之間的差距。

準備微調訓練資料

通用模型是平庸的代理。它們可以進行工具調用，但對企業特定工具的調用不一致且常常不正確。微調通過教導模型您的特定模式來修復這一問題。

訓練資料的樣子

每個訓練示例是一個完整的代理軌跡：

{
  "messages": [
    {
      "role": "system",
      "content": "You are a customer service agent with access to: [tool definitions]"
    },
    {
      "role": "user",
      "content": "What's the renewal date for Acme Corp's contract?"
    },
    {
      "role": "assistant",
      "content": null,
      "tool_calls": [{
        "function": {
          "name": "query_customer_database",
          "arguments": "{\"customer_id\": \"ACME-001\", \"fields\": [\"contract_end_date\"]}"
        }
      }]
    },
    {
      "role": "tool",
      "content": "{\"contract_end_date\": \"2026-09-15\"}"
    },
    {
      "role": "assistant",
      "content": "Acme Corp's contract renews on September 15, 2026."
    }
  ]
}

如何建立訓練集

收集真實的企業查詢——用戶實際上問什麼？從支援工單、內部聊天記錄、電子郵件查詢中提取。這些是您的輸入。
讓領域專家標記正確的回應——對於每個查詢，正確的工具調用序列和正確的最終答案是什麼？這需要了解工作流程的人，而非 ML 工程師。
包含多步驟示例——代理通常需要 3 到 7 次工具調用來處理單個請求。訓練資料必須包含這些多步驟軌跡，而非只是單步驟示例。
包含錯誤處理——當工具調用失敗時代理應該做什麼？當找不到資料時？當用戶的請求模糊時？包含這些邊緣情況下正確行為的示例。
平衡資料集——如果您的示例中有 80% 是簡單查詢，20% 是複雜工作流程，代理在查詢方面會很出色，但在工作流程方面會很糟糕。平衡分佈以反映您希望代理處理的難度分佈。

目標量： 單一定義明確的工作流程需要 500 個示例。處理多種工作流程類型的更廣泛代理需要 1,000 到 2,000 個示例。品質比數量更重要——500 個乾淨、良好標記的示例優於 5,000 個嘈雜的示例。

審計追蹤：將決策追溯到資料

企業代理做出影響運營、財務和（在受監管行業中）人類福祉的決策。當決策出錯時，您需要回答：為什麼出錯了？

審計追蹤將代理的輸出連接回產生它的資料：

哪個用戶查詢觸發了代理？ → 在輸入時記錄
代理檢索了哪些文件？ → 由 RAG 系統記錄（文件 ID、分塊 ID、相關性分數）
哪些訓練示例影響了代理的行為？ → 在訓練資料清單中記錄
代理進行了哪些工具調用？ → 記錄了參數和返回值
最終輸出是什麼？ → 在交付時記錄

這種可追溯性不是錦上添花。在醫療保健中，錯誤的建議必須可以追溯到被錯誤檢索的臨床指南。在金融服務中，交易決策必須可以從代理使用的資料重建。在法律中，錯誤的判例引用必須可以歸因於它來自的文件。

可追溯到資料的常見代理失敗

失敗模式	症狀	根本原因
幻覺事實	代理陳述不在任何來源文件中的內容	RAG 檢索不佳——返回不相關的分塊，模型用捏造填補空白
錯誤的工具調用	代理調用錯誤的函數或傳遞錯誤的參數	訓練資料不佳——工具調用示例不足或不一致
自信地給出錯誤答案	代理給出詳細、權威但不正確的答案	知識庫中的過時資料——攝取時是正確的，現在是錯誤的
回應緩慢	代理每次交互需要 5 到 10 秒	分塊不良——大分塊導致嵌入查找緩慢和上下文視窗臃腫
行為不一致	同樣的問題每次得到不同的答案	知識庫中的重複資料——不同的分塊給出衝突的資訊
過度檢索	代理回應冗長且不集中	缺少元資料——無法過濾檢索到相關文件

這些失敗中的每一個都是資料問題，而非模型問題。切換到更大的模型可能會減少某些失敗的頻率，但無法修復根本原因。修復資料，大多數這些失敗就會消失。

從哪裡開始

如果您正在構建企業 AI 代理，從資料層開始：

審計您的文件語料庫——您有哪些文件，它們是什麼格式，有多新，存在哪些品質問題？
建立攝取管道——解析、清理、去重複、分塊、標記、嵌入。自動化——隨著文件變化，您需要重新運行它。
定義和記錄工具架構——代理將使用的每個工具，都有完整的參數約束和使用指南文件。
收集和標記訓練資料——來自您領域的真實查詢，由領域專家標記了正確的代理軌跡。
在測試代理之前測試檢索品質——用代表性問題查詢您的向量存儲，並手動檢查檢索到的分塊。如果檢索不好，無論模型如何，代理都會很糟糕。

框架選擇——LangChain、CrewAI、AutoGen 或自訂循環——是您將做出的最不重要的決定。資料準備是最重要的。把資料做好，7B 模型就能很好地作為您的企業代理執行。做錯了，GPT-4 也會自信地給您錯誤的答案。