Layaモデルを解説：ローカルで実行できるオープンソースの意思決定モデル

Layaは、より安価なChatGPTになろうとする別の小型言語モデルではありません。トークンを1つずつ順番に処理して段落を生成することはありません。代わりに、メール、サポートチケット、エージェントのトレース、JSONオブジェクトなどの状態を受け取り、確率付きの構造化された意思決定を返します。

これにより、LayaはTypeSafeのJevと同じ新興カテゴリに属しますが、大きな違いが1つあります。LayaのウェイトはApache 2.0の下で公開されており、モデルを完全にローカルハードウェア上で実行できます。ローカルAIにとって、これはLayaを単なる高速分類器以上に興味深いものにしています。反復的なAIによる意思決定を、そもそも最先端モデルに送るべきなのかという、より大きな疑問を提起します。

Layaとは？

Layaは、Convai Innovationsが開発したオープンウェイトの非自己回帰型意思決定モデルです。

英語版の主要チェックポイントは、バックボーンとしてModernBERT-largeを使用し、約4億2,100万パラメーターを含んでいます。任意の言語を生成する代わりに、アプリケーションは状態と1つ以上の型付き質問を渡します。

このインターフェースに聞き覚えがあるのは、Jevも同様の型付き意思決定モデルを使用しているからです。以前のAIエージェント向け意思決定モデルに関するガイドでは、このモデルカテゴリがそもそも登場しつつある理由を説明しています。

Layaは、学習済みの意思決定エンジンとして理解するのが適切です

生成モデルには、次のような入力を与えることがあります。

「このサポートチケットを読んで、顧客が何を求めているか説明してください。」

Layaは、より限定された質問向けに設計されています。

• どの部署に送るべきか？
• 緊急か？
• フィッシングのように見えるか？
• 別のモデルでレビューする必要があるか？

重要な違いは「賢いモデルか単純なモデルか」ではありません。アプリケーションが実際に言語生成を必要としているかどうかです。

ソフトウェアが知る必要があるのが請求、技術、営業のいずれかだけなら、段落を生成してから列挙型に解析し直すのは無駄な作業です。

Layaはテキストを生成せずにどのように意思決定するのか？

公式アーキテクチャドキュメントによると、Layaは約3億9,500万パラメーターのModernBERT-largeエンコーダーに、2層の意思決定ヘッド、選択肢マーカーのスコアリング、act/escalateコンポーネントを組み合わせています。

ModernBERTは双方向モデルであるため、Layaは出力を一度に1トークンずつ予測するのではなく、状態、質問、利用可能な選択肢をまとめて考慮できます。

このアーキテクチャ上の違いが、次のようなワークロードで小型の判断モデルを魅力的にします。

• エージェントのルーティング。
• メールの振り分け。
• モデレーション。
• 文書の関連性。
• 意図の検出。
• 安全ゲート。
• ワークフローのエスカレーション。

これらはまさに、ハイブリッドAIルーティングが有効になる日常的なワークロードです。反復的な作業はより安価なローカルレイヤーで処理し、難しいケースにはより大きなモデルを回します。

Layaには本当に「ハルシネーションがない」のか？

プロジェクトのドキュメントによれば、Layaはテキストを生成しないため、解析エラーやハルシネーションを排除できます。

ただし、この主張には重要な補足が必要です。

Layaは次のような失敗を排除できます。

• 不正な形式のJSON。
• 存在しない列挙値。
• 構造化されたレスポンスの周囲に付加された余計な文章。
• 自由形式で生成された主張。

それでも、誤った判断を下す可能性はあります。

モデルは次のように返すことがあります。

billing: 0.92

チケットをテクニカルサポートに送るべき場合であっても

型付き出力は無効な回答を防ぎます。しかし、判断が正しいことを保証するものではありません。

出力がエージェント、セキュリティワークフロー、金融プロセス、または自動化されたアクションを制御する場合、この違いは非常に重要です。

信頼度の数値より校正が重要な理由

LayaはRLCD（Reinforcement Learning for Calibrated Decisions：校正済み判断のための強化学習）を用いて訓練されています。目的は正しい答えを選ぶことだけでなく、報告される確率を有用なものにすることです。

本番システムでは、信頼度を使ってエスカレーションを制御できます。

しかし、Layaのドキュメント自体が、こうした確率を盲目的に信頼すべきでない理由を示しています。このプロジェクトでは、温度スケーリングによって校正が大幅に改善されると報告しており、導入先のドメインでモデルを校正することを推奨しています。

言い換えれば、校正済みの判断を行うよう設計されたモデルでも、実際のワークロードで校正する必要があります。

Layaで最も重要な成果は速度ではない

Layaが公開しているレイテンシーの数値は印象的です。このプロジェクトでは、Tesla T4上で短い判断を数十ミリ秒で実行できると報告しています。一方、独立したLaya-MLX移植版では、M3 Max上で英語モデルが約13.4ms、多言語チェックポイントが7.4msと報告されています。

これらの測定結果から、Layaは数十億パラメータの生成モデルとはまったく異なるデプロイメントクラスに属することが確認できます。

しかし、より示唆的なのは、性能がどれほど強く特化に依存しているかという点です。

このプロジェクトの型付き意思決定評価では、ベースLayaモデルはゼロショット利用時、ランダムベースラインをわずかに上回る程度です。タスク固有のファインチューニング後は、特化型チェックポイントの性能が大幅に向上します。

この点を踏まえて、Layaの捉え方は変わります。

これは、あらゆる新しい意思決定問題を魔法のように理解する421Mの汎用推論モデルというわけではありません。

Layaのより強力な価値提案は、小規模なモデルを安定した意思決定境界に特化させ、キャリブレーションを行ったうえで、大量の処理を極めて低コストで実行できることです。

ファインチューニングはベースモデルより重要になる可能性がある

このプロジェクトでは、チェックポイントと併せてトレーニングおよびファインチューニング用のツールも公開されています。これは重要です。というのも、本番環境での意思決定の多くは、ドメインに大きく依存するためです。

検討事項：

• この問題を担当する社内サポートチームはどこですか？
• この文書は、社内のプライベートな分類体系に合致していますか？
• このホームオートメーションを実行すべきですか？
• このタスクはどのエージェントに割り当てるべきですか？
• このローカルファイルには、より深いAI分析が必要ですか？

汎用モデルでもこれらの質問には答えられますが、ほとんど変化しない意思決定境界を再構築するために、大規模モデルの計算資源を何度も費やす可能性があります。

特化型のLayaチェックポイントなら、その境界を直接学習できます。

これはオープンモデルとフロンティアAIをめぐるより大きな傾向にも当てはまります。最も高性能なモデルが、反復的で明確に定義されたワークロードにとって、必ずしも最も効率的なモデルとは限りません。

Layaが依然として苦手なこと

公開された結果からも、明確な限界が示されています。

ラベルの選択肢が多いと困難です。Layaのドキュメントでは、選択肢をおおむね20未満に抑えることを推奨しています。利用可能な選択肢は固定されたトークン予算を共有するため、非常に大規模なフラット型分類体系では性能が低下する可能性があります。

階層的なルートのほうが理にかなっていることがよくあります。

順序尺度のスコアリングも、もう一つの弱点です。モデルにカテゴリーを選ばせるほうが、1から5までのフラストレーションスコアのように、互いに近いレベルを安定して区別させるより簡単なことがよくあります。

コンテキストも最新のLLMと比べて限られています。英語チェックポイントの入力上限は512トークンですが、他のLayaバリアントでは1,024トークンまで拡張されています。

つまり、Layaは長い文書全体をモデルに投入するよりも、選別したエビデンスに適しています。

Laya対Jev：ローカルモデルとマネージド意思決定APIの比較

LayaはオープンソースのJev代替として説明されることが多いものの、比較をベンチマークスコアだけに限定すると、より重要なアーキテクチャ上の違いを見落としてしまいます。

専門化されたLayaチェックポイントは、公開された型付き意思決定ベンチマークの1つでJevより高い精度を示しています。一方、Jevは同じ比較の一部でより優れたキャリブレーションを示しています。これだけでは、どちらかのモデルが普遍的に優れていると断定する十分な根拠にはなりません。

より大きな違いは、制御性です。

Jevは開発者にマネージドな意思決定サービスを提供します。Layaは、ファインチューニング、ベンチマーク、バージョン固定、プライベートデータのそばへのデプロイが可能なモデルの重みを提供します。

Layaは完全にローカルで実行できますか?

はい。これがLayaの最も重要な実用上の利点です。

公式モデルはPyTorchとTransformersを通じて動作します。コミュニティプロジェクトによって、すでに他のランタイムにも展開されています:

• Node.jsおよびTypeScript向けONNX Runtime;
• Apple Silicon向けMLX.

主要な421Mチェックポイントは、公開されている重み表現で1GB未満であり、一般的に有用な生成LLMの大半よりもはるかに小さいメモリクラスに収まります。

これは、メモリフットプリントに基づくモデルの振り分けという実用的な課題にLayaが適していることを示しています。受信するすべてのリクエストを分類するだけのために、大規模な生成モデルを常時稼働させておく必要はありません。

意思決定レイヤーをローカルで実行することが重要な理由

ローカル推論は、API料金を避けることだけが目的ではありません。

意思決定モデルへの入力は、機密性の高い情報であることが少なくありません:

• メール;
• サポートチケット;
• プライベートドキュメント;
• 顧客記録;
• ソースデータ;
• エージェントのトレース;
• ローカル検索結果。

ホスト型の意思決定APIは安価かもしれませんが、アプリケーションは分類のために状態をどこかへ送信する必要があります。

Layaは別のアーキテクチャを可能にします:

これは、保存データの近くで行うローカルAI処理が重要である理由と同じです。最初の判断をデータのそばで行えば、ネットワークへの露出と不要なクラウド推論の両方を減らせます。

Layaは大規模モデルの前段フィルターになり得る

最も強力なアーキテクチャは、LLMではなくLayaかもしれません。

次のような場合があります:

ローカルに10,000件の記録があるプライベートなドキュメントシステムを想像してください。最先端モデルが10,000件すべてを深く読み込む必要はありません。

小規模なローカルモデルがまず次のように問いかけます。

• これは関連性がありますか？
• どのカテゴリーに分類されますか？
• 機密情報が含まれていますか？
• エスカレーションするほど確信度が低いですか？

高コストの推論が必要なのは、難しい一部だけです。

NAS上のプライベートAIアシスタントは、このパターンに適した環境です。ストレージ、検索、分類、個人データをローカルに保持しながら、より難しいリクエストだけを選択的にエスカレーションできるためです。

Layaが実際に変えること

ここ数年、AIアーキテクチャはますます汎用的なモデルへと進んできました。1つのモデルで、推論、コーディング、執筆、分類、検索、ツール呼び出しまで行うというものです。

Layaは正反対の考え方を示しています。

モデルがより一般的になるのではなく、より専門化されることで、いくつかのタスクは改善される可能性があります。

システムが次のような何百万件もの判断を必要とする場合：

関連性がありますか、それともありませんか？

安全ですか、それとも危険ですか？

A、B、Cのどれに振り分けますか？

続行しますか、それともエスカレーションしますか？

その場合、ローカルの421M意思決定モデルは、最先端のLLMとはまったく異なる経済性とプライバシーの層を担うことができます。

したがって重要なのは、Layaがあらゆる面でJev、Claude、Gemini、GPTを上回れるかどうかではありません。

できません。

より有用な問いは次のとおりです。

AIワークフローにおける意思決定のうち、そもそも生成モデルを必要としなかったものはどれくらいあるでしょうか？

「たくさん」と答えるなら、小規模なローカル意思決定モデルは、実用的なAIインフラに欠けていた層の1つになるかもしれません。