La LLM Wiki de Karpathy, pero para tu campaña de D&D (y ya está en producción)

¿Por qué la IA olvida tu campaña?

La ventana de contexto no es memoria. Es una pizarra que se borra después de cada sesión. Un modelo puede manejar un millón de tokens, pero la calidad empieza a degradarse mucho antes de llegar ahí, y cuando la sesión termina, todo desaparece. La siguiente conversación empieza de cero.

En un chatbot eso es molesto. En una campaña de rol es fatal. Pasas tres sesiones construyendo una rivalidad con una contrabandista llamada Elara. La perdonas la vida en una cripta. Dos semanas después el Director de Juego la introduce de nuevo — como un hombre, de otra ciudad, que nunca te ha conocido. La ilusión se rompe. La historia en la que estabas invertido deja de ser tuya. Si has jugado con un LLM sin más, conoces exactamente ese momento: el PNJ muerto que sigue hablando.

El RAG fue el primer parche serio: convierte tus documentos en vectores, almacénalos y recupera los fragmentos relevantes en el momento de la consulta. Funciona — millones de sistemas en producción lo usan. Pero tiene un límite estructural que un paper de 2024 mapeó en siete puntos de fallo. Tres importan para un Director de Juego: el chunking divide a un personaje en fragmentos de modo que el modelo encuentra uno y pierde el resto; la re-derivación hace que cada turno empiece de cero sin aprender nada; y la pasividad significa que el sistema solo responde, sin detectar que dos fuentes se contradicen.

Tres formas de que una IA recuerde: recuperar, compilar, actuar

El debate actual alinea tres arquitecturas. Se presentan como rivales. No lo son — son tres capas del mismo stack.

• Recuperar (RAG) — encuentra contenido relevante a escala. Excelente en amplitud, ciego en profundidad; relee los mismos libros en cada examen y nunca aprende el material.
• Compilar (la LLM wiki) — la idea de Karpathy: compila las fuentes una vez en una wiki persistente e interconectada. El conocimiento se acumula; simplemente no escala a millones de documentos.
• Actuar (habilidades autónomas) — el GBrain de Garry Tan: conocimiento que no se queda quieto sino que dispara acciones, corre con un horario, trabaja mientras duermes. Potente, y un compromiso de ingeniería serio.

La pregunta correcta no es “cuál gana.” Es ¿cuál es el trabajo de tu agente? El trabajo de un Director de Juego es los tres a la vez — por eso es un caso de prueba tan brutal. Aquí es donde estamos realmente.

Recuperar: RAG sobre tu campaña

La capa base es RAG real. Cada artículo del Códex de tu campaña se convierte en un vector y se almacena con pgvector en Postgres. Cuando el Director de Juego necesita algo que las búsquedas estructuradas no cubren, ejecuta una búsqueda semántica sobre esos embeddings y recupera los pasajes más cercanos.

Esta es la parte poco glamurosa pero imprescindible. Escala, es lo bastante rápida para un turno en vivo y es el fallback cuando el grafo todavía no conoce la respuesta. Pero por sí sola tiene exactamente la debilidad que Karpathy señala: recupera, nunca acumula. Por eso no nos quedamos aquí.

Compilar: el Códex es la LLM wiki de Karpathy

El Códex es la LLM wiki de Karpathy. La enviamos a producción para juegos de rol de mesa en vez de papers de investigación. Las mismas tres capas que él describe:

• Fuentes inmutables — tu partida real. La transcripción de lo que ocurrió en la mesa. El modelo la lee pero nunca la reescribe.
• La wiki — el Códex: páginas de entidades escritas por el LLM para cada PNJ, lugar, misión e hilo narrativo, con resúmenes, estado y referencias cruzadas. El modelo es dueño de esta capa.
• El esquema — las reglas sobre cómo se mantiene la wiki: qué cuenta como PNJ, cómo se forman los backlinks, qué es una contradicción.

Y se acumula como Karpathy describe. Cuando termina una escena, el Director de Juego no escribe un solo resumen — lee los eventos nuevos contra el Códex existente y actualiza cada página que tocan: nuevas referencias cruzadas, estado actualizado, una nueva entrada en la línea de tiempo. Una entrada literalmente dice “El DM conserva esta entrada.” La wiki se enriquece cuanto más juegas.

El resultado se desplegó esta semana: el Director de Juego ahora lee su propio Códex en cada turno. No vuelca toda la wiki en el contexto — enruta hacia las entidades que importan en la escena actual, carga sus páginas más un salto de backlinks, e inyecta un bloque de memoria compacto. Eso es la intersección recuperar + compilar que toda la industria dibuja en una pizarra, corriendo en una partida real.

El problema que nadie menciona: coherencia, no memoria

Los ensayos sobre “el RAG ha muerto” se saltan la mitad difícil. En una historia, recordar es la mitad fácil. La mitad difícil es no contradecirse. Una wiki que se compila sola acumulará alegremente sus propias alucinaciones — un detalle erróneo se cruza-referencia en tres páginas y se convierte en canon. El gist de Karpathy son 200 líneas elegantes; en producción, el lint y la verificación son el 80% del trabajo real.

Así que la ingeniería interesante no es el paso de compilación, sino las salvaguardas. El Códex separa lo que un jugador puede ver de los secretos solo para el DM, de modo que la memoria que lee el Director de Juego puede incluir el giro argumental sin filtrarlo nunca a la mesa. Y no confiamos en nada de esto al azar — corremos evals. Con el bloque de memoria activo, el Director de Juego usa aproximadamente tres veces más hechos canónicos por escena y nunca filtró un secreto en ejecuciones repetidas; sin él, inventó tres trasfondos mutuamente contradictorios para el mismo personaje. Esa diferencia es todo el producto.

Actuar: lo que viene

La tercera capa es la parte honesta del roadmap. Hoy el Director de Juego ya actúa mediante herramientas — tira dados, resuelve combate mecánico, registra PNJ, lleva el control de relojes de presión. Pero se disparan de forma reactiva, mientras narra tu turno. Lo que todavía no hace es lo que el GBrain de Garry Tan sí hace: correr por su cuenta.

La versión que queremos es un Director de Juego que mantenga el mundo en marcha entre sesiones — avanzando el esquema de un rival, gastando el favor que te debía un PNJ, dejando que una amenaza que ignoraste crezca con dientes — para que vuelvas a un mundo que vivió sin ti. Esa es la capa de acción, y es el honesto “próximamente” en el diagrama de arriba. La memoria y la wiki son los prerrequisitos difíciles, y ya existen.

¿Qué arquitectura gana?

Ninguna por sí sola. Del mismo modo que las bases de datos dejaron de ser “SQL o NoSQL” y se convirtieron en sistemas híbridos, la memoria en agentes converge en un único stack: recuperar a escala, compilar en conocimiento persistente, actuar sobre él de forma autónoma. Los equipos que todavía preguntan cuál elegir están haciendo la pregunta equivocada.

No empezamos esto para demostrar una tesis sobre la memoria IA. Empezamos para construir un Director de Juego que no olvide tu historia. Son el mismo proyecto. Y el lugar menos indulgente para probarlo no es una wiki empresarial — es una mesa de jugadores que notará en el segundo en que su rival muerto vuelva a hablar.