DiDi удвоила точность проверки интентов, скрыв альтернативы

Дополнительный контекст часто считают безусловным улучшением ИИ-системы. Дайте модели полную карточку клиента, все правила, все доступные категории — и решение должно стать лучше. Производственный кейс контакт-центра DiDi указывает на более полезное правило: информация, нужная для исправления решения, может исказить проверку того, было ли это решение приемлемым изначально.

В системе проверки интентов International Business Group компании DiDi сообщила о росте точности валидации с 38% до 86% после того, как на первом шаге модели стали показывать меньше. Это не независимый бенчмарк: публичный материал не раскрывает размер выборки, распределение классов, доверительные интервалы или внешний аудит. Но это всё же редкий конкретный производственный пример: в нём описаны неудачный первый вариант, его замена и измеренный результат до и после.

Главный вывод не в том, что моделям в целом нужно давать меньше контекста. Проверка и переклассификация — разные задачи. Когда альтернативы показаны слишком рано, вторая задача способна исказить первую.

Первый вариант одновременно задавал два вопроса

DiDi создала три производственных конвейера для испано- и португалоязычной поддержки в сервисах поездок, доставки еды и финансовых услуг: проверку интента, оценку соблюдения требований и анализ Voice of Customer. Конвейер проверки интента отвечает на вопрос, соответствует ли назначенная человеком причина обращения содержанию диалога.

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

Это типичная продуктовая ошибка, замаскированная под проблему промпта. От модели требовали бинарной оценки — подходит ли текущая метка? — одновременно предоставляя ей задачу сравнительной оптимизации — какая метка из доступных лучше? «Приемлемая» и «лучшая из возможных» — не один и тот же стандарт. В таксономии разрыв особенно заметен: категории нередко пересекаются или отличаются степенью конкретности.

“Меню исправлений не является нейтральным доказательством для первичной проверки. Оно меняет само решение, которое должна принять модель.

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

Новая схема сохраняет первый вопрос

DiDi разделила процесс на проверку и классификацию. На первом этапе модель видит диалог и текущую метку, но не полную таксономию. Она оценивает метку по существу. Лишь если метка отклонена, второй этап получает всю таксономию и выбирает замену. После этой переработки DiDi сообщает о росте точности производственной валидации с 38% до 86%.

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

Это существенно, потому что этапы оптимизируют разные результаты. Проверка должна не отклонять приемлемую работу. Классификация должна найти наиболее подходящую альтернативу после отклонения. При объединении более строгий стандарт классификации незаметно становится стандартом приемки. При разделении стандарт становится явным, а задача каждого вызова — более узкой и понятной.

Применяйте этот паттерн там, где текущее решение нужно оценить честно

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

Проверка проектного решения проста: если показать все способы исправления, начнёт ли проверяющий оценивать имеющееся решение по излишне строгому стандарту? Если да, пространство исправлений следует скрыть до завершения проверки.

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

Детерминированным операциям — детерминированное место

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

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

Похожее разделение видно в процессе Voice of Customer от DiDi. Диалоги обрабатываются независимо; извлечённые метки проблем кластеризуются с помощью эмбеддингов и статистического ранжирования; затем по наиболее частотным кластерам создаётся отчёт. DiDi сообщает, что работа, занимавшая часы, стала занимать минуты. Система не требует от одного вызова прочитать весь корпус, выявить тенденции и написать отчёт. Она разделяет извлечение, группировку и коммуникацию.

Хорошая последовательность — не универсальное обещание производительности

К цифрам DiDi следует относиться аккуратно. Это заявленные компанией результаты производственной валидации, а не общее доказательство, что многоступенчатые промпты дадут такой же прирост в другой среде. Публичный материал не показывает, как результат меняется в зависимости от метки, языка, типа обращений или оценщика. Он также не доказывает, что улучшение вызвано именно Amazon Bedrock, а не изменением задач и порядка раскрытия информации.

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

Структурированный вывод может поддержать такую схему, но описывать его нужно точно. Amazon Bedrock поддерживает строгий структурированный вывод через соответствующие механизмы, включая документированную настройку strict для строгого использования инструментов. Принудительный выбор инструмента сам по себе нельзя представлять как универсальную гарантию соответствия строгой JSON-схеме. Контроль формата полезен, но он не исправляет неверную последовательность решения.

Сначала путь суждения, затем путь исправления

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

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