10. 実践評価：大規模データにおけるベクトル検索とBM25のハイブリッド運用設計

語彙検索と意味検索のトレードオフ

前章では、英辞郎テキスト（2,349,580 件）を対象に、SQLite FTS5 を用いて 1 〜 3ms で応答する超高速な BM25 全文検索基盤を構築しました。この基盤は、スペルや正確な訳語の「語彙一致（完全一致・部分一致）」において極めて高いパフォーマンスを発揮します。

しかし、実際の AI アプリケーションやプロンプト作成現場では、語彙一致だけでは解決できない次のような要求が生じます。

「薄暗い路地裏」「幻想的な光」といった抽象的・感覚的な日本語表現から、ニュアンスに合致する英語タグ（例: dystopian backstreet, ethereal lighting）を発掘したい。
表記揺れや類語・同義語（例: futuristic と sci-fi）を意味的に橋渡しして検索したい。

本章では、大規模辞書データを対象に、Chroma 等のベクトルデータベース（Dense Retrieval）を組み合わせたハイブリッド運用（BM25 + ベクトル検索） の有効性、コスト、技術的実現性を評価・検証した記録と、導き出された「3層ハイブリッド戦略」を解説します。

1. 比較評価マトリクス（英辞郎 235万件を対象とした場合）

235 万件の全データをベクトル化して Chroma 等で管理した場合と、現行の SQLite FTS5（BM25）との詳細な比較は以下のとおりです。

評価項目	SQLite FTS5 (BM25)	Chroma + ベクトルDB (235万件)	評価・備考
初回インデックス構築時間	約 49 秒	数時間〜半日	235 万回の埋め込み推論（Embedding）バッチ処理が必要
ストレージフットプリント	573 MB	4 GB 〜 15 GB	ベクトル次元数（384〜1024次元）および HNSW グラフ構造による増大
プロセス常駐メモリ	約 40 MB	数 GB 〜 10 GB	HNSW ベクトルインデックスのメモリ展開が必要
検索レイテンシ	1 〜 3 ms	50 〜 200 ms	クエリの Embedding 計算（30〜100ms）＋ベクトル類似度計算
タイピング補完 (即時性)	極めて良好 (即時反映)	遅延あり (デバウンス必須)	キー入力ごとのインクリメンタル検索には不向き
完全一致 (Exact Match)	100% 正確	類似概念が混ざり順位低下のリスク	辞書のスペル確認用途では語彙一致が最優先される
概念・類語検索 (Semantic)	単語・文字の一致のみ	極めて強力	言語化しにくいニュアンスからの検索が可能
外部依存関係	Python 3 標準組み込みのみ	`chromadb`, PyTorch / ONNX, モデル	パッケージサイズと環境依存が肥大化

235 万件のテキストを埋め込みモデル（例: bge-m3, all-MiniLM-L6-v2, text-embedding-3-small 等）でベクトル化する場合、ローカル CPU で 1 秒間に 50 〜 100 件処理できたとしても、全体で 6.5 時間〜 13 時間 を要します。 GPU を活用しても数十分〜1時間は必要であり、ユーザーがツールをセットアップする際の初回起動体験として、数十秒で完了する SQLite FTS5 と比較して極めて重い負荷となります。

2.2 メモリとディスクの消費

軽量なモデル（384次元、float32）を用いた場合でも、1件あたり 384 × 4 bytes = 1.536 KB を消費します。純粋なベクトル生データだけで 2,349,580 × 1.536 KB ≈ 3.6 GB となります。さらに、Chroma が高速近似最近傍探索（ANN）のために構築する HNSW（Hierarchical Navigable Small World）グラフのメタデータを含めると、ディスクおよび常駐メモリの消費量は 5 GB 〜 10 GB を超え、一般的なデスクトップツールのリソース要件として過大になります。

2.3 クエリ時のオーバーヘッドとタイピング補完の衝突

エディタの入力補完では、ユーザーが 1 文字入力するごとに数ミリ秒で候補が絞り込まれるレスポンスが理想です。ベクトル検索では、ユーザーが入力した検索語そのものを推論モデルに通してベクトル化（数十 ms）してから探索を行うため、タイピングの追従性においてレイテンシが顕著になります。

3. 推奨アーキテクチャ: 3層ハイブリッド戦略

全データを無差別にベクトル化するのではなく、データの規模と検索の目的に応じて手法を分担させる「3層ハイブリッド戦略」が最も費用対効果に優れています。

flowchart TD
    subgraph UI["Prompt Studio (UI / エディタ)"]
        Client["ユーザー入力 / クエリ"]
    end

    subgraph Tier1["Tier 1: 語彙辞書引き (即時補完)"]
        FTS["英辞郎 (235万件)<br/>SQLite FTS5 (BM25)"]
        FTS_Info["- 1〜3ms 即時補完<br/>- メモリ 40MB<br/>- 正確なスペル・訳語"]
    end

    subgraph Tier2["Tier 2: タグセマンティック探索"]
        ChromaStore["プロンプトタグ (数千〜数万件)<br/>Chroma (ベクトルDB)"]
        Chroma_Info["- ニュアンス・類語探索<br/>- インデックス数秒〜数分<br/>- メモリ数十MB"]
    end

    subgraph Tier3["Tier 3: 創作ブレスト・文脈生成"]
        OllamaLLM["ローカルLLM<br/>Ollama"]
        Ollama_Info["- 複雑なアイデア出し<br/>- 文脈に沿ったプロンプト生成<br/>- 追加インデックス不要"]
    end

    Client -->|タイピング即時補完| FTS
    Client -->|ニュアンス・タグ検索| ChromaStore
    Client -->|プロンプト自動構成| OllamaLLM

Tier 1: 大規模辞書（235万件）は SQLite FTS5 (BM25) を継続

用途: 単語のスペル確認、正確な訳語検索、直接入力補完。
理由: 573MB の単一ファイル、メモリ 40MB、応答 1 〜 3ms という現行の圧倒的な利点を維持。

Tier 2: プロンプトタグ（数千〜数万件）限定の Chroma 導入

用途: 「こういう雰囲気・衣装・背景のタグが欲しい」というセマンティック探索。
対象データ: 厳選されたタグ定義群（数千〜数万件程度）。
利点:
- 数万件規模であれば、ローカル CPU でも 数秒〜数十秒 で埋め込み計算・インデックス構築が完了。
- DB サイズは数十 MB、常駐メモリも 100 〜 200MB 程度に収まる。
- 「辞書検索」とは別に「類似タグ探索（Semantic Tag Finder）」パネルを新設することで、目的を明確に分離可能。

Tier 3: 複雑なニュアンス・創作支援はローカルLLMに委譲

用途: 「近未来のネオン街で雨に濡れるサイバーパンク少女のプロンプト構成案を作って」といった高度な文脈処理。
理由: アプリケーションに Ollama などのローカル LLM が組み込まれている場合、ベクトル DB の構築・保持コストをかけずに、LLM の事前学習知識を直接活用して最適な英語タグ群をブレインストーミングさせることが可能。

4. 結論とハイブリッド運用の設計指針

本ケーススタディの評価から得られた、実運用におけるハイブリッド運用の重要指針は以下のとおりです。

「何でもベクトル化」を避ける: 数百万件規模の辞書やログデータなど、語彙の完全一致やスペル検索が主目的のデータには、BM25（特に SQLite FTS5 や Elasticsearch）がリソース・速度・精度の全方位で優れています。
意味検索（ベクトル）は「データ量を絞って」局所投入する: セマンティック検索が必要な対象（ドメイン固有のタグや高品質ナレッジの要約）に絞ってベクトル化することで、インデックス時間とリソース消費を最小限に抑えつつ、高い検索体験を提供できます。
UI/UX レベルでの責務分離: キー入力ごとのインクリメンタル補完にはミリ秒単位で動く BM25 を割り当て、ニュアンス検索にはデバウンスを効かせたベクトル検索や LLM を割り当てることで、ストレスのないユーザー体験を実現できます。

次章では、本書全体の総括とともに、チャンキングやメタデータフィルタリング、評価フレームワークを用いた継続的な検索品質の改善アプローチをまとめます。