Cuando analiza documentos que abarcan millones de caracteres, topa con la barrera de la ventana de contexto e incluso las ventanas de contexto más grandes se quedan cortas. Su modelo rechaza la entrada o produce respuestas basadas en información incompleta. ¿Cómo razona sobre documentos que no encajan?
En esta publicación, aprenderá cómo implementar modelos de lenguaje recursivo (RLM) utilizando Amazon Bedrock AgentCore Code Interpreter y el SDK de Strands Agents. Al final, sabrá cómo:
Procese documentos de diferentes longitudes, sin límite superior en el tamaño del contexto. Utilice Bedrock AgentCore Code Interpreter como memoria de trabajo persistente para el análisis iterativo de documentos. Organice llamadas a modelos de lenguaje subgrandes (LLM) desde un entorno de espacio aislado de Python para analizar secciones específicas de documentos.
Por qué las ventanas contextuales no son suficientes
Considere una tarea típica de análisis financiero que consiste en comparar métricas de dos años de informes anuales de una sola empresa. Cada informe tiene entre 300 y 500 páginas. Agregue informes de analistas, presentaciones ante la SEC y materiales complementarios y el total llega a millones de caracteres.
Cuando envía estos documentos directamente a un modelo, la entrada excede el límite de la ventana de contexto del modelo y la solicitud falla, o la entrada encaja pero el modelo tiene dificultades para atender la información en medio de entradas largas, a menudo denominado el problema "perdido en el medio".
Ambos modos de falla existen porque el tamaño de la ventana de contexto es un límite estricto que la ingeniería rápida por sí sola no puede resolver. Necesita un enfoque que desacople el tamaño del documento de la ventana contextual del modelo.
RLM: Tratar el contexto como un entorno
RLM, presentados por Zhang et al. en arXiv:2512.24601, reformule el problema. En lugar de introducir un documento completo en la ventana contextual del modelo, un RLM trata la entrada como un entorno externo con el que el modelo interactúa mediante programación.
Figura 1. Los modelos de lenguaje recursivo funcionan como un bucle iterativo: el LLM raíz genera código para explorar el entorno del documento, delega el análisis semántico a los sub-LLM en fragmentos seleccionados y acumula los resultados en la memoria de trabajo antes de refinar el siguiente paso.
El modelo recibe solo la consulta y una descripción del entorno disponible. Luego escribe código para buscar, dividir y analizar el documento de forma iterativa. Cuando el modelo necesita comprensión semántica de una sección específica, delega ese análisis a una llamada sub-LLM, manteniendo los resultados en la memoria de trabajo como variables de Python en lugar de consumir espacio de ventana de contexto.
Esto crea una estructura recursiva: el LLM raíz organiza el análisis a través de código, llamando a sub-LLM según sea necesario para tareas semánticas, mientras que el documento completo nunca ingresa a la ventana de contexto del modelo.
Arquitectura
Aquí, mostramos cómo implementar RLM utilizando Amazon Bedrock AgentCore Code Interpreter como entorno de ejecución. Amazon Bedrock AgentCore Code Interpreter proporciona un tiempo de ejecución de Python en espacio aislado con estado persistente en todas las ejecuciones. La arquitectura tiene tres componentes que trabajan juntos.
Un agente raíz LLM, creado con el SDK de Strands Agents, recibe la consulta del usuario y decide qué código ejecutar. Una sesión de Amazon Bedrock AgentCore Code Interpreter se ejecuta en modo de red PÚBLICA, con el documento completo cargado como una variable de Python. Una función llm_query() inyectada en el entorno sandbox llama a Amazon Bedrock directamente desde el intérprete de código, por lo que los resultados del sub-LLM permanecen en variables de Python y no regresan a la ventana de contexto del LLM raíz.
Figura 2. Arquitectura RLM utilizando el intérprete de código AgentCore de Amazon Bedrock. El agente raíz LLM escribe y ejecuta de forma iterativa código Python en un entorno de espacio aislado donde los datos de entrada completos están precargados. Desde dentro del sandbox, el agente puede llamar a sub-LLM a través de Amazon Bedrock para realizar análisis semánticos de secciones específicas. Los resultados intermedios permanecen como variables de Python en el entorno de pruebas, lo que mantiene la ventana de contexto del LLM raíz centrada en la orquestación.
El modo de red PUBLIC de Amazon Bedrock AgentCore Code Interpreter admite esto al permitir que el entorno de pruebas realice llamadas API salientes a Amazon Bedrock. El estado de sesión persistente significa que las variables, los resultados intermedios y los datos extraídos se acumulan en múltiples ejecuciones de código, lo que proporciona al modelo una memoria de trabajo que persiste durante todo el análisis.
Implementación
Siga estos pasos para configurar y ejecutar RLM con Amazon Bedrock AgentCore Code Interpreter.
Requisitos previos
Para seguir esta publicación, necesita:
Una cuenta de AWS con acceso a los modelos básicos (FM) de Amazon Bedrock. Python 3.10 o posterior. La interfaz de línea de comandos de AWS (AWS CLI) configurada con las credenciales adecuadas. Familiaridad con Python y uso básico de AWS SDK (Boto3). Un intérprete de código AgentCore de Amazon Bedrock configurado con el modo de red PÚBLICA. Permisos de IAM para bedrock:InvokeModel, bedrock-agentcore:StartCodeInterpreterSession, bedrock-agentcore:InvokeCodeInterpreter y bedrock-agentcore:StopCodeInterpreterSession.
1: Inicie una sesión de Code Interpreter y cargue el documento
Cree una sesión de intérprete de código de Amazon Bedrock AgentCore y escriba el documento en el entorno de pruebas:
2: Inicialice el documento y defina el asistente llm_query() dentro del sandbox
Dentro del entorno sandbox, cargue el documento y defina la función llm_query() que utilizarán las llamadas sub-LLM:
3: Cree el Agente de Strands y ejecute su consulta
Cree un agente de Strands con una única herramienta ejecutar_python que ejecute código en la sesión y luego envíe su pregunta:
El agente escribe y ejecuta de forma iterativa código Python para explorar el documento, extraer secciones relevantes y llamar a llm_query() cuando necesita un análisis semántico de fragmentos específicos.
Evaluación
En nuestra evaluación, comparamos RLM con dos líneas de base, a saber, Base y Contexto Largo. En el enfoque Base, el documento completo se envía directamente al modelo en una única llamada API con una ventana de contexto de token de 200K. Esta es la estrategia más sencilla, pero falla cuando los documentos exceden la ventana de contexto del modelo. En el enfoque de contexto largo, utilizamos la ventana de contexto extendida de 1 millón de tokens de Claude, que maneja entradas más grandes pero aún tiene un límite superior y puede sufrir problemas como "perdido en el medio".
Evaluamos este enfoque en el subconjunto de control de calidad de múltiples documentos financieros de LongBench v2, un punto de referencia diseñado para probar el desempeño de LLM en tareas que requieren razonamiento en contextos prolongados. Este subconjunto contiene 15 preguntas de opción múltiple, cada una de las cuales requiere un análisis de múltiples informes financieros con una longitud de contexto de hasta aproximadamente 2 millones de caracteres.
Informamos dos métricas: tasa de éxito, el porcentaje de preguntas que el modelo puede procesar sin exceder los límites de entrada o encontrar errores, y precisión, el porcentaje de respuestas correctas del total de preguntas formuladas (las preguntas sin respuesta cuentan como incorrectas).
Comparamos tres enfoques como se describió anteriormente: base, contexto largo y RLM. Evaluamos RLM en cuatro modelos de Claude que sirven como LLM raíz, donde el sub-LLM se configuró como el mismo modelo o Haiku 4.5 para equilibrar el rendimiento y la eficiencia. Usamos Claude Haiku 4.5 como sub-LLM porque ofrece una latencia y un costo significativamente menores para el análisis localizado a nivel de fragmentos, mientras que el modelo raíz conserva la responsabilidad del razonamiento y la orquestación globales.
Tabla 1. Control de calidad de múltiples documentos financieros de LongBench v2 (15 preguntas). Precisión de expertos humanos del artículo LongBench v2. Los resultados base para Claude Sonnet 4.6 y Opus 4.6 se omiten porque estos modelos tienen una ventana de contexto predeterminada de 1 millón de tokens, lo que hace que los enfoques Base y Contexto largo sean equivalentes.
Enfoque del modelo Tasa de éxito Precisión Claude Haiku 4,5 Base 46,7 % 33,3 % Claude Haiku 4,5 + Haiku 4,5 RLM 100,0 % 66,7 % Claude Sonnet 4,5 Base 46,7 % 26,7 % Claude Sonnet 4,5 Contexto largo 93,3 % 66,7 % Claude Sonnet 4,5 + Haiku 4.5 RLM 100.0% 66.7% Claude Soneto 4.6 Contexto largo 93.3% 60.0% Claude Soneto 4.6 + Haiku 4.5 RLM 100.0% 73.3% Claude Opus 4.6 Contexto largo 93.3% 66.7% Claude Opus 4.6 + Haiku 4.5 RLM 100.0% 80,0% Experto Humano – – 40%
Los resultados revelan tres hallazgos clave:
RLM alivia los errores de longitud del contexto. Los enfoques de contexto base y largo no logran procesar algunas entradas debido a limitaciones del contexto. El enfoque Base logra una tasa de éxito del 46,7 por ciento (7/15 preguntas), mientras que el Contexto Largo logra un 93,3 por ciento (14/15 preguntas). Por el contrario, RLM logra una tasa de éxito del 100 por ciento en todas las configuraciones evaluadas al desacoplar completamente el tamaño del documento del tamaño de la ventana contextual. A medida que aumenta la escala de los documentos, esta ventaja de confiabilidad se vuelve cada vez más importante para la implementación práctica. RLM mejora la precisión en la mayoría de los modelos. RLM aumenta la precisión para Claude Sonnet 4.6 y Opus 4.6 del 60,0 por ciento y 66,7 por ciento (Contexto largo) al 73,3 por ciento y 80,0 por ciento, respectivamente, y para Claude Haiku 4,5 del 33,3 por ciento (Base) al 66,7 por ciento. La mayor mejora se observa en Claude Haiku 4.5, mientras que los modelos más potentes (Sonnet 4.6, Opus 4.6) muestran ganancias consistentes pero menores. Claude Sonnet 4.5 no muestra ninguna mejora con respecto a la línea base de contexto largo, logrando un 66,7 por ciento en ambos entornos. Esto sugiere que las ganancias de RLM dependen de la eficacia con la que el modelo raíz descompone la tarea en subconsultas, lo que podría limitar las mejoras para Sonnet 4.5 en esta configuración. La elección de un sub-LLM tiene un impacto limitado en este entorno. En experimentos adicionales, comparamos el uso de Claude Haiku 4.5 como sub-LLM con el uso del mismo modelo tanto para raíz como para sub-LLM, y no observamos diferencias significativas en la precisión entre las configuraciones. Esto sugiere que, para esta tarea, el rendimiento está impulsado principalmente por la capacidad del modelo raíz para generar subconsultas efectivas en lugar de la capacidad del sub-LLM para ejecutarlas.
Escalado a la comprensión del repositorio de código: LongBench v2 CodeQA
La evaluación de control de calidad financiera se centra en el razonamiento de documentos de formato largo. A continuación, examinamos la generalización a un dominio diferente: la comprensión del repositorio de código, que requiere navegar por grandes bases de código, resolver dependencias de funciones y rastrear la lógica entre archivos. Esta configuración es particularmente adecuada para la exploración programática mediante la ejecución de código.
Para probar esto, evaluamos el subconjunto Comprensión del repositorio de código de LongBench v2, que contiene 50 preguntas de opción múltiple. Cada pregunta proporciona un repositorio de código completo como contexto (que varía desde aproximadamente 100 000 a más de 16 millones de caracteres) y pregunta sobre detalles de implementación, comportamiento de API o decisiones arquitectónicas que requieren navegar y comprender el código base.
La arquitectura es la misma que para el control de calidad financiero, donde el repositorio completo se carga en el entorno limitado de Code Interpreter como una única variable de contexto. El modelo escribe código Python para buscar archivos relevantes, extraer definiciones de funciones, rastrear cadenas de llamadas y usar llm_query() para analizar secciones de código específicas.
Evaluamos las 50 preguntas utilizando cuatro modelos de Claude con los mismos enfoques. Según el hallazgo del control de calidad financiero de que la elección del sub-LLM tiene un impacto limitado para los modelos más sólidos, fijamos el sub-LLM en Claude Haiku 4.5 en todas las ejecuciones de RLM.
Tabla 2. Comprensión del repositorio de códigos LongBench v2 (50 preguntas).
Enfoque del modelo Tasa de éxito Precisión Claude Haiku 4.5 Base 30.0% 20.0% Claude Haiku 4.5 + Haiku 4.5 RLM 100.0% 64.0% Claude Sonnet 4.5 Base 30.0% 20.0% Claude Sonnet 4.5 Contexto largo 60.0% 46.0% Claude Sonnet 4.5 + Haiku 4.5 RLM 100.0% 76.0% Claude Soneto 4.6 Contexto Largo 60.0% 42.0% Claude Soneto 4.6 + Haiku 4.5 RLM 100.0% 66.0% Claude Opus 4.6 Contexto Largo 60.0% 44.0% Claude Opus 4.6 + Haiku 4.5 RLM 100.0% 74,0%
Los resultados reflejan los hallazgos del control de calidad financiero: RLM logra una tasa de éxito del 100 por ciento en todos los modelos, en comparación con el 30-60 por ciento para el contexto base y largo. La precisión mejora sustancialmente en todos los modelos bajo RLM, y cada modelo alcanza entre 64 por ciento y 76 por ciento, en comparación con 20 a 46 por ciento bajo contexto base y largo.
Cómo funciona el modelo a través de un problema
Para ilustrar cómo funciona RLM en la práctica, a continuación se muestra una secuencia representativa de una de las preguntas de evaluación. Se pide al modelo que compare métricas financieras en dos informes anuales con un total de aproximadamente 1,5 millones de caracteres.
Primero, el modelo busca en el contexto marcadores estructurales para comprender el diseño del documento:
A continuación, se divide en secciones específicas para encontrar tablas de ingresos:
Para el análisis semántico, delega al sub-LLM:
Finalmente, agrega hallazgos en múltiples secciones y llega a una respuesta final.
Consideraciones
Al adoptar RLM para sus cargas de trabajo de análisis de documentos, tenga en cuenta las siguientes ventajas prácticas.
Estado latente. RLM intercambia latencia por capacidad. Según nuestra evaluación de los dos conjuntos de datos de LongBench v2, las ejecuciones de RLM individuales varían desde aproximadamente 10 segundos para preguntas sencillas hasta varios minutos para preguntas complejas con contextos amplios, y la mayoría se completa en unos pocos minutos. Para el procesamiento por lotes o el análisis fuera de línea, esta compensación está bien justificada. Para aplicaciones en tiempo real, considere si la tarea realmente requiere procesar documentos más allá de la ventana de contexto del modelo. Costo. Cada ejecución de RLM implica múltiples invocaciones de modelos, tanto el razonamiento iterativo del LLM raíz como las llamadas sub-LLM desde dentro del entorno limitado. Para cargas de trabajo sensibles a los costos, puede utilizar un modelo más pequeño (como Haiku 4.5) como submodelo y, al mismo tiempo, mantener un modelo más grande como raíz para reducir los costos y mantener la precisión. Ingeniería rápida. El mensaje del sistema afecta la eficiencia con la que el modelo utiliza sus herramientas. Sin orientación, los modelos tienden a realizar llamadas secundarias a LLM innecesarias para validar su propio razonamiento o imprimir resúmenes intermedios detallados mediante la ejecución de código. Las instrucciones claras sobre cuándo utilizar la ejecución de código en comparación con cuándo razonar reducen directamente las llamadas a herramientas desperdiciadas y mejoran la latencia de un extremo a otro.
limpiando
Para evitar cargos continuos, detenga la sesión de Amazon Bedrock AgentCore Code Interpreter cuando se complete el análisis:
Si creó un recurso de intérprete de código dedicado para este tutorial y ya no lo necesita, puede eliminarlo a través de la consola de Amazon Bedrock AgentCore o la CLI de AWS.
Conclusión
Los modelos de lenguaje recursivo ofrecen un camino práctico para procesar documentos que exceden las ventanas de contexto del modelo. Al combinar Amazon Bedrock AgentCore Code Interpreter con el SDK de Strands Agents, puede implementar RLM para razonar sobre datos de entrada arbitrariamente largos mediante la ejecución iterativa de código y llamadas sub-LLM.
En nuestras evaluaciones, los resultados son significativos: Claude Opus 4.6 con RLM logra una precisión del 80,0 por ciento en LongBench v2 Financial QA (en comparación con el 66,7 por ciento para Long Context con una ventana de contexto de 1 millón de tokens y el 40 por ciento para expertos humanos), y Claude Sonnet 4.5 con RLM logra un 76,0 por ciento en LongBench v2 Code Repository QA (en comparación con el 20,0 por ciento para las indicaciones de Base con ventana de contexto de token de 200K, 46,0 por ciento para contexto largo).
Las tareas que requieren razonamiento en contextos extensos o grandes bibliotecas de referencia pueden beneficiarse de este patrón, ya sea análisis financiero, comprensión del repositorio de códigos, investigación de ciencias biológicas y de atención médica, revisión legal o auditoría de cumplimiento. Si prueba este enfoque en sus propias cargas de trabajo de análisis de documentos, queremos escuchar lo que construye. Comparte tu experiencia en los comentarios.
Para comenzar con el enfoque descrito en esta publicación, explore los siguientes recursos:
Referencias
Zhang, AL, Kraska, T. y Khattab, O. (2025). Modelos de lenguaje recursivo. arXiv:2512.24601 Bai, Y., Tu, S., Zhang, J., Peng, H., Wang, X., Lv, X., Cao, S., Xu, J., Hou, L., Dong, Y., Tang, J. y Li, J. (2024). LongBench v2: hacia una comprensión y un razonamiento más profundos en multitareas realistas de contexto largo. arXiv:2412.15204
Sobre los autores
Yuan Tian
Yuan es científico aplicado en el Centro de innovación de IA generativa de AWS, donde diseña e implementa soluciones de IA generativa, desde la recuperación de conocimientos hasta la IA de voz y sistemas de agencia, para clientes empresariales que abarcan atención médica, ciencias biológicas, energía, finanzas y más. Aporta una formación interdisciplinaria que combina IA/ML con biología computacional y tiene un doctorado. en Inmunología de la Universidad de Alabama en Birmingham.
Anran Wang
Anran es científico aplicado en el Centro de innovación de IA generativa de AWS. Trabaja con los clientes para identificar casos de uso adecuados y acelerar su adopción de la IA generativa. Se especializa en evaluación de modelos y le apasiona la sostenibilidad y la atención sanitaria.
Evandro Franco
Evandro es un científico de datos senior que trabaja en Amazon Web Services. Es parte del equipo Global GTM que ayuda a los clientes de AWS a superar los desafíos comerciales relacionados con AI/ML en AWS, principalmente en Amazon Bedrock AgentCore y Strands Agents. Tiene más de 18 años de experiencia trabajando con tecnología, desde desarrollo de software, infraestructura, serverless hasta aprendizaje automático. En su tiempo libre, a Evandro le gusta jugar con su hijo, principalmente construir divertidos ladrillos Lego.
Isaac Privitera
Isaac es científico de datos principal en el Centro de innovación de IA generativa de AWS, donde desarrolla soluciones basadas en IA agentes personalizadas para abordar los problemas comerciales de los clientes. Su principal objetivo es construir sistemas de IA responsables, utilizando técnicas como RAG, sistemas multiagente y ajuste de modelos. Cuando no está inmerso en una IA agente, se puede encontrar a Isaac en el campo de golf, viendo fútbol o haciendo caminatas por senderos con su leal compañero canino, Barry.
Haochen Xie
Haochen es científico de datos sénior en el Centro de innovación de IA generativa de AWS. Es una persona común y corriente.
Jared Kramer
Jared es gerente de ciencias aplicadas en Amazon Web Services con sede en Seattle. Jared se unió a Amazon hace 12 años como pasante en ML Science. Actualmente lidera el equipo de científicos aplicados y arquitectos de aprendizaje profundo en el Centro de Innovación de IA Generativa, habiendo pasado anteriormente 6 años en Tecnologías de Servicio al Cliente y 4 años en Ciencia e Innovación de la Sostenibilidad.
Anila Joshi
Anila tiene más de una década de experiencia en la creación de soluciones de inteligencia artificial. Como gerente sénior de ciencias aplicadas en el Centro de innovación de IA generativa de AWS, Anila es pionera en aplicaciones innovadoras de IA que amplían los límites de las posibilidades y aceleran la adopción de los servicios de AWS con los clientes, ayudándolos a idear, identificar e implementar soluciones seguras de IA.