Todo lo que necesita saber sobre los modelos de lenguaje recursivo

En este artículo, aprenderá qué son los modelos de lenguaje recursivo, por qué son importantes para el razonamiento de entrada larga y en qué se diferencian de los sistemas estándar de sugerencia, recuperación y agencia de contexto largo.

Los temas que cubriremos incluyen:

Por qué el contexto largo por sí solo no resuelve el razonamiento sobre entradas muy grandes Cómo los modelos de lenguaje recursivo utilizan un tiempo de ejecución externo y subllamadas recursivas para procesar información Las principales compensaciones, limitaciones y casos de uso práctico de este enfoque

Vayamos directo al grano.

Introducción

Si está aquí, probablemente haya oído hablar de trabajos recientes sobre modelos de lenguaje recursivo. La idea ha sido tendencia en LinkedIn y X, y me llevó a estudiar el tema más profundamente y a compartir lo que aprendí con ustedes. Creo que todos podemos estar de acuerdo en que los modelos de lenguajes grandes (LLM) han mejorado rápidamente en los últimos años, especialmente en su capacidad para manejar grandes entradas. Este progreso ha llevado a muchas personas a asumir que el contexto prolongado es en gran medida un problema resuelto, pero no lo es. Si ha intentado dar a los modelos entradas muy largas cercanas o iguales a su ventana de contexto, es posible que haya notado que se vuelven menos confiables. A menudo pasan por alto detalles presentes en la información proporcionada, contradicen declaraciones anteriores o producen respuestas superficiales en lugar de razonar cuidadosamente. Este problema a menudo se denomina “pudrición del contexto”, que es un nombre bastante interesante.

Los modelos de lenguaje recursivo (RLM) son una respuesta a este problema. En lugar de introducir más y más texto en un único paso hacia adelante de un modelo de lenguaje, los RLM cambian la forma en que el modelo interactúa con entradas largas en primer lugar. En este artículo, veremos qué son, cómo funcionan y los tipos de problemas para los que están diseñados.

Por qué un contexto prolongado no es suficiente

Puede omitir esta sección si ya comprende la motivación de la introducción. Pero si tienes curiosidad, o si la idea no encajó del todo la primera vez, déjame desglosarla más.

La forma en que funcionan estos LLM es bastante simple. Todo lo que queremos que el modelo considere se le proporciona como un mensaje único y, en función de esa información, el modelo genera la salida token por token. Esto funciona bien cuando el mensaje es breve. Sin embargo, cuando se vuelve muy largo, el rendimiento comienza a degradarse. Esto no se debe necesariamente a límites de memoria. Incluso si el modelo puede ver el mensaje completo, a menudo no lo utiliza de manera efectiva. Aquí hay algunas razones que pueden contribuir a este comportamiento:

Estos LLM son principalmente modelos basados ​​​​en transformadores con un mecanismo de atención. A medida que la indicación se hace más larga, la atención se vuelve más difusa. El modelo lucha por centrarse claramente en lo que importa cuando tiene que atender a decenas o cientos de miles de tokens. Otra razón es la presencia de información heterogénea mezclada, como registros, documentos, código, historial de chat y salidas intermedias. Por último, muchas tareas no consisten solo en recuperar o encontrar un fragmento relevante en una gran cantidad de contenido. A menudo implican agregar información en toda la entrada.

Debido a los problemas discutidos anteriormente, la gente propuso ideas como el resumen y la recuperación. Estos enfoques ayudan en algunos casos, pero no son soluciones universales. Los resúmenes generan pérdidas por diseño y la recuperación supone que la relevancia se puede identificar de manera confiable antes de que comience el razonamiento. Muchas tareas del mundo real violan estos supuestos. Por eso los RLM sugieren un enfoque diferente. En lugar de obligar al modelo a absorber todo el mensaje de una vez, dejaron que el modelo explorara y procesara activamente el mensaje. Ahora que tenemos los antecedentes básicos, veamos más de cerca cómo funciona esto.

Cómo funciona en la práctica un modelo de lenguaje recursivo

En una configuración RLM, el mensaje se trata como parte del entorno externo. Esto significa que el modelo no lee toda la entrada directamente. En cambio, la entrada se encuentra fuera del modelo, a menudo como una variable, y el modelo solo recibe metadatos sobre el mensaje junto con instrucciones sobre cómo acceder a él. Cuando el modelo necesita información, emite comandos para examinar partes específicas del mensaje. Este diseño simple mantiene el contexto interno del modelo pequeño y enfocado, incluso cuando la entrada subyacente es extremadamente grande. Para comprender los RLM de manera más concreta, veamos paso a paso una ejecución típica.

Paso 1: inicializar un entorno REPL persistente

Al comienzo de una ejecución de RLM, el sistema inicializa un entorno de ejecución, normalmente un REPL de Python. Este entorno contiene:

Una variable que contiene el mensaje de usuario completo, que puede ser arbitrariamente grande. Una función (por ejemplo, llm_query(…) o sub_RLM(…)) que permite al sistema invocar llamadas de modelo de lenguaje adicionales en fragmentos de texto seleccionados.

Desde la perspectiva del usuario, la interfaz sigue siendo simple, con una entrada y una salida textuales, pero internamente el REPL actúa como un andamio que permite un razonamiento escalable.

Paso 2: invocar el modelo raíz solo con metadatos rápidos

Luego se invoca el modelo de lenguaje raíz, pero no recibe el mensaje completo. En cambio, se da:

Metadatos de tamaño constante sobre el mensaje, como su longitud o un prefijo corto. Instrucciones que describen la tarea. Acceda a instrucciones para interactuar con el mensaje a través del entorno REPL.

Al retener el mensaje completo, el sistema obliga al modelo a interactuar con la entrada intencionalmente, en lugar de absorberla pasivamente en la ventana de contexto. A partir de este momento, el modelo interactúa indirectamente con el mensaje.

Paso 3: inspeccionar y descomponer el mensaje mediante la ejecución de código

El modelo podría comenzar inspeccionando la estructura de la entrada. Por ejemplo, puede imprimir las primeras líneas, buscar títulos o dividir el texto en fragmentos según los delimitadores. Estas operaciones se realizan generando código, que luego se ejecuta en el entorno. Los resultados de estas operaciones se truncan antes de mostrarse al modelo, lo que garantiza que la ventana de contexto no se vea abrumada.

Paso 4: Emitir subllamadas recursivas en sectores seleccionados

Una vez que el modelo comprende la estructura del mensaje, puede decidir cómo proceder. Si la tarea requiere comprensión semántica de determinadas secciones, el modelo puede emitir subconsultas. Cada subconsulta es una llamada a un modelo de lenguaje independiente en una porción más pequeña del mensaje. Aquí es donde realmente entra en juego la parte “recursiva”. El modelo descompone repetidamente el problema, procesa partes de la entrada y almacena resultados intermedios. Estos resultados viven en el entorno, no en el contexto del modelo.

Paso 5: ensamblar y devolver la respuesta final

Finalmente, una vez recopilada y procesada suficiente información, el modelo construye la respuesta final. Si la salida es larga:

El modelo lo construye incrementalmente dentro de una variable REPL, como Final. Una vez que se establece Final, el bucle RLM termina. El valor de Final se devuelve como respuesta.

Este mecanismo permite que RLM produzca resultados que excedan los límites de token de una llamada de modelo de lenguaje único. A lo largo de este proceso, ninguna llamada a un modelo de lenguaje único necesita ver el mensaje completo.

¿Qué diferencia a los RLM de los agentes y los sistemas de recuperación?

Si pasa tiempo en el espacio LLM, puede confundir este enfoque con marcos agentes o generación de recuperación aumentada (RAG). Sin embargo, estas son ideas diferentes, incluso si las distinciones pueden parecer sutiles.

En muchos sistemas de agentes, el historial completo de conversaciones o la memoria de trabajo se inyecta repetidamente en el contexto del modelo. Cuando el contexto crece demasiado, la información más antigua se resume o se elimina. Los RLM evitan este patrón por completo manteniendo el aviso externo desde el principio. Los sistemas de recuperación, por el contrario, se basan en la identificación de un pequeño conjunto de fragmentos relevantes antes de que comience el razonamiento. Esto funciona bien cuando la relevancia es escasa. Los RLM están diseñados para entornos donde la relevancia es densa y distribuida, y donde se requiere la agregación de muchas partes de la entrada. Otra diferencia clave es la recursividad. En los RLM, la recursividad no es metafórica. El modelo literalmente llama a modelos de lenguaje dentro de bucles generados como código, lo que permite escalar el trabajo con el tamaño de entrada de forma controlada.

Costos, compensaciones y limitaciones

También vale la pena destacar algunas de las desventajas de este método. Los RLM no eliminan el costo computacional. Lo cambian. En lugar de pagar por una única invocación de modelo muy grande, se paga por muchos más pequeños, junto con la sobrecarga de ejecución y orquestación del código. En muchos casos, el costo total es comparable al de una llamada estándar de contexto prolongado, pero la variación puede ser mayor. También existen desafíos prácticos. El modelo debe ser capaz de escribir código confiable. Los modelos mal restringidos pueden generar demasiadas subllamadas o no terminar limpiamente. Los protocolos de resultados deben diseñarse cuidadosamente para distinguir los pasos intermedios de las respuestas finales. Estos son problemas de ingeniería, no fallas conceptuales, pero aun así son importantes.

Conclusión y referencias

Una regla general útil es la siguiente: si su tarea se vuelve más difícil simplemente porque la entrada es más larga, y si el resumen o la recuperación perderían información importante, probablemente valga la pena considerar un RLM. Si la entrada es corta y la tarea es simple, una llamada al modelo de lenguaje estándar generalmente será más rápida y económica. Si desea explorar los modelos de lenguaje recursivo con más profundidad, los siguientes recursos son puntos de partida útiles: