laya - 文章から選択・スコア・真偽を返す非自己回帰型の意思決定エンジン

メールやチケットを読み、担当部署や緊急度を決める処理では、必要な出力は有限のラベルや数値に収まる。それでも生成モデルを使う場合は、分類や判定を依頼し、返答をアプリケーションが受け取れる型へ変換する工程を挟む。構造化出力を求める場合も、判断を生成モデルに担当させるという構成は共通する。

layaは、この判断部分を文章生成から切り出す。入力となるstateと、判断軸を記した質問、候補の説明を渡し、型付きの値を受け取る。たとえば請求対応と技術対応を分けるなら、部署名をchoiceのラベルに、各部署の担当範囲をcriteriaに置く。回答文の表現を解釈する工程は省けるが、入力を読み違えた結果まで防げるわけではない。

この切り分けから、layaは生成モデルを全面的に置き換えるものではなく、分岐直前の判断層として理解できる。根拠の文章化や自由文生成を同じ呼び出しで完結したい用途では、別の生成処理が必要になる。

READMEは、英語用チェックポイントが非英語入力で高確信度の誤答を返す問題を挙げる。誤答にも強い確信を示すなら、推論後に低確信度だけを棄却しても、誤ったモデル選択を救えない。そこでRouterは、推論前に文字体系や機能語を調べ、英語用と多言語用を振り分ける。

作者による構成説明では、英語版とtyped-decisions版はModernBERT-largeの421Mパラメーター、多言語版はmmBERT-baseの322Mパラメーターを使う。単一のモデルへすべての要求を送る構成ではなく、要求に応じてチェックポイントを選ぶ構成だ。

ただし、検出はヒューリスティックであり、短いLatin文字の非英語文を英語側へ送ることがある。多言語版も英語では弱いとされるため、すべてを多言語側に寄せれば解決するとは限らない。言語ヒントや明示指定を管理することが、精度設計の一部になる。

型付き質問では、状態本文だけでなく、質問と候補の説明もモデルが読む必要がある。layaはこの質問・選択肢側をheadとして扱い、本文に残る枠を、全体のmax_lenから実際のhead長と区切り分を引いて決める。候補を増やすと、分類の出力空間だけでなく入力の配分も変わる。

多候補では説明が短縮されて識別しにくくなり、head自体が予算を超えて本文を圧迫する場合もある。head_max_lenは実際のhead長を厳密に制限する上限ではない。候補数を増やしても同じ本文を同じ条件で読める、という前提は置けない。

したがって、導入前に整理すべきなのは質問の型だけではない。候補をどこまで絞るか、説明をどう区別するか、本文のどこまでを読む必要があるかも、判断の仕様として定める必要がある。

stateは文字列、辞書、リストを受け取る。質問はinstructionsとcriteriaで判断軸を記述し、choice、score、noulの型を指定する。choiceは選択ラベル、scoreは順序レベルの期待値、noulはP(true)を返す。scoreは単に一つのレベルを選ぶ出力とは区別して読む必要がある。

Routerはmodel、task、langなどの明示指定やlang_guess、言語検出結果を使って処理先を決める。routeだけを呼ぶ場合は、重みをロードせず、forward passも実行しない。ルーティングと推論を別々に確認できるAPIになっている。

推論先のAgentが未ロードならチェックポイントをロードする。Hubの重みは初回に取得してキャッシュし、Routerは既定で二つのチェックポイントをLRU管理する。常駐枠が足りなければ退避と再ロードが生じるため、入力言語の混在は、精度だけでなくメモリと待ち時間にも関わる。

選ばれたAgentは、質問と選択肢をレンダリングし、状態本文を含む入力行をトークン化する。本文枠はmax_len − head_len − 1で決まり、通常のpredictでは超過部分を切り捨てる。その後、作者の説明では質問群を並列の行として一つのforward passにまとめ、エンコーダーと判断ヘッドで評価する。

ここでいう「単一forward pass」は、質問数にかかわらず計算量が一定という意味ではない。質問を増やせば評価行数も増える。自由文を逐次生成する代わりに、複数の判断行を一括で評価する実行モデルだ。

作者はTesla T4で、多言語版の一質問を32.8ms、十質問をまとめた呼び出しを72.3msと報告する。まとめる効果を示す測定だが、表には入力長、ウォームアップ、計時境界の詳細がない。初回の重み取得やロードを含む要求時間、別のハードウェアでの遅延としては読めない。

判断結果の確率から、choiceのラベル、scoreの期待順序レベル、noulの真である確率を構成する。返り値にはanswersに加えて、確率や確信度、usage、routingが含まれる。decideではJSON Schemaまたはpydanticモデルから質問を作り、回答をスキーマに沿う値へ投影する。

確信度には異なる指標がある。choiceとscoreのconfidenceは、1から正規化エントロピーを引いた分布の集中度だ。一方、answer_confidenceは報告された回答の確率であり、指定されたmin_confidenceの棄却ゲートはこちらを読む。出力を使う側は、二つを同じ意味の値として扱えない。

温度スケーリングやヒストグラムビニングによる校正も提供される。ただし、閾値は選択肢数や提供時のdtypeを含めて検証する必要がある。棄却状態を得られることと、その閾値で誤判断を十分に抑えられることは、別の確認事項だ。

一つの状態に対する複数質問の評価とは別に、predict_batchは複数の要求をまとめる。Routerは先に各要求をルーティングし、チェックポイント、質問スキーマ、トークン予算が共通するものをAgent.predict_batchへ渡す。処理後の結果は元の入力順へ戻す。

バッチ内の入力は最長のものへパディングされる。sort_by_lengthは似た長さの入力をまとめ、その余分な計算を減らす。作者は、実Yelpレビュー128件、英語モデル、batch_size=8、Apple SiliconでのCLI自動デバイス選択、四回の交互測定で、未整列41.25秒に対し長さ順29.23秒、全判断一致と報告している。これは当該条件の結果であり、機種詳細は記載されていない。

同じ質問を大量のチケットへ適用する処理では、この要求単位のまとめ方が効いてくる。個別のpredictを繰り返す構成と、共通スキーマや入力長を利用してまとめる構成は、分けて評価したい。

通常predictの切り捨てに対し、predict_longは重複窓で全文を走査する。ただし、文書全体の情報を統合した一つの判断ではない。noulは最も強い窓、choiceとscoreは最も確信度の高い窓を採用し、返す確率も採用窓の値になる。

そのため、noulの最大値は窓数とともに上がり得る。choiceでは確信度の高い中立窓を選ぶ場合があり、全文を走査したことだけでは文書全体への適切な判断を保証できない。多言語版の通常入力は既定1,024トークンで、8,192を使うにはmax_lenの明示が必要だ。英語主体の長文でも多言語モデルを指定する必要がある。

利用経路はPython SDK、CLI、HTTP、MCPなどに分かれる。laya-serveはJev互換のPOST /v1/systemoneを提供する。MCPでLAYA_BASE_URLを指定すると、予測は共有HTTPサーバーへ送られ、ルーティングはローカルに残る。「ローカル判断層」がどのプロセスで推論するかは、接続方式に応じて確認する必要がある。

適用候補は、少数から中程度の候補で処理先を決めるチケット仕分け、エージェント分岐、同一スキーマのバックログ評価だ。自分のラベル付きデータで学習、校正、棄却方針を検証できる運用と相性がよい。文章を外部の判断APIへ送らず、ローカル重みと自己ホストHTTPやMCPで判断層を共有したい場合も候補になる。

生成モデルとの関係は補完的だ。有限候補の選択をlayaに渡し、自由文生成や開いた質問への回答は生成モデル側へ残せる。一方、判断根拠の文章化まで一つのモデルで済ませたい用途には合いにくい。

TypeSafe Jevとは同種の型付き判断APIを提供する点で競合する。ただし、HTTPの百候補上限、scoreのnull拒否、confidenceの定義などに差があり、互換エンドポイントだけを根拠に既存の閾値をそのまま移せない。READMEのJev性能値も同条件の直接測定ではなく、速度や精度の勝敗は判断できない。

作者のtyped-decisions評価は、400ケース、2,000判断、四つのワークフローで、fine-tune版0.766、英語ベース0.362、多言語ベース0.352、多数派ベースライン0.461と報告される。ベースモデルは多数派を下回る。0.766は同ベンチマークの学習splitで学習した結果であり、汎用ゼロショット精度ではない。さらに、その結果ファイルは未コミットと明記されている。

出荷時の確率には過信傾向があり、多言語版には推定済み温度がない。作者はheld-outデータで型と選択肢数ごとに温度を再推定し、平均ECEが英語版0.466から0.081、多言語版0.314から0.106へ下がったと報告するが、該当節には件数とsplitの詳細がない。

別のfine-tuningノートブックでは校正に学習項目を使うとされるため、この手順とheld-out評価を混同できない。採用判断には、自分の用途で分離した評価データが必要だ。日本語の個別精度、否定表現、未知入力への挙動も取得資料からは判断できない。

選択肢を渡せることは、選択肢の表現に頑健であることを意味しない。READMEはchoiceやnoulがラベル語に引かれること、否定表現の誤読、選択肢位置のバイアスを報告する。多言語版scoreには最初のレベルを選びにくい傾向もある。

公開チェックポイントはすべてsequential option layoutだ。順序不変のparallel layoutを使うには再学習とtransformers>=5が必要で、対応する推論経路もeagerに限られる。候補順序の問題を設定変更だけで解消できるわけではない。

多候補への対処としてshortlistを使う場合、返る確率は残した候補内の値になる。元の全候補に対する確率と同じ意味で扱えない。候補を絞る工程や階層化を導入できない用途では適合性が低く、候補数、語彙、順序を含む質問スキーマ自体を評価対象にする必要がある。

自己ホストはハードウェアと運用の費用を伴う。Hub重みの初回取得にはネットワークが必要で、ローカル重みを指定すればオフライン構成は可能だ。preloadはロード待ちを前へ移せるが、メモリ不足の解決策にはならない。数百Mパラメーターの重みを常駐できず、頻繁な切り替えにも低遅延を求める環境では厳しい。

推論経路にはeager、compile、TileLang、ONNXがある。compileやTileLangには起動やshape別のコンパイル費用があり、compileのwarm-upが失敗してもeagerへ自動退避しない。定常時の測定値だけでは、提供開始時や形状変更時の挙動を評価できない。

混合精度やバッチ形状で確率やargmaxが変わり得る点も、校正条件に関わる。Intel Macには依存関係の固定が必要で、.NET版には長文処理や校正などの未移植機能がある。利用言語とバックエンドを決めたうえで機能範囲を確認したい。入力を外部へ送る範囲は接続方式で変わるが、今回の資料だけでは認証や権限管理、APIの将来の安定性までは評価できない。