Не варто платити за обхідні маневри ШІ

Не те щоб провідні компанії у сфері ШІ не намагалися схилити шальки терезів на свою користь, продаючи нам токени, якби могли це провернути: зрештою, у червні Anthropic фактично підвищила ціни на 30%; у серпні DeepSeek підвищила ціни на API; а наприкінці вересня OpenAI неохоче відмовилася від скорочення середнього ліміту токенів. Тож тепер цілком очевидна тенденція до економії.

І справді, ця думка часто повертається, коли ваш ШІ-агент за 45 хвилин спалює весь денний ліміт токенів на не завжди видатний код, а потім пропонує повернутися за 3-4 години. У такий прикрий момент мимоволі замислюєшся, чи не працюють деякі процеси, залучені до цього, на користь постачальників. Зрештою, це хороший спосіб змусити нас викласти гроші за спеціальне поповнення запасу токенів — або навіть увімкнути «автоматичне поповнення».

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

Боротьба з марнотратством

Те, що ШІ-агенти марнують токени (а отже, і ваші гроші), коли міркують в агентних робочих процесах, є вже добре відомим фактом: рівно рік тому я писав про нове дослідження, яке показало, наскільки моделі ШІ для міркувань схильні спалювати токени через «багатослівність»; на початку цього року — про інше дослідження, у якому йшлося про міркування у формі ланцюжка думок як про «декоративний елемент»; а минулого тижня керівник продуктового напряму Tsuga Нілс Бунге у статті з експертним поглядом, опублікованій тут, заявив:

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

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

Під назвою How Do Ai Agents Waste Your Money? ця нова спільна академічна робота американських дослідників* пропонує єдину систему оцінювання, що дає змогу визначити, скільки токенів насправді марнується в агентних процесах. Коли йдеться про моделі із закритим вихідним кодом, методологію «тіньового» аналізу поєднують з офіційною статистикою та показниками постачальників, щоб отримати настільки ж докладну картину того, що відбувалося з токенами під час міркувань і дій ШІ:

Новий метод вимірювання марно витрачених токенів ШІ. Фіксують міркування, дії та витрати кожного агента, а потім аналізують їх на предмет повторів, непотрібних запитів і зайвих відхилень від мети. Виявлені марні витрати усувають і знову перевіряють, чи здатен агент виконати початкове завдання. Джерело

Як показано вище, агенту дають змогу працювати у звичайному режимі, перехоплюючи та записуючи комунікацію з постачальником ШІ, зокрема міркування, використання інструментів, споживання токенів і витрати. Потім записи аналізують судді — великі мовні моделі (LLM), які відокремлюють корисну роботу від повторів, непотрібних пошуків і відхилень від мети. Після цього ймовірні марні витрати усувають, обчислюють заощаджені токени, а агент продовжує роботу, щоб з’ясувати, чи можна й далі успішно виконати завдання.

Під час тестування дослідники виявили, що близько 18% вихідних токенів агентів витрачалися марно. У понад 45% завдань один агент марнував більше токенів, ніж іншому потрібно було для успішного виконання тієї самої роботи. Також вони з’ясували, що усунення 41–46% непотрібних міркувань майже не впливало на продуктивність, а це свідчить про те, що можна істотно заощадити, не погіршуючи суттєво результати.

У статті зазначено:

«У всіх зібраних траєкторіях приблизно 18% вихідних токенів визначено як марні».

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

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

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

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

У статті також досліджено, як різні програмні оболонки спричиняють марнування токенів. Виявилося, що та сама модель ШІ, Kimi-K3, залежно від використовуваної оболонки могла витрачати на міркування більш ніж учетверо більше токенів на тих самих завданнях, не обов’язково досягаючи кращих результатів.

Частину марнування спричиняли базові програмні помилки: з’ясувалося, що OpenCode, Kimi Code CLI та OpenClaw неодноразово запускали завдання не в тому середовищі Python, що призводило до помилок і повторних спроб, які спалювали токени. Kimi Code CLI також дозволяв ШІ запитувати час очікування, який сама програма відхиляла, змушуючи робити ще більше дорогих спроб.

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

‘[Several]На перший погляд очевидні властивості оболонки не завжди пояснюють виявлені відмінності в марнуванні ресурсів. Наприклад, як показано [below], оболонки, що надають доступ до більшої кількості інструментів, не обов’язково марнують більше ресурсів. OpenClaw надає доступ до значно більшої кількості інструментів, ніж інші оболонки, проте марнує ресурси лише помірною мірою. Крім того, не всі випадки марнування залежать від оболонки.

«[Below right] показує, що на SWE-bench Verified регулярно трапляється відхилення від основного шляху: Kimi-K3 записує те, що вважає початковим виправленням проєкту, а згодом відмовляється від нього».

Результати тестування, що порівнюють кількість змарнованих токенів у програмних оболонках для агентів ШІ. Ліворуч: більша кількість інструментів не обов’язково збільшує марнування. Праворуч: Kimi-K3 неодноразово намагається застосувати й відкидає нібито початкове виправлення програмного забезпечення незалежно від оболонки, але рідко робить це під час виконання завдань іншого типу.

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

Методика

Щоб відтворити роботу агента ШІ, дослідники відстежували кожен обмін між моделлю та програмним забезпеченням, яке нею керувало, записуючи міркування, відповіді, запити до інструментів і витрати токенів. Рівень деталізації залежав від постачальника: Kimi-K3 розкриває весь процес міркування, Gemini 3.1 Pro — лише його підсумки, а Claude не розкриває нічого.

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

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

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

Чотири гравці

У дослідженні визначено чотири повторювані моделі марнування токенів: Повторення (повторення відомої інформації); Дублювання запитів (повторення непотрібних запитів до інструментів); Наповнення (додавання нерелевантного тексту); і Обхідний шлях (спроби застосувати правдоподібні, але зрештою непродуктивні підходи).

Кожну записану сесію перевіряла модель LLM-as-a-Judge (LLMaJ**), якій надали початкове завдання, повний запис сесії та критерії для виявлення всіх чотирьох типів марного використання ресурсів. Імовірно зайві фрагменти позначали й вилучали, після чого повторно підраховували решту токенів, щоб визначити частку та вартість марних витрат. Потім підрахунки звіряли з власними токенізаторами або інструментами підрахунку кожного провайдера та даними про використання токенів у виводі, які він надавав (повідомлялося лише про незначні відмінності у форматуванні).

Тести

У дослідженні перевіряли такі моделі: Kimi-K3; Gemini 3.1 Pro; GPT-5.6 Terra; GPT-6 Astra; Claude Sonnet 5; і Claude Fable 5.1. Їх тестували на таких бенчмарках: τ²-bench (обслуговування клієнтів авіакомпаній і роздрібної торгівлі); SWE-bench Verified (розробка програмного забезпечення); Claw-Eval; і MCP-Atlas (використання інструментів загального призначення).

Крім того, Kimi-K3 тестували з різними рівнями міркування, а також порівняли п’ять агентних середовищ: OpenCode; OpenClaw; OpenHands; Hermes; і Kimi Code CLI. Ці порівняння використовували, щоб оцінити, як моделі, завдання, інтенсивність міркування та конструкція агентного середовища впливають на марні витрати токенів (а в додаткових тестах імовірно зайві фрагменти вилучали, щоб перевірити їхній вплив на продуктивність).

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

Результати тестів, що порівнюють марні витрати на вивід у шести моделях ШІ, усереднені за чотирма бенчмарками. Ліворуч: загальна частка марних витрат, внутрішні міркування Kimi-K3 показано окремо. Праворуч: частка марних витрат для успішних і невдалих завдань; невдалі завдання зазвичай спричиняли більші марні витрати.

Як видно вище, марними визнали від 11% до 24.9% коштів, витрачених на генерування відповідей і використання інструментів: найкращий результат показала GPT-6 Astra, а найгірший — Claude Sonnet 5. У Kimi-K3 марно витрачався приблизно кожен шостий токен, використаний для відповідей і роботи з інструментами; під час внутрішнього міркування ця частка зростала до понад кожного четвертого токена.

Зазвичай невдалі завдання супроводжувалися більшими марними витратами, хоча у випадку з міркуваннями Kimi-K3 спостерігалася протилежна картина; також не було чітких доказів того, що витрачання більшої кількості токенів на непотрібну роботу підвищувало шанси на успіх.

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

Результати тестів, що показують, як вилучення зайвих міркувань ШІ вплинуло на частку успішно виконаних завдань у двох бенчмарках. Вилучення 41-46% міркувань майже не вплинуло на продуктивність, тоді як вилучення всіх міркувань призвело до значно більшої кількості невдач.

У SWE-bench Verified вилучили 41% міркувань без втрати продуктивності; фактично частка успішних результатів трохи зросла — з 89% до 89.5%. У MCP-Atlas вилучили 46% міркувань, і частка успішних результатів знизилася лише незначно — з 65% до 62.3%.

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

Нарешті^†, Kimi-K3 протестували на однакових завданнях із використанням різних агентних середовищ. Як показано нижче, обсяг згенерованих міркувань відрізнявся більш ніж у чотири рази, однак це не давало жодного послідовного покращення продуктивності:

Результати тестів, що порівнюють кількість використаних Kimi-K3 токенів у різних агентних середовищах на двох бенчмарках. Внутрішні міркування позначено синім, а відповіді та виклики інструментів — помаранчевим. Під час виконання завдань із програмування Mini-SWE згенерувало більш ніж учетверо більше міркувань, ніж Hermes.

Частину марних витрат пов’язали з базовими програмними помилками. OpenCode, Kimi Code CLI та OpenClaw запускали тести з програмування в неправильному середовищі Python, що спричиняло помилки й повторні спроби.

Висновок

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

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

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

* За офіційно заявленого рівного внеску University of Illinois Urbana-Champaign, Northeastern University, University of California (Los Angeles) та незалежного дослідника.

* Наскільки я можу судити, у статті не зазначено, яку саме модель використовували.

^†Це стосується цієї статті, а не самої праці, яка довша, ніж я зазвичай дозволяю собі висвітлювати, і містить більше тестів та глибший аналіз, ніж ми можемо охопити тут. Щоб дізнатися більше, зверніться до вихідного PDF-файлу, посилання на який наведено вище.

Уперше опубліковано в п’ятницю, 6 листопада 2026 року