安価な第1段のラベラーとしての意思決定モデル

意思決定モデルは、固定選択肢の質問に1回のフォワードパスでラベルを付け、生成するテキストなしに、すべての選択肢の確率を返します。選択肢が数個のN択の質問では、これをラベリングカスケードの第1段として使い、確信の持てない項目はLLMに回し、そのしきい値はブラインドの人手サンプルで証明してください。誤っている入力でも信頼度が高いままのことがあるからです。

意思決定モデルとは、テキストと型付きの質問のセットを受け取り、各回答の確率を返す分類器です。テキストを生成しないので、プロンプトも理由もルールも書けません。Layaはこの種のオープンなモデルの1つです。そのモデルカードには、Apache 2.0ライセンスの、ModernBERT-largeエンコーダーをベースとする4億2,100万パラメータの英語チェックポイントと、3億2,200万パラメータの多言語チェックポイントが記載されています。/v1/systemone APIは、同じ種類の回答をHTTP経由で、ホスト版のJev、OpenJev、またはLaya自身のサーバーから提供します。

第1段で費用を節約できる場合

ラベリングのカスケードはモデルを順に試し（通常は最も安価なものから最も高性能なものへ）、現在のモデルの確信が十分でない場合にだけ項目を次に回します。コーパスに簡単な項目が多く含まれる場合、それらに確信を持ってラベルを付けられる安価なモデルがあれば、LLMに残るのはより少なく、より難しい項目になります。節約の大きさはその割合で決まるので、それを前提に計画を立てる前に自分のデータで測ってください。

意思決定モデルが第1段に向いているのは、1回のパスですべての選択肢に答えるため、ラベルが5つある質問でも1回のフォワードパスで済み、生成されるテキストもないからです。出力される確率がそのまま信頼度スコアになるので、追加の質問や繰り返しのサンプリングも必要ありません。またCPUで動作します。モデルカードによれば、チェックポイントを事前に読み込んだ状態で、CPUではリクエストあたり193〜464ms、T4 GPUでは英語チェックポイントで39.5msです。

Layaについて報告されている限界

以下の限界のうち4つはLayaのモデルカードによるもので、5つ目の評定尺度に関するものはPotatoのドキュメントによるものです。

• 選択肢が多い場合。 Banking77の意図分類ベンチマークで、モデルカードはLayaの正解率を77ラベルで0.425と報告しており、Jevは72ラベルで0.870です。選択肢は固定のトークン予算を共有するので、長いラベルリストでは選択肢同士が押し合うことになります。Potatoのドキュメントには、選択肢が11個以上の質問ではLayaが温度が範囲外であると警告し、値を範囲内に丸めることも記載されています。
• 英語チェックポイントでの他の文字体系。 モデルカードは、クメール語のテキストに対する英語チェックポイントの正解率を0.000、信頼度を0.952と報告しています。モデルが確信している誤りは、信頼度のしきい値では捉えられません。
• ゼロショットでの正解率。 モデルカードによれば、ベースのチェックポイントは型付き意思決定ベンチマークのゼロショットで偶然に近い0.362で、ランダムの基準線は0.318、多数派クラスの基準線は0.461です。モデルカードはLayaを「特化させるための高速なベースであり、ゼロショットの意思決定エンジンではない」と述べています。
• 素の較正。 モデルカードによれば、layaは過信した状態で提供されており、平均の期待較正誤差は0.466ですが、自分のデータで温度を再フィットすると0.081まで下がります。較正の度合いはドメインによって異なるので、他人のデータで選んだしきい値はそのまま使えません。
• 評定尺度。 Potatoのドキュメントでは、likertとsliderのスキーマにおいて、質問の言い回しにかかわらず、Layaのスコアは尺度をほとんど追えないことがあるとしています。

これらの限界を総合すると、意思決定モデルは、そのチェックポイントが学習した言語での、選択肢の少ないN択の質問に限って使うのがよさそうです。そのしきい値は、自分のコーパスの人手ラベルから選んでください。

Potatoでの意思決定モデル

Potato 2.11では、意思決定モデル用のエンドポイントタイプが2つ加わりました。layaはPotatoのプロセス内でLayaを実行し、decisionエクストラ（pip install 'potato-annotation[decision]'）が必要です。これはtorchとtransformersを取り込みます。systemoneは/v1/systemone APIを持つ任意のサーバーと通信し、必要なのはbase_urlだけです。どちらもradio、select、likert、sliderのスキーマで動作し、multiselect、スパン、自由記述のスキーマをラベリングするよう設定されている場合、Solo Modeは起動しません。

ラベリングエンジンでは、意思決定モデルはカスケードの先頭に置くdecisionソースです。Potatoに付属するテキストの例から抜粋した次の設定では、Layaを小さなOllamaのLLMの前に置き、この組み合わせを、誤り10%の目標に対してPotatoのデフォルトである信頼度90%で証明します。

labeling_engine:
  enabled: true
  sources:
    - id: laya
      kind: decision
      endpoint_type: laya
      model: convaiinnovations/laya
      options:
        device: cpu
    - id: llm
      kind: llm
      endpoint_type: ollama
      model: llama3.2:3b
      base_url: http://localhost:11434
      max_tokens: 200
  cascade: [laya, llm]
  contracts:
    - id: accuracy
      kind: selective_risk
      schema: sentiment
      error: 0.1
      confidence: 0.9

エンジンは、ブラインドの人手サンプルの半分でLayaの信頼度のしきい値を選び、もう半分でそれを検定します。そのため、しきい値はモデルカードではなく自分のコーパスから決まります。サンプルのdevの半分がLayaのしきい値を確定させるまでは、LLMがすべての項目にラベルを付けます。その後、LLMが受け取るのは、Layaが確信を持てない項目とキャリブレーションサンプルだけになります。

この例のREADMEに記録されている、LLMとしてGemma 12Bを使った実行では、Layaのしきい値は一度も確定せず、受理されたラベルはすべてLLMが出したものでした。そのため、第1段がどれだけ貢献するかは、当てにする前に自分のコーパスで測ってください。エンジンは各段の受理したラベルを別々に検定するので、クメール語の例のような確信を伴う失敗は、証明サンプルがその種の入力を含んでいれば、そのサンプルの誤りとして現れます。distributionalコントラクトはLayaの確率ベクトル全体を使うこともでき、アノテーターの意見が分かれる主観的な質問に適しています。

Solo Modeでは、意思決定モデルはlabeling_modelsに、またconfidence_routingの第1段として置かれます。Solo Modeではrevision_modelsに生成モデルも必要です。意思決定モデルは、その改訂ループが生み出すプロンプトやルールを書けないからです。

本番の実行の前に意思決定モデルを試す

コーパス全体をモデルに通す前に、すでにラベルを付けた数十件の項目でモデルを実行してください。Solo ModeのTry on 10 itemsボタンはプロンプトについてこれを行います。エンジンでは、potato label runの後にpotato label statusを実行すると、各段のしきい値にあといくつラベルが必要か、どのソースが誤りを出したかがわかります。証明に失敗した段は何も受理せず、しきい値を超えた項目をLLMではなく人に回します。その結果、LLMがラベルを付けられたかもしれない項目に人手ラベルの予算が使われてしまいます。意思決定モデルの段が証明に失敗し続ける場合は、カスケードから外してください。

参考資料

• ラベリングエンジンの設定：decisionソースのすべてのオプション
• ブラインドの人手サンプルでLLMラベルを証明する：ブラインドサンプルに対するしきい値の証明について
• Solo Mode：1人の専門家による信頼度ルーティング