Laya覚書

第3回で書いたとおり、Jev は $0.042 / 100万入力トークンの API です。Laya は課金がない代わりに、GPU と運用と学習の手間を自分で持ちます。同じ「判定モデル」でも、引き受けるものがまるで違います。

Laya の開発元 ConvAI Innovations の CEO、Nandakishor M 氏は、「自分は1年半前からこれをやっていた」と主張しています。まず事実を並べます。

確かに、「文章ではなく確率を返す」も「確信度で振り分ける」も、Jev の公開より1年以上前に同じ人物が論文として出しています。第3回で「賢い if 文」と紹介した考え方の部品は、先に世に出ていたわけです。

そもそも System 1 / System 2 という言い分けは認知科学の枠組みで、どちらの発明でもありません。同じ時期に同じ着想が別々に出てくるのは、この分野ではよくあることです。先行研究が実在することと、模倣があったことは、別の話です。後者は主張であって、確かめられた事実ではありません。TypeSafe 側はこの件に公に応じていません。

経緯として面白いのは、オープンソース側が論文・重み・学習データを出しているという点です。検証できる形で出ているからこそ、次章以降のように中身を確かめられます。

Laya の学習で押さえるべきは三つです。土台・仕掛け・報酬。

① 土台 ── ゼロから作っていない

Laya は既存の公開エンコーダ（ModernBERT-large など）から始めています。しかも 第1回で扱った GPT 系＝左から右へ書くモデルではなく、BERT 系＝前後を同時に見る双方向エンコーダです。文章を書く必要がないのだから、書くための構造も要りません。

② 仕掛け ── 選択肢の数だけ穴を開ける

state と質問を並べ、選択肢の数だけ [MASK] を置きます。双方向エンコーダは各穴の位置に「そこに入るのはどれくらいもっともらしいか」を集めるので、1回の前向き計算で複数の質問にまとめて答えられる。これが速さの正体です。第1回・一章の「一語ずつ」の繰り返しが、そもそも存在しません。

③ 報酬 ── 正直な確率に点を与える

学習は RLCD（較正された判断のための強化学習）。当たり外れだけでなく、確率が正直かどうかを採点します。使われているのは対数スコア・球面スコア・ランク確率スコアの組み合わせで、いずれも盛っても薄めても損をする性質を持つ採点法です。

公表されている学習量は7,313更新・1エポック・約1.96時間。桁を間違えているように見えますが、そうではありません。土台がすでにあるからです。

素のモデルは、多数派を答え続けるより弱い

モデルカードに書かれている素のチェックポイントの精度は 0.362。同じ評価の多数派ベースライン（すべて最多ラベルで答える）は 0.461 です。つまり何も考えずに一番多いラベルを返したほうが当たる。開発元自身が「Laya は特化させるための速い土台であって、ゼロショットの判定エンジンではない」と明記しています。

確信度も同じです。出荷時の期待較正誤差（ECE）は 0.466。確率としてほぼ機能していません。温度を合わせ直すと 0.081 まで下がりますが、その作業は使う側の仕事です。

使う側が引き受ける作業

• ラベル付きデータを数千件用意する ── ここがいちばん重い
• 開発元のノートブックで追加学習 ── 無料GPU 2枚で約4時間
• 温度の再フィット ── 質問型と選択肢数の組ごとに当てはめ直す
• 選択肢は20個以下に抑える設計にする（増えると目に見えて落ちる）
• 言語・文字種で使うチェックポイントを振り分ける Router を前に置く

つまり、「3日で出た」のは土台であって、判定器ではありません。モデルを作る部分は確かに軽くなりましたが、重さは消えたのではなくデータと較正の側へ移った、というのが実態だと思います。

この件でいちばん勉強になったのは、同じモデルの数字が出どころによって別物になるということでした。

ECE は出どころによって優劣が逆転しています。精度も、選択肢が77個ある課題では立場が入れ替わる。前回 Jev の「193.6倍速い」がベンダー自社評価だと書きましたが、オープンソース側の数字も同じように自己申告です。

「軽いからローカル」と考えたくなりますが、判断軸はもう少し具体的です。まず費用から。

ある試算では、1判定800トークン・東京リージョンの T4 を1枚・運用0.2人月という前提で、損益分岐点は月5,260万件でした。これを下回るなら API のほうが安い。問い合わせの振り分け程度の量では、まず届きません。

ローカルが効く条件

• データを外に出せない ── 医療・金融・行政など。これは量に関係なく効きます
• オフラインで完結させたい ── 重みを一度落とせば、通信なしで動きます
• 遅延の下限を下げたい ── 往復のネットワークが消えます
• 同じ判断を大量にくり返す ── 全取引の不正検知、UGC の常時監視など
• ラベル付きデータが手元にある ── 追加学習の材料がすでにあるなら、持つ意味が出てきます

手元でどれくらい動くのか

Apple Silicon 向けの Core ML 版では、M3 Max の Neural Engine で P50 4.98ms、1判定あたり 0.154 ジュール。同じ機械の MLX 版に比べて速度は1.39倍ですが、電力は2.78倍良いという結果が出ています。バッテリー駆動の端末で常時判定させるなら、この差のほうが効きます。

ただし Neural Engine 版は合計96トークンが上限です。state をそこに収める設計が要ります。Node.js から ONNX Runtime で動かす実装もあり、置き場所の選択肢自体は広がっています。

結局どうするか

④ が現実的だと思います。API で動くものを先に作ると、そのログがそのまま追加学習のラベルになります。順番として素直です。