Un desarrollador reduce a 0,34 rublos el coste mediano de un turno en un juego con LLM

En un RPG de texto, una única respuesta del modelo debe hacer varias cosas a la vez: continuar la escena, resolver las acciones del jugador, actualizar las heridas y las relaciones, conservar la memoria de los personajes y preparar el siguiente turno. Si tan solo dos campos discrepan, la historia empieza a desmoronarse. Un golpe acierta en la descripción, pero falla en el cálculo. Un personaje descubre un secreto pese a no haber estado presente durante la conversación. Un acompañante se marcha y, en el campo siguiente, sigue al lado del jugador.

El creador del juego de Telegram AniWorlds se encontró precisamente con este problema de ingeniería. En lugar de una cadena de agentes, utiliza una sola solicitud y recibe un JSON con 38 campos. La principal conclusión práctica es sorprendentemente sencilla: el orden de los campos de una respuesta estructurada influye en la coherencia del resultado.

Primero la decisión, después la narración

El modelo genera el JSON de forma secuencial. Un campo posterior puede tener en cuenta lo que ya se ha escrito, pero no puede volver atrás y reescribir un campo anterior. Por eso, una decisión oculta —por ejemplo, si un golpe ha acertado— debe aparecer antes que la descripción literaria del combate.

Cuando el orden era el inverso, el narrador podía describir primero un impacto de forma vívida y después registrar un fallo en el campo del resultado. Las instrucciones del prompt del sistema no eliminaban la contradicción de manera fiable. Reordenar los campos suprimió el propio origen del error: el modelo fija primero el desenlace y después describe sus consecuencias.

El segundo principio es que cada decisión debe residir en un único lugar. Si el comportamiento de un acompañante queda determinado a la vez por la regla para desplazarse entre ubicaciones y por una regla independiente para acompañantes, las respuestas empiezan a divergir. En AniWorlds, la decisión se trasladó a un solo campo y las demás partes del esquema se limitan a utilizar su resultado.

Lo que no se debe confiar al narrador

El creador dejó la aleatoriedad y la aritmética exacta en manos del servidor. Para cada participante en el combate, el código lanza dos dados d6, aplica la característica correspondiente y entrega al modelo las cifras ya calculadas. El modelo no decide quién tuvo suerte: calcula el desenlace a partir de los datos proporcionados y lo convierte en una escena.

El coste de las habilidades, la resistencia y los tiempos de reutilización funcionan del mismo modo. El servidor comunica de antemano cuánto recurso queda y qué acciones no están disponibles. Esto reduce el riesgo de que el narrador olvide un gasto anterior o cambie las reglas por su cuenta para crear un episodio más vistoso.

También existe un límite de conocimiento independiente. Después del desenlace, el modelo registra exactamente qué vieron y oyeron los personajes. Su memoria se actualiza únicamente a partir de este campo, no a partir del mensaje completo del jugador. La solución todavía no es perfecta: en algunas pruebas, los personajes siguen recibiendo información innecesaria. El creador reconoce con franqueza que la mejora aún no está demostrada.

El coste del contexto y el coste de los errores

La entrada completa ocupa entre 45 y 53 mil tokens. Las reglas y la descripción del mundo apenas cambian, por lo que se colocan al principio de la solicitud y entran en la caché del proveedor. En el turno 71, el coste mediano de una solicitud fue de 0,34 rublos y el promedio, de 0,57 rublos. Sin acierto de caché, un turno costaba aproximadamente 1,25 rublos.

La causa de los costosos fallos de caché resultó ser prosaica: los identificadores de los grupos se generaban de nuevo en cada turno. Incluso un solo carácter modificado rompía la coincidencia del prefijo. Tras fijar identificadores permanentes, la caché se volvió más estable. Es una lección útil para cualquier producto basado en LLM: la caché no depende de la similitud semántica, sino de que los datos de entrada permanezcan idénticos byte por byte.

El creador comprueba los cambios mediante series de 10 solicitudes idénticas y registra la tasa de errores. El criterio de aceptación es obtener 10 respuestas de 10 sin el defecto seleccionado. Esto no demuestra una fiabilidad absoluta, pero impide declarar resuelto el problema después de un único ejemplo satisfactorio. Antes del lanzamiento, dos sesiones limpias del modelo revisan además las reglas y, después, el cambio se somete a 20 turnos reales.

La conclusión práctica va más allá de los juegos. En los sistemas con salida estructurada, coloque primero los hechos y las decisiones, y después el texto que depende de ellos. Mantenga los cálculos deterministas en el código. Asigne una única fuente de verdad a cada decisión. Haga que la parte estable del contexto sea idéntica byte por byte. Y mida la calidad con series de ejecuciones: que un asistente diga con seguridad que algo está «listo» no significa que el error haya desaparecido.