Back to blog
    為何領域專家——而非 ML 工程師——應該主導資料標注
    domain-expertsdata-labelingenterprise-aiannotationaccessibilitysegment:enterprise

    為何領域專家——而非 ML 工程師——應該主導資料標注

    企業 AI 最大的品質瓶頸不在於工具,而在於真正擁有領域知識的人被排除在標注流程之外。以下是改變這一現狀的理由。

    EErtas Team·

    大多數組織在構建 AI 系統的方式上存在根本性的錯位。了解資料的人——臨床醫生、律師、工程師、核保師、分析師——並非標注資料的人。相反,ML 工程師介入資料與模型之間,在他們並非完全理解的領域中做出判斷。

    這不是工具問題,而是結構問題。這是企業 AI 專案產生平庸結果的最主要原因。

    每個標注管道中的知識差距

    考慮一個具體例子。一個法律 AI 團隊正在構建一個合約分析模型。模型需要從客戶角度將條款分類為「有利」、「中立」或「不利」。

    ML 工程師可以設置標注環境、撰寫標注架構、配置匯出管道。但當他們遇到一個帶有重大過失排除條款的責任限制條款時,他們無法可靠地判斷該條款是否對客戶有利。這種判斷需要多年的合約談判經驗。

    實踐中發生的情況是:ML 工程師基於表面啟發法進行標注。也許他們把任何含有「限制」的內容標為不利。也許他們在 Slack 上詢問一位律師,得到一個沒有背景的單字回答,然後繼續。標籤進入資料集,訓練模型,模型學習了一個膚淺的模式。

    將這種情況乘以 5,000 個樣本,你就得到一個對最重要的案例——那些領域專業知識決定有用分類還是危險分類的邊緣案例——充滿自信地出錯的模型。

    為何這種情況持續發生

    答案很直接:標注工具需要領域專家所不具備的技術技能。

    大多數企業標注工作流程如下:

    1. 資料存放在雲端儲存桶或資料庫中
    2. ML 工程師撰寫 Python 腳本來提取和格式化資料
    3. 資料被載入標注平台(Label Studio、Prodigy、Labelbox)
    4. 平台需要自行託管(Docker、網路、身分驗證)或雲端上傳
    5. 標注者需要帳戶、工具介面培訓,以及通常用於自訂標籤類型的 API 存取
    6. 完成的標籤通過 Python 腳本匯出用於模型訓練

    至少,步驟 1、2、3 和 6 需要熟悉 Python、命令行工具和資料工程概念的人。在大多數組織中,這意味著 ML 團隊中的 2 到 5 個人。

    領域專家——那些知識實際上決定標籤品質的人——被基礎設施所排除。

    數字說明了一切

    Google 的 Data Cascades 論文研究發現,92% 的 AI 從業者在其專案中報告了資料品質問題,大多數追溯到標注和標記問題。2024 年 MIT 的一項研究發現,主要基準資料集中大約有 3% 到 5% 的標籤錯誤——而這些是由專門研究團隊構建的資料集。

    在企業環境中,標注是通過代理完成的(ML 工程師標注領域特定資料),錯誤率明顯更高。我們見過在領域特定分類任務上有 8% 到 15% 標籤錯誤率的組織。不是因為任何人粗心,而是因為標注者缺乏領域知識,無法持續做出正確判斷。

    成本是複合的。在有 10% 標籤錯誤的資料上訓練的模型,不只是損失 10% 的準確率。錯誤創造了矛盾的訓練訊號,全面降低性能。實踐中,10% 的標籤錯誤率可能在最難的樣本上將模型準確率降低 20% 到 30%——而這些通常是最重要的樣本。

    「領域專家標注」的真正含義

    讓領域專家擁有標注主導權,不意味著教他們 Python。不意味著讓他們速成 Docker 或 Jupyter notebook。而是消除他們與標注任務之間的每一個技術障礙。

    放射科醫師應該能打開應用程式,看到醫療影像,並使用他們已熟悉的術語應用標籤。律師應該能審閱合約條款,並使用他們在實踐中使用的相同類別進行標記。工料測量師應該能查看工程量清單條目並對其分類,而無需了解 JSON 架構是什麼。

    這需要的要求是具體的:

    無安裝複雜性。 工具像任何桌面應用程式一樣安裝——下載、雙擊、執行。無需 Docker、終端機命令或環境變數。

    無需上傳資料。 領域特定資料通常是敏感的。醫療記錄、法律文件、財務資料。工具必須處理本地檔案,在使用者的機器上,不向外部伺服器發送資料。

    無需編寫代碼。 架構定義、標籤應用、品質審閱和匯出都應通過視覺介面進行。如果有人需要寫一行代碼來標注資料,你就已經失去了 90% 的領域專家。

    適合領域的介面。 文件的文本標注。視覺資料的圖像標注。表格資料的結構化欄位標注。介面應符合專家對資料的思考方式,而非 ML 管道消費資料的方式。

    代理標注稅

    當領域專家無法直接標注時,組織要支付我們所說的「代理標注稅」。這以三種方式體現:

    時間稅。 每個標注決策都需要在 ML 工程師和領域專家之間來回。工程師遇到一個模糊樣本,向專家發消息,等待回應,解讀回應,應用標籤。一個應該花 5 秒的任務花了 15 分鐘。

    準確率稅。 溝通壓縮了細微差別。專家「取決於司法管轄區和具體排除條款語言」的回應,被壓縮成一個二元標籤。上下文丟失了,邊緣案例被扁平化。

    產出稅。 ML 團隊成為瓶頸。如果你有 3 名 ML 工程師和 50 名領域專家,你以 6% 的潛在標注容量在運作。本應花幾週的專案花了幾個月。

    消除代理標注稅的組織——通過給領域專家直接存取標注工具的機會——通常在第一個月內看到標注產出提升 3 到 5 倍,以及標籤準確率的可測量改善。

    當專家直接標注時的變化

    從代理標注轉向專家直接標注,改變的不只是產出數字,而是以難以量化但易於觀察的方式改變資料集品質。

    首先,邊緣案例被正確標注。難倒代理標注者的樣本——那些需要深厚領域知識的樣本——正是領域專家自信處理的樣本。

    其次,標籤架構得到改善。當領域專家直接與標籤架構互動時,他們立即發現太寬、太窄或完全缺失的類別。標注合約條款的律師,會在一小時內告訴你「不利」需要子類別。ML 工程師可能永遠不會發現這一點。

    第三,標注者間一致性提高。領域專家對術語和分類標準有共同理解。兩位律師在條款分類上的一致性,遠高於嘗試相同任務的兩位 ML 工程師。

    第四,迭代週期縮短。當模型產生錯誤輸出時,領域專家可以查看訓練資料並識別導致錯誤的標注決策。他們不需要向 ML 團隊提交工單,等待調查,並希望工程師理解領域背景。

    使其實際可行

    轉向領域專家主導標注,需要在專家所在之處與他們會面的工具。這意味著處理本地資料的原生桌面應用程式、不需要任何代碼的視覺介面,以及與現有 ML 管道整合的匯出格式。

    Ertas Data Suite 是專為這個用例而構建的。它作為原生桌面應用程式運行——無需 Docker、雲端或 Python 環境。領域專家像安裝任何其他應用程式一樣安裝它,將其指向本地資料,通過視覺介面定義標注架構,然後開始標注。資料永不離開他們的機器。標注後的資料集以標準格式匯出,可直接用於模型訓練。

    結果是,了解資料的人是標注資料的人。從一開始就應該如此。

    Turn unstructured data into AI-ready datasets — without it leaving the building.

    On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.

    Keep reading