RAGの初めの段階は「文書内のどの情報を引っ張ってくるか」の検索の部分です。ここの精度が出ないと、後段でどれだけ工夫しても良い回答は得られません。検索の部分が最重要と言っても過言ではありません。
検索精度を高める工夫の前に、まずは代表的な検索の仕組みを簡単におさらいしてみます。
手法 | 概要 | メリット | デメリット |
---|---|---|---|
キーワード検索 | ・入力された単語と文書内の単語の一致度をスコア化して検索する手法 ・シンプルな単純一致検索や、単語の重要度を文書頻度で重み付けした「TF-iDF」や「BM25」といったアルゴリズムがある |
・固有名詞や専門用語に強い ・シンプルで実装難易度も低い |
・「ログイン」と「サインイン」のような表現の揺らぎに弱い ・「PC」と「プログラミング」のような、関連性の高さは考慮できない |
ベクトル検索 | 文や単語を埋め込みベクトル(文章や単語の意味を数値化して表現したもの)に変換し、意味的な近さを類似度で検索する | ・「ログイン」と「サインイン」のような、意味的には同じでも表現の違いに対応しやすい ・自然言語の質問に対応しやすい |
・固有名詞や専門用語に弱い ・ベクトル変換モデルの精度に依存する |
こういった検索の仕組みを理解した上で、RAGでは以下のような工夫で検索精度の向上が期待できます。
ハイブリッド検索
実際の運用では、キーワード検索とベクトル検索を組み合わせる「ハイブリッド検索」がよく使われます。
例えば固有名詞やコードはキーワード検索で確実に拾い、言い回しの違いはベクトル検索で補う、といった形です。両者の強みを組み合わせることで、より安定して「欲しい文章」にたどり着きやすくなります。
実際に運用する際には、キーワードとベクトルのどちらをどれくらい優先するか(重み付け)を調整することも重要です。
揺らぎの対策
検索では「ログイン」と「サインイン」、「ユーザー」と「利用者」のように、言葉の揺れで取りこぼしがよく起きます。これを防ぐ基本的な工夫が、同義語や関連語をあらかじめ補って検索する方法です。揺らぎ対策の代表的な手法としては、以下が挙げられます。
対策 | 概要 | 効果 | 注意点 |
---|---|---|---|
正規化 | 「ログイン」「login」といったカタカナ/英語の揺らぎや、「1」「一」のような算用数字/漢数字の揺らぎを統一する | 表記ゆれを減らし、検索ヒット率を向上させる | ・どの表記に揃えるかを事前に決める必要がある ・データ修正のコストがかかる |
辞書登録 | 「ログイン=サインイン」「ユーザー=利用者」のような同義語の対応表を事前に作成する | 同義語・言い換えを吸収し、検索精度を底上げできる。元データの修正が不要 | ・辞書のメンテナンスコストがかかる ・短すぎる単語を登録すると誤置換のリスクも上がる |
元のデータ量が大規模になると、正規化や辞書登録での対策だけでは現実的でないため、大規模データを扱う場合はハイブリッド検索、小規模データであれば正規化や辞書登録をまずは試してみて、それでも精度が上がらない場合は、もう一方のアプローチを試してみるのがよいかと思います。
欲しい文章が検索でヒットしても、その文章自体がきれいでなければ思ったような回答は得られません。特にWordやPowerPointといった文書をそのままRAGに投入しても、ノイズの多いデータになりがちです。この問題の解決につながる策は、基本的にはデータの前処理になります。以下に、データの前処理の例を幾つか紹介します。
不要情報の除去(クリーニング)
Wordで作成された文書には、多くの場合目次やヘッダー、フッターが含まれています。RAGでは、こういったテキストはノイズになります。例えば「アプリの再起動方法を教えて」といったプロンプトが入力された場合、本来欲しいのはアプリの再起動方法が書かれたページの情報だと思います。ですが、目次に「3章 アプリの再起動方法-P5」と書かれていたら、テキストとしては近い情報になるので、目次がヒットしてしまいます。こういった「ユーザーが入力するテキストに近そうだが、見ても意味がないページは、事前に除去しておくことで、ノイズが少なくなり精度の向上につながります。
画像データの前処理
PDFなどの資料には、多数の画像や図表が含まれているケースがあります。最近のAIは画像認識能力も高いですが、画像を画像であると明示しないと読み取ってくれなかったり、そもそも画像に対応しておらず、検索対象にすらならなかったりすることがあります。
画像中に含まれるテキスト情報を取得するアプローチとして挙げられるのがOCR(光学文字認識)です。OCRを通すことで、画像の中の文字をテキストデータに変換できます。OCRを導入する際は、以下の点に気を付けて実装してください。
ポイント | 内容 | 効果 |
---|---|---|
言語設定を正しく | 文書の言語に合わせた適切な言語設定 | 文字化け・誤認識を防ぐ |
段落単位で処理 | 行ごとではなく段落ごとに抽出する | 文脈が崩れにくい |
誤認識の補正 | 「1(イチ)/l(小文字のエル)」「0(ゼロ)/O(オー)」など典型的エラーを置換する | 正確なテキストが得られる |
既に触れましたが、RAGでは長い文書をそのまま扱うことはできないため、文章をある程度のまとまり(チャンク)に分割してから検索対象にします。この作業を「チャンキング」と呼びます。このチャンキングの仕方が適切でないと、「文章が途中で切れてしまい意味が伝わらない」、あるいは逆に「長すぎて検索精度が落ちる」といった問題が起こります。
チャンクサイズとオーバーラップの見直し
まず重要なのが、チャンクサイズの設定です。細かく切りすぎると、例えば「アプリケーションが正常に起動できない場合、まず…」のように文が途中で終わり、肝心の説明が別のチャンクに分かれてしまいます。逆に大きすぎると、要点が押さえられずぼやけた回答になることがあります。
そこで、実際には数百〜数千文字程度を目安に分割し、さらに隣り合うチャンクを少し重ねる「オーバーラップ」を取り入れるのが効果的です。こうすることで文脈の切れ目を自然につなぎ、AIが文章を理解しやすくなります。
チャンキング単位の見直し
もう一つ大切なのが、どの単位で分割するかという観点です。単純に文字数で切るのではなく、段落や見出しごとに分けるのが基本です。例えば、FAQなら「質問と回答のペア」を1チャンクとする、マニュアルなら「見出し+本文」をひとまとまりにする、といった具合です。こうした、構造を意識した分割により、情報の意味を保ったままAIに渡すことができ、結果として回答の正確さがぐっと高まります。
これまで挙げたような対策を行って、「欲しい検索結果も取得できているし、取得した文章もきれいになっているが、もっと精度を高めたい」という場合もあるかと思います。ここではさらにRAGの応用的な使い方について紹介したいと思います。
検索結果をAIに評価させる(Self-RAG)
検索で得られた文章が正しいかどうかを、そのままうのみにして使うのではなく、AI自身に「この文章は回答に役立つか」を評価させる仕組みです。これを一般に「Self-RAG」と呼びます。
例えば、検索で5件の検索結果を取得したとき、その中にはノイズや関係の薄いものが混じっている可能性があります。Self-RAGではAIに「これは質問に関係がある/ない」を自己判定させ、不要なものを排除することで、最終的に回答に使う根拠を絞り込めます。
こうすることで、検索が当たっていても関係の薄い文章が混ざるリスクを減らし、回答の一貫性や信頼性を高められるのが大きなメリットです。
検索結果の順番を意識する(Reranking)
もう一つの工夫は、検索結果を並べ替えることです。検索エンジンが出してきた順序は必ずしもベストではなく、ユーザーの質問に最も関連性の高い文章が下位に埋もれている場合があります。
この時、別のAIモデルやスコアリング手法を使って検索結果を再評価し、関連度の高いものを上位に持ってくるのが「Reranking」です。例えば、質問が「パスワードリセット方法」だった場合、検索結果の5件目に的確な説明があるのなら、それを1位に引き上げてから回答生成に使うわけです。
Rerankingを取り入れると、「検索は当たっているのに回答がぼやける」問題を防ぎ、常に最も関連性の高い根拠に基づいて回答を生成できるようになります。
ここまでお読みいただきありがとうございました。
RAGの精度を改善するためのアプローチについていろいろ書きましたが、RAGは「検索と生成を組み合わせればすぐに高精度な回答が得られる」という魔法の仕組みではありません。実際に動かし始めても、一発でうまくいくことはほとんどなく、ノイズの除去やチャンキング、検索結果の工夫といった改善を段階的に積み重ねていく必要があります。
また、RAGに「これが正解」という万能の手法は存在しません。扱うデータの性質や使う生成AIモデルの癖によって、最適な方法は変わってきます。だからこそ、試行錯誤を重ねながら改善していく姿勢が大切です。
RAGはまだ発展途上の技術ですが、工夫次第で大きな効果を発揮します。本稿で紹介したようなポイントを足掛かりに、ぜひトライアンドエラーで自分の環境に合ったベストプラクティスを見つけてみてください。
Copyright © ITmedia, Inc. All Rights Reserved.