Тихий клиент на АЗС: как собрать сессию обслуживания из архивных записей штатных камер и микрофонов

Дано: сеть из нескольких сотен АЗС. Визуальный аудит качества обслуживания и сервиса (проверяется соблюдение скриптов, стимулирование дополнительных продаж и установок приложения) покрывает несколько процентов смен, остальное не просматривается. Наш клиент хотел увидеть, что происходит в те моменты, которые упущены из виду. Важно: система должна работать на действующих камерах и микрофонах без всякой доукомплектации. Задача: брать архивные записи, автоматически выделять сессии обслуживания и проверять их по чек-листу.

Кассир у микрофона говорит громко и развернутыми фразами. Клиент отвечает коротко, тихо, иногда просто кивает. Стандартный ASR-пайплайн сталкивается с суровой реальностью: в транскрипции остаётся монолог кассира с пропусками там, где отвечал клиент.

Начали с видео. 

Одного канала мало

Сначала проверяли, можно ли обойтись одним аудио: прогнать поток через ASR и искать ключевые фразы. Система слышит “здравствуйте”, но у кассы может стоять несколько человек, кто-то из персонала разговаривает с коллегой или курьером, и приветствие не получается закрепить за конкретной клиентской сессией.

Одного видео тоже недостаточно. Камера видит, что клиент простоял у кассы 40 секунд, а предложил ли кассир кофе или приложение — уже нет. Читать это по жестам с существующих камер под таким ракурсом ненадежно.

Поэтому выбрана двухмодальная архитектура: видео дает хронологию сцены и роли, аудио — содержание диалога, сессия собирается после синхронизации обоих потоков.

Видеомодуль: роли и удержание ID

Видеомодуль начинается с разделения людей в кадре по ролям: клиент, кассир, стажер, заправщик. Классов четыре, потому что у каждой роли своя зона перемещения и своя ответственность в чек-листе. Стажера первые 14 дней вообще не оценивают, это требование заказчика, маркер стажера виден визуально — браслет, нагрудный знак.

Стандартные веса детектора не подошли. Кассир и стажер визуально похожи, заправщик выглядит как сотрудник, но работает в другой зоне кадра. Обучали детектор на прикладных классах, на реальных данных с АЗС.

Вторая задача видеомодуля — удержать ID клиента на протяжении всей сессии. Клиент на секунду перекрывается стойкой или витриной, трекер открывает новый ID, одна сессия распадается на две. Бизнес-метрики при этом ломаются: система фиксирует “две сессии без приветствия” вместо одной корректной. 

Для ReID использовали визуальные эмбеддинги, пороги дорабатывали под конкретный ракурс камеры — на каждой станции он свой. Сверху два ограничения: одновременно существующие треки не могут делить один ID, а вход нового трека в ROI кассовой зоны проверяется зональным гейтингом, чтобы случайный человек на периферии кадра не открывал сессию.

ROI кассовой зоны задаётся вручную под планировку каждой станции. Конфигурация хранится отдельно от кода — это позволяет переносить модель на новую АЗС без переобучения, меняя только разметку зон.

Тихий клиент

Типичный диалог на кассе:

[кассир, громко] Здравствуйте, кофе в дорогу?

[клиент, тихо] нет

[кассир] Какая колонка?

[клиент, тихо] девятая

[кассир] Скачайте приложение

[клиент, очень тихо] нет

[кассир] С вас 1894. Картой?

[клиент] (кивает)

Кассир говорит близко к микрофону, длинными фразами, с высоким уровнем сигнала. Клиент — короткими ответами меньше секунды, на несколько децибел тише. Стандартный VAD настроен не пропускать шум. В условиях шумов от холодильников, кофемашины и кассового оборудования тихая реплика клиента акустически не отличается от фона.

Первый прогон через базовые ASR-модели это подтвердил. Речь кассира распознавалась нормально. Клиент терялся систематически.

Выбор модели: GigaAM v3

Из вариантов для русского ASR остановились на GigaAM v3. Модель заточена под русский язык, у неё есть RNN-T вариант, который в наших тестах лучше держал короткие фрагменты, и документированная процедура дообучения на доменных данных.

Базовый WER на реальных записях АЗС — около 49%. Это сдвиг домена: модель не слышала такой акустики в обучении ^[1]. Собрали и вручную разметили около 5 часов диалогов. Для полного переобучения этого мало, и задача стояла скромнее: сместить распределение в сторону нужной лексики и акустики.

В обучающую выборку добавили короткие реплики клиента (“да”, “нет”, “девятая”, “наличными”), числа с единицами (“восемь литров”, “колонка три”), доменную лексику АЗС и шумную среду без стерильной очистки — специально, чтобы модель не разваливалась на фоновом шуме.

Обучали CTC и RNN-T параллельно. CTC проще и быстрее, но делает предсказания токенов почти независимо друг от друга. На короткой тихой реплике контекста и так почти нет — модель решает по маленькому фрагменту на фоне шума. RNN-T добавляет авторегрессионный слой, использует уже распознанный контекст. На валидации RNN-T дал 2–3 процентных пункта абсолютного WER лучше именно на коротких фрагментах.

Двойной VAD

Дообучение модели не поможет, если VAD не пропустил нужный сегмент в распознавание, классифицировав его как тишину. Поэтому перед распознаванием стоит отдельная предобработка: извлечение аудио, выбор лучшего канала, подавление низкочастотного гула от компрессоров и вентиляции, нормализация громкости. 

VAD прогоняется дважды: сначала по исходному аудио со стандартными порогами, затем по усиленному с пониженной чувствительностью. Окна второго прохода добавляются к результатам первого. Прирост покрытия речевых сегментов на тихих участках получился 15–25% в тестах — при том что часть спасённых окон ASR всё равно распознаёт неуверенно. Смысл шага в другом: без него тихий клиент вообще не попадает в модель, и дообучать становится не на чем.

Whisper на сложных фрагментах

Whisper Large v3 в пайплайне играет вспомогательную роль. Он подключается точечно: когда GigaAM выдала низкую уверенность, когда фрагмент слишком короткий, или когда результат подозрительно пустой при явном наличии речи. Такой участок прогоняется через Whisper, и если тот уверенно фиксирует слово, которое GigaAM пропустила, появляется кандидат на добавление. При расхождении моделей без явного перевеса фрагмент отклоняется. Итоговая транскрипция всегда за GigaAM, Whisper закрывает отдельные пропуски.

Сборка сессии

После того как оба модуля отработали, система собирает бизнес-сессию. Начинается она, когда новый клиент появляется в ROI кассы и рядом по времени звучит приветствие или другой стартовый маркер. Завершается, когда клиент покидает ROI и рядом есть прощание, оплата или длинная пауза. Привязка аудиособытий к видеосессии идёт по временному окну с допуском: системы не идеально синхронизированы, особенно на архивных записях.

Чек-лист после сборки:

Правила чек-листа хранятся в конфигурации отдельно от кода. Заказчик менял чек-лист несколько раз за пилот — правка конфига, перезапуск сервиса, без изменений в коде.

Ряд случаев система не оценивает по условиям заказчика: дети и подростки, клиенты, не говорящие по-русски, глухонемые, мотоциклисты в шлемах, клиенты в состоянии опьянения, стажеры первые две недели. Стажёров фильтрует видеомодуль по маркеру на одежде. Остальные исключения — частично визуальные, частично требуют отдельной логики детекции, которой пока нет.

Доказательная база

Для каждой сессии система сохраняет флаги по чек-листу и доказательства: кадр появления клиента, кадр момента предполагаемого события, транскрипцию соответствующего аудиоокна. Требование пришло от заказчика — аудитор должен иметь возможность оспорить или подтвердить автоматическое решение. Выгрузка результатов — JSON, Excel, CSV. Интерфейс MVP даёт просмотр по смене и по конкретной АЗС.

Ограничения

Тихий клиент — основной источник False Negative. Даже после дообучения и двойного VAD часть реплик короче 0.5 секунды на фоне сильного шума не восстанавливается.

Нестандартные конструкции приветствия система пропускает. Кассир, который говорит “Чем помочь?” вместо “Здравствуйте”, формально нарушает стандарт, но семантически приветствует клиента. Текущий лексикон на такие вариации не настроен.

Быстрый клиент — отдельный случай. Клиент озвучивает заказ, платит наличными и уходит за несколько секунд. Видеомодуль фиксирует короткое присутствие в ROI, аудиоокно не успевает закрыться, сессия либо не открывается, либо открывается и сразу закрывается с пустым чек-листом. Заказчик такие случаи из оценки исключил. Детектировать их автоматически с нужной точностью пока не получается стабильно.

Что получилось

В рабочем процессе система снимает с аудитора ручной просмотр записей по типовым сессиям: классифицирует, флагирует нарушения, прикладывает доказательства. Объём записей, который аудитор физически может охватить, вырос с единиц процентов до полного покрытия на подключенных станциях.

Человек остаётся нужен на апелляциях, на нестандартных ситуациях, на записях плохого качества. Логику ^[2] исключений — стажеры, специальные категории клиентов — система выполняет частично, часть случаев уходит в серую зону и требует ручной проверки.

Чек-лист сейчас покрывает четыре обязательных события. Опциональные визуальные признаки, такие как дресс-код, приём пищи, использование телефона — требуют отдельной разметки, 150–200 изображений на класс, и обучения отдельных детекторов. Без достаточного объёма данных добавлять их в пайплайн нецелесообразно: ложные срабатывания на таких классах дороже, чем пропуски.

Хорошего решения пока нет для автоматической детекции “быстрого клиента” без ложных срабатываний и для распознавания семантически корректного приветствия вне фиксированного лексикона. Если сталкивались с похожими задачами в аудио или трекинге — интересно, как решали.