Всем привет! Меня зовут Артём Матюшечкин, я менеджер разработки из команды Толк.ИИ в продукте Контур.Толк — это сервис для общения и работы. Наша команда сделала суммаризацию, обновила и ускорила сегментацию виртуальных фонов, внедрила шумоподавление в продукт. В этой статье поделюсь опытом управления такой командой, которая пыталась одновременно уместить в себе требования бизнеса и технологий.
Представьте себе «сферического коня в вакууме» — технологию вроде распознавания речи или сегментации фона. У неё есть:
-
технические метрики (бенчмарки),
-
рабочие стенды,
-
примеры использования.
Но как превратить это в реальную пользу для клиента и бизнеса?
Тут в игру вступает наша команда — Толк.ИИ. Команда мультифункциональная, чтобы работать максимально автономно, в ней есть продакт, аналитик, дизайнер, фронтендер, бэкендер, тестировщик и дата-сайентист. На первый взгляд, ничего сложного и довольно стандартно.
Почему управлять такой командой — трудная задача?
DS-инженеры живут в мире исследований, экспериментов и долгосрочных циклов. Они умеют глубоко погружаться в модель, оптимизировать её месяцами и годами. Благодаря этому появляются GPT, DeepSeek, Qwen и другие инновации.
Но когда за спиной стоит бизнес со своими ожиданиями, сроками и требованиями — возникает напряжение (несовпадение взаимных ожиданий) между мирами исследований и реализации.
И между ними — ваша команда. И задача — не просто «перевести» одно в другое, а создать процесс, в котором обе стороны достигают целей.
Вот два ключевых вопроса, которые я задал себе
Вопрос 1. Нужно ли знание ИИ, чтобы управлять ИИ-командой?
Ответ: Да, но не обязательно быть экспертом в математике или погружаться в код модели.
Важнее понимать:
-
что такое обучение, эксперимент, инференс;
-
базовые области: LLM, NLP, ASR, CV;
-
как эти технологии могут влиять на продукт.
Не знать, как выводить формулу из статьи по конференции NeurIPS, но зато понимать, зачем команда делает то, что делает, и как это связано с бизнес-целями.
Что можно сделать для этого:
-
организовать обучение: курсы, подкасты, внутренние доклады;
-
задавать правильные вопросы: «Зачем мы сейчас оптимизируем точность на 2%, если пользователь этого не заметит?».
Цель — не сделать из всех экспертов, а дать достаточно контекста, чтобы команда могла принимать осознанные решения.
Вопрос 2. Как управлять такими проектами?
Рассмотрим на примере двух кейсов.
Кейс 1. Большая задача, высокая неопределённость.
Ситуация:
-
Поступила задача сделать сегментацию изображений для виртуального фона в Толке. Обычно сегментация используется для того, чтобы выделить объекты и границы (линии, кривые) на изображениях. В нашем случае нужно было выделить силуэт человека.
-
Не было чётких требований — нужно было просто сделать хорошо (что такое хорошо? как это понять?).
-
Команда только начинала работу (что происходит? где мы?).
-
ML-лаборатория уже провела длительное исследование, и подготовила модель с ожидаемо более высоким качеством.
-
За месяц до релиза выяснилось, что модель не готова, точнее готова, но качество такое же, как и в существующем в Толке решении от Google MediaPipe.
Что произошло:
-
Технические метрики модели соответствовали минимальным требованиям.
-
Продуктовые метрики — отсутствовали, потому что ими не занимались.
-
Обе команды не понимали, как модель повлияет на пользовательский опыт. Плюс фича не влияла на критический путь пользователя.
Что мы сделали:
1. Уточнили критерии успешного релиза.
Собрали все ожидания: от ML-инженеров, бизнеса и пользователей.
2. Приняли решение запускать MVP.
Модель была не идеальной, но давала первый опыт взаимодействия.
3. Собрали пирамиду метрик.
Определили, какие показатели важны: скорость работы, качество сегментации, удовлетворённость пользователей.
4. Сменили фокус: стало ясно, что нужно улучшать не модель, а её инференс.
Занялись оптимизацией инфраструктуры, распределением нагрузки между CPU/GPU.
Что нам это дало:
-
первые данные о поведении модели в реальных условиях;
-
гипотезы влияния ИИ-фичи на продукт;
-
возможность планировать следующие этапы развития.
В результате мы успешно внедрили фичу, получили обратную связь и собрали бэклог развития.
Кейс 2. Рост масштаба и сложности внедрения ИИ-фич.
Ситуация:
-
Команда уже внедрила несколько ИИ-фич.
-
Процессы наладились.
-
Появилось больше технологий: распознавание речи, разделение говорящих, шумоподавление, суммаризация и так далее.
-
Ожидания от качества и скорости начали расти.
Проблема:
-
Как правильно сформулировать требования к новым или существующим моделям?
-
Как понять, что действительно важно улучшать?
-
Какие новые технологии использовать: DeepSeek, Dify или что-то ещё?
Что помогло:
-
Мы пригласили ML-разработчика в команду. Не как внешнего эксперта, а как полноценного члена. Раньше всю информацию о технологиях мы получали только от отдельной команды ML-лаборатории, а теперь в команде есть объединенная экспертиза.
-
Он стал «узлом компетенции» и помогает:
– оценивать качество моделей;
– проверять актуальность новых решений;
– планировать roadmap ИИ-направления;
– участвовать в постановке целей и OKR.
Результат:
-
Продакт и аналитик начали лучше понимать, что возможно, а что нет.
-
Команда получила инструмент для валидации идей.
-
Появилась способность быстро оценивать новые технологии и принимать решения.
Практические рекомендации по управлению ИИ-командой
1. Управляйте коммуникацией.
-
ML-разработчики часто сосредоточены на своих исследованиях. Ваша задача — обеспечить обратную связь и понимание общей цели.
-
Не допускайте «накопленной недоговорённости». Обсуждайте всё: от метрик до ожиданий от релиза.
2. Формулируйте требования.
-
Избегайте крайностей: слишком общие или слишком жёсткие формулировки одинаково опасны. Приведу примеры по обоим вариантам.
Общие. Например, нужно понять, что люди делают на видео во время видеоконференции. Цель: собрать датасет для тестирования качества модели виртуального фона.
И тут сразу возникают вопросы:
-
Какие это действия? Не определён список целевых действий (человек сидит, бежит, поднимает руку, закатывает глаза).
-
В каком контексте? Один человек в кадре или много? Реальное время или обработка архивов?
-
Что на выходе? В датасете нужна разметка всего видео или таймстампы для каждого действия.
Жёсткие. Например, на видео в реальном времени нужно сделать кожу человека гладкой как пластик, чтобы цвет был идеально ровным, убрать все морщины, увеличить глаза на 15%.
И сразу возникают вопросы:
-
Потеря текстуры и естественности: «Абсолютно гладкая кожа» и «идеально ровный цвет» уничтожают все текстуры, делая человека похожим на восковую фигуру?
-
Единые проценты для всех? Увеличение глаз на 15% и сужение лица на 10% для каждого человека будет выглядеть неестественно, особенно на людях с крупными чертами.
-
Игнорирование индивидуальности: алгоритм не адаптируется к уникальным чертам лица.
-
Лучше всего работают гибкие требования с возможностью корректировки на основе данных.
3. Распределяйте ответственность.
-
Чётко разграничьте зоны ответственности внутри команды и между командами.
-
Убедитесь, что ML-разработчик не работает в одиночку, а встроен в общий процесс.
4. Развивайте контекст в команде.
-
Давайте ресурсы для обучения, организуйте внутренние демо, обсуждения.
-
Связывайте ИИ-задачи с бизнес-метриками: «Это улучшение повысит NPS на X%» — гораздо мощнее, чем «точная сегментация фона».
5. Приносите обратную связь от пользователей в команду. «Спасибки» всегда мотивируют, а критика заставляет задуматься, что ещё можно улучшить.
Заключение
Работа с ИИшной-командой — это не только про «внедрить технологию», но и про выстраивание процессов, управление неопределённостью, настройку коммуникации и принятие решений в условиях ограниченных данных.
Ваша роль как менеджера команды — не становиться ИИ-экспертом, а создать среду, в которой эксперты могут работать эффективно и приносить реальную пользу продукту.
Делитесь в комментариях своими лайфхаками работы со сложными технологиями, а ещё расскажите, был ли опыт управления подобной командой, как у меня. 🙌
Автор: Artem_Matyushechkin
