Comment contrôler les LLM dans un jeu de rôle : l'architecture de Beyond The Verge

Beyond The Verge — un jeu de rôle textuel entièrement en russe basé sur les LLM — a rencontré un problème classique : les modèles oublient le contexte, violent les règles du jeu, ajoutent des objets de nulle part. Après 30 coups, le jeu devient un chat incohérent. Les développeurs ont choisi de ne pas essayer d'« apprivoiser » le modèle, mais de lui retirer le contrôle des mécaniques.

Pourquoi les LLM ne conviennent pas pour les mécaniques

Les LLM sont génératifs par nature, tandis que les jeux de rôle exigent du déterminisme. Le modèle ne se souvient que du contexte de la fenêtre, ne peut pas distinguer son imagination de l'état du jeu, et peut spontanément changer l'intrigue ou violer la logique. Si on lui permet de gérer l'inventaire, elle perdra facilement l'épée, oubliera les limitations ou ajoutera un objet que le joueur n'a pas pris.

Architecture : le LLM en tant que narrateur uniquement

Beyond The Verge a séparé les responsabilités. Tous les mécanismes de jeu sont une logique déterministe au backend :

• Inventaire — une ligne dans PostgreSQL avec les ID des objets, le poids et les propriétés
• Carte — un graphe de sommets (lieux) et d'arêtes (transitions entre eux)
• État du personnage — un vecteur dans pgvector pour la recherche rapide de contexte
• Système de combat — formules de dégâts, de défense, de coups critiques — tout est calculé
• Quêtes — automates finis avec états fixes

Le LLM reçoit une capture de l'état du jeu sous forme de texte et génère uniquement une description : « Vous entrez dans une forêt sombre. Vous entendez des sons d'oiseaux. Dans l'inventaire : un poignard, une potion de mana (30%). Devant vous, un gobelin faible ».

L'action du joueur est analysée, validée par la logique du backend (le personnage peut-il le faire ?), le résultat est calculé, puis le LLM décrit les conséquences.

FastAPI + PostgreSQL + pgvector

La pile est simple mais efficace : FastAPI traite le coup du joueur, PostgreSQL stocke l'état (inventaire, PNJ, quêtes), pgvector recherche le contexte pertinent pour le LLM (souvenirs du personnage, atmosphère du lieu), Flutter Web est l'interface.

Lorsque le joueur se déplace, le backend met à jour la position dans le graphe de la carte, trouve les meilleures descriptions dans pgvector, rassemble les objets visibles. Le LLM reçoit un contexte compact et génère le texte en moins d'1 seconde. Pas de lutte avec la mémoire du modèle, pas d'amnésie.

Scalabilité par versionnage

Avec 1000 sessions de jeu simultanées, l'état peut entrer en conflit : deux coups au même moment — qui gagne ?

Solution : verrouillage optimiste avec versionnage d'état. Chaque état a un numéro de version ; si un conflit est détecté lors d'un coup, le client se resynchronise et le coup est rejoué. Les conditions de course sont éliminées, mais le système s'adapte linéairement.

Ce que cela signifie

Les LLM sont des outils de génération de texte, pas de gestion. Pour les systèmes fiables, la logique, l'état et les mécanismes doivent résider dans le code, pas dans le modèle. Le LLM traduit les événements en une description vivante. C'est un modèle pour tous les systèmes d'IA avec un état déterministe : les agents de navigateur, les simulations complexes, les jeux. Séparer ce qui est contrôlé de ce qui est génératif est la voie vers la fiabilité et la scalabilité.