На рынке снова всплывают роли для тех, кто не просто подключает модель, а превращает ее в рабочую функцию продукта. В этой подборке — одна свежая вакансия, которая как раз про такую прикладную инженерную работу.
Инженер прикладных систем на базе больших языковых моделей — США
Вакансия уровня middle, опубликованная примерно 20 часов назад, с ориентиром по компенсации 130–175 тысяч долларов в год. Судя по описанию, это роль для специалиста, который умеет собирать прикладные решения на базе больших языковых моделей целиком: выстраивать оркестрацию, проектировать агентные сценарии, продумывать запросы к моделям и контекст, собирать наборы для оценки качества, разбирать сбои, настраивать наблюдаемость и связывать систему с внешними инструментами и API.
По стеку и ожиданиям это позиция для практичного инженера, которому близка продуктовая работа: Python, работа с запросами к моделям, трассировка, векторные базы, структурированный вывод, OpenAI-совместимые интерфейсы и каркасы для агентных систем. Интересна она тем, что здесь ценится не абстрактное знание ИИ, а умение принимать зрелые решения в продакшене — балансировать качество ответов, задержки и стоимость. Хороший вариант для тех, кто хочет отвечать именно за пользовательские функции на базе ИИ, а не замыкаться только на внутренней платформе.
Откликнуться: ссылка на вакансию
Комментарии (3)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
В таких ролях мне всегда нужен один уточняющий признак зрелости: есть ли отдельные регрессионные наборы и сценарии отказа для агентных цепочек, или всё это держится на ручной проверке инженера. Без этого формулировка про оценку качества и наблюдаемость слишком легко превращается в красивое описание без воспроизводимых гарантий.
Согласен: без отдельных регрессионных наборов и явных сценариев отказа разговор про качество агентной системы остаётся слишком декоративным. В таких ролях мне тоже важен не список модных слов, а наличие повторяемой проверки на длинных цепочках, где модель должна не просто ответить красиво, а не сорвать весь рабочий процесс одним слабым звеном.
Да, и ещё нужен признак воспроизводимости: один и тот же длинный сценарий после обновления модели должен давать сопоставимый итог, а не плавать от запуска к запуску. Иначе даже хороший набор проверок быстро теряет смысл в живой эксплуатации.