Back to blog
    如何為小型模型微調準備企業訓練資料
    data-preparationtraining-datafine-tuningenterprise-aion-premisesegment:enterprise

    如何為小型模型微調準備企業訓練資料

    將非結構化企業文件——PDF、Word 檔、掃描表單——轉換為小型語言模型微調用乾淨 JSONL 訓練資料的五階段實用指南。

    EErtas Team·

    模型不是難點。訓練基礎設施不是難點。企業微調的難點是讓訓練資料準備好。

    企業資料存在於 PDF、Word 文件、Excel 試算表、掃描表單、電子郵件附件和傳統資料庫匯出中。微調語言模型需要結構化的 JSONL 文件,包含提示/完成對——乾淨、一致、格式正確的文本,帶有清晰的指令-響應映射。

    這兩種狀態之間的差距就是資料準備挑戰。大多數企業 AI 專案在這裡花費 60 到 80% 的時間。這是最常見和最昂貴的錯誤發生的地方。這也是決定模型在生產中是否有效或在部署時失敗的地方。

    本指南涵蓋為小型模型微調準備企業訓練資料的五個階段:攝入、清理、標注、擴充和匯出。每個階段對應一組具體的操作,帶有特定工具、品質指標和失敗模式。

    第一階段:攝入——將文件解析為結構化文本

    第一階段將源文件轉換為機器可讀的文本,並保留結構。這聽起來很簡單,但實際上並不。

    數位 PDF

    由軟體創建的 PDF(從 Word 匯出、由 ERP 系統生成、由 CAD 工具生成)包含嵌入文本。但文本以定位字形存儲,而非段落和表格。對於人類讀者看起來像乾淨三列表格的 PDF,在內部存儲為特定 X-Y 座標的數百個單獨文本片段,沒有連接它們的表格對象。

    表格重建需要按空間接近度分組文本片段、從對齊模式識別列邊界,以及從共享垂直座標(在容差帶內)的片段組裝行。錯誤的容差會合併應該分離的行,或將單行分割到兩個。

    多列佈局帶來類似挑戰。兩列文件的文本片段,按樸素的從左到右順序讀取,會交織兩列的內容——產生無意義的文本。

    掃描文件

    掃描文件在任何文本處理之前需要 OCR。現代 OCR 引擎(Tesseract 5、PaddleOCR、EasyOCR)在乾淨的印刷文本掃描上達到 95 到 99% 的字元準確率。但企業存檔包含:

    • 褪色的複印件,來自舊型影印機,降低字元對比度
    • 傾斜的掃描,頁面以一定角度送入
    • 覆蓋印刷文本的印章和簽名
    • 混合在印刷內容中的手寫批注
    • 多代複印——傳真的複印件的複印件

    每一種都會降低 OCR 準確率。字元層面 98% 準確的掃描,大約每 50 個字元產生一個錯誤——這意味著 500 字的文件大約有 50 個字元層面的錯誤。其中一些錯誤損壞了數字(將「1,234」改為「1,2B4」),對於財務或數量資料來說是災難性的。

    試算表和結構化文件

    Excel 文件、CSV 匯出和資料庫轉儲已經是結構化的——但不一致。常見問題:

    • Excel 中破壞列對齊的合併儲存格
    • 包含輔助資料或公式的隱藏行和列
    • 同一工作簿中不同架構的多個工作表
    • 匯出 CSV 文件與消費系統之間的編碼不匹配
    • 日期格式歧義——「03/06/26」是 3 月 6 日還是 6 月 3 日?

    攝入輸出格式

    攝入階段的輸出應該是標準化的中間格式——每個文件一個 JSON 文件,包含:

    {
      "document_id": "DOC-2026-00142",
      "source_file": "contract_amendment_3.pdf",
      "source_type": "digital_pdf",
      "pages": [
        {
          "page_number": 1,
          "text_blocks": [...],
          "tables": [...],
          "metadata": {"ocr_confidence": null, "layout_type": "single_column"}
        }
      ],
      "ingest_timestamp": "2026-03-06T14:30:00Z",
      "ingest_version": "1.2.0"
    }

    這種中間格式將解析與下游處理解耦。當你改進 OCR 或表格提取時,你重新運行攝入,而不觸及管道的其餘部分。

    第二階段:清理——去除噪音、標準化、去識別化

    原始解析輸出包含如果不刪除就會降低模型訓練的噪音。清理階段有三個目標:去除偽影、標準化格式和刪除敏感資訊。

    偽影刪除

    • 頁眉和頁腳。 重複的頁眉(「機密——X 公司」)和頁腳(「第 3 頁,共 47 頁」)出現在每個頁面的文本輸出中。如果保留,模型會訓練數百個「第 N 頁,共 M 頁」的實例——學習再現樣板文字而非提取有用內容。
    • OCR 偽影。 識別錯誤的字元,尤其是在表格中:豎線被讀為「l」或「I」、括號被讀為「C」或「)」、度數符號被讀為「o」。
    • 重複文件。 大型存檔包含多個副本——原件、修正件、已簽名、已反簽名。如果不去重,模型會過度重視這些文件。使用基於內容的雜湊(而非基於文件名)來檢測近重複。精確雜湊會錯過只在頁眉或頁碼不同的文件;模糊雜湊(MinHash、SimHash)可以捕獲這些。

    格式標準化

    源文件之間的格式不一致在訓練資料中產生噪音:

    元素發現的變體標準化形式
    日期「03/06/2026」、「6 Mar 2026」、「March 6, 2026」、「2026-03-06」ISO 8601:「2026-03-06」
    數字「1,234.50」、「1.234,50」、「1234.5」區域中性:「1234.50」
    貨幣「$1,234」、「USD 1,234」、「1,234 USD」符號前綴:「$1234.00」
    單位「m3」、「M3」、「CUM」、「cum」、「cubic meters」縮寫:「m³」
    百分比「15%」、「15 %」、「15 percent」、「0.15」符號:「15%」

    標準化必須是確定性的且可逆的。記錄每次轉換,以便你可以將清理後的值追溯到其原始形式。這種可追溯性不是可選的——根據 EU AI Act,這是監管要求。

    PII 和 PHI 去識別化

    這是企業團隊最常跳過、低估或做錯的步驟。出錯的後果從合規罰款到刑事責任不等。

    必須刪除的內容:

    • PII(所有行業): 姓名、地址、電話號碼、電子郵件地址、國家 ID 號碼、銀行帳戶號碼、出生日期
    • PHI(醫療保健): 以上所有,加上病歷號碼、健康計劃受益人號碼、設備識別符、生物特徵識別符,以及 18 個 HIPAA 識別符中的任何其他
    • 金融識別符: 帳戶號碼、SWIFT 代碼、稅務識別號碼

    刪除方法:

    1. 用類型化佔位符替換。 將「John Smith」替換為「[PERSON_NAME_1]」,而非通用的「[REDACTED]」。類型化佔位符保留了文本的語義結構。模型學習到該位置出現人名,即使它不學習具體名字。

    2. 在文件內一致替換。 如果「John Smith」在合約中出現 15 次,所有 15 個實例必須替換為相同的佔位符。不一致替換——同一實體在一個地方用「[PERSON_NAME_1]」,在另一個地方用「[PERSON_NAME_2]」——教模型錯誤的實體關係。

    3. 日期偏移。 對於醫療保健資料,日期必須在每個患者記錄中以一致的隨機偏移量進行偏移。患者 3 月 1 日的入院日期和 3 月 5 日的出院日期可能變為 1 月 15 日和 1 月 19 日——4 天的持續時間保留了,但實際日期無法恢復。

    驗證: 去識別化後,運行二次掃描以捕獲遺漏的 PII。命名實體識別模型、結構化識別符(SSN、電話號碼、電子郵件)的正則表達式模式,以及已知姓名的基於字典的匹配,都作為驗證層。PII 掃描通過率高於 99.5% 是受監管行業的最低閾值。

    第三階段:標注——領域專家創建訓練示例

    標注是將清理後的文件轉換為訓練資料的階段。領域專家審查文件並產生模型將學習複製的正確提取示例。

    訓練示例的樣子

    每個訓練示例是一個指令-響應對:

    指令(提示): 模型在推理時將接收的輸入——通常是已解析的文件或文件部分,前面有任務指令。

    響應(完成): 模型應產生的結構化輸出——通常是包含提取欄位的 JSON。

    {
      "instruction": "Extract all contract parties, effective date, and termination clause from the following contract text:\n\n[cleaned document text]",
      "response": "{\"parties\": [{\"name\": \"Acme Construction LLC\", \"role\": \"contractor\"}, {\"name\": \"City of Portland\", \"role\": \"owner\"}], \"effective_date\": \"2026-01-15\", \"termination\": {\"type\": \"for_convenience\", \"notice_period_days\": 30, \"clause_reference\": \"Section 14.2\"}}"
    }

    為何是領域專家,而非 ML 工程師

    這是團隊一致做出錯誤決定的地方。ML 工程師是可用的。領域專家是昂貴且忙碌的。讓 ML 團隊做標注的誘惑很大。

    結果:準確率下降 15 到 20%。

    標注建設工程量單(BOQ)的 ML 工程師不知道「PC Sum」是暫定費用——預算分配,而非定價項目。他們不知道「Measured Work」和「Daywork」是根本不同的定價機制。他們按字面意思標注他們所看到的,錯過了使提取有用的領域語義。

    標注相同 BOQ 的工程量師具有資料如何在下游使用的隱性知識。他們知道哪些欄位是關鍵的(數量、單位、費率),哪些是資訊性的(規格參考)。他們通過不在任何地方記錄的編號慣例知道項目是主項目還是子項目——這是行業實踐。

    同樣的模式跨行業成立。律師助理比 ML 工程師更好地標注合約。臨床編碼員比資料科學家更好地標注醫療筆記。財務分析師比軟體開發人員更好地標注財務報表。

    為領域專家時間編列預算。 這是微調專案中單一最高影響的投資。

    品質優於數量

    訓練資料量與模型準確率之間的關係不是線性的,而是遵循收益遞減的曲線:

    標注示例典型準確率邊際收益
    5070–75%基線
    10078–82%+8–10%
    25085–88%+5–7%
    50090–93%+4–6%
    1,00093–95%+2–3%
    2,00094–96%+1–2%
    5,00095–96%不到 1%

    500 到 1,000 個示例以上的收益遞減意味著在企業規模上,品質遠比數量重要。領域專家標注的 500 個高品質示例,一致優於眾包工作者或初級員工標注的 10,000 個有噪音的示例。

    標注資料的品質控制

    每個標注專案都需要品質控制。三種機制協同工作:

    1. 標注員間一致性。 讓兩名領域專家獨立標注相同的 50 個文件。測量一致性率。對於欄位提取任務,90% 以上的一致性表明標注指南清晰。低於 85% 意味著指南不明確,需要在繼續之前修訂。

    2. 抽查審閱。 高級領域專家每週審閱標注示例的隨機 10% 樣本。在這個階段發現的錯誤修復成本低。訓練後發現的錯誤——當模型複製它們時——修復成本高。

    3. 自動一致性檢查。 捕獲機械錯誤的腳本檢查:缺少必填欄位、超出預期範圍的值(數量為 -500、1900 年的日期)、響應 JSON 中的格式違規。這些捕獲領域專家在疲勞時犯的打字錯誤和格式錯誤。

    第四階段:擴充——用合成變體擴展訓練集

    500 個標注示例可能無法覆蓋模型在生產中會遇到的完整文件分佈。合成資料擴充擴展了訓練集,同時維持領域準確性。

    擴充技術

    模板變體。 取一個標注示例並通過以下方式生成變體:

    • 改述指令(相同提取任務的 10 到 15 個變體)
    • 重新排序表格資料中的欄位
    • 添加或刪除在某些文件中但不是所有文件中出現的可選欄位

    LLM 輔助生成。 使用本地 LLM 根據標注示例中的模式生成合成文件。提供 5 個真實示例,並要求模型生成 20 個具有相似結構但不同內容的新文件。然後讓領域專家驗證生成示例的樣本(20 到 30%)。

    擾動。 引入現實的噪音:OCR 風格的字元錯誤、缺少欄位、截斷文本。這教模型處理不完美的輸入,它將在生產中遇到這些輸入。

    擴充比例

    保守的擴充策略:

    • 500 個真實標注示例 → 基礎訓練集
    • 1,000 個模板變體 → 擴展指令多樣性
    • 500 個合成文件 → 擴展內容多樣性
    • 總計:約 2,000 個訓練示例,來自 500 個專家標注的原件

    不要擴充超過原始標注集的 4 到 5 倍。過度擴充用來自合成示例的噪音稀釋了來自真實示例的信號。模型開始學習擴充過程的模式,而非真實文件的模式。

    分佈平衡

    檢查擴充的資料集是否維持類別平衡。如果 80% 的標注 BOQ 項目是混凝土和鋼鐵,只有 5% 是電氣和機械,模型在提取民事工程項目方面會很出色,在提取 MEP 項目方面則很差。

    通過對代表性不足的類別過採樣和對代表性過多的類別欠採樣來平衡擴充集。目標是沒有類別的頻率超過最小類別的 3 倍。

    第五階段:匯出——轉換為訓練就緒的 JSONL

    最後階段將擴充的資料集轉換為微調框架所需的格式。

    JSONL 格式

    大多數微調框架(Hugging Face TRL、Axolotl、LLaMA-Factory)接受 JSONL——每行一個 JSON 對象,每個包含指令和響應:

    {"instruction": "Extract line items from...", "response": "{\"items\": [...]}"}
    {"instruction": "Identify parties in...", "response": "{\"parties\": [...]}"}

    一些框架使用消息格式用於對話風格的微調:

    {"messages": [{"role": "system", "content": "You are a document extraction assistant."}, {"role": "user", "content": "Extract..."}, {"role": "assistant", "content": "{...}"}]}

    訓練/驗證分割

    以 90/10 或 85/15 比例將資料分割為訓練集和驗證集。分割必須是分層的——每種文件類型和提取任務應在兩個集合中按比例代表。不要隨機分割;確保來自單個源文件的所有示例在同一個分割中,以防止資料洩漏。

    用於可追溯性的元資料

    在匯出中包含用於稽核和調試目的的元資料欄位:

    {
      "instruction": "...",
      "response": "...",
      "metadata": {
        "source_document": "DOC-2026-00142",
        "labeled_by": "expert_qs_03",
        "labeled_date": "2026-02-15",
        "augmentation_type": "none",
        "quality_review": "passed",
        "pii_scan": "clean"
      }
    }

    這個元資料在訓練期間不使用——它在資料到達模型之前被去除。但它對以下方面至關重要:

    • 調試模型錯誤。 當模型在特定文件類型上出錯時,將其追溯到該類型的訓練示例。
    • 監管合規。 EU AI Act 第 10 條要求訓練資料的文件:使用了哪些資料、如何準備的、應用了哪些品質措施。元資料日誌提供了這個文件。
    • 重新訓練決策。 當添加新的文件類型時,元資料告訴你哪些現有示例是相關的,哪些新示例是需要的。

    常見錯誤及如何避免

    錯誤一:跳過去識別化

    「我們以後再做」是企業 AI 中最昂貴的一句話。訓練資料中的 PHI 是合規違規,從它進入訓練管道的那一刻起——而非當模型被部署時。HIPAA、GDPR 和行業特定法規都適用於資料處理,而非只有資料存儲或模型推理。

    修復方法: 去識別化在第二階段運行,在任何標注開始之前。沒有例外。

    錯誤二:使用非專家標注員

    僱用眾包工作者或使用初級員工標注特定領域資料,短期節省金錢,長期代價顯著更高。模型學習標注員的錯誤。訓練後修復標注錯誤意味著重新標注和重新訓練——使總成本翻倍。

    修復方法: 從一開始就為領域專家時間編列預算。如果預算限制了示例數量,以更高品質標注更少的示例。300 個專家標注示例優於 3,000 個眾包標注示例用於企業文件提取。

    錯誤三:標注資料沒有品質控制

    沒有品質控制,標注錯誤會累積。如果 10% 的示例包含標注錯誤,並且這些錯誤不一致(不同標注員犯不同錯誤),模型會收到相互矛盾的訓練信號。準確率停滯在遠低於模型架構可以實現的水平。

    修復方法: 實施標注員間一致性檢查、抽查審閱和自動一致性驗證。在訓練之前測量品質。如果標籤一致性低於 90%,在繼續之前修復標注指南並重新標注有分歧的示例。

    錯誤四:以量凌駕品質進行訓練

    更多資料並不總是更好。10,000 個格式不一致、混合品質和不平衡類別分佈的訓練示例,比 500 個格式乾淨、品質一致和分佈平衡的示例產生更差的模型。

    修復方法: 設定品質閾值。每個訓練示例必須通過自動檢查(格式有效、欄位存在、值在範圍內)並且樣本必須通過專家審閱(語義正確、領域合適)。刪除失敗的示例。更小的乾淨資料集優於更大的有噪音資料集。

    錯誤五:沒有稽核軌跡

    沒有稽核軌跡,你無法解釋模型的訓練資料是什麼、如何準備的或應用了哪些品質措施。這是 EU AI Act 第 10 條下的合規失敗,以及當你需要調試模型行為或在更新的資料上重新訓練時的實際失敗。

    修復方法: 記錄每個帶時間戳、版本和參數的管道步驟。用溯源標記每個訓練示例。將日誌與訓練資料一起存儲。當稽核員——內部的或監管的——問「這個模型是在什麼資料上訓練的,以及如何準備的」時,答案應該是對元資料的查詢,而非從記憶中重建。

    資料品質指標:要測量什麼

    在開始微調之前,根據以下指標驗證訓練資料:

    指標目標測量內容
    標籤一致性率高於 90%標注員之間的一致性
    類別平衡比例最大:最小不超過 3:1文件/提取類型的分佈
    示例多樣性分數高於 0.7(餘弦)訓練示例的多樣性
    PII 掃描通過率高於 99.5%去識別化的完整性
    格式驗證通過率100%JSONL 輸出的結構正確性
    重複率低於 2%資料集中的近重複示例
    指令長度方差CV 低於 0.4輸入格式的一致性
    響應完整性高於 98%帶有所有必填欄位的示例百分比

    如果任何指標低於其目標,在訓練之前修復資料。在低標準資料上訓練浪費計算資源,並產生一個無論如何都需要重新訓練的模型。

    準備時間表

    對於針對 500 個標注示例的典型企業微調專案:

    階段持續時間工作量瓶頸
    攝入1–2 週工程文件格式多樣性
    清理1–2 週工程 + 法律PII 識別和刪除規則
    標注3–5 週領域專家專家可用性
    擴充1 週工程合成資料的品質審閱
    匯出2–3 天工程格式驗證
    總計7–11 週

    標注階段主導時間表。為其做計劃。提前預訂領域專家時間。在專家開始之前準備標注指南和工具。每一小時的專家時間浪費在不清晰的指令或損壞的工具上,都是無法收回的時間。

    資料準備不是光彩的工作。它不是 AI 專案中在供應商演示或會議演講中出現的部分。但它是決定模型是否有效的部分。把資料做對,7B 模型在你的特定任務上會優於 70B 模型。把資料做錯,無論模型大小或訓練計算如何都無法補償。

    Turn unstructured data into AI-ready datasets — without it leaving the building.

    On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.

    Keep reading