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-кластерам. Сам по себе большой объем данных здесь ни на что не влияет — имеют значение масштаб 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 split вместо тренировки на всех данных сразу.

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