Une présentation pas à pas du traitement d'une entité par Entity Enricher — de l'entrée à la sortie structurée, en passant par la classification et l'exécution parallèle des modèles.
Ouvrez la page Éditeur de workflow et configurez votre enrichissement. Un assistant par étapes vous guide à travers les phases du pipeline : Données d'exemple, Schéma, Enrichissement et Résultats — plus une étape Base de données prête lorsque le schéma est lié à une database sync, confirmant que les modifications de l'exécution ont été mises en file d'attente pour votre base de données (ou expliquant pourquoi l'enregistrement a été refusé).
Collez un exemple JSON pour générer automatiquement un schéma, puis explorez l'arborescence interactive des propriétés. Modifiez les propriétés, ajoutez des domaines d'expertise et marquez les champs comme clés de recherche ou préservés.
Configurez les options d'enrichissement (stratégie, modèles, langues, classification, ainsi que le schéma de réponse et les options de sortie structurée stricte) et renseignez les clés de recherche de l'entité (nom, site web, pays, etc.) pour identifier l'entité.
Affiche la progression et les résultats en temps réel pour chaque modèle. Lors de l'utilisation de plusieurs modèles, un bouton « Fusionner les résultats » apparaît pour la fusion.
Certaines requêtes ne peuvent tout simplement pas produire de résultat exploitable, et le moment le moins coûteux pour s'en rendre compte est avant le premier appel LLM. Deux contrats sont vérifiés en amont.
Un schéma énonce ce que son entrée doit contenir : les champs clés qui indiquent de quelle entité il s'agit, une clé sur chaque élément d'un tableau que vous fournissez, et une valeur pour chaque champ marqué preserve (rien ne peut être préservé qui n'ait jamais été fourni). Une requête à laquelle il en manque une partie est refusée par une erreur unique qui liste toutes les violations d'un coup — accompagnée du contrat complet du schéma, pour que vous corrigiez en une seule passe au lieu de découvrir les exigences un refus après l'autre. Le contrat est publié sur chaque schéma enregistré, afin qu'un client puisse vérifier avant d'envoyer.
Un tableau dont vous fournissez les éléments est enrichi à l'identique : le modèle complète ce qu'il sait de chaque élément, sans pouvoir en ajouter ni en retirer. Vous avez envoyé cinq lignes, vous en récupérez cinq. Un élément que le modèle n'a pas repris est réinséré tel quel plutôt que perdu, et un élément qu'il a inventé est écarté. Les tableaux que vous laissez vides restent ouverts — c'est là que le modèle découvre des faits, et c'est bien l'objectif.
Si vous avez sélectionné un modèle de classification, un appel LLM rapide et peu coûteux s'exécute d'abord pour vérifier que l'entité correspond au type du schéma. Cela évite de gaspiller des tokens en enrichissement lorsque l'entité ne correspond pas. En savoir plus dans la documentation sur la classification.
Chaque modèle sélectionné traite l'entité selon la stratégie que vous avez indiquée — ou, par défaut, celle choisie automatiquement d'après la structure de votre schéma, que l'exécution annonce à son démarrage. Lorsque plusieurs modèles sont sélectionnés, ils s'exécutent en parallèle entre fournisseurs (Claude et GPT-4 tournent simultanément), tandis que les modèles d'un même fournisseur s'exécutent séquentiellement pour respecter les limites de débit.
Chaque réponse du LLM est validée en temps réel par rapport à votre schéma. Lorsque la sortie ne correspond pas aux types ou contraintes attendus, le système renvoie automatiquement les erreurs au LLM pour correction.
Jusqu'à 5 nouvelles tentatives automatiques par appel LLM. Chaque tentative inclut l'erreur de validation précise afin que le LLM sache exactement quoi corriger — et la réparation est chirurgicale : seules les feuilles erronées sont redemandées, pas la réponse entière.
Notez ce qui ne figure pas dans cette liste : une valeur que le modèle n'a pas pu déterminer n'est pas une erreur à réessayer. Chaque champ peut revenir absent, et le modèle déclare ce qu'il n'a pas trouvé : « inconnu » est donc une réponse, pas un échec. Le caractère acceptable d'une valeur manquante est tranché plus tard, à l'admission de l'entité dans votre base — pas en forçant le modèle à deviner.
Deux options facultatives demandent au provider de contraindre la sortie avant qu'elle ne soit renvoyée, afin de réduire le nombre de réponses à corriger. Les deux ne s'appliquent qu'aux modèles qui les prennent en charge ; tout le reste repose sur la boucle de validation et de nouvelle tentative décrite ci-dessus.
Entity Enricher utilise les Server-Sent Events (SSE) pour diffuser la progression en temps réel. Vous n'avez pas à attendre que tous les modèles aient terminé — les résultats apparaissent progressivement à mesure que chaque domaine d'expertise ou modèle se termine.
Chaque modèle dispose de son propre panneau de résultats affichant la sortie JSON structurée, les badges de progression par expertise, l'utilisation de tokens, le coût et le temps de traitement. Avec la stratégie multi-expertise, les badges d'expertise se mettent à jour en temps réel à mesure que chaque domaine se termine.
Avec la stratégie multi-expertise, certaines expertises peuvent échouer tandis que d'autres réussissent. Plutôt que de tout rejeter, Entity Enricher renvoie la sortie fusionnée des expertises réussies avec le statut « Partiel ». Vous pouvez ensuite relancer uniquement les expertises en échec sans réexécuter tout l'enrichissement.
Une fois l'enrichissement terminé, vos résultats sont enregistrés sur la page Historique pour référence ultérieure. Si vous avez utilisé plusieurs modèles, vous pouvez fusionner les résultats à l'aide de Multi-Model Fusion.