Роль ИИ-инженер все заметнее отделяется от классического ML engineering: об этом прямо говорит специалист с семилетним опытом работы в машинном обучении и LLM. Для русскоязычного IT-рынка это важный сигнал: спрос смещается от людей, которые умеют «докрутить модель», к тем, кто способен собрать вокруг нее рабочую систему с приемлемой ценой, задержкой и качеством.
Об этом сообщает Habr / Карьера со ссылкой на колонку Антона, инженера по машинному обучению и технического лида курса «ИИ-инженер» в Яндекс Практикуме. Его главный тезис звучит без особой романтики: новая роль появилась не из-за модного нейминга, а потому, что изменился сам способ создания ценности в AI-продуктах. Если раньше типичный ML-проект строился вокруг данных, обучения модели и последующего вывода в прод, то в эпоху GPT, Llama, Qwen и других больших языковых моделей компании все чаще получают сильную модель «из коробки» через API или в собственном контуре. Проблема теперь в другом: как встроить ее в бизнес-процессы так, чтобы она приносила пользу, а не только красиво выглядела на демо.
Именно здесь, по версии автора, и начинается зона ответственности, которую все чаще закрепляют за ИИ-инженером. Речь уже не о том, чтобы в очередной раз перебрать признаки, архитектуры и гиперпараметры. На первый план выходят вопросы интеграции: как подключить LLM к внутренней базе знаний, как связать ее с CRM и корпоративными сервисами, как снизить число галлюцинаций на данных компании, как удержать стоимость запросов под контролем и как не утопить сервис в задержках. Отдельная тема — оценка качества после обновлений: если модель, RAG-цепочка или агент стали отвечать хуже, это нужно не обсуждать в чате, а ловить инженерными средствами.
В статье предлагается довольно практичное определение новой роли: ИИ-инженер проектирует, собирает и поддерживает прикладные AI-системы на базе готовых языковых моделей. Ключевое слово здесь — «система». Полезный продукт почти никогда не состоит из одной LLM. Обычно это связка из генеративной модели, RAG, векторной базы, внешних API, агентного слоя, backend-сервиса и мониторинга. У каждого компонента своя задача, а ценность появляется только тогда, когда вся конструкция работает как единое целое. На бумаге схема выглядит аккуратно. В проде она быстро превращается в набор компромиссов между качеством ответа, скоростью, стоимостью и надежностью. И это уже совсем не та работа, которую принято представлять по коротким роликам с заголовком «AI-стартап за один вечер».
На этом фоне особенно интересно сравнение с уже знакомыми IT-рынку ролями. Data Scientist по-прежнему отвечает за анализ данных и построение моделей, NLP-инженер — за языковые модели как таковые, Machine Learning Engineer — за продакшен классического ML, MLOps-инженер — за инфраструктуру и жизненный цикл моделей. А ИИ-инженер, по мысли автора, закрывает другой слой задач: прикладную инженерную сборку LLM-систем для бизнеса. В небольшой компании, конечно, все это может делать один и тот же человек, особенно если стартап пока живет в режиме «кто свободен, тот и архитектор». Но по вакансиям и задачам уже видно, что рынок начинает различать работу с моделью и работу с конечной AI-системой.
Самый полезный фрагмент материала — список того, чем такой специалист часто не занимается. Вопреки ожиданиям новичков, ИИ-инженер может месяцами не обучать модели. Зато постоянно решает более приземленные и дорогие для бизнеса вопросы: сравнивает LLM, проектирует архитектуру, пишет агентов, подключает внешние API, оптимизирует латентность и стоимость генерации, защищает систему от инъекций и джейлбрейков, следит за качеством ответов на реальных данных. Дообучение остается в арсенале, но уже не выглядит автоматическим первым шагом. Сначала нужно ответить на неприятный, но взрослый вопрос: а проблема вообще решается файнтюнингом, или достаточно нормальных данных, хорошего RAG и менее наивной архитектуры?
Для разработчиков и команд это, пожалуй, главный вывод. Бум LLM сделал вход в AI визуально проще: демо действительно можно собрать быстро. Но путь от демо до рабочего продукта по-прежнему проходит через слой тяжелой инженерии, который никуда не делся, а местами стал сложнее. Модель забывает контекст, RAG тянет нерелевантные документы, агент начинает бесконечно дергать инструменты, стоимость генерации ползет вверх, время ответа растет под нагрузкой, пользователи быстро находят обходы ограничений. Все это уже не задачи «про промпты», а задачи про архитектуру, эксплуатацию и ответственность за систему в целом. Для бизнеса это означает более трезвый подход к найму: нужен не просто человек, который знаком с модными моделями, а инженер, умеющий превратить их в предсказуемый сервис.
Если этот подход закрепится, рынок получит не очередной громкий ярлык, а вполне осязаемую специализацию на стыке backend, ML и продуктовой инженерии. Тогда вопрос «нужен ли нам ИИ-инженер» быстро сменится другим: где заканчивается эффектное LLM-демо и начинается команда, способная выдержать реальную нагрузку, цену ошибки и ожидания пользователей.