AI Agent видає сміття? Проблема в тому, що ти не хочеш спалювати токени

作者：Systematic Long Short

編譯：深潮 TechFlow

深潮導讀：Ця стаття має один основний тезис: якість вихідних даних AI-агента прямо пропорційна кількості використаних токенів.

Автор не просто розмірковує теоретично, а надає два конкретні методи, які можна застосовувати вже сьогодні, і чітко окреслює межу, за якою не можна перейти — «проблема новизни».

Для читачів, які використовують агент для написання коду або запуску робочих процесів, інформація дуже насичена та практично застосовна.

Вступ

Добре, ви маєте визнати, що ця назва справді привертає увагу — але чесно кажучи, це не жарт.

У 2023 році, коли ми ще використовували LLM для виробництва коду, навколишні були вражені, бо загальне уявлення тоді було, що LLM може лише генерувати непотрібний сміття. Але ми знаємо одну річ, яку інші не помітили: якість виходу агента — це функція кількості вкладених токенів. Просто.

Самі можете переконатися, провівши кілька експериментів. Наприклад, доручити агенту виконати складне, маловідоме завдання програмування — наприклад, з нуля реалізувати обмежений алгоритм оптимізації. Спершу з мінімальним рівнем роздумів; потім переключитися на максимально глибокий рівень, щоб він переглянув свій код і знайшов стільки багів. Спробувати середній і високий рівень. Ви побачите наочно: кількість багів зменшується з ростом вкладених токенів.

Це не важко зрозуміти, так?

Більше токенів = менше помилок. Це логіка, яка лежить в основі процесу code review — спрощеної, але суті. В іншому контексті, вкладення великої кількості токенів (наприклад, щоб він по рядках аналізував код і визначав, чи є там баги) — дозволяє виявити більшість або всі баги. Цей процес можна повторювати десять, сто разів, кожного разу з різних точок зору — і в кінці ви зможете знайти всі баги.

Ідея «більше токенів — вища якість агента» має ще одне підтвердження: ті команди, що стверджують, ніби агент може писати код і запускати його у виробництво безпосередньо, або — це самі провайдери базових моделей, або дуже багаті компанії.

Тому, якщо ви досі мучитеся через те, що агент не генерує виробничий код — чесно кажучи, проблема у вас. Або у вашому гаманці.

Як визначити, чи достатньо ви вкладали токенів

Я писав цілу статтю про те, що проблема точно не у вашій системі (harness), «зберігайте простоту» — і досі дотримуюся цієї думки. Ви її прочитали, зробили за інструкціями, але все одно розчаровані виходом агента. Ви написали мені в DM, я прочитав, але не відповів.

Це — відповідь.

Якщо агент погано працює і не вирішує проблему — швидше за все, ви вкладали недостатньо токенів.

Скільки потрібно вкладати токенів для вирішення задачі — залежить від її масштабу, складності та новизни.

«2+2 — скільки?» — не потребує багато токенів.

«Допоможи мені написати бота, який сканує всі ринки між Polymarket і Kalshi, знаходить схожі за змістом імовірно одні й ті ж події, встановлює безарбітражні межі, і автоматично торгує при появі можливості» — це вже потребує багато токенів.

Ми в практиці помітили цікаву річ.

Якщо вкладати достатньо токенів для вирішення масштабних і складних задач, агент здатен їх вирішити. Іншими словами, якщо ви хочете створити щось дуже складне, з багатьма компонентами і рядками коду — достатньо вкладати токени, і вони будуть вирішені.

Є один важливий виняток.

Ваше питання не повинно бути надто новим. На даному етапі жодна кількість токенів не здатна подолати «проблему новизни». Достатньо вкладати багато токенів — і зменшити помилки, що виникають через складність, — можливо. Але агент не зможе самостійно винаходити нові ідеї, яких не бачив у тренувальних даних.

Цей висновок нас полегшує.

Ми витратили багато ресурсів, вкладали — багато і дуже багато — токенів, щоб спробувати змусити агента відтворити процес інституційних інвестицій без підказок. Частково це було для того, щоб зрозуміти, скільки років залишилось до повної автоматизації таких процесів. І виявили, що агент не здатен навіть близько імітувати нормальний інституційний процес — бо такого у тренувальних даних просто немає.

Отже, якщо ваше питання — нове, не сподівайтеся, що вирішите його просто вкладенням токенів. Вам потрібно самостійно керувати дослідженням. Але коли ви визначили рішення — можете сміливо вкладати токени для його реалізації — незалежно від розміру коду чи кількості компонентів.

Є простий евристичний принцип: кількість токенів має зростати пропорційно кількості рядків коду.

Що робить більше токенів

На практиці додаткові токени зазвичай підвищують якість роботи агента за рахунок:

Дозволяють йому витратити більше часу на роздуми, щоб самостійно виявити логічні помилки. Чим глибше роздуми — тим краще планування — і тим вищий шанс влучити у ціль.

Дають можливість робити кілька незалежних спроб, досліджуючи різні шляхи розв’язання. Деякі з них кращі за інші. Можливість спробувати кілька разів дозволяє обрати найкращий.

Аналогічно, більше незалежних спроб дозволяє відмовитися від слабких напрямків і зосередитися на найперспективніших.

Більше токенів — більше можливостей для критики власної роботи у новому контексті, щоб дати їй шанс на покращення, а не застрягти у «інерції» логіки.

Звісно, ще одна моя улюблена ідея: більше токенів — це можливість використовувати тестування і інструменти для перевірки. Запустити код і побачити, чи працює — найнадійніший спосіб підтвердити правильність.

Ця логіка працює, бо провали агента у технічних задачах — не випадкові. Зазвичай це через передчасний вибір неправильного шляху, відсутність перевірки його життєздатності (на ранніх етапах), або через недостатній бюджет для відкату і виправлення помилок.

Отже, історія така. Токени — це буквально ваші інвестиції у якість рішень. Уявіть, що це — дослідження: якщо попросити людину відповісти на складне питання за обмежений час, якість відповіді зменшується з ростом тиску часу.

Дослідження — це, в кінцевому підсумку, процес здобуття «знання відповіді». Люди витрачають біологічний час, щоб отримати кращу відповідь, агент — витрачає обчислювальний час.

Як покращити свого агента

Можливо, ви й сумніваєтесь, але багато досліджень підтверджують цю ідею: регулювання «роздумів» — це все, що вам потрібно.

Мені дуже подобається одна стаття, де дослідники навчили модель на невеликій кількості ретельно підібраних прикладів роздумів, а потім примусили її продовжувати думати, додавши слово «Wait» (зачекай) там, де вона хотіла зупинитися. Лише це підвищило результати на одному з бенчмарк-тестів з 50% до 57%.

Щиро кажучи, якщо ви постійно скаржитеся, що агент погано пише код — швидше за все, вам потрібно більше часу для роздумів.

Ось два дуже простих рішення.

Простий спосіб один: WAIT (зачекай)

Вже сьогодні можете зробити найпростіше: налаштувати автоматичний цикл — після завершення — щоб агент переглядав свій код N разів, кожного разу виправляючи помилки.

Якщо цей простий трюк покращить результати — ви зрозумієте, що проблема у кількості токенів. Тоді приєднуйтесь до клубу вкладення токенів.

Простий спосіб два: VERIFY (перевірка)

Дайте агенту раніше і частіше перевіряти свою роботу. Створюйте тестові сценарії, щоб переконатися, що обраний шлях дій справді працює. Це особливо важливо для складних, глибоко вкладених проектів — функція може викликатися з багатьох місць. Виявлення помилок на ранніх етапах зекономить вам багато обчислювальних ресурсів (токенів). Тому, якщо можливо, встановлюйте «контрольні точки» перевірки по всьому процесу створення.

Після завершення частини роботи, головний агент каже, що все зроблено? Запустіть другий агент для перевірки. Не пов’язані потоки думок допоможуть виявити системні похибки.

Ось і все. Про цю тему можна писати ще багато, але я вважаю, що достатньо усвідомити ці два принципи і правильно їх застосовувати — і ви вирішите 95% проблем. Вірю, що прості речі потрібно доводити до досконалості, а потім додавати складність за потреби.

Я вже згадував, що «новизна» — це проблема, яку токени не здатні вирішити. Хочу ще раз підкреслити — бо рано чи пізно ви натрапите на цю пастку і почнете скаржитися, що вкладення токенів безглузді.

Якщо ваша проблема — нова і не входить у тренувальний набір, саме ви маєте бути тим, хто знайде рішення. Тому галузеві знання залишаються дуже важливими.