rag-implementer について
検索拡張生成システムを構築する開発者向けのスキルです。検索、コンテキスト構成、生成、評価を扱い、ハイブリッド検索や再ランキング、分割方式を解説し、複雑化の前に需要を確かめる方針を示します。
主な機能
- 01RAG の 3 段階パイプライン設計
- 02セマンティック検索とキーワード検索の併用
- 03検索コンテキストの再ランキングと圧縮
- 04分割方式とベクトルストアの選定
- 05再現率、忠実度、レイテンシの測定
活用シーン
- 01独自文書を対象とする質問応答の構築
- 02ハイブリッド検索と再ランキング方式の比較
- 03知識関係をたどる多段検索の設計
- 04本番導入前の RAG 品質評価
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/rag-implementerを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/architecture-patterns.mdchunking-strategies.mdevaluation.mdproduction-deployment.mdretrieval-methods.md詳細
RAG 実装者
本番環境に対応した検索拡張生成システムを構築します。RAG ＝ 検索＋コンテキストの組み立て＋生成です。LLM が、学習データに含まれていない最新情報、専門分野の知識、または独自の知識にアクセスする必要がある場合に RAG を使用してください。FAQ ページ、キーワード検索、セマンティック検索など、よりシンプルな方法で十分な場合は RAG を使用しないでください。ナレッジベースのアーキテクチャ選定とガバナンスには、knowledge-base-manager スキルを使用してください。ナレッジグラフの実装には、knowledge-graph-builder スキルを使用してください。
概要
RAG の構築に着手する前に、その必要性を検証してください。まずは FAQ ページ、キーワード検索、コンシェルジュ MVP、またはシンプルなセマンティック検索を試してください。ユーザー需要が確認できており、月額 200～500 ドルの予算があり、文書数が 50,000 件以上の場合に限り、RAG に進んでください。RAG システムは、プロトタイプ向けのナイーブなものから、本番環境向けの高度なもの、エンタープライズ向けのモジュラー型まであり、各段階で複雑さとコストが増します。
RAG パイプラインには、3 つの主要なステージがあります。1 つ目の検索では、ハイブリッド検索（セマンティック検索＋キーワード検索）を使用して関連文書を見つけます。2 つ目のコンテキストの組み立てでは、取得したチャンクをランキングし、重複を除去して圧縮し、最適なプロンプトを作成します。3 つ目の生成では、出典を明示した、根拠に基づく回答を生成します。各ステージには固有の失敗要因があります。検索では関連文書を見落とす（再現率が低い）ことがあり、コンテキストの組み立てではモデルに情報を与えすぎる（中間情報の喪失）ことがあり、生成では適切なコンテキストがあってもハルシネーションが発生する（忠実度が低い）ことがあります。
最新の RAG は、基本的なベクトル類似度検索を超えるものです。密な埋め込みと疎な BM25 を組み合わせたハイブリッド検索が、現在では標準となっています。初期検索後にクロスエンコーダーで再ランキングすると、適合率が向上します。コンテキストを考慮したチャンク分割やレイトチャンク化では、固定サイズのチャンク分割では失われる文書レベルの意味を保持できます。GraphRAG は、文書からナレッジグラフを構築することで、エンティティ間の関係をたどる複数ホップの推論を可能にします。命題チャンク化では、文書を個々の主張を正確に検索できるよう、原子的な事実に分割します。
クエリの複雑さと文書の構造に基づいて手法を選択してください。まず、基盤としてハイブリッド検索と再ランキングを導入し、必要に応じてコンテキストを考慮したチャンク分割、GraphRAG、またはクエリ拡張を追加してください。すべてを測定してください。Precision@K、Recall@K、忠実度、エンドツーエンドのレイテンシを測定します。チャンク分割戦略の良し悪しだけで、再現率に 9％の差が生じることがあります。
クイックリファレンス
| フェーズ | 目標 | 主なアクション |
|---|---|---|
| 1. ナレッジベースの設計 | 構造化された知識基盤 | ソースをマッピングし、チャンク分割を定義して、メタデータを追加する |
| 2. 埋め込み戦略 | 意味の理解 | モデルを選択し、ドメインデータでベンチマークを実施する |
| 3. ベクトルストア | スケーラブルなストレージ | DB を選択し、インデックスを構成して、スケーリングを計画する |
| 4. 検索パイプライン | 単純な類似性検索を超える | ハイブリッド検索、クエリの強化、再ランキング |
| 5. コンテキストの組み立て | 最適な LLM コンテキスト | ランク付け、統合、圧縮、「中間で見失う」問題の軽減 |
| 6. 評価 | パフォーマンスの測定 | Precision@K、Recall@K、忠実性、レイテンシ |
| 7. 本番環境へのデプロイ | エンタープライズレベルの信頼性 | コンテナ化、キャッシュ、グレースフルデグラデーション、セキュリティ |
| 8. 継続的改善 | 継続的な強化 | 自動更新、ファインチューニング、最適化 |
| 判断項目 | 選択肢 |
|---|---|
| ベクトル DB（マネージド） | Pinecone |
| ベクトル DB（セルフホスト） | Weaviate、Qdrant |
| ベクトル DB（軽量） | Chroma |
| ベクトル DB（既存の Postgres） | pgvector |
| ベクトル DB（10 億規模） | Milvus / Zilliz |
| 埋め込み（汎用） | text-embedding-3-large（3072 次元） |
| 埋め込み（コスト最適化） | text-embedding-3-small（1536 次元） |
| 埋め込み（コード） | Voyage Code 3 |
| 埋め込み（多言語） | multilingual-e5-large、Cohere embed-v4 |
| チャンク分割（固定） | 500～1000 トークン、オーバーラップ 50～100 |
| チャンク分割（意味ベース） | 段落／セクション／トピックの境界 |
| チャンク分割（再帰的） | Markdown の見出し、コードブロック |
| チャンク分割（コンテキスト付加） | LLM が生成した要約を各チャンクの先頭に追加 |
| チャンク分割（レイト） | ドキュメント全体を埋め込み、その後チャンク境界でプーリング |
| コスト層 | 期間 | 月額費用 | 規模 |
|---|---|---|---|
| 素朴な RAG（プロトタイプ） | 1～2 週間 | $50-150 | <10k ドキュメント |
| 高度な RAG（本番環境） | 3～4 週間 | $200-500 | 10k-1M ドキュメント |
| モジュラー RAG（エンタープライズ） | 6～8 週間 | $500-2000+ | 1M+ ドキュメント |
| 高度な手法 | 使用する場面 |
|---|---|
| ハイブリッド検索 | 常に使用します。意味検索とキーワード検索（BM25）を組み合わせ、再現率を高めます |
| 再ランキング | 初回の検索結果にノイズが多い場合 |
| コンテキスト検索 | 曖昧な参照表現や代名詞を含むドキュメント |
| レイトチャンク分割 | 照応表現を含む、効率重視のパイプライン |
| GraphRAG | 構造化された知識の関係に対するマルチホップ推論 |
| 命題チャンク分割 | 原子的な検索単位を必要とする、事実密度の高いドキュメント |
| クエリ拡張 / HyDE | 短い、曖昧、または情報が不足しているクエリ |
よくある間違い
| 間違い | 正しい方法 |
|---|---|
| ユーザーのニーズを検証する前に RAG を構築する | まずはよりシンプルな代替手段（FAQ、キーワード検索、コンシェルジュ MVP）を試し、需要を検証してから RAG を構築します |
| 単一の検索方法（セマンティック検索のみ）を使用する | セマンティック検索とキーワード検索（BM25）を組み合わせたハイブリッド検索を実装し、再現率を高めます |
| 利用可能なデータをすべてナレッジベースに投入する | データソースを慎重に選定し、ノイズを除去して、信頼できるコンテンツを選び、品質を維持します |
| 「lost in the middle」問題を無視する | 重要な情報をコンテキストの冒頭と末尾に配置し、中間部分を圧縮します |
| 本番環境への導入前に評価指標を設定しない | 導入前に Precision@K、Recall@K、忠実性、ハルシネーション率のベースラインを確立します |
ベンチマークを行わずに text-embedding-3-large を 3072 次元でそのまま使用する | まずは次元数を減らして（1024 または 1536）テストします。多くの場合、コストを抑えながら同等の精度を得られます |
| すべてのドキュメントタイプに固定サイズのチャンク分割を使う | ドキュメントの構造に合わせてチャンク分割方法を選び、構造化されたコンテンツにはセマンティック分割や再帰的分割を使います |
| メタデータによるフィルタリングを無視する | 豊富なメタデータ（ソース、日付、カテゴリ）を付与し、ベクトル検索の前または検索中にフィルタリングします |
埋め込みモデルに関する注意事項
text-embedding-3-large（3072 次元）は、引き続き OpenAI の最も高性能な埋め込みモデルです。dimensions API パラメーターを使った Matryoshka 次元削減に対応しており、1024 次元でも、ストレージコストを 3 分の 1 に抑えながら、最大次元数に近い精度が得られることがよくあります。text-embedding-3-small（1536 次元）は、100 万トークンあたり $0.02 のコスト効率に優れた代替モデルです。コード検索では、Voyage Code 3 が汎用モデルを上回ります。多言語のワークロードでは、multilingual-e5-large または Cohere embed-v4 を検討してください。必ず自分のドメインのデータでベンチマークを実施してください。一般的なベンチマークでは、ドメイン固有の性能は予測できません。
ベクトルストアに関する注意事項
マネージドでシンプルな運用には Pinecone、ハイブリッド検索を備えたセルフホスト可能な構成には Weaviate または Qdrant、プロトタイピングには Chroma、すでに PostgreSQL を利用しているチームには pgvector（実用上の上限は約 1,000 万～1 億ベクトル）、数十億規模のデプロイには Milvus/Zilliz が適しています。トレードオフに基づいてインデックスの種類を選んでください。速度重視なら HNSW（メモリ使用量は増加）、規模重視なら IVF（トレーニングが必要）、小規模なデータセットでの厳密な検索に限るならフラットインデックスが適しています。
現在、ほとんどのベクトルデータベースは、100 万～1,000 万ベクトルのデータセットで 10～100ms のクエリレイテンシを実現しています。規模の要件を満たす最もシンプルな選択肢から始め、具体的な性能上の限界に達した場合にのみ移行してください。
委任
- データソースを調査し、ナレッジベースの品質を評価する：
Exploreエージェントを使って、ドキュメントを一覧化し、データの鮮度を評価して、信頼できるコンテンツを特定します - ハイブリッド検索と再ランキングを備えた検索パイプラインを実装する：
Taskエージェントを使って、埋め込み、インデックス作成、検索、評価のコンポーネントを構築します - RAG アーキテクチャとベクトルストアの構成を設計する：
Planエージェントを使って、埋め込みモデル、ベクトルデータベース、チャンク分割方法、デプロイアーキテクチャを選定します
ナレッジベースのアーキテクチャ選定、キュレーションのワークフロー、ガバナンスには、
knowledge-base-managerスキルを使用してください。ナレッジグラフの実装（オントロジー、エンティティ抽出、グラフデータベース）には、knowledge-graph-builderスキルを使用してください。