RAG勉強中のエンジニアがGeminiに聞いて作ってもらった、RAG関連技術のキャッチアップ・整理方法

業務でRAG（検索拡張生成）の構築を担当しているエンジニアです。

ここ最近、RAG界隈の進化スピードが早すぎませんか？ 「GraphRAG」「Corrective RAG」「Self-RAG」「Book RAG」……。 次から次へと新しい「〇〇RAG」が出てきて、論文を追うだけでも精一杯。これらをすべて理解し、実務に適用しようとするとパンクしてしまいます。

そこで、生成AI（Gemini）を壁打ち相手に、「どうすればこの技術の奔流に溺れず、社内の『RAG有識者』として戦えるか？」を相談してみました。

その結果たどり着いた「技術を整理する5段階のメンタルモデル」と、「AWSマネージドサービス利用者としての現実的な戦い方」が非常に腹落ちしたので、備忘録としてまとめます。

1. 「〇〇RAG」に溺れないための「5段階モデル」

結論から言うと、無数にあるRAGの手法は、処理フローの「どこに介入しているか」で分類するとスッキリ理解できます。

従来のRAGは「検索して(Retrieval) → 生成する(Generation)」の2ステップでしたが、最新のAgentic RAG（エージェント型RAG）などは、その前後に「判断」や「評価」が挟まっています。

Geminiと壁打ちして整理したのが、以下の「RAG 5段階モデル」です。

RAGの5段階プロセス

1. 質問の判断 (Router/Transformation)
   • 検索する前に、「この質問は検索が必要か？」「キーワードを修正すべきか？」を判断・加工するフェーズ。
2. 資料の検索 (Retrieval)
   • 実際にDBからドキュメントを引っ張ってくるフェーズ。
3. 資料の評価 (Grader/Re-rank)
   • 検索結果を見て、「この資料は本当に質問の答えになっているか？」を採点・選別するフェーズ。
4. 回答の生成 (Generation)
   • LLMが資料を元に回答文章を作成するフェーズ。
5. 回答の評価 (Refiner/Self-Correction)
   • 生成された回答を見て、「ハルシネーション（嘘）はないか？」をチェックし、ダメならやり直させるフェーズ。

ニュースを見たときの脳内振り分け

今後、新しい技術用語を見たら、この5つの箱のどこに入るかだけを確認します。

• HyDE: 質問から仮想回答を作って検索する技術 → 「1. 質問の判断」の工夫。
• GraphRAG / BookRAG: データの持ち方を工夫して検索精度を上げる → 「2. 資料の検索」の工夫。
• CRAG (Corrective RAG): 検索結果がダメならWeb検索に切り替える → 「3. 資料の評価」の工夫。
• Self-RAG: 自分で自分の回答を評価する → 「5. 回答の評価」の工夫。

これだけで、「あ、これは検索ロジックの話ね」「これは事後チェックの話ね」と瞬時にカテゴライズでき、情報の洪水に飲まれなくなりました。

2. AWSユーザーとしての「戦い方」と「待ち方」

私は現在、AWS Bedrock Knowledge Base + Aurora というマネージドサービス構成で開発しています。 Kendraのような完全ブラックボックスよりは柔軟ですが、全てを自前で作る（フルスクラッチ）ほどリソースはありません。

この環境において、「RAG有識者」としてどう振る舞うべきか？ 結論は、「プロンプトでできることは今すぐやる。重い実装はAWSのアップデートを待つ」です。

「今すぐやる」技術（プロンプト・設定ベース）

実装コストが低く、効果が出やすいものは積極的に取り入れます。

• ハイブリッド検索 (Hybrid Search):
  • AWSの設定をONにするだけ。型番や固有名詞の検索漏れを防ぐには必須。
• HyDE / RAT (Retrieval Augmented Thoughts):
  • これらはアルゴリズムに見えて、実は「プロンプトエンジニアリング」で実装可能です。
  • Bedrockのプロンプトテンプレートを書き換えて、「回答の前にステップバイステップで思考して」と指示するだけで、推論精度（RAT的な挙動）を上げられます。

「待つ」技術（データ構造・パイプラインベース）

実装コストが高く、メンテナンスが地獄になりそうなものは、あえて「待ち」を選択します。

• GraphRAG / BookRAG:
  • ドキュメントを解析して「ナレッジグラフ」や「ツリー構造」を作る技術。
  • これを自前で実装するのは「差別化につながらない重労働（Undifferentiated Heavy Lifting）」です。
  • これらは近い将来、AWSが「ドキュメントをアップロードしたら勝手にグラフ化してくれる機能」として提供してくれることを期待し、今は概念の理解に留めます。

3. まとめ：社内有識者としてのスタンス

技術のキャッチアップで重要なのは、すべての論文を詳細に読み込むことではなく、「今の自社の課題は、5段階のどこにあるか？」を特定できる目を持つことだと気づきました。

• 「検索で変な資料が引っかかる」なら、3. 資料の評価（Re-rankなど）を検討する。
• 「資料はあるのに回答がトンチンカン」なら、4. 回答の生成（プロンプト）を見直す。

この視点さえあれば、日々アップデートされるRAG技術も「敵」ではなく、課題解決のための「手札」として冷静に見ることができます。

これ以上自前で複雑なコードを書きたくない私にとって、この「5段階モデル」×「AWS標準機能待ち戦略」は、精神衛生上とても良い指針になりそうです。