Autor: Systematic Long Short
Compilado por: Deep Tide TechFlow
Guía de Deep Tide: El argumento central de este artículo es solo una frase: la calidad de la salida del Agente de IA es proporcional a la cantidad de Tokens que inviertes.
El autor no está hablando en términos generales teóricos, sino que ofrece dos métodos específicos que puedes comenzar a usar hoy, y delimita claramente el límite de lo que los Tokens no pueden lograr: 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 practicidad son muy altas.
Introducción
Bueno, tienes que admitir que el título es bastante llamativo, pero en serio, no es una broma.
En 2023, cuando todavía estábamos usando LLM para ejecutar código de producción, la gente a nuestro alrededor se quedó boquiabierta, porque la percepción general en ese momento era que LLM solo podía producir basura inutilizable. Pero sabíamos algo que otros no se daban cuenta: la calidad de la salida del Agent es una función de la cantidad de Tokens que inviertes. Así de simple.
Puedes verlo ejecutando algunos experimentos tú mismo. Pídele a un Agent que complete una tarea de programación compleja y algo oscura, por ejemplo, implementar desde cero un algoritmo de optimización convexa con restricciones. Primero ejecútalo en el nivel de pensamiento más bajo; luego cámbialo al nivel más alto, pídele que revise su propio código y vea cuántos errores puede encontrar. Prueba el nivel medio y el alto. Verás intuitivamente: la cantidad de errores disminuye monótonamente a medida que aumenta la cantidad de Tokens invertidos.
No es difícil de entender, ¿verdad?
Más Tokens = Menos errores. Puedes llevar esta lógica un paso más allá, y esto es básicamente la idea central (simplificada) detrás de los productos de revisión de código. Cambia a un contexto completamente nuevo, invierte una gran cantidad de Tokens (por ejemplo, pídele que analice el código línea por línea, juzgando si cada línea tiene errores); así básicamente puedes detectar la gran mayoría, o incluso todos, los errores. Este proceso se puede repetir diez veces, cien veces, cada vez examinando el código desde un "ángulo diferente"; eventualmente podrás desenterrar todos los errores.
Este punto de vista de que "quemar más Tokens mejora la calidad del Agent" también tiene un apoyo empírico: los equipos que afirman poder usar Agent para escribir código de principio a fin y llevarlo directamente a producción, son要么 los propios proveedores de modelos base,要么 empresas extremadamente bien financiadas.
Entonces, si todavía estás luchando porque tu Agent no produce código de nivel de producción, seamos directos: el problema eres tú. O más bien, tu billetera.
Cómo saber si estoy gastando suficientes Tokens
Escribí un artículo completo diciendo que el problema definitivamente no está en tu marco de trabajo), "mantener la simplicidad" aún puede producir cosas excelentes, y sigo manteniendo ese punto de vista. Lo leíste, lo seguiste, pero aún estás muy decepcionado con la salida del Agent. Me enviaste un DM, viste que lo leí pero no respondí.
Este artículo es la respuesta.
El rendimiento deficiente de tu Agent, su incapacidad para resolver problemas, en la mayoría de los casos, se debe simplemente a que no estás gastando suficientes Tokens.
La cantidad de Tokens necesarios para resolver un problema depende completamente de la escala, complejidad y novedad de ese problema.
"¿Cuánto es 2+2?" No requiere muchos Tokens.
"Ayúdame a escribir un bot que pueda escanear todos los mercados entre Polymarket y Kalshi, encontrar mercados que sean semánticamente similares y que deberían liquidarse alrededor del mismo evento, establecer límites de no arbitraje, y operar automáticamente con baja latencia tan pronto como surja una oportunidad de arbitraje" — esto requiere quemar un montón de Tokens.
En la práctica, descubrimos algo interesante.
Si inviertes suficientes Tokens para abordar problemas causados por la escala y la complejidad, el Agent los resolverá sin importar qué. En otras palabras, si quieres construir algo extremadamente complejo, con muchos componentes y líneas de código, siempre y cuando arrojes suficientes Tokens a estos problemas, eventualmente se resolverán por completo.
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". Suficientes Tokens pueden reducir los errores causados por la complejidad a cero, pero no pueden hacer que el Agent invente algo que no sabe.
Esta conclusión en realidad nos alivió.
Invertimos un esfuerzo enorme, quemamos —muchos, muchos, muchísimos— Tokens, intentando ver si podíamos hacer que un Agent reconstruyera un proceso de inversión institucional con casi ninguna guía. En parte, esto fue para averiguar cuántos años nos quedan (como investigadores cuantitativos) antes de ser completamente reemplazados por la IA. Resulta que el Agent simplemente no puede acercarse a un proceso de inversión institucional decente. Creemos que esto se debe en parte a que nunca han visto algo así, es decir, el proceso de inversión institucional simplemente no existe en los datos de entrenamiento.
Por lo tanto, si tu problema es novedoso, no cuentes con resolverlo acumulando Tokens. Necesitas guiar el proceso de exploración tú mismo. Pero una vez que hayas determinado el plan de implementación, puedes confiar en acumular Tokens para ejecutarlo — no importa cuán grande sea la base de código o cuán complejos sean los componentes, no es un problema.
Aquí hay un principio heurístico simple: el presupuesto de Tokens debería crecer proporcionalmente al número de líneas de código.
Qué hacen exactamente los Tokens adicionales
En la práctica, los Tokens adicionales generalmente mejoran la calidad de la ingeniería del Agent de las siguientes maneras:
Permitirle dedicar más tiempo al razonamiento en el mismo intento, dándole la oportunidad de descubrir errores lógicos por sí mismo. Razonamiento más profundo = mejor planificación = mayor probabilidad de acertar a la primera.
Permitirle realizar múltiples intentos independientes, tomando diferentes caminos de solución. Algunos caminos son mejores que otros. Permitir más de un intento le permite elegir el óptimo.
De manera similar, más intentos de planificación independiente le permiten abandonar direcciones débiles y conservar las más prometedoras.
Más Tokens le permiten criticar su trabajo anterior con un contexto completamente nuevo, dándole la 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 para ver si funciona es la forma más confiable de confirmar que la respuesta es correcta.
Esta lógica funciona porque los fracasos de ingeniería del Agent no son aleatorios. Casi siempre se deben a que eligió el camino equivocado demasiado pronto, no verificó si ese camino era realmente viable (al principio), o no tuvo suficiente presupuesto para recuperarse y retroceder después de descubrir el error.
Esa es la historia. Los Tokens son literalmente la calidad de decisión que compras. Piensa en ello como investigación: si le pides a una persona que responda una pregunta difícil en el acto, la calidad de la respuesta disminuirá a medida que aumente la presión del tiempo.
La investigación, en última instancia, es lo que genera el "saber la respuesta". Los humanos gastan tiempo biológico para producir mejores respuestas, los Agents gastan más tiempo de computación para producir mejores respuestas.
Cómo mejorar tu Agent
Puede que aún seas escéptico, pero hay muchos artículos que respaldan esto y, sinceramente, la existencia misma del "mando de regulación del razonamiento" es toda la prueba que necesitas.
Un artículo que me gusta especialmente, los investigadores entrenaron con un pequeño lote de muestras de razonamiento cuidadosamente seleccionadas, y luego forzaron al modelo a seguir pensando cuando quería detenerse usando un método — específicamente, agregando "Wait" (espera) donde quería parar. Solo esto, mejoró un punto de referencia del 50% al 57%.
Quiero ser lo más directo posible: si te has quejado de que el código escrito por el Agent es mediocre, es muy probable que el nivel de pensamiento más alto en un solo intento aún no sea suficiente para ti.
Te doy dos soluciones muy simples.
Práctica simple uno: WAIT (ESPERA)
Lo más simple que puedes comenzar a hacer hoy: configura un bucle automático — después de construir, haz que el Agent revise N veces con un contexto nuevo, reparando cada vez que encuentre un problema.
Si descubres que este simple truco mejora los efectos de tu ingeniería de Agent, entonces al menos entiendes que tu problema es solo una cuestión de cantidad de Tokens — únete al club de quemar Tokens.
Práctica simple dos: VERIFY (VERIFICAR)
Haz que el Agent verifique su propio trabajo temprano y con frecuencia. Escribe pruebas para demostrar que el camino elegido 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. Poder detectar errores aguas arriba puede ahorrarte mucho tiempo de cálculo posterior (Tokens). Así que, si es posible, configura "puntos de control de verificación" en todo el proceso de construcción.
¿Después de escribir algo, el Agent principal dice que está listo? Que un segundo Agent lo verifique. Flujos de pensamiento no relacionados pueden cubrir fuentes de sesgo sistemático.
Eso es básicamente todo. Podría escribir mucho más sobre este tema, pero creo que solo darse cuenta de estas dos cosas y ejecutarlas bien puede ayudarte el 95% de los problemas. Creo firmemente en hacer las cosas simples extremadamente bien, y luego agregar complejidad según sea necesario.
Mencioné que la "novedad" es un problema que los Tokens no pueden resolver, y quiero enfatizarlo nuevamente, porque eventualmente te encontrarás con este obstáculo y vendrás a llorarme diciendo que acumular Tokens no funciona.
Cuando el problema que intentas resolver no está en el conjunto de entrenamiento, tú eres quien realmente necesita proporcionar la solución. Por lo tanto, la experiencia especializada en el dominio sigue siendo extremadamente importante.
