Orquestación de IA Full-Stack: Agentes Modulares, Observabilidad y el Edge

Así que bienvenidos a Nueva York, si están aquí desde Nueva York. Así que comencemos con la charla. Gracias por venir a unirse. Mi nombre es Jamal O'Garro. Soy un ingeniero en Netflix, actualmente en la organización de la plataforma de datos, trabajando en el equipo de la plataforma de experimentación. Así que cualquier prueba de experimentación A-B a la que puedan ser asignados aleatoriamente, soy el equipo que básicamente hace que eso suceda. He estado en algunos equipos en Netflix. He estado en ingeniería de infraestructura, ingeniería de plataformas, ciencia de datos e ingeniería, y ahora estoy en la plataforma de datos. He estado allí por un poco menos de cuatro años, así que he visto bastante de la empresa. Antes de unirme, básicamente pasé toda mi carrera trabajando en finanzas, principalmente construyendo estrategias y software de trading algorítmico y trading sistemático. No muy lejos de aquí en JC. Más personal sobre mí, soy un fanático del hip hop, un fanático de las zapatillas, soy fanático de los Yankees, Giants, Rangers, y un fanático acérrimo de los Knicks. Vamos, Knicks. La primera foto es mía en la cima de la oficina de Netflix en Los Ángeles. La segunda es mía en la cima de un volcán en Hawái, representando a los Knicks. Así que se pone real.

Muy bien. Así que vamos a preparar el escenario para esta charla. Principalmente estamos aquí para hablar sobre inteligencia artificial, como la gran cosa que está sucediendo ahora mismo. Todo es IA, IA en todas partes. Y nosotros, como ingenieros de JavaScript, probablemente estemos en uno de los mejores lugares para comenzar a integrar parte de esta experiencia a los usuarios. Y me di cuenta de que mi pantalla está parpadeando un poco. Veamos si puedo arreglar eso. Así que disculpas. Muy bien. Así que voy a dar un poco de contexto sobre qué es la IA para nuestros propósitos. Aquí hay una definición literal de libro de texto, pero no estamos aquí para leer definiciones de libros de texto. Vamos a decir que para nuestros propósitos, un sistema de IA es básicamente solo un software que sabe cómo razonar y realizar algún tipo de acción dentro de un sistema. Y si damos un paso atrás y vemos cuáles son las principales áreas de la inteligencia artificial, vemos que es un campo bastante amplio, ¿verdad? Que contiene el aprendizaje automático como un subconjunto.

Que contiene el aprendizaje automático como un subconjunto. Básicamente estamos tratando de tomar datos y hacer que nuestros programas aprendan de esos datos. Y si profundizamos un poco más, nos vamos a centrar aquí en nuestra charla en el aprendizaje profundo, donde tienes esta construcción muy agradable que puedes haber oído o visto, llamada red neuronal artificial, que se parece a un árbol de la vida si lo volteas de una manera, dependiendo de en qué tipo de cosas estés fuera del trabajo. O es básicamente solo un algoritmo simple que básicamente toma entradas y hace un muy buen trabajo entrenando estas cosas aquí, llamadas estas capas ocultas, para tratar de encontrar formas óptimas de aproximar algún tipo de función. Eso es realmente bueno para predecir datos, clasificar, clasificar algún tipo de datos u objetivo. Y a lo largo de los años, hubo un cambio en esa arquitectura llamada transformer.

Creo que algunas personas en Google publicaron un artículo llamado Attention is All You Need, donde añadieron algunos trucos bastante interesantes y ingeniosos a la arquitectura para básicamente crear este tipo de estructura que es realmente buena para realizar predicciones y análisis secuenciales, básicamente. Y resultó que era realmente buena para predecir grandes secuencias de texto a partir de un corpus muy grande. Y lo que hizo fue dar a luz a todos estos geniales modelos de lenguaje grandes como Chachi, BTE, Grok, DeepC, Claude, Gemini, que probablemente todos estamos usando hoy y tratando de averiguar cómo podemos integrarlos dentro de nuestros sistemas de producción. Creo que la historia divertida aquí es que Google publicó el artículo, pero OpenAI lo implementó primero. Y tuvieron la ventaja del primer movimiento para lanzar Chachi, BTE y abrir las compuertas. Así que miramos hacia atrás en el espectro de LLM, ¿dónde se sitúan? Básicamente se sitúan aquí como un subconjunto del aprendizaje profundo, ¿verdad?

Es un caso de uso muy específico. Así que ahora hablemos un poco más sobre los agentes, en los que nos vamos a centrar hoy. Y básicamente para nuestros propósitos, un agente es simplemente una pieza de software inteligente que sabe cómo interpretar el lenguaje natural. Puede tomar decisiones. Puede hacer cosas como interactuar con API, consultar una base de datos, obtener contexto de un usuario, tener una conversación completa y en vivo, como probablemente veas dentro de Chachi, BTE. Típicamente, como están construidos usando otros modelos de lenguaje grandes. También pueden ser construidos a partir de otros agentes. Así que vamos a hablar de eso hoy. Como cómo construyes un agente de agentes que puede estar compuesto de muchos modelos de lenguaje grandes diferentes que pueden desempeñar lo mejor, que es la mejor herramienta para el trabajo. Algunas de las principales capacidades que obtienes son la capacidad de llamar herramientas. Así que las herramientas son como habilidades simples, como habilidades especiales que puedes dar a un agente o modelo de lenguaje grande. Así que piensa en llamar a una API, consultar una base de datos, ¿verdad? Simplemente sabe cómo hacer eso y hacerlo bien.

Puedes definirlo como una función. Y tu modelo de lenguaje sabe cómo llamarlo, cómo acceder a él y obtener datos de él para realizar su tarea. También tienen un concepto de memoria. Así que probablemente uses algo como un código en la nube o cosas así. Sabes, tienes que tener cuidado con tu contexto cuando se vuelve demasiado grande. Eso es como la parte de memoria de ello.

Pero también con los agentes, tenemos un estado compartido, particularmente cuando miras el programa que vamos a ver hoy llamado LandGraph. Verás cómo esa memoria se modela como un estado. Y si estás familiarizado con React, es muy similar a eso. Y luego una de las partes más poderosas de estos son estas IA's. Tienen estas capacidades de planificación y razonamiento que lo hacen muy, muy poderoso para construir estos sistemas dinámicos de los que vamos a hablar más hoy.

Así que esos sistemas se llaman sistemas agénticos. Básicamente es cualquier software impulsado por IA o agente. Lo principal es que difieren de tu sistema de IA simple. Simplemente vamos a llamar a un chat GPT y obtener una respuesta. Es que estos agentes tienen capacidades de razonamiento donde el flujo no es lineal. Así que no solo estás obteniendo entrada de un modelo de lenguaje grande y pasándola como en una naturaleza de avance. Estas cosas podrían ser cíclicas donde pueden tomar diferentes ramificaciones y diferentes enfoques basados en el contexto que tienen en su estado, lo que los hace muy dinámicos y también muy difíciles de mantener en producción como resultado.

Con eso dicho, con el trasfondo ahí, hablemos de algunas de las cosas interesantes. Así que vamos a hablar más sobre cómo construimos algunos de estos sistemas de IA agénticos para producción. Bien. Así que como una rápida muestra de manos, diría, ¿cuántas personas aquí han usado una aplicación impulsada por un modelo de lenguaje grande? Bien. Como todos. Bien. Entonces, ¿cuántas personas en la audiencia han construido una aplicación impulsada por un modelo de lenguaje grande? Bien. Ya sea por diversión. OK. Así que menos manos.

Así que última pregunta. Mantén tus manos arriba. Si tu respuesta es sí a esto. ¿Cuántas personas han desplegado realmente uno de estos sistemas y lo han hecho funcionar de manera confiable durante meses? OK. Tenemos una persona. Así que probablemente voy a aburrirte y no me abuchees. Pero ahora solo estoy bromeando. Así que probablemente voy a aburrirte aquí. Pero de nuevo, también es probablemente algo que podemos aprender. Así que definitivamente quiero charlar contigo después de esto. Así que lo principal aquí es que construir sistemas de IA agénticos es difícil. ¿Verdad?

Es como Vecna diría que ya perdiste. ¿Verdad? Si estuvieras en Stranger Things ahora mismo, sería él tratando de plantar esa semilla en tu mente. Pero si eres como yo o como nuestro amigo Hopper aquí, sabes, llevando un lanzallamas, vas a ser como, pero ¿por qué? Tiene que haber una manera de que realmente podamos superar este obstáculo y realmente construir sistemas verdaderamente probados que puedan funcionar en producción. Y tengo que preocuparme por mucho de la naturaleza impredecible de algunos de estos modelos de lenguaje. Así que estoy aquí para decir que algunos de los principales desafíos con la construcción de estos sistemas, supongo que puedes resumirlos en estos tres puntos aquí.

Definitivamente hay más que esto, pero algunos de los principales diría que es que en el pasado cuando pensábamos en la ingeniería de IA, realmente se trataba de, OK, ¿cómo entrenas un modelo? ¿Cómo lo comprimes? ¿Cómo lo cuantizas? Tal vez incrustarlo en el navegador o aplicación móvil para hacer la inferencia más rápida. Haces algún entrenamiento offline para actualizar las formas de tu modelo y cosas por el estilo y averiguar cómo hacer eso sin tener tiempo de inactividad para el usuario.

Pero eso es más como ese flujo lineal donde probablemente estás tratando de realizar una tarea especializada. Pero ahora estamos como estos nuevos modelos que pueden hacer muchas cosas diferentes. Tienen capacidades de razonamiento y no hay manera de predecir lo que van a hacer. Tenemos que tomar un enfoque diferente. Correcto. Así que ahora mismo, en realidad estás tratando de tomar algo que tiene algún tipo de inteligencia que puede hacer lo que quiera hacer en el sistema. Probablemente puedas restringirlo por alguna cantidad, pero tienes que ser capaz de averiguar cómo puedes construir un sistema alrededor de eso en el que puedas confiar.

Así que piensa, por ejemplo, si estás tratando de incrustar esto en dispositivos médicos o usarlo para cosas como la aplicación de la ley, donde si te equivocas o tu modelo alucina, puede tener consecuencias muy graves. Quieres asegurarte de que te estás protegiendo contra eso. Y lo que estoy aquí para decir es que el mayor problema es como las alucinaciones son una cosa, pero es solo una pequeña parte del problema. Diré que si miras estos sistemas e intentas escalarlos, realmente son en su núcleo un problema de orquestación de sistemas distribuidos.

Y luego, ¿por qué digo eso? Es que estamos usando estos sistemas de modelos de grandes números, ¿verdad? Principalmente van a usar herramientas para intentar llamar a algún tipo de API, intentar ir a una base de datos. Están interactuando con el usuario y pueden desempeñarse de manera diferente dependiendo del tipo de prompts que reciban o qué datos reciban o pueden acceder a una API y podría agotarse el tiempo o podría fallar. Correcto. Y eso podría ser un punto único de falla para todo tu flujo agente. Correcto. Si el usuario necesita obtener alguna información de alguna fuente crítica y la API no está disponible, como el agente probablemente sepa que debe reintentar. Tal vez lo haga. Tal vez no. Tal vez se rinda y simplemente decida alucinar para darte algunos datos para que pueda avanzar. Correcto. Porque todo lo que quieren hacer es cumplir la tarea de la mejor manera que puedan.

Todos los problemas que como los usuarios de tokens pueden volverse costosos si no se gestionan adecuadamente. Y lo principal que estamos tratando de averiguar es cómo podemos hacer que nuestros sistemas sean resilientes con todos estos problemas que estamos tratando de resolver. Correcto. Así que quiero proponer un stack empresarial moderno. Simplemente tomando algunas herramientas bastante conocidas de la estantería y componiéndolas juntas para intentar crear un sistema que básicamente va a ser robusto. Va a ser escalable. Vas a tener una arquitectura eficiente que te permita realmente como rastrear, ver lo que están haciendo tus modelos, ver qué herramientas están llamando, qué impacto tiene en tu sistema. Te va a dar la capacidad de tener reintentos. Si tu agente intenta hacer una llamada, va a saber cómo reintentarlo una cierta cantidad de veces.

Te va a dar esa durabilidad y también como gestionar el estado entre tu sistema. Así que este stack que voy a cubrir un poco más hoy se compone principalmente de tres piezas. Está LangRaph, LangSmith y Temporal. LangRaph. ¿Alguien ha oído hablar de una cadena Lang antes? Y nuestro LangRaph. Sí. Básicamente está hecho por la gente de la cadena Lang. Básicamente te permite modelar tu gráfico como una especie de modelo, tu agente como un gráfico. Así que es como un DAG básicamente que te permite.

Bueno, si usas Lang chain, tiene más de ese procesamiento lineal, ya sabes, obtener mucho de este modelo, obtener una entrada, realizar algún trabajo, obtener una salida y pasarla hacia adelante. No hay como volver entre las secuencias allí.

Luego está LangSmith, una herramienta de realidad que vamos a ver que básicamente te permite ver cada camino que tu agente toma mientras realiza algún tipo de acción. Entonces, si tu usuario le da a tu agente un prompt y digamos que hay un agente enrutador allí que lo dirige a un agente especialista en particular y se enruta a otros 10 agentes a lo largo del camino, tal vez las cosas fueron bien, tal vez las cosas salieron mal. Tienes trazabilidad completa. Entonces, ¿qué pasó allí?

Hay otra herramienta llamada Temporal, que uso bastante extensamente en mi línea de trabajo, que básicamente te da y garantiza una orquestación duradera de flujos de trabajo. Así que aquí estamos viendo al agente de IA, como lo llamo, como este monolito modular. Y lo digo porque la idea aquí es que porque estás construyendo esencialmente un gran gráfico, ¿verdad?, es que puedes seguir construyendo y construyendo más agentes especialistas, habilidades especializadas, dándoles más herramientas, más formas en que pueden interactuar entre sí con el tiempo donde puede simplemente crecer por separado a cualquier otro sistema de terceros que quiera interactuar con esto, como una aplicación móvil o interfaz de voz de texto a voz.

Simplemente puede crecer. Simplemente sigues construyendo su cerebro y se vuelve más y más inteligente a medida que lo amplías con más agentes en el sistema. Lo bueno de eso es que cada agente se enfoca en una cosa en particular, una tarea muy especializada, y lo hace realmente, realmente bien. Así que hay menos posibilidades de que cometa errores y cause problemas. Y estos agentes están trabajando juntos y forman un gran cerebro para tu sistema.

Y lo genial de esta arquitectura modular es que básicamente puedes tomar problemas muy, muy, muy complejos, dividirlos en piezas más pequeñas, hacer que los agentes trabajen en ellas y todos pueden unirse para resolver el problema más grande. Y luego link graph es una herramienta que básicamente podemos usar para lograr eso. Así que voy a dar un poco de contexto aquí. Voy a mostrar algo de código muy, muy rápidamente. Así que perdóname por aburrirte después del almuerzo. Nadie está durmiendo todavía. Así que, ya sabes, supongo que lo estás haciendo bien.

Pero lo principal para link graph es que básicamente, como mencioné, a menos que definas tus agentes como un gráfico, como ese es todo el flujo de control. Las partes principales de esto, tienes un estado. El estado es básicamente como algunos datos compartidos que simplemente se pasan entre tu sistema y pueden ser accedidos por tus agentes. También pueden actualizarlos. Así que piensas en React. Es muy similar a eso. Tienes algún tipo de objeto de estado y tienes diferentes funciones que pueden operar sobre él y luego producir algún tipo de efecto secundario que actualiza el estado. Y luego esos dos constructos en line graph son nodos y aristas.

Así que, como tus nodos son como tu lógica principal para tu agente. Eso va a realizar tus transformaciones, obtener algunos datos, realizar algún tipo de efecto secundario. Correcto. Y luego tus aristas básicamente dirigen el flujo de hacia dónde va a ir tu agente después de obtener algún tipo de datos.

Y luego lo bueno de esta estructura es que puedes tener estos ciclos que mencioné donde no tienes que preocuparte por ir linealmente. Básicamente puedes ciclar a través de ellos. Así que aquí hay un ejemplo de Lang chain docs donde puedes ver aquí que tienes un usuario. Lo siento, esto es un poco difícil de leer, pero intentaré acercar un poco.

Así que tienes un usuario. El usuario tiene una entrada donde quieren generar un gráfico de la temperatura promedio de Alaska. Correcto. Así que eso entra en el nodo de investigación. El nodo de investigación va a pasar luego a este enrutador. Va a decir, oye, voy a hacer una llamada para alguna herramienta para obtener de vuelta alguna información. Va a hacer alguna investigación. Va a obtenerla de vuelta.

Va a hacer alguna investigación. Va a obtenerla de vuelta. Va a decir, oye, tengo alguna información. Regresa al enrutador. El enrutador ve que tiene una etapa de continuación. Fue enviado desde el investigador. Así que pasa al generador de gráficos y dice, oye, necesito generar un gráfico de esta información. El generador de gráficos puede decir, OK, perfecto. Tengo suficiente información para regresar al enrutador. Si la información es buena, puedes devolvérsela al usuario o tal vez necesite más dinero. Lo siento, no más dinero. Lo siento.

Veo dónde está mi cabeza aquí estando de vuelta, de vuelta en el centro. De vuelta en Wall Street ahora. Creo que podría perder mi dinero. Tengo que obtener el P&L. Muy bien. Así que necesita más información para que pueda regresar al investigador y este ciclo puede continuar hasta que esté terminado. Correcto.

Es cuando realmente va a regresar al usuario. Así que puedes ver lo poderoso que es esto, donde si estás atascado yendo en una dirección, nunca tendrías ese ciclo de retroalimentación aquí que básicamente te daría la capacidad de tener estos agentes trabajando juntos y produciendo un mejor resultado. Así que algunos de los beneficios de este enfoque son que, como dije, cada nodo es independiente. Puedes probarlo completamente. Verás eso cuando te muestre parte del código. También te da ese enrutamiento condicional basado en el estado. Puedes reutilizar los mismos nodos para diferentes agentes. Así que si tienes un agente que sabe cómo investigar un tema muy particular muy, muy bien, puedes reutilizar eso donde quieras en el sistema.

Entonces, ¿es esto una función pura en ese sentido? Y la parte buena con LangSmith es que tienes completa observabilidad en el sistema.

Así que rápidamente repasaré LangSmith muy rápidamente, porque quiero llegar al código y ser consciente del tiempo, es que lo que LangSmith es básicamente como una infraestructura en la nube proporcionada por la gente de LangChain que te permite básicamente acceder a cada llamada, cada acción que ocurre dentro del flujo de llamadas de tu agente para poder tener una trazabilidad completa de lo que está sucediendo.

Correcto. Así que algunas de las cosas principales que vas a obtener aquí es que tienes la visibilidad completa. Puedes ver cosas como cuánto cuestan tus tokens, cuántos tokens has usado. Correcto. Puedes retroceder y crear esos datos. Puedes ejecutar algún análisis sobre ello para tratar de entender dónde tienes algunos cuellos de botella y las cosas se desglosan entre diferentes proyectos y diferentes hilos. Y aquí hay una pantalla de cómo se ve un rastro real.

Vamos a ver uno en vivo cuando muestre la demostración en un segundo. Pero la idea aquí es que aquí a la izquierda, básicamente estás viendo todos los diferentes agentes, lo que están haciendo, a qué están llamando, qué herramientas están usando y cómo se ve todo el flujo. También inspeccionas las entradas y también puedes ver cosas como cuántos tokens se usaron. ¿Cuál es el costo? ¿Cuál es la latencia asociada con la operación real? Así que tienes una visibilidad realmente buena para ver dónde están algunos cuellos de botella. Así que si los usuarios se quejan de que tus modelos tardan una eternidad en regresar con una respuesta, puedes obtener algo de esa observabilidad aquí dentro de LangSmith. Así que lo siguiente es lo que sucede cuando las cosas se ponen patas arriba. Juego de palabras intencionado. Entonces, ¿qué pasa si construyes tu gran modelo, lo pones en producción, pero luego se agota el tiempo de espera después de 15 segundos esperando una llamada API.

Así que en ese punto, estás prácticamente perdido porque todo el trabajo que has hecho hasta ese momento se pierde. Todo el contexto que construiste probablemente se ha ido a menos que lo guardes en algún lugar manualmente. Tienes que empezar de nuevo. Probablemente no tienes reintentos. Si le dices a tu modelo que lo intente de nuevo, como dije, probablemente podría entrar en un bucle infinito donde no es lo suficientemente inteligente como para saber que no puede avanzar más o incluso podría inventar algunos datos solo para seguir adelante, lo cual probablemente no puedas detectar. Correcto. A menos que realmente estés inspeccionando los datos y entonces tu estado no está persistido. Correcto. Así que lo más importante de estos agentes es que tienen un estado que todos pueden actualizar y del que pueden leer. Pero si explotas en el entorno, y no tienes nada para respaldarlo, entonces estás acabado. Comienzas todo el proceso de nuevo, lo cual puede ser bastante costoso en cuanto al uso de tus tokens. Así que algo de lo que preocuparse o pensar al respecto.

Así que lo siguiente es temporal. Así que temporal es básicamente un orquestador de flujos de trabajo que básicamente te permite construir flujos de trabajo duraderos que son básicamente tolerantes a fallos. Si explota con una ejecución, siempre podrías retroceder porque mantiene un historial de todas las transacciones que se ejecutaron. Y si fallaste, por ejemplo, como en el ejemplo que tuvimos con el agente, básicamente reproduciría todo. Pero en lugar de ejecutar una operación nuevamente, lo extraerá como del caché, de este historial y luego simplemente lo aplicará. Así que proporciona estos flujos de trabajo y actividades deterministas. Y lo principal a tener en cuenta es que tenemos flujos de trabajo que son básicamente como la unidad principal de orquestación que simplemente orquesta todas las diferentes actividades y acciones que ocurren dentro de él. Así que piensa en llamar a tu modelo agentic y luego la actividad o todas las cosas que ese modelo está haciendo. Correcto. Realizando investigaciones, añadiendo citas y yendo de un lado a otro para obtener algún consenso antes de devolverte mis datos y cosas por el estilo.

Y lo bueno de esto es que antes de que usáramos estos sistemas en producción sin tener estas dos capas aquí, tener lo que tengo temporal es que tienes dos capas de durabilidad a nivel de gráfico y en los dos niveles de llamada. Así que si explotas durante la ejecución del gráfico, siempre puedes recuperarte y reproducir desde esa parte del fallo. Y lo mismo con cada llamada de herramienta individual también. Así que aquí hay algunas capturas de pantalla rápidas de cómo se ve la pantalla temporal. Puedes ver todas las actividades y flujos de trabajo. Estas actividades aquí básicamente te dan una línea de tiempo de cuánto tiempo ha tardado en ejecutarse y también si tuvieron éxito o fallaron. También podrían profundizar en todas las entradas y salidas reales que recibes. Así que en nuestro caso del agente o cada agente o nodo dentro de nuestro gráfico de agentes, puedes ver las entradas y salidas reales de cada turno.

Así que tienes todo ese historial ahí para ti. Así que muchos beneficios son como mencioné, tienes flujos de trabajo duraderos. Tienes cosas como reintentos integrados en un sistema duradero que está construido para ello. Podrías observar cada acción que se está tomando en tu sistema que se estaba llamando. Y también puedes escalarlo porque ejecutas múltiples trabajadores en paralelo.

Y lo último que estamos tratando de decir aquí es que si vas a construir este gran marco de agencia, debería simplemente vivir detrás de algún back end para tu front end, porque la idea es que puedes construir este agente, hacerlo crecer, puedes volverte inteligente, adquirir más habilidades sin tener que preocuparte por empujar o cambiar el código de la UI. Como resultado, básicamente puedes tener todas tus UIs conectadas al mismo BFF. A medida que el modelo se vuelve más inteligente, adquiere más habilidades. Así que como usualmente puedes verlo volverse más inteligente sin siquiera entender toda la complejidad que ocurre detrás de escena en el back end.

Así que muy rápidamente, solo voy a mostrar esto, sé que es difícil de leer, pero esta es una idea de cómo se ve nuestro POC. La idea aquí, tienes algún tipo de cliente, en nuestro caso, solo vamos a curl este servidor Express. El servidor Express hace todo lo que básicamente hace. Tiene algo de seguridad, algo de enrutamiento que está ahí. Lo principal es que a medida que recibe solicitudes, va a comenzar a activar nuestra infraestructura temporal, que va a tomar eso y comenzar a enviar información para activar nuestro gráfico de capas, que está representado aquí. Y luego lo que sucede es que cada paso de estos nodos en este gráfico, luego activará sus propios flujos de trabajo temporales separados que tienen sus propias actividades. Así que si algo falla aquí o si la actividad falla o el flujo de trabajo falla, pueden reiniciar y reanudar exactamente donde lo dejaron sin tener que preocuparse por dañar todo el sistema.

Así que vamos muy rápidamente a esta demostración. Solo les mostraré muy brevemente parte del código. Así que esto aquí es como una aplicación simple de Express, como mencioné. Y ves aquí está desglosado como si tuvieras tu sección de agente. Así que todo aquí es donde definirías como tu gráfico real. Así que aquí están tus nodos y tus bordes. Así que una cosa aquí es un nodo de guardrail. Ese nodo de guardrail básicamente es como si estuvieras diciendo que estás creando un nodo en el sistema que asegura que no estás enviando de vuelta información personalmente identificable. No hay lenguaje ofensivo ahí. No estás haciendo nada malo. Y este nodo se supone que asegura que nada básicamente se rompa como un formateador de respuestas que está ahí.

Como ves aquí, básicamente son solo funciones asíncronas que toman el estado. Realizan algún tipo de acción y devuelven ese estado. Correcto. Para algunos cambios en algunos metadatos, lo cual es muy similar a como si estuvieras usando React, cómo probablemente funcionaría un reducer. Se parece mucho a eso. Y luego aquí tenemos este borde que básicamente solo dice que cuando recibimos un mensaje proveniente de uno de estos agentes en particular, sabemos a dónde navegar una ruta basada en parte de la lógica como la que se parece a esa pantalla que te mostramos hace un momento con el mensaje.

Así que déjame intentar ir al código. Lo tengo en GitHub. Puedes mirarlo. Pero la idea aquí es básicamente que esto es básicamente lo que es. Y luego si miras en el BFF como un servidor simple de React, lo siento, como un servidor simple de Express, entonces nuestros trabajadores temporales están definidos aquí. Y básicamente lo que sucede, cada uno sabe cuándo llama a esta herramienta, solo llama a una actividad temporal. Así que voy a mostrarte ahora mismo que esta cosa realmente está funcionando porque si estoy mintiendo, estoy volando. Correcto. Así que déjame asegurarme de que estoy aquí diciéndoles la verdad. Así que solo voy a hacer un curl. Puedes leer esto como dice el próximo fan. Así que aquí mismo tenemos tres agentes. Cuando puedo verificar probabilidades, cuando puedo verificar hechos deportivos y el que puedo realizar alguna investigación arbitraria para ti.

Así que voy a hacerle un par de preguntas. Vamos a rastrearlo a través del sistema. Así que aquí este dice verificar la afirmación de que Steph Curry ha hecho más de 300, tres mil quinientos triples en su carrera. Y los New York Knicks son el equipo contra el que ha anotado más puntos. Correcto. Y vemos aquí que obtenemos algo de información. Volvemos a la respuesta. Dice que los mensajes que informan sobre las estadísticas de carrera de Steph Curry son precisos. Bla, bla, bla. Y dice que los Knicks son el equipo contra el que Steph Curry ha anotado más puntos. Nuevamente, no sé si es cierto o no. Podría estar alucinando. El modelo que se usa aquí es como este flash. Así que obtienes todos esos metadatos aquí también.

Pero lo interesante es que si quisiera ver si hay un mejor modelo para usar o un mejor camino a seguir. Puedo ir a Lingraph y puedo ver exactamente qué se envió y cuál fue el camino completo. Puedo ver exactamente que llamó a la herramienta de verificación de estadísticas. La llamó dos veces. Correcto. Así que supongo que fue como solo verificar y confirmar. Puedes ver exactamente qué llamó, qué hizo. Puedes ver aquí que estaba haciendo llamadas reales a Gemini. Todo esto usando la estructura de Lingraph. Y si voy a Temporal, por ejemplo, puedo ver aquí que esto fue realmente llamado.

Supongo que el problema principal es que puedo ver cuáles fueron las entradas, cuáles fueron las salidas. Así que eso fue exitoso. Si falló y lo mismo para cada actividad que se generó también. Así que podemos ver aquí que la actividad de verificación de estadísticas realmente se pasó aquí. Obtienes las líneas completas, cuánto tiempo tomó. Puedes ver exactamente qué se pasó y cuál fue el resultado.

Así que puedes ver que obtienes esa trazabilidad completa en tu sistema. También aquí hay una biblioteca llamada creo que Tivili que puede realizar algunas de las búsquedas. Entonces, lo que hace es que llama detrás de escena. Así que ves aquí que estoy en una cuenta gratuita y aumenté de 17 a 21 después de hacer esa llamada.

Así que te mostraré un ejemplo más donde voy a preguntar simplemente la probabilidad de que los Miami Hurricanes, soy un gran fanático del fútbol universitario. Mi equipo no está yendo muy bien, pero veamos si los Hurricanes van a llegar a los playoffs este año. Correcto. ¿Alguien aquí es fan de Miami? OK, genial. Sí, estoy con Penn State. Así que, ya sabes, tuvimos una mala temporada este año, pero ganamos la semana pasada. Sí. Un saludo al Coach Terry.

Muy bien. Así que, sí. Ahí vamos. Así que ves aquí basado en una investigación, la probabilidad estimada de que los Miami Hurricanes lleguen a los playoffs de la CFP esta temporada es del 95 por ciento. Así que eso definitivamente no voy a, no sé. Supongo que están ahí. ¿Verdad? Están ahí ahora. ¿Verdad? Tal vez no lo sé. No voy a criticar. No voy a criticar a los Hurricanes, pero te da un descargo de responsabilidad.

Así que este es un guardarraíl incorporado aquí donde siempre tiene que poner un descargo de responsabilidad sobre todas las probabilidades que te vende. Eso es solo para fines educativos. Y que hay diferentes cosas que entraron en ello. Así que dice aquí mismo, análisis solo para fines educativos no debe usarse o considerarse como consejo de apuestas. Las probabilidades son probabilidades y deportes y cosas por el estilo.

Así que muy rápidamente, sé que tengo que correr, pero solo volveré a las diapositivas. Y luego solo te mostraré como algunas de las mejoras que podemos haber hecho a este sistema es que hay formas de hacerlo más robusto agregando una arquitectura de envejecimiento más compleja. Así que aquí solo creamos algunos nodos de agentes que hacen cosas específicas. Y teníamos algunos bordes que redirigirían diferentes agentes basados en los resultados que obtienen.

Pero podemos hacer cosas como tener este supervisor de agentes y equipo de agentes jerárquico. Podemos tener un agente supervisor que es un modelo más grande, como, por ejemplo, Opus, que puede hacer el razonamiento y la planificación de tareas y luego dárselo a modelos más pequeños como Sondra. Genial. Para decir, oye, yo hago el pensamiento por ti. Todo lo que tienes que hacer es hacer el trabajo. Aquí está tu plan para ejecutarlo. Correcto. Se ha encontrado que esa es una forma de mejorar realmente el rendimiento de estos modelos.

Y luego lo mismo con tener equipos de agentes jerárquicos y tener múltiples modelos independientes que tienen que discutir entre sí y llegar a un consenso. Es como todas estas cosas realmente geniales que la investigación dice que puedes hacer para obtener un mejor rendimiento al usar múltiples modelos en lugar de uno.

Otra cosa que también puedes hacer es la selección dinámica de modelos de lenguaje grande. Así que puedes usar cualquier modelo bajo el sol que sea el mejor para tu tarea. Puedes mirar Langsmith para ver cómo es el rendimiento y hacer ajustes allí también. También hay agentes que pueden optimizar tus tokens. Básicamente pueden tener tokens máximos.

Puedes hacer cosas como decirle que no debería ir. Sabes, X cantidad de tokens. Si lo hace, puede compactar tus conversaciones automáticamente. Y si usas como cloud code, ves que también hace algunas de las cosas por ti de forma gratuita. Pero es como una mejor práctica incorporada en esto. Así que se puede usar para optimizar tus costos. Y luego otras cosas como consideraciones de seguridad en la escalabilidad también.

Así que puntos clave. Y luego he terminado. Aprecio su paciencia aquí es que usamos estos large language models en producción. Correcto. Hay un montón de cosas que pueden salir mal de las que probablemente no estás pensando una vez que tienes tu primer chat GPT API configurado y estás, ya sabes, haciendo solicitudes. Y estás sobre el presupuesto de una empresa de mil millones de dólares. Es como si tu sistema tuviera que ser resiliente a fallos, cosas que pueden fallar en todo el tablero. Y luego estos modelos son geniales, pero no son buenos para ser resilientes a lanzar esos problemas por sí mismos y luego auto-repararse. Tal vez puedas entrenarlos. Pero si tenemos sistemas en su lugar como land graph para darte esa trazabilidad de lo que el modelo está realmente haciendo. Y luego temporal para darte esos flujos de trabajo y actividades duraderas.

Así que cada vez que tu agente llama a un servicio externo o sale de tu sistema central, puedes estar seguro de que al menos será duradero. Definitivamente debería hacerte dormir, ya sabes, más tranquilo por la noche. Con eso en mente, nuevamente, Langrath hace que sea muy fácil depurar tu modelo. Puedes ver exactamente lo que produce, cuáles fueron las salidas, si llamar, por qué llamó algo, por qué no llamó algo. Te da un rastro de papel muy agradable para volver a la depuración. Y lo bueno es que puedes básicamente, ya sabes, poner todo lo que ves en este ejemplo aquí. Todo está en un contenedor Docker. Es todo Docker compose. Todo está ejecutándose desde Postgres a Express a temporal. Todo está ahí. Despliegas todo de una vez. Es como app runner o algo así. Y puedes simplemente obtener este cerebro inteligente en constante crecimiento que tú y tu equipo están construyendo con el tiempo. Y luego creo que has usado herramientas de observabilidad como Langrath y Langsmith y temporal. Puedes acercarte un paso más a tener un sistema más robusto.

Así que quiero agradecerles a todos por su tiempo. Así que muchas gracias por esta gran, esta gran sesión. Y creo que tuvimos algunas preguntas llegando en el Slido. Y no olviden, amigos, que el Slido es un gran lugar para hacer preguntas. Así que creo. Sí. Bueno, una cosa es sobre la escala de Netflix. ¿Verdad? No todos tenemos los mismos tipos de problemas que podría tener la ingeniería de Netflix. Y entonces una pregunta que hace Anónimo es ¿cómo manejan Landgraf y Temporal la escala de llamadas de agentes de Netflix? ¿Cómo se siente la UX cuando estás tratando de hacer tanto? Sí. Así que descargo de responsabilidad completo, como no estamos usando esto en producción. Esto es algo que estoy pensando en probablemente poner ahí afuera. Diría que para la aplicación principal de Netflix orientada al cliente, creo que definitivamente tienes que hacer mucho de tu típica ingeniería de rendimiento para asegurarte de que estás manejando las solicitudes correctamente. Te aseguras de que estás manejando tu tiempo de espera. No estás evitando cosas como una situación de estampida. No estás como explotando tus sistemas u otros sistemas también. Así que hay más cosas en las que pensar. Y Netflix tiene muchas partes móviles y también es de mayor riesgo debido a los clientes, como donde me siento dentro de la experimentación, estamos construyendo más una plataforma. Así que probablemente sea menos preocupante en ese sentido en términos de cuántas solicitudes estamos recibiendo o cuántos, supongo, como cuántos tokens probablemente estamos usando. Pero si fuera para la aplicación principal de Netflix, sería un enfoque totalmente diferente que tomarías para resolverlo desde la forma en que probablemente estoy proponiendo aquí es probablemente un poco ingenuo. Genial, genial, genial. Y creo que tenemos un montón de otras preguntas llegando. Pero una, por ejemplo, es sobre tu elección de usar TypeScript en lugar de Python, que uno a menudo ve en el código de back end de agentes. Así que la pregunta es, ¿por qué usé TypeScript y no Python? Porque esta no es una conferencia de Python, ¿verdad? No esperaba esa. Soy un Pythonista, pero también escribo mucho JavaScript y Node y un poco de Kotlin y Java. Soy más un políglota. Pero en el trabajo, haría estas cosas en Python. Pero sin embargo, porque soy un JavaScript, he estado escribiendo Node por un tiempo. Estoy muy apasionado por este espacio. Y es realmente genial y poderoso que estas herramientas estén realmente construidas para nosotros JavaScript.

Correcto. Así que realmente quería mostrar que si piensas que estás bloqueado para profundizar en estas cosas porque no escribes Python y no quieres hacer Python o R, que estas cosas están aquí en JavaScript. Todo esto es JavaScript en toda la línea. Correcto. No hay Python aquí en absoluto. Todo es Node. Así que si quieres comenzar a construir esta arquitectura, puedes construirla hoy en el stack de Node y no hay nada que te detenga de hacerlo. Correcto. Lo escuchaste aquí primero, amigos. Puedes hacerlo todo con JavaScript. Así que vamos a hacerlo.

Creo que eso es todo por nuestro tiempo de preguntas y respuestas. Pero habrá más preguntas y respuestas con Jamal allá arriba después. Así que, por favor, un gran aplauso para Jamal. Muchas gracias. Gracias. Gracias. Vengan a hablar conmigo. Estoy feliz de charlar.