Lorsque vous exécutez le même enrichissement sur plusieurs modèles d'IA, Entity Enricher peut fusionner les résultats en une sortie unique à haut niveau de confiance. La fusion détecte les conflits entre les sorties des modèles et les résout à l'aide de règles déterministes ou d'un arbitrage assisté par LLM.
Le détecteur de conflits compare chaque champ entre toutes les sorties des modèles. Les champs sur lesquels tous les modèles s'accordent passent tels quels. Les champs sur lesquels les modèles divergent sont signalés comme des conflits à résoudre.
| Type | Méthode de comparaison | Signification de l'accord |
|---|---|---|
| Scalaire | Correspondance exacte normalisée (espaces supprimés, minuscules, arrondi) | Toutes les valeurs sont égales après normalisation |
| Multilingue | La langue principale de l'exécution tranche ; les différences de traduction ne déclenchent qu'une fusion par langue | Même texte dans la langue principale — les variantes de formulation d'une traduction ne sont pas des désaccords |
| Tableau | Comparaison d'ensembles (indépendante de l'ordre) sur la vue en langue principale des éléments | Mêmes éléments quel que soit l'ordre ou la formulation de la traduction |
| Objet | Par propriété tant que les champs d'identité prouvent que les deux modèles décrivent la même chose — sinon, l'objet entier constitue un unique conflit | Toutes les propriétés imbriquées correspondent |
| Nul / vide | Une valeur nulle, une chaîne vide ou un tableau vide constitue une abstention, pas une affirmation | La valeur renseignée l'emporte sans comptabiliser de conflit |
Les conflits sont résolus selon l'une des deux méthodes, selon que vous avez sélectionné ou non un modèle d'arbitrage dans la barre latérale.
Des règles déterministes sont appliquées selon le type de données de chaque champ. Dans la quasi-totalité des cas, aucun appel LLM n'est nécessaire — la résolution est instantanée et gratuite. Seule exception : les nombres sur lesquels les modèles divergent fortement, qu'aucune règle ne peut honnêtement trancher ; voir ci-dessous.
| Type de champ | Règle | Justification |
|---|---|---|
| Chaîne | Vote majoritaire ; en cas d'égalité, la valeur la plus longue l'emporte | Plus de détails, c'est généralement mieux |
| Nombre | Valeur du modèle la plus proche de la médiane | Robuste face aux valeurs aberrantes, jamais de moyenne fabriquée |
| Booléen | Majorité ; en cas d'égalité, true l'emporte | Valeur par défaut prudente |
| Multilingue | Vote majoritaire par langue, union des langues | Chaque langue est résolue indépendamment |
| Tableau | Union sensible aux clés : les éléments sont regroupés sur leurs champs de clé, les variantes orthographiques sont fusionnées, les éléments correspondants sont fusionnés champ par champ | Une ligne par entité logique, sans rien perdre |
| Objet | Par champ lorsque l'identité concorde ; sinon, l'objet d'un seul modèle est repris en bloc | Mélanger deux objets qui décrivent des entités différentes reviendrait à en inventer un troisième qu'aucun modèle n'a renvoyé |
| Null vs valeur | Préférer la valeur renseignée | Une donnée manquante est pire que n'importe quelle valeur |
Départage : en cas d'égalité des votes, la valeur du modèle le plus cher l'emporte (comme indicateur de capacité), puis vient l'ordre alphabétique du nom du modèle. Pour un objet entier pris de façon atomique, la complétude — le nombre de feuilles renseignées — s'intercale entre les deux : faute de preuve indiquant quelle entité est la bonne, on privilégie le modèle le plus puissant, puis la réponse qui apporte le plus d'informations.
Fusionner un objet imbriqué champ par champ n'est sûr que tant que les deux modèles décrivent la même chose. Lorsque les champs d'identité ne le prouvent pas — clés différentes, ou aucune clé avec un véritable désaccord en dessous —, l'objet devient un conflit unique et la version d'un seul modèle est reprise telle quelle. Sinon, la fusion assemblerait une chimère : l'adresse de ce modèle sur l'entreprise de cet autre. Une conséquence est délibérée mais bonne à connaître : le gagnant est repris avec ses vides, donc un champ que le gagnant a laissé vide reste vide — ce qui peut bloquer l'entité au moment de son admission en base. La raison est indiquée dans les avertissements de validation de l'exécution.
« Le plus proche de la médiane » convient à des modèles qui arrondissent différemment, mais pas à des modèles qui se contredisent — 0 contre 1854 n'est pas une différence d'arrondi. Lorsque l'écart relatif entre les valeurs atteint 20 %, le champ est escaladé vers un arbitre LLM choisi automatiquement selon la sélection de modèles habituelle de votre organisation, et l'appel est facturé comme n'importe quel autre. Ces champs sont signalés comme escaladés automatiquement dans le journal d'audit de la fusion : une fusion qui a consommé des tokens indique donc toujours quels champs en sont la cause.
Lorsque vous sélectionnez un modèle d'arbitrage dans la barre latérale, les conflits sont envoyés à un LLM pour une résolution intelligente. L'arbitre reçoit le contexte de l'entité, les descriptions des champs du schéma et toutes les valeurs en conflit, puis prend des décisions motivées.
Repli : si le modèle d'arbitrage échoue (délai dépassé, erreur), le système bascule automatiquement vers la fusion basée sur des règles afin que vous obteniez toujours un résultat.
Après la résolution des conflits, le système construit un résultat fusionné unique et le stocke comme enregistrement d'« arbitrage » dans la base de données. Chaque résultat fusionné inclut une piste d'audit qui vous permet de retracer comment chaque conflit a été résolu.
Chaque résultat fusionné inclut des métadonnées qui documentent le processus de fusion :
Le même journal d'audit est affiché pour tout enregistrement fusionné sur la page Historique, dans son onglet Vue d'ensemble. Un enregistrement fusionné répertorie les modèles qu'il a fusionnés plutôt qu'un modèle qui lui est propre — et lorsque la fusion était basée sur des règles, elle n'a effectué aucun appel LLM, elle ne comporte donc aucun prompt, aucun token ni aucun coût.
Une fois la fusion terminée, l'onglet « Fusionné » du panneau de résultats affiche :
Dans l'enrichissement en traitement par lot, la fusion se produit automatiquement dès que vous sélectionnez deux modèles ou plus. Vous n'avez pas besoin de cliquer manuellement sur « Fusionner les résultats » : dès que tous les modèles ont réussi pour une entité, la fusion s'exécute et le résultat fusionné apparaît à côté des sorties de chaque modèle. Une exécution dans laquelle un modèle a échoué n'est délibérément pas fusionnée : fusionner ce qu'il en reste publierait silencieusement une réponse partielle comme s'il s'agissait de la réponse convenue. Récupérez d'abord le modèle manquant — relancer ses expertises en échec fusionne automatiquement l'exécution une fois celle-ci de nouveau complète.
fusion_started, conflicts_detected et fusion_completed en temps réel.