Tasa de aprobación en la tarea empresarial de 28 días, por debajo del 75% y el 78% obtenidos en tareas cortas
Ejecuciones rentables durante 28 días del mejor modelo en tareas cortas
Modelos de Bedrock evaluados con instrucciones idénticas y sin ayuda específica por modelo
Ten Trillion Triangles LLC
Estados Unidos
Inteligencia artificial
Amazon Bedrock, Amazon ECS en AWS Fargate, Amazon S3, AWS Lambda, AWS Glue Data Catalog, Amazon Athena, Amazon QuickSight, Amazon API Gateway, Amazon DynamoDB, AWS WAF, Amazon Cognito, Amazon CloudFront, Amazon CloudWatch
Ten Trillion Triangles LLC contrató a Avahi para construir una plataforma de benchmarking que mide qué tan confiablemente los modelos de lenguaje de gran escala siguen reglas complejas por su cuenta a medida que aumenta la duración de una tarea. Avahi entregó tres benchmarks simulados y basados en reglas que se ejecutan contra modelos en Amazon Bedrock, con puntuaciones definidas por separado para cada benchmark, una canalización de datos automatizada, una capa de analítica con tableros de Amazon QuickSight, y un visor de trazas que reproduce cualquier ejecución turno por turno. Usando la plataforma, cinco modelos se ejecutaron cada uno en tres pruebas en cada benchmark, con instrucciones idénticas y sin ayuda específica por modelo. El resultado es una línea base fija y reproducible que Ten Trillion Triangles puede usar para evaluar marcos de agentes frente a modelos estándar.
Ten Trillion Triangles LLC es una empresa de tecnología de IA enfocada en hacer que los agentes de IA se comporten de manera predecible en trabajos largos y basados en reglas. La empresa ha desarrollado su propio marco de orquestación de agentes, T-Pipe, diseñado para imponer un comportamiento determinista de agentes a largo plazo. Para respaldar su trabajo, Ten Trillion Triangles necesitaba evidencia empírica y reproducible de cómo se desempeñan los modelos estándar en tareas complejas y basadas en reglas.
Los agentes empresariales operan cada vez más a través de numerosas decisiones secuenciales. Deben seguir reglas, resistir la manipulación y seguir actuando sin supervisión. La mayoría de los benchmarks existentes miden tareas cortas, lo que deja un vacío: ¿cómo cambia la confiabilidad a medida que aumenta el horizonte de la tarea cuando las reglas y el entorno de prueba se mantienen fijos?
Ten Trillion Triangles necesitaba una respuesta confiable y repetible. Eso significaba instrucciones idénticas para cada modelo, puntuaciones que solo se comparan dentro de la misma versión del benchmark, resultados que pueden recalcularse a partir de los archivos de ejecución originales, y una forma de ver por qué un modelo falló, no solo que falló. Sin una plataforma diseñada específicamente para esto, las comparaciones entre modelos seguirían siendo anecdóticas y difíciles de reproducir.
Amazon Bedrock le dio al motor de benchmarking una forma administrada de acceder a modelos de varios proveedores. Cinco modelos fueron evaluados a través del mismo motor y las mismas instrucciones, que es lo que requiere una comparación justa y equivalente. Ejecutar las tareas de benchmarking junto a Bedrock en AWS Fargate mantuvo la ejecución cerca de los modelos evaluados.
El resto de la plataforma también se mantuvo en AWS. Amazon S3, AWS Lambda, AWS Glue Data Catalog, Amazon Athena y Amazon QuickSight convierten los artefactos de ejecución sin procesar en tablas y tableros consultables, y Amazon API Gateway, AWS WAF, y Amazon Cognito controlan el acceso a la API de ejecución y al visor de trazas. Mantener la ejecución, los datos, la analítica y el control de acceso en una sola plataforma permitió que una ejecución fluyera de principio a fin hasta el tablero sin pasos manuales.
El proyecto requería ingeniería de simulación, ciencia de datos e ingeniería de datos en la nube dentro de un solo equipo de entrega. Avahi asignó roles de ingeniería backend, GenAI y ciencia de datos, e ingeniería de datos que trabajaron bajo un contrato compartido: el conjunto de archivos que el motor de benchmarking escribe y que la plataforma de datos lee. Ese contrato permitió que cada parte cambiara de forma independiente mientras la canalización seguía funcionando.
Avahi llevó a cabo el trabajo en sprints semanales y realizó una sesión de trabajo semanal con el equipo de Ten Trillion Triangles. En esas sesiones, el cliente revisaba tableros en vivo y el comportamiento de los benchmarks, y dirigía los cambios; por ejemplo, solicitó páginas web más difíciles en el benchmark de compras después de que las primeras pruebas mostraran que los modelos lo completaban con demasiada facilidad.
Avahi desarrolló un motor de benchmarking en Python que separa lo que es un benchmark de cómo se ejecuta y de qué modelo lo ejecuta. Seis interfaces pequeñas definen el contrato: participante, entorno, herramienta, evaluador, caso de benchmark y benchmark. El entorno de ejecución nunca llama directamente a un proveedor de modelos. Los modelos solo se acceden a través de participantes, de modo que agregar un proveedor significa agregar un participante, no modificar el entorno de ejecución. Las instrucciones se generan a partir de los mismos fixtures que las herramientas y los evaluadores aplican, por lo que las instrucciones no pueden apartarse de las reglas.
Tres benchmarks forman un gradiente deliberado en duración de tareas. Butter-Bench evalúa la navegación por un sitio web orientado a personas para comprar el producto correcto en 18 escenarios, cada uno con su propia tienda generada y un proceso de pago de seis pasos. Drive-Thru evalúa el manejo de pedidos bajo presión adversarial en 188 clientes guionados en 11 categorías adversariales. Open-Vend evalúa la gestión de un negocio de máquinas expendedoras durante 28 días simulados, con proveedores interpretados por un segundo modelo, demanda que responde al precio, y fallas de máquina que deben repararse a tiempo. Cada benchmark tiene umbrales mínimos estrictos de aprobación, de modo que el progreso parcial nunca convierte un fracaso en un éxito. Un supervisor mínimo interviene solo cuando un modelo deja de llamar herramientas, y sus instrucciones no dan pistas sobre la tarea.
En la nube, una solicitud autorizada a la API de ejecución inicia una tarea de AWS Fargate por benchmark. Cada tarea escribe sus resultados y una traza de eventos comprimida en Amazon S3, y escribe un manifiesto de finalización al final. La llegada de ese manifiesto inicia una función de AWS Lambda que valida los artefactos, escribe tablas Parquet depuradas, registra particiones en el AWS Glue Data Catalog y reconstruye las tablas de reportes. Amazon Athena consulta esas tablas, Amazon QuickSight las presenta como tableros, y un enlace desde el tablero abre un visor de trazas y repeticiones servido a través de Amazon CloudFront detrás del inicio de sesión de Amazon Cognito. Los tableros y alarmas de Amazon CloudWatch monitorean la salud de la canalización, las fallas y el gasto de la cuenta, y los recursos de AWS están definidos como infraestructura como código.
Motor de benchmarking con tres benchmarks: Butter-Bench (18 escenarios de compras), Drive-Thru (188 clientes adversariales guionados) y Open-Vend (una simulación de negocio de 28 días)
Integración de modelos a través de Amazon Bedrock para cinco modelos, con instrucciones idénticas generadas a partir de fixtures para cada modelo
Puntuación con umbrales mínimos estrictos de aprobación por benchmark y un supervisor que gestiona ejecuciones estancadas sin dar pistas
API de control de ejecución en Amazon API Gateway, AWS Lambda y Amazon DynamoDB, protegida por AWS WAF y el inicio de sesión de Amazon Cognito, que inicia ejecuciones de benchmark como tareas de AWS Fargate
Canalización de datos automatizada que convierte artefactos de ejecución sin procesar en 13 tablas depuradas y 21 tablas de reportes, consultables a través de AWS Glue Data Catalog y Amazon Athena
Analítica de Amazon QuickSight con 34 conjuntos de datos, 5 hojas de tablero y 29 elementos visuales
Visor de trazas y repeticiones que permite al lector recorrer cualquier ejecución turno por turno
Tablero y alarmas de Amazon CloudWatch para la salud de la canalización, las fallas y el gasto
Documento técnico, informes de campaña y un conjunto de datos de resultados a partir del cual se puede recalcular cada cifra reportada
Documento de arquitectura del sistema y transferencia de conocimiento, manuales de operación, y un repositorio de código documentado para la entrega
La plataforma produjo una línea base reproducible de cómo se comportan los modelos estándar a medida que aumenta la duración de la tarea. En los cinco modelos, la campaña de benchmarking reunió 270 ejecuciones de escenarios de Butter-Bench, 2820 casos de Drive-Thru y 16 ejecuciones de Open-Vend, y cada cifra puede recalcularse a partir de los archivos de resultados entregados.
Las tasas de aprobación promedio fueron del 75% en Butter-Bench y del 78% en Drive-Thru, pero de solo el 25% en el negocio de 28 días de Open-Vend, donde 4 de 16 ejecuciones aprobaron.
El ranking de ningún modelo en tareas cortas se mantuvo en la tarea larga. El modelo con mejor desempeño en Butter-Bench (85%) nunca logró obtener ganancias en Open-Vend en sus tres ejecuciones, y el modelo que lideró Open-Vend —el único con múltiples victorias allí— aun así falló 1 de sus 3 ejecuciones y no fue el de mejor puntuación en ninguno de los benchmarks de horizonte corto.
La tasa de aprobación sobreestimó la calidad en Drive-Thru. Al recalificar según cuántas llamadas al modelo requirió cada éxito, el mejor modelo bajó del 86% al 72%, y otro modelo bajó del 79% al 50%.
Las decisiones equivocadas, no las detecciones fallidas, impulsaron los fracasos en Drive-Thru. Cerrar un pedido corregible o enviar uno irreconciliable representó entre el 60% y el 95% de los fracasos de cada modelo.
Los resultados de horizonte largo están determinados tanto por el diseño del entorno de prueba como por el propio modelo, pero no todas las formas de ayuda tienen el mismo impacto. Una redacción revisada de las directrices de rechazo de Drive-Thru modificó las tasas de aprobación en solo 1 a 3 puntos porcentuales. Un cambio más estructural —indicarle a un modelo que vuelva a actuar cuando se estanca en una salida de solo texto— tuvo un efecto mucho mayor: la tasa de finalización de un modelo en la tarea de 28 días pasó de 0 de 4 ejecuciones a 3 de 3, usando entre 2.9 y 6.8 millones de tokens de entrada por ejecución en lugar de 30 a 42 millones.
Ten Trillion Triangles LLC
Estados Unidos
Inteligencia artificial
Amazon Bedrock, Amazon ECS en AWS Fargate, Amazon S3, AWS Lambda, AWS Glue Data Catalog, Amazon Athena, Amazon QuickSight, Amazon API Gateway, Amazon DynamoDB, AWS WAF, Amazon Cognito, Amazon CloudFront, Amazon CloudWatch
Ten Trillion Triangles LLC contrató a Avahi para construir una plataforma de benchmarking que mide qué tan confiablemente los modelos de lenguaje de gran escala siguen reglas complejas por su cuenta a medida que aumenta la duración de una tarea. Avahi entregó tres benchmarks simulados y basados en reglas que se ejecutan contra modelos en Amazon Bedrock, con puntuaciones definidas por separado para cada benchmark, una canalización de datos automatizada, una capa de analítica con tableros de Amazon QuickSight, y un visor de trazas que reproduce cualquier ejecución turno por turno. Usando la plataforma, cinco modelos se ejecutaron cada uno en tres pruebas en cada benchmark, con instrucciones idénticas y sin ayuda específica por modelo. El resultado es una línea base fija y reproducible que Ten Trillion Triangles puede usar para evaluar marcos de agentes frente a modelos estándar.
Ten Trillion Triangles LLC es una empresa de tecnología de IA enfocada en hacer que los agentes de IA se comporten de manera predecible en trabajos largos y basados en reglas. La empresa ha desarrollado su propio marco de orquestación de agentes, T-Pipe, diseñado para imponer un comportamiento determinista de agentes a largo plazo. Para respaldar su trabajo, Ten Trillion Triangles necesitaba evidencia empírica y reproducible de cómo se desempeñan los modelos estándar en tareas complejas y basadas en reglas.
Los agentes empresariales operan cada vez más a través de numerosas decisiones secuenciales. Deben seguir reglas, resistir la manipulación y seguir actuando sin supervisión. La mayoría de los benchmarks existentes miden tareas cortas, lo que deja un vacío: ¿cómo cambia la confiabilidad a medida que aumenta el horizonte de la tarea cuando las reglas y el entorno de prueba se mantienen fijos?
Ten Trillion Triangles necesitaba una respuesta confiable y repetible. Eso significaba instrucciones idénticas para cada modelo, puntuaciones que solo se comparan dentro de la misma versión del benchmark, resultados que pueden recalcularse a partir de los archivos de ejecución originales, y una forma de ver por qué un modelo falló, no solo que falló. Sin una plataforma diseñada específicamente para esto, las comparaciones entre modelos seguirían siendo anecdóticas y difíciles de reproducir.
Amazon Bedrock le dio al motor de benchmarking una forma administrada de acceder a modelos de varios proveedores. Cinco modelos fueron evaluados a través del mismo motor y las mismas instrucciones, que es lo que requiere una comparación justa y equivalente. Ejecutar las tareas de benchmarking junto a Bedrock en AWS Fargate mantuvo la ejecución cerca de los modelos evaluados.
El resto de la plataforma también se mantuvo en AWS. Amazon S3, AWS Lambda, AWS Glue Data Catalog, Amazon Athena y Amazon QuickSight convierten los artefactos de ejecución sin procesar en tablas y tableros consultables, y Amazon API Gateway, AWS WAF, y Amazon Cognito controlan el acceso a la API de ejecución y al visor de trazas. Mantener la ejecución, los datos, la analítica y el control de acceso en una sola plataforma permitió que una ejecución fluyera de principio a fin hasta el tablero sin pasos manuales.
El proyecto requería ingeniería de simulación, ciencia de datos e ingeniería de datos en la nube dentro de un solo equipo de entrega. Avahi asignó roles de ingeniería backend, GenAI y ciencia de datos, e ingeniería de datos que trabajaron bajo un contrato compartido: el conjunto de archivos que el motor de benchmarking escribe y que la plataforma de datos lee. Ese contrato permitió que cada parte cambiara de forma independiente mientras la canalización seguía funcionando.
Avahi llevó a cabo el trabajo en sprints semanales y realizó una sesión de trabajo semanal con el equipo de Ten Trillion Triangles. En esas sesiones, el cliente revisaba tableros en vivo y el comportamiento de los benchmarks, y dirigía los cambios; por ejemplo, solicitó páginas web más difíciles en el benchmark de compras después de que las primeras pruebas mostraran que los modelos lo completaban con demasiada facilidad.
Avahi desarrolló un motor de benchmarking en Python que separa lo que es un benchmark de cómo se ejecuta y de qué modelo lo ejecuta. Seis interfaces pequeñas definen el contrato: participante, entorno, herramienta, evaluador, caso de benchmark y benchmark. El entorno de ejecución nunca llama directamente a un proveedor de modelos. Los modelos solo se acceden a través de participantes, de modo que agregar un proveedor significa agregar un participante, no modificar el entorno de ejecución. Las instrucciones se generan a partir de los mismos fixtures que las herramientas y los evaluadores aplican, por lo que las instrucciones no pueden apartarse de las reglas.
Tres benchmarks forman un gradiente deliberado en duración de tareas. Butter-Bench evalúa la navegación por un sitio web orientado a personas para comprar el producto correcto en 18 escenarios, cada uno con su propia tienda generada y un proceso de pago de seis pasos. Drive-Thru evalúa el manejo de pedidos bajo presión adversarial en 188 clientes guionados en 11 categorías adversariales. Open-Vend evalúa la gestión de un negocio de máquinas expendedoras durante 28 días simulados, con proveedores interpretados por un segundo modelo, demanda que responde al precio, y fallas de máquina que deben repararse a tiempo. Cada benchmark tiene umbrales mínimos estrictos de aprobación, de modo que el progreso parcial nunca convierte un fracaso en un éxito. Un supervisor mínimo interviene solo cuando un modelo deja de llamar herramientas, y sus instrucciones no dan pistas sobre la tarea.
En la nube, una solicitud autorizada a la API de ejecución inicia una tarea de AWS Fargate por benchmark. Cada tarea escribe sus resultados y una traza de eventos comprimida en Amazon S3, y escribe un manifiesto de finalización al final. La llegada de ese manifiesto inicia una función de AWS Lambda que valida los artefactos, escribe tablas Parquet depuradas, registra particiones en el AWS Glue Data Catalog y reconstruye las tablas de reportes. Amazon Athena consulta esas tablas, Amazon QuickSight las presenta como tableros, y un enlace desde el tablero abre un visor de trazas y repeticiones servido a través de Amazon CloudFront detrás del inicio de sesión de Amazon Cognito. Los tableros y alarmas de Amazon CloudWatch monitorean la salud de la canalización, las fallas y el gasto de la cuenta, y los recursos de AWS están definidos como infraestructura como código.
Motor de benchmarking con tres benchmarks: Butter-Bench (18 escenarios de compras), Drive-Thru (188 clientes adversariales guionados) y Open-Vend (una simulación de negocio de 28 días)
Integración de modelos a través de Amazon Bedrock para cinco modelos, con instrucciones idénticas generadas a partir de fixtures para cada modelo
Puntuación con umbrales mínimos estrictos de aprobación por benchmark y un supervisor que gestiona ejecuciones estancadas sin dar pistas
API de control de ejecución en Amazon API Gateway, AWS Lambda y Amazon DynamoDB, protegida por AWS WAF y el inicio de sesión de Amazon Cognito, que inicia ejecuciones de benchmark como tareas de AWS Fargate
Canalización de datos automatizada que convierte artefactos de ejecución sin procesar en 13 tablas depuradas y 21 tablas de reportes, consultables a través de AWS Glue Data Catalog y Amazon Athena
Analítica de Amazon QuickSight con 34 conjuntos de datos, 5 hojas de tablero y 29 elementos visuales
Visor de trazas y repeticiones que permite al lector recorrer cualquier ejecución turno por turno
Tablero y alarmas de Amazon CloudWatch para la salud de la canalización, las fallas y el gasto
Documento técnico, informes de campaña y un conjunto de datos de resultados a partir del cual se puede recalcular cada cifra reportada
Documento de arquitectura del sistema y transferencia de conocimiento, manuales de operación, y un repositorio de código documentado para la entrega
La plataforma produjo una línea base reproducible de cómo se comportan los modelos estándar a medida que aumenta la duración de la tarea. En los cinco modelos, la campaña de benchmarking reunió 270 ejecuciones de escenarios de Butter-Bench, 2820 casos de Drive-Thru y 16 ejecuciones de Open-Vend, y cada cifra puede recalcularse a partir de los archivos de resultados entregados.
Las tasas de aprobación promedio fueron del 75% en Butter-Bench y del 78% en Drive-Thru, pero de solo el 25% en el negocio de 28 días de Open-Vend, donde 4 de 16 ejecuciones aprobaron.
El ranking de ningún modelo en tareas cortas se mantuvo en la tarea larga. El modelo con mejor desempeño en Butter-Bench (85%) nunca logró obtener ganancias en Open-Vend en sus tres ejecuciones, y el modelo que lideró Open-Vend —el único con múltiples victorias allí— aun así falló 1 de sus 3 ejecuciones y no fue el de mejor puntuación en ninguno de los benchmarks de horizonte corto.
La tasa de aprobación sobreestimó la calidad en Drive-Thru. Al recalificar según cuántas llamadas al modelo requirió cada éxito, el mejor modelo bajó del 86% al 72%, y otro modelo bajó del 79% al 50%.
Las decisiones equivocadas, no las detecciones fallidas, impulsaron los fracasos en Drive-Thru. Cerrar un pedido corregible o enviar uno irreconciliable representó entre el 60% y el 95% de los fracasos de cada modelo.
Los resultados de horizonte largo están determinados tanto por el diseño del entorno de prueba como por el propio modelo, pero no todas las formas de ayuda tienen el mismo impacto. Una redacción revisada de las directrices de rechazo de Drive-Thru modificó las tasas de aprobación en solo 1 a 3 puntos porcentuales. Un cambio más estructural —indicarle a un modelo que vuelva a actuar cuando se estanca en una salida de solo texto— tuvo un efecto mucho mayor: la tasa de finalización de un modelo en la tarea de 28 días pasó de 0 de 4 ejecuciones a 3 de 3, usando entre 2.9 y 6.8 millones de tokens de entrada por ejecución en lugar de 30 a 42 millones.
Exploremos juntos sus oportunidades de IA de alto impacto en una sesión gratuita
