Skip to content
Guides1 min read

用盲態條目衡量 LLM 建議對標註者的錨定作用

看到 LLM 標籤的標註者,給出的標籤與沒看到的人不同。在一份隨機樣本上隱藏建議,再比較盲態一致性與顯示建議時的一致性。

Potato Team

看到 LLM 建議標籤的標註者往往會給出那個標籤,所以建議顯示在螢幕上時,人與模型之間的一致性要高於建議不顯示時。在一份隨機條目樣本上隱藏建議,衡量這些盲態條目上的一致性,並用盲態一致性而不是總體一致性來決定在多大程度上信任模型。

*錨定效應*是指先看到的數字或答案會把之後的判斷往它那邊拉。在標註中,錨點就是預標註,也就是由標註者接受或修正的模型建議。錨定不同於走過場式的蓋章,後者是指標註者不讀建議就接受它。一個認真閱讀每條建議的標註者仍然可能被錨定,因為在模稜兩可的條目上,建議的答案已經擺在頁面上了。計時訊號能發現走過場式的蓋章,正如一致性抓不出走過場式的蓋章所述。然而,被錨定的標註者在條目上花的時間可能很正常,所以計時無法把錨定與獨立判斷區分開。

建議會改變標籤的證據

一項預註冊實驗(Schroeder et al., 2025)從 350 名眾包工作者那裡收集了 7000 條主觀任務標註,涵蓋 4 種條件、2 個模型和 2 個數據集。顯示 LLM 建議並沒有讓標註者更快,但提高了他們自我報告的信心。標註者採納建議的頻率高到足以讓標籤分佈與沒看到建議的標註者相比發生顯著變化。當用這些在 LLM 協助下得到的標籤去評估該 LLM 時,它報告出的效能顯著上升。

因此,模型與看過其建議的稽核者之間的一致性,部分是模型與它自己的一致。任何依賴這個數字的決定,例如一旦一致性超過 90% 就把剩餘語料交給模型,都是在一個被抬高的數字上做出的。

盲態條目與錨定差距

在標註開始之前,隨機選出一定比例的條目,讓標註者在沒有建議的情況下標註它們。在其餘條目上,建議照常顯示。比較這兩部分會得到三個數字:

  • 盲態一致性,即模型與沒看到其建議時給出的標籤之間的一致性,它估計模型正確的頻率;
  • 顯示一致性,即模型與其建議顯示在螢幕上時給出的標籤之間的一致性;以及
  • 錨定差距,即顯示一致性減去盲態一致性,它估計建議把人拉動了多少。

盲態條目必須隨機選出,並在整個研究中保持固定。挑選最難的條目,或讓標註者自己決定何時檢視建議,都會讓盲態樣本失去代表性,這時盲態一致性對語料的其餘部分就什麼也估計不了。另外,只有當標註者從未看到某個條目的建議時,這個標籤才算盲態,所以出現分歧後重新給出的標籤應歸入顯示建議的那一組。

盲態比例是在速度和證據之間的權衡。每個盲態條目都得不到建議所節省的時間,而盲態條目太少又會讓盲態一致性噪聲很大。Potato 的預設設定是 20% 的比例,下限為 20 個盲態條目。按這個比例,一項只有 20 個條目的研究只會產生大約 4 個盲態條目,所以請把下限設成語料實際能提供的數量。

Solo Mode 中的盲態建議

Solo Mode 是 Potato 為一位專家與一個 LLM 協作而設的模式。LLM 為語料打標籤,專家在旁一起標註,一旦專家與 LLM 的一致性超過 end_human_annotation_agreement,Solo Mode 就把剩餘條目交給 LLM。在 Potato 2.11 之前,這一一致性是在建議可見時給出的標籤上測得的。從 2.11 起,solo_mode.suggestions 控制建議何時出現:

yaml
solo_mode:
  suggestions:
    display: blind_sample      # before_label | after_label | blind_sample
    blind_rate: 0.2
    minimum_blind_sample: 20

blind_sample 在固定的 20% 條目上隱藏建議,這些條目在研究開始時一次選定,所以重新載入或重啟後,仍是同一批條目保持盲態。after_label 從不先顯示建議;當專家與 LLM 意見不一致時,分歧處理頁面會顯示 LLM 的標籤及其理由。一旦有了 20 次盲態比較,交接時就會拿盲態一致性而不是總體一致性去與閾值比較。

面板上的 Blind Agreement 卡片把盲態一致性和顯示一致性並排列出,同時給出兩者的差距,以及專家用 Accept 按鈕採納建議的頻率。差距要等兩邊都至少有 5 次比較後才會報告。較大的正差距意味著專家在能看到 LLM 答案時更常與它一致。這種情況下,請讓更多條目保持盲態,或者改用 after_label。

標註引擎中的盲態校準

同樣在 2.11 中新增的 Potato 標註引擎,把同一條規則應用到它用作證據的每一個標籤上。校準、認證和抽查請求都是隨機抽取的,並記錄了入選機率;當某人持有這樣一個請求時,伺服器會扣下該條目的所有機器答案。預標註、內聯評審和 AI 助手全部關閉,而且這個人儲存之後,條目對他仍保持盲態。引擎只用這些盲態標籤來認證機器標籤。

核驗請求則是反過來的情況。它們會顯示機器的答案,請人保留或修改它,並記錄預填的答案,好讓你衡量人們接受它的頻率。引擎從不用核驗答案來認證,因為它們從設計上就是被錨定的。設定 humans.verify_visibility: blind 後,核驗請求也會在不顯示答案的情況下提供,代價是失去建議所節省的時間。

盲態樣本的侷限

盲態樣本衡量的是模型與沒有輔助的人相比如何,只有當沒有輔助的人在這項任務上可靠時,這才是正確的參照。在認真的標註者彼此也會有分歧的主觀任務上,盲態一致性有一個低於 100% 的上限,而模型可能正好處在這個上限。在把較低的盲態一致性解讀為模型較弱之前,請先按照 LLM 評審一致性所述,把模型與人的一致性同人與人之間的一致性作比較。

盲態樣本也不會改變那些在顯示建議時給出的標籤。這些標籤仍然是被錨定的,一個主要由它們構成的資料集會繼承模型的偏好。請隨資料集一起報告盲態一致性和錨定差距,並在標註第一個條目之前就設定 display: blind_sample,因為在建議可見時標註的條目,事後無法再變成盲態。

延伸閱讀

參考文獻

  1. Schroeder, H., Roy, D., and Kabbara, J. (2025). Just put a human in the loop? Investigating LLM-assisted annotation for subjective tasks. Findings of ACL 2025. https://doi.org/10.18653/v1/2025.findings-acl.1323