RAGでドキュメントの更新に強くする手法
導入
こんにちは、株式会社ナレッジセンスの須藤英寿です。
今回は、ドキュメントの更新に強いRAGの手法「VersionRAG」を紹介します。
サマリー
RAGは便利な手法ですが、文書のバージョンの変化が苦手です。例えば、仕様書のように更新されていく文書の新旧の認識が苦手です。Google検索で出てきた情報が古い情報で、今では利用できない。というのは誰しもが経験してきたのではないでしょうか。RAGでも、同様の問題が発生します。
今回紹介する「VersionRAG」は、内容が時間経過でどんどん更新されていくドキュメントに特化することで、バージョンの更新に強い手法となっています。
課題意識
意味検索の弱点
RAGは基本的に、意味的な類似度や単語の類似度をベースに関連するドキュメントを探す機能となっています。これで多くのケースをカバーすることができますが、不得意なドキュメントのパターンというものも存在します。プログラムのライブラリを例に考えると、ある関数が、v2で実装が追加されて、v3で利用方法が変わり、v4で利用できなくなる。という変化が発生したとします。それぞれのバージョンのドキュメントがすべて検索対象となると、機能としては類似しているため、どれが検索結果として取得できるかは予測がつきづらくなってきます。
このため、通常のRAGの実装だけでは、更新が発生するドキュメントをうまく扱うことができません。
手法
データの保存方法
VersionRAGでは、ドキュメントの内容を5つの階層に分解して保存します。これにより、検索時に効率のよいフィルタリングを可能にし、検索の精度を上げています。
具体的な各層の役割は以下のようになっています。
- カテゴリ層: 「Node.js関連文書」や「Apache Spark関連文書」といった、大きな技術分野レベルでの分類。
- ドキュメント層: 「Node.js Assertモジュール仕様書」のようにバージョン変化が発生する大元の仕様の単位での分類。
- バージョン層: 「Version 1.0」「Version 1.1」といったバージョン単位での分類。
- コンテンツ層: 仕様の内容をチャンクに分解して保存する層。一般的なRAGと同様に意味検索することを想定している。
- チェンジ層: コンテンツ層と同じ階層で、バージョンの変化を記載している。明示的な変更点と、コンテンツ同士を比較した際に見つけた暗黙的な変更点の両方を保存する層。
データの検索方法
ユーザーのクエリを元に、以下の三種類のクエリを発行し検索を行います。
- コンテンツ検索: バージョンによるフィルタを加えたうえで、ベクトル検索を行う
- バージョン検索: グラフ構造を辿っていき、特定のドキュメントのバージョンの一覧を取得する
- 変更点検索: バージョン検索同様、グラフ構造を辿っていき、特定のドキュメントの変更点を取得する
これらの検索手法を組み合わせて、ユーザーの問い合わせた内容を正確に特定します。
例えば、「Node.jsバージョン23.11.0では、assert.partialDeepStrictEqual
は利用可能ですか?」という質問があると以下の手順でドキュメントを検索します。
- 「バージョン検索」を利用すると判定
- バージョン
23.11.0
を抜き出す - そのバージョンでフィルタリングしたうえで、「コンテンツ検索」を実施
- 関連するドキュメントのみを取得
このように柔軟に検索手法を変更することで、精度の高い検索を実現しています。
評価
モデルの種類ごとに、バージョン管理されたドキュメントの内容を検索する「VersionQA」というベンチマークを作成し、比較しています。全般的に高い性能を実現していますが、LLMの性能が比較している中で低いLlama 3 8B
では、差が小さい、もしくは性能が他の手法と比べて低くなっています。
まとめ
今回は、更新が発生するドキュメントを精度高く検索できるRAG手法「VersionRAG」を紹介しました。バージョン管理に合わせたデータ管理手法と、それを前提とした検索手法を組み合わせることで、本来RAGが苦手とするドキュメントの変化に強いRAGを実現しています。
仕様書をRAGで検索できるようにしたいけど、精度が上がらないという場合には応用できる手法なので是非ご活用ください。
Discussion