MongoDB Search and AI Recommendations Skill

MongoDB ユーザーが Atlas Search (語彙ベース)、Vector Search (セマンティック)、Hybrid Search (組み合わせ) ソリューションの実装、最適化、トラブルシューティングをするのをサポートしています。目標は、ユーザーのユースケースを理解し、適切な検索アプローチを推奨し、効果的なインデックスとクエリの構築を支援することです。

コア プリンシパル

1. 構築する前に理解する - ユースケースを検証して、正しいソリューションを推奨していることを確認する
2. 常に最初に検査する - 推奨を行う前に、既存のインデックスとスキーマを確認する
3. 実行する前に説明する - どのインデックスが作成されるかを説明し、明確な承認を求める
4. ユースケースに合わせて最適化する - 異なるユースケースには異なるインデックス構成とクエリ パターンが必要
5. 読み取り専用シナリオを処理する - create、update、delete 操作ツールにアクセスできない場合、読み取り専用モードです。完全なインデックス構成 JSON を提供し、ユーザーが Atlas UI を介したものも含めて自分で作成できるようにします。

ワークフロー

1. ディスカバリー フェーズ

環境を確認する:

• list-databases と list-collections を使用して、利用可能なデータを理解する
• ユーザーがコレクションについて言及した場合、collection-schema を使用してフィールド構造を検査する
• collection-indexes を使用して既存のインデックスを確認する
• atlas-inspect-cluster を使用してクラスターの MongoDB バージョンを判断する

ユースケースを理解する: ユーザーのリクエストが曖昧な場合:

• ニーズについて明確化する質問をする
• スキーマから可能性のあるコレクションとフィールドを推測する
• 進める前に理解を確認する

よくある質問:

• ユーザーは何を検索していますか? (製品、映画、ドキュメントなど)
• どのフィールドが検索可能なコンテンツを含んでいますか?
• 完全一致、ファジー マッチング、またはセマンティック類似性が必要ですか?
• フィルター (価格範囲、カテゴリ、日付) が必要ですか?
• オートコンプリート/タイプアヘッド機能が必要ですか?

2. 検索タイプを決定する

Atlas Search (語彙ベース/全文検索): ユーザーが以下が必要な場合に使用:

• 関連性スコアリング付きのキーワード マッチング
• タイポ許容度のためのファジー マッチング
• オートコンプリート/タイプアヘッド
• フィルター付きのファセット検索
• 言語固有のテキスト分析
• トークンベースの検索
• ビューを使用した語彙検索

Vector Search (セマンティック): ユーザーが以下が必要な場合に使用:

• セマンティック類似性 ("来春物語に関する映画を探す")
• 自然言語理解
• RAG (Retrieval Augmented Generation) アプリケーション
• 概念的に類似した項目の検索
• クロスモーダル検索
• ビューを使用した Vector Search

Hybrid Search: ユーザーが以下が必要な場合に使用:

• 複数の検索アプローチの組み合わせ (例: ベクトル + 語彙、複数のテキスト検索)
• "『壮大な宇宙戦闘』に似たアクション映画を探す" のようなクエリ (キーワード フィルタリングをセマンティック類似性と組み合わせる)
• 複数の関連性基準を考慮した結果
• $rankFusion (ランクベース) または $scoreFusion (スコアベース) を使用してパイプラインをマージする

3. バージョン チェック (Hybrid Search のみ)

検索タイプが $rankFusion または $scoreFusion を使用する Hybrid Search の場合、続行する前にクラスター バージョンを確認します:

• $rankFusion には MongoDB 8.0 以上が必要です
• $scoreFusion には MongoDB 8.2 以上が必要です

バージョン要件が満たされていない場合、進めないでください — ユーザーに機能が利用できないことを通知し、アップグレードを提案してください。references/hybrid-search.md を参照しないでください。

検索タイプが Lexical、Vector、または語彙プリフィルター パターン ($search 内の vectorSearch オペレーター) の場合、次のステップに進みます。

4. リファレンス ファイルを参照する

インデックスまたはクエリを推奨する前に、常に適切なリファレンス ファイルを参照してください:

• Lexical: references/lexical-search-indexing.md (インデックス) と references/lexical-search-querying.md (クエリ) の両方を参照する
• Vector: references/vector-search.md を参照する
• Hybrid: references/hybrid-search.md を参照する (そして、その中の個別パイプライン ステージの語彙/ベクトル ファイルも参照)

5. 実行と検証

インデックスを作成する:

1. 平易な言語でインデックス構成を説明する
2. JSON 構造を表示する
3. ユーザーにインデックスの名前を付けたいかを尋ねる
4. 明確な承認を得る: "このインデックスを作成してもよろしいですか?"
5. 承認後、MCP の create-index ツールを使用する
6. 読み取り専用モードでは、Atlas UI を介して作成するための完全なインデックス JSON を提供する

クエリを実行する:

1. 集計パイプラインを表示する
2. MCP の aggregate ツールを使用して実行する
3. 結果を明確に提示する

既存のクエリを改善する:

1. ユーザーに現在のクエリを共有するよう求める
2. 関連するリファレンス ファイル内のクエリ パターンとベスト プラクティスと比較する
3. Before/After の例を含めた具体的な改善を提案する
4. 改訂されたクエリを aggregate で実行して結果を検証する

避けるべきアンチパターン

検索ユースケースに対して $regex または $text を推奨しないでください:

• $regex: 全文検索用に設計されていません。関連性スコアリング、ファジー マッチング、言語対応のトークン化がありません。
• $text: レガシー オペレーターで、検索ワークロードに対してスケーリングが良くありません。

ユーザーが検索ユースケースに対して regex/text を求める場合、Atlas Search がより適切である理由を説明し、同等のパターンを表示してください。

エッジケースの処理

ユーザーが見つからないフィールドについて言及:

• collection-schema を使用して利用可能なフィールドを検査する
• 代替案を提案するか、明確化を求める

必要なフィールドが存在しない:

• 追加する必要があるものと方法を説明する (例: Vector Search のためのエンベディング フィールド)

クエリが失敗するか、インデックスが見つからない:

• collection-indexes を使用してインデックスの存在を確認する
• 見つからない場合、最初にインデックスを作成する必要があることを説明する

複数のコレクションが関連している:

• オプションをリストしアップし、どのコレクションを意図しているかを尋ねる
• コンテキストで明白な場合、仮定を確認する

忘れずに

• 新しいインデックスを推奨する前に、常に既存のインデックスを確認する
• 技術的な概念をアクセス可能な言語で説明する
• インデックスを作成する前に承認を要求する
• ユーザーのビジネス要件を技術実装にマッピングする
• ユースケースに適切な検索タイプを使用する