Якість виводу штучного інтелекту пов’язана зі знищенням токенів

Автор: Systematic Long Short

Переклад: Deep潮 TechFlow

Глибокий огляд: основний тезис цієї статті — лише одне речення: якість виводу AI Agent прямо пропорційна кількості вкладених токенів.

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

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

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

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

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

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

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

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

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

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

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

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

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

«Скільки буде 2+2?» Не потрібно багато токенів.

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

Ми виявили цікаву річ на практиці.

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

Тут є невелика, але важлива виняток.

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

Цей висновок насправді полегшив нам дихання.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я надаю вам два дуже прості рішення.

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

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

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

Простий спосіб 2: VERIFY (верифікація)

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

Написавши текст, головний агент сказав: «Готово»? Нехай другий агент перевірить. Несумісні потоки міркувань можуть приховати джерела системних упереджень.

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

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

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