AI · Retrieval · RAG · Forecasting · Mechanism

ルーティングが検索に先行する、埋め込み次元ではない

KDnuggets の RAG 失敗調査は、埋め込みの過剰エンジニアリングがコストを悪化させることを示す。欠けているメカニズムは検索前の明示的ルーティングである——Theorem 3 を検索に適用し、Everythink のトポロジーを上流の類比として。

著者 Everythink Studio team2026年6月30日2 分で読了

ルーティングが検索に先行する、埋め込み次元ではない

KDnuggets の 2026 年 6 月の検索拡張生成の失敗に関する調査は、あるグローバル製造企業が RAG システムに 40 万 USD を予算割り当て、初年に 120 万 USD を費やし、技術文書の問い合わせで 23% の精度に終わり、プロジェクトを打ち切ったと報告している。記事の診断は構造的であり、チューニングの次元の話ではない：検索の無関連性、コンテキストの汚染、そしてどの埋め込み次元でも解決できないチャンクサイズの衝突。その処方箋は問い合わせ種別によって選ばれた 4 つのアーキテクチャであり、支えとなる一文は「鍵となる変更はルーティングを明示的にすることです。各問い合わせは、いかなる検索が実行される前に分類されます。」(Nate Rosidi、KDnuggets、「Your RAG Pipeline Is Probably Useless. Here's a Better Alternative」、公開 2026-06-29、取得 2026-08-23、https://www.kdnuggets.com/your-rag-pipeline-is-probably-useless-heres-a-better-alternative)。Honest Architect はこの文章を検索に適用された Theorem 3 として読む：ある性質（事実的関連性）は、そのメカニズム（検索前の明示的ルーティング）が実装され測定されている時に正確に保証される——そしてそのメカニズムを欠いたデザインに埋め込み次元を追加しても、失敗を軽くするのではなく高くするだけである。

[UNIQUE INSIGHT]: オーバーエンジニアリングの罠は Theorem 3 の縮図である。関連性を実装しないメカニズム（より高次元の埋め込み、より多くの再ランキング、多段階検索）をさらに追加して、事実的関連性を保証することはできない。関連性はルーティングの性質である——この問い合わせはこのコーパス、このバージョン、この文書に属するか？——類似性の性質ではない。間違ったメカニズムをスケールしても、性質を産まずにコストを蓄積するだけである。

主要な要点

検索の無関連性はメカニズム欠落の失敗である。Theorem 3：性質事実的-関連性は、検索前に問い合わせを正しいコーパス、バージョン、文書種別にルーティングすることで保証され、ベクトル類似性では保証されない。記事：育児休業の問い合わせが 2022 年のポリシー、2024 年のポリシー、文化ブログ記事を返し、どれも埋め込み距離が高いのに、どれも答えていない。Production ✅（診断）。

コンテキストの汚染はメカニズム欠落の失敗である。Theorem 3：性質矛盾-露呈はバージョンルーティングと矛盾検出で保証され、チャンクを混ぜることでは保証されない。記事：検索器が矛盾するポリシーバージョンからチャンクを返すと、モデルは「一つを選び、両方を混ぜ、自信に満ちた統合を提示する」そして「ユーザーもモデルもそれを知らない」。Production ✅（診断）。

チャンクサイズの衝突は構造的であり、チューニングできない。再現率は 100–256 トークンの小さなチャンクを必要とし、一貫性は 1024 以上を必要とする。二つの性質がパラメータを反対方向に引くトレードオフを、どの埋め込み次元も解決しない。Production ✅（構造的主張）。

オーバーエンジニアリングは失敗を悪化させる。記事：2025 年のエンタープライズ RAG の初年失敗率 72%、40 万から 120 万 USD への予算超過、精度 23%、ある医療企業で 6 か月目に月額 7.5 万 USD のベクトルデータベースコスト。壊れた検索デザインに複雑さを追加することは「計算コストを上げ、より有用な問い——検索アーキテクチャがそもそも正しい選択だったか——を遅らせる」。Partial ⚠️（数値は調査引用、Everythink が独自に検証していない）。

ルーティングが検索に先行する。Self-Route（EMNLP 2024）は、検索が実行される前に問い合わせが完全なコンテキストを必要とするかフォーカス検索を必要とするかを分類する、ハイブリッド検索と再ランキングで 15% から 30% の精度改善が報告されている。Theorem 3：性質問い合わせ-ごとの-正しい-戦略は「分類してから検索」で保証され、構築時に一つの戦略に固定することでは保証されない。Production ✅（形式）；Partial ⚠️（特定のパーセンテージ）。

「The space is the router」は RAG に欠けている上流のルーティングメカニズムである。Everythink の network→community→room トポロジーは、何かが応答する前に問い合わせを正しいコンテキストにルーティングする——Self-Route と同じ形式で、一つ上流のドメイン。Partial ⚠️（同じ形式——応答前にルーティング——別ドメイン）。

範囲：民生/防衛。検索アーキテクチャは民生インフラである。token、wallet、community-credit の結果は一切約束されない、それらは Roadmap 🔵、Howey 審査待ち。Everythink は予測プラットフォームであり、RAG ベンダーではない、ドメイン横断の類推は Partial ⚠️ の図示であり、KDnuggets、StrataScratch、Microsoft GraphRAG への支持ではない。

RAG が失敗する時：性質は保証されていない

記事は、デモが隠す失敗で始まる。ユーザーが育児休業について尋ねる。検索器は 2022 年版、2024 年版、文化ブログ記事を返す。各チャンクは問い合わせと語彙を共有するため埋め込み距離が高い。どれも問いに答えない。モデルは検索された内容が時代遅れか題目から外れていることを知らない、チャンクを自信に満ちた詳細で事実的に誤った回答に混ぜ合わせる。記事はこれを「事実的関連性のない主題的類似性であり、本番の RAG システムにおける支配的な失敗モードである」と呼ぶ。

Honest Architect はこれを Theorem 3 として読む。性質は事実的-関連性である。システムが実装するメカニズムはベクトル-類似性であり、それは答え-が-問い-に-似るを保証し、事実的-関連性は保証しない。コーパスが小さく、最新で、単一バージョンである時——デモの事例——両者は一致する。コーパスが複数バージョン、題目外の語彙の一致、矛盾を含む時、両者は分岐する。システムは類似チャンクを検索することで関連性を主張する、メカニズムは関連性を実装しない、ゆえに性質は保証されない。Production ✅（診断）。

より微妙な失敗、コンテキストの汚染は同じ形式である。エンタープライズのナレッジベースは同じポリシーを複数バージョンで保持する。検索器は両方からチャンクを返す。モデルは「矛盾を表面化しない。一つを選び、両方を混ぜ、自信に満ちた統合を提示する。読者は回答を得る。その回答は間違っているかもしれない。ユーザーもモデルもそれを知らない。」性質は矛盾-露呈である。メカニズムは混ぜて-統合するである。どのメカニズムも矛盾を検出しない、ゆえに性質は保証されない。システムは回答を産出する、正しいと知られた回答は産出しない。Production ✅。

[PERSONAL EXPERIENCE]: 2016 年から HAI Engine を構築してきて、我々は別のドメインで同じ教訓を学んだ。予測はより多くのデータの上で計算することで関連性を持つようになるのではない、いかなるモデルが実行する前に問いを正しい部屋——正しいコミュニティ、正しくスコープされたコンテキスト——にルーティングすることで関連性を持つ。間違ったコンテキストの上でモデルをスケールすると、自信に満ちた詳細で標的を外した予測を産出する、間違ったチャンクの上で埋め込みをスケールすると自信に満ちた詳細で標的を外した回答を産出するのと同じである。関連性を産出するメカニズムはルーティングであり、体積ではない。Production ✅。

オーバーエンジニアリングの罠は Theorem 3 の縮図である

記事の最も有用なセクションは、エンジニアが飛ばす部分である。標準 RAG が低性能のとき、一般的な修正はそれをより複雑にすることである：より高次元の埋め込み、より高度な再ランキング、多段階検索。記事の評決：「これは問題を悪化させる。」

データは容赦ない。あるグローバル製造企業は 40 万 USD を予算割り当て、初年に 120 万を費やし、精度 23% で終わり、プロジェクトを打ち切った。ある医療企業は 6 か月目に月額 7.5 万 USD のベクトルデータベースコストに達した。記事は 2025 年のエンタープライズ RAG 実装の初年失敗率 72% を引用する。Honest Architect はこれを間違ったメカニズムをスケールするコストと読む。より高次元の埋め込みはより細粒度の類似性を実装し、事実的-関連性は実装しない。再ランキングは並び替えを実装し、矛盾-露呈は実装しない。多段階検索は「検索して-再度-検索する」を実装し、「ルーティングしてから-検索する」は実装しない。それぞれが欠落メカニズムを依然欠いたデザインに計算を追加し、ゆえに請求書が膨らむ間も性質は保証されないままである。Partial ⚠️（数値）；Production ✅（形式——性質を実装しないメカニズムをスケールしても性質は産まれない）。

これは Theorem 3 の縮図である。ある性質は、そのメカニズムが実装され測定されている時に正確に保証される。関連性が性質である。検索前のルーティングがメカニズムである。埋め込み次元は別のメカニズムであり、別の性質を測る。埋め込み次元で関連性を買うことはできない、塗料の厚さで耐火性を買えないのと同じである。記事の一文——「計算コストを上げ、より有用な問い——検索アーキテクチャがそもそも正しい選択だったか——を遅らせる」——は定理の運用版である。Production ✅。

記事はまた、どのチューニングでも解決しない構造的衝突を名指しする：再現率は小さなチャンク（100–256 トークン）を必要とし、一貫性は大きなもの（1024 以上）を必要とし、すべての RAG 設計者は一つを選びトレードオフを受け入れる。Honest Architect はこれを「チャンク-埋め込み-検索」メカニズムの境界として読む——チューニングの問題ではなく、メカニズム選択の問題である。4 つの代替はこの衝突への継ぎ当てではない、それぞれが異なる問い合わせ種別のために異なる性質を保証する異なるメカニズムである。Production ✅（枠組み）；ツール名（Self-Route、GraphRAG）は Partial ⚠️（研究報告、Everythink が独自に検証していない）。

4 つの代替は状況によるルーティングである

ロングコンテキスト：コーパスが収まる時は検索を飛ばす

記事の第一の代替は、検索を完全に飛ばすことである。コーパスがモデルのコンテキストウィンドウに収まるなら、それを読み込ませてモデルに読ませる。あるベンチマーク（arXiv 2501.01880）は、計算が利用可能な時、ロングコンテキスト LLM が QA タスクで一貫して RAG を上回り、チャンクベース検索が最も遅れをとったことを見出した。コストのトレードオフは本物である：100 万トークンで、レイテンシは RAG パイプラインより 30 から 60 倍遅く、クエリごとのコストは約 1250 倍である、プロンプトキャッシングは高トラフィックアプリでロングコンテキストをコスト競争力にできる。意思決定規則：コーパスがウィンドウに収まり問い合わせ量が中程度なら、ロングコンテキストがより綺麗な出発点である、コーパスがウィンドウを超える、レイテンシが SLO を違反する、問い合わせ量が損益分岐点を越える時にのみ検索を追加せよ。Theorem 3：性質完全-コンテキスト-からの-回答はコーパス全体を読み込むことで保証され、そのチャンクを検索することでは保証されない。ルーティング決定（このコーパスは収まるか？）はアーキテクチャ選択に先行する。Production ✅（形式）；Partial ⚠️（コスト乗数）。

メモリ圧縮：検索前に要約する

コーパスがウィンドウに大きすぎる時、記事の第二の代替は生チャンクを引くのではなく、検索前に要約することである。要約ベースの検索は完全なロングコンテキスト手法と同等に性能を出し、チャンクベース検索は両方に遅れをとる。具体的な結果：順序を保つ RAG アプローチが 4.8 万のよく選ばれたトークンを使い、7 分の 1 のトークン予算で、11.7 万トークンの完全コンテキスト検索を 13 F1 ポイント上回った。Theorem 3：性質予算内-の-関連-コンテキストは注入前に関連性へ圧縮することで保証され、生チャンクを検索してモデルがフィルタすることを期待しては保証されない。よく圧縮された関連文書は、接線的に関連する生チャンクのダンプに勝る。Production ✅（形式）；Partial ⚠️（13 F1 ポイント、単一研究）。

構造化検索：検索が実行される前に問い合わせを分類する

記事の第三の代替は、欠落メカニズムに最も直接に対応する。検索が正しいアーキテクチャである時、解決策はより良い埋め込みを均一に適用するのではなく、問い合わせ種別でルーティングすることである。Self-Route、EMNLP 2024 で発表、はモデルに問い合わせが完全なコンテキストを必要とするかフォーカス検索を必要とするかを実行前に分類させる。単純な事実的参照はフォーカス RAG に行く。複雑なマルチホップの問いはロングコンテキストに行く。結果：より低い計算コストでより良い全体精度。このハイブリッド手法を使う適応システムは、ハイブリッド検索と再ランキングで 15% から 30% の検索精度改善を示した。記事の支えとなる一文：「鍵となる変更はルーティングを明示的にすることです。各問い合わせは、いかなる検索が実行される前に分類され、システムはすべての問い合わせを同一の埋め込み問題として扱うのを止めます。」

Theorem 3：性質問い合わせ-ごとの-正しい-戦略はメカニズム（問い合わせを分類し、それから検索する）で保証され、構築時に一つの戦略に固定することでは保証されない。分類が測定であり、ルーティングがメカニズムである。検索前に分類するシステムが性質を実装し、検索して-それから-望むシステムはしない。Production ✅（形式）；Partial ⚠️（特定のパーセンテージ）。

[ORIGINAL DATA]: Honest Architect は Self-Route の「分類してから検索」と Everythink の「the space is the router」の間の構造的並行に注目する。Self-Route は問い合わせを分類し、それから検索戦略にルーティングする。Everythink はいかなるモデルが実行する前に問いをある部屋——network→community→room——にルーティングする。両者とも応答する前にルーティングすることで性質関連性を実装し、ブロードキャストしてフィルタすることではない。違いはドメインと範囲である：Self-Route は一つの検索システム内でルーティングする、「the space is the router」はスコープされたコンテキストのネットワーク全体にわたりルーティングする。Partial ⚠️（同じ形式——応答前にルーティング——別ドメイン）。

グラフベース：関係的問い合わせをグラフにルーティングする

記事の第四の代替は、ある一節を取り出すのではなくデータセット全体の関係を理解することを必要とする問い合わせ向けである。これらはマルチホップの問いである：取締役会が第 3 四半期に覆したのはどの決定か、そしてその都度の表明された理由は何か？単一チャンクはこれに答えない、答えは文書間の接続の中にある。Microsoft Research は 2024 年に GraphRAG を導入した：コーパスから知識グラフを構築し、ベクトルを照合するのではなくエンティティ関係を走査する。トレードオフはコストである——知識グラフ抽出はベースライン RAG より 3 から 5 倍高価で、ドメイン固有の調整を必要とする——主題分析とマルチホップ推論には価値がある、単一節の事実参照にはない。Theorem 3：性質文書間-関係はエンティティと型付き関係、走査、で保証され、ベクトル類似性では保証されない。Production ✅（形式）；Partial ⚠️（コスト乗数）。GraphRAG のメカニズム形式のより深い扱いは、メカニズムを問い合わせ種別に合わせることに関する我々の以前の文章にある。

The space is the router——RAG に欠けたメカニズム

4 つの代替は一つのメカニズムに収束する：検索する前にルーティングせよ。ロングコンテキストはコーパスサイズでルーティングする。メモリ圧縮は予算でルーティングする。構造化検索は問い合わせ種別でルーティングする。グラフベースは関係構造でルーティングする。それぞれが検索メカニズムが実行される前に下されるルーティング決定であり、ルーティングが問い合わせの実際の形状に合致するからこそそれぞれがその性質を保証する。

Everythink の「the space is the router」は同じメカニズムであり、一つ上流のドメインである。network→community→room トポロジーは、何かが応答する前に問い合わせを正しくスコープされたコンテキストにルーティングする。支払い再試行ロジックについてのある部屋で出された問いは、いかなる Sister が起草する前、Oracle が統合する前、いかなる検索が実行する前に、すでに支払いコミュニティ、エンジニアリングネットワーク、関連文書スコープへルーティングされている。ルーティングは構造的であり、問い合わせ時に計算されるのではない。性質関連性はトポロジーで保証され、問いをネットワーク全体にブロードキャストして応答をフィルタすることで保証されるのではない。Production ✅（形式——HAI Engine は 2016 年から本番でこのルーティングを運用）；Partial ⚠️（ドメイン横断の主張）。

Honest Architect は「the space is the router」が検索システムであるとは主張しない。Everythink は予測プラットフォームであり、RAG ベンダーではない。主張は構造的である：失敗した RAG パイプラインに欠けているメカニズムは検索前の明示的ルーティングであり、そのメカニズムは Everythink のトポロジーに本番で証明された類比を持つ。Sisters-to-Oracle パイプラインは記事の map-reduce の下流の類比である：各 Sister が並列に起草し（map 段階）、Oracle がそれらを毎回のマージでエントロピーを伴う正規化された Ensemble に統合し（reduce 段階）、性質校準-予測はメカニズムで保証され、一つのモデルが予測全体を産出することでは保証されない。Partial ⚠️（同じ形式——並列起草と測定マージ——別ドメイン）。

よくある質問

見出しが言うように RAG は無用なのか？

いいえ、そして記事はそう論じていない。RAG は予測可能な仕方で壊れる合理的なデフォルトである——検索の無関連性、コンテキストの汚染、チャンクサイズの衝突——そして修正は埋め込みを過剰にエンジニアするのではなく、問い合わせ種別でルーティングすることである、と論じる。メカニズムは性質に合致しなければならない。Production ✅（診断）；「無用」の枠組みは編集的である。

なぜ埋め込み次元を追加しても検索の無関連性は修正されないのか？

埋め込み次元は類似性を実装し、関連性は実装しないからである。検索の無関連性はルーティング欠落の失敗である：問い合わせは問いに答えない語彙の一致を返す。間違ったメカニズムをスケールしても、性質を産まずにコストを蓄積する。Theorem 3：事実的-関連性は検索前にルーティングすることで保証され、より細粒度の類似性では保証されない。Production ✅。

RAG に欠けているルーティングメカニズムとは何か？

検索前の明示的分類である。Self-Route はいかなる検索が実行される前に、問い合わせが完全なコンテキストを必要とするかフォーカス検索を必要とするかを分類する。性質問い合わせ-ごとの-正しい-戦略は「分類してから検索する」で保証され、構築時に一つの戦略に固定することでは保証されない。Production ✅（形式）。

「The space is the router」はどう関係するのか？

同じ形式であり、一つ上流のドメインである。Everythink の network→community→room トポロジーはいかなるモデルが実行する前に問い合わせを正しくスコープされたコンテキストにルーティングする、Self-Route が検索が実行される前に問い合わせを正しい検索戦略にルーティングするのと同じである。両者とも応答する前にルーティングすることで関連性を実装する。Partial ⚠️（同じ形式——応答前にルーティング——別ドメイン）。Everythink は予測プラットフォームであり、RAG ベンダーではない。

Everythink は GraphRAG やいかなる検索ツールを支持するか？

いいえ。Everythink は予測プラットフォームである。記事の数値は Partial ⚠️ である。ドメイン横断の類推は図示であり、支持ではない。範囲は民生/防衛である。token、wallet、community-credit の結果は一切約束されない、それらは Roadmap 🔵、Howey 審査待ち。

Sources

Nate Rosidi、KDnuggets、「Your RAG Pipeline Is Probably Useless. Here's a Better Alternative」、公開 2026-06-29、取得 2026-08-23、https://www.kdnuggets.com/your-rag-pipeline-is-probably-useless-heres-a-better-alternative

もしあなたのチームが検索する前にルーティングする準備ができているなら——いかなる埋め込みが実行する前に問い合わせを分類する、the space is the router がいかなる Sister が起草する前に問いを分類するのと同じように——the 21 papers を読むかデモを予約する。HAI Engine は 2016 年から本番でこのルーティングメカニズムを運用している、Sisters は並列に起草し、Oracle は毎回の実行でエントロピーを伴い統合し、Theorem 3 は成り立つ：性質はそのメカニズムが実装され測定されている時に正確に保証される。