mcpField
R
RAG Implementer

RAG Implementer

github.com/daffy0208開発38186 回インストール44 週間前に更新
リポジトリ

RAG Implementer について

RAG Implementerは、検索拡張生成システムを構築するチーム向けの技術スキルです。知識の準備、検索、評価、デプロイ、継続的改善を扱う8段階の手順を示し、まずRAGの必要性を検証するよう促します。

主な機能

  1. 01必要性の検証と代替案の指針
  2. 028段階の実装プロセス
  3. 03ナレッジ、埋め込み、ベクトルストアの設計
  4. 04検索とコンテキスト構成の手法
  5. 05評価、デプロイ、監視の指針
  6. 06継続的改善の実践

活用シーン

  1. 01単純な検索よりRAGが必要か判断
  2. 02ドメイン固有コンテンツ向けのRAGパイプライン設計
  3. 03検索結果と生成回答の評価
  4. 04デプロイと監視の手順策定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/daffy0208/ai-dev-standards --skill rag-implementer

インストール後、Claude Code で/rag-implementerを入力して読み込まれたか確認します。

同梱ファイルmanifest.yamlREADME.md

詳細

RAG 実装者

本番環境に対応した検索拡張生成システムを構築します。

基本原則

RAG = 検索 + コンテキストの組み立て + 生成

LLM が学習データに含まれていない最新の知識、専門分野の知識、または独自の知識にアクセスする必要がある場合に RAG を使用します。

⚠️ 前提条件とコストの現実を確認

立ち止まって確認：RAG が必要だと検証しましたか？

RAG を実装する前に、次の点を確認してください。

  • 課題を検証済み - product-strategist のフェーズ 1（課題の発見）を完了している
  • ユーザーが AI 検索を必要としている - よりシンプルな代替手段（以下を参照）を試している
  • ROI が妥当 - RAG と代替手段のコストとメリットを算出している
まずはこちらを試してください（RAG を導入する前に）

RAG は強力ですが、コストがかかります。まずはより低コストの代替手段を試してください。

1. FAQ ページ／ドキュメント（1 日、$0）

  • 整理された FAQ またはドキュメントを作成する
  • Cmd+F で検索できるようにする
  • 適するケース： よくある質問が 50 件未満で、コンテンツが静的
  • 確認： ユーザーは回答を見つけられますか？見つけられるなら、ここで止めてください。

2. シンプルなキーワード検索（2～3 日、$0-20/月）

  • Algolia、Typesense、または PostgreSQL の全文検索を使用する
  • ユースケースの 80% には十分
  • 適するケース： ドキュメントが 10 万件未満で、キーワードマッチングで十分
  • 確認： ユーザーは関連性の高い結果を得られますか？得られるなら、ここで止めてください。

3. 手動でのキュレーション（コンシェルジュ MVP）（1 週間、$0）

  • ユーザーの質問に手動で回答する
  • よくある質問から FAQ を作成する
  • 適するケース： ユーザーが 100 人未満で、AI をユーザーが求めているか検証する
  • 確認： ユーザーは回答にお金を払うほどの価値を感じていますか？そうであれば、RAG を検討してください。

4. シンプルなセマンティック検索（1 週間、$30-50/月）

  • OpenAI embeddings と Postgres pgvector を使用する
  • 複雑な検索、再ランキングなどは省く
  • 適するケース： ドキュメントが 5 万件未満で、基本的なセマンティック検索を行う
  • 確認： embeddings はキーワード検索より優れていますか？そうでなければ、ここで止めてください。
コストの現実を確認

素朴な RAG（プロトタイプ）：

  • 期間： 1～2 週間
  • コスト： $50-150/月（ベクトルデータベース + embeddings + API 呼び出し）
  • 用途： プロトタイプ、ドキュメント 1 万件未満、概念実証

高度な RAG（本番環境）：

  • 期間： 3～4 週間
  • コスト： $200-500/月（ハイブリッド検索、再ランキング、監視）
  • 用途： 本番環境、ドキュメント 1 万～100 万件、需要を検証済み

モジュラー RAG（エンタープライズ）：

  • 期間： 6～8 週間
  • コスト： $500-2000+/月（複数の KB、専用モジュール）
  • 用途： エンタープライズ、ドキュメント 100 万件以上、ミッションクリティカル
判断フローチャート：本当に RAG が必要ですか？
Do users need to search your content?
│
├─ No → Don't build RAG ❌
│
└─ Yes
   ├─ <50 items? → FAQ page ✅ ($0)
   │
   └─ >50 items?
      ├─ Keyword search enough? → Use Algolia ✅ ($0-20/mo)
      │
      └─ Need semantic understanding?
         ├─ <50k docs? → Simple semantic (pgvector) ✅ ($30/mo)
         │
         └─ >50k docs?
            ├─ Validated with users? → Build RAG ✅
            └─ Not validated? → Test with Concierge MVP first ⚠️
検証チェックリスト

次のすべてを満たす場合にのみ、RAG の実装に進んでください。

  • よりシンプルな代替手段（FAQ、キーワード検索、手動でのキュレーション）を試した
  • ユーザーが AI 検索を必要としていることを確認した（自分がそう思っているだけではない）
  • ROI を算出した：RAG のコスト < ユーザーが得る価値
  • ドキュメントが 5 万件を超える、または複雑なセマンティック検索要件がある
  • 予算：インフラに $200-500/月
  • 期間：本番環境への実装に 3～4 週間

チェックが 1 つでも外れている場合： まず検証するために、product-strategist または mvp-builder のスキルに戻ってください。

関連項目： 段階的な検証プロセスについては、PLAYBOOKS/validation-first-development.md を参照してください。

RAG 実装の 8 フェーズ

フェーズ 1：ナレッジベースの設計

目標：適切に構成された知識基盤を作成する

アクション：

  • データソースを整理する（内部：ドキュメント、データベース、API／外部：ウェブ、フィード）
  • ノイズを除去し、信頼できるコンテンツを選ぶ（「データをただ投入する誤謬」を防ぐ）
  • チャンク分割の方針を定義する：構造に基づくセマンティックなチャンク分割
  • メタデータを追加する：タグ、タイムスタンプ、ソース識別子、カテゴリ

検証：

  • すべてのデータソースをカタログ化し、優先順位を付けた
  • データ品質を評価した（正確性、完全性、鮮度）
  • サンプルドキュメントでチャンク分割の方針をテストした
  • 検索の有効性を高めるためのメタデータスキーマを検証した

一般的なチャンク分割の方針：

  • 固定サイズ：500～1000 トークン、50～100 トークンの重複
  • セマンティック：段落、セクション見出し、またはトピックの境界ごと
  • 再帰的：構造（Markdown の見出し、コードブロック）に沿って分割
フェーズ 2：埋め込み戦略

目標：意味理解に最適な埋め込みアプローチを選択します

アクション：

  • 埋め込みモデルを選択します：汎用用途には text-embedding-3-large（1536 次元）、専門用途にはドメイン固有モデルを使用します
  • マルチモーダルのニーズ（テキスト、コード、画像、表）を計画します
  • ファインチューニングの要否を判断します：汎用埋め込みの性能が不十分な場合は、ドメインデータを使用します
  • 類似度ベンチマークを設定します

検証：

  • ドメインデータで埋め込みモデルのベンチマークを実施済み
  • 既知のクエリとドキュメントのペアを使って検索精度をテスト済み
  • ストレージとコンピューティングのコストを検証済み

モデルの選択：

  • 汎用：OpenAI text-embedding-3-large、text-embedding-3-small
  • コード：code-search-babbage-code-001 または StarEncoder
  • 多言語：multilingual-e5-large
フェーズ 3：ベクトルストアのアーキテクチャ

目標：スケーラブルなベクトルデータベースを実装します

アクション：

  • ベクトル DB（Pinecone、Weaviate、Qdrant、Chroma、pgvector）を選択します
  • インデックスを設定します：速度重視には HNSW、規模重視には IVF を使用します
  • スケーラビリティを計画します：データの増加とクエリ量を考慮します
  • バックアップ、復旧、セキュリティを実装します

検証：

  • 想定負荷のもとでベクトルストアのベンチマークを実施済み
  • 検索速度と精度が最適になるようインデックスを最適化済み
  • バックアップと復旧をテスト済み
  • セキュリティ制御を実装済み

ベクトル DB の選択：

  • マネージドクラウド → Pinecone
  • セルフホスト可能で機能が豊富 → Weaviate
  • 軽量でローカル向け → Chroma
  • コスト重視 → pgvector（Postgres 拡張機能）
  • 高性能 → Qdrant
フェーズ 4：検索パイプライン

目標：単純な類似度検索を超える高度な検索を構築します

アクション：

  • ハイブリッド検索を実装します：セマンティック検索 + キーワード検索（BM25）
  • クエリ拡張を追加します：拡張、再構成、複数クエリ化
  • 文脈に応じたフィルタリングを適用します：メタデータ、時間的制約、関連性ランキング
  • クエリの種類に合わせて設計します：事実確認（精度）、分析（網羅性）、創造（多様性）
  • 関連する結果が見つからない場合などのエッジケースに対応します

高度な手法：

  • 再ランキング：初回の検索後にクロスエンコーダーを使用します（例：cross-encoder/ms-marco-MiniLM-L-12-v2）
  • クエリルーティング：クエリの種類ごとに異なる専用戦略へ振り分けます
  • アンサンブル手法：複数の検索アプローチを組み合わせます
  • 適応型検索：クエリの複雑さに応じて top-k を調整します

検証：

  • 多様なクエリの種類で検索精度をテスト済み
  • ハイブリッド検索が単一手法のベースラインを上回ることを確認済み
  • クエリのレイテンシが要件を満たしている（理想は <500ms）
  • エッジケースとフォールバックをテスト済み
フェーズ 5：コンテキストの組み立て

目標：検索したチャンクを最適な LLM コンテキストに変換します

アクション：

  • ランク付けして選択します：関連性スコア、新しさ、情報源の信頼性を優先します
  • 統合します：関連するチャンクをまとめ、重複を避けます
  • 圧縮します：トークンを最適化するため、LLMLingua などを使用します
  • 「中間での見落とし」を軽減します：重要な情報を最初または最後に配置します
  • 動的に調整します：会話履歴に応じてコンテキストを調整します

コンテキストエンジニアリングとの統合：

  • RAG の結果をシステム指示およびユーザープロンプトと組み合わせます
  • 複数ターンのやり取りを通じて会話の一貫性を維持します
  • フォローアップクエリ向けにコンテキストの永続化を実装します
  • コンテキストのサイズと情報密度のバランスを取ります

検証：

  • 人間による評価と照らし合わせてコンテキストの関連性を検証済み
  • トークン最適化後も精度が維持されている
  • 複数ターンの会話で一貫性が維持されている
  • 組み立てのレイテンシが 200ms 未満
フェーズ 6：評価とメトリクス

目標：RAG システムのパフォーマンスを包括的に測定します

検索品質：

  • Precision@K：上位 K 件の結果のうち、関連性のある結果の割合
  • Recall@K：上位 K 件に含まれる関連ドキュメントの割合
  • MRR（Mean Reciprocal Rank）：最初の関連結果の順位の平均
  • NDCG：段階的な関連度に基づくランキング品質

生成品質：

  • 忠実性：生成されたコンテンツの、ソースに対する正確さ
  • 回答の関連性：クエリに対する回答の関連性
  • コンテキスト活用度：LLM が検索した情報をどれだけ効果的に活用しているか
  • ハルシネーション率：裏付けのない主張が発生する頻度

システムパフォーマンス：

  • エンドツーエンドのレイテンシ：クエリから回答までの時間（目標：3 秒未満）
  • 検索レイテンシ：検索とランキングにかかる時間（500 ms 未満）
  • トークン効率：トークンあたりの情報密度
  • クエリあたりのコスト：検索と生成を合わせたコスト

検証：

  • ベースラインメトリクスを確立済み
  • 設定比較用の A/B テストフレームワーク
  • 自動評価パイプラインをデプロイ済み
  • 正解データ用の人間による評価プロトコル
フェーズ 7：本番環境へのデプロイ

目標：エンタープライズグレードの信頼性とセキュリティを備えてデプロイします

デプロイ：

  • Docker/Kubernetes でコンテナ化します
  • RAG インスタンス間のロードバランシングを実装します
  • 頻繁に行われるクエリ用のキャッシュを追加します
  • グレースフルデグラデーション：コンポーネント障害時はベースモデルにフォールバックします

セキュリティ：

  • ナレッジベースに対するロールベースのアクセス制御
  • データマスキングと個人識別情報（PII）の保護
  • コンプライアンス対応の監査ログ
  • プロンプトインジェクション対策

モニタリング：

  • リアルタイムのメトリクスダッシュボード（レイテンシ、コスト、精度）
  • パターンと障害モードを把握するためのクエリ分析
  • コスト追跡と最適化アラート
  • ボトルネックを特定するためのパフォーマンスプロファイリング

検証：

  • 本番環境で想定されるトラフィックに対応できる
  • セキュリティによって不正アクセスを防止できる
  • モニタリングから実行可能な分析情報が得られる
  • インシデント対応手順のテスト済み
フェーズ 8：継続的な改善

目標：継続的な強化に向けたプロセスを確立します

データパイプライン：

  • ナレッジベースの自動更新（リアルタイムまたはスケジュール実行）
  • 品質モニタリング：データドリフトと品質低下を検出します
  • ソースの多様化：新しいデータソースを追加します
  • フィードバックの統合：ユーザーによる修正や好みを反映します

モデルの進化：

  • 改良された埋め込みモデルを評価し、移行します
  • ドメインデータを用いて定期的にファインチューニングします
  • アーキテクチャをアップグレードします：Naive → Advanced → Modular RAG
  • マルチモーダル対応を拡大します（画像、音声、動画）

最適化：

  • クエリパターンを分析し、一般的なニーズに合わせて最適化します
  • キャッシュヒット率を改善します
  • ベクトルインデックスを定期的に調整します
  • パフォーマンスとコストのバランスを取ります

検証：

  • 自動改善パイプラインが稼働中
  • パフォーマンスの傾向が改善を示している
  • ユーザー満足度が向上している
  • システムが変化するニーズに適応する

RAG の主要原則

1. 量より関連性
  • 大規模なデータセットより、質の高い選別を優先します
  • 古くなったコンテンツや低品質なコンテンツを継続的に削除します
  • 「中間で見失う」問題を防ぐため、最も関連性の高い情報を優先します
2. セマンティックな理解
  • キーワードだけでなく、真のセマンティックマッチングに埋め込みを使用します
  • クエリの意図（事実確認、分析、創作）を認識します
  • コンテキストに基づいて検索戦略を調整します
3. マルチモーダルインテリジェンス
  • テキスト、画像、コード、表、構造化データを扱います
  • モダリティをまたいだ検索を可能にします（テキストクエリ → 画像の結果）
  • ドキュメントの構造と書式を保持します
4. 時間的な認識
  • 時間に左右されるトピックでは、新しい情報を優先します
  • 関連する場合は過去の情報へのアクセスを維持します
  • 動的なドメインではリアルタイムのデータフィードを統合します
5. 透明性と信頼
  • 常にソースを引用します
  • 信頼度を示します
  • 特定の情報が選ばれた理由を説明します

標準的な RAG 応答形式

{
  "answer": "Generated response incorporating retrieved information",
  "sources": [
    {
      "content": "Retrieved text chunk",
      "source": "Document/URL identifier",
      "relevance_score": 0.95,
      "chunk_id": "unique_identifier"
    }
  ],
  "confidence": 0.87,
  "retrieval_metadata": {
    "chunks_retrieved": 5,
    "retrieval_time_ms": 150,
    "generation_time_ms": 800
  }
}

成功に不可欠なルール

必須事項：

  1. ✅ すべての応答で出典を明記する
  2. ✅ 生成したコンテンツをソースと照合して検証する（ハルシネーションを防止する）
  3. ✅ 検索前に機密データをフィルタリングする
  4. ✅ レイテンシのしきい値内（3 秒未満）に応答する
  5. ✅ コストを継続的に監視し、最適化する
  6. ✅ セキュリティポリシーを遵守する
  7. ✅ 障害発生時も適切に縮退運転する
  8. ✅ 本番環境への導入前に包括的なテストを実施する

品質ゲート：

  • 本番環境への導入前：評価データセットで 85% 超の精度
  • 継続的な評価：ユーザー満足度 4.0/5.0 超
  • パフォーマンス：95 パーセンタイルで 5 秒未満
  • 信頼性：稼働率 99.5%
  • コスト：予算の 10% 以内

高度なパターン

モジュール型 RAG アーキテクチャ
  • 検索モジュール：クエリの理解と再構成
  • メモリモジュール：会話の長期的な保持
  • ルーティングモジュール：クエリを専門のナレッジベースにルーティング
  • 予測モジュール：コンテキストに基づく先読みロード
ハイブリッド RAG ＋ファインチューニング
  • 動的に変化する頻繁に更新される知識には RAG を使用する
  • ドメイン固有の推論パターンにはファインチューニングを使用する
  • それぞれの強みを組み合わせ、効果を最大化する

関連リソース

関連スキル：

  • multi-agent-architect - 複雑な RAG オーケストレーション向け
  • knowledge-graph-builder - 構造化された知識の統合向け
  • performance-optimizer - RAG システムの最適化向け

関連パターン：

  • META/DECISION-FRAMEWORK.md - ベクトル DB と埋め込みの選定
  • STANDARDS/architecture-patterns/rag-pattern.md - RAG アーキテクチャの詳細（作成時）

関連プレイブック：

  • PLAYBOOKS/deploy-rag-system.md - RAG のデプロイ手順（作成時）

コメント

Markdown 対応