В 2026 году технологические компании, банки и крупный enterprise массово открывают позиции, связанные с языковыми моделями. На hh.ru и в Telegram-каналах с вакансиями регулярно появляются LLM Engineer, ML Engineer, AI Engineer, AI Architect — и все они нередко описаны почти одинаково. Проблема не в количестве вакансий, а в том, что одно и то же название скрывает принципиально разные роли.
Для примера: одна вакансия Senior LLM Engineer требует два года коммерческой разработки на Python, опыт с LangChain, LlamaIndex и RAG. Другая — уже Team Lead LLM Engineer — включает дообучение мультимодальных моделей, LLM-as-a-Judge, quality pipelines, observability для агентов и вывод моделей в production. Формально обе называются одинаково, но по содержанию это разные профессии.
| Критерий | LLM Engineer | AI Engineer / Applied AI Engineer |
|---|---|---|
| Фокус работы | Модели как объект исследования и улучшения | Встраивание LLM в продукт и сервисы |
| Типичные задачи | Evals, fine-tuning, prompt engineering как дисциплина, сравнение моделей | RAG, агенты, tool calling, интеграции, observability, продакшен-код |
| Ключевые навыки | Кругозор в NLP, чтение статей и бенчмарков, эксперименты | Строить сервисы, диагностировать качество, доводить до production |
| Нужен ли опыт с Transformer / CUDA | Желателен | Не обязателен |
| Нужен ли MLOps | Частично | Базовое понимание Docker и контейнеризации |
На практике полезно разделить рынок на два типа ролей. Первый — LLM Engineer в узком смысле: человек, который работает с самими моделями как объектом исследования. Его задачи — выбор и сравнение моделей, построение системы оценки (evals), prompt engineering как дисциплина, эксперименты с fine-tuning и post-training, участие в проектировании AI-архитектуры на уровне поведения модели. Для такой роли нужен кругозор в NLP, умение читать исследовательские статьи и разбирать benchmark-результаты.
Многие вакансии требуют fine-tuning, MLOps и CUDA там, где реально нужен бэкенд-разработчик с пониманием RAG и агентов.
Второй тип — AI Engineer или Applied AI Engineer. Это прикладная разработка: встраивание языковых моделей в реальный продукт. Сюда относятся RAG-системы, агенты и их оркестрация, tool calling, интеграции с внешними сервисами, observability на уровне приложения и надёжный продакшен-код вокруг моделей. Здесь важнее умение строить сервисы, диагностировать качество и доводить систему до production, а не знание архитектуры Transformer на уровне исследователя. Требования к такой роли выглядят иначе: уверенный Python или TypeScript, понимание токенов, контекста и ограничений LLM, опыт с векторными хранилищами, Docker и базовая безопасность при работе с моделями.
Ключевой тезис: большинство вакансий с названием LLM Engineer на российском рынке фактически описывают именно AI Engineer. Компании ищут сильного прикладного разработчика с бэкенд- или фуллстэк-базой, который умеет применять LLM в реальных системах — но пишут требования так, будто нанимают ML-исследователя. Результат предсказуем: бэкенд-разработчик, готовый перейти в прикладной ИИ, читает список из RAG, агентов, evals, дообучения и MLOps и решает, что не подходит. Это ложное ощущение.
Для нанимателей вывод простой: если нужен инженер, который встраивает ИИ в продукт, стоит так и писать. Точная формулировка зоны ответственности сокращает нерелевантные отклики, снижает самоотсечение подходящих кандидатов и ускоряет закрытие позиции. Поиск «единорога», совмещающего тренировку моделей, RAG, MLOps и оптимизацию инференса, оправдан только если такой специалист действительно нужен каждый день.
Разработчикам, которые рассматривают переход в прикладной ИИ, имеет смысл не отбрасывать вакансию из-за перегруженного описания, а уточнять на первом же созвоне реальную зону ответственности. Показывать стоит конкретные инженерные кейсы и пет-проекты, а не общие слова про использование ChatGPT. Рынок ещё долго будет путаться в названиях — но это не закрывает вход в отрасль для тех, у кого есть инженерная база и понимание того, как LLM ведут себя в реальных системах.
