Дев’ять інженерних звичок для створення вашого першого AI-агента.
Дев’ять звичок, які допомагають агентам уникнути невдач під час роботи: спочатку оцінка, бюджет контексту, обмеження автономії, відстеження, версіонування запитів, оцінка витрат та сортування невдач.
Джерела: *9 AI Engineering Rules I Wish I Knew Before Shipping My First Agent*
У колах, що займаються агентами та інженерією, поширюється історія про рахунок у розмірі 47 000 доларів. Її розповідають без деталей, тож сприймайте її як ілюстрацію, а не як перевірений випадок. Агент ідеально функціонував під час кожної демонстрації. Однак потім його застосували у реальному робочому процесі клієнта, і він потрапив у цикл повернення грошей, постійно виконуючи однакові дії протягом шести годин без жодного спостерігача. Модель не була надто примітивною. Люди, які створили систему, проігнорували все, що допомагає моделі зрозуміти, коли припинити роботу.
Це неприємна правда про роботу з інженерії в системах штучного інтелекту. Ви можете добре знати Python, RAG, агентів, векторні бази даних, техніки формулювання запитів та кожну нову версію моделей, але все одно залишатися неготовими до використання в продакшені. Навички, які допомагають у разі збоїв під час демонстрації, рідко трапляються в навчальних матеріалах. Вони нудні та легко ігноруються, проте саме вони відрізняють систему, що має гарний вигляд, від системи, якій можна довіряти. Ось дев’ять корисних звичок, які варто розвинути перед тим, як запустити щось автономне.
Чому більше знань не робить вас старшим спеціалістом
Кілька цифр показують, наскільки часто проекти застрягають між демонстрацією та запуском. Це дані з других джерел, а методи можуть відрізнятися, тому сприймайте їх як приблизну картину:
- Прогноз Gartner з середини 2025 року, згідно з яким понад 40% проектів з агентним штучним інтелектом будуть скасовані до кінця 2027 року через зростання витрат, нечітку користь та слабкі механізми контролю ризиків.
Жодна модель раптово не погіршується на 40% у здатності до міркувань. Щось ламається між демонстрацією та запуском. Прийнята тут теорія полягає у тому, що проблеми під час виробництва часто спричиняються або посилюються системою, яка оточує модель, а не лише її вихідними даними: відсутність захисних механізмів, погані дані, слабка перевірка, обмежена можливість спостереження та неконтрольовані витрати.
Показник бенчмарку вказує на те саме, але не доводить причину. У проекті tau-bench, який тестує агентів, що використовують інструменти для завдань на кшталт бронювання рейсів та вирішення запитів підтримки, у одному зустрічному огляді йшлося про те, що навіть найкращі моделі виконали менше половини завдань, а при повторенні завдання стабільність знизилася приблизно до чверті. Це вимірює здатність, але не діагностує нічого. Це свідчить про те, що агенти ненадійні, але не пояснює чому.
Запам’ятайте одне відмінність, адже воно пронизує всі наведені нижче звички: цикл вище не був неправильною відповіддю. Ніщо його не зупинило. Розбіжність між результатом моделі та тим, що система дозволяє зробити з цим результатом, — ось де полягає суть більшості цих звичок.
1. Спочатку напишіть механізм оцінки, потім функціонал
Початківці пишуть запит, пробують його кілька разів, оцінюють отриманий результат та випускають продукт. Більш досвідчені інженери спочатку записують, що означає „правильний“ результат у вигляді набору тест-кейсів, а лише потім приступають до реалізації функціоналу.
Оцінка може бути простою: зберіть від 20 до 30 реальних прикладів з фактичного використання, кожен з яких має очікуваний результат, та щоразу, коли щось змінюється, протестуйте ваш запит на всіх них. Якщо ви не можете визначити, чи допомогла зміна, не дивлячись на результати та не припускаючи, у вас є лише припущення, а не справжня оцінка. Ця звичка — найшвидший спосіб уникнути випуску продукту з проблемами, які неможливо побачити.
2. Ставіться до контексту, як до грошей
Звичка початківців — заповнювати вікно всім: усім документом, усією розмовою, п’ятьма прикладами „на всякий випадок“. Здається, що більше контексту — це безпечніше, але зазвичай це не так. Кожен додатковий елемент конкурує за увагу моделі та дає їй ще одну неправильну деталь, на якій варто зосередитися. Сприймайте вікно як бюджет:
- Обмежіть кількість отриманих документів лише релевантними частинами.
- Узагальнюйте старі етапи розмови та не відтворюйте їх повністю.
- Видаліть приклади, які не приносять користі.
Якщо ви не знаєте, що саме заповнює вікно, роздрукуйте весь запит, який надсилаєте, та прочитайте його. Багато хто дивується, скільки там зайвого матеріалу.
3. Обмежте автономію перед запуском
Це саме та звичка, яка могла б припинити цикл повернень грошей. Один аналіз помилок дорогих агентів, проведений групою під назвою Operator Collective, розділив ці випадки на п’ять категорій: відсутність обмежень на автономні дії, застарілі чи некоректні дані, довіра до результатів без їх перевірки, безпека як післядумка та помилки, яких ніхто не помітив, оскільки ніхто за ними не стежив. Жодна з цих п’яти категорій не є „модель припустилась помилки“. Це лише один аналіз, а не закон природи, проте він вказує на щось реальне. Неправильний результат рідко завдає шкоди сам по собі. Шкода виникає тоді, коли ніщо далі у ланцюжку не фіксує це, не обмежує його чи не запобігає його повторенню.
Логіка розрахунків робить це непереговорним. Якщо кожен крок робочого процесу агента успішний у 95% випадків, а завдання складається з 20 кроків, то весь процес не завершується правильно у 95% випадків, оскільки ймовірності накопичуються. При 90% успішності кожного кроку ланцюжок з 20 кроків успішний лише приблизно у 12% випадків. Демонстрація, у якій три кроки виконуються без проблем, майже нічого не говорить про роботу системи у реальних умовах із двадцятьма кроками.
Перш ніж будь-яка автономна система почне працювати, встановіть для неї ліміт кроків, верхню межу витрат, таймаут та спосіб самостійного зупинення. Причина не в тому, що до моделі неможливо довіряти. Справа у тому, що ймовірність ніколи не програє.
4. Фіксуйте логи так, ніби будете відлагоджувати їх у темряві о 2 годині ночі.
Найнебезпечніша несправність не спричиняє гучних збоїв. Агент вживає неправильних дій, повідомляє про успіх, панель керування залишається у зеленому статусі, а клієнт втрачає гроші чи отримує погану пораду, перш ніж хтось це помітить.
Початківці додають функції логування після того, як щось зламується. Досвідчені інженери з самого початку створюють структуроване відстеження: кожен вхідний даний, виклик інструменту та крок посереднього міркування фіксуються з часовими позначками та є доступними для пошуку. Через три тижні ви захочете повторно переглянути саме те, що бачив та на що вирішив агент, замість того щоб складати цю інформацію з пам’яті. Якщо ваша поточна налаштованість змушує вас здогадуватися у глибокій ночі, спочатку усуньте цю прогалину.
5. Піднімайтесь сходами: формулюйте запит, отримуйте дані, а потім налаштовуйте
Коли точність не виправдовує очікувань, початківці часто одразу переходять до деталізованої налаштування, оскільки це здається „справжньою“ інженерною практикою. Це зазвичай неправильний перший крок, і відомий приклад пояснює чому. Дослідники Microsoft взяли GPT-4, додали набір технік формулювання запитів під назвою Medprompt та порівняли його з Med-PaLM 2 — медичним моделлю від Google, налаштованою на клінічні дані та працюючою з запитами, написаними експертами. За показниками MedQA деталізовано налаштований Med-PaLM 2 набрав 86,5%, тоді як GPT-4 з використанням лише технік Medprompt — 90,2%. Це означає зниження рівня помилок на 27%, а також значно меншу кількість викликів моделі порівняно з методом деталізованої налаштування.
Розумний порядок дій — від дешевих та зворотних до дорогих та повільних:
Prompting Retrieval (RAG) Fine-tuning
(cheap, fast, → (add missing → (expensive, slow,
reversible) knowledge) last resort)
Спочатку виправте запит та протестуйте його. Якщо у моделі бракує фактів, додайте механізм пошуку інформації. Налаштовуйте модель лише тоді, коли у вас є великий, чистий набір даних та певна поведінка, яку запити справді не можуть забезпечити. Більшості команд це ніколи не потрібно, оскільки попередні кроки вирішують проблему.
6. Тримайте „мозок“ окремо від „рук“
Агент для початківців часто є одним величезним запитом, який планує, приймає рішення та виконує дії миттєво. Коли він зазнає невдачі, немає нічого, що б розділяло „модель помилилась у мисленні“ від „код зробив щось не так“, тому що все це переплетене разом.
Досвідчені розробники розділяють систему на дві частини. Одна частина — модель — виступає у ролі „мозку“ та обирає наступний крок. Інша частина — простий детерміністичний код, який виконує цей крок: він викликає API, перевіряє відповідь, повторює спроби в межах встановлених обмежень та дотримується правил, передбачених третім принципом. Саме це розділення робить систему піддається дебагуванню. Ви можете одразу зрозуміти, чи модель обрала неправильну дію, чи код її виконання зіпсував правильну дію — це різні помилки, які вимагають різних способів усунення.
7. Ставтеся до запитів як до коду та версіонуйте їх
Інструкція, яка потребувала чотирьох переписувань, — це логіка продакшну. Якщо ставитися до неї як до аркуша для нотаток, ви втратите робочу версію в момент, коли хтось її „покращить“. Зберігайте інструкції в системі контролю версій, як і будь-які інші файли; перевіряйте їх за допомогою набору тестів ще до об’єднання змін, та фіксуйте короткий журнал змін про те, що змінилося та чому. Це звучить занадто просто, щоб про це згадувати, і саме тому більшість команд проходять повз це, поки проблема з інструкцією не потрапляє у продакшн, і ніхто не може сказати, що змінилося.
8. Спочатку визначте ціну функції
Ось один конкретний приклад. Агент без обмежень, який виконував одне програмне завдання, витратив від 5 до 8 доларів на комісії API, тоді як повні сеанси роботи, спроби повторного виконання та виклики інструментів коштували від 10 до 100 доларів. Цифри можуть відрізнятися залежно від моделі, завдання та способу оптимізації, але загальна тенденція залишається незмінною. Витрати, які здаються незначними за окреме завдання, стають значними при великому обсязі роботи, а проєкт-пілот, який здавався дешевим під час тестування, може стати причиною відкладення проєкту.
Початківці спочатку створюють продукт, а рахунок читають пізніше. Досвідчені інженери оцінюють витрати на кожне завдання ще до написання коду: приблизна кількість токенів, необхідних для виконання завдання, очікувана кількість викликів та щоденний обсяг роботи. Якщо ці показники виглядають неправильними для десяти користувачів, вони не стануть кращими при десяти тисячах. Витрати — це не фінансове питання, яке можна вирішувати після запуску. Це архітектурне рішення, яке ви вже прийняли, незалежно від того, чи усвідомлюєте ви це чи ні.
9. Діагностуйте, перш ніж здогадуватися
Коли щось ламається, початківець інстинктивно показує на модель, пропонує використати більш потужну версію чи складніший запит. Не робіть цього. Проблеми, згадані у огляді під третім правилом, були спричинені відсутністю захисних механізмів, некоректними даними, недостатньою перевіркою даних, слабкою безпекою чи проблемами, яких ніхто не помічав, а не помилками самої моделі. Це спостереження за певною групою випадків, і воно не гарантує того ж у вашому випадку, але це дешева перевірка перед дорожчими діями. Перш ніж торкатися запиту, запитайте себе, чи були отримані дані застарілими чи некоректними, чи провалилася виклик інструменту без жодних сигналів, та чи є обмеження щодо кількості спроб. Часто рішення криється у супутній системі, а перевірка займає п’ять хвилин порівняно з необхідністю переписувати код.
Коли можна пропустити половину цього
Жодна з дев’яти звичок не є безкоштовною. Створення інструментів оцінки займає час, механізми контролю додають код, а моделювання витрат забирає половину дня, який краще було б витратити на розробку. Якщо ви створюєте прототип протягом вихідних та єдиний користувач, пропустіть більшу частину цього процесу. Використовуйте набори інструментів оцінки, механізми контролю та версійовані інструкції тоді, коли інші люди почнуть покладатися на ваш продукт, а не раніше. Проведення експерименту в одній особи з усіма формальностями витрачає час, який краще використати на з’ясування того, що справді ефективно. Дисципліна приносить результати там, де відбувається реальний вплив: у системах, які стосуються реальних користувачів, реальних грошей чи реальних рішень.
Зміна в одному реченні
Згідно з цим описом, жодна більш розумна модель не виправила цей цикл. Те, що його виправило, — це набір письмових правил: обмеження автономії, перевірки перед кожною дією та людина, яка читає журнали. Управління, а не інтелект. Початківці намагаються подолати невдачі за допомогою кращої моделі. Досвідчені інженери створюють систему, яка безпечно зазнає невдачі, коли модель помиляється, адже рано чи пізно це трапиться.