- Se propone una nueva estrategia de razonamiento RLM (Recursive Language Model) para permitir que los modelos de lenguaje de gran escala (LLM) procesen prompts de entrada muy largos
- RLM considera los prompts largos como parte de un entorno externo y permite que el modelo los explore, descomponga e invoque recursivamente de forma programática
- Este enfoque supera los límites de la ventana de contexto y procesa entradas de hasta decenas de millones de tokens, con una mejora importante de calidad frente a los LLM existentes
- En los experimentos, los RLM basados en GPT-5 y Qwen3-Coder muestran mejoras de rendimiento de dos dígitos en diversas tareas de texto largo, con un costo similar o incluso menor
- Se evalúa como un enfoque general capaz de superar las limitaciones del procesamiento de contexto largo y ampliar significativamente la capacidad de razonamiento de los LLM
Resumen de RLM
- Recursive Language Model (RLM) está diseñado para que el LLM no introduzca directamente entradas largas en la red neuronal, sino que las trate como variables de un entorno externo con las que puede interactuar
- El prompt de entrada
P se carga como una variable en un entorno REPL de Python, y el LLM lo explora, descompone y llama recursivamente mediante código
- El LLM reconoce el estado del entorno REPL (por ejemplo, la longitud de una cadena), observa los efectos secundarios de la ejecución del código y resuelve el problema de manera gradual
- Esta estructura resuelve el problema de pérdida de detalles que presentan los enfoques tradicionales de compresión de contexto (compaction) o basados en resúmenes
- RLM se presenta como un paradigma general de razonamiento capaz de ampliar tanto la longitud de entrada como la de salida
Limitaciones de los enfoques existentes
- Los LLM actuales muestran el fenómeno de context rot, en el que el rendimiento cae bruscamente con entradas largas debido a los límites de la ventana de contexto
- Las técnicas de compresión de contexto (compaction) repiten resúmenes al superar cierta longitud, pero no son adecuadas para tareas que requieren acceso a información detallada
- RLM puede tratar el prompt como un objeto externo y extender el tamaño de entrada más allá de los límites del modelo
Configuración experimental
- Modelos evaluados: GPT-5 (OpenAI, 2025) y Qwen3-Coder-480B-A35B (Team, 2025)
- Métodos de comparación:
- Llamada directa al LLM base
- Agente de resumen (Summary agent)
- Agente de recuperación basado en CodeAct + BM25
- RLM (incluyendo entorno REPL) y RLM (REPL, sin llamadas recursivas)
- En los experimentos con GPT-5, se usó GPT-5-mini para las llamadas recursivas y GPT-5 como modelo raíz, para equilibrar rendimiento y costo
Tareas de evaluación
- S-NIAH: problema único de “needle-in-a-haystack”, con costo de procesamiento constante sin importar la longitud de entrada
- BrowseComp-Plus: tarea de preguntas y respuestas multi-hop entre múltiples documentos, con la respuesta correcta incluida entre 1000 documentos
- OOLONG: tarea de razonamiento de texto largo que requiere transformar e integrar semánticamente casi todos los elementos de la entrada; el costo de procesamiento es lineal respecto a la longitud de entrada
- OOLONG-Pairs: variante de OOLONG que requiere combinar información por pares, con un costo de procesamiento proporcional al cuadrado de la longitud de entrada
- LongBench-v2 CodeQA: tarea de opción múltiple que exige comprender un repositorio de código, difícil incluso para modelos recientes
Resultados principales
- RLM casi no muestra degradación de rendimiento frente a GPT-5 incluso con contexto largo
- GPT-5 sufre una caída marcada de rendimiento a medida que aumentan la longitud de entrada y la complejidad de la tarea
- RLM procesa de manera efectiva entradas que superan el límite de 272K tokens (hasta más de 10M tokens)
- En todas las tareas de texto largo, RLM muestra mejoras de rendimiento de dos dígitos frente a otros métodos
- También mantiene la eficiencia de costo, con un costo por consulta similar o menor que el de los enfoques existentes
Análisis de complejidad en tareas de texto largo
- La ventana de contexto efectiva de un LLM puede ser más corta que su límite físico según la complejidad de la tarea
- Un problema NIAH simple puede resolverse incluso con 1M+ tokens
- Las tareas complejas del tipo OOLONG muestran degradación de rendimiento incluso con longitudes mucho menores
- Por eso, es necesario considerar conjuntamente la densidad de información de la tarea y su relación con la longitud de entrada
Conclusión
- RLM amplía recursivamente la capacidad de razonamiento de los LLM, permitiendo manejar entradas ultralargas que los modelos existentes no pueden procesar
- La innovación clave es el diseño que trata el prompt como un objeto del entorno, resolviendo las limitaciones estructurales del procesamiento de texto largo
- Se presenta como un marco general de razonamiento que logra un equilibrio entre rendimiento, costo y escalabilidad en diversos modelos y tareas
1 comentarios
Opiniones de Hacker News
Esto simplemente parece el concepto de subagent
Es decir, una forma de invocar a otro LLM para que lea archivos y extraiga la información necesaria, evitando complicar demasiado el contexto principal
La idea está bien, pero no es algo completamente nuevo
Actualmente estoy experimentando en el proyecto Scope para que subagents observables descompongan tareas de forma recursiva
Pero no sé cómo mejorar esta evaluación de la fase de planificación
Registro heurísticas en archivos Markdown, pero la estructura es demasiado flexible y eso dificulta medirlas
Si alguien conoce literatura o proyectos relacionados, sería bueno que los compartiera
RLM no es ni un agente ni un resumen
Usar múltiples llamadas a LM dentro de un solo sistema no es una idea nueva, y eso es lo que hace la mayoría de los agentic scaffold
El ejemplo más parecido sería ROMA agent, que descompone el problema y lo resuelve con varios sub-agents
Además, asistentes de código como Cursor o Claude Code también resumen o podan cuando el contexto se vuelve demasiado largo
Estos enfoques normalmente descomponen por unidad de tarea, pero RLM enfatiza la descomposición por unidad de contexto, y asume que esa elección debe decidirla el propio LM
La intuición clave es que no deberíamos meter prompts largos directamente en una red neuronal (Transformer), sino tratarlos como parte de un entorno con el que el LLM puede interactuar simbólicamente
Pero me pregunto en qué se diferencia esto, en el fondo, de RAG
Viendo la figura 4, parece que la diferencia es que el mecanismo de retrieval lo implementa directamente el LLM, en lugar de una persona
1️⃣ RAG se parece más a un workflow, mientras que esto es más agentic
2️⃣ Tiene una estructura recursiva
En un workflow, una persona diseña el flujo paso a paso, pero en un enfoque agentic el agente decide por sí mismo qué buscar, cuántas veces invocar herramientas y cuándo responder
Por ejemplo, Claude Code o Codex recorren un codebase leyendo archivos y ejecutando ripgrep
Este tipo de intento recursivo ya había aparecido antes (por ejemplo, babyagi, alrededor de 2023), pero en ese momento el rendimiento de los modelos era insuficiente y hacía falta mucho glue code
Ahora los modelos ya son lo bastante potentes como para que esta estructura funcione de verdad
Como en la broma “T̶u̶r̶t̶l̶e̶s̶ LLMs all the way down”, esto sugiere una estructura en la que un LLM llama a otro LLM sin parar
Hay una versión más fácil de leer del texto: post del blog de alexzhang13
Lo que espero para 2026 es que Anthropic u OpenAI revelen a los creadores de plugins de CLI “cómo se ejecuta compaction”
Esta técnica podría incluso reemplazar funciones integradas en Claude Code, pero por ahora no se exponen los hooks ni las capacidades adecuadas
Yo vi el código de Gemini, y cuando la ventana de contexto se llenaba usaba una estructura de prompt simple que resumía todo
Esto parece similar a este paper: arXiv:2510.14826