ML Engineer vs AI Engineer: кого наймати для AI-проєкту?

Типова історія у стартапах зараз: запит на найм формулюють через рішення («нам потрібен AI»), а не через задачу. Тому й не можуть визначити, це інтеграція чи тренування моделі, і хто саме потрібен компанії: ML Engineer vs AI Engineer.

«Зараз ситуація схожа на початок 2000-х: тоді бізнес без представництва в інтернеті ризикував відстати. Тепер так само — компанія, що не інтегрує AI, ризикує залишитися позаду», — каже Микола Клєстов, CTO ITExpert. Ринок захопила хвиля вакансій із неоднозначними назвами, і компанії масово плутають, кого наймати.

У цьому матеріалі — практичний розбір, який ґрунтується на досвіді закриття таких вакансій:

• різниця між ML та AI інженером
• чим займається ML Engineer
• чим займається AI Engineer
• яким компаніям підходить кожна з ролей
• чек-лист з критеріями вибору ML Engineer та AI Engineer
• як перевірити кандидатів на співбесіді.

ML Engineer vs AI Engineer: у чому різниця?

До буму ChatGPT розмежування було простим:

• Якщо компанії потрібно було розробити щось з нуля, провести дослідницьку роботу (R&D), наймали Data Scientist.

• Якщо потрібно було впровадити вже відомі data science-інструменти в продукт, потрібно було найняти ML Engineer.

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

Причина проста: великі мовні моделі від OpenAI, Anthropic, Google стандартизовані й мають зрозумілі способи інтеграції. Це публічне API — за аналогією з Google Maps, які можна просто додати на сайт і використовувати. 

Для роботи з ним не потрібно глибоко розумітися на тому, як влаштований штучний інтелект всередині — так само, як не треба розумітися на картографії, щоб підключити Google-карти. Саме тому для більшості таких задач замість ML Engineer чи Data Scientist потрібна нова роль — AI Engineer, людина, яка вміє швидко й якісно «підключити карти», а не будувати їх з нуля.

Класичний ML Engineer: фреймворки, бібліотеки, тренування з нуля

Класичний профіль ML Engineer сформувався навколо конкретного набору data science-інструментів: фреймворків на кшталт TensorFlow і Keras, бібліотек компʼютерного зору (OpenCV), бібліотек для обробки тексту (BERT).

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

Важливо: мова не про те, що класичний ML Engineer застарів. Задачі, де потрібна модель, натренована саме на даних клієнта — скоринг, прогнозування, рекомендаційні системи, специфічний computer vision — нікуди не поділись, там класична експертиза досі критична.

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

Новий профіль: AI-інтегратор (той, кого зараз називають «AI Engineer»)

Задача такого спеціаліста найчастіше зводиться не до тренування моделі, а до того, щоб додати у вже наявні IT-системи компанії інтеграцію з публічними API постачальників LLM-моделей. 

Найкращий кандидат на цю роль — досвідчений Python-розробник (більшість готових інструментів написані саме на Python), який останні роки безпосередньо займається інтеграцією AI-рішень.

Щоб найняти AI Engineer та відрізнити такого кандидата від людини, яка просто «щось чула про AI», у ITExpert звертають увагу на три конкретні маркери в досвіді:

• Векторні бази даних — місце, де зберігаються тексти й документи компанії для пошуку від імені AI-інструменту, і повʼязаний з цим термін RAG (Retrieval Augmented Generation).

• MCP (Model Context Protocol) — якщо у векторної бази роль «памʼяті» агента, то MCP — це «руки»: можливість підключити функції з CRM, ERP, ecommerce платформи компанії, щоб AI-агент міг, наприклад, сам додати товар у кошик, обрати колір та кількість і завершити покупку.

• Сімейство фреймворків LangChain, LangGraph, LangSmith — готові інструменти для найшвидших і найпростіших інтеграцій LLM у продукт.

*На глобальному ринку термін «AI Engineer» іноді означає ширшу роль — наприклад, у визначенні дослідниці Chip Huyen (авторки книги AI Engineering) вона охоплює не лише інтеграцію готових API, а й повноцінне створення застосунків на основі базових моделей через промпти та guardrails (набір механізмів контролю, які обмежують поведінку моделі: що вона може відповідати, робити чи генерувати, а що — ні), оцінку якості та оркестрацію агентів як окремі напрями роботи.

Яким компаніям потрібен ML Engineer, а яким — AI Engineer?

Потреба в ML Engineer чи AI Engineer залежить не від розміру компанії чи трендовості технології, а від того, яку задачу ви розвʼязуєте: будуєте власну модель з нуля для власних даних чи інтегруєте готові AI-інструменти в продукт. Нижче розберемо, які типи компаній і завдань тяжіють до кожної з ролей.

Стартап з ідеєю на 6 місяців → AI-інтегратор

Якщо стартап не позиціонує себе як розробник принципово нової технології — наприклад, власної LLM — спеціаліст, що глибоко розуміється на внутрішній будові LLM, тут не потрібен. Такий шлях обрав, наприклад, китайський DeepSeek, який представив власну модель. Але більшість стартапів ідуть іншим шляхом: вони інтегрують AI-технологію в уже готову ідею, яка раніше не була повʼязана з AI. 

Знадобиться саме AI-інтегратор, який працює з фреймворками на зразок LangChain і за кілька тижнів зробить прототип чи MVP. Такі фреймворки підходять для простих прототипів і демонстрацій того, як працює технологія — і саме їх наявність вказує на те, чи кандидат підходить стартапу.

Компанія хоче власну Language Model → класичний ML Engineer

Якщо мета — створити, наприклад, власну small language model (SLM), потрібен класичний ML-спеціаліст. Такий фахівець, як правило, починав з різновидів word2vec-подібних бібліотек, що перетворюють текст у векторизований вигляд, тож добре розуміється на векторних просторах слів і на тому, як влаштовані мовні моделі. У його досвіді мають фігурувати терміни на кшталт «дистиляції моделі» та «донавчання (fine-tuning) під локальні дані».

Важливо: «донавчити» закриту модель на кшталт ChatGPT не вийде. Для цього використовують open-source моделі — наприклад, Llama, на базі якої створюють і українські small language models, зокрема Mamay. Досвід із такими моделями в резюме може свідчити, що фахівець не лише підключав готові API, а й адаптував моделі під конкретні завдання.

Enterprise з великими даними → залежить від обсягу й конфіденційності та даних

Здавалося б, що більше даних у компанії, то очевидніша потреба в ML Engineer, який зможе натренувати модель на цих даних. Розберімося, чи це справді так.

Більшості компаній даних для повного тренування LLM просто не вистачить. Це, до речі, ключова причина, чому в Україні складнощі зі створенням повноцінної національної LLM: оцифрованих україномовних текстових корпусів недостатньо, тож вони міксуються з англомовними даними.

Якщо в компанії є конфіденційні дані, які не можна передавати у зовнішні API (типовий приклад — банк), рішенням найчастіше є саме RAG-підхід: комбінація локального пошуку по векторній базі даних з уже готовою LLM. Це працює найкраще навіть для бізнесу з чутливими даними — компанія розгортає локальну open-source LLM і «підмішує» до неї знання з локального сховища.

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

До цього додається ще один нюанс: якщо бізнес з міркувань безпеки не може використовувати публічні API й повинен розгортати LLM локально, зʼявляється потреба в окремій інфраструктурній ролі — адміністратора дата-центру для мовних моделей. Причина у тому, що такі системи будуються на відеокартах, а не на звичайних серверах. Тобто на масштабі enterprise команда нерідко складається не з двох, а з трьох ролей одночасно: AI-інтегратора, ML Engineer’а й інфраструктурного спеціаліста з GPU-кластерів.

Тобто на масштабі enterprise команда нерідко складається не з двох, а трьох ролей одночасно: AI-інтегратора, ML Engineerʼа й інфраструктурного спеціаліста з GPU-кластерів. Сам по собі великий обсяг даних тут ні на що не впливає — вирішує масштаб RAG-системи та вимоги до конфіденційності.

Критерії вибору ML Engineer vs AI Engineer: короткий чек-лист

Перш ніж створювати текст вакансії, варто відповісти на три запитання:

#1. Чи ви плануєте створювати щось принципово нове — мова про власну модель, кастомізацію, чи інтеграцію готової моделі (наприклад, GPT, Claude або Gemini) у свій продукт?

#2. Чи є у вас дані, які за обсягом і конфіденційністю вимагають локального розгортання й побудови складної RAG-системи, а не прямого виклику публічного API? 

#3. Який масштаб завдання — простий прототип за кілька тижнів чи інфраструктура enterprise-рівня з терабайтами даних?

Якщо ваш продукт вже передбачає власні предиктивні моделі чи розробку рішення з нуля — потрібно пірнути у те, як найняти Data Scientist (Machine Learning) та чим ця роль відрізняється від обох інженерних профілів, описаних вище.

Якщо ж самостійно визначити правильний профіль складно — це нормально: ринок настільки молодий, що навіть досвідчені CEO та рекрутинг-команди нерідко плутають ці ролі. У таких випадках є сенс звернутися до компанії, що спеціалізується на рекрутингу спеціалістів у сфері AI/ML. Профільний рекрутер за 15–20 хвилин розмови визначить, який профіль — ML/AI інженер — закриє вашу бізнес-задачу.

Як перевірити кандидата на співбесіді

Вже є очевидні маркери, щоб розпізнати ці профілі:

• AI-інтегратор згадає RAG і MCP,
• класичний ML Engineer — fine-tuning і model distillation*.

*Це техніка стиснення моделі, коли велика «модель-вчитель» (teacher) використовується для тренування меншої «моделі-студента» (student), яка навчається імітувати поведінку вчителя, а не тренується з нуля на сирих даних. 

Далі — методи оцінки кандидатів ускладнюються. Тож ми розділяємо аналіз на три рівні: запитання-фільтр (відсіює за дві хвилини), запитання на глибину (показує рівень фахівця) і практичне завдання (найнадійніший спосіб, але потребує більше часу).

Перевірка AI-інтегратора (AI Engineer)

Рівень 1 — запитання-фільтр

«Опишіть, як ви будували RAG для конкретного проєкту: звідки брали дані, яку векторну базу обрали та чому саме її?»

Воно відразу розділяє кандидатів на дві групи. Перша — ті, хто справді робив RAG у продакшені: вони називають конкретну базу (Pinecone, Weaviate, Chroma, pgvector, Qdrant) і пояснюють вибір через обмеження — бюджет, потребу в self-hosting через конфіденційність даних, швидкість пошуку на конкретному обсязі документів. 

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

🚩 Тривожний сигнал: кандидат не може назвати, яку модель ембедингів використовував (OpenAI text-embedding-3, sentence-transformers, Cohere) — це означає, що RAG для нього був чорною скринькою на рівні «скопіював код з прикладу».

Рівень 2 — запитання на глибину

«Уявіть: RAG повертає нерелевантні шматки тексту, хоча правильна інформація точно є в базі знань. Які причини ви перевіряли б першою чергою?»

Відрізняє людину, яка справді дебажила RAG у продакшені, від тієї, хто лише запускала його на тестових даних. Хороша відповідь охоплює кілька рівнів: 

• розмір і стратегію чанкінгу (можливо, шматки тексту занадто великі або розбиті посеред речення)
• якість ембедингів для конкретної мови чи домену (наприклад, українська юридична термінологія погано векторизується загальними моделями)
• метрику схожості (cosine vs dot product),
• чи взагалі перевіряв кандидат relevance через reranking або лише покладався на топ-k результатів з векторного пошуку без додаткової фільтрації.

«Що станеться, якщо агент отримає помилку, тайм-аут або неповні дані від MCP-інструменту. Як ви це обробляєте на рівні архітектури?»

Кандидат із досвідом згадає retry-логіку з експоненційним бекофом, fallback-сценарії (наприклад, деградація до відповіді без інструменту з попередженням користувачу), і головне — валідацію відповіді моделі перед тим, як віддати результат далі: чи модель не галюцинує виклик уявного інструменту, чи правильно парсить JSON-схему.

«Порівняйте LangChain/LangGraph і прямий виклик API моделі без фреймворка — коли б ви обрали кожен підхід і чому?»

Гарна відповідь визнає компроміс в обидва боки: фреймворк пришвидшує розробку MVP і дає готові патерни для складних agentic-флоу (LangGraph особливо корисний для стейт-машин з кількома кроками), але додає абстракцію, ускладнює дебаг і робить проєкт залежним від чужих оновлень API. Досвідчений інтегратор скаже, що для простого чат-бота писав би напряму через SDK Anthropic чи OpenAI, а фреймворк брав би тільки коли складність оркестрації виправдовує накладні витрати.

Рівень 3 — практичне завдання (15–20 хвилин)

Дайте кандидату спрощений опис задачі: «У нас є база з 5 тис. документів служби підтримки. Потрібно, щоб AI-агент відповідав клієнтам і за потреби створював тікет у зовнішній системі. Намалюйте архітектуру в Miro за 10 хвилин».

На що дивитися:

• Чи розділяє кандидат векторну базу для пошуку по документах і MCP або function calling для створення тікета? Адже це базове розуміння RAG vs agentic-підходу.
• Чи згадує guardrails — що станеться, якщо агент спробує створити тікет із неповними даними, чи є human-in-the-loop для критичних дій.
• Чи закладає моніторинг і логування — досвідчені інтегратори завжди думають про те, як дебажити систему після запуску, а не лише про те, як вона працює в ідеальному сценарії.

🚩 Порожня схема з одним блоком «LLM API» без деталей навколо — сигнал, що людина ніколи не проєктувала таку систему сама, лише виконувала готові інструкції.

Перевірка класичного ML Engineer

Рівень 1 — запитання-фільтр

«Розкажіть про випадок, коли ви робили fine-tuning open-source моделі. Які дані використовували та як оцінювали результат?»

Ключове тут — не сам факт згадки fine-tuning, а деталі: розмір і джерело датасету, чи проводилась очистка даних, які метрики оцінки застосовувалися (perplexity, BLEU/ROUGE для генерації тексту, F1 для класифікації, або людська оцінка через A/B). 

🚩 Тривожний сигнал: кандидат каже «донавчили модель на наших даних, стало краще» і не може конкретизувати, що саме означає «краще».

Рівень 2 — запитання на глибину

«Чим відрізняється дистиляція моделі від quantization, і коли ви застосовували кожен з підходів?»

Це запитання без правильної відповіді за шаблоном, тому його важко підготувати заздалегідь. Технічно грамотна відповідь: дистиляція — це тренування меншої моделі-студента імітувати поведінку більшої моделі-вчителя (зменшує розмір, але вимагає повторного тренування), а quantization — це зниження точності ваг моделі (наприклад, з FP32 до INT8) без зміни архітектури, що швидше й дешевше, але з ризиком втрати якості на складних задачах. 

Кандидат, який справді цим займався, розповість про конкретний trade-off у своєму проєкті — наприклад, «quantization ми обрали, бо не було ресурсу на повторне тренування, а latency треба було знизити для мобільного застосунку».

«Які метрики ви використовували, щоб довести бізнесу, що кастомна модель краща за просто виклик GPT з хорошим промптом?»

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

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

«Які data leakage ви вловлювали під час тренування моделей і як їх виявили?»

Data leakage — специфічна проблема, яку розпізнають лише ті, хто справді проходив весь цикл валідації моделі. Хороша відповідь містить конкретний приклад — наприклад, часова ознака потрапила і в тренувальну, і в тестову вибірку, або дублікати записів розділилися між train/test split. Відсутність жодного прикладу з роботи — сигнал, що кандидат ніколи не доводив модель до продакшн-якості, де такі помилки завжди спливають на етапі валідації.

Рівень 3 — практичне завдання (20–30 хвилин)

Якщо є технічний ресурс у команді — дайте невеликий датасет (наприклад, кілька тисяч рядків тексту) і попросіть кандидата за 30 хвилин показати, як би він підійшов до fine-tuning невеликої open-source моделі під конкретну задачу класифікації чи генерації. Не очікуйте робочого коду за такий час — дивіться на процес: чи кандидат спершу проаналізує розподіл даних, чи відразу почне писати тренувальний цикл; чи згадає про baseline-модель для порівняння; чи запланує cross validation або хоча б train/val/test спліт замість тренування на всіх даних відразу.

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