Un développeur ramène le prix médian d'un tour de jeu LLM à 0,34 rouble

Dans un RPG textuel, une seule réponse du modèle doit accomplir plusieurs choses à la fois : poursuivre la scène, résoudre les actions du joueur, mettre à jour les blessures et les relations, conserver la mémoire des personnages et préparer le tour suivant. Si seulement deux champs divergent, l'histoire commence à se désagréger. Le coup touche dans la description, mais pas dans le calcul. Un personnage apprend un secret alors qu'il n'assistait pas à la conversation. Un compagnon est d'abord parti, puis reste à proximité dans le champ suivant.

L'auteur du jeu Telegram AniWorlds s'est heurté précisément à ce problème d'ingénierie. Au lieu d'une chaîne d'agents, il utilise une seule requête et obtient un JSON de 38 champs. Le principal enseignement pratique est étonnamment simple : l'ordre des champs dans une réponse structurée influe sur la cohérence du résultat.

D'abord la décision, ensuite le récit

Le modèle génère le JSON de façon séquentielle. Le champ suivant peut tenir compte de ce qui est déjà écrit, mais ne peut pas revenir en arrière pour réécrire le précédent. C'est pourquoi une décision cachée, par exemple « le coup a-t-il touché », doit figurer avant la description littéraire du combat.

Quand l'ordre était inverse, le narrateur pouvait d'abord décrire avec éclat une touche, puis inscrire un échec dans le champ du résultat. Les exhortations dans le prompt système n'éliminaient pas la contradiction de manière fiable. La permutation des champs a supprimé la source même de l'erreur : le modèle fixe d'abord l'issue, puis décrit ses conséquences.

Le second principe : une décision doit vivre à un seul endroit. Si le comportement d'un compagnon est déterminé à la fois par la règle de passage entre les lieux et par une règle distincte sur les compagnons, les réponses commencent à diverger. Dans AniWorlds, la décision a été placée dans un champ unique, et les autres parties du schéma n'en utilisent que le résultat.

Ce qu'on ne peut pas confier au narrateur

L'auteur a laissé au serveur le hasard et l'arithmétique exacte. Pour chaque participant au combat, le code lance deux dés à six faces (d6), prend en compte la caractéristique et transmet au modèle des chiffres prêts à l'emploi. Le modèle ne décide pas qui a de la chance : il calcule l'issue à partir des données fournies et la transforme en scène.

Il en va de même pour le coût des capacités, la réserve d'énergie et les temps de recharge. Le serveur indique à l'avance combien de ressource il reste et quelles actions sont indisponibles. Cela réduit le risque que le narrateur oublie une dépense passée ou modifie les règles de son propre chef pour un bel épisode.

Il existe aussi une frontière distincte des connaissances. Après l'issue, le modèle consigne ce que les personnages ont précisément vu et entendu. Leur mémoire n'est mise à jour qu'à partir de ce champ, et non du message complet du joueur. La solution n'est pas encore parfaite : dans une partie des tests, les personnages reçoivent encore des informations superflues. L'auteur note honnêtement que l'amélioration n'est pas encore démontrée.

Le prix du contexte et le prix de l'erreur

L'entrée complète occupe de 45 à 53 mille tokens. Les règles et la description du monde changent très peu ; elles sont donc placées au début de la requête et mises en cache par le fournisseur. Sur 71 tours, le prix médian d'une requête s'est établi à 0,34 rouble, et le prix moyen à 0,57 rouble. Sans succès du cache, un tour coûtait environ 1,25 rouble.

La cause des échecs coûteux s'est révélée prosaïque : les identifiants de groupes étaient recréés à chaque tour. Même un seul caractère modifié rompait la correspondance du préfixe. Après la fixation d'identifiants constants, le cache est devenu plus stable. C'est une leçon utile pour tout produit LLM : le cache dépend non pas de la similarité de sens, mais de l'invariance des données d'entrée.

L'auteur vérifie ses modifications par séries de 10 requêtes identiques et relève le taux d'erreurs. Le critère d'acceptation est de 10 réponses sur 10 sans le défaut ciblé. Cela ne prouve pas une fiabilité absolue, mais empêche de déclarer un problème résolu après un seul exemple réussi. Avant la publication, les règles sont en outre lues par deux sessions vierges du modèle, puis la modification passe 20 tours en conditions réelles.

La leçon pratique dépasse le cadre des jeux. Pour les systèmes à sortie structurée, placez d'abord les faits et les décisions, puis le texte qui en dépend. Gardez les calculs déterministes dans le code. Attribuez à chaque décision une seule source de vérité. Rendez la partie stable du contexte identique à l'octet près. Et mesurez la qualité par séries d'exécutions : un « c'est fait » assuré de l'assistant ne signifie pas encore que l'erreur a disparu.