¿AI Agent genera basura? El problema es que no quieres quemar Tokens

Autor: Systematic Long Short

Traducido por: Deep潮 TechFlow

Resumen de Deep潮: La idea central de este artículo es una sola frase: la calidad de salida del AI Agent es directamente proporcional a la cantidad de Tokens que inviertes.

El autor no está hablando en términos abstractos, sino que ofrece dos métodos concretos que se pueden empezar a usar hoy mismo, y delimita claramente la frontera más allá de la cual no se puede superar con Tokens: el «problema de la novedad».

Para los lectores que están usando Agents para programar o ejecutar flujos de trabajo, la densidad de información y la operatividad son muy altas.

Introducción

Bueno, tienes que admitir que este título realmente llama la atención — pero, en serio, no es una broma.

En 2023, cuando todavía usábamos LLM para generar código en producción, todos estaban boquiabiertos, porque la percepción general era que los LLM solo podían producir basura inútil. Pero nosotros sabíamos algo que otros no se daban cuenta: la calidad de salida del Agent es una función del número de Tokens que inviertes. Así de simple.

Puedes verlo tú mismo haciendo algunos experimentos. Pide a un Agent que complete una tarea de programación compleja y algo poco común — por ejemplo, implementar desde cero un algoritmo de optimización convexa con restricciones. Primero, ejecútalo con el nivel de pensamiento más bajo; luego, pásalo al nivel más alto, y haz que revise su propio código para detectar cuántos bugs puede encontrar. Prueba en niveles medio y alto también. Verás claramente que la cantidad de bugs disminuye monotonamente a medida que aumentas los Tokens invertidos.

¿No es fácil de entender, verdad?

Más Tokens = Menos errores. Puedes llevar esta lógica un paso más allá, y eso es básicamente el núcleo (simplificado) detrás de los productos de revisión de código. En un contexto completamente nuevo, invirtiendo una gran cantidad de Tokens (por ejemplo, hacer que analice línea por línea el código y determine si hay bugs en cada línea), puedes detectar la mayoría, o incluso todos, los bugs. Este proceso puede repetirse diez, cien veces, cada vez con una «perspectiva diferente» del código, y al final podrás encontrar todos los bugs.

Otra evidencia que respalda la idea de que «más Tokens mejoran la calidad del Agent»: los equipos que afirman poder usar Agents para escribir código y llevarlo directamente a producción, ya sea los proveedores de modelos base o empresas con recursos extremadamente abundantes.

Por lo tanto, si todavía estás luchando porque tu Agent no genera código listo para producción, honestamente, el problema está en ti. O, más bien, en tu presupuesto.

¿Cómo saber si has invertido suficientes Tokens?

He escrito un artículo completo diciendo que el problema no está en el marco (harness) que usas; «mantenerlo simple» puede seguir produciendo resultados excelentes, y sigo manteniendo esa postura. Si leíste ese artículo, seguiste sus consejos, pero aún así estás decepcionado con la salida del Agent, y me enviaste un DM que vi, pero no respondí.

Este artículo es mi respuesta.

En la mayoría de los casos, un rendimiento pobre o incapacidad para resolver problemas con tu Agent se debe a que no has invertido suficientes Tokens.

La cantidad de Tokens necesaria para resolver un problema depende completamente de su escala, complejidad y novedad.

«¿Cuántos Tokens se necesitan para resolver 2+2?» No requiere muchos Tokens.

Pero «Ayúdame a crear un bot que escanee todos los mercados entre Polymarket y Kalshi, identifique aquellos que son semánticamente similares y que deberían liquidarse en momentos similares, establezca límites sin arbitraje y, en caso de detectar oportunidades, realice transacciones automáticas con baja latencia» — eso requiere una gran cantidad de Tokens.

Hemos descubierto algo interesante en la práctica.

Si inviertes suficientes Tokens para abordar problemas derivados de la escala y la complejidad, el Agent podrá resolverlos de cualquier manera. En otras palabras, si quieres construir algo extremadamente complejo, con muchos componentes y líneas de código, solo necesitas invertir suficientes Tokens en estos problemas, y al final, se resolverán completamente.

Hay una pequeña pero importante excepción.

Tu problema no puede ser demasiado novedoso. En la etapa actual, ninguna cantidad de Tokens puede resolver el «problema de la novedad». Los Tokens suficientes pueden reducir a cero los errores derivados de la complejidad, pero no pueden hacer que un Agent invente cosas que no conoce de la nada.

De hecho, esta conclusión nos da un respiro.

Hemos dedicado mucho esfuerzo, hemos invertido —muchísimos Tokens—, para intentar que un Agent pueda, sin mucha guía, reproducir un proceso de inversión institucional. Parte de la razón era entender cuántos años nos quedan a nosotros, como investigadores cuantitativos, antes de ser completamente reemplazados por IA. Pero descubrimos que el Agent ni siquiera se acerca a un proceso de inversión institucional decente. Creemos que esto se debe a que nunca han visto algo así — es decir, los datos de entrenamiento no contienen en absoluto ese tipo de procesos.

Por eso, si tu problema es novedoso, no esperes que apilar Tokens lo solucione. Necesitas guiar tú mismo el proceso de exploración. Pero, una vez que tienes una solución clara, puedes confiar en apilar Tokens para ejecutarla — sin importar cuán grande sea la base de código o cuántos componentes tenga.

Aquí hay una regla heurística simple: el presupuesto de Tokens debe crecer en proporción al número de líneas de código.

¿Para qué sirven realmente los Tokens adicionales?

En la práctica, los Tokens extra generalmente mejoran la calidad del trabajo del Agent de las siguientes maneras:

Permitirle dedicar más tiempo a razonar en una misma tentativa, dándole la oportunidad de detectar errores lógicos por sí mismo. Cuanto más profundo sea el razonamiento, mejor la planificación, y mayor la probabilidad de éxito en un solo intento.

Permitirle realizar múltiples intentos independientes, explorando diferentes caminos para resolver el problema. Algunos caminos son mejores que otros. Al permitir más de un intento, puede escoger el mejor.

De manera similar, más intentos de planificación independientes le permiten abandonar las direcciones débiles y conservar las más prometedoras.

Más Tokens también le permiten usar un contexto completamente nuevo para criticar su trabajo previo, dándole una oportunidad de mejorar en lugar de quedar atrapado en una «inercia de razonamiento».

Por supuesto, otra de mis favoritas: más Tokens significan que puede usar pruebas y herramientas para verificar. Ejecutar el código y comprobar si funciona es la forma más confiable de confirmar que la respuesta es correcta.

Esta lógica funciona porque los fracasos en ingeniería del Agent no son aleatorios. Casi siempre se deben a que eligió un camino demasiado pronto, no verificó si ese camino era viable (en las etapas iniciales), o no tuvo suficiente presupuesto para recuperarse y retroceder tras detectar errores.

Así es la historia. Literalmente, los Tokens representan la calidad de decisión que compras. Imagínalo como un trabajo de investigación: si pides a una persona que resuelva un problema difícil en el acto, la calidad de su respuesta disminuirá a medida que aumenta la presión del tiempo.

En última instancia, la investigación consiste en producir lo que llamamos «saber la respuesta». Los humanos dedican tiempo biológico para producir mejores respuestas, y los Agents dedican más tiempo de cálculo para producir mejores respuestas.

¿Cómo mejorar tu Agent?

Quizá todavía dudes, pero hay muchos artículos que respaldan esto, y, en realidad, la existencia misma del «interruptor de razonamiento» es la prueba definitiva de que esto es cierto.

Un artículo que me gusta mucho, por ejemplo, entrenó con un pequeño conjunto cuidadosamente diseñado de ejemplos de razonamiento, y luego usó un método para forzar al modelo a seguir pensando incluso cuando quería detenerse — agregando simplemente un «Wait» (Espera) en el lugar donde quería parar. Solo con eso, un benchmark subió del 50% al 57%.

Voy a decirlo de la forma más clara posible: si sigues quejándote de que el código que genera tu Agent es mediocre, probablemente no estás usando suficiente nivel de pensamiento en una sola pasada.

Te doy dos soluciones muy simples.

Primera: WAIT (Espera)

Lo más sencillo que puedes empezar a hacer hoy mismo: montar un ciclo automático — una vez construido, que el Agent revise N veces en un contexto nuevo, y que cada vez que detecte un problema, lo corrija.

Si notas que esta técnica sencilla mejora el rendimiento de tu Agent, al menos entenderás que el problema es solo la cantidad de Tokens — así que, ¡únete al club de quemar Tokens!

Segunda: VERIFY (Verificar)

Haz que tu Agent verifique su trabajo lo antes posible y con frecuencia. Escribe pruebas que demuestren que la ruta elegida realmente funciona. Esto es especialmente útil en proyectos muy complejos y profundamente anidados — una función puede ser llamada por muchas otras funciones en la parte inferior del código. Detectar errores en las etapas superiores puede ahorrarte mucho tiempo de cálculo posterior (Tokens). Así que, si puedes, establece puntos de verificación en todo el proceso de construcción.

¿El código está listo y el Agent dice que sí? Haz que otro Agent lo verifique. Flujos de pensamiento no relacionados pueden cubrir las fuentes de sesgo sistemático.

Eso es todo. Podría escribir mucho más sobre este tema, pero creo que si solo te concentras en estas dos cosas y las implementas bien, podrás resolver el 95% de los problemas. Estoy convencido de que llevar las cosas simples al extremo, y luego agregar complejidad solo cuando sea necesario, es la mejor estrategia.

Mencioné que la «novedad» es algo que no puede resolverse solo con Tokens, y quiero enfatizarlo otra vez, porque tarde o temprano te toparás con esa trampa y vendrás a quejarte de que apilar Tokens no sirve de nada.

Cuando el problema que quieres resolver no está en el conjunto de entrenamiento, tú eres quien realmente necesita ofrecer una solución. Por eso, el conocimiento especializado en el dominio sigue siendo extremadamente importante.