2024年末時点でのRAG情報整理
本記事の目的
基本的な RAG の話は、2023年にLLMがブレークしてすぐに一般的なものとなった。
その後、 RAG の基本は変わっていないようでありつつ、 Graph RAG のような話題も出てきている。
現時点での RAG の最新情報を収集・整理し、2024年の1年間で RAG 周りの新たの情報（差分）を棚卸ししておく。
素敵なRAGの資料
ここによくまとまっている。
RAG の基本
AWS をベースにした話にはなっているが、ここ👇️で紹介されているスライドは RAG についてわかりやすくまとめられている。
上記👆️では、あくまでも以下のような「2023年以前の基本知識」をベースにして不足のない考え方をベースに説明されている
ナレッジとして蓄積したい情報をベクトルDBに事前に保存しておく
ナレッジに対して検索処理を行う
その結果に対してLLMでまとめさせる（一つのまとまった文章という形でアウトプットする）
※本記事では、基本の基本として、RAGは以下👇️のような仕組みであるものとする。
RAG ＝ 質問 → 検索 → 生成 → 回答
ナレッジベース・ベクトルDBといった領域を構築するにあたって、AWSのサービスを用いる場合はどういった選択肢があるか、が上記では少し細かく説明されている。
下記👇️では、ナレッジベース（ベクトルDB）に対して検索処理を行う際の「検索クエリの生成」の手順なども含め、ハンズオンとして例示してくれている。
単純にナレッジベースに問い合わせのため文章を投げ込むのではなく、その問い合わせ内容文章から必要なキーワードを抽出・配列化してこれをナレッジベースに渡しているようである。
RAGはベクトルDB構築を前提としない
別にナレッジベースとしてベクトルDBを構築することはRAGの前提ではない。
Web上からキーワードで検索をかけたり、TeamsやSlackのような社内チャットに対して検索をかけてその結果を返してもいい。
という例を示してくれたのが下記👇️
下記👇️では、Difyのエージェント機能を用い、Wikipediaをキーワード検索したり、SerpAPIを用いてGoogle検索する形で、それらをナレッジとして用いて、最終的に回答を生成している。
RAGの分類
改めて本記事の本題。
最近は RAG と言ってもいろんな RAG がある、というか、「XXX RAG」みたいな用語がたくさんあってややこしい。いつの間にか RAG から取り残されているのでは、と不安になる。ので、棚卸しをする。
まずは3つ。下記👇️記事によれば、RAGは大きく3つに分類される
以下の3つの分類となる
Document RAG（ドキュメントRAG）
SQL RAG
Graph RAG
それぞれ、
Document RAG → ベクトルDBやWeb上の記事、チャットログ
SQL RAG → RDB
Graph RAG → グラフ DB
といった形でバックエンドに構えるDBが異なるデータ構造のものになっている。
ベクトル DB がベクトルで関連情報を紐づける一方で、グラフ DB はグラフ構造によって関連情報を紐づけている感じ。
SQL RAG は毛色が異なるというか、SQLを用いたデータ収集に際して「自然言語→SQL」の翻訳をLLMに頼っている、という感じ。
Document RAG
前述までの基本的な RAG。
SQL RAG
「プロンプトを下にLLMがSQLを生成→DBに対してクエリを実行・結果取得→その結果をLLMが処理」といった流れ。
Graph RAG
グラフ DB（Graph DB、ナレッジグラフ）をナレッジベースとして用いている。
次は複合技。
Hybrid RAG
ベクトルDB検索の弱点をナレッジグラフを用いた検索（GraphRAG）で補うハイブリッドなしくみ。
ここでいう弱点は以下のように例示されている
ベクトル検索の弱みはいくつかあります。例えば、専門用語に弱いこと、前後の文脈を理解したうえでの回答に弱いことです。
…
RAGは便利ですが、従来のベクトル検索のみを使ったRAGでは、専門用語に弱かったり、前後の文脈を捉えきれなかったりなど弱みがあります。
ニッチな用語の場合、単語間の距離をベクトルで適切に整理できない、ということかな？
文章を切り刻んだものをナレッジベースに保存しており、その切り刻まれた文章の断片を検索・取得しているので、文脈が捉えられないのは確かにそう。
手法は以下の通り説明されている。
【事前にやっておくこと】
・RAGに使いたい文書(論文内では決算資料)について、テキスト抽出
・抽出されたテキストを、チャンクに分割しベクトル化（VectorRAG用）
・文書からナレッジグラフを構築（GraphRAG用）
【ユーザーが質問を入力して来たとき】
・VectorRAGで関連する文書チャンクを検索
・GraphRAGで関連する知識グラフのサブグラフを検索
・1と2の結果を統合してLLMに渡し、回答を生成させる
（文書からナレッジグラフを構築するプロセスって普通にしんどいのでは…？）
Hybrid RAG を説明した前述の記事では、昨今のRAGへの期待と、それがDocument RAG のみでは解決が難しい天、 その対策として期待されている Graph RAG の課題感について言及したうえで、それらを解決する方法論の一つとして Hybrid RAG を説明している。
弊社では、法人向けにRAGシステムを提供しているので、「RAGで決算書類を読んで欲しい。10年分まとてほしい。」という要望をいただくことが（本当に）よくあります。こういう要望に対して、従来のベクトル検索型のRAGだと対応しきれません。（専門用語・構造・時系列比較など、従来のRAGだと苦手そうな理由が、すぐにたくさん思い浮かびます...）
こうしたニーズから、最近は「GraphRAG」というアプローチが人気なのですが、一方で「これ単体だと実用に耐えないな」という感覚がありました。HybridRAGは、この課題に対する、非常にシンプルなアプローチです。かなりシンプルなので、今後も派生したアプローチが多くでてきそうに感じます。
（個人的には、今後LLMの純粋な性能が向上して、一気に大量のテキストを高速にインプットできるようになり、そのうえで質問すればいい感じに回答してくれるようになる、と思っていたりする。
本当はファインチューニングでやりたい「専門知識の注入」なんかが、実はファインチューニングではうまくいかない現状がある。
少量のテキストを専門知識として注入するだけなら、インコンテキストラーニングでよく、大容量の場合はRAGに頼っている、という状況である。
RAGはLLMの成長の過程で一時的に必要になっている急場しのぎの対処法、という印象を持っている。ので本当はRAGに時間をかけたいと思わない。）
他にも、以下で Adaptive-RAG や Self-RAG という言葉が説明されている
ユーザーからの問い合わせ（プロンプト）に対して、まず「内容を分類する」といったステップを噛ませて後続処理を切り替える、というものである。専用のファインチューニングされたモデルを用いることを想定した記載ではありつつ、考え方は簡単に取り入れることは可能そう。
Adaptive-RAG
ユーザーからの質問について、簡単、中程度、複雑の3つに分類し、それぞれの場合で最適な回答手法を適用します。
・簡単な質問 → 検索なしでLLMのみで回答
・中程度の質問 → LLMと1回の検索を組み合わせて回答
・複雑な質問 → LLMと複数回の検索を繰り返し、推論を重ねて回答
この手法のキモは、質問の難易度を自動で判定するClassifier（分類器）です。
Self-RAG
①RAGするかどうかをまず判断し②取得ドキュメントを批判的に選別するという手法「Self-RAG」を提案しています。Self-RAGの主なポイントは以下の4点です。
【事前にやっておくこと】
LLMをファインチューニングし文章の生成の途中でreflection tokenを混ぜ込めるようにする
Self-RAGでは、独自にファインチューニングしたモデルを生成に利用します。
【ユーザーが質問を入力して来たとき】
ユーザーの質問に対し、まず検索の要否を自己判断
不要と判断した場合は文書検索はせず、独自の知識だけで回答を生成します。以下、検索した場合を説明します
検索で取得した複数の文書を基に、それぞれ回答生成
それぞれのドキュメント1つずつ+元の質問をもとに、LLMが複数の回答を生成します。
回答を評価、最も良い応答を選択
生成された複数の回答について、質問にして関係あるか、証拠になるか、有用かどうかを判断し、最もスコアの高い回答を採用します。
より抽象的な包括的な用語として エージェンチック RAG という言葉のも最近はあるらしい。
エージェンティック RAG
RAG が持つ課題点を解決するための手法、らしい。
エージェンティック RAG のキーとなる要素は以下の通り。
エージェンティックRAGの最大の特徴は、AIエージェントの自律的な判断能力にあるといえるだろう。AIエージェントは、LLM（大規模言語モデル）をベースに、メモリ機能、プランニング機能、そして外部ツールへのアクセス機能を備えている。これにより、単純な情報検索と生成を超えた、より高度な情報処理が可能となる。
代表的なAIエージェントの1つがReActと呼ばれるフレームワークだ。ReActは「Reason（推論）+Act（行動）」の略で、AIエージェントがユーザーのクエリに対して以下の3つのステップで対応する。まず「Thought（思考）」でクエリの意図を理解し、次のアクションを決定。次に「Action（行動）」で、決定したアクションを実行。最後に「Observation（観察）」でアクションの結果を評価する。このプロセスを、タスク完了まで繰り返す。
メモリ機能、プランニング機能、外部ツールへのアクセス機能などによる高度な情報処理
「Thought（思考）」→「Action（行動）」→「Observation（観察）」の一連のプロセスを自己完結で実現
上記により、より正確で信頼性の高い回答を生成できるものを指す言葉らしい。
ざっくり、「最近のRAGでやってること」「Difyでやれるやつ」くらいのイメージ。
その他、RAGをまとめている記事
2024年を振り返りつつ、RAG・AIの今後をまとめてくれている記事
以上
表面的な用語や動向のまとめはある程度できたけど、 Graph RAG についてはもっと具体的なイメージを持てる必要がありそう。
「イメージできないものは実現できない」と一級魔法使いたちも言っている。
次の記事では Graph RAG を深堀って実際に手を動かして整理したいと思う。