П’ять рівнів проектів з інженерії ШІ, від чат-ботів до агентів, здатних до самовдосконалення.

Керівники з підбору персоналу на посади в галузі інженерії ШІ постійно бачать один і той самий портфоліо: чат-бот із зручним інтерфейсом. Різниця між цим та тим, що насправді створюють команди, які розробляють продукти на кшталт Claude Code та Codex, є величезною, проте шлях від одного до іншого складається з досить чіткої послідовності з п’яти рівнів. Знання того, на якому рівні знаходиться проект, допомагає визначити, що потрібно створювати далі, а багато хто застрягає, тому що продовжує розробляти нові проекти для першого рівня.

Рівень 1: модель за простим інтерфейсом

У основній частині проект викликає API мовної моделі (зазвичай OpenAI або Anthropic) та створює щось просте над нею, наприклад додаток Streamlit. Уявіть собі чат-бота, який відповідає на запитання клієнтів, або невелику функцію, яка узагальнює статті. Існує також техніка формулювання запитів, хоча ці запити зазвичай не відстежуються та не тестуються. Може бути структурований вихідний результат, кілька тестів для перевірки правильності обробки даних та певна логіка резервного варіанту на випадок несправності моделі.

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

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

Рівень 2: пошук та оцінка

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

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

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

Потім виникає наступна проблема: змусити ШІ щось зробити з цією інформацією.

Рівень 3: агенти

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

Це, мабуть, найцікавіша, але водночас одна з найризикованіших частин сучасної інженерії ШІ. Кожна функція, яку ви передаєте, створює ще одну можливість для помилок. На рівні 2 оцінювання полягало у присвоєнні балів одній відповіді. Тепер же потрібно оцінювати цілу послідовність рішень, і одна помилка на будь-якому етапі може зіпсувати все, що буде далі. Наслідки також реальні, коли агент має доступ до вашої кредитної картки, коду чи електронної пошти, тож ризик за своєю природою є вищим.

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

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

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

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

Рівень 4: системи корпоративного масштабу

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

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

Огляд кодової бази Claude Code показав, що сама ШІ є лише незначною її частиною. Майже все інше — це інфраструктурні елементи, які забезпечують надійність продукту.

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

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

Рівень 5: спеціалісти, які будують систему

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

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

Два показники даних показують, де це відбувається. У одному проекті Андрея Карпаті один агент самостійно протягом двох днів провів близько 700 експериментів та знайшов двадцять способів прискорити навчання моделі. Компанія Anthropic зазначила, що більшість коду, який інтегрується в їхню базу коду, тепер пише Claude.

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

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

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

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

Більшості людей не потрібний рівень 5. Багато завдань у сфері штучного інтелекту на практиці вимагають рівня 2 або 3, і іноді достатньо добре сформульованого запиту та простої оцінки, щоб створити щось корисне. Інженерів наймають для того, щоб вони були корисними, а не елегантними.