Мультимодальная AI рассыпается на стыке текста, фото и звука
Клиент присылает заявку текстом, прикладывает фото дефекта и голосовое сообщение — три канала, три разных пути обработки. Текст разбирает одна модель, изображение — вторая, звук расшифровывает третья. Каждая ветка по отдельности работает, а на стыке каналов результат расходится: в письме один номер заказа, на фото — другой, в записи назван третий.
Мультимодальная обработка ломается не внутри моделей, а на склейке. Ошибки распознавания редко видны на выходе одной ветки — их маскирует уверенный ответ. Проблема всплывает позже: сущности не совпадают, поля заполнены противоречиво, у части данных нет якоря, по которому их связать с остальными.
Разные типы данных приходят с несовпадающей разметкой. У текста есть структура и ключи, у изображения — визуальные признаки и уверенность модели, у звука — фрагменты без привязки к сущностям и авторам. Свести это в одну запись получается только вручную, и каждая спорная заявка съедает время оператора на сверку.
Единый поток заявок строится иначе. Сначала общий слой идентификации связывает каналы по клиенту, времени и контексту обращения, затем признаки согласуются между собой, а порог уверенности отсекает то, что система не должна додумывать за человека — такие данные помечаются как требующие проверки, а не уходят дальше молча. Ниже разбираем, как это собирается.
Что даёт единая мультимодальная AI вместо набора сервисов
Когда текст, изображения и аудио живут в трёх отдельных сервисах, каждый стык между ними — ручная работа: документ распознают в одном месте, реквизиты переносят во второе, расшифровку звонка приклеивают в третьем.
На каждой склейке теряется контекст и появляется класс ошибок, которого не видит ни один из сервисов: сумма в счёте и сумма в письме расходятся, а сверить их некому — расхождение всплывает уже на финальном разборе.
В единой мультимодальной системе модальности сходятся на общем слое представлений: текст, изображение и звук приводятся к сопоставимому виду, и модель разбирает фрагмент целиком, а не три разрозненных ответа. Речь переводим в текст отдельным слоем — здесь опираемся на открытую модель Whisper, — но результат попадает в тот же сквозной поток данных, что и поля документа.
За счёт этого ручные перекладки уходят: вместо сверки данных из трёх источников вручную остаётся проверка спорных случаев. Доля ошибок на стыке каналов падает в разы — расхождение между модальностями ловится автоматически и помечается как подозрение, а не проходит дальше по процессу.
Время отклика определяется уже не скоростью отдельной модели, а исчезновением каскада: модальности обрабатываются параллельно и сходятся в одной точке, без последовательных запросов с ожиданием на каждом шаге.
Режимы работы: облако, закрытый контур, гибридная схема
Выбор режима определяется не мощностью оборудования, а двумя вопросами: какие данные разрешено выносить за периметр и насколько критична задержка ответа. У мультимодальной системы потоки разные — расшифровка речи чувствительна к задержке, а разбор архива сканов спокойно уходит в ночную пакетную обработку.
Переключение между режимами не означает переписывания системы. Логика обработки остаётся единой, меняется слой исполнения: где физически живут модели, где хранятся промежуточные артефакты распознавания и куда пишется журнал запросов.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Облачное размещение | Нужен быстрый старт, пики нагрузки непредсказуемы, ограничения по данным позволяют внешнюю обработку | Зависимость от канала связи; передачу данных нужно обосновать юридически |
| Закрытый контур | Персональные данные, коммерческая тайна, требования регулятора | Ресурсы фиксированы: пик выше расчётного придётся переждать, масштабирование — закупкой |
| Гибридная схема | Часть сценариев публичная, часть — чувствительная | Дороже в поддержке: два контура, две политики обновлений, синхронизация весов моделей |
| Локальные модели на объекте | Нужна работа без связи, задержка критична | Модели компактнее — на сложных сценариях качество ниже, обновления ставятся вручную |
Границы между режимами задаются на уровне отдельных потоков, а не всей системы: чувствительный аудиопоток остаётся внутри, а генерация текстов уходит наружу.
Этапы внедрения: от аудита данных до передачи в работу
Мультимодальная система не собирается из готовых блоков: текст, изображения и аудио приходят с разным качеством, а на выходе нужен один согласованный ответ. Поэтому работа идёт этапами, и каждый заканчивается артефактом, который проверяется до перехода к следующему — иначе дефект в данных всплывёт уже в эксплуатации.
- Аудит данных. Смотрим объёмы по каждой модальности, долю ручной разметки, брак и пропуски, рассинхрон между текстом и приложенным изображением или записью.
- Согласование критериев качества. Договариваемся, что считаем верным ответом и какие ошибки критичны: ложное срабатывание, пропуск, неверно определённая модальность.
- Проектирование схемы. Решаем, как модальности сходятся в одну цепочку: где распознавание речи, где разбор текста, где изображение и в какой точке результаты объединяются.
- Настройка моделей. Подбираем базовые модели под задачу, дообучаем на подготовленных данных, задаём пороги срабатывания и правила для спорных случаев.
- Проверка качества. Прогоняем на отложенном наборе и на срезах по модальностям, разбираем ошибки и при необходимости возвращаемся к разметке или к схеме.
- Передача в эксплуатацию. Отдаём конфигурации, описание схемы, регламент обновления моделей и порядок отката на предыдущую версию.
- Обучение команды. Показываем, как читать метрики и журналы работы, что делать, если качество просело после поступления новых данных.
На выходе заказчик получает не набор разрозненных скриптов, а систему с понятными границами применимости, измеряемым качеством и точками контроля на каждом слое.
Что остаётся у заказчика: схемы, настройки и регламенты
После запуска система живёт без разработчиков, поэтому всё, что определяет её поведение, должно быть воспроизводимо на стороне заказчика. Передаём не «работающий сервис», а полный комплект: без него любая правка превращается в обращение к подрядчику, а откат — в поиск того, кто помнит исходные параметры. Состав фиксируем в акте приёмки и проверяем на стенде заказчика.
- Схема системы: контуры обработки текста, изображений и аудио, потоки данных между сервисами, точки хранения и внешние вызовы с привязкой к сетевым сегментам.
- Конфигурации по средам: тестовый, предпродуктивный и рабочий наборы параметров, включая пороги уверенности моделей, правила маршрутизации модальностей и лимиты очередей.
- Политики доступа: роли, права на хранилища и индексы, сервисные учётные записи и порядок ротации ключей без остановки обработки.
- Схема данных: форматы на входе и выходе, сроки хранения сырых файлов, перечень полей, которые маскируются перед записью в журналы.
- Документация: описание контуров, инструкции по типовым операциям, известные ограничения моделей и границы, за которыми качество ответа падает.
- Регламент разбора инцидентов: как фиксируется сбой, какие журналы и трассировки смотреть, кто принимает решение об откате версии модели.
- Регламент обновления: порядок выката новых версий и шаблонов запросов, набор проверочных сценариев и критерий, при котором обновление откатывается.
Приёмка идёт по сценариям: прогоняем типовые и пограничные случаи, сверяем метрики качества и время восстановления после учебного сбоя. Обучение команды заказчика — часть передачи, а не отдельная опция.
Кейс: заявки с фото и голосом в одном потоке обработки
Клиент — сервисная компания с распределённой сетью точек: в сутки приходит несколько сотен обращений, и почти половина из них не чистый текст. Клиент прикладывает фото дефекта, записывает голосовое сообщение, дописывает комментарий словами. Оператор разбирал это вручную: читал текст, рассматривал снимок, прослушивал аудио — в среднем 14 минут на заявку, а к концу смены доля ошибок в классификации доходила до 18%.
| Метрика | До | После |
|---|---|---|
| Время разбора заявки | 14 минут | 4 минуты |
| Доля ошибок в классификации | 18% | 3% |
| Заявки, требующие ручного разбора | 100% | 28% |
Что собрали
Текст, изображение и аудио теперь попадают в одну точку входа, приводятся к общему виду и обрабатываются под одним идентификатором обращения. Расшифровка речи идёт через Whisper, классификация снимка — отдельной моделью, поверх работает слой правил: он расставляет приоритет по типу дефекта и срочности. Оператор получает уже размеченную заявку и подтверждает решение, а не собирает его с нуля.
Ошибочные разборы упали с 18% до 3% — сказалось то, что модальности больше не конфликтуют: голос и фото оказываются в одной карточке, а не в разных системах. Ручной разбор остался там, где уверенность модели ниже порога, — это 28% заявок, и именно на них уходит освободившееся время операторов. Время первичного разбора сократилось с 14 до 4 минут, а пиковые часы больше не требуют вывода дополнительной смены.
Что делать, если часть данных уже размечена вручную?
Размеченные вручную данные не выбрасываем — они становятся опорным набором для новой системы. Сначала собираем паспорт разметки: словарь классов, правила отнесения к каждому, список спорных примеров и договорённости по ним. Если такого документа нет, восстанавливаем его по самим аннотациям и разговорам с теми, кто размечал.
Дальше перенос. Конвертер сопоставляет поля текущего хранилища со схемой новой системы, а совместимость проверяем на пересечении — берём примеры, размеченные двумя людьми независимо, и смотрим, совпадает ли результат после переноса. Классы, которых нет в новой схеме, не удаляем, а выносим отдельным слоем: часть пойдёт в дообучение как есть, часть — как подсказка разметчику.
Дообучение строим итерациями: старые аннотации задают стартовое качество, новые порции добавляем и после каждой сверяем метрики на отложенной части. Ручная работа постепенно смещается с простых случаев на сложные — доля ручной разметки падает, а качество на базовых классах не проседает.
Переход делаем параллельным: старый и новый процесс идут на одном потоке документов, результаты сравниваются на одних и тех же примерах, переключаем по частям — сначала один тип данных, потом остальные. Откат к прежнему процессу возможен до последнего шага.
Миграция процесса — это регламент: кто размечает, кто проверяет, что считается спорным и куда уходит. Инструменты можно оставить прежние, если они отдают выгрузки; для новых типов данных разворачиваем Label Studio и переносим правила туда же.
Частые технические сомнения перед началом работы
Перед стартом инженеры и руководители направлений задают почти один и тот же набор вопросов — про данные, качество распознавания, интеграции и ответственность после передачи. Ниже — ответы в том виде, в каком мы даём их на технических сессиях, без обтекаемых формулировок.
В каком контуре работают данные?
Система разворачивается в вашем окружении и не отправляет файлы во внешние сервисы. Доступ разграничивается по ролям, обращения к хранилищу журналируются, а срок хранения задаётся политикой под требования вашей службы безопасности.
Какой точности ждать на наших материалах?
Публичные метрики модели мало говорят о вашем потоке, поэтому качество считаем на пилотной выборке из ваших текстов, изображений и записей. Фиксируем долю операций, проходящих без ручной правки, и отдельно — критичный для вас класс ошибок.
Что будет, когда модель устареет?
Версия модели закрепляется, качество отслеживается на контрольной выборке. Когда метрики проседают, запускаем дообучение на накопленных примерах: обновление проходит ту же проверку, что и первый релиз, и в любой момент возможен откат.
Как это встроится в наши процессы и кто отвечает после запуска?
Точки стыковки определяем на обследовании: программный интерфейс, очереди или файловый обмен — под то, что уже работает у вас. Передаём конфигурации, схемы и регламент эксплуатации, обучаем вашу команду, даём гарантию на исправление дефектов и ведём сопровождение с контролем метрик.
Обсудим задачу: что уточнить на первом созвоне
Первый созвон нужен не для презентации, а чтобы собрать вводные, без которых оценка мультимодальной AI-системы превращается в гадание. По опыту, вот этого набора данных хватает, чтобы вернуться с планом работ, оценкой сроков и составом команды под конкретный контур.
- Модальности и данные: что на входе — текст, изображения, аудио, в каком соотношении, есть ли разметка и в каком объёме.
- Метрика качества: какая доля ошибок считается приемлемой и на какой выборке её считаем.
- Инфраструктура и доступы: облако или закрытый контур, требования к изоляции данных, кто выдаёт доступы.
- Интеграции: с чем связываем — хранилище, очереди, учётные системы, куда уходит результат.
- Нагрузка: сколько запросов в пике, какая задержка ответа критична, нужна ли пакетная обработка.
- Границы первой версии: что обязательно в первом запуске, а что можно отложить без потери смысла.
- Приёмка: кто со стороны заказчика принимает результат и по какому сценарию проверяем.
После обсуждения задачи возвращаемся с планом работ по этапам, оценкой сроков с запасом на дообучение и настройку качества, составом команды и явно описанным следующим шагом. Дальше — короткая проверка на ваших данных, чтобы оценка опиралась на замеры, а не на предположения.
