Rompiendo el Techo del Contexto: Implementación de Modelos de Lenguaje Recursivos con LangGraph y TypeScript

Hola Node Congress. Mi nombre es Jamal Legaro. Soy un ingeniero de software senior en Netflix, trabajando en la plataforma de experimentación, y bienvenidos a mi charla, Rompiendo el Techo del Contexto, Modelos de Lenguaje Recursivos en TypeScript, o Cómo Procesar Documentos 100 Veces Más Grandes que la Ventana de Contexto de tu LOM Usando LangRep. Hablemos más sobre el problema con las ventanas de contexto. Si usas modelos de lenguaje grandes en herramientas como Claw, Gemini, Claw to Code, puedes notar que cuando eliges tus modelos, típicamente tienen un límite en su ventana de contexto, usualmente entre 128,000 a 1 millón de tokens. Pero una cosa que no te dicen es que el rendimiento realmente va a degradarse a medida que comienzas a pasar por esos tokens. Hay un efecto de pérdida en el medio que básicamente dice que a medida que comienzas a llenar esa ventana de contexto, y te acercas al límite, tu modelo solo puede recordar eficientemente lo que está al principio o al final del contexto. Y todo en el medio básicamente se pierde o se olvida, o es más difícil de encontrar. Y lo que eso hace es causar una degradación en el rendimiento real de tu modelo de lenguaje grande. Entonces, algunos ejemplos de dónde esto puede suceder es, digamos, si tienes documentación de API, estoy pensando en múltiples documentos a través de múltiples aplicaciones, y estás tratando de juntar alguna información para averiguar cómo funciona el sistema en un sentido más amplio, o estás tratando de encontrar algún tipo de cambios disruptivos en las muchas notas de lanzamiento, haciendo algo de depuración o triaje. Y debido a esta pérdida en el medio, probablemente te perderás los cambios que estás buscando, porque el contexto es demasiado grande. Esto también sucede para bases de código muy grandes. Imagina si tuvieras toneladas de documentos de postmortems de incidentes que estás tratando de revisar, y luego muchas especificaciones técnicas. La idea es que cuanto más grande sea el texto, más se convierte en un problema. Entonces, una forma de evitar esto es usar algo llamado un modelo de lenguaje recursivo. Y esto proviene de algunos estudiantes e investigadores en MIT. Y la idea es bastante simple. Lo que dicen es que, en lugar de poner todo el documento en tu prompt para inflar ese contexto, o prácticamente ocupar mucho de tu contexto, lo que puedes hacer es descomponer recursivamente ese texto en piezas más pequeñas, y luego tener un modelo orquestador que escriba código determinista, y tenga sub, diré sub, digamos, engendros de sí mismo o copias de sí mismo, que realicen esa operación de búsqueda de texto. Y luego devolvemos algunos metadatos y una versión condensada del texto que el orquestador más grande puede usar para realmente tomar una decisión. Entonces, antes de profundizar en eso, probablemente sea un bocado, probablemente mucho que desempacar, pero vamos a pasar por ello poco a poco, ¿verdad? Así que vamos a desglosarlo en piezas más pequeñas para que podamos entenderlo. Así que primero veamos los dos enfoques diferentes. Entonces, el documento habla de uno llamado el andamio estándar. Eso es a lo que estás acostumbrado hoy. Básicamente, si estás usando Cloud Code o usando Codex, y estás mirando tu prompt, usualmente verás como en la esquina inferior derecha o en algún lugar dentro del terminal o dentro de esa interfaz, cuánto contexto has usado realmente en una sesión. Y una vez que llegas a cierto nivel, se auto-contactará por ti y básicamente comprimirá toda esa información en una versión más pequeña de sí misma para devolverte algo más de contexto, pero aún entender lo que estás trabajando dentro del sistema. Eso es un poco problemático porque lo que realmente sucede es que comienzas a perder algo de información porque esa compresión en sí misma es con pérdida, ¿verdad? No estás manteniendo todo. Ahora, el avance aquí, y lo que el documento propone, es que hay un nuevo tipo de algoritmo o arquitectura que podemos usar llamado un modelo de lenguaje recursivo, o un RLM. Y básicamente lo que hace, tiene tres cosas principales que quieres tener, como manejadores simbólicos, programación simbólica y recursión simbólica. Y luego hablaremos de eso. Pero el concepto principal aquí, si miras el pseudocódigo aquí, la idea aquí es que si tienes un entorno, ¿verdad?

, en el que tu modelo de números grandes está trabajando, realmente no hay necesidad de almacenar tu estado en el modelo en sí.

Pero quieres pasarlo en contexto porque el modelo no puede acceder a él, ¿verdad? Y luego lo que haces es que puedes mantener tu historial, pero en lugar de todo el historial del prompt que tiene que ser compactado con el tiempo, puedes realmente pasar solo algunos metadatos sobre él y luego cuál es el estado actual. Y luego lo que parece es que tienes el OAM, tomas tu historial, luego produce algún código. Desde allí, ese código se ejecuta, el estado se asocia con él, y esta ejecución aquí es como una replicación de sí mismo, de otro agente o varios agentes que básicamente realizarán ese código. Así que piensa en como cortar la lista de textos. Una vez que obtiene el texto, probablemente pasará un prompt que dice, encuentra alguna información relevante en este texto, ¿está aquí? Sí, pásalo de vuelta al modelo orquestador actual. El orquestador puede entonces tomar eso y todo el otro contexto para todos los otros agentes que han surgido, y decidir sintetizar al final y luego proporcionar un resultado final. Así que lo bueno es que tu prompt vive en el entorno y tienes este agente orquestado que básicamente crea copias de sí mismo y luego permite que esas copias analicen el texto real del documento, y luego devuelvan un resumen al modelo más grande. Como resultado, nunca pones el prompt completo o el documento completo en el modelo real. Y luego eso básicamente te ahorra mucho, no tanto tiempo, pero definitivamente te ahorra algo de contexto y también algunos costos. Así es como funciona ese algoritmo a un alto nivel.

Así que comparemos ambos enfoques. Así que como el andamio es que la principal diferencia es que estás poniendo el prompt completo dentro de tu ventana de contexto. Así que por muy grande que sea, cuántos tokens tenga ese prompt, o que tenga ese documento, eso básicamente llena la ventana de contexto con esa cantidad. Así que estás moviendo ese espacio desde el principio. Luego lo que sucede a medida que tu historial crece, porque estás agregando más información, se está guardando más contexto, porque estás en el mismo sistema, la misma sección, continúa creciendo. Vas a ver que tu historial crece mucho más rápido. En el enfoque RLM, solo estás pasando resúmenes y metadatos sobre lo que está sucediendo. Así que eso mantiene la ventana de contexto pequeña, solo suficiente información para entender dónde estás en la recursión y luego qué información tienes. Así que el orquestador puede realizar varias acciones como detenerse, continuar generando elementos de sí mismo o saber que tiene suficiente información para devolverte una respuesta. Luego está la recursión en sí misma. Así que lo que sucede aquí, es programático en RLM. Lo que significa que realmente estás escribiendo código que va a ser ejecutado. Mientras que en la versión estándar, básicamente estás pasando otro prompt o instrucción como llama a esta herramienta o responde a esta pregunta por mí. Así que esa es una de las principales diferencias entre este enfoque y el enfoque de sub-agente con el que puedes estar familiarizado. Luego el tamaño de salida, estás limitado por K, que es el tamaño del contexto del modelo con el que estás trabajando. Pero si estás usando esta estructura RLM en teoría, estás técnicamente sin límites. Porque solo estás tomando pequeños fragmentos de datos, estás generando instancias más pequeñas de RLMs que viven y mueren a medida que pasan información de vuelta. Y el sistema está construido de tal manera que no deberías poder exceder la ventana de contexto en ese orquestador principal porque solo estás ingiriendo suficiente información para tomar una decisión informada. Así que para profundizar en nuestra arquitectura, tenemos tres componentes principales. Está el orquestador, que es solo un modelo lingüista grande que genera código.

Recibe nuestros prompts y nuestros metadatos. Y decide qué código de texto va a escribir para explorar nuestro prompt que está en nuestras ventanas de contexto. Creo que es algún documento que estamos cargando. Y luego decide cuál va a ser la estrategia de slicing y recursión. ¿Qué parte del documento deberías cortar? ¿Cuántas particiones deberíamos tener? Y luego, ¿cuántas llamadas recursivas para crear un nuevo modelo de gran lingüista o instancia de RLM debería crear?

Luego, el ejecutor de código va a iniciar una sesión de nodo. Y luego dentro de eso, va a ejecutar ese código que se le estaba pasando. Va a actualizar su estado. Y va a llamar a este callback de análisis, que va a analizar los datos y luego devolver los resultados al orquestador para decidir si debería pasar por otro ciclo de ejecución para generar más, los llamaremos sub LLMs, o si debería pasar y sintetizar el resultado para producir una respuesta final.

Entonces, ¿por qué funciona esto? Básicamente es como si no perdieras ningún contexto al poner ese documento grande o prompt en la ventana de contexto. Así que la ventana de contexto del modelo de gran lingüista principal se mantiene muy, muy pequeña porque siempre está analizando fragmentos de ella y obteniendo resúmenes de vuelta porque el prompt vive fuera de un entorno externo. Y sabe cómo pasar una referencia a ese entorno a los modelos de gran lingüista reales que va a generar. Y luego tienes esta recursión programática, que básicamente solo se ejecuta en un bucle. Llama a una función especial de análisis que tenemos que decide si debería generar algunas nuevas instancias o sintetizar los datos que tiene. Y luego lo bueno de esto es que el modelo de gran lingüista decide qué hacer, no lo decidimos programáticamente, lo cual es la parte muy interesante. Y luego lo que sucede es que en cada turno, en cada ciclo, el LLM va a inspeccionar los resultados y decidir qué hacer. Escribirá más código y refinará ese código para analizar más ese texto y obtener la información que necesita. Y una vez que tiene todo, entonces avanza. Así que ese es el concepto, pero ¿cómo construimos esto realmente, verdad?

Es realmente agradable porque te permite crear un grafo de ejecuciones lleno de nodos y aristas, donde los nodos son tus agentes y tus aristas son cómo los agentes están básicamente conectados entre sí. Tienes gestión de estado incorporada de forma gratuita. Básicamente puedes usar reducers para manejar la acumulación de tus resultados. Piensa en tus metadatos y los resultados que tienes para cada subnivel de información de RLM que devuelve. También tienes enrutamiento condicional. Puedes decidir condicionalmente a qué nodo deberías ir o qué acción deberías tomar. ¿Deberías generar otra instancia y ejecutar más código, o deberías devolver el contexto que tienes de vuelta por la tubería? ¿Deberías llamar a alguna función de utilidad y hacer más particiones, o deberías sintetizar los resultados? Así es como deberías pensar en eso. Langchain también funciona muy bien con TypeScript. Tienen un SDK oficial. Así que es bueno para nosotros como desarrolladores de nodos de TypeScript. Y luego básicamente puedes usarlo con Anthropic, OpenAI, prácticamente cualquiera de los modelos principales y también una herramienta bastante fácil llamada Langsmith, que veremos. Así que no es solo un envoltorio alrededor de grandes modelos de lenguaje. Básicamente te da un tiempo de ejecución de ejecución para ayudar a hacer flujos de trabajo complejos de agentes como el que estamos proponiendo aquí en esta charla.

Así que profundizamos en algunos de los conceptos principales. Los cuatro componentes principales en los que nos vamos a centrar son nodos. Y puedes pensar en estos como funciones que simplemente realizan algún trabajo. Toman el estado, que se almacena dentro de Langraph, y luego harán algún trabajo y luego devolverán algún tipo de resultado. Así que si piensas en React, en cómo funciona React, tienes un estado, luego se realizan algunas operaciones sobre él, luego se devuelve una nueva versión del estado. Puedes pensarlo de esa manera. Las aristas definen cómo conectamos realmente los nodos entre sí en el grafo. Así que como el inicio es como un nodo de inicio especial y como un nodo final, podemos conectarlo usando estos métodos de agregar arista. Pero la idea es que usamos estas aristas para construir nuestro grafo y controlar la mayor parte de nuestro flujo.

Así que el estado es básicamente lo que es. Es como un objeto que simplemente contiene algunos valores y luego puedes tener algunas funciones, como funciones de productor, por ejemplo, para ayudar a calcular nuevos valores. Y luego tienes aristas condicionales que básicamente te permitirán decidir condicionalmente a qué nodo regresar basado en algún tipo de lógica o condición, de ahí el nombre aristas condicionales. Así que cuando juntamos todo eso, podemos tomar las constantes del RLM y mapearlo a Langraph. Así que ese manejador simbólico, ¿verdad? Así que eso es básicamente solo un nombre elegante para decir como un puntero real a tu prompt o tu gran documento que básicamente puede ser almacenado en el estado dentro de Langraph. La programación simbólica es básicamente manejada por nuestro nodo ejecutor de código que simplemente sabe cómo escribir texto con onFly en un contexto de nodo vs vm. Y tu recursión simbólica es básicamente como, ya sabes, llamar de vuelta al contexto principal de VM para devolverle algunos más datos y luego decidir a qué nodo debería pasar usando esa arista condicional. Y luego lo mismo con la iteración, básicamente puedes, ya sabes, ciclar de vuelta entre nodos y nodos.

Y luego lo mismo con la iteración, básicamente puedes, ya sabes, ciclar de vuelta entre nodos y nodos. Así que, por ejemplo, este orquestador va a un bucle de ejecutor de código o va a sintetizador una vez que ha terminado. Y luego hay algo de seguridad allí, siendo que cuando usamos este contexto vmprec, ya sabes, es prácticamente sandbox. No permitimos que pruebe el sistema de archivos, la red o genere cualquier otro procesamiento separado. Así que de nuevo, aquí está esa memoria de grafo a jerga, tenemos el orquestador. El orquestador básicamente llamará al ejecutor de código. El ejecutor de código básicamente decidirá si necesita, ya sabes, volver al orquestador principal. Si el orquestador necesita más información, generará más ejecutores de código y básicamente irá si ejecutamos en término máximo. Así que aquí hay una cosa que mencionar es que queremos establecer un límite en cuántas veces pasaremos por el ciclo, pero no podríamos caer en un bucle infinito. Así que o va a tener suficiente información para básicamente avanzar para sintetizar resultados y dar una respuesta o si detectamos un bucle infinito, vamos a salir de él y luego sintetizar lo que tenemos y luego salir de él.

Bien. Así que aquí estoy mirando mi terminal y luego aquí vamos a tener dos ejemplos y mostraremos el código en esto y brevemente lo que voy a hacer ahora es ejecutar npm run naive. Esto es básicamente un script simple que va a cargar un documento muy grande o una plantilla con un documento muy grande dentro de él. Así que tomemos ese documento por un segundo. Así que esto es esto. Así que imagina que es como alguna gran biblioteca de toda tu documentación técnica y estás tratando de averiguar, ya sabes, cuáles son algunas cosas que están obsoletas que estás tratando de, ya sabes, necesitas hacer para la migración, pero por cualquier razón el documento es tan grande, ¿verdad?, que probablemente apenas podrías, apenas puedo cargar la vista previa porque hay tanto texto. Y digamos que quiero decir, oye, ya sabes, claud o codex, en este caso va a ser firmado, um, 4.5, vamos a decir carga este documento en tu contexto, voy a hacer algunas preguntas al respecto para ayudarme a poner alguna migración. Así que genial, vamos a ejecutarlo y luego, oh no, ¿qué pasa? Nos encontramos con un problema. El prompt es demasiado largo, ¿verdad?, porque nuestro número de tokens excede el máximo. Así que no podemos hacer nada aquí, estamos muertos en el agua, como qué podemos hacer en este momento. Así que lo que podemos hacer es básicamente ejecutar otra versión que usa nuestro RLM que básicamente va a generar tantos sub-agentes. Lo que voy a hacer ahora es simplemente ejecutarlo y simplemente mirar los registros. También veremos otra herramienta llamada Langsmith que nos permite ver el rastro real. Así que ves ahora mismo que realmente carga nuestra configuración, ¿verdad?, le damos la consulta, tenemos Langsmith básicamente como trazando y rastreando cada acción que nuestro gran modelo de lenguaje está haciendo, lleva un registro del costo y otra información que puede ser útil. Así que ahora mismo tenemos el orquestador generando el código, tenemos nuestro sandbox, vemos aquí que obtuvimos ocho secciones que particionamos para análisis, ahora estamos analizando buscando cambios disruptivos, y luego lo que estamos haciendo aquí es que tenemos estas llamadas a este método sub-RLM, que básicamente va a tomar ese código, tomar nuestro contexto existente, y luego simplemente pasar un prompt a él. Vamos a decir cuáles son los cambios disruptivos, danos de vuelta alguna información, y luego ahora vemos al final del día, somos capaces de analizar ese gran texto y obtener algunos resultados reales, ¿verdad?. Así que realmente fuimos capaces de analizar esto y no tomó tanto tiempo. Si miramos aquí y vamos a Langsmith, podremos ver, y voy a cerrar esto, podremos ver como lo que pasó. Podemos rastrear.

Así que eso es lo bueno de Langsmith, obtienes trazabilidad del flujo en esto, incluso hasta el nodo sintetizador, y sabes exactamente qué modelo está vinculado a qué elemento, y luego qué salida, y ves aquí, este es el mismo texto que vimos en Terminal, y luego aquí ves que estos son los inputs. Así que puedes ver cómo funciona esa recursión, mientras que antes intentábamos usar un modelo, básicamente se rompía inmediatamente, y luego si intentábamos usar el RLM, en realidad podía analizarlo dividiendo ese documento en partes más pequeñas simplemente haciendo que el orquestador principal escribiera código arbitrario.

Así que vamos a mirar muy brevemente el código, y luego terminaremos con algunas partes más importantes en estas diapositivas. Puedes ver aquí que tenemos algunas funciones, este router app orchestrator, y esta ejecución de router app son básicamente funciones que se pasan a nuestras aristas condicionales para que sepamos qué nodo quiere regresar. Así que básicamente estamos diciendo que si estamos fuera de términos o ciclos máximos, simplemente volvemos al tamaño de los resultados, de lo contrario iremos al ejecutor de código para ejecutar el código para analizar nuestros datos, y la ejecución de la aplicación de enrutamiento es bastante similar, pero lo que está haciendo es que básicamente dice que si tenemos un resultado final, entonces vamos a sintetizarlo, o si tenemos el orquestador, o si no tenemos un resultado, van a volver al orquestador.

Así que como continuar con ese ciclo, va a generar más instancias de sí mismo y pasar por aquí. Así que nuestra definición de grafo está aquí, así que básicamente solo pasamos un grafo de estado, pasamos nuestro estado, agregamos nuestros nodos, así que orquestador, ejecutor de código, y un sintetizador, y luego agregamos nuestras aristas, agregamos nuestras aristas condicionales, y vemos aquí que estas son dos funciones que miramos para determinar a qué aristas ir, y si continuamos vemos que la arista final es nuestro sintetizador. Una vez que llegamos allí, lo terminamos y compilar compila nuestro grafo.

Si nos adentramos en estas definiciones, básicamente, vemos aquí los nodos reales que estamos definiendo, así que este es nuestro nodo de orquestador que contiene toda la lógica de lo que hace el orquestador, tenemos información de metadatos, tienes el propio prompt que se le pasa para que sepa cómo comportarse y sepa qué pasar a estos sub agentes. Tenemos nuestro nodo ejecutor de código que sabe cómo tomar esa información y luego básicamente cortar y analizar los datos usando varias funciones de utilidad auxiliares. Así que aquí está el ejecutor de código principal, ves la lógica y tiene algunas funciones asociadas con él que puede hacer para crear el sandbox, obtener un resultado, puede hacer algunas vistas previas y otras acciones, también algo de manejo de errores aquí, y nuestro nodo sintetizador va a básicamente tomar nuestro estado final y luego va a, basado en el prompt que se le da, sintetizar una respuesta y devolvérsela al usuario.

Solo para recapitular, comenzamos con el enfoque directo cuando intentamos cargar la ventana de contexto, era demasiado grande y falló de inmediato. Tan pronto como cargamos los datos en el sistema, recibimos un error de la API de Antropic diciendo que son demasiados tokens. Así que podemos ver aquí donde el RLM se vuelve útil, y ejecutamos RLM, en realidad obtuvimos algunos resultados que fueron útiles, fue capaz de identificar exactamente cuáles eran los problemas, así que como número cuatro y después, llamada de modelo de números grandes individuales, sabes que básicamente explotamos tan pronto como enviamos la información, pero luego si usamos el RLM en realidad pudimos descubrir cuáles son algunos de los cambios críticos que rompieron el sistema. Así que algunas cosas a considerar cuando pones esto en producción es como el costo. Vas a obtener un beneficio de costo con esto.

Una cosa que notamos es que al mirar Landgraft, hay un costo allí. Ves que a medida que pasas de 50,000 caracteres a 200,000 a 900,000, cierto, como que el costo sube incrementalmente, no es grande, se mantiene relativamente plano, lo cual es un beneficio de este enfoque, es que va a tomar un poco más de tiempo, pero va a ser mucho más barato, especialmente si estás analizando grandes cantidades de datos. Algunas cosas que quieres considerar si lo pones en producción es como si deberíamos hacer un tiempo de espera. Nuestra implementación es ingenua, no estamos haciendo tiempos de espera, no hay como reintentos o finalización con retroceso que puede ser útil tener como cualquier otro sistema que quieras tener. Podrías querer poner estos aquí antes de poner en producción.