「RAGの精度がイマイチ」なら試してみるべき“改善のヒント”はこれだ:生成AIを支えるRAGの裏側【後編】
AIシステムの裏側に広く採用されている「RAG」だが、期待した精度が出ないケースも少なくない。RAGの構築から評価までのステップと、検索精度を最大化するために押さえるべきポイントを解説する。
大規模言語モデル(LLM)をベースにした生成AI(AI:人工知能)システムの裏側で広く採用されているのが「RAG」(検索拡張生成)だ。RAGは、LLMが外部のデータベースから情報を検索、取得できるようにし、事前学習していない知識や最新情報を含めたより実用的な応答を実現する仕組みだ。
しかし導入現場では、「RAGを導入したが、期待する精度が出ない」という声も少なくない。こうした問題の背景には、RAGシステムの設計からモデル選定、評価体制に至るまで複数の要素が絡んでいる。そこで本稿は、RAGの検索精度を高めるために押さえておきたい設計・運用上のポイントを、構築から評価までのステップに沿って解説する。
RAGの精度が出ないのはなぜ? 改善のヒントはこれだ
データをベクトルに変換する「エンベディング」
まず、検索対象となる文書やデータをベクトル(数値のリストや配列)化して、AIモデルが意味を理解できるようにする必要がある。このプロセスがエンベディング(埋め込み)だ。
エンベディングでは、文書やそのチャンク(小さい区切り)を、AIモデルが処理しやすいベクトルに変換する。ベクトルはベクトルデータベースに保存され、検索や生成処理の際に活用される。
エンベディングモデルには、大きく分けて以下の2種類がある。
- 密(dense)モデル
- 多くのLLMで採用される一般的な方式。固定長のベクトル(768次元、1536次元など)を出力し、ベクトルの次元数(x次元)が表現力や計算コストに影響する。
- スパース(sparse)モデル
- 入力テキストに応じてベクトルの次元数や密度が可変となる方式。検索精度の最適化を目的とするモデルでよく用いられる。
これらを組み合わせたハイブリッド方式も存在する。特に短文(SNSのコメントやFAQなど)を対象とする際に有効で、検索精度と処理効率を両立する。代表的なものは以下の通り。
- Splade
- ColBERT
- IBM sparse-embedding-30M
ベクトルの次元数は、検索精度や処理速度に大きく影響する。次元数の多いベクトルは、より豊富なコンテキスト(文脈)やニュアンスを保持できて検索精度の向上が期待できる一方、ベクトルの生成と検索に計算リソースを多く消費する。反対に、次元数の少ないベクトルは保持できる情報量も限られるが、検索処理が高速で軽量なため、応答速度やリソース効率を重視する用途に適している。
エンベディングモデルを選定する際は、以下の要素を考慮すべきだ。
- ベクトルデータベースの仕様
- 対応する次元数や検索アルゴリズム、ストレージ容量などが選定に影響する。
- 連携するLLMの特性
- LLMがエンベディングで使用する表現空間との整合性や、推論時の相性も重要。
- 用途(検索、分類、生成など)
- 検索対象の文書量や応答に求められる精度、リアルタイム性などに応じて最適解は異なる。
エンベディングモデルの性能比較に役立つベンチマークとして、Hugging Faceの「MTEB」(Massive Text Embedding Benchmark)などがある。
注意すべき点として、ユーザーが入力するクエリ(AIモデルに対する指示)と文書のベクトルは、基本的には同じエンベディングモデルで生成する必要がある。異なるモデルでベクトル化すると、ベクトル間の類似度が適切に評価されなくなるからだ。
使用するエンベディングモデルが特定分野の専門用語や文脈を保持していない場合は、ファインチューニング(追加学習)が精度向上に有効だ。
併せて読みたいお薦め記事
連載:生成AIを支えるRAGの裏側
なぜRAGが注目されるのか
関連性の高い情報を探す「ベクトル検索」
ベクトル化された大量のデータの中から、意味的に類似した情報を高速かつ高精度に探し出す技術がベクトル検索だ。
ベクトル検索では、クエリと文書ベクトルの類似度を基に関連性の高い情報を探す手法だ。これにより、単なるキーワード一致ではなく、ユーザーの意図に沿った文脈的な関連情報を効率的に取得できる。
コストと精度のバランスを取るため、キーワード検索とベクトル検索を組み合わせることもあるが、ハイブリッド検索に標準対応しているベクトルデータベースは限られているため、導入前に対応状況を確認すべきだ。
ベクトル検索の中核となる手法が「近似最近傍探索」(ANN:Approximate Nearest Neighbor)であり、検索クエリに最も類似したベクトルを高速かつ高精度に見つけ出すことを可能にする。ANN探索に用いられる代表的なアルゴリズムには、以下のようなものがある。
- HNSW(Hierarchical Navigable Small Worlds)
多くのベンダーが採用しているアルゴリズム。精度と検索速度のバランスに優れている。
- DiskANN
Microsoftが開発したオープンソースアルゴリズム。大規模なベクトル集合を対象にコストパフォーマンスを重視した設計で、多少の精度低下を許容して高速処理を実現している。
- ScaNN
- Googleが独自に開発したアルゴリズム。大規模データセット向けに最適化されている。
ベクトル検索では、ベクトル空間上に構築されたグラフ構造をたどることで、近似的に最も類似したベクトルを探索する。その際の類似度の評価指標として用いられるのが距離関数であり、代表的なものに以下の2つがある。
- コサイン距離
- ベクトル同士の角度(方向)の近さに着目し、意味的な類似性を評価する手法。テキストデータのセマンティック検索において広く使われており、LLMとの親和性も高い。
- ユークリッド距離
- ベクトル間の直線距離(絶対的な距離)を測定する手法。実装がシンプルで処理が高速な他、計算コストを抑えやすい。ただし、意味的な違いにはやや鈍感。
一般的に、ベクトルデータベースは近似的な類似ベクトルを複数返すため、「上位k件のみを返す」(top-kカットオフ)という制限を設ける。この制限は、LLMのコンテキストウィンドウ(入力上限)に収まるようにするため、無関係なベクトルを排除して応答の精度を確保するために重要だ。ただし、データベース内に大量のベクトル数が含まれる場合は、本当に欲しい情報が上位k件に入らず検索精度が低下したり、検索結果が制限を上回ったりする可能性がある。
ベクトル検索の精度を高める「リランク」
ベクトル検索では文脈の微差を捉えきれないため、意味的な判定に限界がある。より精度の高い回答を引き出すために、リランクモデル(reranking model)の活用が有効だ。
まず、AIモデルが検索結果を通常より多めに取得する。次に、リランクモデルがクエリとの関連度に基づいて結果を並べ替え、より適切な順序でLLMに渡す。
代表的なリランクモデルには、次のようなものがある。
- Cohereの「Cohere Rerank」
- オープンソースの「BGE」
- DeepSeekの「Janus AI」
- Elasticの「Elastic Rerank」
リランクモデルを使用すると処理が増えるため、結果の返答に遅延(レイテンシ)が生じる可能性がある。専門的なデータを扱う場合は再トレーニングが望ましい場合もある。一方、リランクの過程で各チャンクに「関連スコア」が付与されるため、RAGシステムの精度や挙動を監視、評価するデータとして有用だという見方もある。
検索精度を最大化するための評価手法
RAGの品質を見極めるためには、生成結果を評価、監視する仕組みの整備が欠かせない。
例えばLLM自体を評価者(ジャッジ)として用いる手法がある。生成された回答に対して、別のLLMを用いて品質や正確性、妥当性などを判定させることで、RAGの出力の信頼性をチェックできる。
ユーザーからのフィードバックを収集し、それに基づいてシステム構成や検索精度を改善する仕組みも有効だ。生成結果に対する「良かった点」「不満点」などを定性的、定量的に評価することで、運用のチューニングにつなげられる。
セキュリティやコンプライアンスの観点からは、特定のユーザーによる機密情報の取得や有害な質問の送信を防ぐために、ルールベースのフィルタリング機能を持つAPIも登場している。
こうした評価を継続的に行うには、RAGを構成する各コンポーネント(エンベディング、検索、LLMなど)のコスト、性能、セキュリティといった指標を可視化、監視できる基盤が重要となる。
Copyright © ITmedia, Inc. All Rights Reserved.