検索拡張生成（RAG）を第一原理から理解する
RAGはツールの積み重ねとして説明されがちです。それを取り払えば、一つの単純な考えに行き着きます。モデルが答える前に適切な資料を読ませること。その本当の仕組みを解説します。
検索拡張生成は、たいてい製品のパイプライン、すなわち埋め込みモデル、ベクトルデータベース、リトリーバー、ジェネレーターとして紹介されます。その枠組みは逆さまです。RAGは一つの考えであり、ツールはそれを実装する一つの方法にすぎません。その考えとは、モデルが答える前に、答えのもととなる具体的な資料を与えること。 それ以外はすべてエンジニアリングです。
この用語は、Lewisらによる2020年の論文に由来します。リトリーバーとジェネレーターを組み合わせ、モデルがウェイトに記憶したものだけに頼るのではなく、外部の文章を引き込めるようにしたものです。当時の動機は今の動機であり、それを第一原理から理解すれば、いかなる特定のツールよりも長持ちします。
RAGが解く問題
言語モデルは、学習データにあったもの、すなわちある時点で凍結され、ウェイトに溶け込んだものしか知りません。これは二つの限界を生みます。
- あなたの私的または最近の情報を知りえない。 自社の文書、先週のリリースノート、特定のPDFの中身。どれもモデルの中にはありません。
- ウェイトからの想起は損失を伴う。 モデルの「中にある」ものでさえ、正確な詳細は間違って出てきうるのです。モデルは圧縮された記憶から再構築しているのであって、何かを参照しているのではありません。
RAGは、問いを「モデルは何を覚えているか」から「いまモデルの前に何を置けるか」へ変えることで、両方に対処します。その転換、すなわち記憶から証拠へ、がすべての要点です。
三段階の仕組み
その核心において、RAGは三つの動きです。
- インデックス化。 元の資料を文章に分け、検索できるように格納する。ほとんどのシステムは、各文章を埋め込み、すなわち似た意味を互いに近くに置くベクトルへ変換し、それらのベクトルを格納することでこれを行います。
- 検索。 質問が来たら、それに最も関連する文章を見つける。埋め込みでは、質問をベクトルに変え、最も近い文章を取得することを意味します。
- 生成。 検索された文章を質問とともにモデルのコンテキストに入れ、その資料を使って答えるよう求める。
それが全体の流れです。モデルはなお答えを書きますが、いまや記憶から想起するのではなく、供給された証拠を読んでいます。RAGの洗練されたものはすべて、この三段階のいずれかの精緻化です。
なぜ埋め込みか、そしてそれが魔法ではない理由
埋め込みは、正確な語ではなく意味で検索することを可能にします。だから「休暇」についての質問が、共通のキーワードがなくても「有給休暇規程」についての文章を検索できます。これは真に有用で、意味検索がほとんどのRAGシステムを支える理由です。しかし正直な注意が二つ。
- 意味検索は正確な検索ではない。 正確な識別子、すなわち製品コード、特定の条項番号、エラー文字列については、キーワード検索が埋め込みに勝ることがよくあります。多くの強力なシステムは両方を組み合わせており、通常ハイブリッド検索と呼ばれるパターンです。
- 検索品質が下流のすべての上限を決める。 第二段階が間違った文章を返せば、モデルは間違った資料から答え、同じくらい自信たっぷりに聞こえます。これはRAGについて唯一最も重要な事実であり、デモが隠すものです。
チャンキング：品質を決める地味な決定
文書を文章にどう分割するかが、検索のうまくいき方を静かに決めます。長すぎるチャンクは関連性を薄めます。有用な一文が無関係なものに埋もれ、埋め込みが多すぎる考えの平均になってしまうのです。短すぎるチャンクは、それを意味あるものにしている文脈を失います。確実な助言は、任意の文字数で切るのではなく、自然な境界に沿ってチャンク化すること、すなわちセクション、段落、論理的なまとまりです。良いチャンキングは退屈な作業ですが、凝ったモデルに差し替えるより報われます。
良いRAGが実際に必要とするもの
素朴な版、すなわちすべてを埋め込み、上位いくつかを取得し、詰め込むだけ、はデモでは機能し本番では失望させます。本物にする要素はこうです。
- 理にかなったチャンキング。 上記のとおり。
- 十分な、しかし多すぎない文脈。 より多くの文章を検索することが常に良いわけではありません。無関係な文章はモデルの気を散らし、有用なものを注意の外へ押し出します。スイートスポットがあり、それは人々が思うより小さいのが普通です。
- グラウンディングの指示。 提供された資料からのみ答え、資料に答えが含まれないときはそれをはっきり言うようモデルに伝える。これが、検索を自信たっぷりの推測ではなく信頼できる答えに変えるものです。
- 出典の提示。 どの文章が使われたかを返すと、人間が答えを検証できます。重大な事柄には不可欠で、それ以外のどこでも静かに信頼を築きます。
あなたのRAGが良いかどうかを見分ける方法
ほとんどの失敗は検索の失敗なので、検索を生成と分けて評価しましょう。実例に対して問う二つの問いです。
- そもそも適切な文章が検索されたか。 答えが検索された集合になければ、どんな巧妙なプロンプティングも生成段階を救えません。
- 適切な文章が与えられたとき、モデルはそれを忠実に使ったか。 検索は良かったのに答えがずれたなら、問題は検索ではなくグラウンディングです。
評価をこう分けることが、どちらの半分を直すべきかを教えます。一緒くたにすると、「間違っている」としか分からず、それは行動につながりません。
RAGが直さないこと
RAGは答えを供給されたテキストに根づかせます。モデルをより上手に推論させはせず、真実を保証もしません。元の文書が間違っているか古ければ、答えはまさに同じ口調で自信たっぷりに間違います。可動部分も増やします。インデックス化の段階、検索の段階、そしてそれぞれ監視すべき独自の失敗モードです。RAGは、答えが具体的で、変化する、または私的な情報を反映しなければならないときに適した道具です。モデルがすでに十分に知っていて、ただより良いプロンプトが必要なだけのときには過剰です。
RAGが向かう先
RAGの最前線は、ほとんどが検索をより賢くすることに関わっています。いつ検索するかを決めること、複数回に分けて検索すること、モデルに自らの検索クエリを発行させること、そして結果をジェネレーターに届く前に再ランク付けすること。これらは能力と複雑さを等しく加えます。その下では第一原理の見方がなお成り立ちます。どれも、モデルが答える前に、より良い資料をその前に置く方法なのです。
まとめ
しばらく製品の積み重ねを忘れましょう。RAGとは、モデルが答える前に適切な資料を読ませる規律です。埋め込みとベクトルストアは人気の実装であって、本質ではありません。検索を正しくし、注意深くチャンク化し、根づいたままでいるようモデルに指示すれば、RAGは記憶から推測するモデルを、証拠から答えるモデルに変えます。しかもあなたが確認できる出典つきで。