Как внутренний транскрибатор стал основой направления прикладного ИИ в компании
Час пользовательского тестирования электромобиля редко ограничивается одним часом работы. Пока участник выполняет задания, оценивает интерфейс и отвечает на вопросы исследователя, команда записывает происходящее на аудио и видео. После завершения сессии начинается не менее трудоемкий этап - расшифровка записи, поиск важных наблюдений и подготовка выводов.
Один тест может потребовать несколько часов ручной работы. Если участников много, объем материала быстро превращается в десятки часов аудио. При этом исследователю необходимо не просто перевести речь в текст, а выделить моменты, когда пользователь не понял сценарий, столкнулся с ошибкой, начал сомневаться или предложил улучшение.
Меня зовут Майя Азарова. Раньше я руководила исследованиями пользовательского опыта цифровых сервисов, а сейчас отвечаю за направление прикладного использования искусственного интеллекта в компании "Атом". В этой статье расскажу, как попытка автоматизировать расшифровку интервью превратилась в полноценный внутренний продукт и затем стала отправной точкой для развития корпоративных ИИ-сервисов.
Почему расшифровка стала проблемой
При разработке электромобиля "Атом" проводится большое количество исследований: тестируются интерфейсы, сценарии взаимодействия с автомобилем, поведение водителя и пассажиров, реакции пользователей в движении и в статичных условиях. За эти процессы отвечает отдельная команда HMX.
Каждое интервью или юзабилити-тестирование оставляет после себя объемный медиаматериал. Записи нужны не только для текущего анализа. Со временем они могли бы стать базой знаний компании - источником реальных пользовательских наблюдений, решений и аргументов.
Но без текстовой расшифровки такие материалы быстро теряют практическую ценность. Мало кто станет пересматривать 10-15 часов видео в поисках одной фразы о непонятной кнопке или неудачном сценарии. Текст позволяет искать информацию, сопоставлять ответы участников и быстрее переходить от записи к выводам.
До появления собственного решения использовались три основных подхода.
Бесплатные онлайн-сервисы казались удобными, однако у них были ограничения на размер файлов и продолжительность обработки. Кроме того, оставался открытым вопрос: где хранятся записи внутренних исследований и кто может получить к ним доступ.
Коммерческие платформы обеспечивали более предсказуемое качество и понятные условия хранения данных. Однако они формировали постоянные расходы и создали зависимость от внешнего поставщика. Изменение тарифа, правил использования, функциональности или доступности сервиса могло повлиять на весь рабочий процесс.
Ручная расшифровка и локальный запуск моделей также не были универсальным выходом. Ручной труд слишком дорог для квалифицированного исследователя, а самостоятельное развертывание ИИ-модели требует технических компетенций и времени, которых у продуктовой команды обычно нет.
Сначала компания использовала готовые решения, но затем оценила совокупные затраты, риски зависимости и требования к работе с внутренними данными. Так появилась идея собрать собственный прототип.
Прототип, который быстро стал востребованным
Первая версия была предельно простой. Она решала одну задачу: принимала запись и превращала речь в текст. Но уже вскоре выяснилось, что подобная потребность есть не только у UX-исследователей.
Инструмент оказался полезен всем, кто проводит интервью, тестирования, встречи или анализирует пользовательские обращения. Число пользователей росло, а вместе с ним увеличивалось количество запросов на новые функции.
Проблема заключалась в том, что прототип создавался как временное решение. Его архитектура подходила для проверки идеи, но не для масштабирования. Каждое улучшение требовало обходных решений, а добавление новых сценариев становилось все сложнее.
Летом 2025 года было принято решение превратить инструмент в полноценный продукт. Важным условием стало участие будущих пользователей в формировании требований. Техническое задание готовили сами исследователи - люди, которые должны были работать с сервисом ежедневно.
Это решение значительно сократило разрыв между разработкой и реальными потребностями бизнеса. Вместо абстрактного набора функций команда получила описание конкретных рабочих сценариев: загрузки файлов, поиска по расшифровкам, разделения спикеров, корректировки текста и подготовки материалов для анализа.
Ограниченные ресурсы и короткий цикл разработки
Ресурсы на запуск были ограничены, поэтому команда формировалась под конкретный срок и заранее определенный набор возможностей. Первую рабочую версию удалось выпустить примерно за три месяца.
Однако запуск не означал завершения проекта. Еще около трех месяцев ушло на стабилизацию сервиса, составление внутренних чек-листов и прохождение согласований. Именно этот этап оказался наиболее неожиданным.
Для обычных корпоративных продуктов процедура выхода в промышленную эксплуатацию обычно понятна: существуют требования по безопасности, инфраструктуре, хранению данных и сопровождению. ИИ-сервис оказался сложнее, поскольку часть критериев контроля еще только формировалась.
Некоторые правила появлялись одновременно с процессом проверки. Команда могла подготовить документацию по действующим требованиям, а затем столкнуться с новыми вопросами, которые возникали уже в ходе согласования. Это не было следствием чьей-то ошибки - внутренние процессы просто не успевали развиваться с той же скоростью, что и технологии.
В результате оценить срок "до прода" традиционными методами было трудно. Разработка могла завершиться вовремя, но выпуск зависел от дополнительных требований к данным, модели, журналированию запросов, контролю доступа и оценке качества результатов.
Что важно учитывать при создании ИИ-продукта
Опыт с транскрибатором показал: ИИ-сервис нельзя рассматривать как обычное приложение с подключенной моделью. Помимо интерфейса и серверной части приходится заранее продумывать целый набор дополнительных вопросов.
Во-первых, необходимо определить, какие данные разрешено обрабатывать. В интервью могут встречаться персональные сведения, коммерческая информация и детали еще не опубликованных разработок. Поэтому важны правила загрузки, хранения, удаления и предоставления доступа к материалам.
Во-вторых, нужно заранее описать ответственность за результат. Автоматическая расшифровка может ошибаться, путать имена, термины и реплики разных участников. Следовательно, текст должен восприниматься как инструмент ускорения работы, а не как безусловно точная стенограмма.
В-третьих, требуется оценивать не только качество модели, но и пользу для процесса. Для исследователя важна не абстрактная точность распознавания, а возможность быстрее найти нужный фрагмент, сформировать наблюдения и подготовить отчет.
Отдельная задача - удобство исправлений. Пользователь должен иметь возможность быстро корректировать ошибки, отмечать спорные места и сохранять итоговую версию без сложного ручного редактирования.
Также полезно закладывать наблюдаемость с самого начала: время обработки, долю ошибок, частоту повторных загрузок, наиболее востребованные функции и причины отказов. Такие данные помогают понимать, что именно нужно улучшать, а не опираться только на субъективные отзывы.
Почему транскрибатор стал началом большего направления
Изначально задача выглядела локальной: избавить исследователей от ручной расшифровки. Но в процессе стало очевидно, что такой сервис создает общую платформу для множества прикладных сценариев.
На его основе можно развивать автоматическое резюме интервью, выделение тем, поиск повторяющихся проблем, сравнение ответов разных групп пользователей и подготовку структурированных отчетов. Следующим шагом может стать интеграция с корпоративной базой знаний, чтобы результаты исследований не оставались в отдельных папках и документах.
Кроме того, транскрибатор помог компании накопить компетенции, необходимые для других ИИ-проектов: оценки моделей, защиты данных, организации доступа, проверки качества и сопровождения решений после запуска.
Главный вывод оказался простым: наиболее перспективные ИИ-продукты часто начинаются не с масштабной стратегии, а с конкретной рабочей боли. Если проблема регулярно отнимает время у специалистов и имеет понятный измеримый результат, она может стать хорошей точкой входа для автоматизации.
При этом не стоит пытаться сразу построить универсальную платформу. Гораздо эффективнее выбрать один сценарий, проверить его на реальных пользователях, измерить эффект и только после этого расширять решение.
В случае с транскрибатором таким эффектом стало сокращение рутинной работы исследователей и ускорение анализа тестов. А главным результатом - появление внутри компании устойчивого направления прикладного ИИ, ориентированного не на демонстрацию возможностей моделей, а на решение ежедневных задач бизнеса.
