準備 RAG 資料集與微調資料集：不同管道，相同源資料

大多數企業 AI 團隊最終會構建兩個獨立的資料管道：一個用於為 RAG（檢索增強生成）準備文件，另一個用於為微調準備訓練資料。兩個管道都從相同的原始文件開始——相同的 PDF、相同的內部 wiki、相同的政策手冊。它們共享相同的攝入和清理階段。然後它們分歧。

將這些作為兩個獨立管道運行意味著重複 60–70% 的工作。您攝入相同的 PDF 兩次。您清理相同的文字兩次。您提取相同的實體兩次。您調試相同的解析錯誤兩次。當文件更新時，您必須記得在兩個管道中重新處理它——這不可避免地會遺漏。

更好的方法是共享公共階段並分支到兩個導出路徑的統一管道。一個來源，兩個輸出。本文確切涵蓋管道在哪裡共享工作、在哪裡分歧，以及如何從單一資料準備項目運行兩者。

兩種輸出格式

在深入管道之前，了解每個輸出需要看起來像什麼。

RAG 輸出：向量資料庫的分塊文字 + 元數據

RAG 系統在查詢時檢索相關文字塊並將其作為上下文饋送給模型。輸出是：

{
  "chunk_id": "doc-4421-section-3-chunk-2",
  "text": "A 類客戶的最大信貸風險敞口不得超過一級資本的 15%...",
  "metadata": {
    "source_document": "信貸風險政策 v4.2",
    "section": "3. 風險敞口限制",
    "page": 12,
    "date": "2025-11-01",
    "entities": ["A 類", "一級資本"],
    "doc_type": "policy"
  },
  "embedding": [0.0234, -0.1891, 0.0442, ...]
}

每個塊都足夠獨立可以回答問題，帶有用於過濾和歸屬的元數據，並包含用於語義搜索的向量嵌入。

微調輸出：指令/響應 JSONL 對

微調資料集直接教導模型領域知識。輸出是從源文件派生的問答對：

{
  "messages": [
    {
      "role": "system",
      "content": "您是信貸風險分析師助手。"
    },
    {
      "role": "user",
      "content": "A 類客戶的最大信貸風險敞口限制是多少？"
    },
    {
      "role": "assistant",
      "content": "根據信貸風險政策 v4.2 第 3 節，A 類客戶的最大信貸風險敞口不得超過一級資本的 15%。"
    }
  ]
}

每對從源文件中捕捉特定的知識片段，格式化為對話交流。

為什麼您通常需要兩者

決策通常不是「RAG 或微調」。對於有嚴格精確度要求的企業部署，答案是兩者都要。

RAG 處理長尾：頻繁更新的文件、適用於罕見查詢的特定知識，以及任何需要確切來源歸屬的信息。RAG 檢索來源，因此用戶可以驗證。

微調處理常見核心：構成 80% 所有用戶查詢的 200–500 個問題。這些是領域基礎——定義、標準程序、常見計算。微調模型無需檢索延遲即時回答這些問題，且具有更高的一致性。

我們合作的一個金融服務團隊發現，微調涵蓋了 78% 的分析師查詢（標準法規定義、風險計算方法、報告程序）。RAG 處理了剩餘的 22%（特定客戶資料、最近的法規更新、特定產品細節）。組合系統在答案精確度上優於任何單一方法 23%。

從單一管道構建兩種輸出不僅更高效——它產生更好的結果，因為相同的清理和結構化工作適用於兩者。

共享階段：攝入、清理、實體提取

無論輸出格式如何，管道的前三個階段都是相同的。

攝入

將原始文件解析為標準化中間格式。PDF、Word、HTML、電子郵件、wiki 導出——所有格式都轉換為帶有結構標記（標題、章節、表格、列表）和源元數據的乾淨文字。

這個階段是格式相關的，而不是輸出相關的。PDF 就是 PDF，無論您是為 RAG 分塊還是為微調提取問答對。運行一次。

清理

刪除 OCR 偽影，去重文件，標準化 Unicode，去除樣板（頁眉、頁腳、浮水印）。驗證清理過程沒有刪除有意義的內容。

清理錯誤傳播到兩種輸出。清理文字中的拼寫錯誤術語成為向量資料庫中的錯誤拼寫塊和微調資料集中的錯誤拼寫答案。在清理階段修復一次，而不是在導出階段修復兩次。

實體和結構提取

識別文件結構（章節、小節、表格），提取命名實體（產品、法規、人物、日期），並標記元數據。這個結構信息饋送到兩個管道：

• RAG 使用它進行元數據過濾檢索（「只顯示風險政策第 3 節的文件」）
• 微調使用它進行問題生成（「風險政策第 3 節關於風險敞口限制說了什麼？」）

運行一次實體提取。兩個管道消費相同的結構注釋。

分歧點

清理和結構提取之後，管道分支。相同的清理、結構化文字饋送到兩個並行過程中。

分支 A：RAG 管道

分塊：將結構化文字分割成針對檢索最佳化的塊。分塊策略取決於文件類型：

• 政策文件：在章節級別分塊，在章節邊界重疊
• 技術手冊：在程序/步驟級別分塊
• 通信：在消息級別（用於電子郵件線程）或段落級別分塊
• 表格：將表格保留為帶有周圍上下文的單個塊

目標塊大小：大多數嵌入模型為 256–512 個 token。在每個塊中包含上下文前綴（文件標題 + 章節標題），使塊在獨立時有意義。

元數據標記：將可過濾的元數據附加到每個塊：源文件、章節、日期、實體、文件類型、置信度分數。

嵌入：通過嵌入模型運行每個塊以生成向量表示。對於本地部署，使用本地嵌入模型——BGE-large、E5-large 或通過 Ollama 的 Nomic 嵌入模型。批量處理：單個 GPU 每小時嵌入 10,000–50,000 個塊，具體取決於塊長度和模型大小。

索引：將塊和嵌入加載到向量資料庫（Qdrant、Milvus 或 Chroma，均可用於本地部署）。創建用於過濾搜索的元數據索引。

分支 B：微調管道

問題生成：對於每個結構單元（章節、段落、表格），生成內容回答的問題。使用本地 LLM 進行此操作：

• 通過 Ollama 將內容饋送給 Llama 3.3 70B 或 Qwen 2.5 72B
• 提示：「生成這段文字回答的 3–5 個問題。問題應該具體且僅從文字中可以回答。」
• 過濾生成的問題：刪除重複項，刪除太模糊或太具體的問題

每頁源內容產生 5–15 個問題。一份 100 頁的政策文件在品質過濾之前產生 500–1,500 個問答對。

答案提取：對於每個生成的問題，從源文字中提取答案。答案應該是直接響應，而不是源段落的複製貼上。使用本地 LLM 從源內容生成簡潔、準確的答案。

格式轉換：將問答對轉換為您的微調框架期望的 JSONL 格式。添加適合用例的系統提示（例如「您是合規助手」或「您是風險分析師」）。

驗證：檢查每個答案都受源文字支持——沒有幻覺信息，沒有來自其他文件的事實，沒有憑空捏造的數字。這是關鍵的品質關卡。拒絕任何答案無法追溯到源中特定段落的對。

品質要求不同

RAG 和微調對噪音的容忍度不同，這影響您需要多積極地過濾。

RAG 能容忍一些噪音，因為檢索步驟充當輔助過濾器。如果一個塊包含輕微的 OCR 錯誤，檢索系統可能仍然為正確的查詢返回它，模型在生成答案時可以解決錯誤。塊語料庫中 2–5% 的噪音率對大多數 RAG 部署是可接受的。

微調需要高度的每個示例精確度，因為每個訓練示例直接塑造模型的行為。包含不正確信息的單個訓練示例教導模型自信地產生該不正確的信息。微調資料集的目標噪音率低於 0.5%——這意味著積極的驗證和對生成的問答對的人工審查。

品質容忍度的這種差異意味著微調分支需要比 RAG 分支更重的驗證。相應地安排專家審查時間：計劃讓領域專家抽查 5–10% 的 RAG 塊，但審查 15–25% 的微調對。

運行統一管道

實際工作流程如下：

1. 將所有文件攝入到共享中間格式。一次處理。
2. 清理整個語料庫。一次處理。
3. 提取結構和實體。一次處理。
4. 分支到 RAG：分塊、標記元數據、嵌入、索引。這作為批量作業運行，通常在夜間。
5. 分支到微調：生成問題、提取答案、格式化 JSONL、驗證。如果您有足夠的計算，這與步驟 4 並行運行，否則按順序進行。
6. 專家審查：領域專家審查 RAG 塊樣本（抽查）和更大的微調對樣本（徹底審查）。
7. 導出：RAG 塊去向量資料庫。微調對去訓練管道。

步驟 1–3 是共享工作。步驟 4–5 是並行但獨立的。步驟 6 是品質關卡。

時間和成本節省

運行兩個獨立管道與統一管道——以下是典型的 10,000 個文件知識庫的數字：

統一管道節省約 33% 的計算時間和 25% 的專家時間。更重要的是，它消除了一致性問題——兩種輸出保證都源自相同的清理源資料。

文件更新

當源文件發生變化時，統一管道再次帶來好處。

使用獨立管道，文件更新意味著：在管道 A 中重新攝入，在管道 A 中重新清理，在管道 A 中重新分塊和重新嵌入，然後記住在管道 B 中也重新攝入，在管道 B 中重新清理，在管道 B 中重新生成問答對。錯過第二個管道，您的 RAG 系統有更新的信息，但您的微調模型仍然有舊版本。

使用統一管道，文件更新觸發一次通過共享階段的重新處理，然後自動分支到兩種輸出。兩者保持同步，因為它們共享單一的真實來源。

對於按季度更新政策文件、按月再訓練模型、按週刷新 RAG 索引的組織，這種同步不是方便——而是一致代理行為的要求。

Ertas Data Suite 如何處理雙輸出

Ertas Data Suite 原生實現了這個統一管道。您創建一個項目，導入一次文件，運行一次清理和結構化，然後配置兩個導出目標：用於 RAG 的向量資料庫格式和用於微調的 JSONL。

系統追蹤哪些文件已通過哪些分支處理，在文件更改時處理增量更新，並維護顯示從源文件到 RAG 塊和微調對的血緣的審計追蹤。

對於目前運行獨立管道的團隊——或者更糟的是，使用一個工具準備 RAG 資料，使用另一個工具準備微調資料——整合到單一管道消除了在生產中調試代價昂貴的一類一致性錯誤。

延伸閱讀

• 微調 vs RAG：何時使用哪個 — 在 RAG、微調或兩者之間選擇的戰略決策框架。
• 企業微調訓練資料準備 — 企業團隊微調資料準備工作流程的深度解析。
• 多格式導出：JSONL、COCO、YOLO 管道 — 如何從單一資料準備管道支援多種導出格式。