ストーリー
田
田中VPoE
ベクトルDB、ハイブリッド検索、フィルタリング、パイプライン設計 — 検索周りの知識は揃った。ここで統合的な検索パイプラインを設計してもらう
あなた
Step 2のドキュメント処理パイプラインの後段にあたる部分ですね
あ
田
田中VPoE
その通りだ。今回は具体的なクエリシナリオを使って、検索パイプラインがどう動くかを検証する。「こういう質問が来たらどう検索して、どう回答するか」をシミュレーションしてくれ
あなた
実際のユーザーシナリオを想定した設計ですね
あ
田
田中VPoE
設計は常にユーザー視点で検証する。技術的に正しくてもユーザーが満足しなければ意味がない
ミッション概要
| 項目 | 内容 |
|---|---|
| 演習タイトル | 検索パイプラインの構築 |
| 想定時間 | 90分 |
| 成果物 | 検索パイプライン設計書（アーキテクチャ + クエリシナリオ検証 + パフォーマンス設計） |
Mission 1: 検索パイプラインのアーキテクチャ設計
要件
以下の検索パイプラインを設計してください。
- パイプラインの全体アーキテクチャ図
- 各コンポーネントの設定パラメータ
- ハイブリッド検索の設定（RRF + 重み）
- メタデータフィルタの設計（プリフィルタ/ポストフィルタ）
解答例
アーキテクチャ図
[API Gateway (FastAPI)]
↓
[Query Processor]
├── 入力バリデーション（長さ制限: 500文字）
├── LLMフィルタ抽出（Claude Haiku → JSON出力）
└── クエリEmbedding（OpenAI text-embedding-3-small）
↓
[Hybrid Retriever]
├── Dense Search: Qdrant Vector Search（Top-20, コサイン類似度）
├── Sparse Search: Qdrant BM25（Top-20）
└── Fusion: RRF（k=60）→ Top-15
↓
[Metadata Pre-Filter]
├── doc_type（ユーザー指定 or LLM抽出）
├── department（ユーザー指定 or LLM抽出）
└── updated_at（デフォルト: 直近2年以内）
↓
[Reranker]
├── Cohere Rerank v3（Top-15 → Top-5）
└── スコア閾値: 0.3（これ以下は除外）
↓
[Context Builder]
├── チャンクの結合（最大3000トークン）
├── 参照元メタデータの整形
└── 階層的チャンク: Childマッチ → Parent取得
↓
[LLM Generator]
├── モデル: Claude 3.5 Sonnet
├── ストリーミング応答
└── 参照元リンク付き回答パラメータ一覧
| コンポーネント | パラメータ | 値 |
|---|---|---|
| Dense Search | top_k | 20 |
| Dense Search | score_threshold | 0.5 |
| Sparse Search | top_k | 20 |
| RRF | k | 60 |
| Hybrid Weight | alpha（dense比率） | 0.6 |
| Reranker | top_n | 5 |
| Reranker | score_threshold | 0.3 |
| LLM | max_tokens | 1024 |
| LLM | temperature | 0.1 |
| Context | max_tokens | 3000 |
Mission 2: クエリシナリオ検証
要件
以下の5つのクエリシナリオについて、検索パイプラインの動作をシミュレーションしてください。
各シナリオで以下を記述してください：
- 適用されるフィルタ条件
- 検索手法の貢献度（ベクトル/BM25どちらが有効か）
- 期待される検索結果
- 想定される課題と対策
シナリオ一覧
| No. | クエリ | 特徴 |
|---|---|---|
| S1 | 「RAGシステムのデプロイ手順を教えて」 | 意味的検索が有効 |
| S2 | 「ECS-2847のインシデント対応状況は？」 | キーワード検索が有効 |
| S3 | 「先月の開発部の定例会議で決まったこと」 | フィルタリングが重要 |
| S4 | 「Pythonでベクトル検索を実装するサンプルコード」 | コード検索 |
| S5 | 「新人が最初に読むべきオンボーディング資料」 | 曖昧なクエリ |
解答例
S1: 「RAGシステムのデプロイ手順を教えて」
| 項目 | 内容 |
|---|---|
| フィルタ | doc_type = “技術文書”（LLM自動抽出） |
| 有効な検索 | ベクトル検索が主力（「デプロイ手順」≒「リリースプロセス」を捉える） |
| 期待結果 | RAGシステムのデプロイガイド、CI/CDパイプライン設定書等 |
| 課題 | 「RAG」の範囲が広い。RAGシステム以外のデプロイ手順もヒットする可能性 |
| 対策 | Rerankingでクエリとの関連度が高い結果を上位に |
S2: 「ECS-2847のインシデント対応状況は？」
| 項目 | 内容 |
|---|---|
| フィルタ | doc_type = “議事録”（LLM自動抽出） |
| 有効な検索 | BM25が主力（「ECS-2847」は完全一致で検索すべき） |
| 期待結果 | ECS-2847に関するインシデントレポート、議事録 |
| 課題 | ベクトル検索では「ECS-2847」が意味的にマッチしにくい |
| 対策 | ハイブリッド検索のBM25重みを動的に上げる（alpha=0.3） |
S3: 「先月の開発部の定例会議で決まったこと」
| 項目 | 内容 |
|---|---|
| フィルタ | doc_type = “議事録”, department = “開発部”, meeting_date >= “2026-02-01” |
| 有効な検索 | フィルタリングが最重要。残りの候補内でベクトル検索 |
| 期待結果 | 2月の開発部定例議事録、決定事項セクション |
| 課題 | 「定例会議」の名称がソースごとに異なる可能性 |
| 対策 | agenda_topicメタデータでの補完、会議名の正規化 |
S4: 「Pythonでベクトル検索を実装するサンプルコード」
| 項目 | 内容 |
|---|---|
| フィルタ | has_code = true, tech_stack contains “Python” |
| 有効な検索 | ベクトル検索 + has_codeフィルタの組み合わせ |
| 期待結果 | Python版のベクトル検索実装コードを含む技術文書 |
| 課題 | コードブロックの検索精度。コメントやドキュメントと本文が混在 |
| 対策 | コードブロックを独立チャンクとして格納し、code_languageで絞り込み |
S5: 「新人が最初に読むべきオンボーディング資料」
| 項目 | 内容 |
|---|---|
| フィルタ | tags contains “オンボーディング” or “新人” |
| 有効な検索 | ベクトル検索（意味的な「入門」「初心者向け」を捉える） |
| 期待結果 | オンボーディングガイド、環境構築手順、チーム紹介資料 |
| 課題 | 「新人向け」が明示されていないドキュメントもある |
| 対策 | difficultyメタデータ（初級/中級/上級）でのフィルタリング |
Mission 3: パフォーマンスとコスト設計
要件
以下を設計してください。
- レイテンシバジェット（各段階の時間配分）
- スケーリング設計（同時接続50ユーザー対応）
- 月額コスト試算
- キャッシュ戦略
解答例
レイテンシバジェット（目標: 5秒以内）
| 段階 | 目標レイテンシ | 備考 |
|---|---|---|
| クエリ前処理 + フィルタ抽出 | 300ms | LLM呼び出し（Haiku）含む |
| クエリEmbedding | 150ms | OpenAI API |
| ベクトル検索 + BM25 | 200ms | 並列実行 |
| RRF統合 | 10ms | ローカル処理 |
| Reranking | 400ms | Cohere API |
| プロンプト構築 | 10ms | ローカル処理 |
| LLM生成（TTFT） | 500ms | Claude API（ストリーミング） |
| 合計（TTFT） | 1.57秒 | 最初のトークン表示まで |
| LLM生成（全体） | 2000ms | ストリーミング中 |
| 合計（全体） | 3.57秒 | 目標5秒以内を達成 |
月額コスト試算
| 項目 | 計算根拠 | 月額 |
|---|---|---|
| OpenAI Embedding API | 500クエリ/日 × 30日 × $0.00002/1Kトークン | 約0.3万円 |
| Cohere Rerank API | 15,000リクエスト/月 × $0.002/リクエスト | 約3万円 |
| Claude Sonnet API | 15,000リクエスト × 入出力トークン | 約12万円 |
| Claude Haiku（フィルタ抽出） | 15,000リクエスト | 約1万円 |
| Qdrant（EC2 r6g.large） | オンデマンド | 約5万円 |
| 合計 | 約21.3万円 |
キャッシュ戦略
| キャッシュ層 | 対象 | TTL | ヒット率目安 |
|---|---|---|---|
| クエリEmbeddingキャッシュ | 同一クエリのEmbedding | 24時間 | 15-20% |
| セマンティックキャッシュ | 類似クエリの回答 | 1時間 | 10-15% |
| 検索結果キャッシュ | Top-K検索結果 | 30分 | 5-10% |
達成度チェック
| 観点 | 達成基準 |
|---|---|
| アーキテクチャ | パイプラインの全段階が設計され、パラメータが具体的 |
| クエリシナリオ | 5つのシナリオで検索動作がシミュレーションされている |
| ハイブリッド検索 | クエリ特性に応じた検索手法の使い分けが設計されている |
| パフォーマンス | レイテンシバジェットが目標内に収まっている |
| コスト | 月額コストが具体的に算出され、予算内に収まっている |
| 運用考慮 | キャッシュ、エラーハンドリングが設計されている |
推定所要時間: 90分