Jitsi Meet: почему транскрипция для электронных медкарт требует Jigasi и Vosk

Jitsi Meet поддерживает транскрипцию, но в реальном продукте это оказывается не переключателем в интерфейсе, а отдельным инфраструктурным контуром. В кейсе с автоматическим заполнением EMR после видеоконсультаций именно этот слой оказался самым трудоёмким: пришлось сводить вместе Jigasi, XMPP/SIP, Vosk и LLM-постобработку.

Архитектура под капотом Базовая идея Jitsi выглядит просто только снаружи.

Сам видеозвонок обслуживают фронтенд Jitsi Meet, медиасервер Jitsi Videobridge, менеджер конференций Jicofo и XMPP-слой Prosody. Но транскрипция живёт не внутри одной кнопки в интерфейсе. За неё отвечает Jigasi — отдельный gateway, который подключается к комнате как обычный участник, получает аудио от собеседников и отправляет поток во внешний сервис распознавания речи.

Это и создаёт ложное ощущение простоты на старте. Из-за этого задача быстро переходит из уровня «подключить API» на уровень инфраструктуры. Нужно не просто включить опцию в UI, а согласовать несколько сервисов, сетевые соединения и отдельный STT-бэкенд.

В разобранном кейсе таким бэкендом был Vosk, запущенный через WebSocket. Сам по себе подход удобен для асинхронной обработки после консультации: системе не нужно укладываться в жёсткие задержки live-режима, а итоговый текст можно спокойно разбирать уже после завершения звонка.

Где ломается схема

Главная проблема в том, что у транскрипции здесь сразу несколько независимых точек отказа. Конфиг Jigasi, параметры фронтенда Jitsi Meet и доступность STT-сервиса должны совпасть одновременно. Если один слой настроен неверно, система часто не падает с понятной ошибкой, а просто не даёт ожидаемый результат: бот не входит в комнату, файл не сохраняется или текст получается слишком слабым для практического использования. Без просмотра логов такие сбои легко принять за случайность.

«Jigasi — это SIP gateway с транскрипцией, а не наоборот». * отдельный XMPP-аккаунт для

Jigasi в Prosody: если с ним ошибка, transcriber bot вообще не появится в конференции; права на директорию с транскриптами: промежуточные субтитры могут идти, а итоговый файл на диск не сохранится; выбор STT-модели: базовый Vosk подходит для MVP, но хуже справляется с медицинскими терминами, названиями препаратов и дозировками; * детектирование конца сессии: Jigasi пишет финальный текст только когда комната действительно опустела, а downstream-пайплайну нужен надёжный триггер на обработку. Отдельный нюанс — разделение каналов сохранения и отправки результатов. Один набор параметров отвечает за запись итогового текста на диск после завершения консультации, другой — за пересылку промежуточных фрагментов участникам через XMPP.

Для продукта, который заполняет EMR постфактум, важнее именно гарантированно получить финальный файл, чем показывать субтитры в реальном времени. Иначе следующий этап обработки просто не с чего запускать, и вся автоматизация зависает.

От текста до EMR Даже после успешной настройки Jitsi задача не заканчивается.

Выход Jigasi — это обычный сырой диалог с таймкодами: врач задаёт вопросы, пациент отвечает, затем следуют назначения и рекомендации. Для медицинской карты такой текст почти бесполезен в исходном виде, потому что системе нужны не реплики как таковые, а структурированные сущности: жалобы, история симптомов, препараты, дозировки, режим приёма и дальнейшие действия. Между распознаванием речи и EMR остаётся ещё большой слой преобразований.

Поэтому поверх STT понадобился ещё один слой — LLM-обработка. Модель нормализует текст, исправляет часть ошибок распознавания по контексту и раскладывает результат по полям, совместимым с FHIR-структурами. После этого данные попадают во фронтенд-форму, где врач проверяет и подтверждает запись перед финальным сохранением в EMR.

Такой human-in-the-loop здесь не перестраховка, а обязательное требование: в клиническом сценарии нельзя без ревью автоматически записывать в карту лекарства, дозы и назначения. Именно здесь хорошо видно ограничение «дешёвого» STT. Если базовая модель слабо распознаёт доменную лексику, вся остальная цепочка начинает тратить ресурсы на исправление ошибок.

Для production-варианта напрашиваются более тяжёлые модели Vosk, специализированный движок вроде Deepgram с медицинским профилем или комбинация STT и LLM-нормализации, где языковая модель компенсирует промахи распознавания. Иначе цена ошибок слишком высока уже на уровне медицинской записи.

Что это значит

История с Jitsi Meet показывает простую вещь: транскрипция для прикладного AI-продукта — это отдельная подсистема, а не косметическая фича. Для MVP подойдёт асинхронная схема с Jigasi и Vosk, но для production в медицине нужны точная настройка всего стека, хорошие логи, контроль завершения сессии и слой нормализации, который превращает разговор в пригодные для EMR данные. Чем строже домен, тем дороже обходится иллюзия, что всё решается одной галочкой в интерфейсе.