Автор: Systematic Long Short
Компиляция: Deep Tide TechFlow
Введение от Deep Tide: Ключевой тезис этой статьи можно выразить одной фразой: качество вывода AI Agent прямо пропорционально количеству потраченных токенов.
Автор говорит не об абстрактной теории, а дает два конкретных метода, которые можно применять уже сегодня, и четко определяет границы, которые не преодолеть количеством токенов — «проблему новизны».
Для читателей, которые уже используют Agent для написания кода или рабочих процессов, информация здесь очень плотная и практичная.
Введение
Ладно, признайте, заголовок действительно броский — но, серьезно, это не шутка.
В 2023 году, когда мы использовали LLM для запуска продакшен-кода, окружающие были поражены, поскольку普遍 считалось, что LLM способны выдавать только непригодный мусор. Но мы знали то, чего другие не осознавали: качество вывода Agent — это функция от количества投入енных токенов. Все так просто.
Вы можете сами провести несколько экспериментов, чтобы убедиться в этом. Поручите Agent выполнить сложную, несколько нишевую programming задачу — например, с нуля реализовать алгоритм выпуклой оптимизации с ограничениями. Сначала выполните на минимальном уровне «размышлений»; затем переключитесь на максимальный, пусть он проверит свой код и посмотрит, сколько ошибок найдет. Попробуйте средний и высокий уровни. Вы наглядно увидите: количество ошибок монотонно уменьшается с ростом количества потраченных токенов.
Это несложно понять, верно?
Больше токенов = меньше ошибок. Вы можете продвинуть эту логику дальше, это basically упрощенная основная идея, стоящая за продуктами для code review. В совершенно новом контексте,投入ьте огромное количество токенов (например, заставьте его построчно анализировать код, определяя, есть ли в каждой строке ошибка) — так можно выловить绝大多数, если не все, ошибки. Этот процесс можно повторить десять, сто раз, каждый раз рассматривая код库 с «разных углов», и в конечном итоге вы выловите все ошибки.
У точки зрения, что «сжигание большего количества токенов повышает качество Agent», есть еще одно эмпирическое подтверждение: те команды, которые заявляют, что могут писать код с помощью Agent и сразу выкладывать его в продакшен, — либо сами провайдеры базовых моделей, либо компании с чрезвычайно большим финансированием.
Так что, если вы все еще расстраиваетесь, что Agent не выдает продакшен-код — скажу прямо, проблема в вас. Или, точнее, в вашем кошельке.
Как определить, достаточно ли я жгу токенов
Я написал целую статью о том, что проблема绝对 не в вашем фреймворке (harness), что «сохраняя простоту» still можно делать отличные вещи, и я до сих пор придерживаюсь этой точки зрения. Вы прочитали ту статью, последовали советам, но все равно разочарованы выводом Agent. Вы написали мне в DM, увидели, что я прочитал, но не ответил.
Эта статья — ответ.
Ваш Agent плохо справляется, не решает проблемы, в большинстве случаев просто потому, что вы жжете недостаточно токенов.
Сколько токенов нужно投入ить для решения проблемы, полностью зависит от масштаба, сложности и новизны этой проблемы.
«Сколько будет 2+2?» — много токенов не нужно.
«Напиши мне бота, который сканирует все рынки между Polymarket и Kalshi, находит семантически похожие рынки, которые должны结算 примерно в одно и то же событие, устанавливает границы безарбитражности и автоматически торгует с низкой задержкой при появлении арбитражной возможности» — для этого потребуется сжеть кучу токенов.
На практике мы обнаружили кое-что интересное.
Если вы投入ите достаточно токенов для решения проблем, вызванных масштабом и сложностью, Agent так или иначе справится. Другими словами, если вы хотите построить нечто чрезвычайно сложное, со множеством компонентов и строк кода,只要你 вложите足够多的 токенов в эти проблемы, они в конечном итоге будут полностью решены.
Здесь есть небольшое, но важное исключение.
Ваша проблема не должна быть слишком новой. На данном этапе никакое количество токенов не решит проблему «новизны». Достаточное количество токенов может снизить ошибки, вызванные сложностью, до нуля, но не может заставить Agent изобрести то, чего он не знает.
Этот вывод на самом деле нас обрадовал.
Мы потратили огромные усилия, сожгли — очень-очень много — токенов, пытаясь выяснить, сможет ли Agent восстановить институциональный инвестиционный процесс практически без нашего руководства. Отчасти это было сделано, чтобы понять, сколько лет нам (как количественным исследователям) осталось до полного вытеснения AI. Оказалось, что Agent просто не способен приблизиться к сколь-нибудь decentному институциональному процессу. Мы считаем, что отчасти это потому, что они никогда такого не видели — то есть, институциональные инвестиционные процессы в тренировочных данных просто не существовали.
Так что, если ваша проблема новаторская, не надейтесь решить ее堆чением токенов. Вам нужно самостоятельно направлять процесс исследования. Но как только вы определили план реализации, вы можете смело堆ть токены на execution —无论 код库多大、组件多复杂,都不是问题.
Вот простое эвристическое правило: Бюджет токенов должен расти пропорционально количеству строк кода.
Что на самом деле делают лишние токены
На практике дополнительные токены обычно повышают инженерное качество Agent следующими способами:
Позволяют ему потратить больше времени на рассуждения в одной попытке, дают шанс самостоятельно обнаружить ошибочную логику. Более глубокие рассуждения = лучшее планирование = выше вероятность успеха с первой попытки.
Позволяют ему сделать несколько независимых попыток, пойти разными путями решения. Некоторые пути лучше других. Разрешив more than one попытку, он может выбрать最优的.
Аналогично, больше независимых попыток планирования позволяют ему отказаться от слабых направлений и сохранить наиболее перспективные.
Больше токенов позволяют ему критиковать свою предыдущую работу в全新的 контексте, давая возможность улучшить,而不是 застрять в какой-то «инерции рассуждений».
И, конечно, мой любимый пункт: больше токенов означают, что он может использовать тесты и инструменты для проверки. Фактический запуск кода, чтобы посмотреть, работает ли он, — самый надежный способ подтвердить правильность ответа.
Эта логика работает, потому что инженерные неудачи Agent не случайны. Почти всегда они происходят из-за того, что слишком рано выбран неверный путь, не проверено, действительно ли этот путь可行 (на раннем этапе), или нет достаточного бюджета на восстановление и откат после обнаружения ошибки.
Вот и вся история. Токены буквально — это купленное вами качество решений. Представьте это как исследовательскую работу: если вы заставите человека сразу ответить на сложный вопрос, качество ответа будет падать с ростом временного давления.
Исследования, в конечном счете, это то, что порождает «знание ответа». Люди тратят биологическое время, чтобы дать лучшие ответы, Agent тратит больше вычислительного времени, чтобы дать лучшие ответы.
Как улучшить вашего Agent
Вы, возможно, все еще сомневаетесь, но есть много статей, подтверждающих это, и, честно говоря, само наличие «регулятора рассуждений» — это все доказательство, которое вам нужно.
Мне особенно нравится одна статья, где исследователи тренировали модель на небольшой тщательно отобранной выборке рассуждений, а затем强制 заставляли модель продолжать думать, когда она хотела остановиться — конкретно, добавляя «Wait» (Подожди) в месте, где она хотела остановиться.仅此一项, повысило результат в одном benchmark с 50% до 57%.
Я хочу быть максимально прямолинейным: если вы постоянно жалуетесь, что код от Agent получается посредственным, даже single最高档思考 для вас, скорее всего, недостаточно.
Я дам вам два очень простых решения.
Простое решение первое: WAIT (Подожди)
Самое простое, что вы можете начать делать уже сегодня: настройте автоматический цикл — после сборки пусть Agent reviewит свою работу N раз с全新 контекстом, каждый раз исправляя найденные проблемы.
Если вы обнаружите, что этот простой трюк улучшает результаты вашего инженерного Agent, то вы, по крайней мере, поняли, что ваша проблема — лишь в количестве токенов — тогда добро пожаловать в клуб сжигателей токенов.
Простое решение второе: VERIFY (Проверяй)
Заставляйте Agent проверять свою работу рано и часто. Пишите тесты, чтобы доказать, что выбранный путь действительно работает. Это особенно полезно для highly сложных, deeply вложенных проектов — одна функция может вызываться многими другими downstream функциями. Возможность поймать ошибку на upstream сэкономит вам массу последующего вычислительного времени (токенов). Так что, если возможно, расставляйте «контрольные точки проверки» throughout всего процесса сборки.
Написали что-то, главный Agent говорит, готово? Пусть второй Agent проверит. Несвязанные потоки мышления могут покрыть источники систематических смещений.
В основном, это все. Я мог бы написать намного больше на эту тему, но я считаю, что осознание этих двух вещей и их хорошая implementation помогут решить 95% ваших проблем. Я твердо верю в то, чтобы делать простые вещи превосходно, и добавлять сложность по мере необходимости.
Я упомянул, что «новизна» — это проблема, которую не решить токенами, и я хочу подчеркнуть это еще раз, потому что вы рано или поздно наткнетесь на эту яму и придете ко мне плакаться, что堆чение токенов не работает.
Когда проблема, которую вы хотите решить, отсутствует в тренировочном наборе, именно вы тот, кто должен предоставить решение. Следовательно, экспертные знания в предметной области по-прежнему чрезвычайно важны.
