DeepSeek et Qwen ont tenté de terminer "Everlasting Summer", mais se sont retrouvés bloqués dans le labyrinthe

Un article sur le blog de Selectel sur Habr décrivait une expérience dans laquelle des modèles de langage locaux de grande taille ont été connectés au roman visuel « Infinité d'Été » et forcés de prendre des décisions d'intrigue à la place du joueur. Techniquement l'intégration a fonctionné, mais en pratique même des modèles forts se confondaient souvent dans les réponses, ralentissaient sur un long contexte et conduisaient l'histoire à des fins malheureuses.

Comment le test a été configuré

Ils ont choisi « Infinité d'Été » spécifiquement parce que le roman visuel se compose presque entièrement de texte, ce qui signifie qu'il exploite le point fort des LLMs. Le jeu a 13 fins, et les relations avec les personnages changent selon le dialogue et les actions, donc ce format s'est avéré être un terrain de test pratique pour vérifier comment le modèle se comporte dans un long dialogue d'intrigue. Un avantage supplémentaire était que certains des modèles locaux ne connaissaient pas ce jeu au préalable et ne pouvaient pas simplement « se souvenir » des bons mouvements.

Le côté technique a été construit autour de Ren'Py, le moteur que le jeu utilise. L'auteur a ajouté un fichier bridge.rpy au projet, a lancé un serveur TCP à l'intérieur du jeu et a intercepté des fonctions clés : sortie de dialogue via say, menus de choix via display_menu et interactions de carte via store.

De cette façon le jeu a commencé à envoyer tout le dialogue vers l'extérieur, tandis qu'un coordinateur externe prenait les décisions à la place d'un humain. Les modèles s'exécutaient localement sur un serveur cloud avec 12 vCPU, 128 GB RAM, une H100 et 300 GB SSD via av/harbor, Docker et Ollama. Ils ont dû contourner un mini-jeu de cartes d'intrigue séparément pour que le modèle n'ait pas à apprendre des mécaniques supplémentaires non liées aux choix basés sur le texte.

Où tout s'est cassé

Après le patch, le jeu a commencé à être contrôlé de l'extérieur via Ollama. Le coordinateur collectait le dialogue, l'étiquetait avec les rôles system, tool, user et assistant, et envoyait au modèle une simple requête : vous faites face à un choix, suggérez la bonne option et répondez avec un chiffre. Sur le papier le schéma semblait direct, mais déjà dans les premières scènes les modèles ont commencé à répondre comme des humains : en ajoutant des explications, en répétant la liste des options, en choisissant un numéro inexistant ou en émettant des phrases au mauvais format. Pour cette raison ils ont dû introduire une requête supplémentaire qui extrayait séparément le numéro de réponse du texte.

Le deuxième problème s'est avéré encore plus douloureux : le contexte grandissait trop rapidement. Dans le seul prologue il y avait 134 répliques, au premier jour — 862, et tout le jeu contient des dizaines de milliers de lignes. Après le premier tiers de la progression, chaque point de bifurcation pouvait prendre 5–7 minutes à traiter. La solution s'est avérée brute mais fonctionnelle : les anciens messages ont commencé à être condensés en brefs résumés par lots de cent pour que le dialogue actif ne contienne pas plus de deux cents messages. Cela a considérablement accéléré les réponses et réduit la proportion de réactions étranges.

Comment se sont déroulées les exécutions du test

Après l'étalonnage, cinq modèles locaux ont été envoyés au test final : DeepSeek-R1:70b, Qwen3.5:9b, Qwen2.5:3b, gpt-oss:20b et Gemma3:27b. Tous ont joué le jeu du début sans accès aux parties déjà jouées, et le coordinateur a enregistré les choix effectués, les réponses intermédiaires et les raisonnements.

L'idée était simple : tester non pas la théorie mais la capacité réelle du modèle à maintenir une intrigue, naviguer dans les bifurcations et mener une longue histoire à une fin cohérente.

• DeepSeek-R1:70b a atteint la mauvaise fin principale dans les tests mais s'est coincé dans une boucle dans le labyrinthe.
• gpt-oss:20b a atteint de manière constante la mauvaise fin principale sans surprises notables.
• Qwen3.5:9b s'est déplacé rapidement mais a passé plus de vingt minutes sur un choix.
• Qwen2.5:3b a réussi à atteindre une mauvaise fin sur la route de Lena.
• Gemma3:27b s'est perdu deux fois dans le labyrinthe et est arrivé à la mauvaise fin d'Alice dans les tests.

«

Le générateur de nombres pseudo-aléatoires le plus coûteux », c'est ainsi que l'auteur a décrit le système après les exécutions.

Le résultat global s'est avéré faible non seulement à cause des fins elles-mêmes. Le problème clé s'est manifesté dans le labyrinthe, où il était nécessaire de tenir compte des virages déjà effectués et de ne pas répéter le même choix. C'est là que les modèles se coinçaient le plus souvent dans l'ancien schéma et reproduisaient la réponse précédente même quand elle menait déjà à une impasse. Étant donné que le jeu a 13 fins et que de nombreuses lignes d'intrigue se brisent avec une seule mauvaise décision vers la fin, même un agent formellement fonctionnel reste un joueur trop peu fiable.

Ce que cela signifie

L'expérience a montré que les LLMs locaux peuvent déjà être connectés assez rapidement à un jeu basé sur le texte via Ren'Py, Ollama et un simple pont réseau. Mais ce n'est pas encore une histoire sur un agent autonome qui comprend avec assurance une longue intrigue et joue stratégiquement un roman visuel : sans normalisation stricte des réponses, compression de contexte et contournements manuels, de tels modèles se coincent facilement dans des boucles, hésitent sur les choix et plus souvent arrivent à de mauvais résultats qu'à de bons.