Cómo controlar LLM en un juego de rol: la arquitectura de Beyond The Verge
Beyond The Verge controló los problemas de la LLM en los juegos de rol: derivas del modelo, amnesia, violaciones de reglas. La solución es radical: un…
Procesado por IA desde Habr AI; editado por Hamidun News
Beyond The Verge —un RPG textual completamente en ruso basado en LLM— se enfrentó a un problema clásico: los modelos olvidan el contexto, violan las reglas del juego, añaden objetos de la nada. Después de 30 turnos, el juego se convierte en un chat incoherente. Los desarrolladores eligieron no intentar «domesticar» el modelo, sino quitarle el control de las mecánicas.
Por qué la LLM no es adecuada para las mecánicas
Las LLM son generativas por naturaleza, mientras que los RPG requieren determinismo. El modelo solo recuerda el contexto de la ventana, no distingue su imaginación del estado del juego, puede cambiar espontáneamente la trama o violar la lógica. Si se le permite controlar el inventario, fácilmente perderá la espada, olvidará las limitaciones o añadirá un objeto que el jugador nunca tomó.
Arquitectura: la LLM solo como narradora
Beyond The Verge dividió las responsabilidades. Todas las mecánicas del juego son lógica determinista en el backend:
- Inventario —una fila en PostgreSQL con IDs de objetos, peso y propiedades
- Mapa —un grafo de vértices (ubicaciones) y aristas (transiciones entre ellas)
- Estado del personaje —un vector en pgvector para búsqueda rápida de contexto
- Sistema de combate —fórmulas de daño, defensa, críticos—todo se calcula
- Misiones —autómatas finitos con estados fijos
La LLM recibe una instantánea del estado del juego en forma de texto y genera solo una descripción: «Entraste en un bosque oscuro. Se escuchan sonidos de pájaros. En el inventario: daga, poción de maná (30%). Delante hay un goblin débil». La acción del jugador se analiza, se valida mediante la lógica del backend (¿puede el personaje hacer esto?), se calcula el resultado, luego la LLM describe las consecuencias.
FastAPI + PostgreSQL + pgvector
El stack es simple pero efectivo: FastAPI procesa el turno del jugador, PostgreSQL almacena el estado (inventario, NPCs, misiones), pgvector busca contexto relevante para la LLM (recuerdos del personaje, atmósfera de la ubicación), Flutter Web es la interfaz. Cuando el jugador se mueve, el backend actualiza la posición en el grafo del mapa, encuentra las mejores descripciones en pgvector, recopila objetos visibles. La LLM recibe contexto compacto y genera texto en <1 segundo. Sin luchas con la memoria del modelo, sin amnesia.
Escalabilidad mediante versionado
Con 1000 sesiones de juego simultáneas, el estado puede entrar en conflicto: ¿dos turnos en el mismo momento—quién gana? Solución: bloqueo optimista con versionado de estado. Cada estado tiene un número de versión; si se detecta un conflicto durante un turno, el cliente se resincroniza y el turno se repite. Se eliminan las condiciones de carrera, pero el sistema se escala linealmente.
Lo que significa esto
Las LLM son herramientas de generación de texto, no de control. Para sistemas confiables, la lógica, el estado y las mecánicas deben vivir en el código, no en el modelo. La LLM traduce eventos en descripciones vívidas. Este es un patrón para todos los sistemas de IA con estado determinista: agentes de navegador, simulaciones complejas, juegos. Separar lo controlable de lo generativo es el camino hacia la confiabilidad y la escalabilidad.
¿Quieres dejar de leer sobre IA y empezar a usarla?
AI News es un feed curado de noticias de IA. Hamidun Academy te enseña a usar la IA en tu trabajo.