Привет! Я Антон, инженер по машинному обучению — уже больше семи лет работаю в индустрии. За это время мне довелось поработать с классическим ML, компьютерным зрением, NLP, а последние годы — с современным ИИ и большими языковыми моделями. Сейчас я совмещаю работу инженером с ролью технического лида в Яндекс Практикуме на курсе «ИИ-инженер». 

За последние несколько лет я заметил, как вместе с развитием технологий меняется и сама роль инженера, работающего с ИИ. Если раньше в ML-командах зоны ответственности Data Scientist, Machine Learning Engineer и профильных специалистов вроде NLP/CV Engineer были относительно понятны, то сегодня всё чаще появляется отдельная роль — ИИ-инженер. 

У меня, как у человека, который успел поработать в разных областях ML, этот переход вызывает закономерный вопрос: это просто модный ребрендинг MLE или действительно новая инженерная роль? На мой взгляд — второе. И причина не в маркетинге, а в том, что изменился сам способ создания ценности с использованием машинного обучения.

Дисклеймер: все мысли и оценки в этой статье принадлежат мне, ИИ использовался только для стилистического улучшения текста.

Когда обучение моделей перестало быть главной задачей

Когда я начинал работать с машинным обучением, типичный ML-проект выглядел примерно одинаково:

• компания собирала данные;

• дата-сайентист мог обучать модель;

• ML-инженер помогал довести её до продакшена. 

Если задача касалась текста или изображений, то подключался NLP/CV-инженер. Большая часть работы крутилась вокруг одного вопроса: как сделать модель лучше? 

Это хорошо знакомая мне постановка задачи. Мы выбирали признаки, экспериментировали с архитектурами и гиперпараметрами, сравнивали метрики, думали о качестве данных и пытались выжать из модели ещё несколько процентов качества.

С появлением GPT, Llama, Qwen и других современных LLM ситуация изменилась. Теперь компания может взять уже готовую модель мирового уровня и использовать её через API или развернуть самостоятельно.

Казалось бы, задача решена. Но на практике оказалось, что хорошая модель — это лишь начало. Почти сразу возникают совсем другие вопросы: 

• Как подключить модель к внутренней базе знаний?

• Как научить её работать с CRM или корпоративными сервисами?

• Как сделать так, чтобы она не галлюцинировала на данных компании?

• Как уменьшить стоимость запросов?

• Как сократить задержку ответа?

• Как понять, что качество системы не ухудшилось после очередного обновления?

Когда я начал работать с современными LLM-системами, стало особенно заметно, насколько сильно эти вопросы отличаются от привычной задачи «обучить модель получше». 

То есть основной объём работы сместился с обучения модели на построение системы вокруг модели. Именно поэтому и появилась отдельная инженерная роль. 

Кто такой ИИ-инженер

Если попробовать дать определение одной фразой, оно будет звучать примерно так:

ИИ-инженер — это такой инженер, который проектирует, собирает и поддерживает ИИ-системы на базе готовых языковых моделей.

Ключевое здесь — слово система. Сегодня полезный ИИ-продукт редко состоит только из одной LLM. Гораздо чаще архитектура выглядит примерно так: 

Пользователь → LLM → RAG → векторная база → внешние API → агент → мониторинг → бизнес-система.

Каждый компонент решает свою задачу.

• LLM отвечает за генерацию.

• RAG предоставляет модели нужные данные.

• Агент принимает решения и использует инструменты.

• FastAPI публикует сервис.

• Мониторинг показывает, что происходит после релиза.

Именно ИИ инженер отвечает за то, чтобы всё это работало как единое целое.

По моему опыту, именно здесь и проходит главное отличие современной ИИ-инженерии от работы непосредственно с моделью. Нужно понимать не только, что умеет конкретная LLM, но и как встроить её в существующую техническую и бизнес-инфраструктуру. 

Чем ИИ-инженер отличается от других специалистов

Новая роль не появилась вместо существующих профессий. Скорее, она закрыла другую область задач. Если очень грубо сравнить специализации, получится примерно так. 

Конечно, в небольшой компании один человек может выполнять сразу несколько ролей. Да и границы между профессиями никогда не были абсолютно жёсткими. 

Но если посмотреть на то, с какими задачами я сталкиваюсь сегодня и какие требования всё чаще появляются в вакансиях, становится заметно: ИИ-инженер всё чаще становится человеком, который отвечает именно за конечную систему, а не за отдельную модель. 

Чем ИИ-инженер обычно не занимается

Это, пожалуй, самый неожиданный момент для тех, кто только начинает знакомиться с профессией.

Многие представляют ИИ инженера человеком, который постоянно работает с нейронными сетями. На практике, как я уже понял, всё часто наоборот.

Большинство ИИ-инженеров могут месяцами не запускать обучение модели. Зато постоянно занимаются такими задачами, как: 

• проектирование системы;

• выбор и сравнение LLM;

• разработка агентов;

• интеграция с внешними API;

• оптимизация латентности и стоимости генерации;

• защита от иньекций и джейлбрейков;

• мониторинг качества ответов;

• оценка эффективности системы на реальных данных.

Дообучение моделей тоже встречается, но гораздо реже, чем принято думать.

Во многих проектах оказывается, что проблему можно решить качественными данными, хорошим RAG или более удачной архитектурой без дополнительного обучения модели. 

И это, на мой взгляд, один из самых важных сдвигов в профессии. Инженеру всё чаще приходится сначала ответить на вопро: «А действительно ли нам нужно дообучать модель?» — а уже потом думать о самом обучении. 

Почему эта работа кажется проще, чем есть на самом деле

Сейчас в интернете огромное количество видео с лозунгами, что можно легко и просто создать ИИ-стартап за день. Доля правды в этом есть: красивое демо действительно можно собрать быстро. Но между демо и рабочим продуктом лежит огномная инженерная прослойка.

За время работы с ML я видел, как менялось отношение к этой части работы. Раньше многие инженерные проблемы возникали вокруг вывода и эксплуатации обученной модели. Сегодня к ним добавился целый новый слой, связанный с поведением LLM-систем.

Почти каждый, кто доводил LLM до реальных пользователей, сталкивался с одинаковыми проблемами. Например:

• Модель начинает забывать нужный контекст.

• RAG достаёт нерелевантные документы.

• Стоимость генерации оказывается слишком высокой.

• Агент начинает бесконечно вызывать инструменты.

• Время ответа растёт с увеличением нагрузки.

• Пользователи находят способы обойти ограничения.

Именно здесь важна работа ИИ-инженера. Большую часть времени он занимается не промптами, а поиском компромиссов между качеством, стоимостью, скоростью и надёжностью системы.

И это, пожалуй, одна из вещей, которые сложнее всего объяснить человеку, который знакомится с профессией только по красивым демо про ИИ. В демо обычно виден один удачный запрос. В реальном продукте приходится думать о тысячах запросов, ошибках, задержках, стоимости, безопасности и поведении системы в нестандартных ситуациях.

Кто может стать ИИ инженером

Наверное, это одна из самых открытых инженерных профессий последних лет. В неё приходят из самых разных направлений. Тут и бэкенд-разработчики, которые уже умеют строить сервисы, и ML-инженеры, которые уже хорошо понимают модели. 

Безусловно, в списке есть и Data Scientist, которые привыкли работать с данными. Здесь же и MLOps-инженеры, которые отлично знают инфраструктурную составляющую. 

Я сам прошёл через несколько областей машинного обучения: от классического ML до компьютерного зрения, NLP и современных LLM. Поэтому хорошо понимаю, что переход в новую область обычно выглядит не как обучение профессии с нуля, а как постепенное расширение уже существующего инженерного фундамента.

Каждому из этих специалистов приходится расширить свою область знаний, но фундамент уже есть.

Даже Python-разработчики без опыта в машинном обучении сегодня довольно успешно переходят в ИИ-инжиниринг, если готовы разобраться в устройстве современных LLM и научиться работать с ними как с инженерной платформой.

Чему должен учиться ИИ инженер

Если посмотреть не на курсы, а на реальные задачи компаний, становится заметно, что обучение ИИ-инжинирингу довольно естественным образом складывается в несколько последовательных этапов. 

Сначала нужно разобраться, как работают современные языковые модели. Не на уровне математического вывода известного механизма внимания, а на уровне инженерных решений.

Что влияет на качество генерации? Почему одна модель отвечает быстрее другой? Откуда берётся стоимость инференса? Когда стоит использовать длинный контекст, а когда лучше построить RAG?

Следующий этап — научиться подключать модель к данным компании. Именно поэтому сегодня практически невозможно представить ИИ-инженера без понимания RAG-систем и всех этапов в нём: подготовки документов, эмбеддингов, векторных баз, поиска и оценки качества извлечения целевой информации. 

После этого появляются агенты. Современные ИИ-системы всё реже ограничиваются одним ответом модели. Они используют инструменты, обращаются к API, работают с изображениями, планируют последовательность действий. Всё это требует понимания агентных архитектур и оркестрации.

Дальше возникает следующая проблема: даже хорошо работающий прототип ещё не является продуктом. Его нужно упаковать в сервис, сделать быстрым, устойчивым к нагрузке, научиться наблюдать за ним после релиза.

Поэтому ИИ инженер неизбежно сталкивается с FastAPI, Docker, асинхронностью, мониторингом и метриками, которые специфичны именно для LLM.

И, наконец, после запуска начинается самая длинная часть жизненного цикла — эксплуатация в проде. Нужно измерять качество ответов, защищать систему от атак, искать узкие места, понимать, когда достаточно изменить промпт или параметры инференса, а когда действительно пора задуматься о дообучении модели. 

Если посмотреть на этот путь целиком, становится понятно, что ИИ-инжиниринг — это не про одну библиотеку и не про конкретную модель. Это про умение собрать работающую ИИ-систему от первого запроса пользователя до сервиса, который можно без страха показать клиентам. При этом ключевым навыком ИИ-инженера становится способность смотреть на систему целиком.

Именно вокруг такой логики мы строили программу обучения на курсе «ИИ-инженер». У курса есть бесплатная часть, чтобы узнать больше о задачах ИИ-инженера, познакомиться с Практикумом и узнать, подходит ли программа по сложности.

Мы строили программу не вокруг отдельных инструментов вроде LangChain, FastAPI или Qdrant — они всё равно будут меняться. А вокруг инженерных задач, которые сегодня приходится решать практически каждому ИИ-инженеру: работа с LLM, построение RAG, создание агентных систем, деплой, мониторинг и развитие ИИ-сервиса после запуска.

Вместо заключения 

Профессия уже успела пройти несколько этапов на моих глазах. Когда-то главным вопросом действительно было: «Как обучить хорошую модель?» Сегодня же для большинства компаний вопрос звучит иначе: «Как превратить возможности современных LLM в надёжный продукт, который приносит пользу бизнесу?» 

Именно на этот вопрос отвечает профессия ИИ-инженера. И даже если название изменится через несколько лет, задача останется той же самой: соединять модели, данные, инфраструктуру и продукт в единую работающую систему.