Leçons tirées après avoir traité 500 millions de tokens GPT

• Truss a exploité des fonctionnalités centrées sur les LLM au cours des six derniers mois et a traité plus de 500 millions de tokens avec des modèles OpenAI ; l’entreprise y résume les limites rencontrées en conditions réelles sur des usages B2B de résumé, d’analyse et d’extraction de texte
• Les prompts n’étaient pas forcément plus stables lorsqu’ils contenaient beaucoup d’instructions détaillées, et pour les connaissances générales déjà maîtrisées par GPT, des consignes plus courtes et moins spécifiques donnaient parfois de meilleurs résultats
• Même sans Langchain, JSON mode, function calling ni assistants, plusieurs fonctionnalités ont été mises en production avec la seule API chat et une fonction d’extraction JSON ; le cœur du code tenait en une fonction de 40 lignes avec un peu de gestion d’erreurs et de troncature automatique
• GPT montrait des faiblesses sur le traitement de la null hypothesis comme « renvoyer une valeur vide s’il n’y a rien », ainsi que sur les sorties longues ; indépendamment de la fenêtre d’entrée de 128k de GPT-4, la sortie restait autour de 4k
• RAG et les bases de données vectorielles convenaient mal aux tâches limitées d’extraction de texte de Truss ; l’analyse, le résumé et l’extraction avec tout le contexte étaient fiables, mais les problèmes augmentaient quand l’entrée était vide ou sans information pertinente

---

Périmètre d’usage et hypothèses

• Truss a lancé quelques fonctionnalités centrées sur les LLM au cours des six derniers mois, avec un volume estimé légèrement supérieur à 500 millions de tokens
• Les modèles utilisés viennent de la famille OpenAI, et la consommation de tokens se répartit en 85 % GPT-4 et 15 % GPT-3.5
• Les données traitées sont uniquement textuelles ; cela n’inclut pas les fonctions non textuelles comme gpt-4-vision, Sora ou Whisper
• Le contexte produit est B2B, et les tâches principales sont le résumé, l’analyse et l’extraction
• 500 millions de tokens correspondent à environ 750 000 pages de texte

Les prompts peuvent mieux fonctionner quand ils sont moins spécifiques

• Lorsqu’on surchargeait les prompts d’instructions précises et de listes exhaustives sur des connaissances générales que GPT maîtrise déjà, les résultats pouvaient se dégrader
• Un pipeline devait classer des blocs de texte selon l’État américain concerné parmi les 50 États, ou le gouvernement fédéral
  • Le prompt initial plaçait dans le champ locality_id une liste des identifiants des 50 États et de federal au format JSON, puis demandait d’en choisir un
  • Cette approche fonctionnait à environ 98 % ou plus, mais les échecs restaient assez nombreux pour justifier une enquête complémentaire
• Un autre champ, name, n’était pourtant pas explicitement demandé, mais renvoyait de manière fiable le nom complet correct de l’État
  • Ensuite, le système a été modifié pour rechercher l’État à partir de la chaîne retournée dans name, et cela fonctionnait bien
• Une meilleure approche consistait à utiliser un prompt s’appuyant sur le bon sens, du type : « vous connaissez les 50 États ; renvoyez le nom complet de l’État concerné ou Federal »
• D’autres observations ont aussi été faites
  • Les échecs survenaient plus souvent avec les États commençant par M comme Maryland, Maine, Massachusetts ou Michigan
  • Lorsqu’on demandait de choisir un identifiant dans une liste, un JSON lisible avec un État par ligne prêtait moins à confusion qu’une liste continue séparée par des virgules

API et abstractions sont restées simples

• Dans ce cas d’usage, Langchain relevait surtout d’une abstraction prématurée ; même après plusieurs millions de tokens et 3 ou 4 fonctionnalités de production différentes, le fichier openai_service ne contenait toujours qu’une fonction d’une quarantaine de lignes
• En pratique, seule l’API chat a été utilisée
  • L’extraction se faisait toujours en JSON
  • JSON mode, function calling et assistants n’étaient pas nécessaires
  • Aucun system prompt n’était utilisé
  • À la sortie de gpt-4-turbo, une seule chaîne a été modifiée dans le codebase
• La majeure partie de la fonction gérait les erreurs de l’API OpenAI, comme les erreurs 500 ou les fermetures de socket
  • Ces erreurs se sont améliorées, ce qui n’a rien de surprenant compte tenu de la charge supportée par OpenAI
• La limite de longueur de contexte était gérée par une troncature automatique maison
  • Si la longueur de la chaîne dépassait model_context_size * 3, elle était tronquée
  • En présence de beaucoup de points ou de chiffres, le ratio pouvait descendre sous 1 token pour 3 caractères et provoquer un échec
  • En cas de context_length_exceeded, une nouvelle tentative était faite après troncature selon model_context_size * 3 / 1.3

Difficile de sous-estimer l’UX du streaming

• Au départ, l’idée de réduire la latence avec l’API de streaming et d’afficher à l’utilisateur des caractères qui arrivent à vitesse variable pouvait sembler gadget
• En pratique, les utilisateurs réagissaient très positivement à cet affichage de frappe à vitesse variable
• L’expérience donnait l’impression d’un moment équivalent, pour l’IA, à l’apparition de l’UX souris/cursor

Les résultats vides et les longues sorties sont des faiblesses

• La formulation « si vous ne trouvez rien, renvoyez une sortie vide » était proche du prompt qui générait le plus d’erreurs
  • Il ne s’agissait pas de ne rien afficher du tout, mais de renvoyer une représentation de valeur vide comme {value: ""}
  • Le problème tenait moins à une limite de sortie qu’à la difficulté même de déterminer la null hypothesis
• Quand GPT devait renvoyer une valeur vide, il choisissait parfois d’halluciner ; à l’inverse, lorsqu’il manquait de confiance, il renvoyait aussi trop souvent une valeur vide
• Un bug faisait que certains blocs de texte pouvaient être vides, ce qui déclenchait de fortes hallucinations
  • Des noms fictifs de boulangeries apparaissaient alors, comme Sunshine Bakery, Golden Grain Bakery ou Bliss Bakery
  • La solution a consisté à ne pas envoyer de prompt du tout lorsqu’il n’y avait pas de texte
• GPT-4 peut disposer d’une fenêtre d’entrée de 128k tokens, mais la fenêtre de sortie reste de l’ordre de 4k
  • L’expression « context window » entretient la confusion entre entrée et sortie
• Lorsqu’on demandait une liste d’objets JSON, il était difficile de dépasser 10 éléments, même pour des objets simples
  • En en demandant 15, le taux de réussite était estimé à seulement environ 15 %
  • Même lorsque le modèle s’arrêtait autour de 10 éléments, la sortie ne représentait pourtant qu’environ 700 à 800 tokens
• Il est possible de contourner cette limite en demandant les éléments un par un puis en réinjectant les résultats précédents, mais cela revient à jouer au téléphone arabe avec GPT et à manipuler des outils comme Langchain

RAG et les bases vectorielles ne conviennent pas bien à ce cas d’usage

• Dans le cas de Truss, les bases de données vectorielles et RAG/embeddings étaient le plus souvent peu utiles
• Les bases vectorielles et RAG semblent mieux adaptées à la recherche, en particulier à de la vraie recherche façon Google ou Bing
• Le problème central est celui du critère de pertinence
  • Il n’existe pas de seuil de pertinence clairement défini
  • Il peut y avoir des approches comme le rerank de Cohere ou des heuristiques maison, mais elles ne sont pas stables
  • On risque soit de polluer les résultats avec des éléments non pertinents, soit de fixer un seuil trop conservateur et de manquer des résultats importants
• Stocker les vecteurs dans une base spécialisée et propriétaire séparée des données générales entraîne aussi une perte
  • À moins d’être à l’échelle de Google ou Bing, la perte de contexte ne justifie pas ce compromis
• Dans les applications métier, les utilisateurs sont souvent des experts du domaine
  • Ils n’apprécient pas forcément une recherche sémantique qui devine et renvoie un sens qu’ils n’ont pas explicitement saisi
• Dans la plupart des cas de recherche, il peut être préférable d’utiliser un LLM via un prompt de completion classique pour convertir la requête utilisateur en faceted search, requête complexe ou SQL
  • Cette approche n’est pas du RAG

Les hallucinations diminuent fortement quand le contexte est suffisant

• Dans la plupart des usages chez Truss, on fournit un bloc de texte à partir duquel il faut extraire quelque chose
• Si on demande les noms d’entreprises mentionnées dans le texte, GPT ne renvoie généralement pas des entreprises arbitraires
  • En revanche, si le texte ne contient aucune entreprise, le problème de la null hypothesis réapparaît
• En code aussi, GPT n’a généralement pas tendance à halluciner au sens de réécrire un bloc de code fourni en inventant des variables ou en ajoutant au hasard des fautes de frappe au milieu
  • En revanche, si on lui demande de créer quelque chose, il peut inventer l’existence de fonctions de bibliothèque standard
  • Là encore, cela ressemble surtout à une incapacité à dire « je ne sais pas »
• Lorsqu’on fournit tout le contexte et qu’on demande une analyse, un résumé ou une extraction, les résultats étaient très fiables
• Le schéma se rapproche d’une logique où de bonnes données d’entrée produisent de bonnes réponses GPT en tokens

Jugement sur les perspectives à venir

• Avec les transformers actuels, les données d’Internet et un accès à une infrastructure valant des dizaines de milliards de dollars, l’auteur estime qu’on n’atteindra pas l’AGI
• GPT-4 n’est pas un simple produit marketing mais une technologie utile à 100 %, encore à un stade comparable aux débuts d’Internet
  • Ce n’est pas une technologie qui va licencier tout le monde
  • Elle abaisse fortement les barrières d’entrée du ML/IA, auparavant accessibles surtout à Google
• Claude, Gemini et les autres n’ont pas fait l’objet de tests A/B rigoureux
  • Mais en les essayant au quotidien pour coder, ils ne semblaient pas aussi proches de GPT-4 dans cette subtile capacité à deviner l’intention
• Il n’est pas forcément nécessaire de suivre toute l’actualité LLM/IA
  • À la lumière de The Bitter Lesson, si l’amélioration des performances des modèles généraux compte davantage que les optimisations spécialisées, il suffit surtout de surveiller la sortie de GPT-5
  • En dehors de domaines séparés comme Sora, les releases intermédiaires d’OpenAI relèvent selon lui surtout du bruit
• GPT-5 a plus de chances d’apporter des améliorations incrémentales qu’un bouleversement total
  • Lors du passage de GPT-3 à GPT-3.5, l’auteur s’attendait à une amélioration superlinéaire, comme un doublement de l’intensité d’entraînement produisant des performances 2,2 fois supérieures
  • En pratique, cela ressemble davantage à une amélioration logarithmique, avec un coût par token et une vitesse de traitement qui augmentent de manière exponentielle pour obtenir des gains progressifs
• GPT-4 est peut-être le point optimal pour l’ensemble actuel des tâches
  • L’auteur était prêt à payer GPT-4 20 fois plus cher que GPT-3.5, mais pense ne pas être prêt à payer 20 fois plus par token pour passer de GPT-4 à GPT-5
  • GPT-5 pourrait démentir cela, ou n’être qu’un saut comparable à celui de l’iPhone 4 vers l’iPhone 5

[GN⁺]

Commentaires Hacker News

• L’équipe dont je m’occupe traite plus de 5 milliards de tokens par mois, et ça continue d’augmenter ; voici quelques enseignements
  D’abord, il y a trop d’abstractions trop précoces. Des outils comme Langchain pourront peut-être être utiles un jour, mais au final un prompt n’est qu’un appel d’API, et il est plus simple de traiter les appels à des LLM comme du code standard, à la manière d’appels d’API peu fiables, plutôt que comme quelque chose de spécial
  Ensuite, les hallucinations sont clairement un gros problème. Les résumés sont assez robustes dans nos tests, mais le raisonnement est vraiment difficile, et les modèles d’action où le LLM reçoit l’entrée utilisateur et décide de l’action suivante sont particulièrement compliqués, surtout pour la compréhension du contexte et pour lui faire dire « je ne suis pas sûr ». Malgré tout, le simple fait que ce soit possible change la donne
  Troisièmement, je suis un peu plus du côté « ça change la donne » que l’auteur, mais je ne pense pas que ce soit la fin du monde. Certains métiers seront fortement touchés, et on risque de traverser quelques années pénibles avec des bots qui manipulent l’opinion sur les plateformes. Globalement, cela ressemble moins à une percée comme Internet qu’à un amplificateur de capacités
  Personnellement, cela me rappelle les changements DevOps des années 2000. On n’a plus besoin d’une énorme équipe dédiée pour aider aux déploiements ; on recrute quelques experts et, pour le reste, on achète des solutions existantes. De la même manière, certaines tâches de machine learning deviennent faciles à mettre en œuvre même pour des développeurs web comme moi

  • Cette analogie est utile pour expliquer ce qu’on peut attendre des LLM dans les workflows de développement modernes. Elle montre bien qu’il ne s’agit pas d’une solution miracle, mais d’un compromis
    L’évolution du DevOps avait aussi ses compromis. Par exemple, le simple « il suffit d’utiliser AWS RDS » a directement entraîné la disparition de compétences clés comme l’administration de bases de données, et les factures cloud ont explosé. Même les coûts d’exploitation des startups, surtout quand elles n’ont ni gros volumes de données ni forte complexité régionale, ont augmenté, et je pense que cette tendance a aussi conduit à des incidents comparables à la grosse panne de GitLab
  • Faire dire « je ne suis pas sûr » relève davantage de la fonction propre du modèle de langage. Au moment où il arrive à la sortie, l’incertitude inhérente au calcul a disparu dans la prédiction
    C’est un peu comme si on vous demandait de deviner pile ou face et que vous répondiez « face » : avant de répondre, vous pouvez parler d’une incertitude du type Pr[face] = .5, mais dans la prédiction réelle et le résultat du lancer, cette incertitude disparaît. Pour les LLM aussi, l’incertitude présente pendant le calcul disparaît dans la prédiction finale du token ; sauf si la prédiction elle-même exprime l’incertitude, il est donc peu probable qu’ils produisent « je n’ai pas compris ». Mais la raison, c’est justement qu’ils prédisent sans comprendre au départ
  • Je n’avais jamais pensé à l’analogie avec le DevOps avant, mais ça m’a paru étonnamment juste, au point que je viens d’écrire un billet à partir de cette idée : https://kenkantzer.com/gpt-is-the-heroku-of-ai
    En gros, nous utilisons GPT comme l’équivalent de PaaS/Heroku/Render pour l’exploitation de l’IA
  • Je suis d’accord avec l’idée que c’est « moins une percée comme Internet qu’un amplificateur de capacités ». Les clients ressentent eux aussi un choc des prix face au rapport coût/résultat des grands modèles. Les coûts finiront par baisser avec le temps
  • Je me reconnais dans l’idée que les résumés sont robustes mais que le raisonnement est difficile. La demande d’analogies est une approche intéressante et étonnamment utile

• Le passage « Nous extrayons toujours du JSON. Le mode JSON n’est pas nécessaire » m’intrigue. Dans mon cas, ça a plutôt bien marché
  La phrase « Lesson 4: GPT est vraiment mauvais pour formuler l’hypothèse nulle » me parle énormément. Hier encore, je testais un prompt de règles de modification de texte et j’avais ajouté à la fin : « si aucune règle ne s’applique au texte, renvoie le texte original sans modification »
  Vous savez ce que ChatGPT a répondu sur un texte auquel aucune règle ne s’appliquait ? Exactement la chaîne : « The original text without any changes »

  • Il existe plein d’histoires sur des génies capricieux qui interprètent au pied de la lettre la formulation d’un vœu et l’exaucent de façon maudite ; c’est exactement ce qu’on a aujourd’hui. Ceux qui écrivent des prompts pour des modèles de génération d’images depuis longtemps ont déjà développé une certaine intuition, mais pour ceux qui sont arrivés avec les LLM, cela peut être assez surprenant
    Un jour, je créais pour un tarot une image de trois femmes buvant du vin dans un magnifique jardin, et j’ai ajouté « lush vegetation » à la fin du prompt ; à cause de l’ambiguïté de lush, l’image est passée d’une ambiance élégante à quelque chose qui ressemblait à des fêtardes étudiantes au nez rouge
  • Je l’ai compris comme : « notre méthode fonctionne bien, donc nous n’avons pas besoin du mode JSON ». Dans notre entreprise, c’est pareil. Cela tourne en production depuis un an et nous n’avons jamais eu besoin de changer. Nos prompts sont assez efficaces pour que GPT-3.5 produise toujours du JSON
  • Quand on voit les sites consacrés aux décorations de gâteaux ratées, on constate que les humains font eux aussi constamment ce genre d’erreurs

• Avec de meilleurs prompts, on peut utiliser des modèles moins chers
  Dire à un LLM « si tu ne trouves rien, ne renvoie rien » est une approche de niveau 0 qui lui donne une porte de sortie. Mieux vaut lui offrir une échappatoire plus souple. Par exemple : « si tu n’as pas assez d’informations pour formuler une affirmation définitive, dis-le clairement et tu peux émettre une hypothèse à condition d’en exposer les éléments de preuve et la base logique », puis lui faire évaluer sa propre réponse à la fin

  • On ne développe pas des prompts de manière abstraite. Le but d’un prompt est d’activer les représentations internes du modèle pour qu’il accomplisse au mieux la tâche
    S’il n’existe pas de méthode automatisée, il faut tester de façon répétée les réactions du modèle sur des entrées variées afin de comprendre comment il interprète la demande, où il échoue, puis combler ces failles. Il faut même vérifier si le modèle comprend ce que signifie nothing

• Je suis abonné aux trois principaux services du domaine des LLM et je leur soumets souvent le même prompt, et l’avantage penche très nettement en faveur de GPT-4. C’est surprenant même en tenant compte du fait que cela fait un an que GPT-4 est sorti et qu’il a reçu plusieurs mises à jour entre-temps
  Au moins dans mon mode d’usage, les hallucinations y sont aussi plutôt rares. À l’inverse, Claude invente assez facilement des API plausibles mais inexistantes quand il écrit du code. GPT-4 a aussi tendance à être plus obstiné et moins complaisant quand il sait qu’il a raison. Ces différences apparaissent à peine dans les métriques, il faut vraiment l’utiliser soi-même pour les voir

  • Dans mon cas, Claude 3 Opus était meilleur que GPT-4. Surtout pour les explications, et plus important encore, il est plus rigoureux
    Même pour les tâches de programmation, plutôt que de lui faire écrire du code, je lui demande des explications sur un sujet ou sur du code, et il a tendance à donner des réponses bien plus nuancées. Quand on lui donne un long texte et qu’on discute avec lui, Claude Opus donne l’impression de comprendre le contenu plus en profondeur, alors que GPT-4 reste davantage au niveau du résumé du texte fourni, tandis que Claude développe mieux son raisonnement
  • Je me demande si la comparaison a été faite avec Claude Opus ou avec une variante inférieure. Opus me plaît vraiment pour la rédaction en anglais
  • GPT-4 gère mieux les prompts mal formés, pauvres en information ou mal structurés. Si on ne structure pas intelligemment un gros prompt, Claude peut se perdre sur ce qui est demandé
    En revanche, avec des prompts bien construits, Claude Opus a tendance à produire de meilleures sorties que GPT-4. Claude est plus souple et fournit des réponses plus longues, tandis que ChatGPT/GPT-4 sonne souvent comme ses réponses courtes et « typiques »
  • Mon expérience a été l’inverse. Je suis abonné à plusieurs services et je copie-colle la même question, et sur les questions liées au développement logiciel, Claude Opus est tellement devant que je me demande si je vais encore avoir besoin de GPT-4
    Dans les exemples de code demandés, il arrivait souvent que le code généré par GPT-4 ne compile même pas, alors que cela m’est presque jamais arrivé avec Claude
  • Moi aussi, je suis abonné aux trois services et je compare de la même manière. Surtout à chaque sortie d’une nouvelle version
    Mon test décisif du moment, c’est : « Donne-moi 10 bars insolites dans un rayon de 200 miles autour d’Austin ». C’est extrêmement difficile pour tout le monde, GPT-4 s’en est approché à peu près, mais Claude a tout simplement inventé, et Gemini s’est complètement effondré

• GPT est très impressionnant, mais je ne suis pas du tout d’accord avec l’interprétation des deux paragraphes de l’article
  On peut résumer cela en disant qu’une meilleure approche aurait été quelque chose comme : « GPT, tu connais évidemment les 50 États, donc donne le nom complet de l’État correspondant, ou réponds Federal si cela correspond au gouvernement américain »
  Mais je trouve exagérée l’interprétation selon laquelle le fait que la qualité et la généralisation de GPT s’améliorent quand on formule la demande de manière plus ambiguë serait un signe typique de délégation/réflexion de haut niveau. Le langage naturel est simplement la sortie la plus probable pour GPT, parce qu’il ressemble aux textes sur lesquels il a été entraîné. Dans ce cas, le développeur s’est juste davantage appuyé sur ce que GPT sait bien faire ; il ne lui a pas vraiment donné plus de travail
  Il existe beaucoup de tâches simples qui font échouer GPT. Les substitutions de caractères, les fautes intentionnelles et ce genre de tâches sont très difficiles pour GPT. Les correspondances d’identifiants aussi, surtout lorsqu’elles diffèrent fortement de celles vues à l’entraînement. Par exemple, des codes pays à trois lettres similaires mais non ISO
  Ce qui est intéressant, c’est déjà le fait que GPT « comprenne » une correspondance. C’est plutôt là que je vois un véritable indice de reconnaissance de motifs de haut niveau

  • Ou alors il peut simplement mémoriser la correspondance. Pas au sens de la reproduire telle quelle, mais au sens d’avoir un vecteur proche de correspondances déjà vues auparavant

• Astuce concernant le problème de null : les LLM sont conçus pour produire des tokens, pas pour ne pas en produire
  Donc au lieu de dire « ne retourne rien », il vaut mieux dire « retourne la valeur par défaut XYZ » lorsqu’il n’y a pas de résultat, puis rechercher dans le texte cette valeur par défaut, par exemple XYZ, comme on chercherait un nom d’état
  Et les prompts système peuvent aussi être très utiles. En pratique, cela donne l’occasion de faire jouer un rôle X au LLM. Ce serait bien de pouvoir transmettre directement le prompt système, mais c’est toujours mieux que rien

• Dire que GPT n’arrive pas à retourner correctement plus de 10 objets JSON dans une liste, c’est un problème de prompt. J’ai déjà réussi à lui faire retourner de manière fiable jusqu’à 200 éléments dans le bon ordre
  L’astuce consiste à ne pas utiliser de liste du tout et à employer dans la sortie des clés JSON comme "item1": {...}. Lorsqu’il y a de 0 à n sorties pour une entrée donnée, on peut utiliser une liste comme valeur

  • Il est en train de dire à l’utilisateur qu’il vient d’une culture où répondre avec une liste incomplète est considéré comme impoli et insultant
  • J’aimerais vraiment que tu développes, parce que je me bats avec ce problème en ce moment
    Si je donne à GPT-4 une liste d’éléments existants avec une structure définie et que je lui demande de la convertir en JSON, par exemple comme une transformation de schéma, il peut faire ça toute la journée. Mais dès qu’un raisonnement quelconque est nécessaire et qu’il doit essentiellement construire sa propre liste, il ne renvoie qu’un sous-ensemble très limité
    J’ai vu des problèmes similaires avec d’autres LLM. Je suis très curieux de savoir comment tu abordes ça

• Pour une tâche comme « extraire les noms d’entreprise d’un bloc de texte », il suffit de la découper en deux étapes
  D’abord, demander : « Y a-t-il une entreprise mentionnée dans ce bloc de texte ? » Si la réponse est non, on a son résultat null. Sinon, on peut demander : « Liste les noms des entreprises présentes dans ce bloc de texte »

• J’utilise des modèles OpenAI dans une application d’écriture personnelle, et cet article est vraiment juste. J’ai appris quelque chose en lien avec la leçon 1, « moins il y a de prompt, mieux c’est »
  En construisant une fonction de recherche intelligente sur mes notes, j’essayais de faire en sorte que ChatGPT renvoie des données JSON structurées. Par exemple, je voulais pouvoir demander : « Donne-moi toutes mes notes marquées comme brouillons qui mentionnent Haskell au cours des deux dernières années », puis laisser ChatGPT décider quoi renvoyer. Ça ne marchait que parfois
  À la place, j’ai mis les données dans une base SQLite, envoyé le schéma à ChatGPT, puis lui ai fait écrire la requête qui renvoyait le résultat voulu, et cela a beaucoup mieux marché

  • On dirait que c’est un cas où une base de données et de bons filtres de recherche sont plus adaptés qu’un LLM
  • Je me demande si tu as essayé response_format=json_object
    Pour obtenir des réponses structurées, l’appel de fonction marchait mieux, mais il impose plus de contraintes que le simple fait de recevoir un corps JSON

• L’exemple où donner des instructions trop précises fait baisser la précision me semble cohérent avec ma compréhension rudimentaire du fonctionnement de ces systèmes
  Si on injecte la liste complète des États, on active dans une certaine mesure les vecteurs correspondant à tous les États. Si on dit simplement « state » et que le texte fourni contient un État explicite, moins de vecteurs liés à ce qu’on cherche sont activés. Lorsqu’on applique ensuite le softmax, la probabilité que le bon État soit choisi devient plus élevée
  Dans le même esprit, la comparaison entre /n et la virgule vient probablement aussi d’une différence de tokenisation