Seguimos reconstruyendo nuestro agente de IA. Esto es lo que sobrevivió - Fuad Ali, Arize AI

하이라이트

• El primer prototipo de Alex a finales de 2023 presentaba un cincuenta por ciento de alucinaciones y un cincuenta por ciento de utilidad.

• El almacenamiento de la memoria a largo plazo utiliza un archivo Markdown limitado a ochocientos caracteres por usuario en lugar de grafos de conocimiento o recuperación vectorial.

• El sistema descarta los resultados de herramientas demasiado grandes mediante truncamiento y permite que el código vaya a buscar el contexto completo cuando es necesario.

• El modelo por defecto pasó a ser Sonnet cuatro punto cinco con el lanzamiento de la versión dos punto cero en febrero de dos mil veiciuno.

• El arnés de código asume el control directo del plan de ejecución paso a paso dentro de los mensajes para evitar que el modelo pierda el enfoque.

타임라인

1. 00:00 - 04:15

   Evolución y cronología del agente Alex

   El proceso de construcción abarcó dos años de iteración continua sobre el producto integrado en la plataforma. Las primeras versiones sufrían de una alta tasa de alucinaciones debido a las limitaciones de los modelos de esa época. Con el tiempo, la interfaz y las capacidades de razonamiento se ampliaron para permitir la optimización de prompts y la lectura de trazas dentro de la aplicación.

   • El desarrollo del agente integrado Alex comenzó a finales de dos mil veintitrés utilizando modelos tempranos.
   • El prototipo inicial funcionaba como un enrutador simple de habilidades y bucle de llamadas a herramientas.
   • La arquitectura evolucionó hacia la integración de capacidades de planificación y ejecución de múltiples pasos.
2. 04:16 - 08:35

   Decisiones arquitectónicas sobre planificación y tareas

   Los modelos de lenguaje demostraron ser ineficientes al gestionar listas de tareas extensas por sí mismos, gastando demasiadas iteraciones en tachar elementos sin realizar un trabajo útil. La solución consistió en eliminar las herramientas de tareas redundantes y dejar que el arnés mantenga el estado y la comprobación de finalización de forma secuencial.

   • Las operaciones matemáticas y de cálculo se trasladaron desde el modelo hacia el código del arnés.
   • El uso inicial de listas de tareas independientes provocaba bucles inútiles y pérdida de enfoque en el modelo.
   • El control del plan pasó gradualmente al arnés de código para mantener las reglas junto a los datos en cada llamada.
3. 08:36 - 13:30

   Gestión de memoria y control de turnos

   Para resolver el problema del desbordamiento de contexto causado por grandes volúmenes de datos o trazas complejas, el sistema procesa los resultados como archivos externos y utiliza punteros. Asimismo, se descartaron arquitecturas complejas como grafos de conocimiento en favor de un archivo de memoria ligero que se actualiza mediante un proceso en segundo plano.

   • La finalización de un turno pasó a ser una compuerta estricta regulada y forzada por el arnés.
   • Los resultados masivos de herramientas se truncan para evitar saturar la ventana de contexto del modelo.
   • La memoria a largo plazo se implementa mediante un archivo Markdown individual por usuario.
4. 13:31 - 19:57

   Pruebas, validación y lecciones aprendidas

   El seguimiento de la actividad del agente en producción permite automatizar la detección de anomalías mediante herramientas de análisis. Aunque la automatización reduce la carga de revisión manual, las decisiones definitivas sobre métricas de rendimiento y cambios de modelos continúan requiriendo la intervención y el criterio humano.

   • Las sesiones de producción en vivo actúan como conjuntos de datos de regresión y casos de prueba permanentes.
   • Los errores en los agentes se manifiestan de forma cualitativa, como repeticiones excesivas o latencias anómalas.
   • El juicio humano sigue siendo indispensable para equilibrar las decisiones sobre velocidad y calidad de respuesta.