無資料外洩的本地 LLM 輔助資料標記

資料標記是資料準備流水線中最耗費人力的階段。一個具有複雜標記需求的 10,000 個範例資料集，可能需要一個標注員團隊花費數週時間。乘以服務提供商一年處理的客戶專案數量，標記就成為吞吐量的主要瓶頸。

雲端標記 API（OpenAI、Anthropic、Google）可以大幅加速這個過程——模型可以在幾分鐘內預標注數千筆記錄。但對於受監管的企業客戶，將資料傳送到雲端 API 並非選項。資料不能離開大樓。

實際的替代方案：使用在本地端執行的 LLM 來協助標記。不是取代人工標注員，而是將每位標注員的工作量減少 40-60%。本指南涵蓋本地 LLM 輔助標記的設置、模型選擇和工作流程。

本地 LLM 能為標記做什麼

本地 LLM 以三種方式協助標記：

1. 預標注（草稿標籤）

模型為每筆記錄產生建議標籤。然後人工標注員審查並修正建議，而不是從頭開始標記。

對於具有 10 個類別的文字分類任務，提示設計良好的本地 7B 模型通常在草稿標籤上達到 60-80% 的準確率。這意味著 60-80% 的記錄只需要驗證（快速），而不需要從頭標記（慢速）。時間節省是可觀的——標注員吞吐量大約翻倍。

對於更複雜的任務（實體擷取、多標籤分類、指令/完成對產生），準確率差異更大，但即使 40% 的正確預標注也能節省大量時間。

2. 標籤品質檢查

人工標注員應用標籤後，模型會檢查一致性：

這個標籤是否與內容相符？
這個標籤與類似記錄的標記方式是否一致？
是否有標注模式顯示疲勞或系統性錯誤？

這能捕捉否則會進入訓練集的錯誤。以高速運作的人工標注員會犯錯——根據任務複雜度和標注員專業程度，通常有 5-15% 的錯誤率。品質檢查通道能捕捉其中相當大的比例。

3. 主動學習優先排序

並非所有未標記的記錄對模型訓練都同樣有資訊價值。主動學習使用模型不確定性來優先確定下一步應標記哪些記錄——將標注員時間集中在最能提升模型效能的記錄上。

使用本地 LLM，你可以計算每筆未標記記錄的預測信心度，並優先呈現最不確定的記錄。這樣每單位標注員工作量就能產生更好的訓練集。

設置本地 LLM 推理

運行本地 LLM 的兩個實際選項：

Ollama

Ollama 提供最簡單的本地模型推理路徑。安裝二進位檔、拉取模型，然後透過本地 API 端點存取。

標記任務的硬體需求：

7B 模型（Mistral 7B、Llama 3 8B）：最少 8 GB RAM，建議 16 GB。可在 CPU 上執行，但 GPU 加速能大幅提升吞吐量。
13B 模型：最少 16 GB RAM。在複雜標記任務上明顯更好。
70B 以上模型：需要嚴肅的 GPU 基礎設施（48 GB 以上 VRAM）。通常對標記輔助來說過度。

對於大多數標記用例，7B-8B 指令跟隨模型提供最佳的吞吐量與準確率比。

llama.cpp

更多控制，更多配置。llama.cpp 直接在 CPU 或 GPU 上執行 GGUF 量化模型，對上下文長度、批次大小和量化級別有精細控制。

適合需要以下需求的服務提供商：

在沒有 CUDA 相容 GPU 的硬體上執行（Apple Silicon、AMD、純 CPU 伺服器）
在特定硬體上最大化吞吐量
在無法安裝 Ollama 的環境中部署

標記任務的模型選擇

並非所有模型都同樣適合標記。關鍵屬性是指令跟隨——模型需要可靠地產生你指定格式的結構化輸出。

模型	大小	指令跟隨	結構化輸出	標記準確率（典型）
Llama 3.1 8B Instruct	8B	優秀	良好	65-80%
Mistral 7B Instruct v0.3	7B	非常好	良好	60-75%
Qwen 2.5 7B Instruct	7B	非常好	非常好	65-80%
Phi-3.5 Mini Instruct	3.8B	良好	尚可	50-65%
Llama 3.1 70B Instruct	70B	優秀	優秀	80-90%

準確率範圍是具有 5-10 個類別的典型文字分類任務的估計值。你的實際結果會根據領域、任務複雜度和提示設計而有所不同。

批次 vs. 互動式標記

兩種工作流程模式：

批次預標注

在整個未標記資料集上執行模型，為所有記錄產生草稿標籤。然後標注員逐一處理佇列，驗證或修正每個草稿。

優點：最大化 GPU 利用率。標注員始終有預標注記錄的佇列可供審查。實作簡單。

缺點：初始批次處理需要時間（在一般硬體上處理大型資料集需要數小時）。草稿標籤在沒有任何人工修正的情況下產生——模型在批次過程中不會改進。

互動式協作標記

當標注員開啟每筆記錄時，模型即時產生草稿標籤。標注員立即看到建議，並接受、修改或拒絕。

優點：感覺更自然。提示可以包含最近標記的範例（少量樣本），隨著工作階段進行而提高準確率。

缺點：需要低延遲推理（每筆記錄少於一秒）。基於單一記錄推理速度設置吞吐量上限。在 CPU 加上 7B 模型的純 CPU 硬體上，延遲可能為每筆記錄 5-15 秒——對簡單任務可接受，對快速標注員來說令人沮喪。

對於大多數服務提供商工作流程，批次預標注是實際的起點。當硬體支援次秒推理時，切換到互動式協作標記。

比較：本地 LLM 標記 vs. 現有工具

Label Studio

部署最廣泛的開源標注工具。Label Studio 為多種標注類型（分類、NER、邊界框等）提供網頁介面，具有專案管理、多標注員支援和基本的機器學習後端整合。

優點：成熟、靈活、支援多種標注類型。缺點：自託管部署增加運營複雜性。機器學習後端整合（用於預標注）需要自訂程式碼。沒有內建的本地 LLM 支援——你需要自己構建橋接。

Prodigy

Explosion 的商業標注工具。為效率而構建——圍繞主動學習和快速標注工作流程設計。

優點：快速的標注介面、內建主動學習、良好的 NLP 整合。缺點：需要商業授權。桌面應用程式（非網頁），限制了多標注員工作流程。以 Python 為中心——領域專家需要技術協助才能配置。

雲端標記服務（Scale AI、Labelbox）

具有勞動力管理、品質控制和模型循環功能的企業級標記平台。

優點：強大、可擴展、品質管理整合良好。缺點：資料必須離開客戶的基礎設施。對於有零外洩需求的受監管行業，不是選項。

實際工作流程：從未標記到訓練就緒

以下是服務提供商為受監管企業客戶處理標記專案的現實工作流程：

第一階段：設置（第 1 天）

在客戶硬體上部署本地 LLM 推理（Ollama 或 llama.cpp）
與領域專家設計標記架構
針對 50 筆記錄的樣本撰寫並測試標記提示
測量預標注準確率，並迭代提示直到準確率超過 60%

第二階段：批次預標注（第 2 天）

在完整資料集上執行模型
產生帶有信心分數的草稿標籤
標記低信心記錄，優先進行人工審查

第三階段：人工審查（第 3-10 天以上）

領域專家審查預標注記錄
高信心正確標籤：驗證並核准（快速）
低信心或不正確的標籤：手動修正
追蹤重疊記錄上的標注員一致性

第四階段：品質保證（持續進行）

以本地 LLM 作為完成標籤的品質檢查員
標記不一致之處供重新審查
計算標注員間一致性指標
匯出品質報告用於稽核追蹤

第五階段：迭代

初始標記輪次後，使用已標記資料改進提示
使用改進的提示對剩餘未標記記錄重新執行預標注
每次迭代通常將預標注準確率提高 5-10%

硬體建議

對於在客戶現場部署標記基礎設施的服務提供商：

場景	硬體	模型	預期吞吐量
預算 / 純 CPU	32 GB RAM 工作站	Llama 3.1 8B Q4	50-100 筆記錄/小時（批次）
中階	NVIDIA RTX 4090（24 GB）	Llama 3.1 8B Q8	500-1,000 筆記錄/小時（批次）
生產	NVIDIA A100（40 GB）	Llama 3.1 70B Q4	200-400 筆記錄/小時（批次，準確率更高）
Apple Silicon	M3 Max（64 GB 統一記憶體）	Llama 3.1 8B Q8	200-400 筆記錄/小時（批次）

這些吞吐量數字適用於具有 200 個 token 輸入記錄和 50 個 token 輸出的典型文字分類任務。實體擷取和指令產生任務會更慢。

這能實現什麼

Ertas Data Suite 的 Label 模組將本地 LLM 輔助標記直接整合到資料準備流水線中。內建協作 AI 透過 Ollama 或 llama.cpp 執行，支援批次預標注和互動式標記，並將每個標籤決策記錄到專案稽核追蹤中。領域專家在視覺介面中工作——無需 Python、無需命令列、無需配置檔案。

相較於組合 Label Studio + Ollama + 自訂膠水程式碼的優勢：一切都在單一應用程式中執行，具有統一的資料模型。在 Label 模組中應用的標籤直接饋入擴增和匯出，無需檔案格式轉換或資料傳輸。

連接到流水線

已標記資料饋入擴增，其中合成資料產生擴展資料集——在真實已標記資料稀缺時尤為重要（典型的企業情況）。

有關完整流水線概覽，請參閱如何為 LLM 微調建立本地端資料準備流水線。