Avec l'enrichissement par LLM, la facture, ce sont les tokens. Entity Enricher est conçu pour envoyer le moins de tokens facturés possible sans sacrifier la précision — porté avant tout par la mise en cache des prompts, et complété par le cadrage des schémas, un filtrage intelligent et moins de tentatives inutiles. La majeure partie se fait automatiquement ; rien ici ne nécessite de configuration supplémentaire.
Chaque appel d'enrichissement paie des tokens d'entrée (votre prompt, le schéma et les documents joints), des tokens de sortie (le résultat structuré) et — si elles sont activées — des requêtes de recherche web. La part la plus volumineuse et la plus répétitive est généralement l'entrée : les mêmes instructions système, la même description de schéma et les mêmes documents sources sont renvoyés à chaque appel. Mettre en cache cette entrée partagée est le levier le plus puissant, c'est pourquoi il vient en premier.
Prompt + schéma + pièces jointes. Volumineux et très répétitif d'un appel à l'autre — la cible idéale pour la mise en cache et la limitation de portée.
Le résultat structuré. Reste léger, car chaque modèle ne reçoit que les champs dont il est réellement responsable.
Tentatives échouées, saturation des limites de débit et enrichissement de la mauvaise entité. Éliminés d'emblée plutôt que facturés.
Lorsqu'un enrichissement multi-expertises s'exécute, il effectue plusieurs appels LLM pour la même entité — un par domaine d'expertise. Chacun de ces appels partage le même contexte d'ouverture : les instructions système génériques et les documents en texte intégré que vous avez joints. Entity Enricher conserve ce préfixe partagé identique octet par octet d'un appel à l'autre et le marque comme pouvant être mis en cache, de sorte que le fournisseur le stocke une seule fois et le relit à chaque appel suivant pour environ un dixième du prix d'entrée normal.
Chacun des N appels renvoie l'intégralité du contexte partagé au plein tarif d'entrée. Cinq expertises signifient payer cinq fois ce gros bloc partagé.
Le bloc partagé est écrit une seule fois dans le cache, puis relu lors des quatre autres appels à environ 10 % du prix d'entrée. Les économies augmentent avec chaque domaine d'expertise, langue et document joint supplémentaires.
Les caches des fournisseurs ne sont lisibles qu'après la fin de la première requête qui les écrit. Si tous les appels d'expertise partaient en même temps, aucun ne trouverait de cache chaud et chacun écrirait inutilement sa propre copie. Ainsi, lorsque la mise en cache s'applique, le premier appel s'exécute seul, un bref délai est accordé pour la propagation du cache, et ce n'est qu'ensuite que les appels restants sont lancés en parallèle — chacun lit alors le cache chaud au lieu de payer pour le réécrire.
Les modèles Anthropic mettent explicitement en cache les instructions partagées ; les PDF et images en pièce jointe sont mis en cache sur place ; et les fournisseurs avec mise en cache automatique des préfixes (OpenAI, xAI, DeepSeek et autres) bénéficient du même préfixe identique à l'octet près. La mise en cache est la plus rentable précisément lorsque l'entrée est volumineuse — de nombreuses expertises, plusieurs langues ou des documents en pièce jointe.
La comptabilité des coûts tient compte du cache : les jetons d'entrée en cache sont facturés au tarif de lecture du cache du modèle (une fraction du tarif d'entrée), et seuls les jetons réellement nouveaux sont facturés au plein tarif. Les économies apparaissent directement dans vos analyses de coûts, pas seulement en théorie.
Au-delà de la mise en cache du préfixe partagé, Entity Enricher réduit la partie non partagée de chaque appel.
Chaque appel d'expertise ne reçoit que la portion du schéma dont il est responsable, et non le schéma entier.
Un expert financier ne voit jamais les champs réglementaires. Moins de champs signifie moins de tokens en entrée et en sortie — et la réponse est élaguée à sa portion avant la fusion.
Lorsque des documents sont joints et que vous n'avez pas activé un mode strict de sortie structurée, la liste des champs ne figure que dans le prompt lisible — aucun schéma n'est dupliqué sur le réseau.
Cela supprime entièrement les jetons du schéma et conserve un préfixe partagé identique (pour une meilleure mise en cache). La réponse reste validée côté client, avec auto-correction automatique en cas de dérive.
La classification préalable facultative exécute un seul modèle rapide et économique pour vérifier qu'une entité correspond bien à votre schéma avant tout enrichissement multi-modèles coûteux. Une non-correspondance — comme une lune envoyée à un schéma « Planète » — est détectée pour une fraction de centime au lieu de gaspiller un enrichissement complet sur plusieurs modèles premium.
Cette vérification est non bloquante (en cas d'échec, l'enrichissement se poursuit quand même) et annulable : vous ne commencez donc jamais à payer pour des modèles que vous avez décidé d'ignorer.
Un cycle de validation échoué est un appel LLM au tarif plein sans aucun résultat. Deux mécanismes rendent les nouvelles tentatives rares et productives.
Les anomalies courantes des sorties LLM — objets indexés qui devraient être des tableaux, la chaîne « null », guillemets échappés parasites — sont corrigées avant la validation.
De nombreux échecs de validation potentiels sont corrigés silencieusement et ne déclenchent donc jamais de nouvelle tentative payante.
Lorsqu'une nouvelle tentative est réellement nécessaire, l'erreur de validation exacte est renvoyée au modèle afin qu'il puisse corriger ce problème précis.
Un retour clair et précis augmente les chances que la prochaine tentative réussisse, au lieu de gaspiller des tentatives avec des indications vagues.
La passe unique est la moins coûteuse pour les petits schémas ; la multi-expertise est conçue pour les grands, où la mise en cache et le périmètre par expertise compensent largement les appels supplémentaires. Consultez Stratégies pour savoir quand utiliser chacune.
Une limite de concurrence par fournisseur empêche les tâches de submerger un fournisseur jusqu'aux erreurs de limite de débit, qui déclencheraient sinon des temporisations et de nouvelles tentatives — tokens et temps perdus. Une concurrence régulée et stable coûte moins cher que de lutter contre les erreurs 429.
Chaque enrichissement enregistre ses décomptes réels de tokens — y compris les lectures en cache — et le coût qui en résulte. Le Tableau de bord des coûts les transforme en graphiques temporels et en ventilations par modèle, afin que vous voyiez exactement où va la dépense et confirmiez que la mise en cache et le cadrage font leur travail. Le prix affiché est le prix facturé ; les coûts bruts des fournisseurs et toute marge de la plateforme restent transparents.