Bosunとは何をするモデルか
今回取り上げるのは「Bosun」というモデルです。ナレッジグラフのエッジを判定するための、小さな判定モデル、いわゆるジャッジモデルです。
一番小さいXSサイズで0.6ビリオンと、かなり小さなモデルになっています。手元のMacでも動くようなサイズ感です。
ただ、このモデルが面白いのは小ささだけではありません。自分の意見で判定するのではなく、渡されたルールに従って判定するという、汎用的な方向を目指している点です。
ある二つの事実を見たとしても、あるルールだとつなぐ。ただ、別のルールだとつながないみたいな切り替えを、自然言語で指示することができるんですね。
なぜ記憶に判定器が必要なのか
なぜこれが嬉しいのか。LLMエージェントに記憶を持たせるときは、何を覚えるかだけでなく、何と何を結びつけるかが重要になってきます。
Bosunは、この「結びつけていいのか」を判定するモデルです。
記憶の中でも、特にナレッジグラフに着目しています。会話や作業ログから取り出した事実をノードにして、ノード同士の関係をエッジで張るような形です。
こうしておくと、プレーンテキストの検索やベクトル検索といった通常のRAGよりも、関係をたどりやすくなります。「この人はこれに関係する」「このエラーに関係する処理はこれ」といった探索がしやすくなるのです。
増えすぎるエッジという落とし穴
ただし、気をつけなければいけない点があります。エッジを増やしすぎないことです。
ナレッジグラフを作るとき、エッジはとても簡単にできてしまいます。これとこれを紐付けようと思えばエッジになるので、間違ったエッジも簡単に増えてしまうのです。
例えば、二つのメモが同じ単語を含んでいる。これだけでエッジとしてつないでいいのか、という問題があります。つないでいい場合もあれば、ダメな場合もあります。
この判定を雑にやると、ナレッジグラフはどんどんノイズで埋まっていってしまいます。
さらに怖いのは、間違ったエッジが忘れた頃に効いてくる点です。検索時に関係ない情報を引っ張ってきて、それが連鎖していきます。
またその改良プロセスみたいなところで、そこをさらに含めた上でエッジが作られるので、どんどん悪化していく、汚染されていくような感じになっちゃうんですね。
だからこそ、エッジを張るときはしっかり判定しなければいけません。Bosunは、この処理を担おうとしているモデルです。
「オプションフリー」という考え方
Bosunのキーワードは「オプションフリー」です。
判定モデルは、通常のLLMにさせることも一般的です。その場合は「この二つの文章は関係ありますか？」のように聞くのが主流です。
ただ、ナレッジグラフのエッジ判定では困ることがあります。「関係ある」の定義が、アプリケーションによって違ってしまうのです。
同じトピックなら接続したいアプリもあれば、同じトピックだけでは接続せず、具体的な事例を共有しないと接続しないアプリもあります。
ジャッジに求めたいのは、どう関係あるかみたいなシンプルなものではなくて、このルールでどうですか、YesですかNoですかみたいに判断するというところになります。
Bosunは、ここを自然言語のインストラクションという形で判断できるようにしています。
もちろんLLMでもプロンプトを調整すれば実現できます。ただ、ナレッジグラフは大量のデータを扱うため、APIの費用や処理時間がネックになります。
Bosunの具体的な挙動
ここからは、具体的な挙動を見ていきます。BosunはQwen3リランカーをベースにしたモデルで、LoRAでファインチューニングされています。使い方は生成モデルというより、リランカーに近い形です。
プロンプトにはinstruction、query、documentを入れます。instructionには「このルールでこのエッジをつないでいいですか」という判定ルールを書きます。
queryは「二つの候補が指定された関係を共有していますか」という固定の問いです。document部分には候補を二つ並べます。
ここが肝ですが、モデルに長い文章を生成させるわけではありません。最終位置でYesとNoのロジットスコア、つまり生のスコアを取り出します。
YesのロジットからNoのロジットを引き、それをシグモイドに通します。こうすると、Yesらしさのスコアを出せます。
一回フォワードすればスコアが出る。ナレッジグラフを構築するときに大量に回さなきゃいけないとなった時に、一回フォワードだけでいいのはすごいメリットがあるんじゃないかなと思います。
WarrantBenchでの評価と注意点
では、これはちゃんと使えるのか。ここで「WarrantBench」というベンチマークが出ています。Bosunの作者たちが公開しているベンチマークです。
このベンチマークが面白いのは、正しいエッジを一つのラベルに固定していない点です。候補A、候補Bに対して、さらにルールが付与されています。
同じ候補A、候補Bでも、ルールが違えばエッジとして張ってよかったり、いけなかったりします。
ルールで結果が分かれる問題は、ほぼ正解できない結果になっていた
大体9割ぐらいの精度で、こうした判定にも成功できる結果になっていた
結論から言うと、Bosunはすごくいいモデルだと感じられます。ただ、これを使えばOKというわけでもないと話されています。
WarrantBenchはBosunの作者たちが作ったベンチマークなので、外部タスクにそのまま一般化できるとは限りません。そこは注意が必要です。
それでも、0.6ビリオンのモデルが自然言語のルールに従ってエッジ判定を切り替えられるのは、かなり面白い方向だと考えられます。
グラフ構築のたびに大きなLLMへ「関係ある？」と聞くのはコストが高く、ローカルでない場合はAPIのバージョン変更で基準が変わることもあります。
まとめ
Bosunは、渡されたルールに従ってナレッジグラフのエッジ判定を切り替える0.6Bの小型ジャッジモデルです。低コストで運用でき、記憶を持つAIエージェントの発展方向を示すモデルだと語られました。
- Bosunはナレッジグラフのエッジを判定する0.6Bの小型ジャッジモデル
- 自分の意見ではなく、渡されたルールに従って判定を切り替える「オプションフリー」が特徴
- Qwen3リランカーをベースにし、一回のフォワードでYesらしさのスコアを出せる
- WarrantBenchでは約9割の精度だが、作者製ベンチのため外部タスクへの一般化は要注意
- 低コストで不変のローカルモデルを持てる点が実運用上のメリット
- 再現実験のコードはZennにまとめられ、概要欄のリンクから参照できる