優化資料標記和增強任務的本地 LLM 推理

本地 LLM 推理將資料準備從完全手動的過程轉變為人機協同的工作流程。ML 工程師或領域專家不必從頭為每個文件添加標記，而是審查和更正 AI 生成的預標記。這些預標記的質量——以及生成它們的速度——取決於本地推理堆疊的配置有多好。

本指南涵蓋在資料標記和增強中使用本地 LLM 的實際優化：選擇哪些模型、量化如何影響標記準確性、如何構建提示詞以獲得一致輸出，以及吞吐量瓶頸在哪裡。

---

資料準備任務的模型選擇

並非所有模型都同樣適合資料準備工作。要求與對話 AI 不同：

• 指令遵循：模型必須始終如一地遵循結構化輸出指令。如果您要求特定鍵的 JSON，它應該生成帶有這些鍵的 JSON——每次都是，而不是 95% 的時間。
• 短小、結構化的輸出：大多數標記任務產生 10-200 個 Token 的輸出（標籤、JSON 對象、簡短提取）。針對長篇生成優化的模型在這裡是浪費的。
• 領域詞彙：模型應該能處理技術術語而不進行改述。醫療代碼、法律引用和工程術語需要原文傳遞。

按任務推薦的模型

7B 的最佳點：對於大多數分類和提取任務，7B 指令調優模型以 2-3 倍的吞吐量提供更大模型 90-95% 的準確率。從 7B 開始。只有在測量到您特定任務的準確率差距時才移動到 14B。

---

量化取捨

量化將模型精度從 16 位浮點數降低到更低的位寬，縮小模型大小並提高推理速度。取捨是準確性。

量化水平比較

資料準備的量化建議

分類任務（二元、多分類）：Q4_K_M 即可。分類輸出是短小且受限的。模型要麼選擇正確的類別，要麼不選——Q4 為這個決策保留了足夠的精度。

實體提取：首選 Q5_K_M 或 Q8_0。提取需要模型識別並重現輸入中的特定字符串。較低的量化可能導致微妙的 Token 級錯誤（拼寫錯誤、截斷實體），這些錯誤在審查中代價高昂。

合成資料生成：最低 Q5_K_M。在 Q5 以下，生成的文字質量明顯下降——句子變得不那麼連貫，技術術語被混淆，輸出需要更多人工編輯。

一般建議：從 Q4_K_M 開始初始測試。如果您特定任務的準確率可以接受，就停在那裡以獲得吞吐量。如果您看到質量問題，升級到 Q5_K_M 或 Q8_0。資料準備工作不要低於 Q4_K_M。

---

推理後端：Ollama vs llama.cpp vs vLLM

Ollama

最適合：大多數資料準備設置。簡易的模型管理、OpenAI 相容 API、自動 GPU 檢測。

Ollama 用模型倉庫和 HTTP 伺服器包裝了 llama.cpp。開銷很小——HTTP 請求/回應每次推理調用增加不到 1ms 的延遲，與推理本身需要的 100ms-10s 相比可以忽略不計。

資料準備的配置：

# 設置並發請求限制（默認為 1）
OLLAMA_NUM_PARALLEL=4 ollama serve

# 拉取模型
ollama pull mistral:7b-instruct-v0.3-q4_K_M

# 或拉取特定的量化版本
ollama pull qwen2.5:14b-instruct-q5_K_M

關鍵設置：OLLAMA_NUM_PARALLEL 控制 Ollama 並發處理多少個請求。對於資料準備，如果您的 GPU 有足夠的 VRAM，設置為 2-4。每個並行請求在 VRAM 中加載一個額外的上下文視窗。

llama.cpp（直接使用）

最適合：Ollama 模型倉庫無法訪問的氣隔環境，或者當您需要對推理參數進行精細控制時。

llama.cpp 的 llama-server 提供 OpenAI 相容端點，沒有 Ollama 的模型管理層。您直接指向一個 GGUF 文件。

# 使用特定模型和調優參數啟動伺服器
llama-server \
  --model ./models/mistral-7b-instruct-v0.3.Q4_K_M.gguf \
  --ctx-size 4096 \
  --n-gpu-layers 99 \
  --parallel 4 \
  --batch-size 512

關鍵參數：

• --ctx-size：上下文視窗大小。對於文件標記，4096 個 Token 處理大多數單文件任務。對於長文件，增加到 8192 或 16384。
• --n-gpu-layers：要卸載到 GPU 的模型層數。設置為 99 以卸載所有內容。如果 VRAM 不足，則減少。
• --parallel：並發請求槽。每個槽保留上下文內存。
• --batch-size：提示詞評估期間每批處理的 Token 數。較高的值加快提示詞處理但使用更多內存。

vLLM

最適合：具有多個並發請求的高吞吐量批量處理。vLLM 的 PagedAttention 機制比 llama.cpp 更有效地處理許多並發請求。

取捨：更重的安裝（Python + PyTorch + CUDA）。更複雜的設置。不適合每次處理一個文件的交互式標記工作流程。對於大多數資料準備場景來說，除非您正在對 100,000 個以上的文件運行批量推理，否則是過度配置。

對大多數服務提供商的建議：使用 Ollama。這是通向可工作的本地推理的最簡單路徑。如果您在氣隔環境中，切換到 llama.cpp 直接使用。只有在批量吞吐量是測量瓶頸時才考慮 vLLM。

---

批量推理策略

資料標記和增強天然適合批量處理。您有 N 個文件需要標記——盡可能高效地處理它們。

順序單文件處理

一次處理一個文件。簡單，易於調試，中斷後易於恢復。

吞吐量：對於每個標籤生成約 50 個 Token 的 7B Q4 模型，在 RTX 4070 上預計每分鐘 30-50 個標籤。即每小時 1,800-3,000 個標籤。

並行批量處理

並發發送多個推理請求。Ollama 的 OLLAMA_NUM_PARALLEL 或 llama.cpp 的 --parallel 啟用了這一功能。

吞吐量改進：2-4 個並行請求通常將吞吐量提高 1.5-3 倍（不是線性的，因為 GPU 計算是共享的）。在 RTX 4070 上使用 4 個並行請求，預計每小時 4,500-8,000 個標籤。

VRAM 費用：每個並行槽保留上下文內存。在 4096 個上下文大小下，每個槽消耗約 200-400 MB 的 VRAM（因模型而異）。確保您有餘量。

提示詞批量（每個請求多個文件）

在單個提示詞中包含多個短文件，要求模型對所有文件進行標記。這分攤了每個請求的開銷。

用以下一種類別標記每個文件：[合同, 發票, 通信, 報告]。
以 JSON 數組回應。

文件 1：「尊敬的先生，我們寫信確認...」
文件 2：「發票 #4521 - 應付金額...」
文件 3：「Q3 業績摘要...」

取捨：更高的吞吐量（更少的請求），但更複雜的錯誤處理。如果模型在批次中的某個文件上出現幻覺，您需要識別並重新處理它。最適合容易檢測錯誤的簡單分類任務。

---

上下文視窗管理

文件標記通常需要完整的文件文本作為輸入上下文。這造成了一種矛盾：較長的文件需要更大的上下文視窗，但更大的上下文視窗會降低推理速度。

上下文大小 vs. 速度

實際方法：將上下文大小設置為與您的實際文件長度匹配，而不是模型的最大值。如果 95% 的文件符合 4096 個 Token，將上下文設置為 4096。對於超出的那 5%，要麼截斷（基於前 N 個 Token 標記），要麼使用更大的上下文單獨處理它們。

長文件的分塊

超過上下文視窗的文件需要分塊。對於標記任務：

1. 將文件分成重疊的塊（例如，3000 個 Token，500 個 Token 重疊）
2. 獨立標記每個塊
3. 合併標籤，解決重疊區域的衝突

這對實體提取和分類效果很好，但對需要全局文件理解的任務（如摘要或文件級情感）效果較差。

---

一致標籤的提示詞工程

資料準備需要一致性。對某個文件輸出「Contract」而對相同文件輸出「contract」的分類提示詞會造成下游問題。

結構化輸出提示詞

您是一個文件分類器。將以下文件分類為恰好一個類別。

類別：contract, invoice, correspondence, report, other

規則：
- 只輸出小寫類別名稱
- 無解釋、無標點、無額外文字
- 如果不確定，輸出「other」

文件：
{document_text}

類別：

複雜標籤的 JSON 輸出

從以下文件中提取實體。只輸出有效的 JSON。

架構：
{"parties": [string], "date": string|null, "amount": string|null, "type": string}

規則：
- 缺失欄位使用 null
- 日期使用 ISO 8601 格式（YYYY-MM-DD）
- 金額包含貨幣符號
- 無 Markdown，無解釋

文件：
{document_text}

JSON：

資料準備的關鍵提示詞原則

1. 約束輸出空間：明確列出所有有效標籤。模型應從您的列表中選擇，而不是發明標籤。
2. 精確指定輸出格式：「僅小寫」、「僅 JSON」、「無解釋」。重複這個約束。
3. 提供 2-3 個示例，用於模糊的類別。少量示例是提高標籤一致性的最有效方法。
4. 對分類和提取任務將溫度設為 0。您希望得到確定性輸出，而不是創意變化。

---

按配置的吞吐量估算

常見資料準備任務的實際吞吐量數字：

這些假設是單文件處理。並行推理（2-4 個並發請求）將這些數字提高 1.5-3 倍。

---

準確率 vs. 速度的取捨

預標記不需要完美。它需要足夠好，以至於人工審查和更正比從頭標記更快。

閾值：如果預標記的準確率超過 80%，人工審查員將大部分時間花在確認正確標籤（快）而不是更正錯誤標籤（慢）上。準確率超過 90% 時，工作流程由確認點擊主導。

實際含義：不要以犧牲吞吐量為代價過度優化準確率。以每小時 3,000 文件速度達到 85% 準確率的 7B Q4 模型，比以每小時 800 文件速度達到 92% 準確率的 14B Q8 模型更有用——因為額外 7% 準確率所節省的人工審查時間無法抵消 3.7 倍的吞吐量降低。

在提交模型配置之前，在實際資料的樣本上測量準確率。

---

實際配置

Ertas Data Suite 將本地 LLM 推理作為標記和增強的內置助手進行整合。應用程式與在本機上運行的 Ollama 或 llama.cpp 通訊，使用您指定的模型配置。用於分類、提取和生成的提示詞模板是內置的，具有按項目自定義提示詞的選項。

原生桌面應用程式與本地推理後端的結合意味著標記介面和模型之間沒有網路跳轉。點擊文件，查看預標記，接受或更正——所有操作都在本地硬體上進行，沒有資料離開機器。

對於優化資料準備工作流程的服務提供商，最大的槓桿是模型選擇和量化，而不是複雜的基礎設施。在具有足夠 VRAM 的工作站上以正確的量化獲得正確的模型，吞吐量自然會跟上。