Gérez les fournisseurs et modèles LLM, synchronisez les modèles depuis des registres externes, exécutez des contrôles de santé et configurez des clés API par organisation pour une facturation indépendante.
Entity Enricher prend en charge un large éventail de fournisseurs LLM. Chaque fournisseur peut proposer plusieurs modèles avec une tarification, des capacités et une configuration individuelles.
De nombreuses équipes font transiter leur trafic LLM par une passerelle IA d'entreprise, un point de terminaison régional ou un fournisseur non intégré — par exemple un proxy LiteLLM d'entreprise, Cloudflare AI Gateway ou Alibaba DashScope (pour les modèles Qwen). Vous les ajoutez en tant que fournisseur Standard (compatible OpenAI) distinct avec une URL de base personnalisée.
acme-openai-gw). Les noms intégrés comme openai ou anthropic sont réservés. https://gateway.example.com/v1. Ce champ est obligatoire pour tout fournisseur pour lequel Entity Enricher ne dispose pas de client intégré. https://. Les adresses de bouclage et les plages privées (localhost, 10.x, 192.168.x) sont rejetées pour prévenir les attaques SSRF — un serveur auto-hébergé doit être accessible depuis Internet. Pour un Ollama local, utilisez plutôt le tunnel Ollama dédié./v1 (chat completions, /models). {endpoint}/models pour vérifier la clé et l'URL de base avant de lancer un enrichissement.Chaque appel effectué avec une clé API est cadencé selon le budget que le fournisseur accorde à cette clé — requêtes et jetons par minute, par modèle — afin qu'une rafale d'appels parallèles ne provoque jamais d'erreurs 429. Ce budget n'est pas saisi à la main : il est lu dans les en-têtes de réponse du fournisseur, appris à la suite d'un rejet lorsque le fournisseur n'annonce rien, ou, en dernier recours, saisi par un propriétaire.
Ceci est distinct de la limite de tâches simultanées maximum de votre forfait, qui plafonne le nombre de tâches d'enrichissement exécutées à la fois par l'ensemble de votre organisation, tous fournisseurs confondus.
Chaque modèle suit ses capacités, affichées sous forme d'icônes dans le sélecteur de modèles :
| Capacité | Description |
|---|---|
| Vision | Peut traiter des images et des entrées visuelles |
| Appels d'outils | Prend en charge l'appel de fonctions / l'utilisation d'outils |
| Entrée audio | Peut traiter des entrées audio |
| Entrée PDF | Peut traiter des documents PDF |
| Mise en cache des prompts | Prend en charge la mise en cache des prompts pour réduire les coûts |
| Raisonnement | Capacités de réflexion étendue / chaîne de pensée |
| Embeddings | Transforme le texte en vecteur au lieu de répondre — c'est ce avec quoi les ID sémantiques sont résolus. Les modèles d'embedding forment leur propre famille, avec leur propre taille de vecteur, et n'apparaissent jamais dans un sélecteur d'enrichissement |
Indiquer un modèle est facultatif. L'enrichissement, la génération de schéma et la génération d'exemples acceptent tous auto — et traitent un modèle omis comme auto —, valeur résolue sur le serveur, par tâche, au démarrage du job. L'exécution indique quel modèle a été retenu : automatique ne veut jamais dire opaque.
Les propriétaires peuvent fixer un modèle préféré par tâche dans Paramètres → Organisation → Sélection du modèle. Si un modèle est défini pour la tâche en cours, c'est lui qui prévaut.
À défaut d'épinglage, le choix se porte sur le modèle au meilleur score combiné issu de vos benchmarks de source de scoring — vos propres mesures de qualité, de vitesse et de coût sur vos propres schémas. En l'absence totale de source de scoring, la requête est refusée plutôt que devinée.
Activer la recherche web, ou joindre un document qui doit être transmis tel quel, restreint les candidats aux modèles qui en sont réellement capables — et si aucun ne convient, vous obtenez une erreur explicite plutôt qu'une dégradation silencieuse.
Un modèle peut aussi être écarté d'une seule tâche sans être désactivé : un modèle qui enrichit bien mais génère de mauvais schémas peut être masqué uniquement dans les sélecteurs de génération de schémas et d'échantillons, pour votre organisation ou globalement par un administrateur. Il reste pleinement disponible partout ailleurs — un instrument plus souple que la désactivation ci-dessous.
Maintenez les tarifs des modèles à jour en les synchronisant depuis des registres externes. Le processus de synchronisation détecte automatiquement les nouveaux modèles, les changements de prix et les modèles supprimés.
La source de tarification par défaut. Récupère les données depuis le registre communautaire de LiteLLM sur GitHub, avec les vrais noms de modèles API, les tarifs, les longueurs de contexte et les capacités.
Couvre ~30 fournisseurs. N'inclut pas les noms d'affichage, les benchmarks ni la vitesse de génération.
Une source alternative provenant de pricepertoken.com. Inclut les noms d'affichage, les benchmarks (scores en programmation et en mathématiques) et la vitesse de génération (tokens par seconde).
Couvre ~20 fournisseurs. Fournit des métadonnées plus riches que LiteLLM.
Un catalogue officiel et authentifié des identifiants de modèles GLM, avec des tarifs extraits directement de la documentation Z.AI et les lacunes de capacités qui y ont été étudiées.
Remplace les entrées Z.AI précédemment importées depuis LiteLLM et PricePerToken.
Validez proactivement l'accessibilité des modèles en exécutant un prompt minimal de vérification d'état. Cela permet de détecter les modèles défaillants avant que les utilisateurs ne rencontrent des erreurs lors de l'enrichissement.
Les vérifications d'état peuvent être exécutées sur tous les modèles, sur les modèles d'un fournisseur spécifique ou sur un seul modèle. Les résultats sont diffusés en temps réel via SSE, avec une barre de progression affichant le nombre de réussites et d'échecs.
Lorsqu'un appel d'enrichissement échoue avec une erreur « modèle introuvable », le modèle est automatiquement désactivé pour éviter des échecs répétés. Cela se produit en temps réel pendant les opérations d'enrichissement normales.
| Motif de désactivation | Défini par | Réactivé automatiquement ? |
|---|---|---|
| Modèle introuvable | Erreurs d'enrichissement, contrôles de santé, ou une sonde de capacités à laquelle aucune route ne répond | Oui (par synchronisation des tarifs ou validation) |
| Aucune sortie structurée | Sonde de capacités : ni le canal outil ni le canal natif sur aucune route joignable | Oui, uniquement via une sonde de capacités ultérieure |
| Supprimés à la synchronisation | Synchronisation des tarifs (modèle disparu) | Oui (si le modèle réapparaît dans le registre) |
| Manuel | Bascule administrateur dans l'interface | Non (réactivation manuelle uniquement) |
Les organisations peuvent configurer leurs propres clés API de fournisseur LLM pour une facturation et un suivi d'utilisation indépendants. Le système utilise une résolution de clés à deux niveaux avec sélection LRU :
Clés par organisation configurées dans la page Clés API. Prend en charge plusieurs clés par fournisseur avec rotation LRU. Chiffrées avec Fernet.
Clés à l'échelle du système gérées par les administrateurs. Partagées entre toutes les organisations. Prend également en charge plusieurs clés par fournisseur avec rotation LRU.
Chaque enrichissement indique la clé utilisée, ce qui vous permet de suivre les coûts par clé. Les clés prennent en charge les contrôles d'état et les compteurs d'utilisation. Au sein d'un pool, la clé retenue ensuite est la clé activée dont la dernière utilisation est la plus ancienne ; une clé ne quitte la rotation que si vous la désactivez manuellement, si bien qu'une erreur de fournisseur ne retire jamais silencieusement une clé du service. Découvrez comment gérer les clés dans le guide API Keys.
Exportez l'ensemble de votre configuration de fournisseurs et de modèles au format JSON pour une sauvegarde ou un transfert vers une autre instance. L'import est toujours un upsert : les fournisseurs et modèles existants sont identifiés par leur nom et mis à jour sur place, tandis que les nouveaux sont ajoutés — rien n'est supprimé.
L'export inclut les paramètres des fournisseurs, les configurations de modèles, la tarification, les capacités et les spécifications canoniques des modèles — mais jamais les clés API, qui sont stockées séparément. Après l'import, configurez les clés API séparément. Les administrateurs système sauvegardent l'intégralité du catalogue global ; les propriétaires d'organisation exportent et importent uniquement les fournisseurs et modèles de leur propre organisation — le catalogue global partagé ne peut être ni créé ni modifié via l'import.
La page des modèles présente le catalogue global à tous : les tarifs des fournisseurs, les capacités mesurées et les scores obtenus par chaque modèle sur les scénarios de benchmark publiés comme sources de scoring globales. Elle lit deux fichiers JSON statiques que l'actualisation nocturne des modèles réécrit, et que vous pouvez télécharger et réutiliser. Un modèle que le fournisseur ne propose plus (désactivé en « model not found ») est exclu ; tous les autres modèles du catalogue sont listés.
/data/models.json — le tableau : une entrée par fournisseur × modèle, avec des tables de correspondance pour les fournisseurs, les scénarios et les spécifications./data/benchmarks.json — tous les résultats de benchmark publics, regroupés par clé de modèle.Les deux sont servis avec un ETag et un cache public d'une heure, encodés en gzip si le client l'accepte. Le champ version est incrémenté à chaque changement auquel un consommateur devrait s'adapter.
generated_at, counts, default_weightsLa date d'écriture du fichier, le nombre de modèles, de fournisseurs et de scénarios qu'il contient, et la pondération qualité / vitesse / coût (en pourcentage) derrière chaque score global.providers[], scenarios[], specs{}Tables de correspondance : les modèles référencent un fournisseur et les scénarios par index ; les specs sont les scores de benchmark publics des poids (intelligence, code, maths, et le reste sous extra), indexés par clé canonique afin que les revendeurs d'un même modèle les partagent.models[].key, model, display_name, canonical_keyLa clé composite acceptée par l'API (provider::model), l'id brut du modèle, son libellé et l'identité inter-fournisseurs.models[].pricingTarifs publics du fournisseur en USD par million de tokens : input, output, cache_read, cache_write, cache_write_1h, reasoning_output, plus web_search_per_query avec son unité. Avant toute commission du forfait.models[].capabilities[]Les indicateurs actifs : vision, pdf_input, audio_input, audio_output, video_input, tool_calls, tool_choice, response_schema, strict_structured_output, reasoning, reasoning_effort, web_search, prompt_caching, embeddings, requires_streaming. Un indicateur absent est faux ou non mesuré.models[].context_length, max_input_tokens, max_output_tokens, deprecation_date, latencyLimites, date de retrait annoncée par l'éditeur le cas échéant, et mesures de latence collectées (tokens par seconde, temps jusqu'au premier token).models[].enrichment_capable, disabled_tasks[]Si le modèle dispose d'un canal de sortie structurée, et les tâches pour lesquelles l'application ne le propose jamais (la classification et l'arbitrage nécessitent des appels d'outils ; la génération de schémas et d'échantillons suit le verrou de génération de schémas).models[].scores{task}Par type de tâche (enrichment, schema_generation, sample_generation) : la qualité, la vitesse et le coût moyens sur les scénarios publics de cette tâche, le score global selon les pondérations par défaut, et les index des scénarios. La vitesse et le coût sont relatifs aux autres modèles sur le même scénario.Le calcul des scores de qualité, de vitesse et de coût est expliqué dans Notation des benchmarks.