Lighthouse、RAG 設計パターンガイドを公開──BM25 からハイブリッド検索までの選定基準を解説
過剰設計になりがちな RAG パイプラインに対し、MVP としての BM25 全文検索からエージェント型クエリ書き換え、オンザフライ埋め込みまでを段階的に適用する設計指針を解説した。
リリース: 2026-06-10 · 読了 4 分記事の要約
1. 核心（What）
- RAG システムの過剰設計を防ぐため、データ更新頻度やチームの ML 習熟度に応じた 4 つの段階的アプローチを提案
- MVP としての BM25 全文検索（Elasticsearch や Postgres）を活用し、ゼロチャンキング・ゼロ API コストで運用する手法を提示
- 社内固有の用語（例: 固有名詞「Atlas」）の認識精度を担保するため、LLM によるエージェント型クエリ書き換えの仕組みを紹介
- 10%以上の高頻度でデータが更新される環境において、全文書の再インデックスを回避するオンザフライ埋め込みのコストとレイテンシを試算
2. 影響（Why）
- 初期フェーズにおける実装コストの大幅な削減: 初期から複雑なベクトルデータベースやチャンキング戦略を導入すると検証コストが跳ね上がるため、まずは BM25 全文検索から始めることで開発工数を大幅に圧縮できる。
- 国内 SaaS・受託開発における検索精度の実用的な改善: 専門用語や社内固有のコード名を持つドキュメントを扱う国内 SaaS 開発チームは、埋め込みモデルの再学習よりもプロンプトによるクエリ書き換えを採用する方が、実装の確実性とコスト面で有利になる。
3. 根拠・詳細（How）
- BM25 とエージェント型クエリ書き換えのパイプライン構成: ユーザーの自然言語クエリを GPT-4o-mini などの軽量 LLM でストップワード削除や同義語追加に変換し、BM25 全文検索へ渡すことで、モデルの再埋め込みなしに検索精度を最適化する。
- ハイブリッド検索とオンザフライ埋め込みのコスト試算モデル: OpenAI text-embedding-3-small（$0.02/100万トークン）を用い、1日 1,000 クエリ・1回 50 ドキュメントを処理する場合のトークン計算と、200〜500ms のレイテンシトレードオフを定義している。
4. 展望・課題（Next）
- モデル非推奨化への耐性確保: 商用埋め込みモデルの非推奨化リスクやインデックス再構築の負担を考慮し、データ更新頻度に基づいたアーキテクチャの選定を継続的に検証する必要がある。