Hacer que un LLM escriba código para leer 10 millones de tokens - Cómo funciona RLM

“Si la ventana de contexto es más grande, la IA es más inteligente, no?”

La respuesta es no. De hecho, entre más largo el input, peor le va al modelo.

Context Rot - Por qué necesitamos RLM

Los LLM predicen el siguiente token calculando distribuciones de probabilidad sobre los tokens de entrada. El problema es que conforme crece el input, la información relevante se va mezclando con ruido, y cada vez se le hace más difícil al modelo hacer cálculos precisos.

Incluso los modelos que presumen ventanas de contexto de 128K o 1M tokens alcanzan su mejor rendimiento alrededor de los 10K tokens. Pasados los 100K, la calidad cae en picada. A este fenómeno se le llama Context Rot (deterioro de contexto).

Piénsenlo así: es como leer un manual de 500 páginas para responder una sola pregunta. No necesitas las 500 páginas - necesitas los tres párrafos correctos. Pero un LLM con una ventana de contexto enorme intenta digerir el libro completo de un jalón, y la señal útil se pierde entre el ruido.

La idea central - “No leas todo, extrae lo que necesitas”

RLM (Recursive Language Model) toma un camino fundamentalmente distinto. En vez de meter 10 millones de tokens de golpe al LLM, almacena el texto en variables de Python y deja que el modelo escriba código para leer selectivamente solo las partes que necesita.

En términos sencillos, trata al LLM como un CPU y al corpus masivo de texto como un disco duro. El modelo procesa aproximadamente 50K tokens relevantes a la vez mientras extrae respuestas precisas de documentos que superan los 10 millones de tokens.

Es un cambio de paradigma: pasamos de “dale más contexto al modelo” a “deja que el modelo decida qué contexto necesita.”

Los tres componentes centrales

RLM Orchestrator

El controlador que gestiona el historial de mensajes, maneja el ciclo de iteración y determina cuándo se llegó a una respuesta final. Decide si el modelo necesita otra pasada por los datos o si ya juntó suficiente información para responder.

LMHandler

Un servidor de sockets que retransmite las peticiones a la API del LLM. Lo clave de este componente es que permite hacer llamadas al LLM incluso durante la ejecución de código - o sea, el modelo puede hacerse preguntas a sí mismo mientras procesa datos.

Environment / REPL

Un sandbox de Python donde el texto masivo se almacena en una variable context. La función estrella es llm_query(), que permite al LLM llamarse a sí mismo de forma recursiva durante la ejecución. De ahí viene lo de “Recursive” en RLM.

El ciclo de ejecución - Explorar, Descomponer, Agregar, Terminar

RLM sigue un ciclo estructurado para trabajar documentos masivos:

Explorar: El modelo empieza examinando la estructura de los datos - ejecutando algo como print(context[:500]) para entender con qué está trabajando.

Descomponer: Divide el texto en fragmentos y usa llm_query() para hacer subpreguntas sobre cada fragmento. En lugar de una sola consulta monolítica sobre millones de tokens, ejecuta docenas de consultas enfocadas sobre piezas manejables.

Agregar: Las subrespuestas se combinan - ya sea mediante lógica de Python (contar, filtrar, ordenar) o pidiéndole al LLM que sintetice los resultados de múltiples fragmentos.

Terminar: Cuando el modelo juntó suficiente información, llama a FINAL(answer) para devolver la respuesta final.

Este ciclo se puede repetir las veces que haga falta, y cada iteración se construye sobre lo que descubrieron las anteriores.

La conexión con Ralph Wiggum - “Está bien fallar, sigue iterando”

El plugin de Claude Code Ralph Wiggum, que ha estado dando de qué hablar últimamente, comparte una filosofía con RLM aunque resuelve un problema diferente.

Cómo funciona Ralph Wiggum

Cuando Claude termina una tarea e intenta cerrar la sesión, un Stop Hook intercepta la terminación y reinyecta el prompt original. En cada iteración, Claude puede ver los archivos modificados en ejecuciones anteriores y el historial de Git, lo que le permite ir resolviendo problemas de forma progresiva.

Lo que tienen en común

Ambos enfoques atacan problemas que no se pueden resolver en una sola llamada al LLM, usando ciclos iterativos. Los dos tratan los fallos como datos - cada iteración referencia los resultados anteriores para mejorar.

En qué se diferencian

RLM se especializa en procesamiento de texto a escala masiva, con llamadas recursivas al LLM durante la ejecución de código como mecanismo central. Ralph Wiggum se enfoca en la ejecución autónoma de tareas de desarrollo, operando al interceptar la terminación de la sesión para impulsar la mejora continua.

Tips prácticos para implementación

Procesamiento por lotes: No llamen al LLM 1,000 veces para 1,000 líneas. Procesen 50 líneas a la vez en 20 llamadas.

Pre-filtrado: Antes de llamar a llm_query(), usen regex para acotar candidatos. Dejen que el código determinístico haga lo que puede antes de gastar tokens en razonamiento del LLM.

Limitar la profundidad de recursión: Profundidad 1 suele ser suficiente. Ir más profundo acumula errores en vez de mejorar la precisión.

Manejo de historial: Usen ventanas deslizantes o enfoques basados en resúmenes para evitar que el context rot se acumule entre iteraciones.

Qué significa todo esto

RLM representa un cambio de mentalidad: pasamos de forzar ventanas de contexto cada vez más grandes a diseñar formas más inteligentes para que los modelos lean datos. En vez de meter todo en un solo prompt, el modelo escribe código, lo ejecuta, lee selectivamente y se llama a sí mismo de forma recursiva cuando lo necesita.

Este tipo de razonamiento estilo agente - donde los LLM escriben y ejecutan código para encontrar la información que necesitan de forma autónoma - se está volviendo cada vez más central en cómo construimos sistemas de IA. El futuro no son ventanas de contexto más grandes. Son patrones de acceso más inteligentes.