Comment le passage d’un agent IA de production à GPT-5.6 l’a rendu 2,2 fois plus rapide et 27 % moins cher

 (ploy.ai)
1 points par GN⁺ 7 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Ploy a remplacé le modèle de ses agents qui planifient, construisent et valident des sites marketing en production, passant de Claude Opus 4.8 à GPT-5.6 Sol, désormais défini comme modèle par défaut dans tous les workspaces
  • Après avoir corrigé les hypothèses propres à chaque modèle dans son harness d’évaluation, le temps d’exécution moyen pour une reconstruction de page d’accueil est passé de 8 minutes à 3 min 42 s, le coût a baissé de 27 %, de 3,06 $ à 2,22 $, et le score visuel est monté à 0,970
  • GPT-5.6 remplissait arbitrairement les 25 paramètres optionnels des appels d’outils, ce qui faisait que 52 à 64 % des lectures de fichiers renvoyaient un résultat vide ; en convertissant les champs optionnels en champs obligatoires et nullable, les lectures vides sont tombées à 0 % et les appels d’outils ont diminué d’environ 30 %
  • En raison des différences de portée de cache et de structure de débit entre OpenAI et Anthropic, GPT-5.6 paraissait au départ environ 50 % plus cher ; mais avec une clé de cache par workspace et des breakpoints par couche, le taux de hit au premier appel est passé de 0 % à 83,7 % et les tokens d’entrée non mis en cache ont baissé de 28 %
  • Le coût et les performances d’un changement de modèle dépendent non seulement du modèle lui-même, mais aussi du budget d’évaluation, du schéma des outils, de la structure du cache et de la façon de rejouer le raisonnement ; il faut donc d’abord identifier et corriger les hypothèses propres au provider intégrées au modèle existant pour obtenir des comparaisons fiables et une exploitation stable

GPT-5.6 Sol remplace Claude Opus

  • Les agents de Ploy planifient les pages de sites marketing en production, lisent la base de code, génèrent des composants et des images, vérifient le résultat via des captures d’écran, puis déterminent si la tâche est terminée
  • Pendant plusieurs mois, aucun modèle n’a atteint les critères nécessaires pour remplacer Claude Opus, et le modèle par défaut est resté successivement Opus 4.7 puis 4.8 pendant 4 mois
  • GPT-5.6 Sol est le premier à dépasser Opus lors d’une évaluation en tête-à-tête sur les mêmes tâches, et devient le modèle par défaut dans tous les workspaces Ploy
  • Dès l’évaluation initiale, le temps d’exécution des builds terminés était inférieur de plus de moitié, le coût inférieur de 27 %, avec des scores équivalents ou supérieurs à ceux du modèle existant, ce qui a justifié la migration
  • Ploy utilise le Vercel AI SDK, mais a découvert au cours du changement de modèle que des hypothèses propres au provider sur la composition des arguments d’outils, le prompt caching et le rejeu du raisonnement entre les tours restaient présentes dans toute la stack
  • La migration a avancé en corrigeant successivement le harness d’évaluation, le schéma des outils, le prompt caching, puis le rejeu du raisonnement

Corriger d’abord le harness avant de croire les métriques

  • La suite d’évaluation exécute les agents de production dans des workspaces de test figés, sur des centaines de cas allant de la reconstruction complète d’une page d’accueil à des tâches visant à déterminer si une demande de reproduction peut être exécutée sans risque
  • Dans les cas de build, un juge visuel compare le résultat au design de référence via 10 vérifications binaires
    • il vérifie si la zone hero est une scène photo occupant toute la largeur de l’écran
    • il vérifie si le CTA principal est un rectangle à coins arrondis plutôt qu’un bouton en forme de pilule
  • Des vérifications de contenu, de parcours d’exécution des outils et d’assertions sur les fichiers sont également effectuées ; en cas d’échec, l’équipe examine la trace d’exécution complète, y compris les appels d’outils et le texte du modèle

  • Des contraintes ajustées au mode d’appel de l’ancien modèle

    • Le budget d’appels d’outils existant était calibré sur le mode d’appels séquentiels d’Opus, mais GPT-5.6 utilisait des appels parallèles et dépassait donc le budget même dans des cas correctement résolus
    • L’exécuteur d’évaluation ne prenait pas en charge la lecture de fichiers par lot, presque jamais utilisée par Opus, mais fréquemment utilisée par GPT-5.6
    • Environ un tiers des échecs bruts du premier run provenaient non pas du comportement du modèle, mais des hypothèses du harness, et ils n’étaient pas répartis de façon homogène selon les modèles
    • Si l’on ne classe pas d’abord les traces d’exécution du modèle challenger et du modèle existant, l’évaluation favorise le nouveau modèle à mesure qu’il se comporte comme l’ancien

  • Des seuils de score implicites

    • Les datasets sans minScore hérita ient silencieusement de la valeur par défaut 1.0
    • À cause de cela, GPT-5.6 était marqué en échec malgré un score hero de 0.98, et Opus échouait lui aussi dans des cas ayant pourtant réussi toutes les vérifications individuelles
    • Dans les deux cas, le design pouvait être défendu, mais les résultats étaient éliminés à cause d’un seuil implicite, pas du modèle

Résultats du benchmark après correction

  • Après avoir corrigé le harness, Ploy a relancé la suite d’évaluation où il faut reconstruire une page d’accueil de marque à partir du design de référence
Moyenne par build terminé Claude Opus 4.8 (n=11) GPT-5.6 (n=10)
Coût 3,06 $ 2,22 $
Temps d’exécution 8 min 00 s 3 min 42 s
Tokens d’entrée 2,6 M 1,7 M
Tokens de sortie 33 000 17 100
Score visuel 0,936 0,970
  • GPT-5.6 a terminé les pages 2,2 fois plus vite, pour un coût inférieur de 27 %, tout en utilisant environ deux fois moins de tokens de sortie
  • La quantité de code générée était elle aussi plus faible
    • Dans un cas comparatif, Opus a généré 174 variables CSS et un globals.css de 17 957 caractères, incluant des palettes de couleurs rarement utilisées
    • GPT-5.6 n’a utilisé que 45 variables CSS et 2 508 caractères, tout en produisant un rendu similaire voire meilleur

  • Qualité et cohérence du design

    • GPT-5.6 est performant sur les layouts propres et très structurés en grille, mais tend à converger vers ce style s’il n’est pas fortement guidé
    • Dans l’ancien harness conçu pour Opus 4.8, il générait souvent des résultats propres mais banals, en ignorant le système de design existant
    • Après amélioration du guidage du modèle par les équipes design et engineering, il a atteint le niveau de conformité à la marque requis pour la production

Gestion des paramètres optionnels dans les appels d’outils

  • L’outil code de l’agent comporte 25 paramètres de premier niveau ; seul action est obligatoire, tous les autres sont optionnels
  • Claude n’envoie que les 2 ou 3 paramètres utilisés, mais GPT-5.6 envoie les 25 à chaque appel, en remplissant même les champs inutilisés avec des valeurs plausibles comme offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000"
  • Le même schéma a été observé dans les traces d’exécution de code(read) collectées en production sur 3 jours
Modèle Nombre d’appels Appels contenant les 25 propriétés
gpt-5.6 6 635 6 635, 100 %
claude-opus-4.8 2 898 4, 0,1 %
claude-sonnet-5 1 933 0

  • Pourquoi des lectures de fichiers vides se produisaient

    • Le problème n’était pas seulement la verbosité des arguments, mais le fait que l’implémentation de lecture de fichiers ne savait pas distinguer les valeurs inventées par le modèle de celles réellement voulues par l’utilisateur
    • L’implémentation traitait offset: 0 comme un argument réel, et 52 à 64 % des lectures de fichiers de GPT-5.6 renvoyaient un résultat vide
    • Comme l’outil renvoyait success: true à la fois pour les lectures valides et les lectures vides, le modèle ne pouvait pas savoir qu’il lisait des fichiers vides
    • Il multipliait alors les appels pour compenser ces résultats vides, ce qui dégradait aussi la qualité finale

  • Ce que ni le prompt ni le mode strict n’ont résolu

    • Même en ajoutant dans la description de l’outil l’instruction d’omettre les paramètres inutilisés, les 25 champs continuaient d’être générés
    • Ajouter OPTIONAL, omit if unused à chaque propriété n’a rien changé non plus
    • Le mode strict d’OpenAI donnait le même résultat et son adoption aurait obligé à retirer pattern, format et la validation de taille des tableaux de tous les schémas
    • Comme ce comportement provient de la manière dont le modèle génère les function calls, le schéma a été modifié plutôt que le prompt

  • Conversion du schéma à la frontière entre providers

    • Pour les modèles de la famille OpenAI, toutes les propriétés optionnelles ont été réécrites en propriétés obligatoires et nullable sous la forme anyOf: [T, null]
    • Le modèle remplit les paramètres inutilisés avec un null explicite, puis ces null sont retirés avant validation à la frontière commune des appels d’outils
    • L’implémentation des outils n’a pas été changée ; seul le schéma destiné au modèle a été adapté pour pouvoir représenter les valeurs non utilisées
    // Avant : les 25 clés étaient remplies avec des valeurs arbitraires
{ "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 }

// Après : 4 vraies valeurs et 21 null sont envoyés, puis les null sont supprimés avant l’exécution de l’outil
{ "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }
    • Après ce changement, les lectures de fichiers vides sont passées de 52 % à 0 %
    • Le nombre d’appels d’outils nécessaires pour une même tâche a aussi baissé d’environ 30 %, l’agent ayant cessé de relire des résultats vides

Un prompt caching adapté à la façon d’OpenAI

  • Les deux providers proposent du prompt caching, mais avec des implémentations différentes
  • Avant d’en tenir compte, GPT-5.6 paraissait environ 50 % plus cher qu’Opus, alors que la cause n’était pas le prix du modèle mais la configuration du cache

  • Le cache à l’échelle de l’organisation chez Anthropic

    • Le prompt de l’agent commence par un préfixe statique d’environ 29 000 tokens, composé du schéma des outils et du prompt système principal, identique dans toutes les conversations
    • Avec Claude, des breakpoints de cache sont marqués via cache_control, et ce préfixe est partagé à l’échelle de l’organisation
    • Toute conversation de n’importe quel workspace peut réutiliser une même entrée partagée, sans limite de débit par clé
    • Le taux de hit du cache est de 92 à 96 %

  • Le comportement du cache change avec GPT-5.6

    • Les précédents modèles GPT mettaient implicitement en cache les correspondances partielles de préfixe, mais GPT-5.6 a supprimé cette correspondance partielle
    • Comme le cache implicite construit un élément de prompt complet à partir du message le plus récent, même une nouvelle conversation partageant le même préfixe statique de 29 000 tokens obtient un taux de hit de 0 % au premier appel
    • Le préfixe entier est donc refacturé comme non mis en cache pour chaque conversation
    • Indépendamment de l’usage ou non du cache par l’application, GPT-5.6 applique une majoration de 1,25x pour écriture de cache à tous les prompts non mis en cache

  • Les contraintes des clés de cache explicites

    • Le caching explicite nécessite prompt_cache_breakpoint et un prompt_cache_key obligatoire
    • La clé fait elle-même partie de l’identité du cache : un même prompt avec une clé différente ne produira donc pas de hit
    • Chaque clé est mappée à un nœud de cache capable de traiter environ 15 requêtes par minute ; au-delà, OpenAI répartit le trafic vers d’autres nœuds disposant de caches froids indépendants
    • Le choix de la granularité de la clé devient donc une décision d’architecture essentielle
    • Clé par conversation : les nouvelles conversations ne frappaient pas le préfixe partagé, avec un taux de hit de 0 % au premier appel
    • Une seule clé globale : toutes les requêtes étaient hashées vers un seul nœud, puis débordaient vers des nœuds froids dès que le trafic dépassait 15 rpm en production
    • Clé par workspace : toutes les conversations d’un workspace client partageaient les éléments de cache, tout en gardant un trafic faible par clé

  • Un cache hiérarchique par workspace

    • La configuration finale utilise une clé par workspace sous la forme ws:{workspaceId} et découpe le prompt système en couches de breakpoints
    • L’élément A contient les outils et le préfixe statique afin de réduire le coût du premier appel d’une session
    • L’élément B ajoute le contexte du workspace au préfixe statique
    • L’élément C est la chaîne complète du prompt propre à une session, du premier tour jusqu’au message le plus récent
    • Quand la mémoire du workspace change, l’élément B ne matche plus, mais l’élément A continue à produire des hits ; seul le contexte modifié est alors réécrit, pas l’ensemble des 29 000 tokens
    • L’élément C profite du mécanisme implicite d’OpenAI sur toute la chaîne de prompt, car la structure est strictement append-only
    • En raison du partitionnement des clés chez OpenAI, le préfixe statique ne peut pas être partagé entre workspaces
    • À l’inverse, Anthropic permet ce partage grâce à un cache organisationnel sans partitionnement par clé
    • Avec GPT-5.6, chaque workspace effectue une seule écriture à froid de 29 000 tokens par période d’inactivité, pour un coût d’environ 0,18 $
    • Ce coût reste borné et prévisible

  • Résultat après correction du cache

    • Le taux de hit du cache au premier appel est passé d’environ 0 % à 83,7 %
    • Le volume total de tokens d’entrée non mis en cache a diminué de 28 %
    • Le coût par suite d’évaluation de GPT-5.6 est devenu inférieur à celui d’Opus, et l’écart de coût observé au départ provenait entièrement d’une mauvaise configuration du cache
    • Une comparaison de coûts entre modèles n’est pas valide si l’un d’eux démarre avec un cache froid et l’autre non

Rendre le rejeu du raisonnement autoportant

  • Par défaut, la Responses API de GPT-5.6 rejoue le raisonnement des tours précédents en s’appuyant sur une référence à des éléments stockés côté serveur, ce qui provoquait de manière intermittente des erreurs Item 'rs_...' not found dans les conversations de production
  • Avec store: false, le SDK demande un contenu de raisonnement chiffré et rejoue un blob autoportant plutôt qu’un pointeur vers un état serveur
  • Même si les octets envoyés par l’application ont une structure append-only, l’état de raisonnement côté serveur peut modifier le prompt effectivement valide
  • Après correction du harness d’évaluation, du schéma des outils, du prompt cache et du rejeu du raisonnement, GPT-5.6 Sol est désormais le modèle par défaut utilisé en production chez Ploy

À lire aussi

1 commentaires

 
GN⁺ 7 시간 전
Avis sur Hacker News

  • Des formules du genre « avec de tels chiffres, ça vaut le coup de migrer le modèle en production » sont trop ridicules. J’aurais aimé que la personne qui a fait écrire ce texte retouche au moins le style typique des LLM
    Cette manière d’enchaîner de courtes propositions avec des deux-points, des virgules et des points est mauvaise et pénible à lire. Il y a de bonnes intuitions, comme le fait que le cache par correspondance de préfixe partiel a disparu dans GPT-5.6, mais ce n’est pas un texte agréable à lire

    • C’est pour ça que je garde toujours un WRITING.md à côté de AGENTS.md ou CLAUDE.md. La plupart des gens disent au modèle quoi produire, mais presque jamais comment écrire, alors que les LLM suivent étonnamment bien des consignes de style explicites
      J’y mets des règles pour éviter les deux-points inutiles, les tirets longs, les fragments de phrases déguisés en emphase et les erreurs de grammaire que je fais souvent, et j’ajoute aussi Brian Kernighan et Rob Pike comme références pour une prose technique claire, conversationnelle et sans prétention. Un document ne doit pas seulement être facile à lire, il doit donner envie d’être lu
      Si vous générez souvent de la documentation, ça vaut vraiment le coup de faire consulter WRITING.md par l’agent. Le gain de lisibilité est souvent bien plus important qu’en remplaçant simplement le modèle le plus récent, et cela permet de garder un style cohérent même quand on change de modèle
    • Pour une entreprise d’IA, c’est encore pire. Cela peut seulement vouloir dire qu’elle n’utilise pas assez les modèles pour reconnaître ce style caractéristique, qu’elle ne comprend pas que c’est important, qu’elle ne saisit pas l’ensemble du contexte, ou qu’elle ne respecte pas ses lecteurs — et aucune de ces explications n’est flatteuse
    • Vous lisez mal. Il suffit de demander à un LLM de lire et de résumer selon vos préférences de style. Mieux encore, ne lisez rien vous-même et faites convertir le texte par un agent en fichier de compétences qu’il pourra réutiliser plus tard
    • Si je soupçonne qu’un texte a été écrit par un LLM, j’arrête immédiatement de le lire et je demande à l’outil LLM que j’utilise de le résumer ou de le reformuler. Au moins, ça me permet de garder un certain contrôle sur le style de sortie
    • Dans mon claude.md actuel, j’interdis l’expression « load-bearing », que Claude adore vraiment. Il l’aime tellement qu’il lui arrive d’en plaisanter dans les commentaires avec des trucs du genre « load-be…most specific »

  • J’ai déplacé vers 5.6 divers petits workflows simples qui tournaient auparavant sur 5.4-nano et mini, et j’ai globalement constaté des améliorations du même ordre que dans l’article, avec en plus une meilleure qualité sur certaines tâches de classification
    Dans beaucoup d’entreprises, ce type de mise à niveau de modèle revient en pratique à changer une seule ligne de code. Pour les workflows critiques, on utilise une excellente architecture de routage de modèles, mais ça ne vaut pas le coup de faire la même chose pour les tâches simples, sans parler des questions de fiabilité

    • Le point central de l’article, c’est justement que cette mise à niveau de modèle n’a pas consisté à changer une seule ligne de code
    • Vous utilisez quel SDK ? Ou bien c’est du maison ?
    • Le but initial de notre usage de Sol était d’évaluer 5.6 dans nos workflows. Avant, la qualité des modèles simples était insuffisante, donc on utilisait 5.5 pour toutes les tâches ; maintenant, on analyse ensemble texte et images pour extraire des données structurées explicites et implicites à partir de données sources désordonnées
      Globalement, ça fonctionne comme annoncé. En envoyant actuellement la plupart de nos tâches vers terra, on a réduit les coûts de moitié et amélioré les temps de réponse de 50 %. luna sert à compléter les résultats de détection OpenCV ; ses capacités sont très limitées, mais c’est rapide et presque gratuit. Dans nos cas d’usage, Sol n’était que légèrement meilleur que terra
      Sol ultra a aussi très bien fait l’évaluation elle-même. Il a produit un gros dossier avec des recommandations raisonnables, une liste de sorties à vérifier et comparer manuellement, les données brutes et transformées, ainsi que le CPM par requête. En le laissant tourner quelques heures sans rien dépenser au-delà de l’abonnement Pro, on a obtenu des coûts inférieurs de 50 % et un débit supérieur de 100 %

  • Mon expérience est similaire. Les services qui mettent en avant le basculement en cas de panne comme OpenRouter sont presque inutiles en dehors des tests en sandbox. En production, les modèles ne sont pas réellement interchangeables, et les environnements d’exécution qui font tourner de vrais agents dépendent de bien plus de spécificités propres à chaque modèle qu’on ne l’imagine
    Même si un autre modèle fonctionne sans erreur, performance et efficacité sont un autre sujet. Certains modèles, comme la famille Claude, demandent d’ajuster le prompt système au style d’expression auquel ils ont été habitués pendant l’entraînement, tandis que d’autres marchent mieux avec d’autres délimiteurs. Si la performance optimale compte, il faut considérer l’environnement d’exécution, le prompt et le modèle comme un seul système, et non comme des pièces librement interchangeables

    • Dans le cadre du LLMOps, il faut construire un véritable plan de basculement qui vérifie correctement les chemins d’exécution des outils, entre autres. Cela permet alors de mettre en place le basculement souhaité en ordonnant des modèles suffisamment bons du moins cher au plus cher
      J’ai déjà vu des tableaux de correspondance du type model -> {{prompts}, {tools descriptions}, ...}, mais c’est trop extrême. À partir d’un certain point, c’est au modèle de s’adapter à nos prompts ; sinon, il suffit de l’exclure des candidats au basculement et de ne pas lui envoyer de requêtes API
    • OpenRouter ne bascule pas vers un autre modèle, mais vers un autre fournisseur du même modèle

  • Il y a quelque chose d’ironique à voir, sous un article rempli d’enseignements profonds sur l’infrastructure, la moitié des commentaires ne critiquer que le style artificiel. Même si Claude a aidé à lisser les phrases, si le texte contient un plan directement exploitable pour réduire un budget API de 30 % et corriger les lectures de fichiers vides, n’est-ce pas cela le plus important ?

    • Certaines personnes détestent tout ce qui touche à l’IA et cherchent la petite bête, mais d’autres ne supportent peut-être vraiment pas ce style au point de ne voir que ça
      Personnellement, je trouve un peu ridicule de se plaindre du style. Comme je suis faible en grammaire et en orthographe, je me concentre davantage sur le contenu essentiel — les concepts, les faits, le raisonnement — que sur la manière de les présenter. La grammaire et l’orthographe ne sont que les arbres ; le sujet, c’est la forêt
      Si mes textes n’ont pas trop d’erreurs, c’est grâce à la dictée et à des raccourcis que j’ai créés moi-même. Ils corrigent le texte sélectionné avec un LLM local puis le remplacent, et peu d’outils ont autant amélioré ma qualité de vie et la qualité de mon écriture que ces deux-là

  • « À partir d’aujourd’hui, l’agent Ploy utilise GPT-5.6 Sol, dévoilé ce matin » : ils ont donc basculé après à peine une demi-journée de tests ? L’entreprise est dirigée par des ados ?

    • En réalité, l’équipe ressemble davantage à un effectif de niveau Staff et Senior Staff. Grâce à leur relation avec YC, ils ont testé pendant environ une semaine un modèle de prévisualisation de GPT-5.6 et fourni des retours
      Les évaluations s’exécutent dans GitHub CI, et l’ensemble de plus de 115 jeux d’évaluation portant sur les tâches de web design et de marketing, spécialité de ploy.ai, peut être lancé en totalité en environ 15 minutes. Après activation du modèle via les feature flags de PostHog, ils ont surveillé activement les échecs
      Ils veulent transférer au maximum dans Ploy les connaissances acquises en exploitant Webflow, qui supportait plus de 1 % d’Internet, afin de soutenir une plus grande part encore du web
    • Il est tout à fait possible qu’ils aient reçu un certain niveau d’accès anticipé pour effectuer des évaluations leur permettant d’écrire ce genre de billet
    • Aujourd’hui, il est assez facile de construire des évaluations et des benchmarks puis de les exécuter sur les derniers modèles. Comme les LLM se remplacent facilement, un bon jeu d’évaluation est très utile, et parfois l’amélioration est si évidente qu’il n’y a même pas besoin d’évaluer
    • On peut supposer qu’ils disposent d’un jeu de données basé sur la production pour comparer les nouveaux modèles

  • On dit que l’agent Ploy crée et modifie de vrais sites web marketing, fait de la planification, lit le codebase, écrit des composants, génère des images, capture lui-même ses résultats et décide si le travail est terminé ; même sans tests rigoureux, on peut s’attendre à ce que Fable soit bien meilleur qu’Opus pour créer des sites marketing. Il est clairement bien meilleur aussi pour produire des supports de présentation

    • En design, GPT-5.6 est bien meilleur que Fable
    • 4.7 a tendance à suivre les consignes de façon trop littérale, donc le résultat dans l’article original paraît lui aussi tout à fait plausible

  • La solution consistant, uniquement pour les modèles OpenAI, à rendre tous les attributs optionnels obligatoires tout en autorisant null avec anyOf: [T, null] sent mauvais. Je n’ai utilisé qu’une forme modifiée de MCP, mais il n’est pas clair pourquoi les définitions de types TypeScript influencent le JSON Schema envoyé par l’agent au backend d’inférence
    La spécification MCP définit explicitement un champ pour représenter les paramètres optionnels ; il semble donc y avoir un bug quelque part entre la couche TypeScript et la description d’outil réellement transmise. Il se peut aussi que le backend d’inférence soit passé de « générer une réponse d’outil valide » à « générer une réponse valide conforme à un JSON Schema sans paramètres optionnels », mais impossible d’en juger sans voir les requêtes réelles

    • Ce n’est ni un problème de génération de schéma ni un bug TypeScript, c’est un comportement interne du function calling d’OpenAI. Les poids fine-tunés pour l’usage d’outils essaient de produire des structures de données aussi complètes que possible. Quand le modèle voit des noms de paramètres dans le contexte du prompt système, il tend à remplir des valeurs même s’ils ne figurent pas dans le tableau required
    • Les modèles de pointe récents, dont Fable, Opus et 5.6, sont assez permissifs dans les appels d’outils et ne respectent pas toujours strictement le schéma. On peut voir sur https://lucumr.pocoo.org/about/ un exemple où un modèle Claude invente des propriétés inexistantes dans les appels des outils d’édition et de remplacement de Pi
      Une partie de la cause semble liée au fait que le constrained decoding réduit l’intelligence du modèle. La validité du schéma est garantie, mais les capacités chutent fortement ; cela peut convenir pour la classification, le résumé ou l’amélioration de prompt, mais il faut être prudent pour les boucles agentiques
      Des environnements d’exécution comme Claude Code effectuent beaucoup de prétraitement, de récupération et de nettoyage, mais cela reste généralement invisible. En pratique, il est souvent plus simple et plus efficace de rendre l’environnement d’exécution plus souple et de l’adapter aux caractéristiques de chaque modèle, plutôt que de supposer et d’imposer une exactitude parfaite. Les modèles changent aussi tous les un ou deux mois. C’est ça, l’IA applicative bricolée à l’intuition

  • J’aimerais connaître un ordre de grandeur du coût réel pour créer un site avec Opus et avec Sol, respectivement

  • En déplaçant le workflow vers Reasonix et en exploitant les cache hits sur DeepSeek, le coût des requêtes est devenu quasiment gratuit, même en utilisant un fournisseur américain non subventionné

    • Quelle configuration utilisez-vous, et par rapport à Pi, qu’est-ce que ça donne ?

  • Au lieu d’utiliser GPT-5.6 Sol par défaut sur tous les espaces de travail Ploy, il vaudrait peut-être la peine d’envisager Luna pour certaines tâches qui manipulent de vrais outils. C’est étonnamment compétent et rapide
    Sol excelle pour dialoguer avec les humains et orchestrer les appels d’agents, mais il est trop cher pour être utilisé partout. Pour le prix d’une exécution de Sol, on peut lancer Luna cinq fois, et statistiquement la différence entre un seul échantillon et cinq est considérable

    • Si chaque étape d’une exécution de Luna a 90 % de chances d’être correcte, alors la probabilité que les cinq étapes soient toutes correctes est 0.9^5 = 0.59, soit 59 %. Une seule exécution de Sol atteint peut-être 95 % de précision. Les chiffres réels varieront, mais il pourrait être moins coûteux de faire vérifier le résultat final par Sol
    • Il y a aussi toujours le problème de l’isolement des sous-agents. Cela aide à garder un petit contexte et à rester focalisé, mais pour poursuivre leur tâche ils doivent souvent refaire eux-mêmes les recherches, ce qui consomme des tokens non mis en cache
      Selon l’intensité avec laquelle on utilise des agents pour une tâche donnée, cela peut coûter plus cher tout en donnant au final de moins bons résultats