Tokenomics : quantifier où vont les tokens dans l’ingénierie logicielle agentique

 (arxiv.org)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Étude mesurant, en mappant les traces d’exécution de systèmes de développement logiciel multi-agents basés sur des LLM aux étapes du SDLC, une structure de consommation des tokens davantage concentrée sur la revue de code et la validation que sur la génération initiale
  • Sur 30 tâches de développement logiciel exécutées par ChatDev, l’étape de revue de code consomme en moyenne 59,4 % des tokens, ce qui en fait la phase la plus coûteuse
  • En moyenne sur l’ensemble des tâches, la répartition des tokens est de 53,9 % en entrée, 24,4 % en sortie et 21,6 % en raisonnement, ce qui montre qu’une transmission répétitive du contexte entre agents crée une forte communication tax
  • L’étape de codage se distingue par une forte part de tokens de sortie, à 58,0 %, tandis que l’étape de documentation présente une forte part de tokens d’entrée, à 80,2 %, révélant des schémas d’usage nettement distincts selon les phases du développement
  • Conclusion : pour mieux prévoir les coûts et optimiser les workflows, il faut des protocoles de collaboration entre agents plus économes en tokens et un cadre d’évaluation standardisé

Résumé

  • Les systèmes multi-agents basés sur des LLM (LLM-MA) sont de plus en plus utilisés pour automatiser des tâches complexes d’ingénierie logicielle comme l’ingénierie des exigences, la génération de code et les tests
  • Leur efficacité opérationnelle et leur consommation de ressources restent mal comprises, ce qui rend les coûts et l’impact environnemental difficiles à prévoir et freine leur adoption réelle
  • L’étude analyse les traces d’exécution de 30 tâches de développement logiciel réalisées par le framework ChatDev avec le GPT-5 reasoning model, puis mappe ses étapes internes en conception, codage, complétion de code, revue de code, test et documentation
  • Les résultats préliminaires montrent que l’étape itérative de revue de code représente en moyenne 59,4 % des tokens, soit la plus grande part de consommation
  • Les tokens d’entrée représentent en moyenne 53,9 %, la part la plus importante de manière constante, fournissant une preuve empirique d’inefficacités significatives possibles dans la collaboration entre agents
  • Dans l’ingénierie logicielle agentique, le coût principal se concentre non sur la génération initiale de code, mais sur les processus automatisés d’amélioration et de vérification
  • La méthodologie peut servir à la prévision des coûts, à l’optimisation des workflows et à la recherche sur des protocoles de collaboration entre agents plus économes en tokens

Introduction

  • L’ingénierie logicielle à grande échelle explore des systèmes multi-agents basés sur des LLM pour automatiser des tâches complexes sur l’ensemble du SDLC
  • Les frameworks LLM-MA simulent des rôles d’équipes humaines, comme chef de produit, architecte, développeur et testeur, via des agents LLM spécialisés qui collaborent sur la conception, le codage et la validation
  • En principe, les systèmes LLM-MA peuvent répartir le travail entre agents pour accroître l’autonomie et la robustesse
  • Des travaux antérieurs montrent que les systèmes LLM-MA peuvent favoriser la pensée divergente, renforcer le raisonnement et la factualité, et s’étendre à des problèmes dépassant les capacités d’un agent unique
  • En ingénierie logicielle, ils offrent la possibilité d’automatiser de manière intégrée des workflows de bout en bout, des exigences jusqu’aux tests
  • Le framework AGENTTAXO fournit une taxonomie pour analyser la distribution des tokens dans les systèmes LLM-MA généraux et introduit la notion de « communication tax » pour décrire le surcoût des interactions entre agents
  • La taxonomie d’échec MAST confirme qu’une grande partie des problèmes des systèmes LLM-MA provient non des limites d’un LLM individuel, mais de problèmes de conception et de coordination du système, comme la répétition d’étapes ou une validation incomplète
  • Les recherches existantes ont analysé le comportement des agents dans des contextes généraux, mais il subsiste un manque de connaissances sur l’efficacité des ressources dans les systèmes appliqués à des workflows d’ingénierie logicielle en plusieurs étapes
  • La question clé pour une adoption pratique — « où vont les tokens ? » — reste encore insuffisamment traitée dans le domaine de l’ingénierie logicielle
  • Tokenomics désigne l’étude de l’efficacité opérationnelle et de la consommation de ressources des systèmes LLM-MA
  • L’analyse observe la distribution de la consommation des tokens en mappant les étapes internes de ChatDev à des phases du développement logiciel
  • ChatDev simule une entreprise logicielle virtuelle dans laquelle plusieurs rôles d’agents, comme programmeur et testeur, accomplissent le SDLC à travers des conversations multi-tours
  • L’étude fournit un jeu de données curé de 30 traces d’exécution ainsi qu’un package de réplication complet

Conception de l’étude

  • Objectif et objet d’analyse

    • L’objectif est d’examiner empiriquement comment se répartit la consommation de tokens lorsqu’un système LLM-MA réalise une tâche de développement logiciel de bout en bout
    • L’analyse initiale porte sur ChatDev
    • L’architecture « chat chain » de ChatDev représente un modèle séquentiel clair en cascade, de la conception au codage puis aux tests, avec des étapes nettement délimitées, ce qui la rend adaptée au mapping vers les phases du développement logiciel
    • ChatDev est l’un des frameworks open source populaires et largement cités

  • Curation du jeu de données

    • ChatDev a été exécuté sur 30 tâches de développement logiciel différentes
    • Les prompts ont été collectés à partir du ProgramDev Dataset utilisé dans l’étude MAST
    • Les prompts sélectionnés vont d’algorithmes simples comme la génération de nombres de Fibonacci à des applications plus complexes comme un jeu d’échecs
    • La diversité a été vérifiée à partir de travaux récents suggérant que le nombre de tokens de raisonnement peut servir de proxy de la complexité d’une tâche
    • La consommation de tokens de raisonnement sur les 30 tâches va de 17 280 à 40 000, ce qui suggère une diversité suffisante de complexité pour l’étude
    Publicité

  • Choix du modèle

    • Le modèle de base utilisé pour tous les agents est le GPT-5 reasoning model
    • Les critères de sélection sont sa popularité, sa récence, son adéquation aux cas d’usage agentiques et ses fortes capacités de raisonnement, conformes aux attentes vis-à-vis d’agents autonomes
    • La version de modèle utilisée dans l’expérience est gpt-5-2025-08-07
    • Le paramètre temperature n’étant pas pris en charge par ce modèle, la valeur par défaut 1.0 a été utilisée
    • La fenêtre de contexte est de 400 000 tokens, avec un maximum de 128 000 tokens en sortie
    • La date de coupure des connaissances est le 30 septembre 2024

  • Pipeline d’analyse

    • Lors de l’étape de collecte des traces, ChatDev a été instrumenté afin d’enregistrer dans les logs la trace d’exécution complète de chacune des 30 tâches
    • Les prompts, réponses et nombres de tokens d’entrée, de sortie et de raisonnement de chaque appel LLM ont été capturés
    • Le mapping des étapes constitue la méthodologie clé qui transforme les étapes internes du framework ChatDev en phases de développement universelles
    • Cette abstraction permet une analyse généralisable et peut être étendue à d’autres frameworks LLM-MA d’ingénierie logicielle
    • L’agrégation des tokens a été effectuée par des scripts Python
    • Les traces collectées ont été parsées, puis le nombre de tokens a été additionné par phase de développement sur l’ensemble des 30 exécutions
    • Les résultats ont été ventilés entre tokens d’entrée, de sortie et de raisonnement

  • Mapping entre étapes internes de ChatDev et phases de développement

    • La phase de conception correspond à DemandAnalysis et LanguageChoose, centrées sur la compréhension des exigences et les décisions technologiques de haut niveau
    • La phase de codage correspond à Coding et intervient directement dans la rédaction du code source initial
    • La phase de complétion de code correspond à CodeComplete et achève les placeholders ou fichiers de code inachevés laissés à l’étape de codage
    • La phase de revue de code correspond à CodeReview et met en œuvre une conversation itérative entre un agent programmeur et un agent relecteur pour examiner, corriger et améliorer le code
    • La phase de test correspond à Test et se concentre sur les tests dynamiques du système pour trouver et corriger des bugs affectant l’exécutabilité
    • La phase de documentation correspond à EnvironmentDoc, Reflection et Manual, qui génèrent le manuel utilisateur et la documentation des dépendances d’environnement nécessaires

Résultats et discussion

  • Question de recherche

    • La question centrale porte sur les schémas de consommation de tokens des systèmes LLM-MA dans les tâches de développement logiciel
    • Comprendre la tokenomics des systèmes d’ingénierie logicielle agentique est essentiel pour une adoption pratique et durable
    • Une forte consommation de tokens se traduit directement par une hausse des coûts financiers, de la consommation énergétique et de l’impact environnemental
    • Identifier où les tokens sont consommés dans le SDLC permet de construire une « carte des coûts » exploitable pour la prévision budgétaire et l’optimisation des workflows
    • L’analyse suit deux axes
    • la distribution totale des tokens par phase de développement mappée, comme la conception ou le codage
    • la proportion de tokens d’entrée, de sortie et de raisonnement au sein de chaque phase
    Publicité

  • Constat 1 : la revue de code domine la consommation de tokens

    • L’usage des tokens au cours du développement présente une distribution très inégale
    • La phase de revue de code consomme en moyenne 59,4 % des tokens sur l’ensemble des 30 tâches, ce qui en fait la plus coûteuse
    • La phase de complétion de code est apparue dans 6 tâches sur 30 et a consommé en moyenne 26,8 % des tokens dans ces exécutions
    • La phase de documentation consomme en moyenne 20,1 % des tokens, et la phase de test 10,3 %
    • La phase de test est apparue dans 12 tâches sur 30
    • Le codage initial ne représente en moyenne que 8,6 %, et la conception 2,4 %, soit des coûts relativement faibles
    • Le coût principal de l’ingénierie logicielle agentique se concentre donc sur des processus itératifs et conversationnels d’amélioration et de vérification, plutôt que sur la génération initiale du code
    • La valeur n dans la figure indique le nombre de tâches, parmi les 30, dans lesquelles une phase donnée a été exécutée
    • Toutes les phases ne sont pas exécutées systématiquement, car les agents du système multi-agents décident de manière autonome quelles phases lancer
    • Les barres d’erreur indiquent ±1 écart-type et représentent la variabilité de la consommation de tokens pour chaque phase

  • Constat 2 : la consommation de tokens est centrée sur les tokens d’entrée

    • Dans toutes les phases sauf le codage, les tokens d’entrée dépassent nettement les tokens de sortie et de raisonnement
    • En moyenne sur les tâches, la composition globale de la consommation est de 53,9 % en entrée, 24,4 % en sortie et 21,6 % en raisonnement
    • Le ratio d’environ 2:1 entre tokens d’entrée et de sortie constitue un fort appui empirique à la notion de « communication tax » décrite dans les travaux antérieurs
    • Les agents consomment des tokens en se retransmettant à répétition de grands contextes dans leurs échanges collaboratifs
    • Les protocoles actuels de collaboration entre agents présentent ainsi une inefficacité où la majorité des tokens est dépensée à transmettre le contexte plutôt qu’à produire de nouveaux résultats
    • La communication tax pourrait être une caractéristique intrinsèque des architectures conversationnelles multi-agents et mérite des recherches complémentaires

  • Constat 3 : des profils tokenomics différents selon les phases de développement

    • Les ratios de tokens par phase forment des schémas propres à chaque activité d’ingénierie logicielle
    • La phase de codage constitue une exception centrée sur la sortie, avec 58,0 % de tokens de sortie contre 6,9 % de tokens d’entrée
    • Cette structure centrée sur la sortie correspond à la nature de la tâche, qui consiste à produire un code source long à partir de spécifications de conception concises
    • Les phases de vérification et de documentation, comme la revue de code et la documentation, sont au contraire centrées sur l’entrée
    • La part d’entrée est de 51,4 % pour la revue de code
    • La part d’entrée est de 80,2 % pour la documentation
    • Ces phases consomment du code existant comme grand contexte et produisent des sorties analytiques plus courtes
    • Les profils de tokens par phase peuvent servir de carte des coûts selon le type d’activité d’ingénierie
    • Les praticiens peuvent ainsi mieux repérer les opportunités de prévision des coûts et d’optimisation des processus

  • Ratios de tokens par phase

    • Le ratio moyen de la phase de conception est de 60,4 % en entrée, 3,6 % en sortie et 36,0 % en raisonnement
    • Le ratio moyen de la phase de codage est de 6,9 % en entrée, 58,0 % en sortie et 35,1 % en raisonnement
    • Le ratio moyen de la phase de complétion de code est de 47,7 % en entrée, 41,7 % en sortie et 10,5 % en raisonnement
    • Le ratio moyen de la phase de revue de code est de 51,4 % en entrée, 24,7 % en sortie et 23,9 % en raisonnement
    • Le ratio moyen de la phase de test est de 60,8 % en entrée, 20,7 % en sortie et 18,4 % en raisonnement
    • Le ratio moyen de la phase de documentation est de 80,2 % en entrée, 8,3 % en sortie et 11,5 % en raisonnement
    • Le ratio moyen global par tâche est de 53,9 % en entrée, 24,4 % en sortie et 21,6 % en raisonnement
    Publicité

  • Discussion

    • Ces résultats préliminaires fournissent une première carte des coûts du développement logiciel agentique
    • Le coût élevé en tokens de la phase de revue de code peut être interprété comme un « coût de conversation »
    • Ce coût découle directement de l’architecture conversationnelle des systèmes LLM-MA, où les agents s’échangent de manière répétée l’intégralité du contexte du code afin de l’améliorer
    • Les protocoles actuels de collaboration entre agents pour la validation sont très inefficaces et peuvent consommer d’énormes ressources même lorsque seules de petites corrections sont nécessaires
    • Cela s’aligne aussi avec les résultats de la taxonomie MAST sur les échecs de validation et la répétition d’étapes
    • Une forte consommation de tokens peut être le symptôme d’un système agentique qui tente de surmonter par des dialogues forcés des problèmes de coordination qui lui sont inhérents
    • Les praticiens peuvent estimer le coût de projets basés sur des agents en fonction du type de travail requis
    • Un projet greenfield dominé par le codage initial et un projet centré sur le refactoring ou le débogage d’un code existant n’ont pas la même structure de coûts
    • Dans les projets centrés sur le refactoring ou le débogage d’un code existant, ce sont les cycles de revue de code, coûteux et centrés sur l’entrée, qui dominent les dépenses
    • Intégrer un checkpoint « human-in-the-loop » avant la phase de revue de code peut aider à éviter des boucles itératives coûteuses et orienter des choix de conception plus efficaces économiquement et computationnellement
    • Un enjeu de recherche majeur consiste à concevoir des protocoles de collaboration plus économes en tokens pour la validation et l’amélioration
    • Il faut aller au-delà de la simple transmission du contexte complet
    • Un cadre d’évaluation standardisé et complet est également nécessaire
    • Un tel cadre pourrait servir de base commune pour benchmarker et comparer l’efficacité d’architectures LLM-MA différentes, comme le workflow hiérarchique conversationnel de ChatDev et la chaîne de production fondée sur des SOP de MetaGPT
    • Il pourrait aussi jouer le rôle de « pierre de Rosette » traduisant les comportements propres à chaque framework en activités universelles d’ingénierie logicielle

Menaces sur la validité et travaux futurs

  • Menaces sur la validité

    • L’analyse repose sur un seul système LLM-MA, ChatDev, et sur un seul LLM, le GPT-5 Reasoning Model
    • Les schémas de consommation de tokens observés peuvent différer avec d’autres architectures LLM-MA ou d’autres LLM plus ou moins efficaces en tokens
    • Les 30 tâches de développement logiciel sont diverses, mais elles ne représentent peut-être pas l’ensemble des scénarios et niveaux de complexité possibles
    • La taille réduite du jeu de données curé découle directement de l’absence de benchmark public à grande échelle sur des traces d’agents spécialisés en ingénierie logicielle
    • La curation des données est un processus long et coûteux
    • Certaines phases de développement n’ont été exécutées que sur un petit sous-ensemble des 30 tâches
    • La complétion de code (n=6) et les tests (n=12) sont déclenchés rarement
    • Les conclusions sur le profil tokenomics de ces phases particulières reposent donc sur de petits échantillons, ce qui peut limiter leur représentativité et leur généralisation
    • Le mapping des étapes internes de ChatDev vers les phases du développement logiciel reste une abstraction
    • Il s’agit d’un mapping logique et utile pour construire un cadre d’évaluation standardisé, mais ce n’est qu’une possibilité parmi plusieurs pour relier les activités des agents

  • Conclusion et travaux futurs

    • Dans l’ingénierie logicielle agentique, le coût en tokens n’est pas réparti uniformément et se concentre massivement sur la phase itérative et conversationnelle de revue de code
    • Les tokens d’entrée, qui constituent la « communication tax », représentent la majorité de l’usage total des tokens et forment la principale cible d’optimisation future
    • Un premier axe de travail futur consiste à étendre le jeu de données à davantage de tâches afin d’améliorer la généralisabilité
    • Un deuxième axe consiste à étendre l’analyse à d’autres LLM afin d’identifier les effets propres aux modèles
    • Un troisième axe consiste à étendre l’analyse à d’autres systèmes LLM-MA afin de comparer l’impact des différences architecturales sur la tokenomics
    • Un quatrième axe consiste à étudier la relation entre les schémas de consommation de tokens et les modes d’échec
    • Un cinquième axe consiste à poursuivre le développement et la validation d’un cadre robuste et universel de mapping des phases de développement pour benchmarker l’efficacité des agents d’ingénierie logicielle

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Hacker News

  • J’utilise à titre personnel un système multi-agents
    Quand on lui donne un problème, un modèle rapide et peu coûteux pose d’abord des questions, puis affine le prompt d’entrée à partir des réponses
    Ensuite, il choisit une stratégie du type découper le problème en sections puis laisser un juge final trancher, ou faire débattre plusieurs agents avant qu’un juge ne résume
    La meilleure approche est ce que j’appelle all angles : plusieurs stratégies tournent en parallèle et un méta-juge final synthétise les réponses
    La fonctionnalité ajoutée récemment que je trouve la plus utile est un écran permettant de voir les écarts entre les stratégies
    Je m’en sers pour des sujets de vie courante comme la recherche de logement, l’école ou les questions familiales

    • Une démo vidéo de ce que j’ai construit est ici : https://streamable.com/e49cgt
    • Tu as évoqué le coût ; je serais curieux d’avoir plus de détails sur la structure de coût approximative selon les types de problèmes
      J’aimerais aussi savoir quelles stratégies tu utilises et comment les coûts varient selon chacune
    • Je serais aussi curieux de savoir quel harnais d’exécution tu utilises, et quels LLM tu emploies
    • J’ai construit un système similaire, mais en me concentrant davantage sur les boucles de feedback que sur l’amélioration exploratoire des prompts
      Dans un esprit cybernétique, j’agrandis en continu une bibliothèque de vérifications déterministes et de corrections automatiques afin de maintenir la stabilité des sorties des prompts
      Les “problèmes” que cette bibliothèque ne traite pas remontent alors à la personne qui pilote le processus

  • J’ai utilisé GitHub Copilot de façon soutenue pendant un mois entier, sans interruption, puis après le changement de prix j’ai épuisé tous mes tokens en deux jours le mois suivant
    Un changement aussi brutal donne l’impression que le prix des tokens est arbitraire et que le business de l’IA manque rapidement d’argent

    • J’y vois plutôt le résultat d’une volonté de pousser la valorisation maximale ou une IPO
      Il se murmure même que les marges sur l’inférence dépassent 70 %
      Si on prend SpaceX comme exemple, ils ont globalement augmenté les prix des produits grand public ces six derniers mois, mais Alphabet et Anthropic paient ensemble plus de 2 milliards de dollars par mois, donc ce n’est pas un problème de manque d’argent
      Microsoft/GitHub, qui se contentait de reconditionner le produit d’autrui, est simplement celui qui a perdu de l’argent dans l’histoire
    • Le cas de GitHub ressemble surtout à une exception qui paraît particulièrement brutale parce qu’il y a eu récemment un changement de politique tarifaire
      En général, les prix sont fixés selon divers facteurs sous-jacents ; cela ne veut pas dire qu’ils sont arbitraires en soi
      Par exemple, si les dirigeants de GitHub avaient utilisé un générateur de nombres aléatoires pour fixer le prix des tokens, là ce serait une tarification arbitraire

  • Il y a ce passage disant que « les tokens d’entrée représentent en moyenne 53,9 % et constituent la part la plus importante de la consommation », mais dans mon usage le ratio est plutôt d’environ 10:1
    L’écrasante majorité des tokens consommés vient de l’entrée, et il arrive souvent qu’un agent lise un million de tokens pour corriger une seule ligne de code
    Si on est proche de 1:1, ou si la sortie est plus élevée, j’y verrais soit un problème avec l’agent, soit un codebase récent ou vide

    • Je me demande si vous avez essayé de fournir de meilleurs outils aux agents pour explorer et documenter le codebase, comme un AST ou des serveurs de langage
      Un million de tokens non mis en cache, ça paraît énorme
    • Si les tokens d’entrée dominent à ce point le coût, cela signifie qu’une meilleure utilisation du caching pourrait déjà apporter un gros gain
      On pourrait demander au modèle de faire une étape de “compression” ponctuelle en lui donnant les parties de code pertinentes, puis utiliser le résultat comme préfixe mis en cache pour de nombreux appels de sous-agents

  • Quand on utilise des agents pour coder, ils veulent souvent écrire des tests unitaires par milliers, mais sont moins enclins à tester de manière dynamique

    • Ils aiment aussi brûler énormément de tokens à écrire puis déboguer des tests cassés sur le plan sémantique
    • Les tests unitaires sont eux aussi une forme de test dynamique
      Les tests statiques, ce sont des choses comme le linting ou la vérification de types
      Si vous voulez d’autres formes de tests dynamiques que les tests unitaires, je me demande si vous avez essayé de le formuler comme une exigence dès l’étape de planification ou de PRD
    • AWS pousse lui aussi très agressivement des solutions Lambda complexes qui enchaînent le plus possible de services AWS facturables, même pour des besoins simples
      Leurs intérêts ne sont pas toujours alignés avec les vôtres
      Ici, ils veulent vous faire dépenser inutilement de l’argent pour du travail sans valeur
      Il serait peut-être temps d’arrêter aussi avec cet euphémisme qu’est le “token”
    • Il suffit de lui demander de faire davantage de tests dynamiques
      S’il y a une certaine réticence envers les tests dynamiques, c’est sans doute parce qu’ils ralentissent le processus et peuvent bloquer le logiciel à des endroits inattendus

  • Cela m’a rappelé un article de l’an dernier qui fournissait des indications budgétaires pour optimiser l’efficacité d’utilisation des tokens
    [1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Stee...

  • C’est comparable aux miles de fidélité des compagnies aériennes, et du point de vue des entreprises il n’y a aucun avantage par rapport au fait de louer du temps de GPU bare metal

    • J’espère que cette période affreuse prendra bientôt fin, avec davantage de fabricants de matériel qui sortent des NPU bon marché et des tailles de modèles mieux optimisées
      Quand l’essentiel de la demande en IA pourra être couvert par du matériel et des modèles on-premise ou on-device, je me demande bien à quoi serviront ces fermes de calcul géantes et ces modèles dont les coûts d’exploitation sont si élevés
      Il ne restera probablement que les grands gouvernements comme clients, et au final ce sont les contribuables qui paieront les dizaines de milliards investis par le cartel de l’IA

  • J’ai écrit en décembre un post Substack sur ce sujet : https://open.substack.com/pub/zacharywhitley/p/the-coming-ag...

  • Avant, des entreprises comme Google recrutaient des ingénieurs en regardant à quel point ils savaient optimiser l’infrastructure
    Bientôt, les entreprises évalueront peut-être la capacité des ingénieurs à optimiser l’efficacité des tokens d’IA

    • Cela suppose que les tokens restent durablement un coût significatif
      Il est difficile d’être certain que les développeurs trouveront de nouveaux usages à davantage de tokens aussi vite que les prix baisseront
    • Je connais une façon de ramener à zéro les coûts de tokens pour l’entreprise
      Il suffit de traiter les tokens comme une charge de service public comparable à Internet, et de faire payer directement les ingénieurs

  • Petite digression amusante : j’étais dans une réunion d’évaluation d’un nouveau produit candidat, tout se passait bien, puis un écran a montré qu’ils avaient ajouté de l’IA au produit
    Évidemment, il y avait de l’IA, et cela donnait clairement l’impression d’avoir été ajouté de force
    L’un des indices les plus flagrants était une colonne affichant combien de tokens coûtait chaque requête
    J’ai demandé qui payait ce coût de tokens ; on m’a répondu que c’était inclus dans la licence, puis j’ai demandé s’il y avait un plafond budgétaire ou si c’était illimité, et on m’a dit que c’était une bonne question et qu’ils allaient vérifier
    Si j’ai posé la question, c’est parce qu’une simple requête liée à un appareil, montrée à l’instant, avait brûlé 250 000 tokens
    C’est là qu’on a entendu l’un des cadres de l’autre camp dire à voix haute : « Pourquoi est-ce qu’on montre ça au client ? »
    On a bien ri
    La leçon à en tirer, c’est que le coût d’ajouter de l’IA à n’importe quoi n’est pas correctement calculé, et que le coût réel d’exploitation de l’IA l’est encore moins
    Tout ce qui embarquera de l’IA coûtera plus cher, qu’on le veuille ou non

    • AIshittification

  • Tokenomics est déjà un mot qui décrit l’économie des cryptomonnaies ; même si les tokens utilisés en IA sont d’une autre nature, je ne vois pas pourquoi il faudrait absolument redéfinir ce terme

    • Tokenomics est aussi un mot utilisé depuis longtemps chez les amateurs de cannabis
    • C’est la nouvelle mode
      Oublie la précédente ; celle-ci aussi finira par se démoder, donc il faut monter dans le train avant qu’il ne soit trop tard
    • cryptocurrency economics = cryptonomics
    • “Crypto” aussi existait bien avant que les cryptomonnaies ne se l’approprient
      “Web 3.0” aussi existait avant que les gens de la crypto ne transforment Web3 en concept centré sur les cryptomonnaies
      Donc je ne vois pas où est le problème
      Les termes sont constamment réemployés dans des contextes différents
      En plus, la plupart des gens sont déjà passés à autre chose côté cryptomonnaies, donc le risque de confusion n’est probablement pas très élevé