search-strategy

Par anthropics · knowledge-work-plugins

Décomposition de requêtes et orchestration de recherche multi-sources. Découpe les questions en langage naturel en recherches ciblées par source, traduit les requêtes en syntaxe propre à chaque source, classe les résultats par pertinence et gère l'ambiguïté ainsi que les stratégies de repli.

npx skills add https://github.com/anthropics/knowledge-work-plugins --skill search-strategy

Stratégie de Recherche

Si vous rencontrez des placeholders unfamiliers ou avez besoin de vérifier quels outils sont connectés, voir CONNECTORS.md.

L'intelligence centrale derrière la recherche d'entreprise. Transforme une seule question en langage naturel en recherches parallèles et spécifiques à chaque source, et produit des résultats classés et dédupliqués.

L'Objectif

Transformer ceci :

"What did we decide about the API migration timeline?"

En recherches ciblées sur chaque source connectée :

~~chat:  "API migration timeline decision" (semantic) + "API migration" in:#engineering after:2025-01-01
~~knowledge base: semantic search "API migration timeline decision"
~~project tracker:  text search "API migration" in relevant workspace

Puis synthétiser les résultats en une réponse cohérente et unique.

Décomposition de la Requête

Étape 1 : Identifier le Type de Requête

Classer la question de l'utilisateur pour déterminer la stratégie de recherche :

Type de Requête Exemple Stratégie
Décision "What did we decide about X?" Prioriser les conversations (~~chat, email), chercher les signaux de conclusion
Statut "What's the status of Project Y?" Prioriser l'activité récente, les trackers de tâches, les mises à jour de statut
Document "Where's the spec for Z?" Prioriser Drive, wiki, docs partagés
Personne "Who's working on X?" Chercher les assignations de tâches, auteurs de messages, collaborateurs de docs
Factuel "What's our policy on X?" Prioriser wiki, docs officiels, puis conversations de confirmation
Temporel "When did X happen?" Chercher avec une plage de dates large, chercher les timestamps
Exploratoire "What do we know about X?" Recherche large sur toutes les sources, synthétiser

Étape 2 : Extraire les Composants de Recherche

À partir de la requête, extraire :

  • Mots-clés : Termes essentiels qui doivent apparaître dans les résultats
  • Entités : Personnes, projets, équipes, outils (utiliser le système de mémoire si disponible)
  • Signaux d'intention : Mots de décision, mots de statut, marqueurs temporels
  • Contraintes : Plages de temps, indices de source, filtres d'auteur
  • Négations : Éléments à exclure

Étape 3 : Générer des Sous-Requêtes par Source

Pour chaque source disponible, créer une ou plusieurs requêtes ciblées :

Préférer la recherche sémantique pour :

  • Les questions conceptuelles ("What do we think about...")
  • Les questions où les mots-clés exacts sont inconnus
  • Les requêtes exploratoires

Préférer la recherche par mot-clé pour :

  • Les termes connus, noms de projets, acronymes
  • Les phrases exactes citées par l'utilisateur
  • Les requêtes avec beaucoup de filtres (from:, in:, after:)

Générer plusieurs variantes de requête quand le sujet peut être désigné différemment :

User: "Kubernetes setup"
Queries: "Kubernetes", "k8s", "cluster", "container orchestration"

Traduction des Requêtes Spécifique à Chaque Source

~~chat

Recherche sémantique (questions en langage naturel) :

query: "What is the status of project aurora?"

Recherche par mot-clé :

query: "project aurora status update"
query: "aurora in:#engineering after:2025-01-15"
query: "from:<@UserID> aurora"

Mappage des filtres : | Filtre Enterprise | Syntaxe ~~chat | |------------------|--------------| | from:sarah | from:sarah or from:<@USERID> | | in:engineering | in:engineering | | after:2025-01-01 | after:2025-01-01 | | before:2025-02-01 | before:2025-02-01 | | type:thread | is:thread | | type:file | has:file |

~~knowledge base (Wiki)

Recherche sémantique — Utiliser pour les requêtes conceptuelles :

descriptive_query: "API migration timeline and decision rationale"

Recherche par mot-clé — Utiliser pour les termes exacts :

query: "API migration"
query: "\"API migration timeline\""  (exact phrase)

~~project tracker

Recherche de tâches :

text: "API migration"
workspace: [workspace_id]
completed: false  (for status queries)
assignee_any: "me"  (for "my tasks" queries)

Mappage des filtres : | Filtre Enterprise | Paramètre ~~project tracker | |------------------|----------------| | from:sarah | assignee_any or created_by_any | | after:2025-01-01 | modified_on_after: "2025-01-01" | | type:milestone | resource_subtype: "milestone" |

Classement des Résultats

Notation de Pertinence

Évaluer chaque résultat sur ces facteurs (pondérés selon le type de requête) :

Facteur Poids (Décision) Poids (Statut) Poids (Document) Poids (Factuel)
Correspondance de mots-clés 0,3 0,2 0,4 0,3
Fraîcheur 0,3 0,4 0,2 0,1
Autorité 0,2 0,1 0,3 0,4
Complétude 0,2 0,3 0,1 0,2

Hiérarchie d'Autorité

Dépend du type de requête :

Pour les questions factuelles/politiques :

Wiki/Docs officiels > Documents partagés > Annonces email > Messages chat

Pour les questions "que s'est-il passé" / décisions :

Notes de réunion > Conclusions de fil > Confirmations email > Messages chat

Pour les questions de statut :

Tracker de tâches > Chat récent > Docs de statut > Mises à jour email

Gestion de l'Ambiguïté

Quand une requête est ambiguë, préférer poser une question de clarification ciblée plutôt que de deviner :

Ambiguë : "search for the migration"
→ "I found references to a few migrations. Are you looking for:
   1. The database migration (Project Phoenix)
   2. The cloud migration (AWS → GCP)
   3. The email migration (Exchange → O365)"

Demander une clarification seulement si :

  • Il existe véritablement des interprétations distinctes produisant des résultats très différents
  • L'ambiguïté affecterait significativement quelles sources chercher

Ne PAS demander de clarification si :

  • La requête est suffisamment claire pour produire des résultats utiles
  • L'ambiguïté mineure peut être résolue en retournant des résultats de plusieurs interprétations

Stratégies de Secours

Quand une source est indisponible ou ne retourne aucun résultat :

  1. Source indisponible : L'ignorer, chercher les sources restantes, noter le manque
  2. Aucun résultat d'une source : Essayer des termes plus larges, supprimer les filtres de date, essayer des mots-clés alternatifs
  3. Toutes les sources ne retournent rien : Suggérer des modifications de requête à l'utilisateur
  4. Limite de débit atteinte : Noter la limitation, retourner les résultats des autres sources, suggérer de réessayer plus tard

Élargissement de la Requête

Si les requêtes initiales retournent trop peu de résultats :

Originale : "PostgreSQL migration Q2 timeline decision"
Plus large :  "PostgreSQL migration"
Plus large :  "database migration"
Plus large : "migration"

Supprimer les contraintes dans cet ordre :

  1. Filtres de date (chercher tout le temps)
  2. Filtres de source/localisation
  3. Mots-clés moins importants
  4. Garder seulement les termes d'entité/sujet essentiels

Exécution Parallèle

Toujours exécuter les recherches sur les sources en parallèle, jamais séquentiellement. Le temps total de recherche doit être approximativement égal à la source la plus lente, pas la somme de toutes les sources.

[User query]
     ↓ decompose
[~~chat query] [~~email query] [~~cloud storage query] [Wiki query] [~~project tracker query]
     ↓            ↓            ↓              ↓            ↓
  (parallel execution)
     ↓
[Merge + Rank + Deduplicate]
     ↓
[Synthesized answer]

Skills similaires