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

“¿Una ventana de contexto más grande hace a la IA más inteligente?”

La respuesta es no. De hecho, cuanto más largo es el input, peor rinde el 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, a medida que el input crece, la información relevante se diluye entre ruido, y el cálculo preciso se vuelve cada vez más difícil.

Incluso los modelos que anuncian ventanas de contexto de 128K o 1M tokens alcanzan su máxima precisión en torno a los 10K tokens. A partir de los 100K, el rendimiento cae en picado. Este fenómeno se conoce como Context Rot - la degradación del contexto.

Pensadlo así: es como tener que leer un manual de 500 páginas para responder a una sola pregunta. No necesitáis las 500 páginas; necesitáis los tres párrafos adecuados. Pero un LLM con una ventana de contexto masiva intenta digerir el libro entero de golpe, y la señal queda sepultada bajo el ruido.

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

RLM (Recursive Language Model) adopta un enfoque radicalmente distinto. En lugar de inyectar 10 millones de tokens en un LLM de una sola vez, almacena el texto en variables de Python y deja que el modelo escriba código para leer selectivamente solo las partes que necesita.

Dicho de forma sencilla: trata al LLM como una CPU y al corpus de texto masivo como un disco duro. El modelo procesa alrededor de 50K tokens relevantes a la vez, mientras extrae respuestas precisas de documentos que superan los 10 millones de tokens.

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

Los tres componentes principales

RLM Orchestrator (Orquestador)

El controlador que gestiona el historial de mensajes, controla el bucle de iteración y determina cuándo se ha alcanzado una respuesta final. Decide si el modelo necesita otra pasada por los datos o si ya ha recopilado información suficiente para responder.

LMHandler

Un servidor de sockets que retransmite las peticiones a la API del LLM. El detalle crucial es que este handler permite realizar llamadas al LLM incluso durante la ejecución de código - lo que significa que 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 clave es llm_query(), que permite al LLM llamarse a sí mismo de forma recursiva durante la ejecución. De aquí viene exactamente lo de “Recursive” en RLM.

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

RLM sigue un bucle estructurado para procesar 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 utiliza llm_query() para formular subpreguntas sobre cada fragmento. En lugar de una consulta monolítica sobre millones de tokens, ejecuta docenas de consultas enfocadas sobre porciones manejables.

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

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

Este bucle puede repetirse tantas veces como sea necesario. Cada iteración se construye sobre lo que las iteraciones anteriores han descubierto.

La conexión con Ralph Wiggum - “No pasa nada si fallas, sigue iterando”

El plugin de Claude Code Ralph Wiggum, que ha estado en boca de todos últimamente, comparte filosofía con RLM aunque resuelve un problema diferente.

Cómo funciona Ralph Wiggum

Cuando Claude termina una tarea e intenta salir, 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 mordiendo el problema de forma progresiva.

Qué comparten

Ambos enfoques abordan problemas que no se pueden resolver en una sola llamada al LLM mediante bucles iterativos. Ambos tratan el fallo como un dato - cada iteración referencia los resultados anteriores para mejorar.

En qué se diferencian

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

Consejos prácticos para la implementación

Procesamiento por lotes: No llaméis al LLM 1.000 veces para 1.000 líneas. Procesad 50 líneas a la vez en 20 llamadas. La diferencia en coste y latencia es abismal.

Prefiltrado: Antes de invocar llm_query(), usad expresiones regulares para reducir los candidatos. Dejad que el código determinista haga lo que pueda antes de gastar tokens en razonamiento del LLM.

Limitar la profundidad de recursión: Con profundidad 1 suele ser suficiente. Ir más allá acumula errores en lugar de mejorar la precisión - los fallos se componen en cada nivel.

Gestión del historial: Usad ventanas deslizantes o resúmenes acumulativos para evitar que el context rot se propague entre iteraciones. Sin esta precaución, cada pasada degrada un poco más la calidad de la siguiente.

Qué significa todo esto

RLM representa un cambio de mentalidad: de la fuerza bruta de ampliar ventanas de contexto a diseñar formas más inteligentes de que los modelos lean datos. En lugar de embutirlo todo en un solo prompt, el modelo escribe código, lo ejecuta, lee selectivamente y se llama a sí mismo recursivamente cuando lo necesita.

Este razonamiento de estilo agente - donde los LLM escriben y ejecutan código para encontrar autónomamente la información que necesitan - se está convirtiendo en el eje central de cómo construimos sistemas de IA. El futuro no pasa por ventanas de contexto más grandes. Pasa por patrones de acceso más inteligentes.