公開モデル Laya は Jev に追いつくか：SQL 14 問中 6 問から 3.9 時間の追加学習で検証

日本語ナレーション · 720p · 字幕トラック付き · MP4

記事：Laya をファインチューニングしたら、SQL 安全判定が 7/14→14/14 に

AIを仕事に組み込むとき、長い説明よりも「どれを選ぶか」だけを返してほしい場面があります。たとえば、届いた問い合わせを営業とサポートのどちらに回すか、といった判断です。

こうした判断に特化したAIが、JevやLayaのような「決定モデル」です。文章を生成する代わりに、用意した選択肢や、その確率を返します。

Jevは、外部のサービスをプログラムから呼び出して使います。一方、Layaはモデルが公開されていて、手元のパソコンでも動かせます。用途に合ったデータでさらに学習させる「ファインチューニング」ができる点も特徴です。

今回は、データベースを操作する命令であるSQLを題材にしました。LayaにSQLの判定例を教えたら、どこまで改善するのか。Jevと比べながら試してみました。

まず、何を判定してもらうのか

SQLのレビューでは、「実行して安全か」と「欲しい結果が得られるか」を分けて考える必要があります。

たとえば、削除する注文の条件を間違えたSQLは、残すべきデータまで消してしまいます。これは安全性に関わる問題です。

一方、売上を二重に数えてしまう集計は、データを書き換えなくても間違った金額を返します。こちらは、意図どおりに動くかという正しさの問題です。

この違いを見抜けるか確かめるため、正しいSQLとバグを含むSQLを合わせて14件用意しました。

まずファインチューニングなしで試すと、Layaの安全性の判定は14件中7件正解でした。比較したJevは14件すべてに正解しています。ここで使ったLayaは、公開されているモデルの一つ、typed-decisions版です。

そのままでは差がありました。では、SQLの例を与えてファインチューニングすると、結果は変わるのでしょうか。

正しい例と、間違った例を教える

今回のファインチューニングでは、SQLとその判定結果を教材にしました。

教材には、公開されているSQLのデータを使いました。元のSQLを正しい例として扱い、一部を書き換えたものを間違った例にします。

たとえば、更新する対象を絞る条件を削除します。特定の注文だけを変更するはずだったSQLが、すべての注文を変更するSQLになります。こうした例に、あらかじめ決めた規則で判定結果を付けました。

作った教材は約2,900件。そのうち一部を評価用に取り分け、残りを学習に使いました。

学習は手元のM4 Macで実施しました。教材を2周学習するのに、約3.9時間かかっています。大きな計算設備を借りずに、試せる規模でした。

安全性は改善した。でも、長く学習すればよいわけではない

学習後、最初と同じ14件をもう一度判定させました。安全性の結果は次のとおりです。

1周目で、Layaはすべてに正解しました。この14件では、Jevと同じ正解数になっています。

ただし、2周目には1件間違えるようになりました。危険なSQLを、安全と判定してしまったのです。学習時間を増やせば、その分よくなるわけではありませんでした。

また、この14件に正解したことは、どんなSQLでも安全に判定できるという意味ではありません。別のSQLでも同じように改善するかは、さらに確かめる必要があります。

「正しいSQLか」を見抜く力には、差が残った

安全性とは別に、SQLが意図どおりに動くかも調べました。

こちらは、Layaが1周目の学習後で14件中8件、2周目で10件の正解でした。Jevの13件には届いていません。

見逃した例には、日付の範囲を間違えたSQLがありました。しかもLayaは、それを高い確率で「正しい」と判定しています。迷っているときだけ人に確認してもらえば済む、という状態ではありません。

似た種類のバグを学習していても、別のSQLでは見逃す例もありました。教材の例を覚えることと、違う場面でも問題を見抜くことには、まだ隔たりがあります。

ファインチューニングの効果はありました。それでも、SQLレビューを丸ごと任せるには、確認が足りないという結果です。

Jevの企業価値は、導入の手間を抑えて試せること

この結果を、企業での使い方に置き換えるとどうなるでしょうか。ここからは、今回の実験を踏まえた導入案です。業務での効果を測ったものではありません。

Jevは、自社でモデルを学習したり、動かすためのサーバーを用意したりする前に試せます。まず業務の事例を渡し、判断がどのくらい合うかを確認できます。

たとえば、問い合わせの振り分けを自動化したい会社なら、過去の問い合わせを使って担当部署を当てさせます。その結果を、人が付けた分類と比べます。

企業にとっての価値は、モデルを運用する仕組みづくりの負担を抑え、業務に役立つかの検証に集中できることです。分類や振り分けは、Jevの公式紹介でも想定されている使い方です。

ただし、実際に任せる前には、自社の事例で精度を確認する必要があります。外部サービスへ送ってよいデータかどうかも、判断の条件になります。

Layaの企業価値は、社内で動かし、自社向けに育てられること

Layaは、入力を外部サービスに送らず、自社の環境で処理する構成を取れます。公開モデルとファインチューニングの案内は、公式モデルカードにあります。

同じ問い合わせの振り分けでも、社内独自の分類があり、過去の正解例が十分に残っているなら、それを教材にできる可能性があります。

この場合の価値は、会社ごとの判断基準に合わせて改善を試せることです。データを社内に留めたい場合にも、選ぶ理由になります。

その代わり、教材を整え、学習させ、精度を確認する仕事は自社で持つことになります。動かす設備にも費用がかかります。大量に処理する場合でも、外部サービスより安くなるかは、こうした運用費を含めて比べる必要があります。

今回なら、どう使い分けるか

まず業務で役立つかを確かめたいなら、学習や配備の準備を抑えられるJevが候補になります。自社の教材と運用体制があり、社内で処理したいなら、Layaを育てる方法を検討できます。

今回のSQLレビューでは、両方を組み合わせる案も考えられます。Layaには、十分に評価できた範囲の分類を任せる。SQLの意味を詳しく確認する段階では、Jevや人のレビューを使う、という分担です。

ただし、Layaの確率だけで「確認不要」と決めるのは難しそうです。高い確率で間違えた例があるからです。データの更新や削除など影響が大きい操作は、別途レビューに回す条件を設けます。外部に送れないSQLは、社内で確認します。

最終的に確かめたいのは、レビューの手間が減り、そのうえで見逃しを許容できる範囲に抑えられるかです。今回の14件全問正解は、その使い道を探るための一歩になりました。

実験のデータやスクリプトは jev-vs-laya にまとめています。モデル別の詳しい成績や学習条件も、こちらを参照してください。

中国語版の動画は 中文ページ。