RAG の調整は難しい
先日リリースした「ヤマシンAI」ですが、ここ2週間ぐらい、ずっとチューニングをしていました。
RAG の活用ではチューニングが重要といわれていますが、実際やってみると本当に調整が難しい。
理想の回答を得るためには、RAG からのデータ抽出やプロンプティングの調整など、様々な要素のバランスをとる必要があり想像以上に大変でした。
ひとまず、多少のチューニングはできたので再リリースしましたが、今後もきっと調整が必要になることでしょう。
一応、どのようなチューニングを行ったか記しておきましょう。
まず、これまでは「FAISS」というライブラリの「similarity_search」関数を使い、シンプルにデータの類似度を算出していました。
しかし、これだけでは不適切なデータを参照してしまったり、かなりの頻度でハルシネーションが発生していたため、実運用にはかなり問題がありました。
そこで、これを次のように変えました。
- 質問文とベクトルDB内のデータのコサイン類似度を算出
- 質問文から抽出したキーワードによる、ベクトルDB内のデータの全文検索
- ベクトルDB内のデータの日付（記事の公開日）によるスコアリング
これらの要素を『適度な比率』で組み合わせることで最終スコアを算出し、そのスコア上位10件を要約整理して回答を生成するようにしました。
加えて、回答を要約整理する API のモデルも変更しました。
具体的には、これまで「gpt-4.1-nano」を使用していところを、一部「o4-mini」へ変更しました。
この変更は、ハルシネーションに対してはかなり効果的で、回答結果が大きく改善しました。
まだ完璧とは言えませんが、だいぶ私の考える回答に近づいた気がします。
また、回答を作成するうえでは、『生成AI の API をどれぐらい使用するか？』も重要な要素です。
理由は簡単、使うほどにお金がかかるからです。
ベクトルDBの作成には、オープンソースのモデルを使っているので、そこにお金は発生しません。
が、回答の生成には OpenAI 社の API を使用しているので、回答を作るたびにお金がかかります。
今の構成だと、『質問文からの時間軸の重要度』、『質問文の詳細化』、『質問文からのキーワード抽出』、『最終回答の要約整理』と、4 回 API を呼び出します。
以前の構成では、回答に幅を持たせるために 6 回使用していましたので、回数としては減らすことができました。
しかし、一部の API でモデルをより高価なものに変更した（「gpt-4.1-nano」→「o4-mini」）ため、最終的な金額としては増額になっています。
ここはかなり悩んだのですが、希望する回答を得るためにはモデルを変えざるを得ず、泣く泣く増額を受け入れました。
このように、理想の回答を追い求めることも重要ですが、コスト面でも気にしなければいけないのが難しいところです。
さて、チューニングの目途が立ったので、今度はデータソースの充実が必要です。
最低でも、ホームページの各ページの情報を RAG に入れ込みたいです。
そのうえで、検索結果から各ページにジャンプできるリンクを表示するようにしたいですね。
あと、これはまだまだ先のお話ですが、私がこれまで学習してきた内容を RAG に入れ込み、私のクローンと呼ぶべきチャットボットも構築してみたいです。
思考をトレースするのはまだ難しいでしょうが、知識の回答ぐらいはできるのではないかと。
いずれにせよ、せっかく作るのですから、オリジナリティのあるチャットボットを作成したいですね。
それでは、チューニングでへろへろの、山本慎一郎でした。