Нормализация реплик удешевляет аналитику миллионов звонков: пайплайн целиком на малых моделях

Корпоративная аналитика разговоров упирается в простую арифметику: вопросов к транскриптам много, а самих транскриптов миллионы. Каждый вопрос, например «предлагал ли оператор скидку» или «почему клиент отказался», заставляет модель заново расшифровывать, что люди имели в виду, и искать нужные фрагменты. Работа из arXiv cs.CL (2610.10758) предлагает вынести эту интерпретацию в отдельный общий слой. Принцип авторы формулируют так: сначала уточни текст, потом сфокусируй читателя.

Как устроена нормализация

Statement normalization превращает сырой диалог в набор коротких утверждений. Каждое привязано к говорящему, содержит ссылку на исходное место в разговоре и несёт семантические теги. Неявное становится явным: вместо обрывка реплики с местоимениями и недосказанностью появляется самодостаточная фраза.

Теги работают как индекс. Под конкретный вопрос из всего набора выбирается только релевантное подмножество. Следующая модель получает либо полное представление, либо урезанное, в зависимости от того, что ей помогает принять решение.

Главное архитектурное следствие: подготовка делается один раз и обслуживает любое число вопросов к тем же звонкам. Дорогая интерпретация перестаёт повторяться.

• Вход: диалог клиентской поддержки.
• Выход: короткие утверждения с атрибуцией говорящего, ссылкой на источник и тегами.
• Нормализацию выполняет небольшая модель, обученная под заданный формат («контракт нормализации»).
• Теги и итоговые решения обрабатывают лёгкие энкодеры.
• Отбор доказательств опционален: можно подавать всё или только релевантное.

Что показал эксперимент

Проверка шла на задаче offer-suppression в звонках клиентской поддержки. Речь о случаях, когда предложение по какой-то причине не прозвучало или было подавлено. Для такого вывода мало одной реплики: нужно понимать контекст и роли участников.

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

Числовых метрик в абстракте нет. Ни прироста качества, ни точной экономии авторы там не приводят, поэтому «существенно дешевле» пока остаётся заявлением, которое нужно проверять по полному тексту статьи. Это один препринт и одна задача в одном домене, обобщать результат на любые разговоры рано.

Что делать командам, которые анализируют звонки

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

Минимальный план пилота выглядит так:

• Определите схему утверждений: поля говорящего, ссылки на источник и набор тегов под ваши типы вопросов.
• Разметьте небольшой набор диалогов (или сгенерируйте разметку сильной моделью) и обучите малую модель следовать этой схеме.
• Сравните три режима на одной задаче: сырой текст, полная нормализация, нормализация с отбором по тегам.
• Если читатель у вас обученный классификатор, проверьте, нужен ли отбор вообще. Для слабых промптовых моделей он, судя по статье, критичнее.

Ссылки на источник в каждом утверждении пригодятся и вне экономии: аудитор или менеджер сможет за секунды проверить, на каком месте разговора основан вывод. Для регулируемых отраслей это не мелочь. Окончательно судить о ценности подхода можно будет, когда станут известны полные цифры и сравнение с базовыми пайплайнами на больших LLM.