ラベリングエンジンへの移行
potato label migrate-configで、icl_labeling、judge_calibration、pre_annotation、Solo Modeの設定をラベリングエンジンに移行する方法と、移行後に何が変わるかを説明します。
Potatoの従来の機械ラベリング機能は2.11でも引き続き動作し、labeling_engineブロックを追加するまで動作は何も変わりません。3つのキーは起動時に、対応するラベリングエンジンの機能を示す情報メッセージを表示するようになり、3.0で削除される予定です。このメッセージはstderrに出力され、NOTE:で始まり、警告ではないので、potato validate --strictがこれによって失敗することはありません。
次の表は、3つのキーと、それぞれの移行先です。
| 従来のキー | エンジンでの対応 |
|---|---|
icl_labeling | llmソース。従来のルールのためのthreshold_legacyコントラクトと、それに並べたselective_riskコントラクトを使います |
judge_calibration | k_sampleの信頼度を使うjudgeソース。そのブラインドサンプルはキャリブレーションの依頼になります |
pre_annotation | staticソース |
Solo Mode、判定者のアラインメント、対話型のAIアシスタント（ai_support）は非推奨になっていません。Solo Modeは1人の専門家が専用のインターフェースでLLMと協働するもので、判定者のアラインメントはレポートです。エンジンが有効な場合は、どちらもモデルの予測をエンジンのストアにも書き込むので、エンジンはそれらをキャリブレーションし、証明できます。
potato label migrate-config
potato label migrate-configは、従来のキーをlabeling_engineブロックに変換します。
potato label migrate-config config.yaml --out config-engine.yamlこのコマンドはデータを読み込まずにYAMLを読み、同等のlabeling_engineブロックを追加し、各変換を説明する注記をヘッダーに付けて結果を書き出します。ブロックはenabled: falseで書き出されるので、変換された設定は、エンジンを有効にするまで元の設定と同じように動作します。注記を読み、ソースとコントラクトを確認してから、enabled: trueとassignment_strategy: engineを設定してください。設定にすでにlabeling_engineブロックがある場合や、変換するものがない場合、コマンドはエラーで終了します。
変換表
従来の各ブロックは、エンジンのソース、コントラクト、人の設定に次のように対応します。
| 従来のブロック | ソース | コントラクト | 人 |
|---|---|---|---|
confidence_routing.tiersを使うsolo_mode | 段ごとに1つのソース（段の順） | N択の単一選択スキーマごとにselective_risk、error: 1 - end_human_annotation_agreement | pools: [solo] |
labeling_modelsを使うsolo_mode | モデルごとに1つのソースで、最初のものがカスケードになる | 同上 | pools: [solo] |
solo_mode.jury | 審査員ごとに1つのソースと、カスケードとしてのjuryソース | 同上 | |
icl_labeling | llmソースとしてのai_supportエンドポイント | 従来のconfidence_thresholdでのthreshold_legacyと、10%でのselective_risk | calibration_rate = 従来の検証のsample_rate |
judge_alignment | judgeソースとしての判定者のエンドポイント（スキーマが1つならルーブリック付き） | 判定対象のスキーマごとにno_worse_than_human、epsilon: 0.15 | overlap: 0.3 |
judge_calibration | k_sampleの信頼度を使うjudgeソースとしての各モデル | sampling.sample_size → budgets.human_labels | |
fieldまたはpredictions_fileを使うpre_annotation | カスケードの先頭に置くstaticソース | ||
active_learning.llm | llmソース | ||
ai_budget.cap_usd | budgets.model_usd |
移行後の動作の変化
エンジンは従来の機能とは異なる方法で人手ラベルを扱い、変換された設定の注記にはどこが違うかが書かれています。変化は次の4つです。
- 固定のしきい値が、検定されたしきい値になります。 Solo Modeのルーティングのしきい値や
icl_labelingの信頼度しきい値は、固定の数値を超える機械ラベルを受理していました。selective_riskはdevラベルでしきい値を選び、取り置いたラベルでの検定に合格したものだけを受理します。そのため、最初は受理されるラベルが少なくなりますが、受理されたラベルには誤りの上限が明示されます。 - 検証のサンプルが一様になります。
icl_labelingは最も信頼度の低い予測から検証していたので、誤りはすぐに見つかりますが、正解率の推定には偏りが生じていました。エンジンのキャリブレーションの依頼は、包含確率を記録したランダムサンプルです。 - インラインの判定がブラインドになります。
judge_alignment.inlineは人がラベルを付けている間に判定者の判定を表示していたので、一致度はアンカリングされたラベルで測定されていました。エンジンのキャリブレーションの依頼では、機械の答えは決して表示されません。 - プレアノテーションは、信頼する前に検定されます。
staticソースのラベルは、コントラクトが証明した場合にのみ受理され、それ以外では検証の依頼として人に表示されます。
参考資料
実装の詳細については、ソースドキュメントを参照してください。