RAG は悪いアイデアではありません。私たちは真剣に取り組み、特定のシナリオでは実際に機能させることができました。
昨年、私たちは完全な RAG パイプラインを構築するために数ヶ月を費やしました：3 段階の処理フロー（Extract、Chunk、Embed）と、3 種類の検索戦略（Vector、BM25、Hybrid + Reranking）。テキスト抽出から Rerank モデルまで、すべてのコンポーネントを丁寧に作り込みました。技術的には美しかった。
しかし最終的に、正直な事実を認めざるを得ませんでした：十分ではなかったのです。
この記事は RAG を批判するためのものではありません。私たちが具体的にどのような問題に直面し、その後どう考えが変わったかを率直にお伝えするものです。
問題 1：Embedding モデルのジレンマ
ローカルデスクトップアプリケーションにおいて、Embedding モデルの選択は正解のない問題です。
小さなモデル（パラメータ数 < 500M）はデバイス上で動作させられますが、意味理解の品質が不安定で、専門文書・クロスランゲージ検索・長文書を扱うと再現率が明らかに低下します。大きなモデル（1B+）は品質は良いものの、一般的なノート PC ではメモリとコンピューティングのオーバーヘッドが大きすぎて、常駐プロセスとしてのシステムリソース消費が許容できないレベルになります。
デスクトップアプリにはサーバーという逃げ道がありません。「動かせる」か「精度が高い」かの妥協を強いられます。どちらかを選べば、もう一方は諦めなければなりません。このジレンマはサーバーサイドアプリには存在しませんが、ローカルファーストアプリには解決策がありません。
問題 2：ドメイン語彙への非感応性
ベクトル意味検索には根本的な弱点があります：専門用語の理解が苦手なのです。
理由は単純です。Embedding モデルは汎用コーパスで訓練されており、コードの関数名、医療略語、法律条項、製品型番といった語彙は訓練データへの出現頻度が低く、ベクトル空間での位置が不安定です。
実際の動作はどうなるか？ユーザーが「RLHF」と検索しても、「Reinforcement Learning from Human Feedback」と記載された文書が必ずしもヒットしません。「LTV」で検索しても、「顧客生涯価値」について書かれた分析レポートを見つけられないこともあります。特定の製品型番を検索すると、ベクトル検索はその正確な意味を捉えられません。
これは設定や調整で解決できる問題ではありません。業界の一般的な対処法は Embedding モデルのドメインファインチューニングですが、これは特定分野に限定されており、特定 BtoB 領域でしか機能しません。
Embedding の強みはあいまいな意味マッチングです。弱点はまさに正確な語彙マッチングです。ユーザーの実際のニーズはその両方を必要とします。
問題 3：Rerank のコスト
低い再現率と精度の低さは RAG パイプラインの二大課題です。精度問題への業界標準の解決策は、最終ステップとして Rerank モデルを追加することです。
私たちもこれを実装しました。そして問題が解決されたのではなく、場所が変わっただけだと気づきました。
Rerank モデルは Embedding モデルよりも重く、遅いです。導入すると検索チェーン全体のレイテンシが大幅に上昇し、ローカルアプリケーションでは特に顕著です。さらに重要なことに、Rerank モデルも汎用コーパスで訓練されており、同じドメイン語彙の問題を抱えています。すでに取得された候補を並べ替えるだけで、そもそも最初に取得されなかった文書を回収することはできません。
結果：パイプラインは遅くなり、アーキテクチャは複雑になり、根本的な問題は残りました。Rerank を追加した後、ランキング品質の改善は非常に限定的で、むしろ BM25 の貢献がほぼ見えなくなってしまいました。
問題 4：断片化したコンテキスト
チャンキングは RAG が避けられない問題の核心です。
文書を固定サイズのセグメントに切り分けると、各セグメントは前後の文脈から切り離されます。AI が受け取るのはレポートの途中から切り出した一節で、どのセクションに属するのか、前の段落は何を説明していたのか、後に結論が続くのかもわかりません。
最悪のケース：重要な段落がちょうど 2 つのチャンクの境界をまたいでいる場合、両方のチャンクが部分的にマッチしますが、どちらも不完全です。AI は答えに触れているが完全ではない 2 つの断片を受け取り、もっともらしいが正確ではない回答を生成します。
対処策はたくさんあります：チャンクのオーバーラップを増やす、親チャンク検索、Small-to-Big インデックスなど……それぞれのパッチは 1 つの次元を改善しますが、新たなコストをもたらします——より多くのトークン、より複雑なパイプライン、デバッグが難しい動作、そして汎用性の低下です。
これらのパッチを積み重ねた結果、複雑でエラーが起きやすく、それでも十分ではないシステムが完成しました。
問題 5：ドキュメントタイプごとの特別処理
汎用チャンキング戦略はドキュメントタイプによって大きく結果が異なります——これは当初十分に予測できていませんでした。
論文は Abstract + 本文 + References の構造を持ちます。書籍には章の階層とヘッダーがあります。契約書には番号付き条項と相互参照があります。コードドキュメントには API リストとサンプルコードがあります。スプレッドシートでは意味のある「内容」は列名とデータ型であり、セルの値ではありません……
固定ウィンドウチャンキングはこれらの構造を理解しません。分割点は意味の中間に落ちることが多く、見出しと本文を分離したり、条項番号と条項テキストを切り離したり、テーブルヘッダーとデータ行を分割したりします。
各ドキュメントタイプには本来、完全に異なる処理ロジックが必要です。しかし、すべてのタイプに特化したパーサーとチャンキング戦略を書くのは膨大な作業量であり、メンテナンスコストも高くなります——それをすべて完成させたとしても、結果は「汎用戦略よりも少し良い」だけで、依然として断片化しています。
問題 6：AI Agent 使用体験の劣悪さ
上記 5 つの問題はそれぞれ単独では許容範囲内ですが、RAG を実際に AI Agent に接続して使用すると、すべての問題が重なり合い、結果は非常に悪くなります。
実際のシナリオ：AI がユーザーの契約書分析を手伝っており、search() を呼び出して関連条項を取得し、10 個のチャンクが返ってきます。いくつかのチャンクは部分的に関連していますが、情報が不完全です。AI は次にどうすればいいかわからず、検索クエリを調整して再試行します。また 10 個のチャンク——まだ不十分です。別のクエリ、また検索。
毎回の検索はブラックボックスです：AI は何のキーワードが必要な情報を見つけるかわからず、その文書に情報が存在するかどうかも、答えにどれくらい近いかもわかりません。この非効率はエージェントの能力不足ではなく、ツールの設計が合理的な意思決定をサポートしていないことが原因です。
RAG は「ユーザーが直接質問する」シナリオ向けに最適化されています。「エージェントが自律的に探索する」シナリオのために設計されたものではありません。
業界も移行しつつある
これらの問題は私たちだけのものではありません。業界では明確な対応トレンドが生まれています。
Microsoft の GraphRAG はコンテキストの断片化に対処するために知識グラフを導入し、関連するエンティティと関係を断片の継ぎ合わせではなく明示的に保存します。
PageIndex は固定サイズのチャンキングを廃止し、ページ単位のインデックスを採用して文書の自然な境界を保持します。
Agentic RAG は AI が固定パイプラインではなく自律的に検索戦略を決定しようとするものです。方向性は正しいですが、RAG アーキテクチャの上に Agent ロジックを重ねると複雑性が倍増します。
最も根本的な転換は Claude Code と Manus から来ました。彼らは RAG を完全に放棄し、最も原始的なアプローチに戻りました：Glob + Grep + Read。ファイルを見つけ、キーワードを検索し、内容を読む。ベクトルデータベースなし、Embedding モデルなし、チャンキングパイプラインなし。結果は実際にはより良くなりました。
これで、あることが明確になりました：RAG の設計前提は「LLM は十分に賢くないので、情報を事前処理してあげる必要がある」というものです。これは GPT-3.5 の時代には合理的でした。しかし今日の LLM は、ツールを自律的に使用して複数ステップの検索タスクを完了する能力を持っています。彼らに必要なのは事前に断片化されたコンテンツではなく、手がかりです：ファイルはどこにあるか、構造はどうなっているか——そうすれば、何を読むか、どれだけ読むかを自分で決めることができます。
私たちの解決策：Outline Index
Glob + Grep + Read はコードベースには効果的ですが、ユーザードキュメントには機能しません。コードベースでは src/services/auth.ts というパスが認証サービスのコードだと教えてくれます。しかし Q4-2024-総括(改訂版)(最終版).docx では、パスはほとんど何も教えてくれません。さらに PDF と Word はバイナリ形式で、grep では読めません。
そこで私たちの問題はこうなりました：ドキュメントにも同様の「目次インデックス」を構築し、AI が search → outline → read のパターンでファイルを段階的に探索できるようにできないか？
私たちはこのアプローチを Outline Index と呼んでいます。
核心的なアイデアを一言で：AI のために情報を事前断片化するのではなく、地図を渡す。
各ドキュメントについて、文書のメタデータ（タイトル、著者、キーワード、要約）と構造アウトライン（セクション見出し、階層、行番号範囲）を含む構造化された「プロファイル」を構築します。AI は 3 つの層を通じてドキュメントにアクセスします：
- search：関連文書を検索し、メタデータ付きのファイルリストを返す——約 50 トークン/ファイル
- outline：文書の構造マップを表示——約 200〜500 トークン/ファイル
- read：指定したセクションの本文を正確に取得——オンデマンドで読み込み
これは人間が読む方法と完全に一致しています：本を見つけ、目次を確認し、関連する章に飛んで精読する。このプロセス全体を通じて、AI は完全なコンテキストを持ち、文書のどこにいるかを把握し、「もう少し読む」ことを決断でき、複数の文書を横断比較することもできます。
従来の RAG との比較：同じシナリオで、Outline Index は約 800〜3,400 トークンを消費しながら、完全なコンテキストを持つ正確な情報を AI に提供します。従来の RAG は 10 個の事前切り出し断片で 4,000〜6,000 トークンを消費し、AI は文書の構造について何も知りません。
有益な副産物：Embedding の対象が生のテキストチャンクから Outline Index 自体に変わります。各ドキュメントには 1 つのベクトルだけが必要です。10,000 ドキュメント ≈ 10,000 ベクトル ≈ 30MB のストレージで、検索速度も大幅に向上します。
ドメイン語彙問題については、BM25 全文検索がその隙間を埋めます。デュアルパス検索（正確マッチング用の BM25 + 意味理解用のベクトル検索）を RRF で統合することで、Rerank モデルが完全に不要になります。
Outline Index は Linkly AI のコア技術です。実装の詳細に興味がある方は、こちらの技術記事をお読みください：Outlines Index：AI Agent への大量文書の段階的開示アプローチ。
実際の効果を体験したい方は、Linkly AI と linkly-ai-cli をダウンロードして、AI クライアントに接続してみてください。実際の結果は RAG よりも大幅に優れています。
Linkly AI チームより。