Какие специалисты нужны для внедрения ИИ в компании

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

От чего зависит состав команды

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

Есть четыре фактора, которые определяют, кого и в каком количестве вы нанимаете.

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

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

Четыре типа задач и разные команды под них

Разберу на конкретных сценариях, которые встречаются в российских компаниях чаще всего.

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

Обратите внимание, что во всех четырёх сценариях присутствует человек из бизнеса. Это не формальность для согласований. Без него команда оптимизирует метрику, которая не связана с деньгами компании.

Что проверить до того, как открывать вакансии

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

• Есть ли у задачи измеримый показатель, который вы готовы улучшать. Не абстрактная эффективность, а конкретная цифра вроде доли заявок, обработанных без оператора, или процента точности прогноза.
• Где физически лежат данные и за какой период они накоплены. Для прогнозных задач обычно нужно от года истории, для некоторых сезонных товаров от двух лет.
• Кто в компании отвечает за результат. Фамилия, а не отдел.
• Есть ли инфраструктура для запуска. Собственный сервер, облако российского провайдера или ничего из перечисленного.
• Какие ограничения накладывает работа с персональными данными и коммерческой тайной. Это определяет, можно ли вообще отправлять данные во внешние сервисы.

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

Роли в команде внедрения ИИ и их задачи

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

Технические роли

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

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

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

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

Работа с данными и постановкой задачи

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

• Специалист по данным. Формулирует задачу в терминах, пригодных для машинного обучения, проверяет гипотезы, оценивает, достижим ли нужный уровень качества на имеющихся данных. Часто его главный вклад — вовремя сказать, что задача в такой постановке не решается, и предложить другую.
• Аналитик данных. Готовит отчётность, считает базовые показатели, с которыми потом будут сравнивать результат модели. Без базового уровня невозможно понять, улучшила модель процесс или нет.
• Разметчик данных. Размечает примеры для обучения в задачах классификации, распознавания объектов, оценки тональности обращений. Это недооценённая роль, от качества которой напрямую зависит потолок точности модели.
• Эксперт предметной области. Сотрудник из того подразделения, чей процесс автоматизируется. Кредитный специалист, товаровед, старший оператор поддержки, технолог производства. Единственный человек, который точно знает, как процесс работает в реальности, а не в регламенте.

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

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

Управление, безопасность и сопровождение

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

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

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

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

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

Как меняется команда по этапам проекта

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

Пилот: минимальный состав из двух-трёх человек

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

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

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

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

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

Промышленная эксплуатация: кого добавляют

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

1. Инженер по данным. Превращает ручные выгрузки в регулярный процесс с проверками полноты, обработкой пропусков и уведомлениями о сбоях. Без него система будет тихо работать на устаревших данных.
2. Инженер эксплуатации моделей. Настраивает развёртывание, версионирование, журналирование запросов и ответов, возможность откатиться к предыдущей версии. Отвечает за наблюдаемость качества в реальном времени.
3. Разработчик интеграций. Встраивает решение в системы, где работают сотрудники, добавляет обработку ошибок и поведение на случай недоступности модели.
4. Специалист по информационной безопасности. Проверяет разграничение доступа, обезличивание, место хранения журналов, соответствие внутренним политикам и требованиям по персональным данным.
5. Специалист по внедрению. Пишет инструкции, обучает пользователей, собирает обратную связь в первые недели и возвращает её в команду разработки.

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

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

Поддержка модели: кто остаётся в команде

Модель не инструмент с бесконечным сроком службы. Она описывает закономерности того периода, на котором обучалась. Меняется ассортимент, меняется поведение клиентов, меняется формулировка обращений после обновления интерфейса, и качество начинает медленно падать. Это падение незаметно без мониторинга, потому что система продолжает выдавать ответы.

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

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

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

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

Нанять, обучить своих или отдать на аутсорс

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

Сравню по основным параметрам, которые влияют на решение.

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

Когда выгоднее подрядчик

Подрядчик уместен в нескольких ситуациях, и все они связаны с ограниченностью или редкостью задачи.

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

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

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

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

Какие роли оставляют внутри компании

Есть компетенции, вынос которых за пределы компании ломает проект независимо от качества подрядчика.

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

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

Гибридная схема: подрядчик плюс внутренний владелец

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

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

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

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

Как проверить компетенции кандидата

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

Что смотреть в портфолио и в публичном коде

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

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

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

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

Тестовое задание на реальных данных

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

Рабочая схема выглядит так. Берётся обезличенный фрагмент реальных данных со всеми характерными дефектами, то есть с пропусками, дублями, несогласованными справочниками и опечатками. Формулируется задача в терминах бизнеса, без подсказок о методе. Просится не только код, но и короткая записка с описанием хода мысли.

Оценивать имеет смысл четыре вещи.

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

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

Вопросы на интервью для разных роли

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

Для инженера машинного обучения и специалиста по данным.

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

Для инженера по данным.

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

Для инженера эксплуатации моделей.

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

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

Красные флаги в резюме и на собеседовании

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

• Перечисление двадцати библиотек и фреймворков без описания задач, в которых они применялись.
• Все проекты описаны через используемые технологии, ни один через результат для бизнеса.
• Нет ни одного проекта, доведённого до эксплуатации с реальными пользователями.
• Опыт целиком состоит из учебных и соревновательных задач, где данные уже подготовлены.
• Цифры качества без указания на то, с чем сравнивали и на какой выборке измеряли.
• Готовность назвать точный срок и результат до знакомства с данными.

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

Сколько стоит команда: вилки по ролям и грейдам

Любые цифры по оплате труда устаревают быстро, поэтому воспринимайте их как ориентир порядка величины, а не как прайс. Диапазоны ниже отражают ситуацию на российском рынке в конце 2025 и начале 2026 года для найма в штат, без учёта налогов и накладных расходов компании. Москва и Санкт-Петербург находятся в верхней части вилок, региональный найм с удалённой работой обычно на пятнадцать-двадцать пять процентов ниже.

Роль	Начальный уровень	Средний уровень	Высокий уровень
Инженер машинного обучения	от 120 до 180 тыс.	от 250 до 350 тыс.	от 400 до 600 тыс.
Специалист по данным	от 110 до 170 тыс.	от 230 до 330 тыс.	от 380 до 550 тыс.
Инженер по данным	от 120 до 170 тыс.	от 220 до 310 тыс.	от 350 до 480 тыс.
Инженер эксплуатации моделей	от 150 до 200 тыс.	от 260 до 360 тыс.	от 400 до 520 тыс.
Разработчик интеграций	от 100 до 150 тыс.	от 200 до 280 тыс.	от 320 до 420 тыс.
Аналитик данных	от 80 до 130 тыс.	от 150 до 220 тыс.	от 250 до 320 тыс.
Владелец продукта	нет такого уровня	от 200 до 300 тыс.	от 350 до 500 тыс.
Архитектор решения	нет такого уровня	от 320 до 420 тыс.	от 450 до 650 тыс.
Специалист по информационной безопасности	от 100 до 150 тыс.	от 200 до 300 тыс.	от 330 до 450 тыс.

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

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

Сколько стоит проект целиком

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

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

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

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

Ошибки при подборе специалистов

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

Один универсальный ИИ-специалист вместо команды

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

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

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

Инженеры машинного обучения без данных и без инженера по данным

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

Признаки того, что вам нужен инженер по данным раньше, чем инженер машинного обучения.

1. Данные для задачи лежат в двух и более системах, и между ними нет надёжного общего идентификатора.
2. Выгрузки делаются вручную по запросу, регулярного процесса обновления не существует.
3. Исторические данные хранятся не полностью, старые записи перезаписываются текущими значениями.
4. Никто в компании не может назвать, какая система является источником истины по ключевым показателям.
5. Качество справочников не проверяется, дубли контрагентов и товаров присутствуют в заметном количестве.

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

Проект без владельца со стороны бизнеса

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

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

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

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

Отсутствие эксплуатации моделей и смерть решения после запуска

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

Минимальный набор, который закрывает большую часть риска и не требует отдельной штатной единицы в небольшой компании.

• Фиксация версий данных, кода и параметров обучения, достаточная для воспроизведения результата через год.
• Журналирование входящих запросов и ответов модели с возможностью разобрать конкретный случай по обращению сотрудника.
• Регулярный отчёт по качеству на свежих данных с понятным порогом, ниже которого запускается разбор.
• Возможность быстро вернуться к предыдущей версии модели или отключить автоматику с передачей задач людям.
• Назначенный человек, которому приходит уведомление о сбое, и его подменяющий на период отпуска.

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

Чек-лист: кого нанимать под вашу задачу

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

Шаг первый. Определите, с кого начинать

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

Шаг второй. Добавьте роли под тип задачи

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

Шаг третий. Закройте организационную часть

1. Назначен владелец с полномочиями менять процесс, его участие закреплено не менее одного дня в неделю.
2. Эксперт предметной области выделен официально с конкретным количеством часов, а не помогает по доброй воле.
3. Специалист по информационной безопасности подключён до выбора технического подхода, а не на приёмке.
4. Определён человек, отвечающий за обучение пользователей и сбор обратной связи в первый месяц работы.
5. В бюджет заложено сопровождение на год вперёд и время собственных сотрудников, а не только внешние платежи.
6. Для каждой переданной на подряд роли зафиксировано, кто внутри компании сможет проверить результат.

Шаг четвёртый. Проверьте себя перед выходом на рынок труда

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

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

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