Laya の仕組み：Choice・Score・Noul を解説

リクエストには二つの要素がある

状態は評価対象の資料です。チケット、メール、会話、プロンプト、ログ、JSON 文書などが該当します。質問はソフトウェアが受け入れる判断を、指示と基準を含めて定義します。Laya は両者を一つのモデル入力にまとめます。

入力

調べるべき根拠。構造化フィールドと自然言語の内容を含められます。

スキーマ

各質問は一つの出力型と、その解釈に使う基準を宣言します。

モデル

状態と全質問のマーカーを、1 回の順伝播で評価します。

出力

応答は宣言した型に適合し、コードで利用できます。

チャットモデルは通常、一つずつトークンを生成します。範囲の限られた分類でも、生成費用、JSON の検証、スキーマに合わない回答への対処が必要です。Laya は文字列を生成せず、事前定義した回答マーカーを採点し、確率へ正規化します。

そのため、複数の限定的な質問を一緒に評価でき、未知のラベルが出力に現れません。一方、Laya は推論の理由を説明したり、返信を書いたり、新しい行動を考案したりできません。制御フローと副作用は引き続きコード側が管理します。

choice 質問では、ラベルと説明を指定します。Laya は各ラベルの確率を返し、最大のものを選びます。ラベルが具体的で区別しやすければ、振り分けや分類に適します。

Which team should handle this request?

請求：請求書と返金 · 技術：不具合と障害 · 営業：価格と契約

choice の規模には限界があります。基準は固定された選択肢トークン予算を共有します。説明の長いラベルが数十個あると、区別しにくくなるまで説明が切り詰められます。Laya 自身の Banking77 の結果はこの制約を明確に示します。

score 質問では、緊急度の低・中・高など順序付きの評価基準を定義します。モデルは各段階の確率と、確率で重み付けした期待スコアを返します。期待スコアは離散段階の間の値にもなります。

「非常に緊急」といった曖昧な形容詞より、「サービスが利用できず、作業が止まっている」など観察可能な基準を書いてください。順序付き採点は現在 Laya の最も弱い基本型なので、ドメイン別の検証が特に重要です。

noul 質問は yes/no の確率を求めます。明示的な返金要求、秘密の開示を求めるプロンプト指示、解約を示唆するメッセージなど、具体的で観察可能な事実の検出器として使うのが適切です。

「これは適切か」のような広い判断は、明示していない複数の規範を含み、結果が不安定になりがちです。より限定的な事実の質問へ分解してから、コードで組み合わせてください。

チェックポイント	基盤モデル	コンテキスト	適した用途
`laya`	421M ModernBERT-large	512 トークン	英語のタスクと付属プリセット
`laya-multilingual`	322M mmBERT-base	既定は 1,024。エンコーダー自体はそれ以上に対応	英語以外や複数言語が混在する状態
`laya-typed-decisions`	421M ModernBERT-large	1,024 トークン	typed-decisions 学習で使う四つのワークフロー群

プロジェクトには、主に文字体系と言語のシグナルで英語・多言語チェックポイントを選ぶルーターが含まれます。英語チェックポイントは、苦手な文字体系で失敗していても高い確信を維持しうるため、この振り分けは重要です。

校正されたモデルなら、約 80% の確信で出した予測は、比較可能な事例の約 80% で正しいはずです。これにより、しきい値より上を自動化し、下をエスカレーションできます。

Laya の RLCD 学習は適正スコアリングルールで確率の品質を報酬化しますが、ドメインやラベル数によって校正は変わります。リポジトリは未使用検証データへの温度適合を推奨しています。重要な判断を自動化する前に、確信度帯ごとの正確度を描き、高確信の誤りを確認してください。