6月24日、Towards Data Scienceが「Retrieval Is Filtering, Not Search: A Mental Model for Enterprise RAG」と題した記事を公開した。この記事では、エンタープライズRAGにおける検索処理を「ベクトル検索」ではなく「構造化テーブルへのフィルタリング」として捉え直すメンタルモデルについて詳しく紹介されている。
コサイン類似度top-kが失敗する4つのパターン
RAGの実装記事の大半は、「クエリに最も近いチャンクをコサイン類似度で上位k件取得する」という構成から始まる。この記事はその前提そのものを疑う。
記事は保険契約書への4つの質問を使って、なぜ単一の検索手法では不十分かを具体的に示す。
- 「証券番号は？」 → ページ1のヘッダー付近にある1トークン。アンカーは1行、コンテキストは5行程度。
- 「年間保険料は？」 → 「premium」「cotisation」等の語を含む節。コンテキストは50〜200行。
- 「売主の義務をすべて列挙せよ」 → 複数箇所に散在。コンテキストは500〜2000行に及ぶ可能性。
- 「保証条項を要約せよ」 → アンカーは目次の節タイトル。コンテキストは節全体。
top-k=5のコサイン類似度で全ケースを処理すれば、少なくとも3ケースで誤る、というのが著者の結論だ。
ここで著者はNeedle-in-a-Haystackベンチマーク（gkamradt/LLMTest_NeedleInAHaystack）にも言及する。長文コンテキストに1文を埋め込んで探させるこのベンチマークで最新モデルはほぼ完璧なスコアを出す。だがそれは上記の質問分類1に相当するケースだけを検証しているにすぎない。「検索をスキップしてコーパス全体をコンテキストに詰め込む」という戦略の根拠にはならない、と記事は明言する。
「検索ではなくフィルタリング」という発想の転換
この4つの失敗パターンを踏まえて著者が提示するのが、検索処理をSQLライクなフィルタリングとして再設計するメンタルモデルだ。
著者が示す出発点は、人間のドキュメント検索の実態だ。社員が就業規則PDFで有給日数を調べる場面を考える。まずCtrl+Fでキーワードを打ち、ヒットしなければTOCを開いて「Leave and Time Off」のような節を選び、本文を読む。このどこにも「埋め込みベクトルの類似度計算」は登場しない。
記事の主張はシンプルだ。ドキュメントをパース済みのDataFrameとして扱えば、検索はSQLクエリに近い問題になる。具体的には2つのテーブルを操作する：
- **
line_df**（密なテーブル）：ドキュメントの全行を1行ずつ格納。テキスト、ページ番号、バウンディングボックス、section_idなどの列を持つ。答えの本文はここにある。 - **
toc_df**（疎なテーブル）：目次の各節を1行ずつ格納。通常20〜100行程度と小さい。「答えがどの節にありそうか」を示すマップとして機能する。
この2テーブルをsection_idでJOINして使うのが基本パターンだ。toc_dfで節を絞り込み、その節内のline_dfをフィルタリングして正確な行を特定する。
設計の核心：アンカーとコンテキストを分離する
記事が特に強調するのがアンカー（anchor）とコンテキスト（context）の分離だ。
- アンカースコープ（小さく、精密に）：キーワードマッチや類似度スコアリングを行う単位。行・文・節タイトルなど。シグナルを精度よく検出するために小さくする。
- コンテキストスコープ（大きく、十分に）：LLMの生成ステップに渡す単位。段落・節・Nライン窓など。
コンプライアンス担当者がCtrl+Fで「liability」を検索してヒットした1行を見つけても、その1行だけを読んで答えを出すことはない。前後の段落、場合によっては節全体を読む。アンカーは1行、コンテキストは数百行になる。
記事が「RAGパイプラインで最も多い失敗」と呼ぶのは、この2つを同一のチャンクに潰してしまうことだ。チャンク単位でアンカー検出も生成用コンテキストも兼用すると、精度（チャンクは粒度が粗すぎる）とリッチさ（チャンクは狭すぎる）の両方を失う。
「専門家のワークフローを増幅する」という設計原則
記事全体を貫く設計思想として著者が掲げるのが「amplify the expert」だ。人間の専門家が行う作業をコードに落とし、さらに手動では届かない部分を自動化する。具体的に3つの強化点が挙げられている。
- 専門家は1キーワードずつ打つ。システムは複数キーワードの共起を1パスで検出できる。
- 専門家はスキャン画像内のテキストを検索できない。パース段階でOCRを実行しておけば画像内テキストも検索対象になる。
- 専門家はTOCを目視でスキャンする。システムはTOCとコンテンツをプログラム的にJOINし、該当節の本文だけをスコープして絞り込める。
なお、記事ではサンプルドキュメントとして「Attention Is All You Need」（Vaswani et al. 2017）を使用している。15ページ、22エントリ・3階層のTOCを持ち、RAGを触るエンジニアなら内容に馴染みがある選択だ。
本記事はシリーズ7本目に当たる。同シリーズではエンタープライズRAGの設計を段階的に掘り下げており、過去記事ではドキュメントパースの基礎（Article 1）、テーブル・リスト抽出（Article 2）、マルチカラムレイアウト対応（Article 3）、TOC抽出と構造化（Article 4）、画像・図表の解析（Article 5）、セクション単位の構造的チャンキング（Article 6）といったテーマが扱われてきた。本記事はそれらの実装を前提に、検索設計の考え方そのものを再定義する位置づけだ。続くArticle 7Bではアンカー検出の並列実装、Article 7CではLLMアービターへと展開する。
詳細はRetrieval Is Filtering, Not Search: A Mental Model for Enterprise RAGを参照していただきたい。
