MICROSOFT-DECISION-1 · КЛАССИФИКАЦИЯ · ПРИЁМКА
Как проверить AI-классификатор на перестановке вариантов
Новая модель Microsoft даёт повод проверить незаметную ошибку автоматизации: обращение не должно менять очередь только потому, что исполнитель переставил варианты ответа.
Что изменилось 9 октября
9 октября 2026 года Microsoft представила Microsoft-Decision-1: модель выбирает из заданных вариантов и возвращает оценки вероятности для них. В анонсе Microsoft Foundry запуск обозначен как public preview. Это повод для проверки на своих примерах, а не подтверждение готовности заменить действующий процесс.
В техническом разборе Microsoft отдельно проверяет, меняется ли решение при перефразировании и перестановке вариантов. Компания проверила восемь типов изменений запроса и сообщает о средней доле смены решения 1,3% по этому набору проверок. Это результат набора проверок производителя; переносить его на обращения вашего бизнеса нельзя.
Для руководителя продаж полезный вопрос звучит проще: если исполнитель поменяет порядок отделов в запросе к модели, прежняя заявка останется у правильного сотрудника? Ниже — редакционный протокол такой приёмки. Он подходит для сравнения Microsoft-Decision-1 с уже используемым классификатором.
Зафиксируйте смысл маршрута до проверки модели
Условный интернет-магазин распределяет входящие обращения между новой продажей, изменением существующего заказа и ручным разбором. Клиент пишет: «По заказу 1842 нужно изменить адрес доставки». Номер заказа и его связь с клиентом в этом учебном примере уже проверены. Ожидаемый маршрут — сотрудник, который разбирает изменения заказа. Сам адрес при классификации не меняется.
Присвойте каждому маршруту постоянный идентификатор, например «изменение заказа». Позиция «второй пункт» таким идентификатором быть не должна. Сначала проверьте обычную программную связку: выбранный идентификатор попадает в нужную очередь даже после перестановки элементов. Иначе ошибка сопоставления будет выглядеть как ошибка модели.
Описание категорий, сведения о заказе и ожидаемый ответ фиксируются вместе. Общий выбор очередей и проверка перед действием уже разобраны в руководстве по Decisions API для заявок. Здесь оставляем короткий вход полностью сохранённым и меняем только представление списка вариантов и шаблона вопроса.
Соберите связанные пары, а не случайные разные заявки
Для каждого исходного обращения подготовьте несколько вариантов. Сотрудник, который знает процесс, должен подтвердить: факты и правильный маршрут в них одинаковы. Смена обещанного срока, номера заказа или отрицания уже меняет содержание задачи.
Порядок
Переставьте категории: сначала новая продажа, затем изменение заказа; потом наоборот. Идентификаторы и описания сохраняются.
Формулировка
Замените описание «запрос по изменению существующего заказа» на равнозначное. Не расширяйте полномочия и не убирайте условия.
Оформление
Поменяйте переносы строк и пробелы в шаблоне. Не удаляйте данные и не превращайте текст клиента в инструкцию системы.
Перед перестановками повторите полностью одинаковый запрос с неизменными настройками. Если ответы уже различаются, отмечайте эту базовую изменчивость отдельно: нельзя приписывать каждое дальнейшее расхождение порядку вариантов. Записывайте все повторы, без выбора только удачных результатов.
Сначала изменяйте один признак за раз: так проще понять причину расхождения. Затем проверьте сочетания изменений, которые действительно возникают в ваших шаблонах. Если переименовываете технические ключи, храните отдельное соответствие старого и нового ключа одному смысловому маршруту.
Добавьте контрольные случаи, в которых смысл действительно меняется. Например, «Хочу оформить новый заказ» должно проверять категорию новой продажи. Классификатор, который всегда выдаёт одну очередь, будет устойчив к перестановкам, но бесполезен для работы.
Составьте пары для обычных обращений, коротких сообщений, неоднозначных просьб и используемых клиентами языков. Не ограничивайтесь самым частым классом. При подготовке набора используйте обезличенные или вымышленные данные; условия передачи реальных обращений выбранному сервису нужно проверить отдельно.
Проверьте три результата отдельно
- Правильность. Совпадает ли маршрут с заранее размеченным ответом сотрудника? Стабильно неправильный ответ остаётся ошибкой.
- Устойчивость. Изменился ли смысловой маршрут между исходным запросом и равнозначным вариантом? Сравнивайте идентификаторы после сопоставления ключей, а не буквы или позиции в ответе.
- Работоспособность. Получен ли пригодный ответ вообще? Тайм-аут, отказ и неизвестный ключ фиксируются отдельно и не считаются правильным решением.
Как считать долю смены маршрута
Разделите число пар с разными смысловыми маршрутами на число пар, где оба ответа получены и корректно разобраны. Рядом обязательно покажите общее число пар и пары с технической ошибкой. Иначе исключение неудачных запросов может сделать результат привлекательнее, чем он есть.
Отдельно посчитайте обращения, у которых хотя бы один вариант дал другой маршрут. Одна нестабильная заявка с несколькими перестановками не должна теряться среди множества лёгких примеров. Также просмотрите ошибки по каждой очереди: неверная передача просьбы изменить доставку может стоить дороже, чем задержка общего вопроса о товаре.
Если автоматическая передача зависит от оценки вероятности, проверяйте и итоговый режим обработки. Маршрут может остаться прежним, но оценка пересечь ваш порог и перевести запрос с автоматической обработки на ручную. Порог подбирают на собственных размеченных случаях с учётом последствий ошибки; одинаковое число у разных моделей не означает одинаковое качество.
Сохраните исходный текст, номер семейства вариантов, версию шаблона и модели, ожидаемый маршрут, фактический ответ и длительность вызова. В разборе качества правил CRM объяснено, почему настройку и итоговую проверку разделяют. Для этого теста разделяйте их целыми семействами: все варианты одной заявки должны оставаться вместе. Иначе почти одинаковое обращение попадёт одновременно в настройку и контроль.
Что проверить у Microsoft-Decision-1 до такого теста
В каталоге Microsoft Learn указаны текстовый ввод до 32K токенов и отсутствие генерации объяснений. Модель не принимает изображения, аудио или видео. Поэтому классификация записи звонка требует отдельной расшифровки, а фотография повреждения не становится доступной модели от одного упоминания файла.
Зафиксируйте подготовленный вход до сравнения. Если одной модели дали полный текст, а другой сокращённый, эксперимент одновременно проверяет два разных процесса. Для длинной переписки отдельно нужен контроль обрезки истории обращения.
Проверьте доступность модели, условия обработки данных и квоту именно своего развёртывания в Foundry. Документация квот связывает лимиты запросов с уровнем подписки и выделенной ёмкостью. Пакет вариантов увеличивает количество вызовов, поэтому скорость единичного ответа ещё не показывает время выполнения всей проверки.
Бюджет: учитывайте все варианты и повторные вызовы
В публикации Microsoft указана цена $0,042 USD за миллион входных токенов; выходные токены не оплачиваются. Перед тестом сверяйте действующую цену и условия выбранного канала доступа. Это цена модельного ввода, а не полная стоимость интеграции.
Иллюстративный расчёт, не результат внедрения
Допустим, проверяются 10 000 обращений, каждое в шести версиях, включая исходную. Если каждый вызов содержит 2 000 оплачиваемых входных токенов, получится 60 000 вызовов и 120 млн токенов. По указанной ставке модельный ввод стоит $5,04 USD.
Повторные вызовы добавляются отдельно. В примере не учтены подготовка и разметка данных, расшифровка звонков, разработка, инфраструктура и работа проверяющих. Числа заданы только для показа арифметики.
Сравнивайте модели на одном наборе и при одинаковой полноте входа. Сначала проверьте качество и допустимую долю ручного разбора, затем стоимость. План постепенной замены модели можно взять из разбора перехода на новую модель для CRM-агента, предварительно согласовав его с реальной схемой подключения.
Приёмка: одинаковый смысл должен давать объяснимый результат
Попросите исполнителя показать исходную заявку, её равнозначные варианты и контроль с изменённым смыслом. Затем разберите каждое неожиданное переключение: ошибку ключа, неравнозначное описание, недостаток данных или нестабильность модели.
До исправления расхождений оставьте спорный участок на ручной проверке. Успех небольшого теста подтверждает только проверенные условия; после изменения шаблона, набора очередей или модели пары нужно прогнать снова.
Для процесса в CRM SABSUS такой протокол можно включить в требования к исполнителю: какие категории доступны, кто размечает примеры и каким журналом подтверждается передача. Наличие готового подключения Microsoft-Decision-1 и доступных настроек в выбранной конфигурации проверяется отдельно при обсуждении интеграций.