La calidad del agente de IA está correlacionada con la quema de tokens

Autor: Systematic Long Short

Compilado por Deep潮 TechFlow

Guía de Shenchao: El argumento central de este artículo se resume en una sola frase: la calidad de la salida del AI Agent es proporcional a la cantidad de Token que inviertes.

El autor no habla de teorías generales, sino que presenta dos métodos concretos que puedes empezar a usar hoy, y delimita claramente los límites que no se pueden superar con tokens: el "problema de la novedad".

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

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

En 2023, cuando aún estábamos ejecutando código de producción con LLM, todos a nuestro alrededor se sorprendieron, ya que en ese momento la creencia generalizada era que los LLM solo producían basura inutilizable. Pero nosotros sabíamos algo que otros no habían entendido: la calidad de la salida de un Agente es una función de la cantidad de Token que inviertes. Así de simple.

Puedes verlo tú mismo ejecutando algunos experimentos. Haz que el agente complete una tarea de programación compleja y algo poco común, como implementar desde cero un algoritmo de optimización convexa con restricciones. Primero, ejecútalo con el nivel de pensamiento más bajo; luego, cambia al nivel de pensamiento más alto y haz que revise su propio código para ver cuántos errores puede detectar. Prueba también los niveles medio y alto. Verás de forma intuitiva: la cantidad de errores disminuye de forma monótona a medida que aumenta la cantidad de tokens invertidos.

That's not hard to understand, right?

Más tokens = menos errores. Puedes llevar esta lógica un paso más allá: es esencialmente la idea central (simplificada) detrás de un producto de revisión de código. En un contexto completamente nuevo, invierte una gran cantidad de tokens (por ejemplo, haz que analice el código línea por línea y determine si cada línea tiene un error): así podrás detectar la mayoría, e incluso todos los errores. Este proceso se puede repetir diez o cien veces, examinando el código desde «ángulos diferentes» cada vez, y finalmente podrás sacar a la luz todos los errores.

La idea de que «quemar más tokens mejora la calidad del agente» tiene otro respaldo empírico: los equipos que afirman poder escribir código completo con agentes y lanzarlo directamente a producción son o bien proveedores del modelo base o empresas con fondos extremadamente abundantes.

Entonces, si aún te preocupas porque el agente no genera código de producción, dicho de forma directa: el problema está en ti. O, más bien, en tu billetera.

He escrito un artículo completo diciendo que el problema definitivamente no está en el marco (harness) que construiste; aún puedes crear cosas excelentes manteniendo la simplicidad, y sigo manteniendo esta opinión. Leíste ese artículo, lo seguiste, pero aún así quedaste muy decepcionado con la salida del Agente. Me enviaste un DM, viste que lo leí, pero no respondiste.

This one is the reply.

Tu agente tiene un mal rendimiento y no resuelve problemas, en la mayoría de los casos, porque no quemaste suficientes Token.

La cantidad de tokens requerida para resolver un problema depende completamente del tamaño, la complejidad y la novedad del problema.

¿Cuánto es 2 + 2? No se necesitan muchos tokens.

«Hazme un bot que escanee todos los mercados entre Polymarket y Kalshi, identifique mercados semánticamente similares que deberían liquidarse en torno al mismo evento, establezca límites de no-arbitraje y realice operaciones automáticas con baja latencia cuando surja una oportunidad de arbitraje»: esto requiere quemar una gran cantidad de tokens.

En la práctica, descubrimos algo interesante.

Si inviertes suficientes Token para abordar los problemas derivados de la escala y la complejidad, el agente siempre podrá resolverlos. En otras palabras, si deseas construir algo extremadamente complejo con muchos componentes y líneas de código, siempre que arrojes suficientes Token a estos problemas, finalmente podrán resolverse por completo.

Aquí hay una pequeña pero importante excepción.

Tu pregunta no puede ser demasiado novedosa. En esta etapa, ninguna cantidad de tokens puede resolver el problema de la "novedad". Suficientes tokens pueden reducir a cero los errores derivados de la complejidad, pero no pueden hacer que el agente invente algo que no conoce.

Esta conclusión realmente nos alivia.

Invertimos una gran cantidad de esfuerzo y quemamos—muchísimo, muchísimo, muchísimo—Token para intentar ver si el Agente podía reconstruir el proceso de inversión institucional sin ninguna guía. Esta parte se debía a que queríamos entender cuántos años nos separan de ser completamente reemplazados por la IA. Descubrimos que el Agente no puede ni acercarse a un proceso de inversión institucional adecuado. Creemos que esta parte se debe a que nunca han visto algo así—es decir, el proceso de inversión institucional no existe en los datos de entrenamiento.

Entonces, si tu problema es novedoso, no esperes resolverlo acumulando tokens. Necesitas guiar tú mismo el proceso de exploración. Pero una vez que hayas determinado la solución implementable, puedes confiar en acumular tokens para ejecutarla: sin importar qué tan grande sea la base de código o qué tan complejos sean los componentes, no será un problema.

Aquí hay un principio heurístico simple: el presupuesto de tokens debe crecer proporcionalmente a la cantidad de líneas de código.

En la práctica, los tokens adicionales suelen mejorar la calidad del engineering del agente de las siguientes maneras:

Dedica más tiempo a razonar en el mismo intento, teniendo la oportunidad de descubrir por ti mismo errores lógicos. Cuanto más profundo sea el razonamiento, mejor será la planificación y mayor será la probabilidad de acertar en un solo intento.

Permite que realice múltiples intentos independientes, siguiendo diferentes caminos de resolución. Algunos caminos son mejores que otros. Al permitir más de un intento, podrá elegir la opción óptima.

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

Más tokens le permiten criticar su propio trabajo anterior con un nuevo contexto, brindándole una oportunidad de mejora en lugar de quedar atrapado en una «inercia de razonamiento».

Of course, and my favorite point: more tokens mean it can be verified with tests and tools. Running the code to see if it works is the most reliable way to confirm the correct answer.

Esta lógica funciona porque el fracaso de ingeniería del Agente no es aleatorio. Casi siempre se debe a haber elegido incorrectamente una ruta demasiado pronto, no haber verificado si esa ruta realmente era viable (en las etapas iniciales) o no tener un presupuesto suficiente para recuperarse y retroceder tras detectar un error.

Así es la historia. El token es literalmente la calidad de la decisión que compras. Piénsalo como una tarea de investigación: si le pides a alguien que responda una pregunta difícil en el momento, la calidad de la respuesta disminuye a medida que aumenta la presión temporal.

La investigación, en última instancia, es lo que genera la base de "saber la respuesta". Los humanos gastan tiempo biológico para producir mejores respuestas, mientras que los agentes gastan más tiempo de cálculo para producir mejores respuestas.

Tal vez aún estés escéptico, pero hay muchos artículos que respaldan esto; sinceramente, la mera existencia del control de "razonamiento" es toda la prueba que necesitas.

Un artículo que me gusta mucho: los investigadores entrenaron con un pequeño conjunto de muestras de razonamiento cuidadosamente seleccionadas y luego utilizaron un método para forzar al modelo a seguir pensando cuando quería detenerse, específicamente agregando «Wait» (espera) en los puntos donde pretendía detenerse. Solo con esto, se mejoró un benchmark del 50% al 57%.

Quiero ser lo más directo posible: si siempre te quejas de que el código escrito por el agente es mediocre, el nivel máximo de pensamiento por sesión probablemente aún no sea suficiente para ti.

Te doy dos soluciones muy sencillas.

Método sencillo uno: WAIT (espera)

Lo más sencillo que puedes hacer hoy: configura un bucle automático; una vez construido, haz que el agente revise N veces con un contexto completamente nuevo, y cada vez que detecte un problema, lo solucione.

Si descubres que este sencillo truco mejora el rendimiento de tu agente, entonces al menos has entendido que tu problema es simplemente una cuestión de cantidad de tokens: únete al club de los que queman tokens.

Método sencillo 2: VERIFY (Verificar)

Haz que el agente verifique su trabajo lo antes posible y con frecuencia. Escribe pruebas para demostrar que la ruta seleccionada realmente funciona. Esto es especialmente útil para proyectos altamente complejos y profundamente anidados: una función puede ser llamada por muchas otras funciones aguas abajo. Detectar errores en la etapa inicial te ahorrará una gran cantidad de tiempo de cálculo posterior (tokens). Por lo tanto, si es posible, establece "puntos de verificación" en todo el proceso de construcción.

Después de escribir un fragmento, el agente principal dice que está listo. Pide que el segundo agente lo verifique. Los flujos de pensamiento no relacionados pueden cubrir el origen del sesgo sistemático.

Eso es básicamente todo. Podría escribir mucho más sobre este tema, pero creo que si solo te das cuenta de estos dos puntos y los implementas bien, podrás resolver el 95% de los problemas. Estoy convencido de que hacer bien las cosas simples y luego añadir complejidad según sea necesario es la clave.

Mencioné que la "novedad" es un problema que no se puede resolver con tokens, y quiero enfatizarlo nuevamente, porque tarde o temprano te encontrarás con este problema y vendrás a quejarte conmigo diciendo que acumular tokens no sirve.

Cuando el problema que deseas resolver no está en el conjunto de entrenamiento, tú eres la persona que realmente necesita proporcionar la solución. Por lo tanto, el conocimiento especializado en el campo sigue siendo extremadamente importante.