Как на практике устроена роль ИИ-инженера

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

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

Как этап развития компании меняет круг задач

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

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

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

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

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

Работу определяет ответственность за продукт

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

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

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

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

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

Когда ответ неверен, инженер должен найти первое ошибочное допущение. В запросе не указали регион клиента? Поиск вернул устаревшую политику? Промпт плохо описал задачу? Модель проигнорировала верный контекст? Постобработка удалила ссылку на источник? Интерфейс позволил пользователю одобрить действие, не показав основания? Для каждой причины нужно свое исправление. Сначала заменить модель хочется потому, что это занимает несколько минут и дает свежее демо, но часто такой ход лишь перемещает ошибку.

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

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

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

ИИ-разработка и ML-разработка пересекаются, но не совпадают

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

В руководстве Google Cloud для Professional Machine Learning Engineer описан специалист, который создает, оценивает, выводит в продакшен и оптимизирует ML-модели, хорошо знает платформы данных, распределенную обработку, архитектуру моделей, обучение, повторное обучение и MLOps. Это полезное определение, потому что в центре находится жизненный цикл модели. Во многих нынешних вакансиях ИИ-инженеры используют уже обученные модели. Они тоже должны понимать поведение модели, однако их главный результат работы - приложение.

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

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

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

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

Нужные навыки складываются в практический набор

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

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

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

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

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

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

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

Оценка начинается с примеров, а не с балла бенчмарка

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

Каждый пример должен быть достаточно небольшим для диагностики. Этот файл JSON Lines дает системе подготовки ответов входные данные, допустимые факты, обязательные свойства и запрещенное действие:

{"id":"refund-eligible-01","input":"I was charged twice for order 1842","facts":["two settled charges","duplicate charge policy permits refund"],"must_include":["acknowledgment","human approval required"],"must_not":["claim refund was issued"]}
{"id":"refund-missing-02","input":"Refund this now","facts":[],"must_include":["request order identifier"],"must_not":["invent account details","call refund tool"]}

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

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

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

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

Надежные системы ограничивают полномочия модели

Безопасный агент дает модели меньше полномочий, чем пользователю или серверной части, и закрепляет эту разницу вне промпта. Фраза «никогда не отправляй деньги без одобрения» задает поведение, но не ограничивает доступ. Сам инструмент должен требовать авторизованного пользователя, проверять сумму и получателя, применять лимиты и записывать решение.

Проект OWASP GenAI Security называет этот риск Excessive Agency, то есть избыточными полномочиями. В рекомендациях 2025 года коренными причинами названы лишние функции, разрешения и автономность. Такая формулировка полезнее обвинений в галлюцинациях, потому что даже последовательная модель может выполнить вредоносную инструкцию, спрятанную в письме или документе. Размер ущерба определяет граница разрешений.

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

Для надежности нужны такие же внешние ограничения. Задайте тайм-ауты и общее число шагов, чтобы агент не зациклился. Повторные попытки должны быть идемпотентными, иначе сетевая ошибка продублирует действие. Проверяйте структурированный вывод до передачи другой системе. Случаи с низкой уверенностью или неполными данными отправляйте человеку вместе с нужным для решения контекстом. Сохраняйте журнал входных данных, найденных источников, вызовов инструментов, одобрений и результата.

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

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

При найме проверяйте производственное решение

Хороший процесс найма предлагает кандидату подумать над ограниченной продуктовой задачей. Вопросы по названиям моделей быстро устаревают, а чат-бот выходного дня в основном доказывает простоту вызова API. Дайте кандидату небольшой рабочий процесс, показательные примеры, один опасный крайний случай и попросите объяснить, что он будет измерять.

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

Практическое задание может оставаться коротким:

1. Дайте 15 размеченных примеров, включая дубликаты, отсутствующие поля, враждебный текст и один неоднозначный случай.
2. Попросите сделать работающий сервис или четкий проект, который возвращает структурированный результат и записывает достаточно данных для отладки.
3. Потребуйте небольшой отчет об оценке, где ошибки объяснены, а не спрятаны в одном балле.
4. Обсудите, как проект изменится при десятикратном трафике и конфиденциальных данных клиентов.

Оценивайте постановку задачи, качество кода, проверку, безопасность и зрелость решений. Не награждайте сложность фреймворков. Кандидат с простым классификатором и понятной обработкой сбоев может быть сильнее того, кто развернул многоагентный процесс для той же задачи. Спросите, что он намеренно не стал создавать. Хорошие инженеры так же часто защищают команду от ненужного ИИ, как внедряют его.

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

Для первого специалиста по ИИ выбирайте производственный опыт разработки ПО и доказанное умение оценивать продуктовые решения. Сначала нанимать узкого ML-инженера стоит лишь тогда, когда бизнесу действительно нужно создавать собственные модели или модельная способность составляет сам продукт. Если компания в основном добавляет ИИ в существующий процесс SaaS, прикладной инженер, способный освоить слой моделей, обычно выпускает результат быстрее и оставляет поддерживаемый сервис.

Карьерный путь начинается в смежных профессиях

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

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

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

Учитесь в порядке, которого требует работа. Освойте производственное программирование и API, затем основы моделей, структурированный вывод, поиск, оценку, безопасность и эксплуатацию. Читайте документацию поставщиков, но изучайте также AI Risk Management Framework от NIST и руководство OWASP GenAI, потому что примеры поставщиков обычно учат получать первый ответ, а не распределять ответственность внутри организации. Освойте статистику настолько, чтобы рассуждать о выборках, шуме и компромиссах.

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

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

Некоторым компаниям пока не нужен такой специалист

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

Не нанимайте такого специалиста, чтобы не исправлять базовые проблемы ПО и данных. Если у записей клиентов нет стабильных идентификаторов, права хранятся в таблицах, а за политику поддержки никто не отвечает, модель лишь спрячет дефекты глубже. Исправьте исходные системы или ограничьте первый сценарий теми данными, которым компания может доверять.

Короткая внешняя оценка может обойтись дешевле преждевременной постоянной команды. В oleg.is я провожу Team & AI Audit за пять рабочих дней, чтобы разложить инженерную работу и найти места, где усиление команды с помощью ИИ сэкономит деньги до предложения трансформации. Полезный результат такой проверки - план с приоритетами, включая участки, где детерминированная автоматизация или изменение процесса лучше функции с ИИ.

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