第 12 課 從觀點擷取到私有化交付：模型前後要接上什麼

一條回饋，先拆觀點，再匹配標籤

在這個車廠案例中，一則回饋可能同時包含零件問題、服務評價和語音轉寫錯誤。處理流程先拆分觀點，擷取車型、情境、情感、意圖及回饋文字位置，再從維護中的標籤庫選候選標籤、複核歧義並統一品牌車型編碼。

以虛構回饋「車載系統又當機了，但售後回電話很快」為例，應該保留兩條觀點及各自回饋文字位置。先看是否拆對，再看標籤是否匹配。可以用向量檢索與重新排序輔助選擇，把可變的標籤表與模型理解分開；是否採用這條流程，要看標籤規模、歧義和實際檢查結果。

先做能回歸的基準，再決定要不要微調

先用少量經授權、去識別化並人工確認的樣本，做一個可反覆檢查的基準，再比較範例提示或微調等改進方案。廣告、重複文字、個人資訊、轉寫錯字、長文切分和輸出格式異常都要有處理紀錄。不能靠修補格式把猜出來的欄位當真。

把調試樣本與最終評測樣本分開，保留一批較晚時間的資料檢查變化。每次更新都對照同一評測集，分別看觀點擷取、標籤選擇、回饋文字定位和人工複核量。只有定位到具體錯誤與資源限制，再評估微調是否值得；不要把微調當作必經步驟。

對內對齊，結果才接得進產品

模型服務與業務平台即使由不同技術架構實作，也要約定單筆與批次輸入、輸出欄位、逾時和失敗處理。練習時寫清：一筆紀錄如何追蹤到回饋文字，缺欄位怎麼辦，重複請求如何識別，哪些結果進入人工複核，標籤版本如何記錄。模型分數好看，不能代替介面與業務定義一致。

私有化交付的七項核對

訊息佇列、排程任務、資料倉儲等按客戶既有系統選擇，先說清處理語義，再選工具。

顯示記憶體與版本相容，要分開查

資源預算不能只計算模型權重，還要考慮執行開銷和 KV 快取；文字長度與並行請求會影響容量和吞吐量。多卡切分或量化也需要在目標設備上驗證。使用 vLLM 時，應核對預編譯套件與 CUDA、PyTorch 建置的相容性。版本和參數要按目標環境確定。

今天先做一步

用 10 條虛構回饋手動拆觀點，留回饋文字位置和標籤版本，再模擬一次標籤改名、一次服務逾時。無需啟動模型或購買顯示卡。

本章產物與驗收

• 一張「輸入 → 觀點 → 候選標籤 → 複核 → 寫回」流程表。
• 固定評測樣本與兩次版本比較；資料問題、定義問題和模型問題分開記錄。
• 一張環境核對表：已知、未知、待驗證明確區分；未驗證的延遲和容量不填估計成績。