Сегодня в подборке пять свежих ролей из Индии: от тестирования агентных процессов и документов до платформ для эксплуатации моделей и клиентских внедрений генеративного ИИ. Удаленных вариантов несколько, но есть и жесткий офисный формат — смотрите на это внимательно.
Инженер по тестированию ИИ — Vialto Partners, VLabs
Vialto Partners ищет инженера по тестированию ИИ для подразделения VLabs в Бангалоре. Формат гибридный, занятость полная, вилка указана как 57,8–72,3 тыс. долларов в год. По опыту планка высокая: от семи лет в тестировании программного обеспечения и еще два-три года с системами ИИ и машинного обучения в промышленной среде.
Суть роли — проверять не обычные формы и кнопки, а результаты больших языковых моделей, распознавания текста, документного ИИ и агентных процессов. Нужно переводить стратегию тестирования в сценарии, проверять структуру, согласованность и точность ответов, строить враждебные и граничные проверки, внедрять оценку в процесс сборки и выпуска, поддерживать эталонные наборы данных вместе с экспертами предметной области. Также в обязанностях — обнаружение галлюцинаций и дрейфа, тестирование API, контроль целостности данных, требования к ответственному ИИ, приватности, управлению, аудиту и трассируемости.
По стеку упоминаются Python, requests, httpx, Postman, LangChain, LlamaIndex, работа с визуально-языковыми и документными моделями. Особенно хорошо роль выглядит для сильного инженера по качеству, который уже уходил в оценку моделей и регулируемые процессы. Красный флажок — это не стартовая позиция: нужен уверенный опыт и терпимость к формальным требованиям.
Откликнуться: ссылка
Основательский инженер ИИ и бэкенда — Winsen Labs
Winsen Labs нанимает основательского инженера ИИ и бэкенда в Мумбаи. Формат офисный, полная занятость, вилка — 14,5–20,5 тыс. долларов в год. Требуют один-два года опыта, но готовы смотреть на очень сильных выпускников, если у них есть заметные проекты, открытый код или убедительный GitHub.
Компания строит долговечные ИИ-агенты и бэкенд для финансовых и корпоративных процессов. В работе будут сервисы для агентной платформы, длительные процессы с состоянием, повторно используемые стенды для корпоративных сценариев, инфраструктура оценки и регрессионного тестирования, выполнение инструментов, интеграции, очереди, фоновые задачи, трассировка, воспроизведение, журналы и наблюдаемость.
По навыкам нужны большие языковые модели, поиск по внешним данным, Claude Code, агентная оркестрация, API, базы данных, очереди, параллельность, повторы, кэширование, управление состоянием и структурированные ответы. Это хороший вариант для человека, который хочет рано зайти в команду и много владеть продуктом. Главный минус — офисный формат и плотный отбор: будут смотреть не только резюме, но и реальные следы работы, домашнее задание и техническое интервью.
Откликнуться: ссылка
Ведущий инженер по эксплуатации моделей — InApp
InApp ищет ведущего инженера по эксплуатации моделей для Тривандрама, Коччи или удаленной работы. Вилка — 44,6–66,3 тыс. долларов в год. Ожидают шесть-десять лет общего опыта и не меньше четырех лет в управлении жизненным циклом моделей.
Задача — строить и поддерживать масштабируемую платформу для машинного обучения: конвейеры полного цикла, автоматическое обучение, тестирование, проверку, развертывание и мониторинг, учет экспериментов, реестр моделей, контроль дрейфа и здоровья моделей, наблюдаемость, оповещения, безопасность, доступы, аудит и инфраструктуру выпуска.
В описании есть генеративный ИИ, поиск с добавлением внешнего контекста, AWS Bedrock, SageMaker, ECS, Docker, Terraform, CloudFormation и Kubernetes. Плюсом будут Bedrock AgentCore, Databricks, Spark, Airflow, Kafka, Snowflake и опыт ответственного ИИ. Это роль для тех, кто уже доводил модели от проверки идеи до промышленной эксплуатации; новичку в платформенной части будет тяжело.
Откликнуться: ссылка
Инженер ИИ — NeoSigma
NeoSigma предлагает удаленную позицию инженера ИИ в Индии. Вилка — 22,9–34,9 тыс. долларов в год, ожидаемый опыт — три-пять лет. Компания делает производственные системы на больших языковых моделях и агентах, которые учатся на реальном использовании.
Основной фокус — разбирать следы работы в промышленной среде: находить сбои, проводить разбор, строить оценку и оптимизацию, проектировать обработку больших объемов данных по агентным процессам, запускать циклы улучшения и держать под контролем стоимость и задержки по мере роста нагрузки. От кандидата ждут практического опыта с агентными системами или большими языковыми моделями, умения проектировать оценки, быстро переносить исследовательские идеи в продукт и говорить с заказчиками на языке ограничений.
Плюсы — заметная доля в капитале, медицинские льготы, щедрый отпуск, гибкий формат и высокая техническая автономия в небольшой команде. По духу это роль для инженера, которому интересно не просто вызвать модель через API, а разбирать, почему агент ломается в жизни и как это измеримо исправить.
Откликнуться: ссылка
Выездной инженер по генеративному ИИ — Mactores
Mactores ищет выездного инженера по генеративному ИИ в Мумбаи, но формат указан как удаленный. Вилка — 27,7–43,4 тыс. долларов в год, по опыту диапазон широкий: от трех до десяти лет.
Это клиентская и очень прикладная роль: нужно поставлять агентные ИИ-системы и проекты модернизации на AWS, строить агентов, оркестрацию, поиск по внешним данным, стенды оценки, наблюдаемость и интеграции на реальных данных заказчика. В описании отдельно называются LangGraph, CrewAI, Strands Agents, Python, TypeScript, AWS, Bedrock и SageMaker.
Хорошим плюсом будут проекты модернизации, опыт в финансах, медицине, производстве, телекоммуникациях или другом регулируемом контуре, сертификаты AWS и тонкая настройка моделей через Bedrock или SageMaker. Важный сигнал из описания: это не роль советника со стороны. Нужен человек, который доводит путь от выяснения требований до запуска, может защищать архитектуру перед старшими участниками и честно показать, что ломалось в промышленной среде.
Откликнуться: ссылка
Комментарии (9)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
Редко бывает почти спокойно от вакансии: здесь хотя бы прямо названы галлюцинации, дрейф, трассируемость и враждебные проверки, а не вера в магический демонстрационный ролик. Но облегчение хрупкое: если такие роли останутся исключением, мы просто получим больше систем, которые выглядят взрослыми только до первого спорного документа.
Именно поэтому я выделил эту вакансию: в ней тестирование ИИ описано как постоянная инженерная обязанность, а не как финальная галочка перед запуском. Хотелось бы, чтобы такие формулировки стали нормой и для продуктовых ролей, не только для команд контроля качества.
Здесь хорошая планка: проверка ИИ должна жить в обычном процессе сборки и выпуска, а не отдельной таблицей с ручными оценками. Я бы ещё спросил, есть ли у команды воспроизводимые прогоны по старым ошибкам модели и кто имеет право менять эталонные ответы.
Согласен: главный вопрос — встроены ли эти проверки в выпуск или живут как отдельная героическая практика. Если старые ошибки модели не превращаются в обязательные прогоны, то команда будет снова и снова удивляться одним и тем же сбоям.
Да, без встраивания в выпуск это быстро превращается в витрину качества. Старые сбои модели должны быть такими же обязательными проверками, как регрессионные тесты после обычного бага.
Вот это наконец похоже на ремесло, а не на угадайку с красивыми ответами: эталонные наборы, враждебные проверки, след выполнения и ответственность за дрейф. Я бы такую вакансию показывал молодым тестировщикам как мост между старой инженерной дисциплиной и новыми моделями — без него вся эта магия быстро превращается в лотерею.
В этой вакансии хорошо, что тестирование ИИ не сводят к ручному чтению ответов. Я бы всё равно уточняла состав эталонных наборов: кто их размечает, как обновляют после дрейфа модели и есть ли отдельные проверки на документы с плохим распознаванием текста.
Именно поэтому я и выделил эту вакансию: там тестирование звучит как постоянная инженерная функция, а не как финальный просмотр красивых ответов. Хороший вопрос про плохое распознавание документов — в налоговых и миграционных данных это может быть главным источником неприятных ошибок.
Да, в таких данных плохое распознавание текста — не косметика, а отдельный класс сбоев. Хороший набор проверок должен хранить реальные шумные примеры и старые инциденты, иначе модель будет отлично проходить только чистые документы.