MCP-Pinecone環境構築
Claude DesktopでPineconeを使ったRAGシステムを構築するための手順ガイドです。
MCP-Pinecone環境構築
@Devin
# MCP-Pinecone環境構築タスク
## 前提条件
- Claude Desktop: インストール済み
- Python環境: バージョン3.9以上
- Pineconeアカウント: 要APIキー取得
- 必要パッケージ: uvicorn, pydantic, pymupdf等
## インストール手順
1. MCPサーバーのインストール
```bash
pip install uv
uvx install mcp-pinecone
```
または
```bash
uv pip install mcp-pinecone
```
2. Pineconeインデックス作成
- Pineconeコンソールでインデックスを作成
- 適切な次元数(例: 1536 for OpenAI)を設定
- メトリクスはコサイン類似度を推奨
3. Claude Desktop設定
- 設定ファイルの場所:
- MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%/Claude/claude_desktop_config.json
- 設定ファイルに以下を追加:
```json
"mcpServers": {
"mcp-pinecone": {
"command": "uvx",
"args": [
"--index-name",
"your-index-name",
"--api-key",
"your-pinecone-api-key",
"mcp-pinecone"
]
}
}
```
## 動作確認
1. Claude Desktopを再起動
2. MCPサーバーが「semantic-search」などのツールを提供していることを確認
3. テストクエリで検索機能を確認
環境変数設定例
# .env ファイル例
PINECONE_API_KEY=your-api-key-here
PINECONE_INDEX_NAME=your-index-name
PINECONE_ENVIRONMENT=gcp-starter
MCPサーバーのデバッグには、MCP Inspectorを使用すると便利です。以下のコマンドで起動できます:
npx @modelcontextprotocol/inspector uv --directory {project_dir} run mcp-pinecone
Pineconeインデックス設計
RAGシステムのためのPineconeインデックス設計ガイドです。
Pineconeインデックス設計ガイド
@Devin
# Pineconeインデックス設計ガイド作成タスク
## インデックス基本設計
1. ベクトル次元数の選定
- OpenAI Ada-002: 1536次元
- BERT: 768次元
- 他の埋め込みモデルに応じた次元数
2. メトリクスの選定
- コサイン類似度: 方向性の類似度を重視(一般的なテキスト検索に推奨)
- ユークリッド距離: 絶対的な距離を重視
- ドットプロダクト: 大きさと方向の両方を考慮
3. インデックスタイプの選定
- Approximated (ANN): 大規模データに適した近似検索
- Exact: 小~中規模データに適した厳密検索
## インデックス最適化
1. シャーディング
- データ量とクエリレイテンシに基づいたシャード数設定
- シャードサイズの最適化ガイドライン
2. レプリケーション
- 可用性と並列クエリ処理に基づいたレプリカ数設定
- コストとパフォーマンスのバランス
3. ポッドタイプ選択
- s1: 標準的なワークロード向け
- p1: 高パフォーマンス向け
- p2: 最高パフォーマンス向け
## 名前空間とメタデータ設計
1. 名前空間戦略
- 複数ドメインのデータを分離
- アクセス制御の実装
- A/Bテストの実施
2. メタデータスキーマ設計
- 効果的なフィルタリング用メタデータフィールド
- インデックス付きフィールドの選定
- ネストされたメタデータ構造の活用
Pineconeインデックス設計のポイント:
- 埋め込みモデルに合わせた次元数を使用する(次元数の不一致はエラーの原因になります)
- メタデータはクエリ時のフィルタリングに活用できるよう設計する
- 名前空間を使って論理的にデータを分離する(テスト/開発/本番など)
最適なチャンキング戦略
RAGシステムの検索精度を大きく左右するチャンキング(文書分割)戦略の設計ガイドです。
RAGチャンキング最適化
@Devin
# RAGチャンキング戦略最適化タスク
## チャンキング要件分析
- ドキュメントタイプ: [PDF, HTML, テキスト等]
- コンテンツ構造: [長文、技術文書、会話等]
- 言語特性: [日本語、英語、多言語等]
- 検索ユースケース: [質問応答、サマリー生成等]
## チャンキング戦略設計
1. サイズベースチャンキング
- 文字数/トークン数の最適サイズ決定
- オーバーラップ戦略の設計
- 最大/最小サイズの制約設定
2. セマンティックチャンキング
- 意味単位での分割アルゴリズム設計
- 文脈一貫性の維持方法
- セクション/段落の境界検出
3. 階層型チャンキング
- 大→中→小の階層的分割設計
- 親子関係のメタデータ設計
- 階層間のリンク方法
## 実装タスク
1. チャンキングパイプラインの実装
2. 前処理フィルターの実装(箇条書き、表、コード等の特殊処理)
3. メタデータ付与システムの実装
4. チャンク品質評価システムの実装
## 最適化と評価
- 異なるチャンキング戦略の比較実験
- 検索精度との相関分析
- ユースケース別の最適パラメータ導出
日本語テキストのチャンキングでは、単純な文字数や行数による分割ではなく、意味のまとまりを考慮した分割が重要です。また、固有名詞や専門用語が分断されないよう配慮が必要です。
専門分野別チャンキング
@Devin
# 専門分野別チャンキング戦略設計タスク
## 法律文書向けチャンキング
- 条文・項・号の構造を保持する分割
- 法的参照の維持
- 定義・例外・条件の文脈保持
- 判例引用の適切な処理
## 医療文書向けチャンキング
- 患者情報・診断・処方の論理単位保持
- 医学用語の分断防止
- 時系列データの文脈保持
- プライバシー考慮(個人特定情報の管理)
## 技術文書向けチャンキング
- コードブロックの一体処理
- APIリファレンスの構造保持
- 図表参照の維持
- 専門用語・略語の文脈保持
## 実装アプローチ
1. 分野特化ルールベースのチャンキング設計
2. 専門用語辞書との連携
3. 構造認識パーサーの実装
4. メタデータスキーマの分野別カスタマイズ
## 評価方法
- 専門家によるチャンク品質評価
- 分野特化クエリセットでの精度測定
- 生成応答の専門的正確性評価
RAG評価フレームワーク
RAGシステムのパフォーマンスを包括的に評価するためのフレームワークと指標です。
RAG評価メトリクス設計
@Devin
# RAG評価フレームワーク設計タスク
## 評価目標設定
- 検索精度評価: [目標精度レベル]
- 応答品質評価: [正確性、完全性等の要件]
- システムパフォーマンス評価: [レイテンシ、スループット等の目標]
- ユーザー体験評価: [使いやすさ、満足度等の目標]
## 評価メトリクス設計
1. 検索関連性メトリクス
- Precision@K: 上位K件の検索結果中の関連ドキュメント割合
- Recall: 関連ドキュメント全体のうち検索で取得できた割合
- Mean Reciprocal Rank (MRR): 最初の関連ドキュメントの順位の逆数の平均
- Normalized Discounted Cumulative Gain (NDCG): 順位を考慮した関連性スコア
2. 応答品質メトリクス
- 事実的正確性: 生成内容と参照情報の一致度
- 完全性: クエリに対する回答の網羅性
- 簡潔性: 無関係な情報のない簡潔な回答
- ハルシネーション率: 事実と異なる生成内容の割合
3. システムパフォーマンスメトリクス
- E2Eレイテンシ: クエリから応答までの総時間
- 検索時間: ベクトル検索に要する時間
- 生成時間: テキスト生成に要する時間
- リソース使用率: CPU/GPU/メモリ使用効率
## 評価方法実装
1. 自動評価システムの設計
2. 人間評価プロセスの設計
3. A/Bテスト設計
4. ベンチマーク環境の構築
## 継続的評価プロセス
- パフォーマンスモニタリングダッシュボード
- 定期的な評価サイクルの設計
- 改善提案の自動化メカニズム
RAGシステムの成功は、単なる検索精度だけでなく、最終的な応答の品質とユーザー満足度によって評価すべきです。
RAGシステム診断
@Devin
# RAGシステム診断と改善タスク
## システム診断
1. 検索障害パターンの特定
- 関連性の低い検索結果
- 特定ドメインでの検索失敗
- 検索エッジケースの特定
2. 生成障害パターンの特定
- ハルシネーション発生パターン
- コンテキスト無視パターン
- 矛盾した応答パターン
3. システムボトルネック分析
- レイテンシホットスポット
- リソース使用効率低下ポイント
- スケーラビリティ制約
## 問題解決アプローチ
1. 検索品質改善
- チャンキング戦略の最適化
- 埋め込みモデル/パラメータの調整
- メタデータフィルタリングの強化
2. 生成品質改善
- プロンプトエンジニアリング
- コンテキスト選択アルゴリズムの改善
- ポストプロセッシングフィルターの実装
3. パフォーマンス最適化
- キャッシュ戦略の実装
- インデックス最適化
- リソーススケーリング調整
## 実装計画
- 問題の優先順位付け
- 改善実装ロードマップ
- 評価と検証計画
MCPサーバー実装
Model Context Protocol(MCP)サーバーを実装してClaude Desktopと統合するための詳細ガイドです。
MCPツール設計パターン
@Devin
# MCP RAGツール設計パターンタスク
## 基本MCPツール設計
1. semantic-search
- 目的: セマンティック検索の実行
- パラメータ:
- query: 検索クエリ
- top_k: 取得するドキュメント数
- filter: メタデータフィルター条件
- 戻り値: 関連ドキュメントの配列
2. retrieve-document
- 目的: ドキュメントID/URLによる直接取得
- パラメータ:
- document_id: 取得するドキュメントのID
- 戻り値: ドキュメント全文とメタデータ
3. process-document
- 目的: 新規ドキュメントの処理とインデックス登録
- パラメータ:
- document_url: 処理するドキュメントのURL/パス
- metadata: 付与するメタデータ
- 戻り値: 処理結果とドキュメントID
## 高度なMCPツール設計
1. query-refinement
- 目的: ユーザークエリの最適化
- パラメータ:
- original_query: 元のクエリ
- context: 会話コンテキスト
- 戻り値: 最適化されたクエリ
2. multi-index-search
- 目的: 複数インデックスの横断検索
- パラメータ:
- query: 検索クエリ
- indexes: 検索対象インデックスの配列
- 戻り値: 統合された検索結果
3. search-analyze
- 目的: 検索結果の分析と要約
- パラメータ:
- search_results: 検索結果配列
- analysis_type: 分析タイプ
- 戻り値: 分析結果と要約
## 実装アプローチ
1. Pythonベース実装
```python
@tool("semantic-search")
async def semantic_search(query: str, top_k: int = 5, filter: dict = None) -> List[Document]:
# 実装コード
pass
```
2. TypeScriptベース実装
```typescript
export const semanticSearch: Tool<{
query: string;
top_k?: number;
filter?: Record;
}, Document[]> = {
name: "semantic-search",
description: "...",
parameters: { ... },
handler: async (params) => {
// 実装コード
}
};
```
MCP-Pinecone統合コード例
import { tool } from "@modelcontextprotocol/runtime";
import { PineconeClient } from "@pinecone-database/pinecone";
// Pineconeクライアント初期化
const pinecone = new PineconeClient();
await pinecone.init({
apiKey: process.env.PINECONE_API_KEY,
environment: process.env.PINECONE_ENVIRONMENT
});
const index = pinecone.Index(process.env.PINECONE_INDEX);
// セマンティック検索ツール
export const semanticSearch = tool({
name: "semantic-search",
description: "意味的な検索を実行する",
parameters: {
query: {
type: "string",
description: "検索クエリ"
},
top_k: {
type: "number",
description: "取得する結果の数",
default: 5
},
filter: {
type: "object",
description: "メタデータフィルター",
optional: true
}
},
handler: async ({ query, top_k, filter }) => {
// 埋め込みベクトル生成
const embedding = await generateEmbedding(query);
// Pinecone検索実行
const results = await index.query({
vector: embedding,
topK: top_k,
filter: filter,
includeMetadata: true
});
return results.matches.map(match => ({
id: match.id,
text: match.metadata.text,
metadata: match.metadata,
score: match.score
}));
}
});
MCPサーバー開発のポイント:
- ツール名と説明は明確で理解しやすくすること
- パラメータには適切な型と説明、デフォルト値を設定すること
- エラーハンドリングを丁寧に実装し、わかりやすいエラーメッセージを返すこと
- ツールの応答時間を最適化し、タイムアウト処理を実装すること
デプロイメントパターン
RAGシステムの様々なデプロイメントパターンとベストプラクティスのガイドです。
RAGデプロイメントパターン
@Devin
# RAGデプロイメントパターン設計タスク
## 主要デプロイメントパターン
1. サーバーレスRAG
- アーキテクチャ:
- AWS Lambda/Azure Functions/Google Cloud Functions
- Pineconeベクトルストア
- API Gateway
- 利点:
- 自動スケーリング
- 低運用コスト
- 迅速なデプロイ
- 注意点:
- コールドスタート
- 実行時間制限
- メモリ制限
2. コンテナベースRAG
- アーキテクチャ:
- Kubernetes/ECS/GKE
- マイクロサービス分割
- 水平スケーリング
- 利点:
- 細かいリソース制御
- 高い柔軟性
- 長時間実行処理
- 注意点:
- 運用複雑性
- 初期設定の労力
- リソース管理
3. エッジRAG
- アーキテクチャ:
- ローカルベクトルDB
- 軽量埋め込みモデル
- ローカルLLM/外部LLM連携
- 利点:
- レイテンシ低減
- オフライン動作
- データプライバシー
- 注意点:
- リソース制約
- インデックスサイズ制限
- 更新同期
## 実装考慮事項
1. スケーリング戦略
2. データ更新パイプライン
3. 監視とアラート設定
4. バックアップと障害復旧
5. セキュリティ設計
## 運用ベストプラクティス
- ブルー/グリーンデプロイメント
- カナリアリリース
- パフォーマンスベンチマーク
- 負荷テスト計画
RAGシステムのデプロイでは、検索と生成の両方のパフォーマンスを考慮し、ボトルネックとなる部分を特定して最適化することが重要です。
ハイブリッドRAGアーキテクチャ
@Devin
# ハイブリッドRAGアーキテクチャ設計タスク
## アーキテクチャ目標
- 高速応答と高品質検索のバランス
- オンライン/オフラインデータの統合
- プライベートデータとパブリックデータの融合
- リソース効率の最適化
## ハイブリッドアーキテクチャ設計
1. マルチインデックス設計
- 頻出クエリ用高速キャッシュインデックス
- 大規模完全インデックス
- 特殊ドメイン専用インデックス
2. マルチレベル検索
- レベル1: ローカル/エッジ検索(低レイテンシ)
- レベル2: クラウドベース検索(高精度)
- 検索結果マージ戦略
3. アダプティブ生成
- コンテキストサイズ動的最適化
- モデル選択ロジック
- 応答品質フィードバックループ
## 実装タスク
1. ルーティングエンジンの実装
2. マルチレベルキャッシュの実装
3. 検索結果統合アルゴリズムの実装
4. フォールバック戦略の実装
## パフォーマンス最適化
- キャッシュウォーミング戦略
- 予測的検索の実装
- 非同期データ同期メカニズム
プロンプトエンジニアリング
RAGシステムの性能を最大化するためのプロンプトエンジニアリングベストプラクティスです。
RAG向けプロンプト戦略
@Devin
# RAG向けプロンプト戦略設計タスク
## システムプロンプト設計
- モデル役割の明確な定義
- RAGコンテキスト利用指示の明示
- 応答フォーマットの統一
- 情報源の引用方法の指定
- エッジケース処理の指示
## ユーザークエリ最適化
1. クエリリファイメント戦略
- 曖昧なクエリの明確化
- 検索用語の最適化
- エンティティ抽出と標準化
2. クエリルーティング
- 検索が必要なクエリの特定
- 適切なインデックス選択
- パラメータ自動調整
## RAGコンテキスト最適化
1. コンテキスト選択
- 関連性順ランキング
- 多様性確保
- 情報の新鮮さ考慮
2. コンテキスト形式
- 構造化フォーマット
- メタデータの効果的提示
- 優先度表示
## 応答生成プロンプト
- 事実検証と整合性確認
- 不確かな情報の処理方法
- 出典の適切な引用
- 回答が不可能な場合の対応
## プロンプトテンプレート例
```
あなたは[組織名]の知識支援AIです。以下の検索結果を参考に、ユーザーの質問に答えてください。
検索結果:
{{retrieved_documents}}
検索結果に関連情報がない場合は、「その情報は見つかりませんでした」とだけ答え、推測しないでください。
情報の出典を必ず[出典: ドキュメント名]の形式で明記してください。
複数の情報源がある場合は、矛盾点や共通点を明確にしてください。
ユーザーの質問: {{user_question}}
```
プロンプトエンジニアリングはRAGシステムの精度と応答品質を大きく向上させる重要な要素です。継続的なA/Bテストを行い最適化しましょう。
プロンプトパターンライブラリ
@Devin
# RAGプロンプトパターンライブラリ作成タスク
## 基本プロンプトパターン
1. 標準RAGプロンプト
```
システム: 以下の情報を参考に、ユーザーの質問に簡潔に答えてください。情報がない場合は「情報がありません」と答えてください。
コンテキスト:
{{context}}
ユーザー: {{query}}
```
2. 段階的思考RAGプロンプト
```
システム: 以下のステップに従って回答を生成してください:
1. 提供された情報を注意深く分析する
2. 質問に関連する事実を抽出する
3. 論理的に推論して結論を導く
4. 簡潔な回答を作成する
コンテキスト:
{{context}}
ユーザー: {{query}}
```
3. 専門家ペルソナRAGプロンプト
```
システム: あなたは{{domain}}の専門家です。専門的な視点から、以下の情報を参考にユーザーの質問に答えてください。
コンテキスト:
{{context}}
ユーザー: {{query}}
```
## 用途別プロンプトパターン
1. 要約生成プロンプト
2. 比較分析プロンプト
3. 手順説明プロンプト
4. 問題解決プロンプト
## プロンプト最適化戦略
- A/Bテスト設計
- プロンプトバージョン管理
- パフォーマンス測定指標
- 継続的改善プロセス
プロンプトを設計する際は、LLMの強みと弱みを理解した上で、具体的で明確な指示を与えることが重要です。また、プロンプトのバージョン管理を適切に行い、効果を測定しながら改善していきましょう。