People keep writing obituaries for RAG. You have probably seen the headlines by now. Long context windows killed it. Agents replaced it. The whole pattern is obsolete. The truth is narrower and far more useful. RAG did not die. What actually collapsed was the comfortable illusion that you could split a pile of documents into chunks, feed them into a vector database, and suddenly own a reliable, truthful AI.
数年前に、その提案はシンプルで魅力的なものでした。ナレッジベースを埋め込み(Embed)、LLMに接続する。質問を投げれば、モデルが取得したデータのみを使用して回答する様子を眺める。制御されたデモや小規模なFAQボットであれば、正直なところ、これは機能しました。20ページのヘルプデスクマニュアルや、整理された社内Wikiなどです。ボットはおおよそ正しい段落を引用し、経営陣はパイロット運用を承認しました。しかし、パイロット運用は本番環境ではありません。プロトタイプには、実際のビジネス運用における「傷跡」が含まれていないのです。
本番データは混沌としています。同じトラブルシューティングのメモが、微妙に異なるタイムスタンプや矛盾するステータスラベルを伴って、十数ものファイルにコピーされていることがあります。ページをまたぐ複雑なテーブルもあり、スプリッターがその真ん中で切断してしまうと、意味不明な内容になってしまいます。また、謝罪することなく矛盾を保持し続けます。2023年のポリシーマニュアルにはこう書いてあり、2024年3月の修正案には別のことが書いてある。古いPDFはアーカイブされていない。チャンク化、保存、検索という素朴なパターンは、すべての段落を孤立した島として扱います。階層構造、バージョン履歴、あるいは矛盾の解決といった概念が欠落しているのです。モデルがハルシネーション(幻覚)を起こすのは、LLMが壊れているからではなく、受け取ったコンテキストが断片化されていたり、孤立していたり、あるいは完全に間違っていたりするからです。
一部の観測者は、数百万トークンのコンテキストウィンドウによって、検索(Retrieval)は無意味になったと主張しています。彼らの主張は単純明快です。「コーパス全体をプロンプトに放り込み、モデルにすべてを読ませればいい」というものです。これはエレガントに聞こえますが、危険なほど楽観的でもあります。モデルは技術的には短編小説に相当する量のテキストを読み込むことができるかもしれませんが、その広大な領域の中から特定の条項を一つ見つけ出すことは、全く別の能力です。「干し草の山から針を探す」作業は依然として困難なのです。ロングコンテキストウィンドウは利用可能なキャンバスを広げますが、そのキャンバスのどこに何を描くべきかを決定するという困難な作業を解決するわけではありません。問題は単なる「検索」ではなく、常に「コンテキストの組み立て(Context Assembly)」にあるのです。
素朴な検索からコンテキスト・エンジニアリングへ
2026年、この分野は成熟しつつあります。RAGを単一の線形パイプラインとして扱う段階を過ぎ、コンテキストを意図的に設計された「製品」として扱うアーキテクチャへと移行しています。
純粋なセマンティクスを超えたハイブリッド検索。 セマンティックな類似性は、意図を理解するには優れていますが、正確な識別子に関しては精度が低くなります。エンジニアが ERR_CONNECTION_REFUSED のような特定のエラーコードや、v3.2.1 のようなソフトウェアのバージョンをクエリした場合、純粋なベクトル検索では、概念的には似ているが実務的には無関係な結果の海に、正確な一致が埋もれてしまう可能性があります。ここでの進化は明快です。現代のシステムは、埋め込み(Embeddings)と並行して、BM25や転置インデックスなどの手法を用いたキーワード検索を、高密度ベクトル検索と組み合わせています。正確な名称、エラーコード、バージョン文字列、製品IDはキーワード層で捉えられ、概念的なニュアンスはベクトル層で処理されます。
生成前のリランキング(再順位付け)。 検索は本質的に再現率(Recall)に偏りがちです。決定的な「黄金の段落」を見逃すことを恐れるあまり、40〜50個ものチャンクを引っ張ってきてしまいます。しかし、そのノイズのすべてを大規模モデルに投入することは、トークンの無駄遣いであり、重要なシグナルを埋もれさせてしまいます。リランキングは、通常より小規模な第2のモデルを使用して、各候補が特定のクエリに対してどれほど関連しているかをスコアリングすることで、この問題を解決します。上位5つのパッセージだけが次に進み、残りは破棄されます。これは検索と生成の間の精密なフィルターとして機能し、高コストな推論モデルが、本当に重要な内容だけを読むことを保証します。
意味を保持するコンテキスト検索。 チャンク化は、ある種暴力的な行為です。スプリッターは、段落をセクションヘッダー、表のキャプション、周囲の免責事項、あるいは意味を修正する脚注から切り離してしまうことがあります。コンテキスト検索は、断片がモデルに届く前に、それらを豊かにすることでこの問題を軽減します。情報の出所(Provenance)を示すメタデータを先頭に付加するのです。例:This excerpt belongs to the Q3 2024 incident report, Database Outage section, Severity Critical.。モデルは単なる浮遊した一文ではなく、文脈の中に位置づけられた情報としてそれを見るようになります。断片は、その本来の立ち位置を取り戻すのです。
インテント(意図)に基づくモジュール型ルーティング。 すべての質問が、ドキュメントで埋め尽くされたベクトルストアに属するわけではありません。パスワードのリセット方法を尋ねるユーザーには、おそらくヘルプ記事が必要です。前四半期に北東部で収益が減少した理由を尋ねるユーザーには、地域的な販売戦略に関する意味的に類似した段落ではなく、データウェアハウスに対するSQLが必要です。成熟したシステムは現在、インテントに基づいてクエリをルーティングし、適切なツールを選択します。手順についてはドキュメント。構造化された分析にはリレーショナルデータベース。トレースのデバッグにはログアグリゲーター。ライブステータスにはAPI。検索レイヤーは単一文化(モノカルチャー)ではなく、ディスパッチャー(振り分け役)となります。
エージェンティックな推論ループ。 一度の検索ステップでは答えられない質問もあります。それらには再定式化が必要です。曖昧な初期クエリは明確化されます。検索された主張は、第2のソースと照合されます。ドキュメントがAPI仕様と矛盾する場合、システムは妥協点を作り出すのではなく、その衝突をフラグ立てします。モデルは、いつ再検索するか、いつクエリを洗練させるか、そしていつ回答するために十分な証拠が集まったかを判断します。これはワンショットの検索ではありません。検索をサブルーチンとして利用する、構造化された推論です。
関係性の問いに対するGraphRAG。 特定のビジネス上の問いは、文章ではなく「つながり」に関するものです。どのコンポーネントの故障がどのダウンストリームのアラートを誘発したか?どのサプライヤーがどの工場に供給しており、代替ルートは何か?組織内の誰がこの特定の予算項目に対して決定権を持っているか?フラットなテキストチャンクは、トポロジー(位相)を保持するように設計されていないため、これらの関係性を平坦化してしまいます。ナレッジグラフはそうではありません。問いが影響力、リネージ(系統)、パターン、またはネットワーク構造に関するものである場合、グラフを辿ることで、どれほど段落検索を行っても再現できないコンテキストが得られます。
真に重要な問い
RAGをめぐる議論を変える必要があります。汎用的なRAGパイプラインをどう構築するかと問うのはやめましょう。モデルが解決すべき具体的なタスクは何か、正確であるためにどのような正確なデータが必要か、そして組み立てられたコンテキストが十分であることをどのように検証するか、と問い始めてください。これらの問いは、データ品質、スキーマ設計、検証ループ、そしてソースのプロベナンス(由来)といった上流工程へとあなたを向かわせます。これらは、あなたのナレッジベースが自動的な消費に適しているかどうかを明らかにします。
RAGは、一度インストールして終わりという単一の線形プロセスではありません。モデルが効果的に推論できるように、適切なコンテキストを組み立てるという規律(ディシプリン)なのです。つまり、検索をライブラリのインポートとしてではなく、システム設計の問題として扱うことを意味します。
ツールはより鋭利になっています。検索はハイブリッドになり、ルーティングはインテリジェントになり、検索結果はランク付けされ、強化され、検証されます。2022年の単純な幻想は、真に有用なものが取って代わるために崩壊しなければなりませんでした。あなたの仕事は、単にデータベースからテキストを検索することではありません。モデルが考え始める前に、モデルが何を必要としているかを知っているシステムを構築することなのです。
もしあなたがこの分野で開発を行っているなら、GyaanSetuの学習コミュニティは、同じ問題を解決している人々と実践的な知見を交換できる場所です:https://t.me/GyaanSetuAi
