Synthèse des Connaissances

Le dernier kilomètre de la recherche en entreprise. Transforme les résultats bruts de multiples sources en une réponse cohérente et fiable.

L'Objectif

Transformer ceci :

~~résultat chat : "Sarah a dit dans #eng : 'allons-y avec REST, GraphQL est excessif pour notre cas d'usage'"
~~résultat email : "Objet : Décision API — email de Sarah confirmant l'approche REST avec justification"
~~résultat stockage cloud : "API Design Doc v3 — section 2 mise à jour pour refléter la décision REST"
~~résultat suivi de projet : "Tâche : Finaliser l'approche API — marquée terminée par Sarah"

En ceci :

L'équipe a décidé d'opter pour REST plutôt que GraphQL pour la refonte de l'API. Sarah a pris la décision, notant que GraphQL était excessif pour le cas d'usage actuel. Cela a été discuté dans #engineering mardi, confirmé par email mercredi, et le document de conception a été mis à jour pour refléter la décision. La tâche de suivi de projet associée est marquée comme terminée.

Sources :
- ~~chat : discussion #engineering (14 jan)
- ~~email : "API Decision" de Sarah (15 jan)
- ~~stockage cloud : "API Design Doc v3" (mise à jour 15 jan)
- ~~suivi de projet : "Finalize API approach" (terminée 15 jan)

Déduplication

Déduplication Inter-Sources

La même information apparaît souvent à plusieurs endroits. Identifiez et fusionnez les doublons :

Signaux indiquant que les résultats traitent du même sujet :

• Contenu textuel identique ou très similaire
• Même auteur/expéditeur
• Horodatages rapprochés (même jour ou jours adjacents)
• Références à la même entité (nom de projet, document, décision)
• Une source référence une autre (« comme discuté dans ~~chat », « selon l'email », « voir le doc »)

Comment fusionner :

• Combinez en un seul élément narratif
• Citez toutes les sources où elle a figuré
• Utilisez la version la plus complète comme texte principal
• Ajoutez les détails uniques de chaque source

Priorité de Déduplication

Quand la même information existe dans plusieurs sources, préférez :

1. La version la plus complète (contexte le plus riche)
2. La source la plus autoritaire (doc officielle > chat)
3. La version la plus récente (la dernière mise à jour gagne pour l'info évolutive)

Ce qu'il NE PAS Faut Dédupliquer

Gardez comme éléments séparés quand :

• Le même sujet est discuté mais avec des conclusions différentes
• Différentes personnes expriment des points de vue différents
• L'information a évolué significativement entre les sources (v1 vs v2 d'une décision)
• Des périodes temporelles différentes sont représentées

Citation et Attribution des Sources

Chaque affirmation dans la réponse synthétisée doit être attribuable à une source.

Format d'Attribution

En ligne pour les références directes :

Sarah a confirmé l'approche REST dans son email mercredi.
Le document de conception a été mis à jour pour refléter ceci (~~stockage cloud : "API Design Doc v3").

Liste des sources à la fin pour la complétude :

Sources :
- ~~chat : discussion #engineering (14 jan) — fil de décision initial
- ~~email : "API Decision" de Sarah Chen (15 jan) — confirmation formelle
- ~~stockage cloud : "API Design Doc v3" dernière modification 15 jan — spécification mise à jour

Règles d'Attribution

• Nommez toujours le type de source (~~chat, ~~email, ~~stockage cloud, etc.)
• Incluez l'emplacement spécifique (canal, dossier, fil)
• Incluez la date ou le délai relatif
• Incluez l'auteur quand pertinent
• Incluez les titres de document/fil quand disponibles
• Pour ~~chat, notez le nom du canal
• Pour ~~email, notez la ligne d'objet et l'expéditeur
• Pour ~~stockage cloud, notez le titre du document

Niveaux de Confiance

Tous les résultats ne sont pas également fiables. Évaluez la confiance selon :

Fraîcheur

Pour les requêtes de statut, pondérez fortement la fraîcheur. Pour les requêtes de politique/faits, la fraîcheur importe moins.

Autorité

Exprimer la Confiance

Quand la confiance est élevée (plusieurs sources fraîches et autoritaires concordent) :

L'équipe a décidé d'utiliser REST pour la refonte de l'API. [déclaration directe]

Quand la confiance est modérée (source unique ou quelque peu datée) :

D'après la discussion dans #engineering le mois dernier, l'équipe penchait pour
REST pour la refonte de l'API. Cela a peut-être évolué depuis.

Quand la confiance est basse (données anciennes, source informelle, ou signaux contradictoires) :

J'ai trouvé une référence à une discussion de migration d'API d'il y a trois mois
dans ~~chat, mais je n'ai pas trouvé de document de décision formel. L'information
peut être obsolète. Vous devriez vérifier auprès de l'équipe pour le statut actuel.

Informations Conflictuelles

Quand les sources sont en désaccord :

J'ai trouvé des informations conflictuelles sur l'approche API :
- La discussion ~~chat du 10 jan suggérait GraphQL
- Mais l'email de Sarah du 15 jan a confirmé REST
- Le document de conception (mis à jour 15 jan) reflète REST

Les sources les plus récentes indiquent que REST était la décision finale,
mais la discussion ~~chat antérieure a d'abord exploré GraphQL.

Surfacez toujours les conflits plutôt que de choisir silencieusement une version.

Stratégies de Résumé

Pour Petits Ensembles de Résultats (1-5 résultats)

Présentez chaque résultat avec contexte. Aucun résumé nécessaire — donnez tout à l'utilisateur :

[Réponse directe synthétisée des résultats]

[Détail de la source 1]
[Détail de la source 2]

Sources : [attribution complète]

Pour Ensembles de Résultats Moyens (5-15 résultats)

Groupez par thème et résumez chaque groupe :

[Réponse globale]

Thème 1 : [résumé des résultats connexes]
Thème 2 : [résumé des résultats connexes]

Sources clés : [3-5 sources les plus pertinentes]
Résultats complets : [nombre] éléments trouvés dans [sources]

Pour Grands Ensembles de Résultats (15+ résultats)

Fournissez une synthèse haut niveau avec option pour creuser :

[Réponse globale basée sur les résultats les plus pertinents]

Résumé :
- [Constatation clé 1] (soutenue par N sources)
- [Constatation clé 2] (soutenue par N sources)
- [Constatation clé 3] (soutenue par N sources)

Sources principales :
- [Source la plus autoritaire/pertinente]
- [Deuxième source la plus pertinente]
- [Troisième source la plus pertinente]

Trouvé [nombre total] résultats dans [liste des sources].
Voulez-vous que j'approfondisse un aspect spécifique ?

Règles de Résumé

• Commencez par la réponse, pas par le processus de recherche
• N'énumérez pas les résultats bruts — synthétisez-les en narratif
• Groupez les éléments connexes de différentes sources ensemble
• Préservez les nuances et mises en garde importantes
• Incluez suffisamment de détails pour que l'utilisateur décide d'approfondir
• Proposez toujours plus de détails si l'ensemble de résultats était grand

Flux de Travail de Synthèse

[Résultats bruts de toutes les sources]
          ↓
[1. Dédupliquer — fusionner les mêmes infos de différentes sources]
          ↓
[2. Grouper — classer les résultats connexes par thème/sujet]
          ↓
[3. Classer — ordonner les groupes et éléments par pertinence par rapport à la requête]
          ↓
[4. Évaluer la confiance — fraîcheur × autorité × concordance]
          ↓
[5. Synthétiser — produire une réponse narrative avec attribution]
          ↓
[6. Formater — choisir le niveau de détail approprié pour le nombre de résultats]
          ↓
[Réponse cohérente avec sources]

Anti-Modèles

Ne pas :

• Énumérer les résultats source par source (« De ~~chat : ... De ~~email : ... De ~~stockage cloud : ... »)
• Inclure les résultats non pertinents juste parce qu'ils correspondent à un mot-clé
• Enterrer la réponse sous l'explication de la méthodologie
• Présenter les infos conflictuelles sans signaler le conflit
• Omettre l'attribution des sources
• Présenter l'information incertaine avec la même confiance que les faits bien étayés
• Résumer si agressivement que les détails utiles sont perdus

Faire :

• Commencer par la réponse
• Grouper par sujet, pas par source
• Signaler les niveaux de confiance quand approprié
• Surfacer les conflits explicitement
• Attribuer toutes les affirmations aux sources
• Proposer d'approfondir quand les ensembles de résultats sont grands