Постійні ШІ-агенти на практиці: витрати, дрейф пам’яті та проблема 80%.

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

Чому люди відмовилися від запитів

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

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

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

Рахунок

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

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

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

Рішення, яке виявилося ефективним на практиці, складається з трьох частин:

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

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

Перший pull request — це трюк

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

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

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

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

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

Пам’ять існує у двох формах

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

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

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

Саме тоді вина зміщується з моделі. Проблемою була не сама модель, а пам’ять проекту – та частина, яка зберігається на диску та існує довше за будь-яку сесію, яка так і не була створена.

Змінилися обов’язки розробника

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

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

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

Під усім цим криється стриманий „удар“. Одне дослідження вимірювало швидкість роботи розробників у реальних кодових базах та виявило, що вони працюють приблизно на 19% повільніше, хоча вважали, що працюють на 20% швидше. Відчуття швидкості та реальна швидкість вже не збігалися. Постійні агенти розширюють цю прогалину, коли їм це дозволяється, адже вони чудово вміють створювати враження швидкості. Те, що її зменшує, — це нудне, але необхідне: керування, перевірка, специфікація, що відповідає реальності, та обмеження витрат.

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