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 |
Des règles déterministes s'exécutent à chaque fusion et tranchent tout ce que les valeurs des modèles permettent de prouver. Ce pour quoi elles ne peuvent que préférer une réponse — une valeur contredite, un objet imbriqué que les modèles décrivent différemment, un élément produit par un seul modèle — est soumis à un résolveur. Le choix d'un modèle d'arbitrage dans la barre latérale détermine qui est ce résolveur : les règles elles-mêmes ou un LLM.
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 questions que les règles n'ont pas pu trancher sont soumises à ce LLM. Il voit l'identité de l'entité, la description de chaque champ et la valeur de chaque modèle, affichée dans votre langue d'enrichissement principale — et il répond en désignant, jamais en écrivant une valeur de son cru.
Les questions sont posées niveau par niveau : d'abord l'entité elle-même, puis chaque élément de tableau apparié dans son propre appel, avec sa propre identité pour contexte (« Acte I de cet opéra ») — et un élément écarté par l'arbitre n'est plus jamais soumis. La partie commune du prompt est mise en cache par le premier appel : les appels plus profonds s'exécutent donc en parallèle pour une fraction du coût.
Repli : si le modèle d'arbitrage échoue (délai dépassé, erreur), les décisions issues des règles s'appliquent : vous obtenez donc toujours un résultat — et l'enregistrement indique quelle méthode a été employée.
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 s'affiche pour tout enregistrement fusionné sur la page Historique, dans son onglet Vue d'ensemble. Les décisions prises à l'intérieur d'un tableau — un champ d'un élément apparié, un élément conservé ou écarté — y figurent également : ce qui a été laissé de côté est donc aussi visible que ce qui a été retenu. Un enregistrement arbitré par un LLM désigne son arbitre comme modèle ; une fusion fondée sur les règles liste à la place les modèles qu'elle a fusionnés, puisqu'elle n'a effectué aucun appel LLM et ne comporte ni prompt, ni tokens, ni 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.