Ваш агент не знає, коли зупинитися. Як написати умову зупинки до релізу

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт, це Ігор Івіцький. Вісім років займався математичним моделюванням і викладав, останні роки розбираю, куди в автоматичних рекламних системах дівається прибуток. Свій підхід до такого розбору я називаю Profit Forensics.

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

І одразу звужу обіцянку, щоб ви не витрачали час. Це не runbook для LLM-агентів і не розбір агентного циклу зсередини: про будову циклу на DOU вже писали докладно, зокрема Юрій Гуц. Я про інше. Не як агент крутиться, а за якою заздалегідь записаною умовою його зупиняють, коли самозвіт зелений, а результат ні.

Чому «ми стежимо за метриками» не є умовою зупинки

Найнудніше запитання, яке я ставлю командам: за яких умов ви його зупините?

Далі пауза. Потім щось із трьох:

• «ми стежимо за метриками»;
• «якщо стане гірше, побачимо»;
• «у нас є дашборд».

Жодне з трьох не зупиняє агента. Це обіцянка, що хтось колись подивиться.

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

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

Про це вже все написано, просто не в нашій індустрії

Люди, які автоматизували атомні станції і літаки, пройшли цей шлях раніше за нас.

Bainbridge у статті «Ironies of automation» (1983) показала просту річ: що краще система справляється зі звичайним, то гірше людина реагує на рідкісне. Автоматика забирає рутину і лишає оператору аномалії, а навичка розбирати аномалії тримається саме на тій рутині, якої вже немає.

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

Повні посилання поклав у кінці, якщо захочете перевірити самі.

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

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

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

Self-score виконавця не рятує (і Optimization Score теж)

Спокуса очевидна: нехай умову зупинки дасть сама система, у неї ж є вбудований health-score. У рекламі такий показник існує давно. Google рахує Optimization Score від нуля до ста відсотків, і ціла індустрія підрядників звітує клієнтам саме ним.

У моїй вибірці є ніша, де сім прямих конкурентів змагаються за ті самі запити. Один акаунт має Optimization Score 99,1%. При цьому 18,7% його витрат ідуть на пошукові запити, які не дали жодної конверсії, а клік він купує на 14% дорожче за медіану ніші. Його сусід по ніші має оцінку 48,8% і вдвічі менше злитих грошей: 8,9% витрат у нуль і клік на 64% дешевший за медіану. Третій гравець того самого ринку з оцінкою 86,6% зливає ще менше, 6,4%.

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

Якби я був на чергуванні і побачив 99,1%, я б спокійно пішов спати. Саме тому такий показник не годиться на роль критерію зупинки. Він вимірює, наскільки слухняно ви виконуєте підказки платформи, а не результат для власника грошей, тому й росте, коли ви робите те, що вам сказали.

Застереження, щоб не було ілюзій. Optimization Score є у 23 акаунтах моєї вибірки, у 22 з них я маю ще й порахований злив. Слабкий зв’язок між цими двома величинами справді є, і він радше на користь оцінки: коефіцієнт Спірмена мінус 0,39, тобто вища оцінка в середньому йде з трохи меншим зливом. Я його не ховаю, бо він нічого не змінює. Серед семи акаунтів з оцінкою 85% і вище злив іде від 1,3% до 31,3% бюджету, і за самою оцінкою ви ці випадки не розрізните. Це не формальна статистична перевірка, і я стверджую менше, ніж міг би. Але цього достатньо: показник, який дає вам сам виконавець, не може бути критерієм його зупинки.

Те саме стосується агентів: self-check, власна оцінка впевненості, зелений статус у логах, відсоток завдань із позначкою «виконано». Усе це вимірює відповідність інструкції.

Зелені логи, які нічого не значать

У мене є скрипт, який щодня знімає, чи згадують мої матеріали AI-пошуковики. 10 серпня я з іншого приводу зробив той самий запит вручну і отримав відповідь «не вистачає кредитів»: безкоштовна квота ключа скінчилася.

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

Механізм такий. Якби я в ті дні відкрив лог і побачив «нуль згадок», то сприйняв би це як факт про світ. А це виявилося фактом про інструмент. Різниця між «немає результату» і «не було вимірювання» ніде не була записана, тому її ніхто і не перевіряв.

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

Ціль це вхідний параметр, а не обіцянка

Ще одна ілюзія: якщо ціль задано числом, система її виконає.

Я взяв 1950 рекламних кампаній на 42,2 мільйона доларів витрат, де рекламодавець явно задав цільову вартість конверсії, і подивився, наскільки автоматика в неї влучила. Критерії відбору прості: кампанії з живою ціллю, реальними конверсіями і витратами понад тисячу доларів, сім вертикалей, вікно пів року.

У межах ±10% від заявленої цілі опинилися 34% кампаній. 36% перевищили ціль понад 20%. Інші 30% розподілилися між недобором і помірним перебором, і недобір тут не є доброю новиною: він так само доводить, що система не тримає задане число.

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

Якщо ви ставите агентові KPI і не описали, що робити з розкидом навколо нього, ви поставили побажання.

Що має бути в умові: чотири поля

Якщо бракує хоча б одного, у вас не умова, а тривожний текст.

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

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

Вікно в подіях, а не в днях. Не «за тиждень», а «за 200 подій». Умова, прив’язана до календаря, спрацьовує на шумі: у понеділок вона червона, у середу зелена, і за два тижні команда вчиться її ігнорувати. Розмір вікна беріть такий, за якого випадкове коливання метрики помітно менше за ваш поріг. Для низькочастотних процесів це може означати квартал очікування, і тоді поруч потрібна друга умова, вже груба і календарна: на витрачені гроші або час.

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

Дій насправді три, і вибирати між ними краще заздалегідь, а не о другій ночі:

• Вимкнення. Агент зупиняється повністю, черга йде до людей. Дорого, але передбачувано. Це те, що ставлять за замовчуванням, коли взагалі не розуміють, що відбувається.
• Звуження. Агент лишається, але працює тільки на простих категоріях, зі зниженим лімітом і без ризикових дій, а решту віддає людині. На практиці цей варіант найкорисніший, бо його не страшно вмикати автоматично.
• Відкат. Повернення на попередню версію промпта, моделі чи конфіга. Працює тільки якщо ця версія збережена і позначена. Інакше в момент інциденту з’ясується, що повертатися нема куди.

Порівняйте два формулювання.

Не працює: «зупинити, якщо результати погіршаться».

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

Числа тут приклад формату, а не універсальний поріг.

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

Що з цього переноситься на агента, а що ні

Аналогія з рекламними торгами працює доти, доки відмова схожа: величина поїхала, а система рапортує норму. Частина відмов LLM-агента влаштована інакше, і чесно показати, що ловиться, а що ні.

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

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

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

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

Чого моя аналогія не покриває взагалі: недетермінованість. У рекламних торгах вимірювання можна повторити, у LLM-агента дві однакові спроби дають різні відповіді, і будь-який поріг доводиться ставити із запасом на власний шум системи. Скільки саме запасу, у мене чесної відповіді немає.

Як прогнати умову на історії за пів дня

Умову зупинки можна протестувати так само, як тестують код.

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

Перевірка на подіях, які ви пам’ятаєте. У кожній команді є дві-три історії «ми тоді довго не помічали». Прогоніть умову на них: спрацювала б, і за скільки днів до того, як помітили люди? Це і є її цінність, виміряна в днях.

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

Де умова мовчить

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

І межа мого досвіду. Більшість цифр тут походить із рекламних систем, а не з LLM-агентів у великому проді. Можливо, дрейф промпта робить класичні умови зупинки марними саме там, де вони найпотрібніші, і моя аналогія ламається. Якщо ви вже ганяли агентів у проді і бачили таке на власні очі, приносьте кейси в коментарі, розберемо.

Висновок

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

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

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