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

El problema no está en las instrucciones!

Autor: Systematic Long Short

Traducido por: Deep Tide TechFlow

Deep Tide Guía rápida: El argumento central de este artículo es una sola frase: la calidad de salida de un Agente de IA es 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 puedes empezar a usar hoy mismo, y delimita claramente la frontera de lo que no se puede superar con Tokens: el “problema de novedad”.

Para los lectores que usan Agentes para escribir código o ejecutar flujos de trabajo, la densidad de información y la operatividad son 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 usamos LLM para producir código en producción, todos estaban sorprendidos, porque la percepción general era que los LLM solo podían generar basura inutilizable. Pero nosotros sabemos algo que otros no se han dado cuenta: la calidad de salida del Agente es una función del número de Tokens que inviertes. Así de simple.

Puedes verlo en unos pocos experimentos. Pide a un Agente que complete una tarea compleja y algo poco común, como implementar desde cero un algoritmo de optimización convexa con restricciones. Primero, con un nivel mínimo de reflexión; luego, pásale a un nivel máximo, pidiéndole que revise su propio código y detecte cuántos bugs puede encontrar. Prueba ambos niveles, medio y alto. Verás claramente que la cantidad de bugs disminuye monotonamente a medida que aumentas los Tokens invertidos.

¿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, pidiéndole que analice línea por línea el código y determine si hay bugs), puedes detectar la mayoría, o incluso todos, los bugs. Este proceso puede repetirse diez, cien veces, cada vez con un “ángulo” diferente para examinar el código, y al final podrás encontrar todos los bugs.

La idea de que “más Tokens mejoran la calidad del Agente” también tiene respaldo empírico: aquellos equipos que afirman poder usar Agentes para escribir código y llevarlo directamente a producción, o bien son proveedores de modelos base, o bien son empresas con recursos financieros muy abundantes.

Por lo tanto, si todavía estás luchando porque tu Agente no produce código listo para producción, para ser directo: el problema eres tú. O mejor dicho, tu presupuesto.

¿Cómo saber si estás invirtiendo suficientes Tokens?

Escribí un artículo completo diciendo que el problema no está en tu marco de trabajo (harness), que “mantenerlo simple” puede seguir produciendo resultados excelentes, y sigo manteniendo esa postura. Si leíste ese artículo y seguiste sus consejos, pero aún así estás decepcionado con la salida del Agente, y me enviaste un DM sin respuesta, esto es para ti.

Este es mi respuesta.

En la mayoría de los casos, un rendimiento pobre del Agente y la incapacidad para resolver problemas se deben a que no estás invirtiendo suficientes Tokens.

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

Por ejemplo, “¿cuánto es 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 la misma o en diferentes etapas, 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 Agente 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 novedad”. Los Tokens suficientes pueden reducir los errores derivados de la complejidad a cero, pero no pueden hacer que un Agente invente cosas que no conoce.

Este hecho en realidad nos da un respiro.

Hemos dedicado mucho esfuerzo, invirtiendo —muchísimos— Tokens, para ver si podemos hacer que un Agente reproduzca un proceso de inversión institucional casi sin guía. Parte de la motivación era entender cuántos años nos quedan a los investigadores cuantitativos antes de ser completamente reemplazados por IA. Pero descubrimos que el Agente no puede casi replicar un proceso de inversión institucional decente. Creemos que esto se debe a que nunca lo han visto en los datos de entrenamiento — es decir, los procesos de inversión institucional no existen en los datos.

Por eso, si tu problema es novedoso, no esperes que solo apilando Tokens puedas resolverlo. Necesitas guiar tú mismo el proceso de exploración. Pero, una vez que tienes la solución, 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 proporcionalmente a la cantidad de líneas de código.

¿Para qué sirven realmente más Tokens?

En la práctica, los Tokens adicionales generalmente mejoran la calidad del trabajo del Agente de estas maneras:

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

Permitirle realizar múltiples intentos independientes, explorando diferentes caminos de solución. Algunos caminos son mejores que otros. Con más intentos, puede escoger el mejor.

De manera similar, más intentos independientes de planificación le permiten abandonar caminos débiles y conservar los más prometedores.

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”.

Y, por supuesto, mi favorita: 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 Agente no son aleatorios. Casi siempre se deben a escoger caminos prematuros, no verificar si esos caminos son viables en etapas tempranas, o no tener suficiente presupuesto para recuperarse y retroceder cuando se detectan errores.

La historia es así. Los Tokens, en sentido literal, son 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 un tiempo limitado, la calidad de su respuesta disminuirá a medida que aumenta la presión del tiempo.

La investigación, en última instancia, consiste en producir la base del “saber la respuesta”. Los humanos dedican tiempo biológico para producir mejores respuestas, y los Agentes dedican más tiempo de cálculo para obtener mejores resultados.

¿Cómo mejorar tu Agente?

Quizá todavía dudes, pero hay muchas publicaciones que respaldan esto, y en realidad, la existencia misma del ajuste de “razonamiento” como parámetro es la prueba definitiva de que esto funciona.

Me encanta un artículo en particular, donde los autores entrenan con un pequeño conjunto de ejemplos cuidadosamente diseñados para razonar, y luego usan un método para forzar al modelo a seguir pensando más allá de su punto de parada — agregando simplemente “Wait” (Espera) en los lugares donde quiere detenerse. Solo con eso, lograron que un benchmark subiera del 50% al 57%.

Voy a decirlo claramente: si te quejas de que tu Agente escribe código mediocre, probablemente no estás aprovechando al máximo el nivel de reflexión más alto.

Aquí tienes dos soluciones muy simples.

Solución simple 1: WAIT (Espera)

Lo que puedes empezar a hacer hoy mismo: crear un ciclo automático — después de construir, hacer que el Agente revise N veces en un contexto nuevo, y cada vez que detecte un problema, lo corrija.

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

Solución simple 2: VERIFY (Verificar)

Haz que el Agente verifique su trabajo lo antes posible y con frecuencia. Escribe pruebas que confirmen que la solución funciona en la práctica. Esto es especialmente útil en proyectos muy complejos y con muchas funciones anidadas — una función puede ser llamada por muchas otras funciones en diferentes niveles. Detectar errores en etapas tempranas 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 Agente dice que sí? Haz que otro Agente lo verifique. Flujos de pensamiento no relacionados pueden cubrir las posibles fuentes de sesgo sistemático.

Eso es todo. Podría escribir mucho más sobre esto, pero creo que si simplemente entiendes estas dos cosas y las implementas bien, podrás resolver el 95% de los problemas. Estoy convencido de que hacer las cosas simples al máximo, y luego agregar complejidad solo cuando sea necesario, es la clave.

Reitero que el “problema de novedad” 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 funciona.

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.