ポケモン博士と学ぶAssistants API File search
こんにちは、ニケです。
今回はAssistants APIのアップデート（v2）で追加された File search について深堀りしていきたいと思います。
Assistants APIとは、
アシスタント API を使用すると、独自のアプリケーション内で AI アシスタントを構築できます。アシスタントには指示があり、モデル、ツール、ファイルを利用してユーザーのクエリに応答できます。アシスタント API は現在、コード インタープリター、ファイル検索、関数呼び出しの 3 種類のツールをサポートしています。
とりあえず、これを使えば簡単にLLMアプリにAIエージェントを実装できる、という理解で良いと思います。
File searchとは、
ファイル検索は、独自の製品情報やユーザーから提供されたドキュメントなど、モデルの外部からの知識でアシスタントを強化します。 OpenAI は、ドキュメントを自動的に解析してチャンク化し、埋め込みを作成して保存し、ベクター検索とキーワード検索の両方を使用して関連コンテンツを取得してユーザーのクエリに答えます。
つまり、File searchはAssistants APIにおけるRAGに相当する機能だと思ってください。
というわけで、今回はこのRAGの性能を調べていくことにします。
ちなみに結論を先に述べると、ちょっと微妙かなといった印象です。
設定
今回は「ポケモンについて何でも答えてくれるポケモン博士」という設定のAssistantを作成します。
想定として、Discordなどに常駐し、雑談に加え、ポケモンのことを聞いたら何でも答えてくれるbotとして実装することとします。
設定はシンプルに以下のようにしました。
これらは全てOpenAIのコンソール上から実行できます。
なお、File searchに設定されているpokemon_listは、2024年4月現在で公式発表されている全ポケモン（1000対以上）の番号と名前とタイプが記載されたテキストファイルです。
検証
ではこの博士Assistantに質問を投げていきます。
同じくOpenAIのコンソール上で行います。
まずはジャブ。
File searchを使用せずに回答できました。
ちなみに、File searchを使用したかどうかは下記のようなテキストが表示されるので簡単に見分けがつきます。
次はちょっとマイナーなポケモンについて聞いてみましょう。
ナゲツケサルは格闘単タイプなので盛大にハルシネーションしてますね。
今回もFile searchを使用していませんでした。
ちなみに、サルノリの最終進化形はゴリランダーです。
ピカチュウのタイプは一般常識なので問題ないですが、マイナーなポケモンについてはちゃんとFile searchを使用して欲しいところです。
すこし工夫してみます。
1．ポケモンと明記する。=> 検索しない => ハルシネーション
2．丁寧に質問にする。=> 検索しない => ハルシネーション
3．念押しする。=> 検索しない => ハルシネーション
ちなみにこの説明は相方ポケモンのヤレユータンのものです。
4．調べて欲しい旨を伝える。=> 検索しない => ハルシネーション
5．検索して欲しい旨を伝える。=> 検索する => 正答
「検索」という単語に反応している…？
なかなか使いづらい仕様ですね。博士なら検索しないで答えて欲しいものです。
個人で使う分には「そういうものか」と覚えておいて都度メッセージに「検索」という文字を含めれば良いですが、不特定多数が属するDiscord botで使用するのはちょっと使いづらそうです。
どうにかできないか模索します。
上記の理由からユーザコメントでは制御したくないので、必然的にAssistantに設定を変更することになります。
Instructionsにポケモンのことを聞かれたら必ず検索するように設定を付け加えました。
（博士なのに検索してから答えるのってちょっとイヤですね）
1．普通に聞く。=> 検索しない => ハルシネーション
回答自体はポケモンの質問だと理解できているようですが、質問した時点ではそうだとは認識していないかもしれません。
2．ポケモンと明記する。=> 検索する => 正答
惜しいところまでできましたが、1つ目の時点で正答していないと博士botとしては落第点です。
もう少し頑張ります。
今度は何を質問されてもとりあえずファイル検索してもらうことにします。
いけました。
とはいえこのやり方は問題があります。
まず1つ目に、応答速度です。
都度検索が入るのでどうしてもレスが遅くなります。
次に、費用です。
検索をしているかどうかでトークン数が大分違うのがわかると思います。
とにかく無駄が多い構成なので、どの質問にも検索をかけるのはやはりナンセンスです。
ではどうすればいいでしょうか？
個人的にはこのようなフローが良いかなと思っています。
一度RAGが必要かを判断するわけですね。
この判定にもLLMを実行する必要がありますが、費用は抑えられるかと思います。
精査できてないので（いつも使う言い訳）甘いところがあるかもしれませんが、都度検索させるよりかは良いかと思います。
5/1 追記: 同じような考え方の論文が発表されていたので、解説記事を共有しておきます。
結論 => 微妙かも
で、じゃあこれをAssistants APIでどう実装するのか？ということですが、できません。
RAG要不要判定Assistantを追加して、Assistant2人体制にすればいけるかもしれませんが、そこまでするなら別にAssistants APIを使用する理由はないんじゃないかとも思えます。
また、実はRAGにはいろいろな拡張手法があり、用途に合わせて適切な手法を選択するのが良いのですが、もちろんそれもできません。
というわけで、結論 個人的にはAssistants APIのRAG機能はまだちょっと微妙かな？、という判断に落ち着きました。
Assistants APIはV2アップデートでかなり便利な機能が増えたので、今後のアプデ次第ではFile search機能ももっと使いやすくなるかもしれませんね。
この記事が気に入ったらサポートをしてみませんか？