7 помилок, що ламають ШІ-агентів
Ваш ШІ-агент чудово працює під час тестування. Він швидкий і точний. Але коли ви розгортаєте його, усе ламається. Користувачі повідомляють про таймаути та помилки.
Створення стійких ШІ-агентів потребує більшого, ніж просто хороший код. Ви повинні вміти справлятися з хаотичною реальністю експлуатації (production).
Щоб будувати кращі системи, уникайте цих семи помилок:
- Ігнорування збоїв зовнішніх API Мережеві запити завершуються помилкою через таймаути або обмеження частоти запитів (rate limits).
- Огортайте всі виклики в блоки try-catch.
- Встановлюйте конкретні значення таймаутів.
- Використовуйте логіку повторних спроб з експоненціальною затримкою (exponential backoff).
- Використовуйте патерн circuit breaker для сервісів, що дають збої.
- Сприйняття збоїв як бінарних Багато розробників вважають, що система або працює, або ні. Насправді ж частини системи часто виходять з ладу, тоді як інші залишаються активними.
- Створюйте багаторівневі стратегії відкату (fallback strategies).
- Визначте, як система має працювати з обмеженим функціоналом.
- Повідомляйте користувачів, коли система перебуває у деградованому стані.
- Мінімальне логування Ви не зможете виправити те, чого не бачите.
- Логуйте на різних рівнях: DEBUG, INFO, WARNING та ERROR.
- Використовуйте ID запитів (request IDs) для відстеження шляху користувача.
- Відстежуйте рівень помилок та час відповіді.
- Налаштуйте сповіщення про аномалії в системі.
- Тестування лише «щасливих шляхів» (happy paths) Якщо ви тестуєте лише успішні сценарії, ваш агент не витримає навантаження.
- Використовуйте хаос-інжиніринг (chaos engineering) для тестування збоїв.
- Навмисно спричиняйте збої в залежностях під час тестів.
- Симулюйте затримки мережі та повільну роботу сервісів.
- Тестуйте з некоректними (malformed) даними.
- Втрата стану агента Збої не повинні призводити до втрати всього прогресу.
- Зберігайте стан на ключових етапах.
- Використовуйте ідемпотентні операції.
- Зберігайте достатньо контексту, щоб відновити перервану роботу.
- Хардкодинг конфігурацій Зміна таймаутів або кінцевих точок API не повинна потребувати повторного розгортання.
- Використовуйте змінні оточення для всіх налаштувань.
- Зробіть пороги (thresholds) такими, що можна налаштувати без зміни коду.
- Використовуйте feature flags для впровадження нової поведінки.
- Універсальна обробка помилок Помилка валідації потребує іншого підходу, ніж таймаут мережі.
- Відокремлюйте помилки, які можна повторити, від постійних помилок.
- Повторюйте спроби при тимчасових проблемах, таких як обмеження частоти запитів (rate limits).
- Не намагайтеся повторити операцію при постійних проблемах, таких як помилки автентифікації.
Стійкість полягає у передбаченні реальності. Почніть із аудиту ваших поточних агентів на відповідність цим підводним каменям.
Optional learning community: https://t.me/GyaanSetuAi