Специалист по ИИ: кого нанимать для внедрения и что он должен знать

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

Привет! Меня зовут Рустам Борханов и я — старший инженер-программист отдела интеграции в Финаме и автор курса «LLM-разработчик» в Хекслете.

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

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

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

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

Внедрение ИИ в бизнес: три направления, где он приносит пользу

Если сильно обобщить, уже сейчас можно выделить несколько понятных направлений применения ИИ в компаниях:

• Работа с документами.

• Работа с внутренними центрами знаний и накопленной компанией информацией.

• Различные сценарии работы с внешними клиентами и обработки информации.

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

Внедрение ИИ без задачи: компания хочет, но не знает куда

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

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

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

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

Ищут навыки в новых инструментах и забывают про инженерную базу

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

Разные задачи удобнее решать разными средствами. Где-то критична скорость выполнения, где-то — потребление ресурсов. В подобных случаях выбор языка и технологий уже определяется конкретной инженерной задачей. Например, для задач с жесткими требованиями к производительности могут понадобиться C++ или Rust.

Но язык — не главное. Человек должен понимать, что такое агенты, какие существуют инструменты для работы с искусственным интеллектом, какие бывают большие, средние, малые и специализированные модели. И, конечно, уметь писать инструменты, которые затем будут использоваться для автоматизации. Как устроена обвязка вокруг агента изнутри — в разборе Анатомия агентного харнесса. Если хочется собрать агента руками, есть материал с рабочим кодом: Как создать ИИ-агента на Python.

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

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

Что должен знать специалист по ИИ: базовые термины

Что должен знать ИИ-разработчик: языки, базы данных, агенты, оркестрация

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

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

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

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

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

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

Подходящее резюме отсеивают до собеседования

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

Но ее резюме до меня не дошло. Причину мне объяснили буквально так: «Никогда не видел хороших девочек-программистов».

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

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

Отбор резюме через чат: почему «закинуть всё в LLM» не работает

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

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

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

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

Решение: карта компетенций специалиста по ИИ

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

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

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

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

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

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

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

Где подключать ИИ к найму: обработка входящих резюме

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

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

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

Как ИИ-разработчику пройти первичные фильтры и дойти до собеседования

Если посмотреть на ситуацию со стороны соискателя, проблема обратная: компании завалены откликами. Особенно это заметно на HeadHunter.

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

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

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

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

Тестовое задание, которое кандидат делает с ИИ: что смотреть в результате

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

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

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

Техническое интервью заменяют еще одним испытанием

После первичных этапов все равно нужно убедиться, что перед нами действительно тот специалист, которого искали. Формат собеседования может быть разным: можно использовать алгоритмические задачи или live coding, а можно просто поговорить с человеком о конкретной технической проблеме. Для маленьких и средних компаний второй вариант часто оказывается полезнее. Просто выбираем тему и спрашиваем: что ты об этом думаешь? Как бы ты это сделал? Почему? Какие здесь есть ограничения?

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

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

Какие знания добрать опытному разработчику для работы с ИИ

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

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

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

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

Коротко: ответы на частые вопросы

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

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

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

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

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