Автосекретарь ASR работает как голосовой помощник-коммутатор, который вызывает абонента после произнесения его имени и фамилии. Пользователь произносит ФИО конкретного сотрудника, сервис ищет номер телефона в адресной книге и соединяет пользователя с данным контактом. В случае, если контакт найти не удалось, система попросит уточнить запрос.

Описание работы сервиса

Пользователь снимает трубку и набирает номер, на котором работает IVR-скрипт автосекретаря. После приветственного сообщения, аудиопоток с микрофона отправляется на специальный порт MSR, который детектирует тишину и нарезает по ней блок данных (chank). Каждый блок отправляется отдельным HTTP POST-запросом в сторону ecss-clerk (через restfs) с заголовком Content-type: Transfer-Encoding. Идентификатором такого запроса является путь HTTP-запроса вида /speech-recognition/domain/eltex/2021-01-25_18-30-18-866402_asr_5501-4893.wav. По имени этого wav-файла (который по своей сути является чистым pcm) ecss-clerk идентифицирует блок. Каждый блок отправляется на распознавание, по результату которого происходит поиск номера абонента по адресной книге. Если найти его не удалось, то clerk просит следующий блок и так до тех пор, пока не получится найти номер или не сработает таймаут в ivr-скрипте.

В случае успеха, json-файл отправляется на MSR через сервис restfs, далее MSR пересылает его на ядро. Промежуточные ответы также доходят до ядра и имеют HTTP-код 206. Они не содержат в прилагаемом в теле json поля с номером, но имеют поле с распознанной строкой. Также промежуточный ответ может содержать поле с текстом для уточнения, если по полученной речи нашлось несколько совпадений в телефонной книге. Имея эту строку по таймауту, IVR может синтезировать ответ для пользователя, уведомив его о том, что найти распознанную строку не удалось или попросив произнести уточняющую фразу. Если до таймаута ecss-clerk не пришлёт ответ ядру, то синтезированное уведомление не будет содержать распознанной строки.

Синтез речи происходит через сервис restfs, который в свою очередь проксирует запрос на настроенный tts-сервис. Он озвучивает текст, который передаётся по цепочке Clerk → RestFs → ecss-tts.

После получения PCM ecss-clerk выполняет следующие действия:

• Отправляет pcm на распознавание: clerk (http) → asr-server(ws) → vosk-server;

• По результату распознавания пытается найти номер (номера) в телефонной книге;
• Посылает ответ.

Ответ, как уже сказано выше, имеет формат json.

Пример:

{
  "done": true,
  "negative_url": "negative/2021-01-25_18-30-18-866402_asr_5501-4893",
  "number": "4815",
  "positive_url": "positive/2021-01-25_18-30-18-866402_asr_5501-4893",
  "recognized": "антон черненко" 
}

Поле done информирует о том, что распознавание закончено и номер был найден;
negative_url и positive_url — обратные вызовы, которые отправляет IVR-скрипт (через блок RPC) после получения json. Помечают запрос на clerk как успешный или не успешный;
recognized — ответ от asr-server;
answer — текст с уточнением, который используется для синтеза речи;
number — найденный номер телефона.

Пример промежуточного ответа (часть запроса распознано):

{
  "done": false,
  "negative_url": "negative/2021-01-25_18-30-18-866402_asr_5501-4893",
  "recognized": "василий",
  "answer": "уточните фамилию иванов или петров" 
}

Описание работы IVR скрипта

После звонка абонента на номер IVR система произносит приветственное сообщение. Далее голосовой запрос абонента поступает на сервер приложения. Если до таймаута от приложения приходит ответ с номером, то происходит звонок. В противном случае происходит одно из двух:

1. Приложение не распознало запрос или не смогло найти соответствия с распознанной речью.
   Звучит фраза «Не удалось найти абонента». Далее в блоке RPC запрос приложению тегируется как неудачный и делается повторный запрос (блок goto, выполняется 2 раза);
2. Приложение нашло соответствие с распознанной речью, но требуется уточнение (например, были найдены 2 абонента с одним и тем же именем и фамилией, но они находятся в разных отделах).
   Приложение пришлет ответ, что нужно уточнить отдел и перечислит их. Делается повторный запрос (блок goto, выполняется 2 раза), где в блоке ivr будет произнесен ответ от приложения (уточнение). 

Интеграции сервиса Clerk и Address Book

Общая схема

• Clerk загружает телефонную книгу из сервиса AddressBook по GraphQL‑API;
• Для доступа к AddressBook Clerk получает токен в отдельном Keycloak и отправляет его в заголовке Authorization;
• Все контакты сохраняются в in‑memory телефонной книге Clerk; при обновлении применяется дифф.

Интеграция ASR и системы мониторинга Peeper

Что именно мониторится

Clerk экспортирует метрики о:

• количестве запросов на распознавание речи и их статусах (успех/ошибка);
• времени обработки одного запроса в целом;
• времени выполнения ключевых фаз пайплайна:
  • приём и буферизация аудио от MSR/пользователя;
  • взаимодействие с ASR‑сервером/Vosk (стриминг сегментов распознавания);
  • поиск абонента в телефонной книге по распознанному тексту;
• количестве и типах ошибок (проблемы с входными данными, тайм‑ауты ASR, внутренние ошибки);
• состоянии самого сервиса Clerk и его подсистем (обновление телефонной книги, компиляция модели и т. п.).

Эти данные публикуются в виде метрик Prometheus на HTTP‑эндпоинте Clerk и размечаются Docker‑label’ами (ru.eltex-co.metrics.*), чтобы мониторинг мог автоматически находить нужный сервис.

Роль Peeper

Peeper выступает фронтендом к этим метрикам:

• собирает метрики с Clerk (по HTTP‑эндпоинту метрик, используя job/port/path из label’ов);
• строит графики по ключевым показателям:
  • латентность распознавания (общая и по фазам);
  • частота запросов;
  • частота и типы ошибок;
• подсвечивает аномалии:
  • рост времени обработки (например, из‑за проблем с ASR‑сервером или Vosk);
  • рост доли ошибок (тайм‑ауты, внутренние ошибки, проблемы с телефонной книгой);
• даёт возможность быстро локализовать проблему:
  • проблемы в сети до ASR;
  • перегруз или некорректная работа Vosk;
  • замедление поиска по телефонной книге;
  • внутренние ошибки Clerk.