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 :
- Source indisponible : L'ignorer, chercher les sources restantes, noter le manque
- Aucun résultat d'une source : Essayer des termes plus larges, supprimer les filtres de date, essayer des mots-clés alternatifs
- Toutes les sources ne retournent rien : Suggérer des modifications de requête à l'utilisateur
- 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 :
- Filtres de date (chercher tout le temps)
- Filtres de source/localisation
- Mots-clés moins importants
- 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]