ベクトルサーチをやめる

2

自己紹介 自己紹介 やぎ データサイエンティスト 3

Agenda Agenda ・RAGとは ・RAGとは ・いろんなRAG ・いろんなRAG ・PageIndex ・PageIndex ・Book RAG ・Book RAG 4

RAGとは RAGとは このドキュメントを踏まえて回答してほしいな <Context> RAG とは、Retrieval-Augmented Generation であり、LLMが回答を生成する前に・・・ 5

RAGとは RAGとは Retrieval-Augmented Generation (RAG) enhances LLMs by retrieving relevant document chunks from external knowledge base through semantic similarity calculation. ※Gao et al. (2024) Retrieval-Augmented Generation for Large Language Models: A Survey RAG(検索拡張生成)は、 RAG(検索拡張生成)は、 外部知識から関連するドキュメントを検索し 外部知識から関連するドキュメントを検索し LLMを強化すること。 LLMを強化すること。 6

RAGとは RAGとは Naive RAG Naive RAG Documents indexing Prompt Retrieval Output LLM User / Query 3つのプロセス ①index作成 3つのプロセス ①index作成 ②検索 ②検索 ③生成 ③生成 で構成される で構成される 基本的なRAGフレームワークのこと。 基本的なRAGフレームワークのこと。 7

Advanced RAG Advanced RAG Documents User / Query Agentic RAG Agentic RAG Documents User / Query RAGとは RAGとは Naive RAGの精度を上げるためPre-retrievalやPost-retrievalを導入 indexing Retrieval Pre-Retrieval (Query write) Post-Retrieval ・Rerank ・Summary ・Fusion Prompt Output LLM エージェントが検索の要否を自律的に判断し、検索や推論を動的に実行 indexing Retrieval Pre-Retrieval (Query write) Post-Retrieval ・Rerank ・Summary ・Fusion Prompt Output LLM 8 ※今日は話さないよ

RAGとは RAGとは Agentic RAG Agentic RAG Documents User / Query indexing Retrieval Pre-Retrieval (Query write) Post-Retrieval ・Rerank ・Summary ・Fusion Prompt Output LLM 主に「Retrievalの⼿法」を扱う 9

紹介するRAGの相違点 紹介するRAGの相違点 RAGとは RAGとは LLM コンテキストに基づき回答してね 質問 {query} User / Query Documents Retrieval コンテキスト {context} 主に「Retrievalの⼿法」を扱う 10

Long Context Long Context RAGとは RAGとは LLMのContextに利用できる情報全体を直接入力する手法 LLM コンテキストに基づき回答してね 質問 {query} User / Query Documents Retrieval コンテキスト {context} 11

Long Context Long Context の の 問題 問題 RAGとは RAGとは 関連情報がコンテキストの中間にあると、LLMの性能が著しく低下する。 関連情報がコンテキストの中間にあると、LLMの性能が著しく低下する。 （Lost in （Lost in the the Middle） Middle） 長いコンテキストには無関係な情報（ノイズ）が含まれやすく、モデルが 長いコンテキストには無関係な情報（ノイズ）が含まれやすく、モデルが 関連情報に集中できなくなる。（distraction） 関連情報に集中できなくなる。 （distraction） 関係ない情報によりトークン数が増え、コスト/実行時間 が増える。 関係ない情報によりトークン数が増え、コスト/実行時間 が増える。 他に押さえておくべき観点 他に押さえておくべき観点 コンテキストが不十分な場合、LLMは「わからない」と回答を控える コンテキストが不十分な場合、LLMは「わからない」と回答を控える （abstain）のではなく、誤った回答を生成（Hallucination）しがち。 （abstain）のではなく、誤った回答を生成（Hallucination）しがち。 12

13

いろんなRAG いろんなRAG 質問 {query} User / Query Documents Vector Retrieval Graph コンテキスト {context} Table LLM Knowledge Baseは Knowledge Baseは 3種類 の 3種類 の RAG RAG を を 構築できる 構築できる 14

Vector Database Vector Database いろんなRAG いろんなRAG テキストをベクトル埋め込みに変換し、意味的類似度で検索する Documents User / Query indexing Embedding cos類似度 Pre-Retrieval (Query write) Relevant Documents Embedding AWS サービス S3 Vectors や OpenSearchで構築できる 15

いろんなRAG いろんなRAG Vector Database Vector Database の の メリット メリット 大量のドキュメントを効率的に検索できる。 大量のドキュメントを効率的に検索できる。 Vector Database Vector Database の の 限界 限界 意味的に類似していても、回答に必要な情報とは限らない。 意味的に類似していても、回答に必要な情報とは限らない。 ※ベクトルの類似 = ※ベクトルの類似 = 意味的な類似 意味的な類似 を仮定している。 を仮定している。 関連情報がTop-K外になると取得されない。 関連情報がTop-K外になると取得されない。 クエリ（質問文）とドキュメント（回答文）は異なる性質を持つ。同じ埋 クエリ（質問文）とドキュメント（回答文）は異なる性質を持つ。同じ埋 め込み空間で比較することに無理がある。 め込み空間で比較することに無理がある。 同じ意味でも異なる表現（同義語など）を正確に捉えれない場合がある。 同じ意味でも異なる表現（同義語など）を正確に捉えれない場合がある。 多くの異なる概念が埋め込み空間で近くに配置されてしまう。 多くの異なる概念が埋め込み空間で近くに配置されてしまう。 16

Graph RAG Graph RAG いろんなRAG いろんなRAG エンティティ（ノード）と関係性（エッジ）をグラフ構造で表現して検索する。 Documents User / Query indexing Pre-Retrieval (Query write) Graph (node/edge) Edge Relevant Documents Graph (node) AWS サービス Neptune で GraphDB を構築できる 17

いろんなRAG いろんなRAG Graph RAG Graph RAG の の メリット メリット 離れた情報（ドキュメント）同士を関係性で接続できる 離れた情報（ドキュメント）同士を関係性で接続できる Graph RAG Graph RAG の の 限界 限界 クエリからグラフ探索の起点となるエンティティを決めるのが難しい。 クエリからグラフ探索の起点となるエンティティを決めるのが難しい。 構築コストが高い。NodeとEdgeのうち、Edge作成がかなり大変。 構築コストが高い。NodeとEdgeのうち、Edge作成がかなり大変。 更新時には全てのドキュメントとの関連性が必要となる。 更新時には全てのドキュメントとの関連性が必要となる。 Graph構造は、ドメインに依存する。汎用的な方法の確立が難しい。 Graph構造は、ドメインに依存する。汎用的な方法の確立が難しい。 検索時に相当な計算リソース // トークンを消費する。 検索時に相当な計算リソース トークンを消費する。 同一エンティティの異なる表記を統合 // 分離するかの判断が難しい。 同一エンティティの異なる表記を統合 分離するかの判断が難しい。 例：J. Smith 例：J. Smith // John John Smith Smith // スミス氏 スミス氏 18

Text to Text to SQL SQL いろんなRAG いろんなRAG 自然言語の質問からSQLクエリを生成し、データベースから情報を取得する Documents User / Query indexing SQL DB SQL検索 Pre-Retrieval (Query write) Relevant Documents SQLの生成 AWS サービス RDS や AuroraなどのリレーショナルDBで構築できる 19

いろんなRAG いろんなRAG Text to Text to SQL SQL の の メリット メリット 既存のRDB（RDS、Auroraなど）をそのまま活用できる 既存のRDB（RDS、Auroraなど）をそのまま活用できる Text to Text to SQL SQL の の 限界 限界 クエリに対して、どのテーブル/カラムを使うべきか特定するのが難しい クエリに対して、どのテーブル/カラムを使うべきか特定するのが難しい 自然言語の曖昧さをSQLの厳密な条件に変換するのが難しい 自然言語の曖昧さをSQLの厳密な条件に変換するのが難しい ※ DB名/テーブル名/カラム名が略称や社内用語のせいで特定が困難である。 ※ DB名/テーブル名/カラム名が略称や社内用語のせいで特定が困難である。 大規模スキーマがコンテキストに収まらない 大規模スキーマがコンテキストに収まらない 複雑なクエリで精度が急落する 複雑なクエリで精度が急落する 実行エラー時の自己修正が難しい 実行エラー時の自己修正が難しい 不適切なSQL生成によるセキュリティリスクがある 不適切なSQL生成によるセキュリティリスクがある 20

いろんなRAG いろんなRAG 質問 {query} User / Query Documents Vector Retrieval Graph コンテキスト {context} Table LLM Knowledge Baseは Knowledge Baseは 3種類 の 3種類 の RAG RAG を を 構築できる 構築できる 21

22

PageIndex PageIndex こっちに 入ってそう うわっ 反対や フォルダ名を見て どっちかなと推測しながら 入ってそうなものを開く 間違ってそうなら またやり直す 23

PageIndex PageIndex RAG でもしたい RAG でもしたい こっちに 入ってそう うわっ 反対や フォルダ名を見て どっちかなと推測しながら 入ってそうなものを開く 間違ってそうなら またやり直す 24

PageIndex PageIndex 文書をツリー構造に変換しLLMがツリーを辿って情報を探し出す 25

PageIndex PageIndex 従来の 従来の 課題 課題 文書構造を保てない 文書構造を保てない 特徴 特徴 （PageIndex） （PageIndex） ベクトルDBなし ベクトルDBなし 類似≠関連性 類似≠関連性 参照を辿れない 参照を辿れない LLMが読んで考えて探す LLMが読んで考えて探す 26

PageIndex PageIndex 階層ツリーを構築する 階層ツリーを構築する "node_id": "XX", "title": "Financial", "page_index": 11, "summary": "XXX ...", 各ノードで、ID/タイトル/要約/ページ情報/ 子ノードがある。 「章→節→段落」をそのまま保持できる。 ツリーを探索して回答する ツリーを探索して回答する 目次（ツリー全体）を読む 答えがありそうなセクションを選ぶ 内容を読む（ノードの文章を取得） 答えに足りていれば回答を生成。 足りなければ①から別ノードを探索する。 27

どこかで どこかで 見覚えない？ 見覚えない？ 28

PageIndex PageIndex B-Tree B-Tree データベースの検索を高速にするための手法で、 木構造でルートから段階的に絞り込む。 100万件のデータでも数回でたどりつく。 データの中身をすべて読む必要はなく、各ノード のキーを見るだけで「次にどこへ行けばいいか」 が機械的に決まる。 29

PageIndex PageIndex BB Treeの限界 Treeの限界 ⇒ ⇒ PageIndexの限界 PageIndexの限界 隣のデータを見たくても、毎回ルートから辿り直す 隣のデータを見たくても、毎回ルートから辿り直す 30

PageIndex PageIndex B+Tree B+Tree B-Treeの弱点を克服した拡張版 変わったのは 「リーフノード同士がリンクでつながっている」 B-Treeでは隣のノードに行くには ルートからやり直しだったが、 B+Treeではそのまま隣に移動できる。 31

おなじこと おなじこと できないの？ できないの？ 32

BookRAG BookRAG 2025年12月に発表されたRAG手法 Tree PageIndexと同じく文書を階層ツリーに加えて、 ノード間をつなぐリンクを持っている。 BookIndex BookIndex Graph ①ツリー（T）目次のようなTree構造 ②グラフ（G）文書のエンティティと関係性 ③ GT-Link（M） グラフのエンティティとツリーのマッピング 33

AWS で構築するなら AWS で構築するなら BookRAG BookRAG Tree Dynamo DB Graph Strands Agents Neptune 34

参考文献 参考文献 ・Gao et al. (2024) Retrieval-Augmented Generation for Large Language Models: A Survey ・Liu et al.(2025) A Comprehensive Survey on Long Context Language Modeling ・Chen et al. (2023)Benchmarking Large Language Models in Retrieval-Augmented Generation ・Zhu et al.(2024)Large Language Model Enhanced Text-to-SQL Generation: A Survey ・PENG et al.(2024)Graph Retrieval-Augmented Generation: A Survey ・Sarthi et al.(2024) RAPTOR: RECURSIVE ABSTRACTIVE PROCESSING FOR TREE-ORGANIZED RETRIEVAL ・Wang et al.(2025) BookRAG: A Hierarchical Structure-aware Index-based Approach for RetrievalAugmented Generation on Complex Documents ・Khan et al.(2026)DF-RAG: Query-Aware Diversity for Retrieval-Augmented Generation ・Lau et al.(2026)Breaking the Static Graph: Context-Aware Traversal for Robust Retrieval-Augmented Generation ・Du et al.(2026)A-RAG: Scaling Agentic Retrieval-Augmented Generation via Hierarchical Retrieval Interfaces ・Amazon Bedrock Knowledge Bases https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/knowledge-base.html 35 ・PageIndex https://docs.pageindex.ai/

• https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/knowledge-base.html

※ hit@1 BookRAG BookRAG 正解率 ※今回はローカルでデータを所持 実行時間 コスト Vector RAG (top 1) 7件 / 100件 36秒 Embedding：144118token +OpenSearch維持費 PageIndex 11件 / 100件 1530秒 input：921,862token output：148,885token +DynamoDB維持費 Vector RAG 22件 / 100件 vectorと同じ vectorと同じ Vector+Graph 18件 / 100件 vectorと同じ vectorと同じ BookRAG 44件 / 100件 pageIndexと同じ +Dynamo呼び出し +Neptune呼び出し PageIndexと同じ +Neptune維持費 +OpenSearch呼び出し +Dynamo呼び出し ※ hit@3 コストを犠牲に精度を向上できた コストを犠牲に精度を向上できた 36

BookRAG BookRAG 拡張案①：DF-RAG (2026/1/23) 拡張案①：DF-RAG (2026/1/23) コサイン類似度のTop-Kでは、似たチャンクばかり で推論に必要な多角的な証拠が欠落する。 Query λ=0.1 Chunk1 λ=1.0 Chunk2 LLM Chunk3 ツリー探索でも同じ問題が起きる。 並列に検索するビームサーチ（LATTICE）でも 有望なパス同士が同じノードに集中する。 DF-RAGは、ノードを選ぶ際に 「既に選んだノードとの距離」を加味することで、 関連性と多様性を同時に最適化する。 ※ビームサーチよりGridSearchのイメージが近い 37

BookRAG BookRAG 拡張案②：CatRAG (2026/2/2) 拡張案②：CatRAG (2026/2/2) HippoRAG2はナレッジグラフ上でPersonalized PageRank（ランダムウォーク）を実行し、確率的に 多く到達したノードほど関連性が高いと判定する。 インデックスは構築時に固定されるため、 接続数が多く重みが大きい汎用エッジに集中する 「セマンティック・ドリフト」が起きる。 CatRAG は、質問が来るたびに遷移行列を書き換えて からノード検索する。 38

BookRAG BookRAG 拡張案③：A-RAG (2026/2/3) 拡張案③：A-RAG (2026/2/3) 最初から全文を渡さず、階層的に絞り込む。 これをモデル駆動に検索を進める。 第1層：keyword_search キーワード完全一致で探す 第2層：semantic_search 意味が近い文を探す 第3層：chunk_read 全文を読む価値があるなら取得 個人的には、全ての層をGraphにしたいな。 ArchRAGはベクトル検索なのでLLM版がいい。 39

どこかで どこかで 見覚えない？ 見覚えない？ 40

BookRAG BookRAG HNSW (Hierarchical HNSW (Hierarchical Navigable Navigable Small Small Worlds) Worlds) 多層グラフ構造のベクトル近傍探索アルゴリズム 粗い情報でざっくり絞り段階的に精度を上げる。 ①上位層（Layer 2, 3…） ノード数が少なく、エッジが長い。 大ジャンプで検索空間を絞り込む 粗い探索。 ②下位層（Layer 1, 0） 細かく絞りこみ最近傍を見つける 精密探索。 OpenSearchなど多くのベクトルDB が採用 41

BookRAG BookRAG B-TreeからB+Treeへの延長で考えると、 HNSWは階層的な絞り込みで 高速かつ高精度な近傍探索を実現している。 42

BookRAG BookRAG Vector RAG Vector RAG 何が悪い？ 何が悪い？ B-TreeからB+Treeへの延長で考えると、 HNSWは階層的な絞り込みで 高速かつ高精度な近傍探索を実現している。 43

BookRAG BookRAG 問題は、ベクトル化にある。 文書をベクトルにした瞬間、構造は壊れ、文脈は消え、 「似た文」は見つかるが「答えの文」は見つからない。 どれだけよいアルゴリズム(HNSW) で探しても、 壊れたものの中から正解は見つからない。 だからこそ、構造をLLMの推論で辿る時代へ。 44

45