你的 ML 工程師不應該做這些事

以下是我們經常遇到的情況：一家醫療機構的 ML 工程師每週花兩到三天標注臨床筆記。不是因為他們喜歡，也不是因為他們特別有資格這樣做，而是因為真正有資格的醫生，根本搞不懂如何操作標注工具。

這不是一個難搞醫生或急性子工程師的故事。這是一個關於工具設計只為 ML 工程師、從未認真考慮其他使用者的故事。結果是對昂貴專業人力的系統性錯誤分配，以及標注品質的系統性下降。

核心問題

標注品質取決於領域專業知識。這一點沒有爭議。一位審閱臨床筆記以確保診斷標籤一致性的醫生，比沒有醫學背景的 ML 工程師做同樣任務，會產出更好的標注。一位審閱工程量清單條目的建築工程師，比從未讀過工料測量師報告的資料科學家，更能可靠地分類成本類別。一位審閱合約條款標注的律師，能發現 Python 開發者會錯過的歧義和例外情況。

擁有高品質標注所需領域專業知識的人，通常不是知道如何操作標注工具的人。這造成了一個結構性問題：工具流向了錯誤的人，因為只有他們才能操作這些工具。

後果是雙重的。首先，標注品質低於領域專家親自操作時的水準。其次，ML 工程師的時間被標注任務佔用，而這些任務本應由領域專家以較低成本且更佳效果完成。

領域專家實際面臨的困境

讓我們具體說明，當你要求領域專家使用標準標注工具時，情況是什麼樣子。

臨床筆記情境

一個醫療 AI 團隊需要標注 10,000 份臨床筆記，用於醫療編碼模型。這些筆記需要由臨床人員審閱和標注——最好是最終會使用 AI 系統的臨床工作人員。這是理想的設置：系統的未來使用者生成訓練資料。

團隊設置 Label Studio。這需要：一台伺服器（或本地 Docker 安裝）來執行 Web 應用程式、在任何將託管服務的機器上安裝和配置 Docker 執行環境、以 Label Studio 的 XML 模板格式撰寫的標注介面配置、為每個臨床標注者建立和管理使用者帳戶，以及讓臨床工作人員從工作站存取工具的網路配置。

臨床人員到場開始標注。他們遇到一個假設熟悉標注概念的 Web 應用程式介面——標籤集、關係、預測、審閱佇列。第一次會議需要 ML 工程師支援來解釋工具如何運作。由於醫院網路限制，幾位臨床人員無法從工作站存取工具。一位臨床人員需要特定格式的標注說明；將其轉換為 Label Studio 配置又花費了另一個工程小時。

第一週的產出低落。ML 工程師在支援標注流程上花費的時間比做工程工作還多。三週後，標注達到 2,000 個樣本。品質審閱揭示了不一致性，因為不同的臨床人員對標注指導方針有不同的解讀——但工具不容易看出不一致性是系統性的還是個人的。

這個情境，以各種形式，是典型的。它不是努力或意圖的失敗，而是工具設計的失敗。

工程量清單標注情境

一個建築 AI 團隊需要標注工程量清單，用於條目分類模型。標注者應該是工料測量師或建築估算師——那些在專業上與工程量清單打交道、能可靠地區分直接費用、初步費用和暫定金額的人。

團隊建立了一個 Python 腳本，從試算表讀取工程量清單行，並通過命令行提示呈現以供分類。建築工程師打開終端機，輸入命令，看到提示要求他們按 1、2 或 3 來分類每個條目。

對這個情境而言，這比 Label Studio 好，因為不需要部署伺服器。但它更差，因為它需要命令行熟悉度，而且如果腳本在會議中途崩潰，沒有可靠的方式從停止的地方恢復。工程師打電話給 ML 工程師求助。ML 工程師修復腳本並重新安排標注會議。

產出：低落。標注工作與領域專家之間的回饋迴路：取決於工程師的可用性。

合約審閱情境

一個法律 AI 團隊需要標注合約條款，用於條款類型分類。標注者應該是律師——特別是處理資料集中合約類型的律師。

團隊設置了 Jupyter notebook。律師在 VS Code 或基於瀏覽器的 Jupyter 會話中打開 notebook，逐個單元格處理條款，修改一個字典變數，記錄每個條款的分類。輸出儲存為 JSON 檔案。

律師不是 Jupyter notebook 使用者。介面令人困惑。第一次會議在一位律師意外修改了代碼單元格並破壞 notebook 時結束。ML 工程師在技術支援通話上花費了一個小時。

替代方案：團隊將條款匯出到試算表，並要求律師在 Excel 中標注。從可用性角度來看這更好，但從資料管理角度來看更差——試算表的版本控制不可靠，格式易損壞，合併多位律師的標注引入了出錯機會。

當 ML 工程師反而來標注時會發生什麼

當領域專家標注太難操作時，預設就是讓 ML 工程師來標注。這並非不理性——ML 工程師是可用的，他們能操作工具，而且專案需要推進。

但沒有領域專業知識的 ML 工程師，在領域特定任務上系統性地產生較低品質的標注。這不是對他們能力的批評——這是一個結構性事實。放射科報告需要臨床知識才能正確標注。工程量清單需要建築成本知識。合約需要法律知識。

後果是複合的。

初始標籤準確率較低意味著模型在噪聲更多的訊號上訓練。在監督學習中，標籤雜訊直接降低模型性能——模型無法從不一致的標籤中學習一致的模式。由非專家以 85% 標籤準確率標注的資料集，產生一個學習了 85% 底層訊號的模型。由領域專家以 95% 準確率標注的相同資料集，產生一個可測量地更好的模型。

更多迭代輪次，因為較低的初始品質意味著更多標注審閱週期。團隊注意到模型性能低於預期，進行調查，發現標注錯誤，重新標注。這個週期昂貴且緩慢。每一輪都需要重新接觸標注者、重新運行訓練、重新評估。

對邊緣案例的回饋較弱，因為沒有領域專業知識的 ML 工程師，無法可靠地識別哪些標注決策是需要判斷的邊緣案例，哪些是明確的。他們應用的指導方針必然更機械，不如領域專家所帶來的那樣細緻入微。

時間線更慢，因為所有這些加在一起，意味著從標注開始到可用模型的總時間更長。在讓領域專家標注變得容易上投入資源的團隊，通常比將 ML 工程師標注作為替代方案的團隊更快達到品質目標。

領域專家可及工具的真正意義

解決方案不是對領域專家進行如何使用開發者工具的更好培訓。而是不需要開發者培訓即可操作的工具。

標準應該是：一位從未使用過標注工具的領域專家，能在 15 分鐘內安裝軟體、打開它並開始標注，不需要終端機、不需要 Docker、不需要 Python 環境、不需要閱讀配置指南。

這個標準是可以實現的。使用現代跨平台框架構建的桌面應用程式，可以打包所有依賴項，像標準軟體一樣安裝，並呈現為特定工作流程設計的介面——而非為 ML 工程師靈活性設計、然後再為其他人調整的介面。

實踐中的樣子：

安裝： 下載安裝程式，雙擊，執行。無需終端機命令。無需 Docker。無需環境設置。無需端口配置。

標注介面： 為特定任務設計，不可配置為任何任務。臨床筆記審閱者看到臨床筆記和標籤按鈕。工程量清單標注者看到行和分類選項。介面不暴露「標籤集」或「預測置信度」等概念，除非這些是領域專家實際需要互動的內容。

恢復和儲存： 工作自動儲存。關閉並重新打開工具，從上次位置恢復。不需要執行命令，不需要管理檔案，不需要依賴正在運行的伺服器。

回饋： 標注者清楚地看到還剩什麼需要標注、他們已完成什麼，以及任何被標記待審閱的條目。進度可見，無需解讀日誌文件或資料庫查詢。

無需 ML 工程師介入： 領域專家可以完成完整的標注會議，從打開軟體到提交完成的工作，無需打電話給 ML 工程師。如果出現問題，錯誤訊息是人類可讀且可操作的。

這是一種與「構建強大工具並詳細記錄」不同的設計哲學。它需要將介面限制到實際使用者所需的範圍，這意味著接受工具不會具有最大靈活性。對於標注工作流程來說，這是正確的權衡。

標籤品質的改善

領域專家標注的實際好處是真實且可測量的。

在臨床文本標注中，比較由臨床醫生標注的資料集與眾包或非專家標注資料集的研究，一致發現當領域專家進行標注時，下游模型性能改善了 8 到 15 個百分點。對於複雜的、依賴判斷的任務（診斷分類、治療建議），效果更大；對於較簡單的提取任務，效果較小。

在法律文件標注中，專家與非專家標注的效果在類別邊界上最為明顯。非專家標注者機械地應用類別；專家標注者以對底層法律區別的知識來應用它們。在專家標注上訓練的模型，在生產中的邊緣案例上泛化得更好。

在技術領域標注（工程圖紙、金融工具、專業科學文件）中，專家與非專家標注之間的差距可能更大，因為概念本身在沒有領域知識的情況下是無法理解的。一個標注工程量清單的非專家，對許多條目的正確類別本質上是在猜測。

讓領域專家標注變得可及的論據，主要不是關於節省工程時間，儘管它確實如此。而是關於獲得更好的 AI 系統。更好的標注產生更好的模型。更好的模型產生更好的結果。使領域專家標注成為可能的工具，不是一種便利——它是一個品質槓桿。

我們交談的工程和建築 AI 負責人直接說：

「問題不在於微調，而在於清理和準備多樣化的資料。」

「多樣化的資料」包括領域專業知識的多樣性。將正確的專業知識引入標注迴路，需要將正確的人引入工具。這需要為正確的人設計的工具，而非為 ML 工程師設計、然後交給其他人的工具。

Your data is the bottleneck — not your models.

Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.

Book a Discovery Call Learn about Ertas Data Suite →