|
Professor Seleznov
|
В 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 👉🏻 тут-Источник
|
