Forme de l’ontologie vs taille du modèle : quel est le coût de la conception d’un graphe pour un agent d’IA

Lorsqu’un agent ne performe pas correctement, la solution à laquelle recourent la plupart des équipes est d’utiliser un modèle plus grand. Cette méthode fonctionne également, mais à un coût environ quatorze fois supérieur à celui de corriger le graphe directement. Ce chiffre provient d’une expérience où les mêmes données ont été modélisées de trois manières différentes, et où un seul agent sur Microsoft Foundry disposait de quatre outils de parcours sans aucune autre voie menant à la réponse. Ce qui a été mesuré, c’est le coût de la structure des connaissances, par question.

Trois présentations d’une même base de faits sont illustrées ci-dessus, pour un total de 2 435 faits. Chaque panneau représente un véritable sous-graphe tiré des données expérimentales, montrant comment chaque ontologie gère le voisinage des mêmes trois demandes d’assurance. Dans la présentation plate, la structure est intégrée à des propriétés, de sorte que presque rien ne relie les éléments entre eux. La présentation normalisée fait de chaque fait un sommet à part entière : rien n’est omis, mais rien n’a de nom. La présentation structurée attribue un type à chaque entité et donne un nom à chaque arête. L’agent, le modèle et la base de données restent identiques dans les trois cas, et seule la forme varie.

Tout d’abord, quelques mots sur les données. Tout y est inventé : les personnes, les entreprises, les lieux ainsi que l’assureur proviennent de listes de mots fictives avec une graine fixe, de sorte que rien ne fait référence à quelque chose de réel. Les mesures proviennent d’exécutions en temps réel en Suède centrale. Le raisonnement a eu lieu sur une installation dédiée Microsoft Foundry, les connaissances étaient stockées dans un compte Azure Cosmos DB pour Apache Gremlin, et chaque appel à outil correspondait à une requête Gremlin s’adressant à un graphe en temps réel. Au total, cela a donné 480 épisodes d’agents, 4,3 millions de tokens et 8,09 dollars. Une première analyse sur le même réseau, où les outils consultaient les fichiers génératifs plutôt que la base de données, a coûté 7,74 dollars ; on l’appelle l’exécution de vérification croisée. Toutes les figures rapportées proviennent des campagnes Cosmos, et la vérification croisée n’est effectuée que lorsque deux exécutions révèlent ensemble quelque chose que seule une exécution n’aurait pas pu montrer.

La couche que personne ne met à jour

Les équipes qui mettent en place des agents ont tendance à répéter un petit rituel : l’agent échoue sur des questions qu’il devrait pouvoir résoudre. Quelqu’un propose alors un modèle plus complexe. La facture double, les échecs se déplacent vers d’autres questions, et l’analyse post-projet conclut que les agents ne sont pas encore prêts.

Presque personne ne met en avant le matériel réel : la nature des connaissances fournies à l’agent. Oublions un instant les faits. Demandons-nous si l’ajusteur est un nœud ou une chaîne enfouie dans un bloc JSON, si le lien indique assessed_by ou simplement related, et si le passage d’une demande à un assuré nécessite un seul saut ou cinq.

Les travaux de mesure précédents portaient sur un système qui prend des décisions et un outil qui les consigne. Ailleurs, une série publique en trois parties a créé une couche de connaissances persistante, y a fait fonctionner des agents à l’aide de ses propres données d’assurance synthétiques, et a défendu l’idée de considérer les connaissances comme des artefacts conçus plutôt que comme de simples sources de récupération. Ce qui manquait dans cette argumentation, c’était une mesure, et cette expérience en fournit une. Elle ajoute une couche au substrat sur lequel les agents raisonnent et pose une question pour laquelle on obtient rarement des chiffres : avec le modèle, les outils, les prompts et les faits figés, et seule la structure de l’ontologie modifiée, comment réagissent la précision, l’effort et le coût ?

Cette première réponse suscite une objection ; c’est pourquoi tout le réseau a été recalculé à l’aide d’un modèle bien plus grand pour voir si l’argent peut simplement surpasser un graphique de forme déficiente. C’est possible. Ce qui est intéressant, c’est le prix, ainsi que ce qu’il révèle sur la forme qui vaut la peine d’être développée. Comme précédemment, chaque affirmation nécessite une preuve.

Trois formes d’une même vérité

Le domaine de test est un registre d’assurances comprenant des assurés, des polices, des couvertures, des sinistres, des ajusteurs, des prestataires de réparations, des paiements et des régions. Un script prédéfini a généré tout cela une seule fois, produisant 2 435 faits canoniques concernant 507 entités, toutes fictives.

Trois ontologies découlent de cette même base de faits. Les qualifier de trois ensembles de données serait erroné ; il s’agit de trois formes des mêmes données, soumises à une règle unique : chaque variante doit reformuler les faits sans ajout ni perte. Pour la faire respecter, un script parcourt chaque graphe généré, reconstruit les faits et vérifie que le résultat est identique à la source. Une variante qui connaîtrait un fait de plus ou de moins que l’autre transformerait cette compétition en un test de couverture des données. Le système de contrôle continu du dépôt exécute cette vérification à chaque mise à jour sur la branche principale et à chaque demande de fusion, ainsi qu’une vérification pour s’assurer que les données commitées correspondent mot pour mot à ce que génère la version de référence ; l’expérience est annulée si l’une ou l’autre des vérifications échoue. Une réservation concernant l’équité s’applique : les constructeurs de structures plates et façonnées ont été développés sans tenir compte de l’ensemble des faits, ce qui rend leurs vérifications substantielles, tandis que le graphe normalisé est codé directement à partir des faits, ce qui le rend, par construction, plus proche d’eux sans perte d’information que par preuve.

La structure plate est celle que de nombreuses équipes finissent par livrer en premier, et elle ne fait usage que de deux types de nœuds complexes. Chaque nœud de souscripteur stocke ses polices et leurs couvertures sous forme de bloc JSON dans une propriété. Chaque nœud de sinistre intègre son expert, son prestataire et les paiements de la même manière. Un seul type d’arête générique, related, relie les souscripteurs aux sinistres, ce qui constitue l’ensemble du schéma. Toutes les informations existent, mais sont enfouies.

La normalisation échoue dans la direction opposée et n’est pas un « strawman », car un manuel scolaire l’applaudirait. Elle réifie tout : les entités deviennent des nœuds Resource purs ne contenant que leur type, chaque attribut devient un nœud Attribute accessible via un bord générique has, et chaque relation devient un nœud Relation avec des bords subject et object. Cela semble impeccable sur le papier, mais apprendre quoi que ce soit nécessite quatre étapes.

Shaped a été conçu en tenant compte du consommateur qui l’utilisera réellement. Les types de nœuds sont définis avec une granularité réfléchie, et chaque arête possède une direction, un type ainsi qu’un nom ayant une signification précise, tels que filed_against, assessed_by ou settles. Les politiques font référence aux assurés via held_by, et ce même nom est réutilisé à des fins délibérées : quatre-vingt-dix arêtes held_by dérivées relient directement une réclamation à son assuré, ce qui réduit la distance entre la réclamation et l’assuré à un seul saut. La réutilisation de ce nom est intentionnelle, car la relation reste identique des deux côtés et l’agent n’a pas besoin d’un second vocabulaire. Ces quatre-vingt-dix arêtes portent un indicateur derived, ne fournissent aucune information supplémentaire et sont exclues de la démonstration d’absence de perte, étant donné qu’elles reposent sur des faits déjà existants.

La figure 1 esquisse une seule relation, une demande d’indemnisation et son expert-évaluateur, sous les trois formes. La version plate intégre l’expert-évaluateur dans une propriété JSON de la demande et ne crée presque aucun lien. La version normalisée attribue à cette relation un nœud distinct, deux arêtes, ainsi qu’un nœud d’attribut séparé pour chaque fait. La version structurée se contente de nommer les arêtes et s’arrête là, son panneau illustrant également pourquoi ce raccourci dérivé unique existe. Un script de reconstruction confirme que les trois versions contiennent exactement les mêmes 2 435 faits.

Le nombre de nœuds donne un aperçu du raisonnement. Un ensemble de faits nécessite 130 nœuds dans la version plate, 507 dans la version structurée et 2 942 dans la version normalisée, chaque nœud supplémentaire représentant un point où l’agent peut devoir se rendre.

Une entité concrète montre mieux la différence qu’une description. Prenons l’assurance qui rendra les résultats célèbres : chaque variante la stocke réellement comme telle :

La figure 2 extrait directement la politique P-7009 des fichiers d’ontologie enregistrés à l’aide du script de rendu des figures, les mêmes fichiers qui ont été chargés dans Cosmos, ce qui montre exactement le chemin emprunté par l’agent. Flat conserve la politique sous forme de chaîne de caractères au sein d’une propriété du souscripteur : elle est bien présente, mais ce n’est pas un sommet et elle ne peut pas être consultée. Normalized la stocke en tant que sommet Resource nu, dont les attributs se trouvent chacun dans un sommet distinct situé à deux étapes de distance. Shaped, quant à lui, conserve un sommet typé dont les propriétés sont attachées, ainsi que des arêtes nommées qui en partent. La prime reste identique dans les trois cas, mais elle se trouve à trois distances différentes par rapport à la question.

Chaque forme est placée dans son propre conteneur de graphe au sein d’Azure Cosmos DB pour Apache Gremlin, et c’est ce que l’agent parcourt ; chaque appel d’outil se transforme en parcours Gremlin sur un graphe en temps réel. Le générateur émet la base de faits, un chargeur l’écrit dans Cosmos, et le système effectue des audits de chargement : le nombre de sommets et d’arêtes doit correspondre à celui de la source, sinon un manque de correspondance est signalé plutôt que de trouver un graphe inachevé par la suite.

Une seule base de données, une seule couche d’outils et des paramètres d’indexation identiques permettent de comparer les conceptions, et ils rendent également ces conceptions visibles. Un graphe de propriétés ne cache rien. Demandez-lui ce qu’il sait, et la réponse sera la conception elle-même.

Le tableau 1 dénombre les mêmes 2 435 faits sous chaque schéma, tirés des fichiers graphiques. Le format plat présente plus de sommets que d’arêtes, et cinq sommets ne sont reliés à rien. Le format normalisé est uniforme et ne contient pas de mots. Le format structuré est le plus bien connecté, et ses étiquettes utilisent le vocabulaire du domaine.

Retour au format plat. Les arêtes sont en nombre inférieur aux sommets, et cinq nœuds ne sont reliés à rien ; il s’agit de souscripteurs sans réclamations, et selon cette conception, rien d’autre dans le système ne les relie. Il s’agit donc d’une base de données graphiques stockant quelque chose qui à peine peut être considéré comme un graphe. La structure existe toujours, mais elle a été transformée en 8,2 propriétés par sommet, de sorte qu’elle se comporte comme du texte et non comme une topologie. Les résultats dépendent de ce choix de conception, et la base de données graphiques le présente comme un fait, et non comme une opinion.

La colonne normalisée le reflète. C’est le graphique le plus uniforme des trois : environ un arête par sommet, rien d’isolé, 1,6 propriétés par nœud, car la réification transforme chaque fait en les mêmes trois éléments de base, répétés 2 942 fois. La structure abonde tandis que le vocabulaire fait défaut, avec trois étiquettes de sommet et trois étiquettes d’arête couvrant l’ensemble du secteur de l’assurance.

Avec 1,36 arêtes par sommet, le graphique structuré est le plus bien connecté, disposant de huit étiquettes de sommet et de neuf types d’arêtes. Le contraste apparaît immédiatement lorsque l’on demande à chaque graphique quels types d’éléments il contient :

g.V().groupCount().by(label)

• Flat ne contient que la demande (90) et l’assuré (40).
• Les rapports normalisés indiquent Ressource (507), Attribut (1834) et Relation (601).
• Les listes structurées présentent huit catégories : 216 pour la couverture, 90 pour les demandes, 75 pour les polices, 59 pour les paiements, 40 pour les assurés, 12 pour les prestataires, 10 pour les ajusteurs et 5 pour les régions.

Une deuxième requête compte les polices par catégorie :

g.V().hasLabel('policy').count()

Le tableau 2 place une requête à côté de trois réponses. Les deux zéros représentent des échecs de types différents. Dans le graphique plat, il n’existe tout simplement aucune politique à trouver. Dans le graphique normalisé, une politique existe mais ne se manifeste pas. Le graphique plat a perdu l’entité ; le graphique normalisé a conservé l’entité mais a perdu le vocabulaire, de sorte qu’une politique ne peut être atteinte qu’en la parcourant, jamais en la nommant. Rien de tout cela ne provient de la manière dont les données ont été stockées : trois schémas, une base de données, une requête.

Le même déséquilibre apparaît lors du calcul du prix pour une question réaliste. Dans quelle ville réside le souscripteur, pour la police d’assurance associée à la demande C-31020 ? Chaque graphique indique Larkfield, car chaque graphique contient les mêmes faits. Ce qui varie, c’est le chemin à suivre pour y parvenir. Dans le graphique structuré, le bord dérivé le raccourcit :

# shaped - the derived shortcut collapses the path
g.V().has('number','C-31020').out('held_by').values('city')

Les graphiques plats et normalisés ont besoin de ceci à la place :

# flat - one hop, but only because claims and holders are the only two things
g.V().has('number','C-31020').in('related').values('city')# normalized - the same answer, five steps and two unwrappings later
g.V().has('value','C-31020').in('has')
     .in('subject').has('kind','filed_against').out('object')
     .in('subject').has('kind','held_by').out('object')
     .out('has').has('attr','city').values('value')

Flat gère cela en une seule étape uniquement parce qu’une réclamation et un détenteur sont par hasard les deux seuls types d’éléments présents dans ce schéma. La normalisation nécessite cinq étapes et deux déballages. Un agent ne compose jamais ces requêtes lui-même ; il trouve le chemin étape par étape, à l’aide d’appels d’outils, ce qui constitue l’objectif de l’expérience. Néanmoins, ces requêtes révèlent ce qui est découvert et en quelle quantité.

La figure 3 montre qu’une requête identique est exécutée sur les trois graphes présents dans le Cosmos DB Data Explorer. Que le graphique propose deux étiquettes, trois métalégendes ou le domaine exprimé en ses propres termes, les schémas ne contiennent pas de données différentes ; ils contiennent un seul ensemble de données sous différentes formes.

La figure 4 sélectionne la réclamation C-31020 dans chaque graphe et permet à l’Explorateur de données de dessiner ses voisins. Dans le graphe plat, un seul sommet est accessible, un assuré, via une arête étiquetée simplement related. L’adjuster AJ-09 et l’assurance PL-043 sont visibles dans le panneau des propriétés, mais sous forme de texte, de sorte que l’agent ne peut pas s’y rendre. Dans le graphe normalisé, huit sommets apparaissent, ainsi que six attributs et deux relations, aucun d’eux ne portant de nom en langue de domaine. Dans le graphe structuré, trois d’entre eux sont nommés : filed_against, assessed_by et held_by. Une réclamation, une base de données, trois distances.

L’outil : quatre outils et un reçu

L’agent est maintenu au minimum intentionnellement, car il ne s’agit pas de l’entité testée. Il s’agit d’une simple boucle d’appel de fonction qui fonctionne avec un déploiement de modèle Microsoft Foundry, configurée selon la manière dont les documents Foundry décrivent l’utilisation des outils via l’API Chat Completions. Un prompt système fixe, un plafond de seize tours de modèle par question (après quoi l’épisode est abandonné) et quatre outils complètent ce système, dont les signatures sont identiques dans les trois ontologies.

La figure 5 montre l’ensemble des ressources informatiques utilisées : une seule ressource Microsoft Foundry contenant deux déploiements de modèles, agent-small exécutant gpt-5.4-nano et agent-large exécutant gpt-5.5, tous deux de type Global Standard. Les noms et les versions proviennent du modèle d’infrastructure présent dans le répertoire, de sorte qu’aucune flotte cachée ne se trouve derrière ces chiffres.

Les quatre outils sont :

• find_nodes recherche les propriétés et les identifiants des nœuds par sous-champ, avec un plafond de vingt résultats
• get_node lit le type et les propriétés d’un nœud
• traverse renvoie jusqu’à trente voisins d’un nœud, filtrables par type de bord et par direction
• describe_edges résume quels bords quittent ou entrent dans un nœud et combien il y en a de chaque type

Dans les faits, chaque outil se transforme en Gremlin sur Cosmos. get_node et find_nodes nécessitent chacun une seule itération, soit une lecture ponctuelle soit un balayage, tandis que traverse et describe_edges en exigent trois, car ils doivent d’abord vérifier l’existence du nœud avant d’explorer successivement les arêtes sortantes et entrantes. L’agent ne gère rien de tout cela ; il demande un nœud ou un voisin et reçoit une réponse JSON compacte, qui correspond à la forme habituelle des outils de production utilisés avec un stockage de graphes, ce qui permet également de séparer le langage de requête du modèle lui-même.

Parcourir le graphe est le seul moyen d’obtenir une réponse. L’agent ne consulte jamais le schéma ni n’écrit de code Gremlin, et il a pour instruction de répondre littéralement par NOT_MODELED chaque fois que le graphe ne contient pas ce dont une question a besoin. La capitalisation est importante : un graphe mal structuré entraîne des appels supplémentaires à des outils plutôt qu’une seule réponse volumineuse, tout comme cela se produit dans les budgets réels alloués aux outils. La limite de seize tours compte les échanges dans la conversation et non les appels aux outils, et un tour peut demander l’utilisation de plusieurs outils en même temps ; ainsi, l’épisode le plus chargé a nécessité soixante appels au cours de ses seize tours.

Trois leçons pratiques tirées de l’utilisation d’une véritable base de données graphiques, chaque fois nécessitant une reconstruction. Cosmos ne permet pas les scripts multi-instructions, ce qui signifie qu’un chargement implique une seule exploration par requête, et la capacité de traitement provient de l’exécution de nombreuses requêtes en parallèle plutôt que par lots. Un délai de réponse strict de soixante secondes empêche g.V().drop() d’effacer quelques milliers de sommets : il s’arrête en cours de route et laisse un graphe partiellement supprimé, ce qui oblige à effectuer les suppressions par tranches. Le niveau sans serveur présente également une limite de capacité de traitement qui transforme une série de quarante écritures simultanées en temps d’attente excessif, d’où la nécessité pour le chargeur et l’outil d’agent de tenter à nouveau avec un retard progressif. Rien de tout cela n’est inhabituel, mais cela distingue clairement un stockage graphique en situation de repos d’un autre sous charge.

Évaluation sans juge

L’évaluation des agents tend à s’assouplir lors de l’étape de notation, c’est pourquoi celle-ci a reçu le plus d’attention, et aucun juge basé sur un LLM n’apparaît nulle part. Quarante questions forment quatre catégories de dix chacune : des recherches sur un seul fait, des parcours courts de deux ou trois étapes, des questions nécessitant un chemin long ou une agrégation sur un sous-graphe, ainsi que des questions impossibles à répondre. Un script les génère à partir de la base de faits et déduit chaque réponse correcte à partir des faits bruts. La notation est mécanique : un nombre doit correspondre à la valeur calculée, une chaîne de caractères doit la contenir, et une question sans réponse n’est considérée comme correcte que lorsque l’agent affirme explicitement qu’il ne peut pas y répondre. Aucune ontologie ne s’évalue elle-même, aucun modèle ne juge un autre modèle, et la justesse provient de comparaisons plutôt que d’opinions.

Puisque l’agent ne peut agir qu’au moyen de ses quatre outils, chaque réponse est accompagnée de la liste complète des appels qui l’ont générée. Lors des mesures précédentes sur le routage, le champ model servait de reçu ; ici, c’est le chemin qui le remplace. Une réponse correcte peut être suivie étape par étape, tandis qu’une erreur indique précisément où la forme a perdu le contrôle de l’agent.

La figure 6 illustre cette configuration. Une base de faits initiale alimente trois formes sans perte de données, qui deviennent trois conteneurs de graphes dans Azure Cosmos DB pour Apache Gremlin ; une branche distincte alimente quant à elle l’oracle qui déduit chaque réponse correcte à partir des mêmes faits. L’agent accède aux graphes uniquement via ces quatre outils, en effectuant une requête Gremlin par appel. Les outils, les boucles et les questions restent inchangés tandis que les formes varient, et chaque exécution produit des reçus : les appels aux outils, les tokens, la latence ainsi que le verdict de l’oracle.

Le groupe d’interrogations sans réponse mérite une analyse à part entière. Ses dix questions demandent des informations que la base de faits ne peut jamais représenter : numéros de téléphone, adresses e-mail, conditions météorologiques, numéros d’identification des véhicules. La bonne réponse consiste à indiquer que le graphe ne peut pas le dire. Un agent qui invente une liaison au lieu d’admettre que le graphe n’en possède aucune présente l’échec le plus dangereux au sein de cette famille de systèmes, et presque personne ne le mesure.

Le coût de parcours

La campagne principale a été menée sur les graphes en temps réel de Cosmos DB, en utilisant un déploiement dédié de Microsoft Foundry situé en Suède centrale. Elle a porté sur trois ontologies, quarante questions et trois parcours complets, avec un petit modèle maintenu constant, ce qui a donné 360 épisodes d’agents, 3,1 millions de tokens et soixante-dix cents. Chaque appel d’outil correspondait à une requête Gremlin. Une deuxième campagne, décrite plus tard, a réexécuté le processus sur un modèle plus grand, pour 120 épisodes supplémentaires et 7,39 dollars. Un script de répertoire calcule tous les chiffres ci-dessous à partir des reçus enregistrés, et aucun n’a été saisi manuellement.

Le tableau 3 résume la campagne mesurée : petit modèle, trois parcours, 360 épisodes, une requête Gremlin derrière chaque appel d’outil. Le vert indique le meilleur résultat dans chaque ligne. Les lignes relatives aux ressources restent dépourvues de couleur intentionnellement, car leur consommation est la plus faible sur les quatre critères, et comme le montrent les sections suivantes, cette économie permet de financer des réponses qui n’ont jamais été fournies.

Commencez par soustraire la première ligne, qui représente la valeur la moins informative du tableau. La méthode « shaped » a répondu correctement à 84,2 % des questions, la méthode « flat » à 78,3 %, et la méthode « normalized » à 59,2 %. Cependant, au cours de trois essais par ailleurs identiques, la précision des différentes méthodes a varié respectivement de 0,075, 0,150 et 0,075, de sorte que l’écart de six points entre « shaped » et « flat » se situe à l’intérieur de son propre bruit ; avec trois essais, rien ne permet de distinguer ces deux méthodes en termes de précision globale. L’avance de vingt-cinq points sur la méthode « normalized » permet de surmonter facilement ce bruit.

Cela semble moins significatif qu’en réalité. La valeur globale est floue car elle calcule une moyenne de plages qui présentent des divergences importantes, et ces divergences constituent justement la conclusion :

Le tableau 4 illustre le problème posé par cette moyenne globale. Les différentes méthodes ne diffèrent pas légèrement partout ; elles présentent des écarts marqués d’une plage à l’autre, et chaque plage exige des informations différentes du graphique.

Examinons d’abord les recherches basées sur un seul fait. Les scores obtenus sont de 0,967 pour la forme courbe et de 0,533 pour la forme plate, soit une différence de quarante-trois points, contre un bruit de 0,100 pour la première et de 0,200 pour la seconde, ce qui confirme que le signal est réel. Pour les parcours de deux ou trois étapes, les scores atteignent également 0,967. Dans la bande la plus difficile, avec un bruit de 0,300 et 0,400 respectivement, il n’y a pas de moyen de désigner un gagnant.

Ces deux formes ne sont donc ni meilleures ni pires. Elles se brisent en des points différents, et les combiner en un seul chiffre cache l’information utile. Lorsqu’il faut trouver quelque chose, la forme plate échoue et continue d’échouer. Lorsque l’agent a déjà une base solide et n’a besoin que de progresser, la forme plate performe aussi bien que le graphe conçu à cet effet.

La version normalisée reflète cette situation, comme le montrent ses bandes : 0,867 pour les recherches, ce qui est supérieur à la forme plate puisque chaque entité constitue un véritable sommet, puis 0,467 et 0,133 à mesure que les parcours s’allongent. Elle parvient à trouver n’importe quoi mais ne termine jamais rien.

Comment chaque forme échoue

Les deux approches diffèrent tant par la manière que par le lieu où elles échouent. Chacune a abordé trente questions trois fois, soit au total quatre-vingt-dix épisodes ; en regroupant les échecs par type d’échec, on peut identifier le mécanisme en jeu.

Le tableau 5 regroupe les échecs sur ces quatre-vingt-dix épisodes. Normalized épuise son budget de tours ; Flat s’arrête tôt et avec assurance sur des questions que la base de données aurait pu résoudre.

Vingt-deux des quatre-vingt-dix épisodes de Normalized, soit environ un quart, se terminent avec l’épuisement du budget et l’agent encore en train de marcher. Flat, quant à lui, le fait rarement : il s’arrête tôt et avec confiance, refusant dix-huit questions pour lesquelles des réponses existent dans la base de données. L’une des approches s’épuise, tandis que l’autre abandonne.

La défaillance plate est la plus marquée, et les traces révèlent un mécanisme que personne n’attendait. Voici deux épisodes réels. Dans les deux cas, on demande le supplément pour la police P-7009, et ils ne diffèrent que par le schéma qui se trouve derrière les outils :

flat                                       shaped
find_nodes "P-7009"          -> 1 hit:     find_nodes "P-7009" type=policy
   policyholder:PH-05 "Ivo Renner"            -> 1 hit: policy:PL-009 "P-7009"
find_nodes "7009"            -> 1 hit      get_node policy:PL-009
find_nodes "P-7009" type=policy       -> 0     -> premium 750
find_nodes "P-7009" type=policyholder -> 1 hit
ANSWER: NOT_MODELED                        ANSWER: 750

Sur le graphique structuré, deux requêtes suffisent. Demandez la police d’assurance par numéro, obtenez un sommet correspondant, lisez le montant de la prime qui s’y trouve, et c’est terminé.

Le graphique plat raconte une histoire différente. La première recherche a retourné un sommet, tout comme la deuxième. La troisième a demandé type=policy mais n’a rien trouvé, car cette étiquette n’existe pas dans ce schéma. La quatrième a demandé type=policyholder et a obtenu un résultat. Ainsi, en fonction du type, l’agent a trouvé le sommet exact qui contenait la réponse, tout en déclarant néanmoins les données manquantes.

Le contrat premium se trouvait à l’intérieur de ce sommet, dans une propriété, à une seule appelation de get_node de distance. Au cours des dix épisodes où la recherche échouait, la recherche non filtrée a révélé le sommet contenant le contrat quinze fois, tandis que get_node n’a été exécuté que zéro fois sur celui-ci. Le sommet portait l’étiquette « Ivo Renner », qui correspondait à une personne. Dans les autres épisodes où la recherche échouait, l’étiquette appartenait à l’un des deux autres assurés, jamais au contrat lui-même, et le nom d’une personne ne donnait aucun indice indiquant que le contrat recherché se trouvait à l’intérieur.

C’est là le risque particulier lié au fait de cacher une entité, et une base de données graphique permet de la localiser. Les données sont accessibles mais irreconnaissables. Elles sont indexées, retournées par la requête et présentes dans le contexte de l’agent, pourtant elles ne correspondent à aucun nom utilisé dans la question.

La normalisation échoue en public, et à un coût élevé. Lire une attribut signifie parcourir un nœud Attribute, et suivre une relation signifie faire un détour par un nœud Relation. La colonne « Tokens » montre le coût : 13 701 par question contre 7 176 pour les formes structurées, ainsi que 12,15 appels d’outils contre 7,24. Vingt-cinq des 120 épisodes atteignent la limite de seize transformations, contre trois pour les formes structurées et deux pour les formes plates, et le groupe le plus difficile a obtenu un score de 0,133. Le graphe ne manquait de rien. L’agent s’est simplement essoufflé avant d’avoir terminé la phrase.

Le mode le moins cher est vraiment le moins cher, même si ce n’est pas un compliment. Le mode « Flat » coûte 0,109 dollar par cent questions, contre 0,165 dollar pour le mode « Shaped » ; en tenant compte de la précision, il reste encore le plus avantageux, avec 0,14 dollar par cent réponses correctes, contre 0,20 dollar. Selon ce modèle, le mode « Flat » est véritablement moins cher à utiliser. Ce que le prix ne permet pas d’obtenir, c’est les dix-huit réponses qu’il a refusées. Arrêter rapidement est peu coûteux, et une facture modeste ne constitue pas une économie, ce que la seule colonne des coûts ne révèle jamais.

Le paradoxe du refus

Le meilleur et le pire échangent de place dans la catégorie des questions sans réponse une fois que l’on consulte les questions répondables. Le mode « Flat » a correctement refusé toutes les trente épisodes sans réponse, obtenant ainsi le seul score parfait du tableau. Le mode « Shaped » a atteint 0,933 et un score normalisé de 0,900 ; ses échecs provenaient de fins prématurées d’épisodes, et non d’inventions.

Considéré isolément, ce groupe présente une tendance plate. À côté du compteur des refus fictifs, l’ordre s’inverse : le groupe ayant le score de refus parfait a ignoré dix-huit questions auxquelles il aurait pu répondre, tandis que le groupe ayant le pire score de refus en a ignoré treize. La tendance plate n’est pas plus efficace pour détecter l’absence de réponse ; elle a plutôt tendance à la signaler, et cette tendance, qui l’emporte sur les questions sans réponse, échoue sur celles qui ont des réponses. Une métrique de refus sans une métrique de répondabilité à côté d’elle conduit à la création du graphique le moins informatif possible.

Une conclusion contre la conception

Un résultat contredit le design structuré privilégié par l’expérience, et la deuxième campagne l’a encore renforcé. Il n’existe qu’un seul raccourci dérivé dans ce modèle structuré : held_by, qui relie directement une demande à son assuré. Pour la question concernant le lien entre la demande, l’assuré et la ville, ce modèle a obtenu 0,83, contre 0,33 pour le modèle normalisé, tandis que le modèle plat a atteint 0,92 sans aucun raccourci, étant donné que dans ce schéma il n’y a que deux éléments : la demande et l’assuré. Un résultat obtenu par un modèle structuré sans ces éléments supplémentaires ne peut donc pas être attribué à ces derniers.

Pire encore, l’absence d’abréviation a eu des conséquences là où on s’y attendait. Le comptage des types de couverture distincts au sein des politiques d’un assuré a donné 0,17 sur le graphique censé être bien conçu et 0,67 sur le modèle plat, ce qui les regroupe dans une seule propriété lisible. La somme des paiements liés aux demandes d’indemnisation d’un assuré s’établit à 0,33. Pour l’agrégation au sein d’un sous-graphique, le design défendu perd face au design qualifié de défectueux. La dénormalisation n’est pas un compromis par rapport à une bonne conception, mais en fait une partie intégrante ; de plus, le graphique structuré a appliqué ses propres principes de manière trop parcimonie justement là où la charge de travail l’exigeait.

Essayer de se sortir en utilisant un modèle plus complexe

Le réseau complet a ensuite été exécuté une deuxième fois sur un modèle bien plus grand, et la réponse à la question principale est apparue grâce à un comportement inattendu de ce dernier. Au départ, on supposait que le petit modèle sur un graphe bien structuré surpasserait le grand modèle sur un graphe mal structuré. Ce ne fut pas le cas. Seules les questions répondables entrent dans cette comparaison, de sorte que le refus des questions sans réponse ne peut pas améliorer l’image d’un graphe quelconque. Chaque ligne correspondant à un petit modèle comprend quatre-vingt épisodes répartis sur trois passes, tandis que chaque ligne correspondant à un grand modèle en compte trente issus d’une seule passe.

Le tableau 6 se limite aux questions répondables, donc des refus corrects ne peuvent pas faire paraître un graphe sujet aux refus sous un meilleur jour.

Le grand modèle lit sans difficulté les propriétés cachées. Il a répondu aux trente questions posées sur le graphe plat, y compris celles concernant les entités que le schéma avait transformées en texte, et les dix-huit refus fictifs qui gênaient le petit modèle ont disparu. Le résultat honnête n’est pas celui que tout le monde souhaitait.

Une ontologie mal conçue peut néanmoins être rentable. Le coût est d’environ quatorze fois celui par question : le grand modèle sur le graphe plat coûte 1,90 dollar par cent questions, tandis que le petit modèle sur le graphe structuré coûte treize cents. En conservant le graphe plat et en ne mettant à jour que le modèle qui s’y trouve, la facture est vingt fois supérieure à celle du même petit modèle utilisé sur ce type de graphe.

Ce résultat est plus utile que celui prévu en raison de ce qu’il implique. Avec un modèle de frontière et des questions répondables, la forme a cessé d’être un problème de correction pour devenir un problème de coût : les versions plate et façonnée ont répondu aux trente questions chacune, et seules les factures les distinguaient. Avec un modèle de petite taille, la forme était elle-même la correction. Une ontologie bien conçue offre donc moins de qualité qu’elle ne procure la capacité d’exécuter un modèle peu coûteux. Un graphe plat lie la couche de connaissances au budget du modèle, fonctionnant uniquement tant que le paiement se poursuit pour un modèle suffisamment grand pour y accéder, pour chaque question, indéfiniment.

Sur les quatre gammes d’évaluation, l’ordre des résultats est plus clair que ce que suggère une vision basée uniquement sur les questions répondables. Avec le modèle de grande taille, la version façonnée a atteint une note parfaite de 1,000 dans toutes les gammes, y compris celle des questions irrépondables. La version plate a atteint 0,950 et une valeur normalisée de 0,825. L’argent ne corrige la justesse que partiellement, tandis que les factures restent inchangées.

Ce que la vérification croisée a appris sur la prudence

La vérification croisée effectuée (même grille, mêmes questions, des outils lisant les fichiers au lieu de Cosmos) a produit le résultat le plus alarmant du projet, et il provenait du graphique structuré. Lorsqu’on lui a demandé quel était le temps le jour d’un incident, que l’ontologie ne modélise délibérément pas, l’agent a répondu « dommages causés par la grêle ». Il avait trouvé la propriété cause de la réclamation et l’a présentée comme étant le temps. Cela a été enregistré à l’époque comme le schéma de conception privilégié ayant entraîné l’échec le plus dangereux, avec la mise en garde qu’il s’agissait d’un épisode survenu lors d’une seule itération, d’une observation et non d’une mesure, sans base pour en faire une loi.

Réexécuter l’expérience sur une infrastructure réelle a été la bonne décision. Dans la campagne mesurée, le graphique à forme appropriée a correctement refusé de répondre aux dix questions auxquelles le grand modèle ne pouvait pas répondre, tandis que le graphique plat a fourni une réponse erronée à la même question. Le modèle, la question et le piège étaient identiques ; seule la forme prise au piège différait.

La conclusion n’est donc pas que les graphiques complexes incitent à la fabrication de réponses. Une propriété cause indiquant « dommages causés par la grêle » tentera tout modèle interrogé sur la météo, quel que soit l’endroit où il est stocké, et la forme prise au piège varie d’une exécution à l’autre. Il s’agit d’une affirmation moins forte que celle qui aurait pu être faite, et c’est ce que les preuves soutiennent. Cela signifie également que le risque ne dépend pas de la forme : si un graphique contient un champ qui ressemble à la réponse à une question à laquelle il ne répond pas, un modèle quelque part y répondra malgré tout.

La forme normalisée sur les deux modèles

La perte normalisée a globalement augmenté avec les deux modèles. Avec le modèle de petite taille, il a terminé en dernière position, et avec le modèle de grande taille, il est resté en retrait avec un score de 0,867 pour les questions répondables, tout en coûtant 9,31 $ par cent, soit près de cinq fois plus que le graphique plat du même modèle, et il a épuisé ses tours à sept reprises. La réification ne s’en sort pas mieux avec un modèle plus grand, car son problème n’a jamais été la compréhension : il s’agissait de la distance, avec quinze appels d’outils par question contre 8,3 pour le modèle normalisé, un modèle qui n’a jamais mal interprété quoi que ce soit.

La forme normalisée n’a pas perdu partout, et c’est cette exception qui enseigne le plus. Lors des recherches basées sur un seul facteur, la forme normalisée a obtenu 0,867 contre 0,533 pour la forme plate, et pour les deux questions où la forme plate a échoué, c’était clairement la forme normalisée qui était supérieure : 0,83 contre 0,17 pour la prime d’assurance, 0,83 contre 0,33 pour la spécialité du prestataire. La réification est extrêmement coûteuse mais ne cache rien. Chaque entité est un sommet, ce qui permet de la retrouver facilement.

Cela résume l’argument : chaque forme défaillante conserve la moitié du problème tout en rejetant l’autre moitié. La forme plate conserve la distance mais perd la capacité d’identification. La forme normalisée conserve la capacité d’identification mais perd la distance. Chacune rivalise sur la moitié qu’elle conserve et échoue complètement sur l’autre.

Shaped ne représente pas de compromis entre les deux approches. Il obtient une note de 0,967 sur l’échelle relative aux valeurs supérieures à zéro et de 0,967 sur l’échelle relative aux valeurs normalisées, ce qui signifie qu’il refuse ce compromis. C’est là que réside son avantage, mais un seul chiffre d’exactitude globale le masque complètement.

Latence face à une base de données réelle

La latence est une mesure que la vérification croisée ne pouvait pas prendre en compte. Avec des fichiers, les temps par appel variaient fortement entre différentes exécutions : la même variante pouvait nécessiter 1,17 seconde par appel lors d’une exécution et 4,21 secondes lors d’une autre, si bien qu’aucun résultat n’a été rapporté, car la variabilité du service l’emportait sur les caractéristiques de l’ontologie. Avec Cosmos, la situation est plus ordonnée, pour une raison liée à une légère déflation des données.

Le tableau 7 montre le temps par question, qui diffère clairement selon les formes, tout en restant constant au sein de chaque forme ; en revanche, le temps par appel d’outil est identique pour les trois cas, ce qui fait que le tableau représente en fait le nombre d’appels d’outil exprimé en secondes.

Dans une même variante, l’écart maximal est de sept secondes, contre un écart de près de cinquante secondes entre le mode plat et le mode normalisé. Une question normalisée prend deux fois et demie plus de temps qu’une question en mode plat. La dernière colonne atténue ce résultat : pour chaque appel, les trois formats coûtent à peu près autant, entre 6,2 et 7,4 secondes, quel que soit le schéma. Il ne s’agit donc pas d’une découverte indépendante. La base de données assure la cohérence, car un aller-retour dans Cosmos est prévisible là où un dictionnaire local ne l’était pas, et c’est ce qui permet de communiquer des chiffres.

Une conséquence pratique en découle. Étant donné que la latence par appel reste à peu près constante, les ensembles de formats ontologiques déterminent le temps de réponse de la même manière qu’ils influencent le coût en tokens, et ce chiffre peut être estimé avant la construction en comptant les sauts.

Principes, chacun avec sa justification

Lorsqu’on écrit sur la conception de l’ontologie, on propose généralement des principes en fonction des préférences personnelles. La plupart de ceux mentionnés ci-dessous sont accompagnés du numéro qui les identifie, et ceux qui n’en ont pas indiquent pourquoi.

Tout ce qui peut faire l’objet d’une question doit être un sommet. Si l’on doit graver un principe au-dessus de la porte, qu’il s’agisse de celui-ci. Le graphique plat conserve chaque prime d’assurance et chaque spécialité de prestataire, indexées, dans la même base de données que tout le reste, et le petit modèle ne les a retrouvées que difficilement. Les primes ont été retrouvées dans 17 % des cas seulement, et les spécialités dans 33 %, tandis que le modèle structuré en a retrouvé 100 % et 83 % respectivement. L’intervalle complet se situe entre 0,533 et 0,967. Cacher une entité à l’intérieur d’une propriété d’une autre entité ne rend pas sa recherche plus difficile ; cela fait en sorte qu’une question pertinente revienne sous un autre nom, que l’agent interprète comme une preuve de l’absence de cette entité. Le croisement ajoute une condition, puisque le modèle frontal les a tous retrouvés. La dissimulation n’est pas une barrière absolue, mais simplement une « taxe » à payer selon le niveau du modèle.

La granularité représente un budget, et sa mise en œuvre l’épuise rapidement. Chaque nœud ajouté pour assurer la pureté du schéma entraîne des coûts supplémentaires à chaque consultation. Par rapport à la version structurée, la version normalisée nécessitait 3,7 fois plus d’appels d’outil pour les recherches sur une seule donnée, 2,3 fois plus pour les parcours courts, et quatre fois plus de tokens dans les parcours longs ; de plus, elle atteignait la limite de tours en vingt-cinq des 120 épisodes, contre trois pour la version structurée. Un modèle dont le coût par token d’entrée était vingt-cinq fois plus élevé a permis d’améliorer les résultats de 0,489 à 0,867 pour les questions répondables. Il s’agit bien d’une amélioration significative, mais elle a été obtenue au prix de 9,31 dollars par cent tokens, soit près de cinq fois le coût du même modèle en mode standard. La distance est toujours coûteuse, quel que soit le budget alloué.

Les points d’entrée relèvent de l’architecture, et ils dépendent fortement du modèle. Chaque question commence par un nom ou un numéro, et ce que renvoie la première appelation d’outil détermine si l’agent commence à travailler ou à deviner. Pour le petit modèle, cette appelation renvoyait une valeur vide dans 10 % des épisodes structurés, 26 % des épisodes plats et 53 % des épisodes normalisés, c’est-à-dire lorsque la recherche aboutissait à un sommet Attribute plutôt qu’à l’entité. Pour le modèle avancé, elle n’était jamais vide, quel que soit le type d’épisode. Ainsi, un premier mouvement gaspillé n’est pas seulement une propriété du graphe : c’est ce qui se produit lorsque un modèle moins puissant rencontre un point d’entrée qu’il n’attendait pas. Construisez les mécanismes adaptés au modèle qui sera utilisé en production, et non à celui utilisé pour les tests.

Denormalisez délibérément, et admettez-le lorsque le reçu ne correspond pas. Une astuce dérivée, held_by, a été utilisée en espérant obtenir un bon résultat sur le chemin « demande vers détenteur ». Elle a obtenu 0,83 dans ce cas contre 0,33 pour la version normalisée, mais 0,92 sans cette astuce sur la même question, ce qui signifie que le crédit n’est pas disponible, et le test propre (effectué avec ou sans cette astuce) n’a pas été réalisé. L’absence de cette astuce apprend en fait davantage. Le calcul du taux de couverture pour les polices liées à un détenteur a donné 0,17 sur le graphique bien conçu et 0,67 sur la version simplifiée, ce qui les place dans une même propriété lisible. Pour l’agrégation sur un sous-graphe, le design proposé a été inférieur à celui qualifié de défectueux. Le choix des astuces fait partie du design, la charge de travail montre lesquelles sont nécessaires, et ici la mauvaise astuce a été choisie, comme l’ont montré les données.

La diffusion a été limitée. La recherche était plafonnée à vingt résultats et la navigation à trente, ce qui signifiait qu’un nœud trop connecté entraînait des appels supplémentaires visibles et comptables, plutôt qu’une seule réponse volumineuse. Aucun mécanisme sans plafond n’était activé, donc les économies restent inconnues. Ce qui est certain, c’est que sans ces plafonds, le coût se cache dans la taille de la réponse, là où aucune métrique de nombre d’appels n’est disponible.

Rendre l’absence lisible et la noter honnêtement. Considérez la zone non répondable comme une exigence de conception et non comme un piège dans le test, mais lisez-la à côté de la zone répondable. Flat a obtenu une note parfaite de 1,000 pour les refus, ayant décliné dix-huit questions auxquelles il aurait pu répondre. Shaped a refusé le moins, et ses deux épisodes non répondables se sont terminés par une abandon plutôt que par l’invention de réponses. Une bonne ontologie permet à l’affirmation « nous ne modélisons pas cela » d’être à la fois accessible et vraie, et une évaluation a besoin des deux aspects pour distinguer un graphe conscient de ses limites d’un autre incapable de localiser son propre contenu.

Les noms constituent l’API. L’agent interprète les noms des éléments de bord de la même manière qu’un développeur lit une signature de fonction, et cette expérience regroupe délibérément la nomenclature et la structure en une seule variable appelée « design ». Aucun chiffre ne vient seul étayer ce principe. Séparer les deux représente l’épreuve d’ablation suivante évidente, et l’indiquer vaut mieux que prétendre des résultats supérieurs à ceux mesurés.

Ce que ce n’est pas

Ce n’est pas une évaluation des bases de données graphiques. Les trois formats partagent un même compte Cosmos DB, une même couche d’outils ainsi que les mêmes paramètres par défaut d’indexation ; par conséquent, le stockage constitue une constante et non une variable, et rien ne compare Cosmos à d’autres bases de données graphiques ni ne l’adapte. Il ne prétend pas non plus que la seule navigation est le moyen par lequel les agents en production devraient récupérer toutes les informations, car les requêtes floues sans point d’entrée clair nécessitent une recherche ; les résultats montrent où la navigation simple trouve son utilité et où elle ne le fait pas. Il ne s’oppose pas à la normalisation dans les systèmes transactionnels, car le format normalisé est inadapté ici pour ce type d’utilisateur, un agent qui paie par étape, et non nécessairement inadapté en général. Il ne s’agit pas non plus d’une comparaison entre fournisseurs : Microsoft Foundry est la constante, et non la variable, et cette méthode pourrait être appliquée à toute plateforme disposant de fonctions d’appel.

Un système de base de données intégré dans le cycle changerait-il le résultat ? Cela exige une réponse, pas une assurance. Avant les campagnes mesurées, les mêmes quatre outils ont été mis en œuvre à deux reprises, tant via Cosmos que sur les fichiers générés par le générateur, et les appels aux outils enregistrés ont été rejoués pour les deux méthodes : 3 056 appels distincts, correspondant à chaque combinaison unique d’outil et d’argument produite par les campagnes. Les deux implémentations ont donné des résultats identiques dans tous les cas. La base de données joue néanmoins un rôle : elle ajoute de la latence et des unités de requête, et Cosmos nécessite environ 4 % de plus d’étapes d’agent que les versions basées sur des fichiers, la majeure partie de cette différence étant liée au graphe normalisé. Cependant, les réponses obtenues par l’agent proviennent de la structure de l’ontologie et non du moteur qui la sous-tend, ce qui suffit pour cette comparaison. La reconstitution des tests est stockée dans le répertoire sous forme de script.

Limites de l’instrument

Plusieurs réserves persistent issues des travaux sur les routeurs. Quarante questions synthétiques dans un seul domaine synthétique forment un outil de petite envergure. Les contrastes sont marqués car les formes sont des archétypes, et une ontologie de production se situe entre les deux, c’est pourquoi ce sont les points d’extrémité qui ont été mesurés. La campagne avec le petit modèle a été réalisée trois fois, et son niveau de bruit est cité à chaque fois. Le réseau de grands modèles n’a été testé qu’une seule fois, si bien que seuls ses résultats saturés, trente réponses correctes sur trente pour deux formes, sont fiables. Un écart de deux questions au sein de ce réseau est considéré comme un cas isolé, et rien ici ne repose sur un tel exemple. Un seul petit modèle et un seul grand modèle ont également été comparés, de sorte que la courbe entre eux reste inconnue.

L’audit du code avant sa mise en production a révélé deux défauts dans l’outil. Premièrement : lorsque le type d’arête demandé n’existe pas dans le graphe, la fonction traverse renvoie une liste de voisins vide, ce qui est indiscernable d’un nœud qui n’a réellement aucun voisin. L’agent a effectué 112 appels de ce type au cours des campagnes, et neuf des vingt-deux refus falsifiés sur le graphe normalisé en contiennent un ; le script d’analyse compte les deux cas. L’écart majeur persiste, car shaped a effectué le plus grand nombre de tels appels tout en refusant le moins de questions. Néanmoins, un outil qui répond « rien ici » pour « aucun tel type d’arête » constitue une source de confusion, et l’alternative honnête serait d’indiquer par erreur les types disponibles. Deuxièmement : la preuve d’absence de perte compare des faits reconstruits, ce qui l’empêche de détecter les arêtes ne contenant aucun fait en soi, c’est-à-dire les arêtes de connexion dans flat ainsi que les raccourcis dérivés dans shaped. Une seconde vérification valide désormais ces arêtes par rapport aux faits qu’elles énoncent, et elle détecte les suppressions ainsi que les erreurs de redirection pour chacune d’elles. Les campagnes ont été menées avant cette vérification, donc aucune garantie n’existait au moment de leur exécution.

La forme constitue l’instruction du système

Beaucoup d’efforts sont consacrés aux mots placés devant un modèle, tandis que presque aucun n’est consacré à la structure des connaissances qui le sous-tendent. Pour un agent utilisant des outils, l’ontologie constitue une instruction : elle définit les actions possibles dans le monde, exprimées en types de nœuds et en noms d’arêtes, et est lue une appel d’outil à la fois. Il convient de la concevoir pour le lecteur réel qui existe.

Les documents de référence se trouvent dans le répertoire de code de l’expérience : base de faits, trois ontologies, preuve d’absence de perte d’information, questions, oracle, agent ainsi que tous les reçus des campagnes. Quiconque modéliserait la même vérité d’une quatrième manière et réussirait à répondre aux questions qui avaient échoué aux autres formes apporterait quelque chose de concret à cette comparaison.

Pour en savoir plus sur les éléments utilisés, la documentation de référence pertinente traite d’Azure Cosmos DB pour Apache Gremlin, des appels de fonction avec les modèles Microsoft Foundry ainsi que de l’API REST Azure Retail Prices, qui fournit les prix par token à l’origine des chiffres de coût.