Роль інженерів у штучному інтелекті за останні два роки змінилася радикальніше, ніж за попереднє десятиліття. Про це відверто говорить Чіп Хюєн — інженерка, підприємниця та авторка бестселерів “Designing Machine Learning Systems” і “AI Engineering”, яка очолює рейтинги O’Reilly. У розмові з ведучим подкасту Super Data Science Джоном Кроном вона пояснює, чому класичний ML engineering більше не є центром всесвіту, як народився окремий напрям AI engineering і чому системний дизайн раптом став головною навичкою для тих, хто хоче лишатися потрібним.
Від моделей з нуля до «модель як сервіс»
Класичний образ machine learning engineer формується довкола однієї задачі: збудувати модель. Це означало повний цикл — від сирих даних до продакшн‑сервісу.
У минулому, описує Хюєн, робота машин‑лернінг інженера була «більше про побудову моделі з нуля»: треба було зібрати власні дані, натренувати модель і лише потім задеплойити її як частину більшого продукту. Йдеться про рекомендаційні системи, детектори шахрайства чи класифікатори, де все — від фіч до моделі — збиралося інхаус.
З появою генеративних foundation‑моделей цей ландшафт змінився. Тепер, каже вона, «з генеративним AI ви можете просто почати з демо»: отримати доступ до «найдивовижнішої AI‑моделі», яка вже працює в чиємусь хмарному середовищі, і використати її як одну з фіч вашого продукту. Час від ідеї до першої робочої версії стискається до дня чи навіть годин.
Це й є ключова відмінність AI engineering: для «багатьох людей AI зараз — це переважно сервіс, модель як сервіс», і зробити це правильно — «цілком нова техніка». Йдеться не про тренування ядра моделі, а про інтеграцію, оркестрацію, керування контекстом, пам’яттю, витратами, ризиками й усім тим, що відбувається навколо API‑виклику до великої моделі.
Не «AI vs ML», а «яку проблему ви розв’язуєте»
Попри популярне протиставлення «AI engineer проти ML engineer», Хюєн наполягає: це хибна дихотомія. Вона прямо формулює: це «не про те, що я хочу стати AI‑інженером чи машин‑лернінг інженером», а про те, «які проблеми ви намагаєтеся розв’язати і який найкращий спосіб це зробити».
На практиці розв’язки все рідше вписуються в одну категорію. «Дуже часто рішення включатиме і класичний machine learning, і генеративну AI‑модель», наголошує вона. Сучасні системи — це конструктори з багатьох компонентів, де:
- класичні моделі виконують чіткі, вузькі задачі (класифікація, маршрутизація, фільтрація),
- великі генеративні моделі забезпечують гнучкішу поведінку: відповіді у вільній формі, планування, багатокрокове мислення.
Хюєн наводить типовий приклад: клієнтський чат‑бот. Генеративна модель — не єдине, що там працює, і далеко не завжди перше, до чого варто звертатися. Є крок перед нею: перевірити, чи запит взагалі релевантний продукту, чи не варто його відфільтрувати, чи достатньо віддати статичну сторінку з FAQ.
Це вже зона класичного ML: простий класифікатор або роутер, який вирішує, куди спрямувати запит. «Такий класифікатор — це класичний machine learning, і ви, можливо, захочете будувати його всередині компанії», зазначає вона. А ось складні, дороге за токенами резонування довірити вже великій моделі, яку ви викликаєте як сервіс.
У підсумку роль інженера зміщується з «обрати стека» до «скласти правильну комбінацію» під конкретну бізнес‑проблему.
Як виглядає сучасна AI‑система: багато компонентів, одна відповідальність
Хюєн акцентує: «ви можете мати систему, що поєднує дуже багато різних компонентів», і справа інженера — розуміти весь простір можливих рішень.
На прикладі того ж саппорт‑бота видно типовий шаблон AI‑engineering сьогодні:
Спершу запит проходить крізь фільтр — класифікатор визначає, чи стосується він вашого продукту і чи не зачіпає заборонених тематик. Це дешевий традиційний ML, який може працювати швидко і без участі великих моделей.
Далі, для частини запитів достатньо взагалі не звертатися до LLM: якщо йдеться про «як змінити пароль», можна просто повернути посилання на релевантний розділ FAQ. Для цього знову можна застосувати окремий класифікатор, який мапить запит до бази знань.
Лише запити, які справді потребують гнучкого, контекстно‑залежного міркування, йдуть до великої моделі. І вже навколо неї з’являються інші AI engineering‑теми: промпти, контекст, пам’ять, guardrails.
Хюєн наголошує, що вона «витрачає багато часу, думаючи про дизайн систем пам’яті»: як змусити модель «і зберігати інформацію, і ефективно отримувати до неї доступ з часом». У її баченні контекстні вікна та пам’ять — це різні прояви однієї задачі: керування інформацією в динамічній системі, де користувачі повертаються, накопичують історію, змінюють свої потреби.
Тут і проявляється розрив між ML та AI engineering: перший сфокусований на якості окремої моделі, другий — на тому, як модель вбудована в потік подій, даних і рішень.
Інженер — це не «той, хто пише код»
Окрема лінія, яку послідовно проводить Хюєн: уявлення про інженера як фабрику рядків коду застаріло. «Інженерна робота — це не тільки про написання коду», каже вона. Набагато суттєвіше «думати про проблеми й про те, як знайти рішення, які мають сенс у довгостроковій перспективі».
Її шлях до системного мислення почався задовго до хайпу навколо ChatGPT. Ще у 2018–2019 роках, коли вона викладала курс по TensorFlow, швидкий прогрес фреймворків став для неї болісним досвідом: виходила нова версія, і «доводилося переробляти 80% туторіалів». Це підштовхнуло її до питання: які знання швидко старіють, а які — стійкіші?
Після розмов з колегами й практиків вона «приземлилася» на системному мисленні та дизайні систем. Саме це лягло в основу її конспектів з design of machine learning systems, які перетворилися на популярний GitHub‑репозиторій, потім — на курс у Стенфорді, а далі — на книгу.
Сприйняття аудиторії спочатку було настороженим: технічна книга без кодових сніпетів здавалась нетиповою. Але час зіграв на користь: зі зростанням складності реальних продакшн‑систем стало очевидно, що «інженерна робота — це про системи, а не про синтаксис».
Тепер, коли AI‑інструменти автоматизують дедалі більше вузьких навичок, цей зсув лише посилився. Хюєн формулює це просто: чим вужча навичка, тим легше її автоматизувати. А от здатність мислити системно, бачити, як частини впливають одна на одну у часі, — стає новим дефіцитним ресурсом.
Системний дизайн в епоху foundation‑моделей
«Системне мислення або системний дизайн завжди були для мене дуже‑дуже крутими», зізнається Хюєн. Але тепер, коли AI «автоматизує багато навичок», це, на її думку, «стає ще важливішим — думати про речі як про систему».
Це не абстрактна порада, а практична відповідь на нову реальність:
-
Моделі швидко змінюються. Багато компаній, з якими вона спілкується, живуть у ритмі «два‑три місяці» — саме стільки триває цикл від появи моделі нового покоління до її відчутного впливу на продукти. Техніки, що латали слабкості попередніх версій, раптом перестають бути актуальними.
-
Fine‑tuning — не панацея. Попри те, що вона визнає: іноді fine‑tuning «необхідний», Хюєн скептична до рефлексу «дрібна проблема — значить, перетренуємо модель». Вона наголошує: сам процес донавчання став простішим завдяки готовим фреймворкам, але справжня складність починається потім — при деплої, сервінгу, оптимізації інференсу, відстеженні, як fine‑tuned версія тримається на фоні все кращих базових моделей.
-
Вартість зрушується з «створення коду» на «експлуатацію системи». Коли час і гроші на написання прототипу прагнуть до нуля, справжня робота починається з питання: як система поводитиметься в реальному світі? Як вона змінюватиметься разом із моделями, продуктом, бізнесом?
Усі ці фактори роблять системний дизайн центральною компетенцією AI‑інженера. Не лише розуміти, як працює LLM, а й проєктувати, як вона:
- взаємодіє з класичними моделями,
- споживає зовнішні сервіси (від веб‑пошуку до внутрішніх API),
- використовує пам’ять, кеші, бази знань,
- вписується у вже наявну інфраструктуру компанії.
Де тепер «справжня робота» інженера
На тлі автоматизації коду та публічних API до потужних моделей неминуче постає питання: що ж лишається людям? Відповідь Хюєн виявляється менш драматичною, ніж песимістичні прогнози, але значно більш вимогливою до мислення.
«Багато в чому AI тепер — це сервіс», каже вона. Коли ядро складності «знято» й винесено в хмару, відповідальність зсувається з побудови моделі на:
- вибір правильної комбінації компонентів під конкретну задачу,
- розуміння компромісів між якістю, ціною, швидкістю та ризиком,
- проєктування систем, які не руйнуються при наступному стрибку якості foundation‑моделей,
- формулювання завдань і контексту так, щоб моделі справді робили те, що потрібно бізнесу.
У цій картині ML engineering не зникає — він стає частиною більшого полотна. Дешеві, сфокусовані моделі продовжують відігравати важливу роль, але як елементи системи, а не самоціль. А AI engineering стає дисципліною про зв’язки: між моделями, сервісами, даними, користувачами та часом.
Тож для інженерів питання звучить не «ким бути — ML чи AI інженером», а «чи вмію я мислити системами, а не лише функціями». Саме тут, у дизайні складних, гібридних AI‑систем і в розумінні реальних проблем, які вони мають вирішувати, і лежить та «справжня робота», яка ще довго не стане безкоштовною.
Джерело
YouTube: What’s Left to Build When Software Is Free (with Chip Huyen)