Проблема с озвучкой чисел, дат и адресов на техническом уровне называется нормализацией текста — процессом преобразования нестандартных письменных форм (цифр, сокращений, символов) в развёрнутую словесную запись, которую модель синтеза может произнести как обычную речь. Человек, читая «25», интуитивно понимает из контекста, что это «двадцать пять» рублей, «двадцать пятое» число или «два — пять» как часть номера телефона. Модель синтеза такого контекста по умолчанию не имеет и вынуждена статистически угадывать наиболее вероятный вариант — а угадывает она не всегда правильно.
Именно на этапе нормализации возникает большинство «роботизированных» артефактов озвучки: не в самом качестве синтезированного голоса, а в том, что модель выбрала не ту интерпретацию цифровой последовательности. Хорошо натренированная модель может звучать абсолютно естественно на разговорном тексте и тут же «спотыкаться» или читать неправильно ровно в тот момент, когда в тексте встречается число, дата или адрес — потому что для этих элементов недостаточно фонетической модели произношения, нужна ещё и корректная интерпретация смысла.
Показательный пример разночтения — число «1/2». В зависимости от контекста оно может означать дробь «одна вторая», дату «первое февраля» (в американском формате) или просто последовательность «один, слэш, два» при чтении технического обозначения. Без явного указания модель выбирает вариант на основе статистически наиболее частого употребления в обучающих данных, что не гарантирует совпадения с тем, что имел в виду автор конкретного текста.
Технически большинство современных TTS-движков используют для нормализации либо предобученные лингвистические правила для конкретного языка, либо отдельную языковую модель, которая анализирует окружающий текст, чтобы определить наиболее вероятную интерпретацию числа. Второй подход даёт более контекстно-зависимый результат, но всё равно ошибается на пограничных случаях — именно поэтому большинство профессиональных TTS-платформ, включая Amazon Polly, Google Cloud Text-to-Speech и Microsoft Azure Speech, предоставляют разработчику возможность вручную указать модели, как именно интерпретировать конкретную числовую последовательность, через тег <say-as> в SSML-разметке.
Что говорит статистика ошибок нормализации
Разработчики систем синтеза речи, публикующие данные о качестве нормализации, отмечают, что основная доля ошибок произношения в готовых аудиоматериалах приходится именно на нестандартные слова — числа, аббревиатуры, даты и единицы измерения, — а не на обычную лексику естественного языка. Для сравнения: словарный запас разговорной речи модель воспроизводит с точностью, близкой к 99%, тогда как для чисел и специфических форматов процент точной интерпретации без явной разметки заметно ниже и сильно варьируется в зависимости от языка и формата конкретного числа.
Даты: главная ловушка международной локализации
Дата — один из самых неоднозначных типов данных для автоматического синтеза, потому что формат её записи различается по регионам, а визуально идентичная последовательность цифр может означать совершенно разные даты. Классический пример — «03.08.2026»: в российском и большинстве европейских форматов это третье августа, а в американском формате mm/dd/yyyy та же последовательность цифр читается как тридцатое августа быть не может (в августе нет 30 дней при таком написании) — но более безобидный пример вроде «04.05.2026» уже двусмысленен: это может быть и четвёртое мая, и пятое апреля, в зависимости от того, какой региональный формат подразумевался.
Без явного указания формата модель синтеза ориентируется на локаль, установленную для голоса и языка озвучки, но эта локаль не всегда совпадает с намерением автора текста — особенно если текст написан для международной аудитории или скопирован из источника с другим региональным форматом дат. Тег <say-as interpret-as="date" format="dmy"> в SSML снимает эту двусмысленность, явно указывая модели, что перед ней день-месяц-год, а не месяц-день-год: например, конструкция <say-as interpret-as="date" format="dmy">03.08.2026</say-as> гарантированно прочитается как «третье августа две тысячи двадцать шестого года» независимо от того, какая локаль установлена для самого голоса.
Отдельная сложность — озвучка диапазонов дат и относительных временных указаний. Формулировка вроде «в период с 01.03 по 15.04» требует, чтобы модель дважды корректно применила формат даты, но при этом не добавила лишнего слова «года» к обеим датам, если год общий и указан только один раз в конце фразы. На практике такие конструкции стоит проверять отдельно, поскольку автоматическая нормализация диапазонов дат — одна из областей, где даже продвинутые модели чаще дают сбой по сравнению с одиночными датами.
Как избежать двусмысленности при подготовке текста
Помимо явной разметки через <say-as>, есть более простой и надёжный способ снять неоднозначность формата дат — писать месяц словом там, где это уместно по стилю текста: «3 августа 2026 года» вместо «03.08.2026». Такая запись не требует дополнительной SSML-разметки, потому что не содержит цифровой неоднозначности изначально, а для модели синтеза словесная запись месяца интерпретируется однозначно на любом языке.
Для текстов, где числовой формат даты необходим по стилистическим причинам — например, в официальных документах, финансовых отчётах или юридических материалах, — явная SSML-разметка остаётся единственным надёжным способом гарантировать правильное произношение, особенно если материал впоследствии будет переведён и озвучен на нескольких языках с разными региональными стандартами записи дат.
Большие числа, суммы и разделители разрядов
Разделители тысяч и десятичных дробей — ещё один источник разночтений, поскольку они устроены по-разному даже в пределах Европы. В английском и большинстве международных стандартов запятая разделяет тысячи, а точка — десятичную дробь: «1,234.56» читается как «одна тысяча двести тридцать четыре целых пятьдесят шесть сотых». В немецком, испанском и многих других европейских языках правило обратное: точка разделяет тысячи, а запятая — десятичную дробь, то есть та же величина записывается как «1.234,56». В русском и французском для разделения тысяч традиционно используется неразрывный пробел, а не точка или запятая: «1 234,56».
Если текст с числами подготовлен под один региональный стандарт, а озвучивается моделью, настроенной на другую локаль, число может быть интерпретировано с ошибкой на три порядка — например, «1.234» в немецком формате означает «одна тысяча двести тридцать четыре», но модель, ориентированная на английский стандарт, может прочитать ту же запись как «один целых двести тридцать четыре тысячных». Для финансовых и технических материалов, где точность передачи величины критична, подобная ошибка не просто портит впечатление от озвучки, а искажает фактическую информацию.
Отдельная категория — округлённые большие числа с приставками вроде «млн» и «тыс.». Сокращение само по себе не всегда однозначно интерпретируется моделью синтеза: без предварительного разворачивания в словесную форму («2,5 млн» → «два с половиной миллиона») некоторые модели читают сокращение побуквенно или пропускают вовсе. Наиболее надёжный подход — там, где приемлемо по стилю, разворачивать подобные сокращения в тексте заранее, а не полагаться на автоматическую интерпретацию.
Проценты и валюта требуют похожего внимания: символ «%» обычно нормализуется корректно как «процент» на большинстве языков, но порядок слов при чтении суммы с валютой различается — «$50» на английском читается как «fifty dollars» (число перед единицей), тогда как «50 ₽» на русском естественно звучит как «пятьдесят рублей», и модель должна учитывать эту разницу в порядке при локализации одного и того же текста на разные языки. Тег <say-as interpret-as="currency">, где он поддерживается платформой, помогает явно зафиксировать корректную интерпретацию суммы независимо от того, как записан сам числовой формат в исходном тексте.
Телефонные номера, индексы и технические коды
Телефонные номера, почтовые индексы и другие длинные цифровые последовательности озвучиваются принципиально иначе, чем количественные числа: их не нужно интерпретировать как единую величину, а нужно произнести поразрядно, цифра за цифрой, с естественными паузами между смысловыми группами. Номер «+7 495 123-45-67» при неправильной нормализации модель может попытаться прочитать как одно огромное число — «семь миллиардов четыреста девяносто пять миллионов...» — что звучит абсурдно и совершенно не соответствует тому, как человек воспринимает телефонный номер на слух.
Для подобных случаев в SSML предусмотрен специализированный формат интерпретации <say-as interpret-as="telephone">, который явно указывает модели читать последовательность как номер телефона — поразрядно, с паузами на границах групп цифр, соответствующих коду страны, кода региона и самому номеру. Там, где отдельный формат telephone недоступен в конкретном сервисе, альтернативой служит побуквенная интерпретация через <say-as interpret-as="characters">, которая заставляет модель читать каждый символ последовательности отдельно, не пытаясь интерпретировать её как единое число.
Похожая логика применима к почтовым индексам, номерам банковских карт, VIN-кодам автомобилей и другим структурированным цифробуквенным последовательностям. Индекс «101000» в контексте почтового адреса должен звучать как «один, ноль, один, ноль, ноль, ноль», а не как «сто одна тысяча» — и без явного указания формата модель, ориентированная на количественную интерпретацию чисел по умолчанию, скорее выберет второй, ошибочный вариант.
Группировка цифр для естественного звучания
Помимо выбора корректного типа интерпретации, на естественность звучания влияет и способ группировки цифр внутри самого текста. Номер, записанный сплошной строкой без разделителей — «74951234567» — заставляет модель либо угадывать логичные границы групп самостоятельно, либо читать все одиннадцать цифр монотонно подряд без пауз. Тот же номер, заранее отформатированный с дефисами, пробелами или скобками по стандартной для страны схеме записи — «+7 (495) 123-45-67» — даёт модели явные визуальные подсказки о естественных границах пауз, что заметно улучшает звучание даже без дополнительной SSML-разметки поверх текста.
Адреса: сокращения и порядок слов
Адреса объединяют сразу несколько источников потенциальных ошибок озвучки: сокращения, числа и региональные различия в порядке следования элементов адреса. Русскоязычный адрес традиционно содержит множество сокращений — «ул.», «д.», «кв.», «просп.», «наб.» — которые при неправильной нормализации модель может прочитать побуквенно как аббревиатуру вместо разворачивания в полное слово «улица», «дом», «квартира», «проспект», «набережная». Для голосовых интерфейсов, озвучивающих адреса доставки или геолокацию, подобная ошибка сразу выдаёт в системе недостаточно проработанную локализацию.
Наиболее надёжный способ избежать этой проблемы — разворачивать стандартные адресные сокращения в тексте заранее, до отправки на озвучку, а не полагаться на автоматическую нормализацию модели. Это особенно важно для голосовых ассистентов и IVR-систем, которые часто получают адрес из базы данных в сокращённом виде и должны озвучить его в реальном времени: здесь имеет смысл заложить отдельный этап предобработки текста, который заменяет стандартный набор сокращений на полные словесные формы ещё до передачи текста в модель синтеза.
Порядок следования элементов адреса тоже различается между языками и странами, что критично при локализации одного и того же адреса для разных языковых версий продукта. В российском формате адрес обычно записывается от общего к частному в письменной форме, но при устном произношении естественнее звучит порядок от частного к общему — сначала улица и дом, затем город. В американском формате, напротив, принят строгий порядок «номер дома, улица, город, штат, индекс», и механическое сохранение русского порядка слов при озвучке переведённого на английский адреса даёт неестественно звучащую, «переводческую» речь, даже если сами слова переведены правильно.
Числовые компоненты адреса — номер дома, корпус, квартира — также требуют отдельного внимания к формату произношения. Номер дома «7к2» или «15/3» на слух должен читаться как «дом семь, корпус два» или «дом пятнадцать дробь три», а не как единое число или последовательность отдельных символов — и здесь снова оправдано либо предварительное разворачивание записи в словесную форму, либо явная SSML-разметка через <say-as> для той части адреса, которая содержит нестандартное числовое обозначение.