Профессия AI-инженер: что делает, чем отличается от ML-инженера и как в неё прийти

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

Типичная задача AI-инженера звучит как продуктовая: «ассистент должен отвечать на вопросы по внутренней базе знаний», «агент должен разбирать заявки и заводить их в систему», «нужно извлекать поля из сканов документов». Модель здесь — одна из частей, а основная работа идёт вокруг неё: какие данные ей дать, какие действия разрешить, как проверить результат и что делать, когда она ошибается.

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

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

Термины, которые встретятся дальше

• LLM — большая языковая модель, которая генерирует текст по входному тексту.
• Токен — единица текста, которой оперирует модель; от числа токенов зависят ограничения контекста, задержка и стоимость.
• Контекстное окно — сколько текста модель учитывает за один запрос.
• Эмбеддинг — числовой вектор, описывающий смысл текста; на них строится семантический поиск.
• RAG — генерация с опорой на найденные документы: сначала поиск по вашим данным, потом ответ модели по найденному.
• Агент — система, в которой модель сама выбирает, какие инструменты вызвать, чтобы решить задачу.
• Эвалы (evals) — наборы проверочных примеров и метрики, по которым измеряется качество ИИ-системы.

Жизненный цикл ИИ-функции: от идеи до продакшена

1. 01Формулировка задачи. Что именно должен делать ИИ, для кого и как пользователь поймёт, что результат хороший. Здесь же — решение, нужен ли ИИ вообще или задачу проще решить обычным кодом.
2. 02Сбор примеров. Десятки реальных входов с ожидаемыми результатами или критериями оценки. Это будущий набор эвалов.
3. 03Прототип. Простейшая версия: одна модель, один промпт, структурированный ответ. Прогон на примерах и честный разбор ошибок.
4. 04Контекст и инструменты. Если модели не хватает знаний — поиск по данным. Если нужны действия — инструменты с минимальными правами.
5. 05Итерации по метрикам. Изменение промпта, модели, разбиения документов — и каждый раз повторный прогон эвалов.
6. 06Подготовка к продакшену. Валидация ответов, обработка ошибок и обрывов, ограничения по затратам, логирование, защита от prompt injection.
7. 07Запуск и наблюдение. Небольшая группа пользователей, сбор реальных ошибок, пополнение набора эвалов новыми случаями.

Как это выглядит в обычной работе

Значительная часть времени AI-инженера уходит не на написание промптов, а на чтение: логов, ответов модели, разборов ошибок. Типичный рабочий цикл — посмотреть, где система ошиблась на реальных запросах, понять причину (не нашёлся нужный документ, модель неверно поняла инструкцию, данные противоречат друг другу), внести изменение и проверить его на эвалах, чтобы не сломать то, что уже работало.

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

AI-инженер, ML-инженер, дата-сайентист и разработчик

ML-инженер

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

Дата-сайентист

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

AI-инженер

AI-инженер работает на уровень выше модели: она для него обычно готовая, доступная через API или как открытые веса. Его вопросы — как превратить модель в надёжную систему, которая решает задачу пользователя. Границы размыты: AI-инженер может дообучить небольшую модель, а ML-инженер — собрать агента. Но центр тяжести разный.

Обычный разработчик

Разработчик строит системы из детерминированных компонентов. AI-инженер — тоже разработчик, но с одним вероятностным компонентом в центре, и это меняет подход к тестированию, проектированию и эксплуатации.

Что меняется по сравнению с обычной разработкой

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

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

Карта навыков

Инженерный фундамент

Уверенный язык программирования — чаще всего Python или TypeScript, работа с API, базами данных, асинхронностью, очередями, контейнерами, деплоем. AI-инженер прежде всего инженер: без этого фундамента система не доживёт до продакшена.

Понимание моделей

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

Поиск по данным (RAG)

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

Агенты и инструменты

Описание инструментов, структурированные ответы, циклы «модель — инструмент — модель», ограничение прав, подтверждение человеком для опасных действий. Здесь же — понимание стандартных протоколов подключения инструментов и того, почему запрет в промпте не заменяет ограничение доступа.

Оценка качества

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

Эксплуатация и наблюдаемость

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

Тексты на нескольких языках

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

Продуктовое мышление

Где ИИ действительно нужен, а где достаточно обычного кода; как пользователь будет проверять и исправлять результат; что произойдёт, когда модель ошибётся. Хороший AI-инженер умеет отговорить от ИИ там, где он не нужен.

Куда двигаться: рамка выбора

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

План перехода из разработки

1. 01Разберитесь с основами работы моделей: токены, контекст, эмбеддинги, ограничения. Официальная документация крупных провайдеров моделей хорошо объясняет практику.
2. 02Сделайте первый проект через API со структурированным ответом и валидацией по схеме.
3. 03Добавьте поиск по своим данным: соберите небольшой RAG по реальной документации и разберитесь, где он ошибается.
4. 04Соберите набор эвалов и автоматическую оценку. Меняйте промпт или модель и смотрите, как меняются метрики.
5. 05Сделайте агента с инструментами — сначала только для чтения, потом с одним действием под подтверждением человека.
6. 06Доведите один проект до эксплуатации: логи, обработка ошибок, контроль затрат, защита от injection.
7. 07Применяйте это на текущей работе: найдите задачу в своей компании, которую можно автоматизировать, — это лучший опыт и лучшая строчка в резюме.

Идеи для учебных проектов

• Извлечение структурированных полей из документов разного формата с проверкой по схеме и подсчётом ошибок по каждому полю.
• Ассистент по документации открытого проекта с поиском, цитированием источников и честным «не знаю», когда ответа в документах нет.
• Классификатор обращений с эвалами и сравнением нескольких моделей по качеству, задержке и стоимости.
• Агент, который по описанию задачи создаёт черновик тикета в трекере, но не публикует его без подтверждения.

Пример: как мог бы выглядеть первый проект

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

Он берёт задачу извлечения реквизитов из счетов. Первым делом собирает несколько десятков реальных счетов разного вида и вручную записывает правильные значения полей — это набор эвалов. Затем пишет прототип: модель получает текст счёта и возвращает JSON по схеме, код проверяет формат и типы.

Прогон показывает, что модель хорошо справляется с суммой и датой, но путает реквизиты продавца и покупателя на счетах нестандартного вида. Разработчик добавляет в промпт пояснение и пару примеров, снова прогоняет набор — ошибок по этому полю становится меньше, но появляется новая проблема с датами в другом формате. Он добавляет нормализацию дат в код, а не в промпт, потому что это детерминированная задача.

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

Портфолио и собеседования

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

На собеседованиях на такие роли обычно проверяют несколько вещей:

• Инженерные основы — так же, как у любого разработчика.
• Проектирование ИИ-системы: как бы вы построили ассистента или агента под задачу, где поиск, где инструменты, где человек.
• Оценку качества: как вы поймёте, что система работает, и как заметите деградацию.
• Разбор ошибок: что делать, если модель отвечает неверно, — и умение отличить проблему поиска от проблемы промпта или данных.
• Безопасность и данные: права агента, prompt injection, персональные данные.

Как готовиться

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

Типичные ошибки и как их заметить

• Бесконечная подгонка промпта. Как заметить: изменений много, а набора эвалов нет. Как исправить: сначала собрать примеры, потом менять.
• Агенты там, где хватает одного вызова. Как заметить: цепочка из нескольких шагов решает задачу, которую решает один запрос со структурированным ответом. Как исправить: начинать с самого простого решения и усложнять только по метрикам.
• Вера в красивое демо. Как заметить: систему проверяли только на удобных примерах. Как исправить: добавить в эвалы редкие, неудобные и некорректные входы.
• Доверие к ответу модели без проверки. Как заметить: ответ сразу пишется в базу или показывается пользователю. Как исправить: валидация по схеме и бизнес-правилам.
• Всё решается промптом. Как заметить: в промпте инструкции по форматированию дат, расчётам и проверкам. Как исправить: детерминированное — в код.
• Стоимость и задержка «потом». Как заметить: в проекте нет учёта токенов и времени ответа на запрос. Как исправить: логировать их с первого прототипа и сравнивать модели по качеству, цене и скорости одновременно.
• Эвалы только на одном языке. Как заметить: все проверочные примеры написаны по-русски, а пользователи пишут и по-узбекски. Как исправить: добавить реальные примеры на каждом языке продукта.
• Начало с обучения моделей с нуля. Как заметить: месяцы уходят на теорию, а работающего продукта нет. Как исправить: начинать с готовых моделей и задач из своей работы.

Чек-лист: готовы ли вы к первой роли

1. 01Можете объяснить, что такое токены, контекстное окно и эмбеддинги.
2. 02Понимаете, почему модель ошибается правдоподобно, и как это ловить.
3. 03Сделали проект со структурированным ответом и валидацией.
4. 04Построили поиск по своим данным и знаете, где он ломается.
5. 05Собрали набор эвалов и измеряете качество на нём, а не на глаз.
6. 06Сравнивали несколько моделей по качеству, задержке и стоимости.
7. 07Сделали агента с инструментами и ограничили его права.
8. 08Понимаете, почему запрет в промпте не защищает от prompt injection.
9. 09Знаете, какие данные нельзя отправлять во внешние сервисы.
10. 10Довели хотя бы один проект до состояния, когда им пользуются другие люди.

Итог

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