AI Agents Drift: Identificación y Corrección de Fallos Sutiles

Buenas tardes a todos. Mi nombre es Sam. Soy un ingeniero desplegado en el campo convertido en fundador. Mi trabajo diario gira en torno a la construcción de agentes de producción que están realizando una amplia variedad de tareas en la agricultura. Como estoy seguro de que han escuchado hasta el cansancio hoy, y como estoy seguro de que han visto en línea, la tendencia de las empresas de construir sus propios agentes desde cero ya no es una actividad de nicho. Esto es algo en lo que muchas organizaciones están invirtiendo, y las razones son bastante obvias. Las tecnologías detrás de muchas de estas bibliotecas y plataformas son de código abierto. Son gratuitas. Son muy robustas. Además, es mucho más barato. Sabes, si vas a contratar a una empresa externa para que venga y construya estos agentes desde cero, ese es un costo que tendrás que asumir.

Además, de manera crítica, todo el contexto que tú y tu organización tienen sobre tus productos, la historia de tu empresa, el panorama competitivo, todo eso, vas a necesitar condensarlo y de alguna manera dárselo a este tercero. No es un proceso sin pérdidas. A menudo es mucho mejor simplemente construir estas cosas por tu cuenta.

La otra cara de eso, sin embargo, es que ahora eres responsable de mantener estos agentes, arreglarlos cuando están rotos, mejorar su eficiencia, el tiempo que tardan en hacer las cosas. Esencialmente tienes este nuevo sistema que tienes que depurar. La depuración de agentes es este campo que, creo, está madurando más pero aún es bastante nuevo.

Muchas de las plataformas que la gente usa, todavía son muy jóvenes. El objetivo de esta charla es introducir solo algunas de esas tecnologías, cómo se ven esos bucles de retroalimentación, y luego lo concluiré con algunos de los aprendizajes que encontré en algunas industrias diferentes que podrían ser pertinentes para la tuya también. Nuevamente, solo quiero comenzar con lo que realmente es un agente. Nuevamente, estoy seguro de que has visto esto muchas veces hoy, así que no insistiré en ello.

En su núcleo, un agente es algún tipo de modelo de razonamiento ejecutado en un bucle. Se ejecuta en un entorno, por lo que puedes pensar en esto como la arquitectura en la que realmente se está ejecutando. Tiene herramientas que usará para interactuar con ese entorno. De manera crítica, va a tener contexto sobre, nuevamente, tu negocio, cuál es su tarea.

Y luego, además de todo eso, tendrás algún tipo de evaluaciones u observabilidad, tal vez algunos permisos, seguridad, cosas así. Y al mirar esto inmediatamente, es obvio por qué, potencialmente por qué, la depuración de agentes es tan difícil. Si un agente se comporta mal, ¿es probable que sea el modelo? Probablemente no. Pero, ¿podría una herramienta estar mal configurada? ¿Podría haber un contexto faltante o contradictorio? Tal vez hay algún permiso que está desviado. Todas estas cosas podrían ser lo que está causando el mal funcionamiento o la ineficiencia. Y depende de ti rastrear de principio a fin qué exactamente está sucediendo y por qué.

A menudo hago la analogía de que es similar a este paradigma de errores de tiempo de compilación versus tiempo de ejecución, para aquellos de nosotros que somos ingenieros de software. Cuando tu código se compila, si hay algún error con la sintaxis, si una variable ha sido definida incorrectamente, se te dirá muy claramente, específicamente, dónde está el problema y qué es. Es muy fácil de arreglar. Si hay un error de tiempo de ejecución, si ingresas algún tipo de valor en un formulario y eso causa que toda la aplicación se bloquee, o si incluso algo como la solicitud de red está tardando demasiado, hay demasiada latencia, depurar el porqué es una bestia completamente diferente en sí misma. Y esto es mucho más parecido a lo que es la depuración de agentes en realidad. De hecho, es mucho más cercano a casi una evaluación psicológica de lo que está sucediendo, por qué el agente se comporta de cierta manera y qué puedes hacer al respecto.

Específicamente, ¿a dónde van los tokens? ¿Quién está notando esto primero? ¿Son tus ingenieros? ¿Es algún sistema que has configurado? Es un proceso diferente por sí solo. Para solucionar esto, necesitamos observabilidad de agentes. Necesitamos saber qué está pasando, y tenemos que poder solucionarlo. La mayoría de las bibliotecas de observabilidad de agentes, bueno, no debería decir todas, la mayoría de las que encontrarás en línea, están construidas sobre este protocolo de telemetría abierta. Esto proviene de la ingeniería de sistemas, y se adapta bastante bien al paradigma de los agentes. Esencialmente, cuando instancias un agente y le das una tarea, hasta que muere, eso se considera un rastro. Y luego todos los pasos atómicos intermedios, ya sea una llamada de herramienta, un bucle de razonamiento, todo eso, cada uno de esos se considera un span.

Críticamente, cada span va a tener, obviamente, el modelo o la herramienta que fue llamada. También tendrá el número de tokens que se usaron, por lo que puedes deducir el costo a partir de eso. Tendrá cosas como latencia, todas estas diferentes, o incluso cualquier etiqueta que hayas agregado manualmente. Tendrá una plétora de metadatos para que los examines.

Así que digamos que has instanciado un agente, le has dado una tarea y lo has dejado correr. Ahora tienes todos estos spans en el único trace. ¿Qué haces ahora? Bueno, si el agente que fue instanciado funciona durante tal vez media hora, y solo tienes un par de docenas de spans, puedes leerlo bastante fácilmente, linealmente. Verás los diferentes pasos de razonamiento, todas las herramientas que fueron llamadas. Es bastante fácil deducir qué está pasando y por qué. Obviamente, si hay una llamada de herramienta que tal vez no debería haberse hecho, o hay algún error, al mirar el razonamiento justo antes de eso, en el paso de inferencia de LM, a menudo te dirá un poco sobre por qué.

Llegaremos a algunos ejemplos un poco más tarde. Pero esto es más o menos lo mismo cuando se trata de arquitectura multi-agente también, aunque es un poco más difícil. Si tienes múltiples agentes que están operando en el mismo entorno, todos editando los mismos artefactos, puede volverse bastante desordenado, pero muchas plataformas están trabajando activamente en esto desde una perspectiva de UX.

Ahora, la siguiente pregunta lógica es, bueno, si tenemos un trace que, digamos, un agente ha ejecutado durante tres o cuatro horas, y tenemos decenas de miles de spans, ¿vamos a leer eso linealmente? Probablemente no, ¿verdad? La mayoría de las plataformas tienen este concepto de un chat con tu trace, algún tipo de superposición de LM sobre los datos. Esto se hace ya sea alimentando todos los metadatos del trace como parte de la inferencia, o harán cosas ingeniosas como vectorizar la ejecución del agente, todos los diferentes spans, y luego ejecutar la inferencia sobre eso. De cualquier manera, la interfaz para ti es exactamente la misma. Puedes hacer preguntas muy básicas como, resume esta ejecución, ¿dónde estuvo la concentración de tokens? E incluso puedes hacer preguntas como, ¿qué puedo hacer para mejorarlo? Y muy a menudo, obtendrás respuestas muy detalladas y buenas.

El siguiente paso es imaginar que tienes un agente en producción, ¿verdad? Este no es un agente que está trabajando para ti personalmente. Digamos que tienes uno que está en el entorno. Decenas de miles de ellos están funcionando diariamente. Y quieres encontrar patrones en el comportamiento. Si piensas en un agente y en última instancia cuál es su poder, es extremadamente poderoso en el sentido de que puedes darle diferentes bits de contexto, diferentes entradas, incluso diferentes entornos, y aún así podrá operar con un cierto grado de efectividad. El problema, sin embargo, es que si introduces algún tipo de cambio, digamos que añades contexto, añades una herramienta, y quieres ver si hay un cambio en el comportamiento, no es estadísticamente significativo hacerlo solo para una o una docena de ejecuciones de agentes. Tienes que probar cientos y cientos. Y pasar por esos manualmente para deducir la efectividad no es factible.

Este concepto de un clúster tomará lo que mencioné antes sobre vectorizar una ejecución de agente. Tomará esos vectores y luego verá si hay algún clúster de comportamientos, comportamientos específicos que puedas buscar. Estos podrían ser cosas como el uso ineficiente de tokens. Podría ser algo como un usuario que se agita en el curso de una conversación. Todos estos comportamientos serán detectados y luego podrás analizarlos después del hecho, ver si alguno de ellos tuvo lugar, y luego profundizar en las ejecuciones específicas que puedan estar agrupadas allí. Estos son algunos ejemplos de comportamientos comunes que querrás observar. Muy a menudo los clústeres tendrás que configurarlos tú mismo, por lo que no tendrán una opción solo para agrupar en cualquier comportamiento.

Normalmente serán cosas como, como dije, uso ineficiente de herramientas o uso de tokens, si hay demasiado contexto o si hay muy poco. Y luego también creo que uno importante, como mencioné, es si los usuarios se están frustrando o si generalmente les gusta un agente.

Ahora, el lado opuesto de esto es que algunos comportamientos que los agentes llevarán a cabo, cosas como el alto uso de tokens o digamos comportamiento crítico para la misión, no quieres saberlo después del hecho. No quieres tener estos clústeres de cientos de ejecuciones de agentes que cayeron víctimas del alto uso de tokens.

En cambio, lo que quieres configurar es algún tipo de señal que detecte si una ejecución particular de un agente está exhibiendo alguno de estos comportamientos objetivo y luego te notificará a través de Slack o correo electrónico o lo que sea. El proceso para configurarlos es muy similar a los clústeres anteriores. Defines tu comportamiento y como dije, serás notificado en tiempo real si hay un comportamiento del que quieres saber.

Estas son algunas de las señales de ejemplo que creo que vale la pena configurar. Son muy similares a los clústeres que buscarás, excepto que, como dije, serán más críticas para la misión. Entonces, si es algo que no te importa aprender dos semanas después de que sucedió, probablemente no valga la pena configurarlo como una señal. Solo obtendrás costos más altos. Si es algo que va a ser crítico para la misión, entonces querrás saberlo a medida que sucede.

Y luego, la pieza final que muchas de estas plataformas ofrecerán es este concepto de eval o prueba de cambios. Digamos que has definido algún comportamiento que un agente está haciendo incorrectamente y tienes una posible solución, tal vez falta algún fragmento de contexto. Volviendo a nuestro punto original de asegurarnos de que las soluciones se demuestren de manera estadísticamente significativa, ¿cómo defines que tu solución, tu contexto adicional, realmente resolverá el problema? Aquí es donde entra este concepto de evals. Puedes definir criterios de éxito, que podrían ser algo como una cadena o Booleano o un entero, o muy a menudo podría ser simplemente comportamiento en texto plano.

Y muchas de estas plataformas hacen cosas inteligentes en el back end para probar eso. En última instancia, es solo inferencia LM. El resultado es que defines los criterios de éxito, lanzarás un cierto número de pruebas en paralelo, y luego puedes ver claramente si el cambio que hiciste para una variedad de entradas es exitoso. Esto ayuda con cosas como la depuración. Esto también ayuda con cosas como la optimización. Digamos que se lanza un nuevo modelo y en última instancia va a costar cinco veces el precio del estado del arte actual. ¿Quieres integrarlo? Tal vez sí, pero no si no tiene un gran efecto en la efectividad. Esta es una forma en que puedes probar eso.

De manera similar, creo que una tendencia que realmente me entusiasma en los próximos meses o tal vez el próximo año es este concepto de optimización de costos. ¿Podemos usar modelos más baratos, tal vez incluso de código abierto para hacer el trabajo de modelos propietarios? Y si estás trabajando en una organización que quiere optimizar ese costo, no solo quieres lanzar un modelo de peso abierto en tu agente y hacer algunas pruebas dudosas para determinar si sigue siendo efectivo. Esta es una buena manera de probar con diferentes modelos, ver si realmente te da el resultado que aún deseas.

Sí, un poco más sobre ebals. Así que, ahora sobre algunos de los aprendizajes que he obtenido. La primera parte será que la mayoría de los problemas de comportamiento de los agentes son fundamentalmente problemas de contexto. Típicamente, cuando estás depurando por qué un agente tal vez no seleccionó una herramienta particular para el trabajo o dio un consejo incorrecto a un usuario, se reducirá a algo en su ventana de contexto. Ahora, en muchas de las plataformas que he destacado, en cada punto del bucle de inferencia, puedes seleccionar para ver qué exactamente está en contexto en cualquier momento dado. Típicamente, será demasiado grande para revisarlo tú mismo, pero puedes simplemente ejecutar inferencia sobre él y preguntar, ¿está esta información particular allí?

Y es un gran bucle de desarrollo que tendrás. De manera similar, demasiado contexto también será un gran problema, simplemente volcar todo en tu inferencia es, A, va a contaminar la ventana de contexto. Probablemente obtendrás compactaciones mucho más a menudo. Además, lo que es bastante genial es que las compactaciones también están incluidas en muchas de estas observabilidades, por lo que puedes ver exactamente cómo estas diferentes empresas de LLM, cómo compactaron el contexto, lo cual es bastante interesante. Pero sí, no quieres poner demasiadas cosas en contexto. También te da la oportunidad de tener un contexto contradictorio, lo cual será simplemente un problema. Y luego, lo último que mencionaré es este concepto de simplemente volver a los flujos de trabajo multi-agente.

El estado del arte en términos de plataformas de observabilidad es tal que no tienen una gran respuesta para los flujos de trabajo multi-agente. A, porque no creo que la industria los haya adoptado ampliamente. Pero B, es simplemente, es naturalmente un problema de UX difícil, ¿verdad? No sabes, quiero decir, tienes diferentes agentes detectando a otros. Es este extraño problema lineal o no lineal. Y creo que la última parte que diría sobre esto es si tienes una arquitectura multi-agente, no te sorprendas si muchas de las plataformas que miras no lo soportan muy bien. Hay algunas respuestas, pero no muchas.

Así que sí, finalmente, espero que el objetivo de esto sea solo darte un poco de contexto sobre la observabilidad, con suerte convencerte si tienes agentes operando en el campo de instalar una plataforma. No puedo recomendar ninguna específica. Creo que es principalmente una cuestión de preguntar a un LLM. Te dará una respuesta mucho mejor de la que puedo darte yo. Pero es extremadamente importante. Obtienes muchos beneficios de ello. Y muchos de estos sistemas son de código abierto y gratuitos. Así que no te cuesta nada probarlos.

Sí, gracias por tu tiempo. Fantástico, increíble, increíble. Muchas gracias, Sam. Tenemos un par de preguntas en la pantalla. Para Sam, ¿cómo se puede evaluar el éxito de un agente cuyo resultado requiere una interpretación significativa en comparación con un agente con un rango limitado de resultados o un resultado claro de funciona o no funciona? Sí, es una buena pregunta. Así que creo que hay dos opciones para ti. La primera es quizás un poco más cercana a lo que estás preguntando, que es que muchas de estas plataformas te permiten definir evaluaciones con humanos en el bucle. Esencialmente, configuran una plataforma web donde un humano mirará los diferentes, supongo, el resultado de estos diferentes agentes y los juzgará por sí mismos. Así que si tienes una tarea que realmente no puede definirse fácilmente ni por booleanos ni por cadenas o incluso solo por una descripción en texto plano, esta es una buena opción. Sin embargo, diré que la inferencia de LLM ha mejorado bastante, obviamente, dependiendo del modelo que uses, pero puedes definir comportamientos muy vagos, criterios de éxito, y típicamente la plataforma hará un buen trabajo al juzgarlos. Pero sí, el humano en el bucle también es una opción.

Fantástico. La siguiente pregunta que tengo es, leyendo rutas de ventanas de contexto ampliadas, hay muchas observaciones sobre si hay un umbral estricto en el conteo de tokens para entrar en la zona de volcado o un pasaje. ¿Cuál es tu experiencia con esto generalmente? Lo siento mucho. ¿Podrías, entonces está el porcentaje de, es el, Entonces, ¿hay como una especie de umbral estricto para alcanzar como la ruta de tokens? Hmm. Como hacer que tu modelo comience a volverse normal. Sí. En términos de lo que está en contexto. Sí. No lo sé. Quiero decir, obviamente diferentes modelos van a tener diferentes tamaños de ventana de contexto. En términos de un porcentaje, para ser honesto, no creo que haya uno particular para todos los modelos. He usado algunos modelos de peso abierto, como había un poolside o deep seek. Y si su, si su contexto llega a, ya sabes, 50 o 60%, he notado una degradación decente en el rendimiento. Pero luego creo que los modelos propietarios, Sonic, Opus, creo que son bastante buenos en, como puedes llenar el contexto por completo. Pero también tienen estrategias de compactación bastante buenas. Creo que eso es lo que, tal vez lo que sufren los modelos de peso abierto, tienes que implementarlas tú mismo. Así que no lo haría, creo que depende del modelo, desafortunadamente. Sí. Fantástico. Muchas gracias.

Siguiente. ¿Cómo manejas la observabilidad en una situación donde el contenido de las sesiones necesita mantenerse privado? Esa es una gran pregunta. Así que muchas, muchas plataformas ofrecerán algún tipo de servicio de redacción de PII. Lo harán ya sea. Esto es ya sea un proceso manual que puedes configurar similar a las evaluaciones con humanos en el bucle, o puedes configurar algún, algún LLM privado para que lo haga por ti. Básicamente una vez que el, una vez que el, el rastro llega, como texto plano directamente a la plataforma de observabilidad, la PI es redactada y luego pasa por el proceso de agrupamiento, definición de señales, todas estas cosas. Así que sí, la mayoría de las plataformas tendrán eso. Fantástico. Siguiente. ¿Cómo puedes elegir qué contenido, contexto proporcionar? Bien.

Como elegir qué contexto proporcionar. Quiero decir, sí, creo. Así que creo que en general, si no es pertinente, bueno, depende primero de todo, de lo que tu agente está haciendo para algo como desarrollo de software. He encontrado que el contexto alrededor, ya sabes, tu, tu panorama competitivo, la historia de tus aplicaciones. He encontrado que eso es bastante útil cuando el agente está decidiendo qué cambios estructurales hacer en la base de código. Luego de nuevo, si es un agente haciendo algo muy específico, argumentaría que menos contexto, mejor. Creo que como regla general, comenzaría con tan poco contexto como sea necesario. Y, y luego usando eso, el, el bucle de evaluación para potencialmente agregar más contexto y esperando que el, el resultado sea mejor y viendo si lo es y si no lo es, avanzando desde Fantástico.

Creo que ya respondiste esta siguiente, que es cómo haces que el contexto esté disponible por referencia. ¿Puedes expandir sobre esto? Creo que preguntas muy similares. Contexto disponible por referencia. Sí. Lo siento. ¿Qué referencia en qué sentido? Entonces, ¿alguien quiere hablar sobre esto es anónimo aquí mismo. Referencia en contexto disponible por referencia, supongo que tal vez como dijiste, proporcionando la menor cantidad de contexto posible según lo necesites. Sí. Quiero decir, si ref, si te refieres a referencia en términos de como, si, si el, si algo en el bucle de depuración indica que se refiere a un poco de contexto que podrías necesitar o, o está faltando. Entonces yo, creo que de nuevo, de nuevo, comenzando con tan poco contexto como sea posible, como sea posible, solo para no contaminar. Y luego si, típicamente no verás contexto que falta referencia, porque obviamente el agente no va a saber, ya sabes qué, qué, qué está faltando. Pero si, si notas que, ya sabes, herramienta, hay una cierta llamada de herramienta que has introducido y no la está usando o no la está usando correctamente. O si, ya sabes, si estás construyendo un agente de servicio al cliente y hay alguna base de datos que debería ser consultada y no lo está, esos, entonces puedes probar agregando esos al contexto. Y si, si tiene una actualización, espero que eso haya sido útil.

Sí. Eso tiene sentido sobre el tema del contexto. ¿Cómo podrías, cómo podrías, supongo, cómo podría inyectarse el contexto eficientemente para que el agente pueda continuar por más tiempo sin alcanzar límites? Sí. Es una buena pregunta. Creo que es importante este paradigma de como hacerlo a lo que estamos hablando de nuestro punto sobre tratar de no contaminar el contexto. Mucha gente aconsejará similar a cómo funciona MCP, donde a los agentes no se les da esta lista gigante de herramientas y todas las entradas que toma, lo que es útil para ellos se les da una descripción muy breve, tal vez incluso solo el título. Y luego según lo necesiten, harán una consulta.

Entonces, la última pregunta, justo antes de irnos es ¿cómo evolucionas la orquestación de agentes? Cualquier fin está observando tal complejidad y efectos secundarios directos más indirectos. Parece que deberíamos evitar esto tanto como sea posible. Entonces, si por orquestar agentes, te refieres a agentes con mucha infraestructura compleja a su alrededor, creo que en general evitar eso es lo mejor. Obviamente, como dije, si tienes muchas partes móviles diferentes, tratar de averiguar dónde en este gran ecosistema, algo salió mal va a ser más desafiante de lo que creo que necesita ser. Creo que típicamente cómo estructuro los agentes es darles un entorno que esté lleno de herramientas que puedan usar si quieren. No necesitas orquestar cosas como quiero decir, he visto a personas poner herramientas de navegador web en Lambdas que los agentes pueden consultar ellos mismos. Es solo esta arquitectura de AWS insana que ni siquiera puedo comprender. Cuando en realidad, creo que simplemente manteniéndolo muy simple, incluso solo un VPS donde tus agentes se ejecutan, darle un navegador, darle tal vez una herramienta de uso de navegador y luego dejar que lo use. Creo que eso se prestará mejor al proceso de depuración de lo que lo haría de otra manera. Fantástico. Muchas gracias, Sam. Un aplauso para Sam.