📰 今日のZenn記事
元記事：ベクトルDBを使わないRAGを作って、従来方式と比べてみた（Zenn）
RAG（資料を探してからAIに答えを作らせる仕組み）では、ふつうベクトルDB（文章の意味を数字にして保存しておく、検索用の保管場所）で、意味の近い資料を探します。この記事は、そのベクトルDBを使わないRAGを自作して、従来のベクトルDB版と同じ資料・同じ質問で比べた検証です。動機は、ベクトルDBを用意して運用する手間とコストを避けたい、というものです。参考にしたのはCorpus2Skillという論文の手法ですが、大幅に簡略化した自作版なので、論文の手法の性能を示すものではない、と筆者自身が断っています。
作った仕組みは「資料の目次をAIに作らせて、目次をたどって探す」というものです。準備として、資料ごとに短い紹介カードを作り、内容の近いものを自動でグループにまとめ、グループごとにAIが要約して、2階層の目次にします。質問が来たら、AIが目次を上から読んで、答えがありそうなグループ、そして資料を選んでいきます。質問のたびに意味の近さを計算することはしません。ただし、目次を作る準備の段階ではその計算を使っているので、完全にベクトル不要というわけではありません。
比較に使ったのは、AWSのAmazon Bedrockの解説書28文書と、20問の質問です。文書と同じ言葉で聞く質問、言い換えて聞く質問、2つの文書をまたぐ質問、資料に答えがない質問が混ざっています。結果はこうでした。
- 正解数はどちらも20問中16問で、差は出なかった
- 1問あたりのAI利用料は目次方式が約1.5倍、応答時間は約1.3倍かかった
- 資料に答えがない質問では、目次方式は資料を1件も取らずに「分からない」と答え、入力を節約できた
間違え方には違いがありました。目次方式は、目次をたどる途中で違うグループを選んでしまう失敗が中心で、論文でも最も多い失敗とされています。ベクトルDB版は、正しい資料までは拾えているのに、答えが書かれた部分が取れずに間違えるケースがありました。また、AIによる採点が実際の正誤とずれることが多く、そのずれだけで2〜3問の差になりました。
ベクトルDBをやめて省けるのは、質問ごとに意味の数字を計算する1回と、ベクトルDBの運用です。その代わり、目次を降りるたびにAIを呼ぶので、質問1件あたりの呼び出しは平均2.75回（ベクトルDB版は1回）に増えます。つまり「ベクトルDBをやめれば安くなる」とは限りません。なお、比較相手の「ベクトルDB版」も専用の製品は使わず、ファイルとメモリ上の計算で動かしているので、運用の手間が減る効果はこの比較に入っていません。
筆者の結論は、28文書・20問という小さな規模では、どちらが優れているとは言えない、というものです。大量の文書での強みや、用語の索引などを足した場合は検証していません。
ベクトルDBの運用をやめることで、構築の手間や運用コストを省きたい、というのが狙いらしいんですが、結局は別の準備が要るし、階層を降りるためのLLMの呼び出しが増えて、トークンの消費も増えた、という実験結果だったみたいですね。AIをどう運用すれば安く効率的に試せるかの一次情報なので、専門家や技術者の人にとっては、すごく実践的な実験レポートなんじゃないかなと思います。
ベクトルDBというと、うちのナレッジ検索のmikkeがまさにそれかなと。検索する言葉と文書の用語が一致してなくても探せるので、実際に使っていて便利です。mikkeについては、作った方の紹介記事があります。
その後のmikke
で、この記事をきっかけに思い出して、AIに「mikkeの意味検索、使ってみてどうだった？」と聞いてみたんですが、答えられる材料がほぼ残ってなかったらしい。導入から1週間は積極的に使ってねと頼んでいたのに、実際に意味検索で調べ物をしたのは導入時の動作確認くらい。人間なら「あれ便利だったな」と後から言えますが、AIはその場の手応えを次の会話に持ち越せない。
そこで、AIが過去のメモを探すときの最初の一手を、mikkeのハイブリッド検索（言葉の一致と意味の近さを両方使う検索）に切り替えてもらいました。試しに言い換えた文で3本探してもらったら、言葉の一致だけの検索は3本とも0件、ハイブリッドは2本当たり。ただ、外れたときも何かしら5件返してくるので、当たったかどうかは別に見ないといけないらしい。
なので感想を書かせる代わりに、会話ログを後から読んで「検索した後にそのノートを開いたか、探し直したか、grepに移ったか」で採点するスクリプトを組んでもらいました。2週間たまったら集計する予定なので、mikkeが本当に役に立っているかは、今後のお楽しみということで。