← Todos los insights

Análisis de casoEnfoque: España y Latinoamérica4 min de lectura

Cuando los agentes experimentan, lo lento está alrededor del modelo. Third Moment y Databricks lo muestran

Third Moment ejecuta 10,000 agentes de investigación hasta 48 horas; Databricks lanzó 8 veces más trabajos de entrenamiento con agentes. Ambos chocan con el mismo muro: espera, lanzamiento y errores.

Escuche este artículo · 6 min

Narración completa del artículo, generada con IA.

Una larga fila de carritos de compra anidados y sus ruedas, en duotono de La Madre, junto a las palabras Menos espera
Foto: rawpixel (CC0)

Los agentes de Third Moment Research tenían un hábito que desperdiciaba dinero. Hacer backtesting de una estrategia de trading con un año de datos de acciones de EE. UU. a nivel de orden tomaba varias horas, y mientras esperaban, los agentes consultaban repetidamente para ver si el trabajo había terminado. Cada chequeo costaba tokens y dejaba otro mensaje de estado en su contexto, desplazando la investigación que se suponía debían estar haciendo.

La solución no fue un mejor modelo. Según un perfil de cliente de OpenAI publicado el 14 de octubre, Third Moment usó Codex para analizar miles de trayectorias de agentes registradas junto con marcas de tiempo y el código base. Encontró el cuello de botella, luego una optimización de caché y una técnica de empaquetado de memoria, y redujo el backtest de unas tres horas a tres a cinco minutos, una reducción del 97%. Los agentes dejaron de quemar sus presupuestos en esperas.

Un día después, el equipo de investigación de IA de Databricks describió la misma lección desde dentro de una operación de investigación mucho más grande.

Dos organizaciones, un mismo cambio

Third Moment ejecuta alrededor de 10,000 agentes de forma concurrente en sesiones de investigación de 36 a 48 horas, usando modelos de la familia GPT-6 y el harness de Codex dentro de entornos Dockerizados, con un terabyte de datos por agente. Reportó procesar aproximadamente un billón de tokens de OpenAI en un solo día. Un harness externo examina trayectorias sin terminar y decide si reintentar, detener el trabajo o escalar a una persona. Antes de lanzar las simulaciones, usa Daybreak de OpenAI para probar si un agente podría escapar de su entorno de investigación. Estas son cifras reportadas por el cliente en un entorno inusualmente intensivo en cómputo.

Databricks reporta que los trabajos de entrenamiento para un área de investigación crecieron ocho veces después de que el equipo cambiara a investigación liderada por agentes, en la que los agentes proponen cambios, lanzan experimentos en paralelo, evalúan métricas y actualizan sus planes. El equipo trabaja en Databricks AI Runtime, su infraestructura de GPU para entrenamiento, con verificaciones preflight de salud de GPU, aislamiento de nodos fallidos, prioridades y preemption, contenedores compartidos, seguimiento automático de MLflow y datos gobernados a través de Unity Catalog. Ocho veces más trabajos mide volumen, no mejor investigación.

Qué se rompe primero

Los autores de Databricks lo nombran con precisión: tareas que son manejables a pequeña escala, como inicios lentos o errores de configuración confusos, se convierten en cuellos de botella cuando los agentes lanzan cientos de trabajos. Una persona espera dos minutos a que arranque un trabajo y se va por un café. Un agente espera y consulta, o reintenta, o malinterpreta el error y lanza algo incorrecto.

Eso da una lista corta de propiedades de infraestructura que importan más cuando los agentes son los usuarios:

  • Lanzamientos rápidos. El tiempo de inicio se multiplica por el número de experimentos. Databricks destaca trabajos que inician en segundos.
  • Errores accionables. Un error que una persona puede interpretar por experiencia debe convertirse en uno sobre el que un agente pueda actuar a partir de su texto.
  • Señales de finalización en lugar de polling. El desperdicio de Third Moment vino de agentes que verificaban trabajos lentos. Callbacks o notificaciones eliminan el bucle por completo.
  • Resultados a través de una API. Los agentes necesitan acceso programático a métricas y logs, no un dashboard.
  • Contención probada antes del lanzamiento. Los agentes con herramientas reales en sesiones largas necesitan que su entorno sea probado en busca de rutas de escape, como hace Third Moment. Argumentamos que para agentes de larga duración el entorno es el límite útil.

Las trayectorias registradas son el activo

Ambas organizaciones mejoran sus sistemas estudiando lo que los agentes realmente hicieron. Todo el enfoque de Third Moment se basa en eso: analizar trayectorias registradas, identificar debilidades recurrentes, generar escenarios sintéticos alrededor de ellas y mejorar los agentes. La solución del backtest vino de ese análisis, no de la intuición.

La mayoría de los programas empresariales de agentes no guardan las trayectorias en un formato que alguien pueda estudiar. Guardan resultados, a veces logs. Si sus agentes ejecutan tareas largas, almacene la secuencia de acciones, esperas, errores y resultados de herramientas, y revísela para ver el tiempo dedicado a esperar y repetir. Asana encontró la mayor parte de la reducción de costos de su agente de navegador en el flujo de trabajo, antes de cambiar los modelos. Third Moment la encontró en un backtest de tres horas.

No es una plantilla para escalar

Diez mil agentes concurrentes y un billón de tokens al día no son objetivos para una empresa común, y los resultados de Third Moment aplican a sus propias cargas de trabajo. El punto transferible es más pequeño y más útil: cuando el trabajo de un agente toma horas, mire las horas. Una actualización de modelo mejora el pensamiento. Muy a menudo, la espera es donde se va el presupuesto.

¿Tiene un caso de uso de IA detenido entre el prototipo y la producción?

Cuéntenos qué quiere poner en marcha. Le respondemos con próximos pasos honestos.

Conversemos sobre un caso de uso