ラベリングエンジン

ラベリングエンジンは、モデルでデータセットにラベルを付け、そのモデルがどのくらいの頻度で誤るかを人によって測定します。完成したラベルが満たすべき条件は、たとえば「受理した機械ラベルのうち誤りは最大5%、信頼度90%で」のように、コントラクトとして宣言します。エンジンはその主張を検定するのに必要なラベルを人に依頼し、検定が裏付ける機械ラベルを受理し、残りの項目を人に回します。出力はデータセットと、何をいくつの人手ラベルで検定したかを記録した証明書です。

エンジンはPotato 2.11から使えます。アノテーションサーバー、potato labelコマンドライン、REST API、MCPサーバー、Python SDKはいずれも、タスクディレクトリにある同じengine.sqliteファイルを通してエンジンを操作します。

エンジンが研究に合う場合

エンジンが役に立つのは、人がすべてにラベルを付けることはできず、モデルがその大部分にラベルを付けられる場合です。いずれにせよ人がすべての項目にラベルを付けるのであれば、エンジンは何も付け加えないので、通常の割り当て戦略のほうが適しています。合うのは次の3つの状況です。

• 人がラベルを付けきれないほど多くの項目があり、ほとんどの場合に正しいモデルがある。
• 論文、データセットの公開、あるいは他の人が使う学習セットのために、モデルがラベルを作ったことだけでなく、ラベルの品質を報告する必要がある。
• LLM判定者を使ってモデルやエージェントを評価しており、その判定者が人の代わりを務められるかを知る必要がある。

モデルの予測から最終ラベルまで

エンジンは機械の予測、人への依頼、コントラクトの結果を1つのストアに保持し、すべての項目は同じ6つのステップを通ります。

1. ソースはモデルです。ソースには、LLM、視覚言語モデル、意思決定モデル（Laya、Jev、OpenJev）、物体検出器、LLM判定者、その研究自身のラベルで学習したモデル、他のソースからなるジュリー、手元にある既存のラベルを使えます。各ソースは予測ごとに信頼度を記録します。
2. カスケードはソースの順序を決めます。項目はまず最初のソースに送られ、コントラクトがその答えを受理しなければ、次のソースが試します。最後のソースの後、項目は人に回ります。
3. 依頼は、エンジンが人に求める作業です。各依頼には、依頼の理由（例：キャリブレーション、証明、検証、監査）、その項目がサンプルとして抽出された確率、その人が機械の答えを見ることができたかどうかが記録されます。キャリブレーションの依頼はランダムに抽出され、常にブラインドです。
4. コントラクトは、ランダムサンプル上の人手ラベルに対して機械ラベルを検定します。サンプルの半分（dev分割）で受理ルールを選び、もう半分（cert分割）でそれを検定します。コントラクトのステータスは、met、insufficient（さらにラベルが必要で、あといくつ必要かの見積もりが付く）、infeasible、violated、staleのいずれかです。
5. 解決によって、すべての項目に最終ラベルが与えられます。ラベルは、満たされたコントラクトのもとで受理された機械ラベル、人のラベル、または保留のいずれかです。
6. 証明書には、各コントラクトの結果、モデルとプロンプトのバージョンを含むカスケード、各目的に使われた人手ラベルの数、モデルへの支出、呼び出しログのダイジェストが記録されます。

保証を支えるルール

コントラクトが満たされたというのは、人がラベルを付けたランダムサンプルについての統計的な言明であり、それが成り立つのはそのサンプルの抽出方法と使い方によるものです。エンジンは次の5つのルールを強制します。

• ブラインドの依頼では機械の答えを表示しません。 人がキャリブレーション、証明、監査の依頼を受け持っている間、サーバーはその項目に対する機械の答えをすべて伏せます。プレアノテーション、インラインの判定者、AIアシスタント（403を返します）、AIヘルプボタンはすべて無効になります。機械の答えを見た後で付けたラベルは、その答えの独立した検証にはなりません。
• 選択と検定には別々のラベルを使います。 しきい値はdevラベルで選び、certラベルで検定します。certラベルで新たに検定するたびにより厳しい水準で実行されるため、検定に通るまで証明をやり直しても信頼度は水増しされません。
• 証明できるのは人だけです。 機械のアノテーターは最終ラベルの推論には参加できますが、コントラクトが検定の基準とするラベルには決して加わりません。
• 変更があると証明書はstaleになります。 ソース、プロンプト、しきい値、スキーマのいずれかを変更すると、影響を受けるすべてのコントラクトがstaleになり、受理されていたラベルは、そのコントラクトが再び検定されるまでpending_recertに移ります。人手ラベルは保持されます。
• 機械の予測はアノテーターの枠を埋めません。 エンジンの予測は、項目ごとのアノテーター数の上限に数えられません。

エンジンは人手ラベルが正しいかどうかを確認しません。どのコントラクトも、サンプルにラベルを付けた人々を基準に機械を測定します。そのため、信頼性の低い人々に対して検定したコントラクトは、信頼性の低い人々との一致を証明することになります。人のほうも確認するには、品質管理、重複アノテーション（humans.overlap）、no_worse_than_humanコントラクトを使ってください。

最初の研究

Potatoには、examples/labeling-engine/以下に、テキスト、画像、エージェントトレースそれぞれ1つずつ、計3つの研究例が付属しています。次の表は、各例が使うソースとコントラクトの一覧です。

テキストの例は4つのコマンドで実行できます。1つ目はカスケードですべての項目にラベルを付け、最初のブラインドサンプルを抽出します。2つ目はそのサンプルを人に提示します。残りの2つは、人がサンプルにラベルを付け終えた後に、コントラクトを検定して証明書を出力します。

potato label run examples/labeling-engine/text-certified-sentiment/config.yaml
potato start examples/labeling-engine/text-certified-sentiment/config.yaml -p 8000
potato label certify examples/labeling-engine/text-certified-sentiment/config.yaml
potato label certificate examples/labeling-engine/text-certified-sentiment/config.yaml --format md

自分の研究にエンジンを加えるには、すでにdata_filesとsentimentという名前のアノテーションスキーマを持つ設定に、次のキーを追加します。このコントラクトは、受理した機械ラベルのうち誤りが最大10%であることを信頼度90%で求めます。budgets.human_labelsは、エンジンが開ける人への依頼の数に上限を設けます。

assignment_strategy: engine
 
labeling_engine:
  enabled: true
  sources:
    - id: gemma
      kind: llm
      endpoint_type: vllm
      model: google/gemma-4-12B-it-qat-w4a16-ct
      base_url: http://localhost:8001/v1
      confidence: {method: logprob}
  contracts:
    - id: accuracy
      kind: selective_risk
      schema: sentiment
      error: 0.1
      confidence: 0.9
  budgets:
    human_labels: 400

このソースは、トークンの対数確率から信頼度を求めます（method: logprob）。この方法は項目ごとに1回の呼び出しで済み、通常は信頼度の求め方の中で最もよく較正されています。すべてのキーは設定に、各コントラクトが何を検定するかはコントラクトにあります。

アノテーションページでの依頼

assignment_strategy: engineを指定すると、アノテーターにはエンジンの依頼が優先度の高い順に提示されます。順序は、裁定、証明、キャリブレーション、分布型コントラクトのための追加の評価者、どの機械もラベルを付けられなかった項目、検証、監査です。キャリブレーションの依頼は固定のランダム順で提示され、devとcertの依頼が交互に混ざります。1人の人には、ある項目で開いているすべての依頼がスキーマごとに1つずつまとめて渡され、同じ項目の同じスキーマについて2つの依頼が渡されることはありません。

項目の上には、それがどの種類の依頼かを示す短い注記が表示され、複数の質問があるページではその質問の名前も示されます。

• ブラインド。 注記には「Label this one yourself. Suggestions are off for this item.」と表示されます。その人にとってこの項目は、保存した後も、再読み込みや「戻る」の後もブラインドのままです。
• 検証。 機械の答えが入力済みになっており、注記には、正しければそのままにし、正しくなければ変更するよう書かれています。ページは事前入力された答えを記録するので、人がそれをどのくらいの頻度で受け入れるかを測定できます。人が操作するまで何も保存されないため、開いたままのページが本人に代わって回答することはありません。ページが答えを事前入力できないスキーマ（時間セグメント、3Dオブジェクト、エージェントトレース）は、代わりにブラインドで提示されます。
• 解決。 受理できる機械ラベルがなかったため、その人の答えがラベルになります。

依頼を受け持ったままruntime.hold_minutes（デフォルトは60）のあいだ回答しなかった場合、その依頼はプールに戻り、その人のページから消えます。エンジンがその人に提示していない項目で保存されたラベルが他の人の依頼を閉じることはなく、エンジンはそれを自発的なラベルとして保持します。新たな証明で機械ラベルが受理されると、エンジンはその対象となった項目で開いている検証と解決の依頼を取り消します。すでに人が受け持っている依頼はその人のもとに残り、その人の答えが機械ラベルに置き換わります。

進捗カウンターが数えるのは、コーパス全体ではなく、その人がまだ受けられる依頼です。まだ作業がないとき、アノテーターには短い待機ページが表示され、プランナーが依頼を開くたびに新しい依頼が提示されます。すべての項目にラベルが付いた、人手ラベルの予算を使い切った、あるいはその人自身の上限に達したといった理由でこれ以上依頼が来ない場合、その人の担当分は通常どおり研究後のページで終わり、クラウドソーシングのプラットフォームでは完了コードが表示されます。プランナーの最初の処理が終わる前に作業が終了する人はいません。

Pocket Modeもエンジンの依頼を1バッチ分まとめて提示し、「All caught up」と表示する前にさらに依頼を求めます。Pocket Modeは機械の答えを決して表示しないため、そこで提示された検証の依頼は、デスクトップのページがすでにその人に答えを表示していた場合を除き、ブラインドとして記録されます。解決と裁定のカードでは、デスクトップのページと同じ注記を表示します。

管理ページ

エンジンが有効なとき、管理ダッシュボードには/admin/labeling-engineのLabeling engineへのリンクが表示されます。このページのすべてのグラフには表形式の表示もあります。ページには次の内容が表示されます。

• 各コントラクトのステータス、カバレッジ、ルック番号、あといくつラベルが必要か、およびそのコントラクトが述べる完全な言明（満たされていないコントラクトは保証ではなく目標を述べます）
• 各ppiコントラクトの区間と、人だけから得た区間の並列表示
• 最後の実行が失敗したソース、またはすべての答えがエラーだったソースに対する警告
• カスケードの最後の段についての、誤り率とカバレッジの曲線（保証される上限と目標付き）
• 段ごとの信頼性ダイアグラム（記載された信頼度と人手ラベルでの正解率をプロットし、ECEとブライアースコアを付け、ラベルの少ないビンは薄く描画）
• 受理されたラベルの監査（目標に対する誤りとして表示）と、監査の数が少なすぎて判断できないかどうか
• 目的とステータスごとの人への依頼
• トークン数、レイテンシ、コスト付きのモデル呼び出しログ（新しい順）
• プランナーの処理を実行する、今すぐ証明する、証明書を開く、の各ボタン

管理セッションなしで開くと、ページはダッシュボードのキー入力フォームに移ります。エンジンが無効な場合は、その旨と、エンジンを有効にするキーの名前が表示されます。

参考資料

• ラベリングエンジンのコントラクト：6種類のコントラクトと、それぞれが何を検定するか
• ラベリングエンジンの設定：labeling_engineのすべてのキー
• コマンドライン、REST API、MCPツール、SDK
• icl_labeling、judge_calibration、pre_annotationからのラベリングエンジンへの移行
• 1人の専門家がLLMと協働する場合のSolo Mode
• LLMによるプレアノテーションとLLM判定者と人の一致度

実装の詳細については、ソースドキュメントを参照してください。