DiDi повысила точность проверки обращений с 38% до 86% на Amazon Bedrock

Три конвейера вместо закрытого внешнего сервиса

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

Новая архитектура делит работу на три независимых конвейера. Intent pipeline проверяет выбранную оператором причину обращения и предлагает другую категорию при ошибке. Evaluation pipeline оценивает соблюдение стандартов и извлекает бизнес-показатели. Voice of Customer, или VOC, объединяет большие серии похожих обращений и ищет растущие системные проблемы.

По данным production validation DiDi, точность проверки intent выросла с 38% до 86%, средняя точность compliance scoring превысила 90%, а анализ трендов VOC сократился с нескольких часов ручной работы до нескольких минут. Это показатели конкретной внутренней системы и её набора данных, а не независимый универсальный benchmark Amazon Bedrock.

Полное дерево категорий оказалось лишним контекстом

Первый вариант intent-проверки выглядел логично: показать модели разговор и всё дерево Contact Reason. На практике модель начинала последовательно сравнивать варианты и нередко отвергала разумную текущую метку, если замечала лишь немного более точную. Многократная настройка промпта проблему не устранила, поэтому команда изменила не формулировку инструкции, а состав доступной информации.

Для обычной категории процесс разделили на два этапа. Сначала модель видит только разговор и текущую метку и отвечает, допустима ли она. Полное дерево категорий открывается лишь после отрицательного решения: тогда модель предлагает замену, confidence score и обоснование. Так поиск более узкого варианта больше не вмешивается в исходную проверку.

Обращения с меткой Other идут по отдельному маршруту. Система сначала ищет подходящую метку среди соседних категорий, затем во всём дереве, а если соответствия нет — фиксирует пробел в таксономии и предлагает новую метку. Поэтому QA здесь контролирует не только сотрудников, но и качество самого справочника причин обращения.

Один шаблон собирается из языка, бизнеса и правил

Для compliance-оценки DiDi не стала поддерживать отдельный промпт для каждого сочетания языка, бизнес-линии и критерия. Определения, правила принятия решения и локальный контекст хранятся как внешние конфигурации, а единый шаблон динамически собирается по метаданным обращения. Добавление языка или проверки требует изменить конфигурацию, а не размножать целую систему инструкций.

Amazon Bedrock Tool Use ограничивает ответ схемой структурированного JSON: у каждой оценки есть само решение и reasoning chain. Однако модель не получает монополию на вычислимые факты. Время ожидания ответа рассчитывает обычный код, а заявленные орфографические ошибки перепроверяются только по сообщениям оператора и сравниваются с детерминированным порогом.

Такое разделение полезно для аудита: семантическая оценка остаётся задачей LLM, но счётчики и однозначные правила не зависят от её арифметики или внимания. Полная цепочка аргументации помогает человеку разбирать спорные результаты. При этом название reasoning chain не означает доказанную истинность каждого объяснения — итог всё равно требует мониторинга и выборочной проверки.

VOC сначала извлекает факты, затем объединяет темы

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

Затем embedding model сравнивает названия проблем, объединяет синонимичные формулировки и ранжирует кластеры по частоте. На этой стадии используются расстояния между векторами и статистический подсчёт, а не новый генеративный ответ, поэтому результат можно воспроизвести. Только после этого LLM превращает наиболее частые кластеры в отчёт с резюме, анализом боли и рекомендациями.

В описанном кейсе всплеск жалоб на cancellation fee в странах Латинской Америки был разобран за минуты: система выделила основные причины и повторяющиеся сценарии. Но частотный кластер показывает корреляцию в обращениях, а не автоматически установленную первопричину бизнеса. Рекомендации нужно сопоставлять с операционными данными и результатами последующих изменений.

Надёжность строится за пределами промпта

До отправки в модель Amazon Bedrock Guardrails маскирует персональные данные и применяет contextual grounding checks. Доступ к инфраструктуре ограничен через VPC endpoints, AWS PrivateLink и IAM, а данные шифруются при передаче и хранении. Это даёт команде контролируемый контур, которого не хватало при работе с закрытым сторонним решением.

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

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