かけあがれいろはざか！ 判断AIのJev vs. 無料オープン版のチキチキ自転車対決

　生成はせず、判断だけが可能なAIモデル「Jev」のリリースから少しして、それと似たオープンな判断AI「Ollaya」が登場しています。実際のところJevの代替になるのか、DGX Sparkで動かして比較してみることにしました。

Jev互換のオープンな判断AI「Ollaya」

　改めて簡単に紹介すると、Jevは米TypeSafe AIが開発した判断AIモデルです。従来のAIモデルは単純な1つの判断をするのにも複雑な思考を経て、返答をするための生成も必要になることから時間がかかります。が、Jevでは生成せず判断だけを行ない、高速に処理できるのが特徴です。

　プロンプトなどで指示した基準・条件をもとに、ある事柄について「イエスかノーか」（Noul）を決める処理に加えて、段階的な評価（Score）や、あらかじめ用意した複数の選択肢からの分類（Choice）という3種類の判断が可能になっています。

　そして、このJevに類似したオープンな判断AIとして「Ollaya」というものが登場しました。オープンなのでもちろん無料。APIはJev互換となっており、置き換えも簡単です。

Ollayaの公式サイト

　クラウドAPI経由の利用に限定されているJevも料金は安価ですが、Ollayaはそれに加えてローカルAIなのでプライバシー面で安心、インターネット通信の遅延が発生しないというメリットもあります。

　あとは判断の「精度」がどれくらいなのか。ですが、ここでOllayaについてもう少し詳しく説明すると、実はOllaya自体はAIモデルではありません。正確には「判断AIモデルを扱うエージェント」で、Jev互換のAPIを備えたある意味「器」です（ちなみにJevも、ユーザー側からアクセスする先はAIモデルというよりAIエージェントですから、同じではあります）。

　なので、Ollayaという器にオープンな判断AIモデルを組み合わせる、という形になります。その候補として「winnow」「laya」「decider」など数十のAIモデルが案内されており、なかでも精度が高いとされているのがwinnowで、今回はこれをDGX Spark上で動かしてみました。

判断用のAIモデルが多数用意されている

判断AIをルート選択で競わせてみよう

　winnowのモデルサイズは、判断用ということもあって比較的軽量です。モデルウェイトは主に3パターンで、4.6B／7.5B／12Bとなっています（PNG画像解析ができるビジョンモデルもあります）。ロード時の実メモリ占有量はそれぞれ約7GB／約10.6GB／約18GBでした。

winnowは基本の3モデルとビジョンモデル2種からなる

　わざわざDGX Sparkに頼らずとも済みそうなサイズですが、こういった判断AIはたいてい他のAIモデルなどと組み合わせて使うことになるでしょうから、その意味ではやはりメモリ容量が大きいほど正義であることに変わりありません。

　そんなわけで、今回2つの判断AIの性能や速度を比較するにあたっては、少しゲームチックなノリで「自転車による移動ルート選択競争」を題材にサンプル作成してみました。

　具体的には、地図上のスタート地点から2つのAIが同時に自転車で出発して、遭遇する分岐ごとに進行方向を判断（Choice）しゴール地点を目指す、というもの。どれだけ速く、有効な判断ができるかが鍵を握ります。

分岐のたびにどの方向に進むのかをその場で判断していく

　一般的なルート探索と異なるのは、最初にゴールまでのルートを探索して確定しない点です。実際に動いて次の分岐点に到達したら、そこから3～4分岐先までの道路状況や勾配、ゴールまでの直線距離など必要最小限の情報を与え、そこで直進するのか方向転換するのかを都度判断します。

　スタート前に「距離優先」や「坂道回避」といった基本的な条件を設定できるようにもしています。たとえば「坂道回避」を条件にすると、直進すればゴールに近づくけれど、急勾配があるので右左折して回り込んだ方がいいかも、というような判断が発生するわけです。

坂を登るべきか、回り道すべきか

　とはいえ、ゴールが遠ければ先を見通せず都度判断になることには変わりないので、1つ1つの分岐においては必ずしも最適解が選ばれるとは限りません。一般的なルート探索の手法と比べれば非効率で、遠回りしてしまう可能性も大いにありえます。

　けれど、うまくチューニングできれば自転車や徒歩の簡易的なルート案内ツールとして使えるようになるかも、なんて思ったりもします。DGX Sparkを持ち運ぶわけにはいきませんが。

同じプロンプト・情報を渡して、速さと判断の的確さを競う

　さて、舞台は東京多摩地区、ジブリ映画の舞台にもなった聖蹟桜ヶ丘駅付近としました。サイクリストにとってはちょうどいいヒルクライムルート「いろは坂」があります。なので、Webアプリのタイトルも「かけあがれいろはざか」としました。

判断AI比較用Webアプリ「かけあがれいろはざか」

　ちなみに今から26年ほど前の2000年頃に「まさしくんハイ!」というWindows用のアクションゲームがリリースされました（今もダウンロードできます）。そのなかの1ゲームモードが、棒人間がひたすら疾走する「かけぬけろどうげんざか」。タイトルはそれにインスパイアされたものになります。

　筆者としては、当時の個人開発ゲームのなかで屈指の名作だと思う……というのは完全に余談ですが、そうこうしている間にプログラムができあがったので、さっそく2つのAIに競争させてみましょう。

　スタート地点は聖蹟桜ヶ丘駅前。そこからいろは坂のある丘の先、少し下ったところをゴールに設定しています。「距離優先」と「坂道回避」の2パターンで実行しているので、前者ならまっすぐいろは坂を登るかもしれませんし、後者なら遠回りしてゴールに向かうものと思われます。

スタート（S）は駅前とし、丘の向こう側にゴール（G）を設定

「距離優先」で移動する場合の参考ルート。これは一般的にルート探索で用いられる双方向ダイクストラ法によるもの

「坂道回避」の参考ルート。いろは坂は登らず回り道することになる、はず

　各判断AIに渡すプロンプトや条件は、各分岐点においては完全に同一なので、純粋にAIモデルの判断の違い（と処理速度）が差として現われます。ゴール時には移動距離や平均時速15kmで走行した場合の想定走行時間、API呼び出しの回数、APIの通信にかかった平均・合計時間などを表示します。

　先にゴールした方が、「総合的に処理が高速で判断も的確」と言えるでしょう。ただし、現実での移動も考えた場合には、最終的に走行時間と距離が短いほうがうれしいので、処理が遅くても判断の的確さが重視されるところもあると思います。

どちらか先にゴールするのか。かけあがれ（あがるな）いろはざか！

　では、その様子を動画でご覧ください。移動は80倍速にしているので（たぶん）サクッと終わります。

　結果は、モデルウェイトによって差は変化したものの、いずれもJevが先にゴールしました。Ollayaで最も軽量なwinnow:e2b（4.6B）を選んだ場合、迷走の度合いがやや強く、ゴールはできるものの「坂回避」ではJevの2倍近い時間・走行距離になりました。

　winnow:e4b（7.5B）ではかなり遠回りになってしまうことが多く、winnow:12b（12B）だと改善が見られるものの、「坂回避」では堂々と坂を駆け上がることも。

「距離優先」（Ollaya winnow:e2b）の結果

「距離優先」（Ollaya winnow:e4b）の結果

「距離優先」（Ollaya winnow:12b）の結果

　先にゴールしたことからもわかる通り、判断速度はJevに軍配が上がります。Jevは平均API処理時間が安定して0.3秒前後で、どんどん分岐を通過していきます。

　一方、Ollayaはe2bで0.7秒前後、e4bで1秒以上、12bで3秒近くかかり、あっという間に置き去りです。推論だけでなく通信も含む時間なので、インターネットを経由しているJevは推論がかなり高速であることがわかります。

「坂回避」（Ollaya winnow:e2b）の結果

「坂回避」（Ollaya winnow:e4b）の結果

「坂回避」（Ollaya winnow:12b）の結果

　Jevも迷走することはありますし、結局素直にいろは坂を登ってくれなかったのですが、そのミスを速度でカバーしているようなイメージ。

　反対にwinnow:12bにしたOllayaは判断こそ遅いものの、1つ1つ丁寧に行き先を決めて少ない手数と距離でゴールしています。トータルでは距離、API呼び出し、想定走行時間の項目でOllaya（winnow:12b）が優秀でした。

時間をかけていいならOllaya、高速・高精度が必要ならJevを

　判断AIを実用することを前提にした場合、今回のサンプルを使った結論としては、1つの判断に時間がかかってもいいならOllaya（winnow:12b）を、高速かつ精度高く判断したいならJevを、ということになるでしょうか。

「進むべきルートを決める」といったようなタイムラグが気にならない用途なら2秒以上かかるOllayaでも問題ありませんし、24時間判断させ続けてもコストゼロです。しかし、大量の事柄をできるだけ的確に、高速に判断していく必要があるならJevを使うのが無難と思われます。