RAG登場時のイメージとその用途利点
RAGが登場したときのイメージは、最新の情報や社内の非公開情報をAIに含められるようなものというイメージでした。
今は別に最新の情報についてRAGがなくともAgentic Searchで取得などもできるので、ここのネットに転がっている最新の情報という意味でのRAG活用はほぼないと思ってます。
最近のイメージはRAG≒社内情報もしくは非公開情報の学習DB
最近はRAGが「社内情報や非公開情報をAIに使わせる仕組み」というイメージで語られることが多くなった気がします。「社内のマニュアルやFAQをAIに読ませて答えさせる」というユースケースがRAGとほぼ同義になりつつあり、そこにベクトルDBが組み合わさることでRAG≒ベクトルDB≒社内情報もしくは非公開情報の学習DBというイメージがある気がします。
私個人も実際にRAGチャットボットを構築するまでは似たようなイメージでした。
検索の例
「経費って何日以内に出せばいいの？」というクエリに対して「旅費交通費精算申請規程」というドキュメントを引いてきたい場合、キーワードは一致しなくても意味が近ければベクトル検索で引っかけられます。これがベクトル検索の曖昧さ対応で、ユーザーの自然な言い回しと文書側の正式な表記がずれていても拾えるというのが強みです。また、使用するembeddingモデルが複数言語に対応していれば、図らずも多言語対応も兼ねることになります。日本語のクエリで英語ドキュメントを引いてきたり、その逆も意味が近ければ拾えます。
「曖昧な問い合わせに対応するためにベクトルDBが必要」という論理は一見正しそうですが、これには曖昧さへの対応をDB側で持たなければならないという前提があります。ただ、必ずしもそうではないかと思っています。
別に検索したいものはそこまであいまいではないのでは?
そもそも検索したいものがそこまで曖昧かというと、ユースケースによっては全然そうでもないと思います。個人的にはエラーコードやスタックトレースに紐づく情報を検索することが多く、こういった用途では意味的に近いドキュメントが来ても困ります。ERR_001 認証失敗 を調べたいのに類似したエラーのドキュメントが引っかかっても事故の原因になるので、むしろピンポイントで一致してほしいです。あいまいさへの対応をDB側に持たせることが、逆に精度を下げるケースもあると感じています。
キーワード検索とベクトル検索を組み合わせたハイブリッド検索という手法もありますが、実際にはキーワード一致側が大部分を担っていて、ベクトルが貢献している割合は思ったより小さいのではと感じています。
Knowledge Graphのように関係性を構造として持つアプローチは、エンティティ間のつながりを辿りたいケースで有効だと思いますが、ベクトルである必要は必ずしもないのではと思っています。
もしあいまいが必要だったとしても、今はクエリリライトで別途あいまいさなどや関連を担保して、DB側にあいまいさを持たせる必要性が下がっている気がします。
あいまいさでも拾えないもの
あいまいさはあくまでembedding modelが定義している関連性のみで、その情報独自の紐づきは拾えない。
例えば、薬品番号というものがあって、それは薬品ごとに特有のIDを持つ場合、embedding側は、どれがどの薬品番号かわからず、ここの関連性を拾うことはできない。
番号と薬品の紐づけが書かれた薬品一覧表があって、薬品の詳細が薬品名で書かれている場合、薬品番号で問いかけをしたとしても、この場合は基本的に薬品の詳細情報が取れることはない。
ここを解決するためにiterative query、Graph、シノニムマップ等(メンテが大変ですがシノニムマップ)を使って関連性を明示することが解決がいくつかの選択肢かと思います。
その他
社内情報の活用という文脈は、非エンジニアにとってIT化をイメージしやすいものだと思います。「社内のマニュアルをAIに読ませて質問に答えさせる」という概念は直感的で、具体的に何をさせるかまで考えていなくても「これは使えそう」というイメージが持ちやすいです。その結果として、PoCレベルの社内チャットボットやドキュメント検索アプリの開発は増えていきそうだと感じています。ベクトルDBを使った実装が標準として広まっているのも、こういったPoC需要が後押ししている部分があるかもしれません。
SaaSでRAGチャットボットとか、非エンジニアがRAGチャットボット請負製作会社を立ち上げたり、なんちゃってRAGチャットボットが蔓延ってますが、ここの検索精度の改善で差別化ができるのかなと思います。
(果たしてその精度は求められているのか、なんちゃっての程度でも満足という可能性もありますが。)
以前からいる(会ったことないですが)検索エンジンやロジック生成を生業にしていたエンジニアがこのRAGにて力を発揮できるのではないかと思います。
まとめ
究極はどうやって必要な情報を検索させるかの本質を理解と実装ができれば良い。
個々の開発者の責任ではなく、各Dify,OpenAI、AWS,Azure,Elastic searchなどの基盤となるものを作る人がそれを作って、各開発者はそれに乗っかるだけかもしれませんが。