В 2026 году вакансий, связанных с ИИ, большими языковыми моделями и агентами, стало заметно больше и в России, и за ее пределами. Технологические компании, банки и даже обычный enterprise поняли, куда движется индустрия, и начали срочно внедрять ИИ в продукты и внутренние процессы.
Если открыть hh.ru, LinkedIn или Telegram-каналы с вакансиями, легко увидеть набор ролей, которые постоянно пересекаются по описанию и требованиям:
LLM Engineer
ML Engineer
AI Engineer
AI Architect
иногда еще что-то вроде «AI Automation Engineer»
Особенно часто встречается вакансия LLM Engineer. И вот тут начинается путаница.
Например, в одной вакансии Senior LLM Engineer требуют:
2+ года коммерческой разработки на Python
практический опыт с LangChain, LlamaIndex, prompt engineering, RAG
подтвержденный опыт разработки и внедрения AI-решений
Смотришь другую вакансию — уже Team Lead LLM Engineer. А там:
создание и развитие RAG-систем, включая Agentic RAG
observability для агентов
сервисы обработки документов
организация разметки данных
дообучение мультимодальных моделей
LLM-as-a-Judge и quality pipelines
вывод моделей и сервисов в production
Проблема в том, что под одним и тем же названием компании часто описывают совершенно разные роли.
Где-то под LLM Engineer реально подразумевается человек, который работает с моделями как с объектом исследования и улучшения: оценка (evals), промптинг, fine-tuning, data curation, quality loops, иногда даже инференс и serving.
А где-то под тем же названием ищут обычного сильного прикладного инженера, который должен собирать AI-функции в продукте: RAG, агенты, интеграции, пайплайны, наблюдаемость (observability), безопасность, продакшен-уровень.
А иногда компания просто ищет единорога, который одновременно умеет:
тренировать и дообучать модели
строить RAG и агентные системы
делать evals
поднимать production-инфраструктуру
выстраивать MLOps
а в идеале еще и оптимизировать инференс
Естественно, когда бэкенд- или фуллстэк-разработчик, который хочет перейти в прикладной ИИ (applied AI), читает такую вакансию, у него быстро появляется мысль: «я вообще не подхожу».
И это часто ложное ощущение.
Где проходит граница
Проблема рынка в том, что названия ролей пока не устоялись. Но на практике полезно различать хотя бы два типа задач.
LLM Engineer
Это роль ближе к работе с самими моделями и качеством их поведения.
Обычно сюда попадает:
выбор и сравнение моделей
построение evals (оценки)
prompt engineering как системная дисциплина, а не просто подбор промптов
эксперименты с quality loops
работа с fine-tuning или post-training
участие в проектировании AI-архитектуры на уровне поведения модели и ее качества
Для такой роли действительно полезны:
хороший кругозор в NLP и LLM
понимание того, как устроены современные модели
умение читать статьи, документацию и разбирать бенчмарки
привычка много экспериментировать и валидировать гипотезы
AI Engineer / Applied AI Engineer
Это прикладная разработка: создание ценности для продукта с помощью уже существующих моделей и инструментов.
Обычно сюда относится:
AI-функции внутри продукта
tool calling
RAG
агенты и их оркестрация
интеграции с внешними системами
оценка (eval) и наблюдаемость (observability) на уровне приложения
надежный продакшен-код вокруг моделей
Здесь важнее другое:
умение строить сервисы
понимать ограничения LLM и не ломать продукт об эти ограничения
уметь отлаживать качество: проблема в данных, retrieval, prompt, tool use или модели
уметь доводить систему до продакшена, а не просто собирать демо
И вот здесь важный тезис: во многих вакансиях под названием LLM Engineer на самом деле ищут именно AI Engineer. То есть разработчика с сильной бэкенд- или фуллстэк-базой, который умеет применять LLM в реальных системах.
Как могут выглядеть вменяемые требования к AI Engineer
Например, так:
уверенное владение Python или TypeScript
умение писать чистый код, тесты и поддерживаемые сервисы
базовое понимание LLM: токены, контекст, temperature, top-p, ограничения по длине контекста
опыт промптинга моделей: шаблоны, few-shot, structured output, tool/function calling
опыт разработки RAG-систем и работы с векторными хранилищами
опыт интеграции LLM в сервисы
понимание Docker и контейнеризации
навыки диагностики качества и производительности AI-сервисов
базовое понимание безопасности и ограничений при работе с LLM
Как видно, тут нет обязательного требования знать Transformer на уровне LLM-инженера/исследователя, заниматься fine-tuning, строить MLOps-платформу или разбираться в CUDA.
И это нормально.
Что с этим делать
У меня здесь два простых совета.
Рекрутерам и нанимающим менеджерам
Если вам нужен прикладной инженер, который будет встраивать ИИ в продукт, так и пишите.
Не называйте вакансию LLM Engineer только потому, что это звучит модно. Чем точнее вы обозначите границы роли, тем лучше будет воронка:
меньше нерелевантных откликов
меньше самоотсечения хороших кандидатов
выше шанс быстрее закрыть позицию
Не стоит искать единорога там, где на самом деле нужен сильный инженер-разработчик с хорошим продуктовым и системным мышлением.
Разработчикам, которые хотят перейти в Applied AI
Не отбрасывайте вакансию только потому, что в ней в одну кучу свалены RAG, агенты, evals, дообучение, observability и MLOps.
Очень часто это просто плохо написанное описание, а не реальный список того, чем вы будете заниматься каждый день.
Поэтому:
уточняйте на первом же созвоне, что реально входит в зону ответственности
показывайте пет-проекты и рабочие кейсы
рассказывайте не только про «я пробовал ChatGPT», а про реальные инженерные задачи
не думайте, что без опыта в ML/LLM вам закрыт путь в ИИ разработку
Для входа в прикладной ИИ (applied AI) не обязательно быть исследователем. Во многих случаях достаточно хорошей инженерной базы и нормального понимания того, как LLM ведут себя в реальных системах.
Рынок еще долго будет путаться в названиях. Но это не значит, что в него нельзя зайти.
P.S. Про разработку в эпоху ИИ, агентов и LLM 👉🏻 тут