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