MWS убирает шум из звонков прямо в сети оператора: на обработку — 20 мс

Фраза «подключим нейросеть» звучит просто, пока не упрёшься в миллисекунды, токены и неточно поставленную цель. На одиннадцатом митапе MWS три доклада разобрали именно эти упирания: в звонках, в архитектурной документации и в стратегическом планировании. Вот что стоит забрать практикам.

Шум убирают в сети, а не на телефоне

Максим Масленников, Cluster lead Architect в MWS, рассказал о системе шумоподавления на стороне оператора. Она работает без приложений и без участия смартфона: голос чистится до того, как попадёт к собеседнику. Идея родилась после случая в метро, когда руководитель компании не смог нормально поговорить из-за шума.

Сложнее всего оказалась реализация. В 2G и 3G голос идёт по выделенному каналу, и там команда рассматривала маршрутизацию звонка через специальный префикс. В LTE звонки идут через IMS, то есть пакетами по IP, и туда встроили собственный медиасервис, через который проходит голосовой поток. Номер менять не нужно.

Главное ограничение — время. Каждый пакет нужно принять, перевести в удобный нейросети формат, очистить и отправить дальше примерно за 20 мс. Если не уложиться, собеседники услышат щелчки и обрывы. Модель при этом работает с непрерывным разговором, а не с отдельными записями, поэтому её пришлось адаптировать так, чтобы она хранила состояние между фрагментами.

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

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

Агенты, которые чинят документацию

Евгений Артемьев, Stream lead Architect в MWS, показал инструмент, который борется с классической болезнью: код ушёл вперёд, а архитектурные документы остались в прошлом. Новые микросервисы и изменённые API не попадают в описание системы, и оно перестаёт соответствовать реальности.

Инструмент собирает данные из репозиториев, DevOps, Jira и Confluence. Один агент анализирует изменения и подбирает материалы, второй сводит их и готовит предложения по обновлению. Работой управляет оркестратор, а перед отправкой в модель отдельный слой вырезает конфиденциальные сведения. На выходе получаются файлы YAML и Markdown, по которым можно искать устаревшие технологии, смотреть связи между системами и оценивать риски. Решение о правках принимает архитектор.

Самое полезное в докладе — сравнение двух режимов. В детерминированном разработчики заранее задают шаги и инструменты. В недетерминированном агент сам решает, что делать. В эксперименте с Claude второй вариант оказался хуже: модель тратила больше токенов, делала лишние действия и хуже держала структуру. Поэтому выбрали LangGraph, где заданы этапы и допустимые переходы, а несколько агентов могут работать параллельно. Платой стала более сложная отладка: нужно следить за состоянием каждого агента и сохранять промежуточные результаты.

Отдельная ловушка — контроль данных перед отправкой в модель. Это можно делать регулярными выражениями или моделью-классификатором. Но в одном из проектов классификатор на CPU работал три-четыре секунды при лимите 500 мс.

«Карта гипотез»: цель всё равно задаёт человек

Александр Бындю представил методологию, которая связывает цели компании, её ресурсы и внешние условия со стратегическими ставками. В основе лежит связанный SWOT-анализ. Его главный тезис: ускорение отдельных операций не гарантирует роста бизнеса. Если письмо пишется за пять минут вместо двух часов, это экономит время, но не обязательно прибавляет выручку.

На практическом кейсе ИИ собрал карту по небольшому PDF и попал близко к реальности. Но всё упирается в формулировку цели: ошибка в ней ведёт к неверным метрикам, и это сразу видно при сравнении с эталоном. Во второй демонстрации модель с навыками из GitHub задала уточняющие вопросы и выдала карту с прототипом интерфейса. Она ошиблась в определении субъекта, и это пришлось править вручную. Когда выяснилось, что одного из трендов не существует, данные заменили и примерно за десять минут получили новую версию. Ценность прототипа здесь в скорости обратной связи, а не в качестве реализации.

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

Что забрать на практике

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

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

Оговорка: это пересказ докладов самих разработчиков. Независимых замеров качества шумоподавления или точности агентов не приводится.