Какие новые IT-профессии появились благодаря ИИ

Какие новые IT-профессии появились благодаря ИИ

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

Несколько лет назад почти любую работу с нейросетями называли машинным обучением. Сейчас названий стало заметно больше: AI Engineer, LLM Engineer, RAG Engineer, разработчик агентов, AI Evaluator. Иногда кажется, что индустрия просто любит придумывать новые должности быстрее, чем успевает определить их обязанности.

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

AI Engineer

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

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

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

Поэтому хороший AI Engineer — это прежде всего сильный разработчик. Умение написать красивый промпт полезно, но слабое понимание архитектуры оно не компенсирует.

LLM Engineer

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

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

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

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

RAG Engineer

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

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

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

RAG Engineer занимается как раз этой частью. Он решает, как разбивать документы, что помещать в индекс, как искать подходящие данные и как проверять, действительно ли ответ основан на найденном источнике.

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

Разработчик AI-агентов

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

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

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

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

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

Prompt Engineer

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

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

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

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

MLOps Engineer

Модель может отлично работать в ноутбуке разработчика и рассыпаться после выхода в продакшен. Именно здесь появляется MLOps Engineer.

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

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

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

AI Trainer и AI Evaluator

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

AI Trainer подготавливает примеры и показывает модели, какие ответы считаются удачными. Здесь часто важнее не программирование, а знание предметной области. Код для обучения программистов должен проверять разработчик. Юридические ответы — юрист. Медицинские — специалист с соответствующей квалификацией.

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

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

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

AI Safety Specialist

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

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

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

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

Специалист по AI-автоматизации

Не каждой компании нужен собственный LLM Engineer. Зато почти в любой компании найдётся несколько повторяющихся процессов, которые хочется ускорить.

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

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

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

AI Product Manager

Появление AI Product Manager вполне логично. Продукты с нейросетями ведут себя не так предсказуемо, как обычное программное обеспечение.

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

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

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

Какие профессии останутся?

Часть названий наверняка исчезнет. Prompt Engineer может раствориться внутри разработки и аналитики. RAG Engineer со временем, возможно, станет одной из специализаций backend-разработчика. Слово AI вообще начнут добавлять к должностям реже, когда технология перестанет восприниматься как отдельная экзотика.

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

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

Что учить разработчику?

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

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

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

Источник