Сборка полноценного ИИ-видеозвонка

Кратко

Этот итоговый урок объединяет все материалы главы 6 в единую рабочую систему: живой видеозвонок, в котором изображение очищается, голос очищается от шума, субтитры и перевод появляются в реальном времени, опасный контент блокируется на лету, а ИИ-ассистент ведёт заметки – при этом разговор остаётся быстрым и плавным. Основная идея заключается в том, что у звонка есть три отдельные компоненты, которые мы называем плоскостями: медиа-плоскость передаёт звук и видео, ИИ-плоскость добавляет интеллектуальные функции, а control-плоскость координирует всё. Каждая новая функция размещается строго на одной из этих плоскостей – на устройстве отправителя, на промежуточном сервере или в облачном ИИ-воркере, который подключается к звонку как участник. Если вы правильно определите место для функции – она войдёт в жёсткий временной бюджет; если ошибётесь – звонок начнёт тормозить, станет дороже или и то, и другое сразу. Мы предоставляем вам референс-архитектуру, матрицу размещения функций, две модели задержки с подробной арифметикой и порядок сборки, который позволяет получать ценность уже на ранних этапах, а не ждать, пока система станет идеальной.

Почему это важно

Этот урок – для продакт-менеджера, который оценивает фичу «ИИ-видеозвонки» и должен понять, что здесь один проект, а что – десять; для основателя, решающего, строить ли на базе SDK или собирать из open-source-компонентов; и для инженера, который прошёл отдельные уроки главы 6 и теперь хочет увидеть, как они объединяются в единый развёртываемый продукт. Урок предполагает, что вы ознакомились с предыдущими материалами, на которые он ссылается, поскольку этот итоговый проект как раз связывает их воедино, а не повторяет всё с нуля. К концу урока вы сможете нарисовать архитектуру современного ИИ-звонка на доске, сразу определять, в какой слой помещать новую фичу, ставить измеримые цели по задержке и стоимости, а также выстроить процесс разработки так, чтобы первая полезная версия вышла за недели, а не за кварталы.

Что на самом деле значит «ИИ-Видеозвонок»

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

«Реальное время» – это и есть то ограничение, которое делает задачу трудной, и здесь у него точный смысл. Разговор кажется естественным, только если круговая задержка – вы говорите, собеседник слышит, он отвечает – укладывается примерно в то время, за которое можно моргнуть и подумать. Исследования живого общения показывают, что люди начинают воспринимать ответ как неестественно задержанный уже после 300–500 миллисекунд, а практический предел для голосового ИИ-цикла – около 800 миллисекунд: после этого обмена ощущается как нарушенный. Миллисекунда, сокращённо мс, – это одна тысячная секунды; 800 мс – чуть меньше секунды. Каждая ИИ-функция, которую вы добавляете в звонок, «съедает» часть этого временного бюджета. Вся инженерная задача этого итогового проекта – добавить интеллект, не превысив лимит времени, отведённый на разговор.

Полезный образ: живой звонок – это эстафета, где палочкой-эстафетой становится сам разговор. Каждый бегун, которого вы выводите на старт – шумодав, субтитровщик, переводчик, – должен успеть передать палочку дальше до следующего обмена репликами, иначе вся команда отстаёт. Замедлить разговор невозможно. Дальше – о том, как уместить больше бегунов на той же дорожке, не уронив палочку.

Три плоскости: одна ментальная модель, которая всё упорядочивает

Почти каждая запутанная архитектура, которую нам приходится спасать, возникает из смешения трёх задач, которые должны оставаться раздельными. Разделите их – и система станет простой для понимания. Мы называем их тремя плоскостями.

Первая – медиа-плоскость. Это та часть системы, которая передаёт сам звук и видео – байты аудио и изображения – от одного участника ко всем остальным. Медиа-плоскость – это как дорога, по которой движется разговор. В современных звонках она построена на WebRTC – браузерном стандарте для передачи звука и видео в реальном времени, который стал официальной рекомендацией W3C в январе 2021 года, и работает в связке с сервером под названием SFU, о котором мы расскажем чуть позже. У медиа-плоскости самый жёсткий временной бюджет, потому что любое препятствие на пути живого звука и видео добавляет задержку, которую можно услышать и увидеть.

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

Третья – control-плоскость. Это слой координации: кто может войти в комнату, кто говорит, кто выключил камеру, когда появляется ИИ-ассистент, какие субтитры кому показывать. Control-плоскость – как судья эстафеты с планшетом. Она почти не обрабатывает тяжёлые данные, поэтому у неё самый свободный временной бюджет, но именно она синхронизирует две другие плоскости. Смешивать логику управления с медиа-потоком – например, поручать видеосерверу решать, кому можно войти, – классическая ошибка, из-за которой систему невозможно масштабировать.

Нажмите, чтобы увеличить

Медиа-Плоскость: WebRTC и SFU

Начнём с дороги, потому что именно к ней подключена каждая ИИ-функция. В звонке с участием более двух-трёх человек участники не отправляют видео друг другу напрямую – это заставило бы каждый телефон передавать свой видеопоток сразу всем остальным, что быстро разрядило бы батарею и перегрузило домашний интернет. Вместо этого каждый отправляет одну копию своего звука и видео на сервер посередине, а тот пересылает каждый поток остальным участникам. Этот сервер называется Selective Forwarding Unit, или SFU. Название отражает принцип работы: он избирательно пересылает медиапотоки, не переобрабатывая их.

Слова «не переобрабатывая» – самая важная часть. Раньше MCU (Multipoint Control Unit) декодировал видео каждого участника, смешивал его в общую картинку и заново кодировал – процесс трудоёмкий и требующий мощного сервера на каждый звонок. SFU почти ничего из этого не делает. Он принимает поток каждого участника по протоколу RTP (в защищённой версии SRTP, то есть зашифрованному при передаче) и просто пересылает пакеты дальше, в худшем случае выбирая, какой слой качества отправить, если не хватает полосы пропускания. Поскольку SFU никогда не транскодирует видео, один такой сервер обслуживает заметно больше участников при тех же затратах. Поэтому практически каждая платформа видеозвонков в продакшене в 2026 году – LiveKit, mediasoup, Janus и коммерческие SDK на их основе – использует модель SFU.

Сам звук передаётся с помощью Opus – открытого и бесплатного кодека для голоса и музыки, стандартизированного как IETF RFC 6716. На нём общаются все WebRTC-устройства. Кодек – это способ сжать аудиосигнал в компактный поток байтов и восстановить его на приёмной стороне. Opus важен для ИИ-платформы по одной ключевой причине, к которой мы постоянно возвращаемся: большинству моделей аудио-искусственного интеллекта нужен не сжатый Opus-поток, а исходный, неспрессованный звук. От того, где находится модель по отношению к Opus-энкодеру, зависит, сможет ли она вообще работать.

Практический вывод: медиа-платформа – во многом решённая и стандартизированная задача. Её не изобретают с нуля: берут WebRTC и SFU. Урок 6.2 про WebRTC AI-API и выбор SDK разбирает, как выбирать между самостоятельной сборкой на чистом WebRTC и покупкой готового видео-SDK. Все интересные решения сосредоточены на том, как интегрировать ИИ-платформу – об этом идёт речь во всём оставшемся уроке.

Три Дома для ИИ-фичи

Каждая функция ИИ в звонке работает ровно в одном из трёх мест. Определить их заранее – самое полезное, что можно сделать на старте проекта, потому что выбор влияет на стоимость, приватность, задержку и поддерживаемые устройства.

Первый дом – на устройстве отправителя: в вкладке браузера или в приложении на телефоне, до сжатия и отправки звука и видео. Сюда относятся функции, которые изменяют передаваемый контент: размытие и замена фона, шумоподавление, бьюти- и AR-фильтры. Причина здесь чисто техническая. Эти функции должны обрабатывать необработанные кадры с камеры и необработанный звук с микрофона, а единственное место, где такой «сырой» сигнал существует, – это устройство, его захватившее. Запустите размытие фона на устройстве отправителя – и все ниже по цепочке (SFU, остальные участники) получат уже размытое видео и никогда не увидят настоящую комнату. Это же делает такую схему самой надёжной с точки зрения приватности: неизменённый сигнал не покидает помещение.

Браузер делает это возможным благодаря небольшому семейству стандартов. WebCodecs предоставляет низкоуровневый доступ к кодированию и декодированию кадров и поддерживается в Chrome, Edge, Firefox 130+ и Safari 26. MediaStreamTrackProcessor разбивает живой видеопоток с камеры или микрофона на отдельные кадры, которые можно обрабатывать. WebGPU, теперь доступный во всех основных браузерах, позволяет выполнять обработку на графическом процессоре устройства – это обеспечивает достаточную скорость для работы с живым видео. Для обработки звука AudioWorklet запускает небольшой шумоподавитель на необработанном аудиосигнале за пределами основного потока. Урок 6.3 про размытие фона и урок 6.5 про интеграцию шумоподавления – это подробные разборы этих технологий.

Второй дом – на SFU, пересылающем сервере. Сюда относится узкий набор функций, которым нужно видеть один поток, но при этом нельзя доверять устройству каждого участника или обновлять его – ведь через SFU и так проходит каждый поток. Самый чистый пример – модерация контента: вы хотите централизованно проверять кадры и звук, чтобы вредоносный клиент не мог просто отключить проверку, поэтому урок 6.12 ставит реал-тайм-модерацию на SFU. Ловушка, которой надо избегать, – запускать тяжёлый ИИ по каждому потоку прямо на самом SFU; суперсила SFU в том, что он не декодирует видео, а модель, заставляющая его это делать, эту эффективность уничтожает. Рабочий паттерн – чтобы SFU отправлял копию потока в отдельный воркер, а не запускал модель встроенно.

Третий дом – облачный ИИ-агент, который присоединяется к звонку как полноценный участник. Это ключевая архитектурная идея всей фазы, которую легко упустить. Вместо того чтобы интегрировать ИИ внутрь сервера, вы позволяете программе войти в комнату так же, как это сделал бы человек: она подписывается на аудио- и видеопотоки, обрабатывает их с помощью моделей и публикует результаты – субтитры, переведённый голос, резюме – обратно в комнату. Именно здесь живут субтитровщик, переводчик и ассистент встречи. Именно эту модель формализует фреймворк LiveKit Agents: агент – это «любая программа на Python или Node.js, добавленная в комнату как полноценный участник в реальном времени». Поскольку агент – это просто ещё один участник, он масштабируется независимо от SFU, его может разрабатывать продуктовая команда, а не инфраструктурная, и вы можете запускать по одному агенту на комнату, не затрагивая медиасервер.

Нажмите, чтобы увеличить

Проходим по пайплайну, фича за фичей

Когда три дома определены, размещение каждой фичи главы 6 становится механическим процессом. Рассмотрим путь сигнала – от камеры одного человека до экрана другого.

Сигнал начинается у камеры и микрофона отправителя. Первым делом он проходит предобработку на устройстве. Модель размытия фона заменяет пиксели за человеком с помощью модели сегментации – той, что определяет попиксельно: «это человек, а это стена» – и работает на WebGPU. Параллельно шумоподавитель очищает звук с микрофона внутри AudioWorklet, убирая стук клавиатуры и фоновые голоса ещё до сжатия. Если продукт поддерживает бьюти-фильтры или коррекцию взгляда, они тоже применяются на этом этапе – об этом подробно в уроке 6.8 про AR-эффекты.

Золотое правило этой стадии: в цепочке должен быть ровно один шумоподавитель. Браузеры предоставляют встроенный, работающий бесплатно; если вы добавляете свой, встроенный нужно отключить, иначе два устройства будут конфликтовать и создать роботизированный, «подводный» голос. Два шумоподавителя одновременно – самый частый аудиобаг, с которым мы сталкиваемся в ИИ-продуктах для видеозвонков.

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

ИИ-агент подписывается на потоки и выполняет сложную лингвистическую обработку. Он запускает потоковое распознавание речи – automatic speech recognition, или ASR, – чтобы генерировать живые субтитры. Тема урока 6.9 про fan-out субтитров на стороне SFU. «Потоковое» здесь означает, что модель выдаёт слова по мере произнесения, а не ждёт окончания предложения – именно это делает субтитры живыми. На основе того же транскрипта модель перевода создаёт субтитры или синтезированный голос на другом языке – см. урок 6.11 про реал-тайм-перевод речи. Ассистент встречи сохраняет транскрипт, чтобы формировать бегущее резюме и список задач – это тема урока 6.14 про ИИ-ассистента встреч на LiveKit. Если ваш продукт включает ИИ-аватар, синхронизирующий синтетическое лицо с сгенерированной речью, его также публикует в комнату агент – см. урок 6.13 про аватаров внутри звонка.

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

Два бюджета, которые нужно учитывать: интерактивные медиа и голосовой ИИ-цикл

Единого значения задержки для ИИ-звонка не существует, потому что одновременно работают два разных цикла с разными пределами. Смешивать их – и команды начинают оптимизировать не то.

Первый – бюджет интерактивного медиа: насколько быстро ваш голос доходит до собеседника. Этот бюджет определяет, будут ли люди говорить друг через друга. Цель для комфортного общения – удерживать одностороннюю задержку звука примерно на уровне 200 мс, а полную задержку туда-обратно – около 400 мс. Функции на устройстве напрямую расходуют этот бюджет: шумоподавление добавляет 20 мс, а размытие – 15 мс, и оба процесса происходят в реальном времени. Арифметика здесь проста и беспощадна. Если сетевой транспорт занимает у вас 120 мс в одну сторону, остаётся около 80 мс на захват звука, обработку ИИ на устройстве, кодирование и воспроизведение – всё вместе. Поэтому модели на устройстве должны быть компактными и быстрыми, и поэтому нельзя бездумно объединять четыре таких компонента подряд.

Второй – бюджет голосового ИИ-цикла: сколько времени проходит от момента, когда ИИ-ассистент слышит вопрос, до начала ответа. Этот цикл включает распознавание речи, обработку языковой моделью и синтез речи, и его практическая граница – около 800 мс: после этого ассистент начинает казаться медлительным. Типичная раскладка 2026 года, взятая с продакшен-платформ голосовых агентов, выглядит так: детекция голосовой активности и решение о смене реплики – 150–300 мс; финальный транскрипт распознавания – 50–150 мс после того, как человек замолчал; время до первого токена языковой модели – 150–400 мс; первый аудиочанк синтеза речи – 100–200 мс; накладные расходы сети – 30–80 мс. Сложив нижние границы, получим около 480 мс; сложив верхние – превысим 1000 мс. Приведём один конкретный пример: 200 мс на смену реплики + 100 мс на транскрипт + 300 мс до первого токена модели + 150 мс до первого чанка речи + 50 мс на сеть = 800 мс. Вот бюджет, использованный полностью, без запаса.

Рычаг, который прячется на виду, – смена реплики, то есть решение о том, что человек действительно закончил говорить. Неуклюжий детектор конца реплики добавляет ощутимую задержку в 500 мс, которой нет ни в одном бенчмарке модели, потому что время теряется в ожидании, а не в вычислениях. Современные фреймворки используют небольшую трансформерную модель, обученную предсказывать конец реплики, а не полагаются на фиксированный таймер тишины – именно поэтому стек LiveKit Agents и подобные системы предлагают детекцию смены реплики как первоклассный компонент. Потоковость каждой стадии – частичные транскрипты в модель, токены модели в синтезатор речи до конца предложения – и позволяет хорошо собранному циклу уложиться в секунду. Урок 6.1 про бюджет задержки sub-100 мс раскладывает эти цифры по стадиям.

Нажмите, чтобы увеличить

Разобранный пример: один звонок с пятью фичами

Числа делают архитектуру осязаемой. Представьте общую встречу компании из 25 человек на видеоплатформе с пятью включёнными ИИ-функциями: размытие фона для всех, шумоподавление для всех, живые английские субтитры, живой испанский перевод для шести удалённых сотрудников, которым так удобнее, и ИИ-ноутейкер, готовящий резюме. Где реально оседает работа?

Размытие фона и шумоподавление работают на каждом из 25 устройств – 25 небольших моделей, но каждая выполняется на железе своего владельца и не требует от вас, оператора платформы, никаких затрат на серверные вычисления. Это тихая суперсила edge-вычислений: масштабирование происходит бесплатно по мере роста числа участников, потому что каждый новый пользователь приносит с собой свой процессор. SFU пересылает 25 входящих аудиопотоков и выборку видеопотоков, не транскодируя ни одного – поэтому даже скромный сервер справляется с нагрузкой в комнате.

Субтитры, перевод и заметки работают в рамках одного ИИ-агента, который подключается к встрече. Агент обрабатывает потоковый ASR для активного говорящего – обычно в группе по очереди говорит только один человек, так что расшифровывается один аудиопоток, а не 25. Английский транскрипт используется одновременно для наложения субтитров, перевода на испанский и формирования текущего резюме, которое ведёт «ноутейкер». Стоимость зависит от количества обработанных минут речи и сгенерированных токенов, а не от числа молчащих участников. Приблизительная оценка: один час ASR одного говорящего, плюс перевод и периодическое резюмирование – обойдётся в несколько центов или десятков центов в 2026 году, в зависимости от провайдера. Это погрешность округления по сравнению с реальной ценностью встречи, где информация была не только записана, но и переведена, и обобщена. Урок 6.18 про инженерию meeting-ботов подробно разбирает, как коммерческие ноутейкеры реализуют именно такую систему.

Урок разобранного примера – в форме стоимости. Фичи на устройстве не стоят оператору ничего на участника; фичи агента стоят за минуту речи и за токен, а не за участника. Продукт, который это понимает, ценит и масштабирует правильно; продукт, который гоняет всё в облаке, платит за 25 GPU-слотов там, где нужен был один агент.

Частая ошибка: поставить ИИ не в ту плоскость

Поломка, которую нас чаще всего просят чинить, – не плохая модель, а хорошая модель в неправильном доме. Повторяются три версии.

Первая – применять аудио-обработку после Opus-энкодера, а не до него. Команда подключает шумоподавление к цепочке WebRTC Encoded Transform – API, позволяющему изменять закодированные кадры, – и удивляется, почему оно не работает. Дело в том, что эти кадры – уже сжатые байты в формате Opus, а не исходный звук; шумоподавлению нужна именно звуковая волна. Обработка шума должна выполняться на сырых аудиоданных, в AudioWorklet, до кодирования. Encoded Transform – подходящий инструмент для других задач, например, для добавления дополнительного слоя сквозного шифрования, который SFU пересылает без возможности прочитать, – но это не тот инструмент, который способен понимать медиаданные.

Вторая – заставить SFU декодировать видео, чтобы запускать модель встроенно. Вся эффективность SFU строится на пересылке без транскодирования. Как только вы заставляете его декодировать видео каждого участника для детекции, вы фактически создаёте дорогой MCU, от которого пытались избавиться, и стоимость сервера на комнату резко возрастает. Решение – паттерн агента: передать копию потока в отдельный воркер, который будет заниматься декодированием и запуском модели, оставив SFU лёгким и эффективным.

Третья – размещать модели на устройстве без бюджета. Каждая функция на устройстве – размытие, шумоподавление, бьюти-фильтр – занимает миллисекунды в реальном времени. Добавьте их без замеров – и вы незаметно превысите одностороннюю задержку, после которой разговор становится непонятным, а на телефонах среднего класса быстро сядет батарея. Дисциплина здесь – иметь чёткий письменный бюджет для устройства и измерять реальную стоимость каждой функции на реальном железе, как предписывает урок 6.1. Если бюджет исчерпан, функцию либо переносят в агент, либо удаляют; её не встраивают в путь, который не справится с нагрузкой.

Порядок сборки: выдавать ценность рано, а не всё сразу

Эту систему не строят сразу целиком и не в том порядке, в каком она изображена на схеме. Её реализуют так, чтобы на каждом этапе получалась полезная ценность: работающий продукт появляется уже с первой недели, а каждое последующее дополнение можно выпускать независимо.

Фундамент – обычный, надёжный звонок на WebRTC и SFU, вообще без ИИ. Доведите звук и видео, доведите переподключение, добейтесь стабильности на тех устройствах, что реально есть у пользователей. Всё остальное крепится к этому; если фундамент шаткий, никакой ИИ продукт не спасёт. Это же правильный момент выбрать build-versus-buy для медиа-слоя – решение, которое формулирует урок 6.2.

Первый ИИ-слой – очистка на устройстве: размытие фона и шумоподавление. Это фичи, которые пользователи замечают сразу, они не стоят оператору ничего на участника и не требуют нового бэкенд-сервиса. У них лучшее в системе соотношение ценности к усилию, поэтому они идут первыми.

Второй слой – ИИ-агент для субтитров. Запустить одного агента, входящего в комнату и генерирующего живые субтитры, – это момент, когда продукт становится по-настоящему «ИИ-видеозвонком». Такой подход закладывает паттерн агента, который будет переиспользоваться каждой последующей языковой функцией. Когда субтитры работают, перевод – это небольшое расширение той же системы: транскрипт уже есть, остаётся добавить шаг перевода. Заметки и резюме – ещё одно расширение, использующее тот же накопленный транскрипт.

Последний слой – специализированный и регулируемый: модерация контента, аватары в ходе звонка, ассистенты для продаж или по предметной области. Он требует больше усилий, ориентирован на конкретную аудиторию или связан с комплаенсом, поэтому внедряется только после того, как ядро продукта доказано. Модерацию особенно важно добавлять обдуманно, а не торопясь – она затрагивает как модель доверия, так и, на регулируемых рынках, законодательство. Отметьте одно жёсткое требование ко всей системе: там, где ваш продукт генерирует или существенно изменяет изображение или голос человека – ИИ-аватар, клонированный голос, синтетический перевод, звучащий голосом пользователя, – статья 50 EU AI Act требует раскрывать это участникам. Вводите раскрытие с самого начала: это гораздо дешевле, чем дорабатывать позже.

Нажмите, чтобы увеличить

Build Versus Buy: Где проходит граница в 2026

Разумная команда не создаёт всё с нуля и не приобретает всё целиком. К 2026 году граница пройдёт в вполне устойчивом месте.

Медиа-плоскость – WebRTC плюс SFU – почти всегда берут, а не строят: либо используют open source, который хостят сами (LiveKit, mediasoup), либо выбирают управляемый SDK. Реал-тайм-медиа в масштабе порождает длинный хвост сетевых краевых случаев, мобильных особенностей и логики переподключения – на правильную отладку всего этого уходят годы. Нет смысла изобретать велосипед: нет деловой причины переосмысливать это заново. Фреймворк агента тоже всё чаще берут «из коробки»: SDK LiveKit Agents и его аналоги уже решают задачи детекции смены реплики, обработки перебиваний и потоковой интеграции STT-LLM-TTS, которую утомительно и легко собрать с ошибками самостоятельно.

Что вы строите – это часть, которая и есть ваш продукт: какие фичи вы показываете, как они настроены под вашу вертикаль, бизнес-правила в вашем агенте и пользовательский опыт вокруг них. Что вы покупаете как сервис – обычно отдельные модели: провайдер ASR, модель перевода, голос синтеза речи, – потому что они улучшаются помесячно, а самохостинг окупается только на большом, стабильном объёме. Решение по каждой модели – это рамка build-versus-buy урока 6.6 про Krisp, Maxine и Dolby: покупайте ради скорости и широты поддержки устройств, самохостьте, когда объём велик и предсказуем, а правила приватности требуют, чтобы данные не покидали ваши серверы.

Где здесь Фора Софт

Фора Софт разрабатывает реал-тайм-видео софт с 2005 года, и описанная здесь архитектура – WebRTC-медиа, SFU и ИИ-функции, распределённые между устройством, сервером и агентом, – является основой наших продуктов для видеоконференций, e-learning и телемедицины. Мы внедряли обработку фона и шумоподавление на стороне устройства в прямые звонки, запускали ИИ-агентов, генерирующих субтитры и краткие резюме в реальном времени, а также добавляли модерацию пользовательского видео, не увеличивая задержку звонка. Принцип трёх плоскостей – для нас не абстракция, а чек-лист, которым мы пользуемся при оценке новой реализации, поскольку именно он позволяет отличить полезную фичу от той, что незаметно ухудшает качество каждого звонка. Наши ключевые направления – видеоконференции, e-learning, телемедицина и видеонаблюдение, где реал-тайм-искусственный интеллект на живом видео – не дополнение, а ядро продукта.

Главное

• У звонка три плоскости: медиа (звук/видео), ИИ (модели) и управление (координация). Держите их раздельно.
• Каждая ИИ-функция работает в одном из трёх мест: устройство отправителя, SFU или облачный ИИ-агент.
• Устройство – для пикселей и необработанного звука; агент-участник – для обработки языка; SFU остаётся лёгким.
• Параллельно действуют два временных бюджета: интерактивное медиа (~200 мс в одну сторону) и голосовой цикл (~800 мс).
• Шумоподавление работает на необработанном звуке до кодирования в Opus – никогда на закодированных кадрах; никогда не применяйте два шумоподавления подряд.
• Разрабатывайте поэтапно: сначала обычный звонок, затем очистка звука на устройстве, далее агент для субтитров, потом специализированные функции.

Что читать дальше

• Урок 6.1 – Бюджет задержки реального времени менее 100 мс
• Урок 6.2 – WebRTC AI-API и решение 100ms / video SDK
• Урок 6.14 – ИИ-ассистент для встреч на LiveKit