非ベクトルAgentic Searchの検証 〜モデルサイズによる比較〜

どうも、soda エンジニアの國田です。

皆さん、毎日プロテイン飲んでますか？

私は常に肌身離さずプロテインを持ち歩いています。
仕事用のバッグの中には常に3kgほどのプロテインが入っており、会議中でも、開発中でも、出張中でも、いつでもプロテインを摂取できる体制を整えています。仕事のパフォーマンスを最大まで高めるためには、まず血中プロテイン濃度を切らさないことが重要です。

そうそう！プロテインと言えば、前回、プロテインの商品データを対象に、ベクトル検索を使わないAgentic Searchで商品レコメンドができるのかを検証しましたね。
非ベクトル利用のAgentic Searchは、『検索対象のデータが綺麗に整理されている』という条件付きではあるものの、ベクトル化などの前処理を必要とせずに、エージェントが文脈把握と検索を高精度で実現してくれるということがわかっています。

ただ、ここでもう1つ気になることがあります。
上述のように『ドキュメントが整理された条件』であれば、小規模モデルでも精度の高い回答を生成できるのでしょうか？

Agentic SearchはあくまでもAIエージェントに自律的な検索を任せる仕組みです。つまり、「どの情報を見に行くか」「見つけた情報をどう整理するか」といった判断はベースとなるLLMに委ねている状態で、精度部分も実際には、LLMの性能に依存している筈ですよね？
「もっと小さいモデル...例えば、GPT-5.4-nanoや、GPT-OSSのようなローカルモデルでも十分な性能を発揮できるのか？」といった点は多くの人が関心のある点ではないでしょうか？

さぁ、やってみよう

方法

と言うことで、論より証拠。実験してみることにします。
前回同様、プロテインレコメンドAIに使う商品データを用意します。
実在する商品ではなく、架空のプロテインとして、以下のような商品詳細情報を作成しました。

こちらのデータは、"P001_朝霧ホエイ_チョコレート.md"という名前で保存します。
同様の形式で、25種類のプロテインのデータを作成しました。以下、用意したダミーデータの一覧です。

また、Agentic Searchで利用できるよう、索引用のフォルダを構成します。

同じ `.md` ファイルが、複数のフォルダに登場していますが、これは意図しているもので、配置そのものを検索インデックスとして機能させる工夫です。
たとえば「チョコレート系で、乳成分を含むプロテイン」を探したい場合は、味/チョコレート系 と 体質・食事制限/アレルゲン/乳成分 の両方に登場するファイルを確認すれば良いわけです。
（より詳しい説明が知りたい方は、前回の記事を参照ください。）

検索処理

検索方法は、以下の手順で実施します。

① ユーザーの希望条件と索引フォルダを照合する
まず、ユーザーがLLMに質問します。
その質問文をもとに、LLMが索引フォルダの一覧から、「どのフォルダを見るべきか」照合します。
たとえば「チョコレート味の安いプロテイン」という質問では、以下のようなフォルダが候補になります。
・味/チョコレート系
・価格/低価格帯
この段階では、まだマスターデータは読みません。あくまで、どの索引を見るべきかを選ぶだけです。

② 複数の索引フォルダに含まれる製品ファイル名を比較する
次に、選択された複数の索引フォルダに含まれるファイル名をリストアップし、比較します。
ここで、もし同一のファイル名が複数の索引フォルダに出現する場合、その製品は複数のユーザー条件に対応している可能性が高いとみなせます。
完全一致する製品が存在しない場合は、より多く出現する製品を優先します。

③ 候補製品の正規データを読み込む
最後に、手順②で得られた候補のうち、優先度の高い最大5件をLLMが選定した上で、マスターデータを読み込み、実際の回答を生成します。

以上の検証をモデル別に実施します。
今回は、以下のモデルで比較しました。

• GPT-5.4: 大規模サイズのOpenAI製言語モデル
• GPT-5.4-nano: 上記、GPT-5.4を小規模化した最小のモデル。
• GPT-OSS-20b: OpenAIが公開しているローカル向けの小規模言語モデル

結果

では早速ですが、結果に移りましょう。
まず、以下の質問を投げてみます。

Q. 低糖質でタンパク質が多いものを探している

想定している答えは、「P022_高タンパク質チョコアイソレート.md」と「P019_無糖プレーンアイソレート.md」です。
それぞれのモデルの答えを以下に示します。（なお、回答中で想定通りのプロテインには黄色いマーカーを引いてあります。）

いずれのモデルにおいても、想定していた回答を提示することができていますね。
他の質問もしてみましょう。

Q. おいしくて水に溶けやすいチョコ系が欲しい

ここで、想定している答えは、「P001_朝霧ホエイチョコレート.md」もしくは「P022_高タンパク質チョコアイソレート.md」です。『水に溶けやすいプロテイン』とはホエイプロテイン系統に代表されており、今回の実験では、「種類」ディレクトリから「ホエイ」「ホエイアイソレート」の索引を辿れば導出できます。

GPT-5.4およびnanoはきちんとホエイプロテイン2種類を提示できていましたが、GPT-OSS-20bのみ、「朝霧ホエイ チョコレート」に関する記述は見られませんでした。
実際にGPT-OSSが検索・閲覧したファイルを確認してみましょう。

P024_南国マンゴークリア.md
P022_高タンパク質チョコアイソレート.md
P020_低価格チョコスタンダード.md
P016_白桃クリアホエイ.md
P004_透明柑橘クリア.md

おや？「朝霧ホエイ チョコレート」が含まれていませんね？
逆に多くヒットしているのは「南国マンゴークリア」「白桃クリアホエイ」「透明柑橘クリア」など、「クリア」という文字が商品名に含まれているプロテインです。OSSのみ、他の2つのモデルとは違う検索の挙動をしていたことになります。

それでは、次の質問にいってみましょう。

Q. お腹がゴロゴロしにくいプロテインが欲しい。でも、価格は抑えたいです。

一部の乳由来プロテインは、乳糖が含まれます。乳糖は人によってはうまく消化しにくく、腹痛などが起きることがあります。そのようなケースでは、ホエイアイソレートやソイプロテインなど乳糖不使用の製品が候補になります。

つまり、この質問では、AIが以下のような意味的な変換をしつつ、さらに「価格は抑えたい」という要求を汲み取り、低価格なプロテインを提案する必要があります。

　お腹がゴロゴロしにくい = 乳糖不使用、または乳由来ではないもの

果たして、うまくいくでしょうか。想定している回答は「きなこ大豆ライト」および「黒ごま大豆プロテイン」です。

GPT-5.4やnanoではキチンと正解を提示しているのに対し、GPT-OSS-20bでは、大豆プロテイン系を一切提示できていません。代わりに提案されたのは「乳糖不使用だが高価格」もしくは「低価格だが乳糖使用している」製品(補足: 低価格チョコスタンダードは乳糖使用している製品)であり、ユーザーの提示した条件に対して、いずれの提案も片手落ちです。
また、回答の特徴として、お腹のゴロゴロを「糖質が原因」として捉えている点も気になりますね。確かに「糖質が原因でお腹に不調が出る」という主張は一定数存在します。ただ、今回はプロテインの文脈ですので、一般には「乳糖」で解釈するのが妥当と言えるでしょう。

考察

今回の結果を見る限り、モデルによって明らかにAgentic Searchの性能に変化がありました。回答自体の質もあるのですが、これは予め予想していた点ではあります。それよりも遥かに【検索行動】と【検索内容】の変化が大きいです。
特に、質問が抽象的であればあるほど、ローカルモデルの検索行動は本来あるべき検索水準から外れていくのが目に見えました。
質問を順番に振り返ってみましょう。

まず最初の、「低糖質でタンパク質が多いものを探している」という質問では、3つのモデルすべてが想定通りの候補を提示できていました。

この質問は、比較的分かりやすい条件です。「低糖質」と「高タンパク」は索引用のディレクトリにも「栄養成分」という項目ありますし、商品データ内の数値項目にも直接対応しています。モデル側でユーザーの意図を解釈したり、意味を違う言葉に変換する必要性が殆ど無い質問であるとも言えます。そのため、GPT-OSS-20bでも正しく候補を取得し、回答を生成できたと考えられます。

次の「おいしくて水に溶けやすいチョコ系が欲しい」では、GPT-5.4とGPT-5.4-nanoは、想定していた「朝霧ホエイ チョコレート」と「高タンパク質チョコアイソレート」を候補として提示できていました。
一方で、GPT-OSS-20bは「高タンパク質チョコアイソレート」は提示できたものの、「朝霧ホエイ チョコレート」には辿り着けませんでした。この条件では、まず「水に溶けやすい」ということでホエイプロテイン、そして「チョコ系」のプロテインを抽出する必要がありました。しかし、GPT-OSS-20bが実際に検索したファイルを確認すると、チョコ系だけでなく、「クリア」という文字列が商品名に含まれるプロテインも候補に含めていました。

つまり、GPT-OSSには、「水に溶けやすい＝ホエイ」という認識がそもそも無かった可能性があります。その代わりに「クリア」といういかにも水に溶けやすそうな名前のものを中心に取り扱ってしまったのではないでしょうか？

最後、大きく差が出たのは、「お腹がゴロゴロしにくいプロテインが欲しい。でも、価格は抑えたいです。」という質問でした。こちらも前問と同様、ユーザーの表現をそのまま検索条件にするだけでは不十分で、「お腹がゴロゴロしにくい」という表現を、商品データ上の属性に変換する必要があります。

GPT-5.4とGPT-5.4-nanoは、この変換を行ったうえで、比較的価格の安い「きなこ大豆ライト」や「黒ごま大豆プロテイン」を提示できていました。
一方で、GPT-OSS-20bは「お腹がゴロゴロしにくい」という条件を、乳糖ではなく「糖質や炭水化物が少ないこと」と解釈していました。その結果、低糖質な「無糖プレーンアイソレート」や、価格が安い「低価格チョコスタンダード」を候補に挙げ、結果的にユーザーの意図とは異なる回答を生成していました。

つまり、こちらもモデル特有のコンテキスト理解力、ユーザーの意図に対する解釈性の問題と言えるでしょう。

Agentic Searchでは、検索対象となるデータを整備することで、LLMが正しい情報に辿り着きやすくなります。
しかし、検索対象をどれだけ整理しても、ユーザーの自然言語を正しい検索条件に変換できなければ、見るべき索引を間違えることが考えられます。

今回の例で言えば、

• 水に溶けやすい = クリア
• お腹がゴロゴロしにくい = 低糖質

など、解釈の方向性から間違っているために、結果として、見るべき索引フォルダやファイルが変わり、最終的な候補も変わってしまいます。GPT-5.4-nanoは、小型モデルでありながら3つの質問すべてでおおむね期待通りの候補を提示できていた点から考えると、Agentic Searchにおいてモデル差が出やすいのは、索引の作り方よりも、曖昧な自然言語を検索条件に変換する場面だと言えそうです。

nanoで性能が発揮できていた以上、検索対象が整理され、索引フォルダの意味が明確であれば、小型モデルでもAgentic Searchを実用的に動かせる可能性はそれなりにあります。ただ、ローカルモデルやOSSモデルを使う場合は、モデル特有のコンテキスト変換の癖を把握していた上で対応する索引インデックスの整備を進める方向性が良さそうですね。
今回の場合ですと、「水の溶けやすさ」などのインデックスを与えておくと検索性能が向上するように思います。（そのような逐次的なチューンナップができるのも、Agentic Searchの利点ですね。）

まとめ

いかがでしたか？今回は、プロテインの商品データと索引フォルダを使い、gpt-5.4、gpt-5.4-nano、gpt-oss-20bでAgentic Searchの結果を比較しました。

Agentic Searchにおけるモデル性能は、最終回答そのものよりも、むしろ探索行動そのものに表れます。

小型モデルでも、質問文とフォルダ構造の整理がきちんと噛み合っていれば、十分に機能する場面があります。
一方で、曖昧な質問や、モデルによる解釈が必要な表現が質問文に含まれている場合には、より高性能なモデルの方がファイル探索は安定して働くことがわかりました。単に「一番大きいモデルを使うこと」も勿論、戦略としては否定しませんが、「その検索タスクに対して、適切に効くモデルや設計を選ぶこと」が構築において重要な意味を持ちそうです。

そういった意味では、RAGの世界も筋トレと同じかも知れませんね。
大胸筋をデカくしたいからといって、必ずしもベンチプレスだけが正解とは限りません。ダンベルプレスの方が効く人もいれば、マシンの方が安定して追い込める人もいます。
Agentic Searchは、ユーザーの言葉を正しい検索条件に変換し、見るべき索引にきちんと辿り着けるかが重要だと言えるでしょう。

ではまた！