Google випустив Gemini 3.5 Transcribe — оновлений сервіс перетворення мовлення на текст, який підтримує 85 мов і вміє автоматично виправляти мовні застереження та обмовки просто під час розпізнавання. За даними The Decoder, модель орієнтована саме на живу розмовну мову — з паузами, самокорекціями та незакінченими фразами, які традиційні STT-системи зазвичай транскрибують дослівно, включно з помилками мовця.

Для розробників це означає одне: ще один пункт у списку «не будувати самому». Автокорекція обмовок — це та частина voice-конвеєра, яку зазвичай доводилося докручувати вручну постобробкою через LLM після базового розпізнавання. Якщо Gemini 3.5 Transcribe справді робить це в одному проході, це прибирає окремий крок з пайплайна і скорочує затримку.

Ринок STT давно не про «чи розпізнає слова правильно» — з цим і Whisper від OpenAI, і Google Speech-to-Text, і Azure Speech впораються непогано. Конкуренція перемістилась у площину «наскільки чистий і готовий до використання текст на виході без додаткової обробки». Саме сюди і б'є новий реліз.

Що саме випустив Google?

Google представив оновлений сервіс транскрибації Gemini 3.5 Transcribe, який автоматично виправляє мовні застереження й обмовки просто в процесі розпізнавання мови. Сервіс охоплює 85 мов і, судячи з опису, спроєктований під живу розмовну мову — тобто типове мовлення людини з повторами, самопоправками, паузами-хезитаціями кшталт «е-е, я хотів сказати», а не начитаний дикторський текст.

Це принципова відмінність від класичного підходу до транскрибації, де модель фіксує все, що почула, буквально: обмовки, повтори слів, незакінчені речення. Такий «сирий» транскрипт потім доводиться чистити окремим кроком — або вручну, або пропускаючи через LLM для приведення до читабельного вигляду. Gemini 3.5 Transcribe, судячи з опису, бере цю функцію на себе одразу.

Як автокорекція обмовок міняє архітектуру voice-пайплайна?

На практиці типовий voice-first продукт сьогодні складається з кількох послідовних кроків: захоплення аудіо → STT → нормалізація тексту (прибрати «е-е», повтори, поправки) → NLU/LLM-обробка → відповідь. Другий і третій крок часто виконуються різними інструментами, а це додає затримку і ще одну точку відмови в конвеєрі.

Якщо автокорекція вбудована в саму модель транскрибації, крок нормалізації тексту фактично зникає з пайплайна. Для розробника це означає:

Наскільки суттєвим буде виграш у затримці, залежить від того, як саме реалізована автокорекція — прямо в моделі транскрибації чи як окремий внутрішній прохід на боці Google. The Decoder цієї деталі не розкриває, тож тут варто дочекатися бенчмарків від незалежних розробників.

Кому це реально полегшить роботу?

Найбільше виграють команди, що будують voice-first продукти з нуля і не мають ресурсів на власний STT-стек: голосові асистенти, транскрибація дзвінків у контакт-центрах, диктування для нотаток і документів, субтитрування живого відео. Для них Gemini 3.5 Transcribe — це готовий блок, який можна підключити й одразу отримати прийнятну якість на 85 мовах, включно з менш поширеними.

Менше виграють команди, яким потрібен контроль над сирим транскриптом — наприклад, у сфері модерації контенту чи лінгвістичних досліджень, де саме обмовки й самокорекції мовця є значущими даними, а не шумом, який треба прибрати.

Варто також пам'ятати: Google вже інтегрував ту саму модель транскрибації безпосередньо в Chrome — про це ми писали окремо, розбираючи, чи означає це кінець епохи окремих API для голосу. Тобто модель існує не лише як окремий API-сервіс, а й як вбудована функція браузера — і це розширює її потенційну аудиторію далеко за межі розробників, які свідомо обирають STT-провайдера.

Висновок AiiN: що з цим робити зараз

Наша теза: Gemini 3.5 Transcribe закриває проблему, яку раніше вирішували костилями поверх STT-моделей — LLM-постобробку сирого транскрипту тепер можна прибрати з пайплайна, якщо якість автокорекції підтвердиться на реальних даних. Для команд, що на стадії прототипування voice-продукту, це означає на один інтеграційний крок і одну точку відмови менше — головна практична цінність саме тут, а не в сирій точності розпізнавання, де різниця між провідними моделями вже мінімальна.

Порада практикам: перш ніж переписувати існуючий voice-пайплайн під нову модель, варто прогнати власний набір реальних записів (з акцентами, шумом, специфічною термінологією проєкту) і порівняти вихід Gemini 3.5 Transcribe з поточним рішенням на конкретних метриках — WER (word error rate) і суб'єктивній читабельності тексту. Універсальних 85-мовних бенчмарків від незалежних сторін поки не було, тому найнадійніший тест — власні дані.

Чим Gemini 3.5 Transcribe відрізняється від класичного Google Speech-to-Text?

Головна заявлена відмінність — автоматична корекція мовних застережень і обмовок прямо під час розпізнавання, орієнтація на живу розмовну мову, а не лише на чисто начитаний текст. Класичні STT-сервіси зазвичай фіксують мовлення дослівно, включно з помилками.

Чи підходить сервіс для української мови?

Офіційний список із 85 підтримуваних мов The Decoder наводить без деталізації по кожній мові окремо, тому конкретну якість розпізнавання української варто перевіряти на власних аудіозаписах, а не покладатися на загальну заяву про кількість мов.

Чи потрібен тепер власний STT-стек для voice-first продукту?

Для швидкого прототипу — необов'язково: готовий сервіс на 85 мов з автокорекцією закриває більшість базових сценаріїв. Власний стек залишається виправданим там, де потрібен контроль над сирими даними, специфічна термінологія або офлайн-обробка з міркувань приватності.