検索拡張生成（RAG）：AI検索の仕組みを徹底解説

大規模言語モデルを本番環境で運用している方なら、必ず直面する問題があります。それは、モデルの知識が学習データの時点で凍結されているということ。そして、存在しない情報をもっともらしく生成してしまうハルシネーションの問題です。

RAG、つまりRetrieval-Augmented Generationは、この根本的な課題に対する現時点で最も実用的な解決策として、プロダクション環境で急速に普及しています。基本的なアーキテクチャは明快で、ユーザーのクエリに対して、まず外部のナレッジベースから関連するコンテキストを検索し、そのコンテキストを含めた形でLLMに生成を行わせる。これにより、モデルは最新の情報にアクセスでき、回答の根拠も明示できるようになります。

しかし、実際にRAGシステムを構築すると、検索精度をどう上げるか、チャンクサイズをどう決定するか、ベクトルインデックスの選択は何が最適か、といった設計上の判断が山ほど出てきます。これらの判断を正しく行うには、RAGの各コンポーネントが内部でどう動作しているかを深く理解する必要があります。今日は、ベクトル埋め込みの数学的な仕組みから、プロダクションで使える具体的なチューニング手法まで、RAGの内部構造を詳しく見ていきます。

では、このRAGの心臓部とも言えるベクトル埋め込みについて深掘りしていきましょう。

私たちが普段使っている言葉、例えば「犬」という単語をコンピュータはそのままでは理解できません。ここで登場するのがベクトル埋め込みです。これは、テキストを数百から数千次元の数値の配列に変換する技術です。例えばOpenAIのtext-embedding-ada-002は1536次元、最新のtext-embedding-3-largeは最大3072次元のベクトルを生成します。

ここで面白いのは、この変換が単なる文字のエンコーディングではないという点です。意味的な関係性がベクトル空間上の距離として表現されるんです。「王様」から「男性」を引いて「女性」を足すと「女王」に近いベクトルが得られる、という有名な例をご存知の方も多いでしょう。これと同じ原理が、より複雑な文章レベルでも働いています。

実務で使われるモデルを見てみると、Sentence Transformersのall-MiniLM-L6-v2は軽量で高速、一方でE5やBGEといった最新モデルは、特に長文の意味把握において優れた性能を発揮します。日本語に特化したmultilingual-e5-largeやJapanese Sentence BERTも、実際のプロダクション環境でよく採用されています。

重要なのは、これらのモデルが大量のテキストデータで事前学習されているため、人間が明示的にプログラムしなくても、文脈や含意を捉えたベクトル表現を自動的に学習している点です。つまり、「りんご」と「みかん」は数値としては全く異なりますが、ベクトル空間では「果物」という概念の近くに配置され、「自動車」とは遠く離れた位置に存在することになります。

ここで重要なのは、従来のキーワード検索との根本的な違いです。キーワードマッチングでは「東京の観光スポット」と検索すると、まさにその単語を含む文書だけがヒットします。しかし「首都で訪れるべき場所」という検索では、たとえ同じ意図を持っていても、全く異なる結果が返ってくるわけです。

セマンティック検索はこの限界を突破します。ベクトル空間において、意味的に近い概念は物理的にも近い位置に配置されています。つまり「東京」と「首都」、「観光スポット」と「訪れるべき場所」は、異なる単語でありながら、ベクトル空間上では非常に近い座標を持つのです。

では、どうやってベクトル間の「近さ」を測定するのか。代表的な手法がコサイン類似度です。これは二つのベクトルがなす角度を測定し、完全に同じ方向を向いていれば1、正反対なら-1を返します。角度が小さいほど意味的に類似していると判断できるわけです。もう一つの手法がユークリッド距離で、これは単純に二点間の直線距離を計算します。

RAGにおいてセマンティック検索が決定的に重要な理由は、ユーザーの質問と関連文書のマッチング精度に直結するからです。ユーザーは必ずしも文書内の正確な表現を使いません。意図を理解し、関連性の高い情報を取得できなければ、生成されるレスポンスの質は著しく低下します。

さて、ベクトル化の前段階として絶対に避けて通れないのが、チャンキング、つまり文書分割の問題です。実はこれ、RAGシステムの精度を左右する最も重要な設計判断の一つなんですが、意外と軽視されがちなんですよね。

まず基本的なアプローチとして、固定長チャンキングがあります。例えば512トークンごとに機械的に分割する方法です。実装は簡単ですが、文の途中でぶった切られることがあり、意味的な一貫性が損なわれるリスクがあります。

次に、文ベースや段落ベースのチャンキング。これは自然言語の区切りを尊重するので、意味的なまとまりは保たれやすい。ただし、チャンクサイズにばらつきが出るため、埋め込みベクトルの品質が不均一になる可能性があります。

そして最近注目されているのがセマンティックチャンキングです。文間の意味的な類似度を計算し、トピックが変わるポイントで分割する。計算コストは高くなりますが、本当に意味のあるまとまりでチャンクを作れます。

ここで重要なのが、チャンクサイズとオーバーラップのトレードオフです。チャンクが大きすぎると、検索結果に関係ない情報が混入してLLMの回答精度が下がります。逆に小さすぎると、必要な文脈情報が失われ、断片的な情報しか取得できません。

実務では、チャンクサイズを256から1024トークン程度に設定し、20から30パーセントのオーバーラップを持たせることが多いです。オーバーラップによって、チャンク境界で文脈が切れる問題を緩和できるんですね。

結局、最適な戦略はユースケース次第です。技術文書なら段落ベース、Q&Aデータなら質問回答ペアでの分割など、データの性質に合わせた設計が求められます。

さて、ベクトル埋め込みを生成し、文書を適切にチャンキングしたら、次はそれらを効率的に保存し検索する仕組みが必要になります。ここで登場するのがベクトルデータベースです。Pinecone、Weaviate、Chroma、Milvusといったツールが現在のプロダクション環境で広く使われています。

興味深いのは、これらのデータベースが採用しているインデックス手法です。特にHNSW、Hierarchical Navigable Small Worldと呼ばれるアルゴリズムは、近似最近傍探索の分野で革命的な存在です。従来の方法では、数百万のベクトルから最も類似したものを見つけるには、全てのベクトルとの距離を計算する必要がありました。これは計算コストが爆発的に増加します。HNSWは、グラフ構造を階層的に構築することで、この問題を巧みに解決しています。上位層では粗い検索を行い、下位層に進むにつれて精度を上げていく。結果として、精度をほぼ維持しながら、検索速度を劇的に向上させることができるのです。

しかし、インデックスだけでは検索精度の限界があります。ここでクエリ拡張の出番です。HyDE、つまりHypothetical Document Embeddingsは、ユーザーのクエリに対してLLMが「仮想的な回答文書」を生成し、その文書をベクトル化して検索に使うという逆転の発想です。ユーザーの短いクエリより、生成された仮想文書の方が、実際の関連文書と意味的に近くなることが多いのです。

もう一つの強力な手法がMulti-query Retrievalです。単一のクエリを複数の異なる表現に書き換え、それぞれで検索を実行し、結果を統合します。「機械学習のオプティマイザー」という質問を、「勾配降下法の種類」「Adam、SGDの比較」といった複数の角度から検索することで、より網羅的な結果が得られるわけです。

ここまで見てきたように、RAGシステムの真価は、大規模言語モデルの生成能力と、外部知識ベースからの正確な情報検索を融合させる点にあります。ベクトル埋め込みによる意味理解、適切なチャンキング戦略、そして洗練されたクエリ拡張技術。これらの要素が組み合わさることで、ハルシネーションを抑制しながら、実用的で信頼性の高いAIシステムを構築できます。

今後の展望として注目すべきは、テキストだけでなく画像や音声を統合するマルチモーダルRAG、検索結果の精度を飛躍的に向上させるクロスエンコーダーベースのリランキング、そしてツール使用と組み合わせたエージェント型RAGです。これらの技術は、企業のナレッジマネジメントから医療診断支援まで、幅広い領域で革新をもたらすでしょう。

次のステップとして、実際にLangChainやLlamaIndexといったフレームワークを使って、小規模なRAGシステムを構築してみることをお勧めします。理論と実践の両輪で、この分野の最前線を歩んでいきましょう。