Практическое руководство по движку Laya: нулевая точность, калибровка и принятие решений

Подробности изложены в материале первоисточника. Привет, друзья! Меня зовут Сергей Багров. Сегодня я подготовил для вас разбор архитектуры и тонкостей настройки open-source движка Laya от Convai Innovations, который заслужил широкое признание в сообществе разработчиков. Давайте разберем практические шаги по развертыванию, калибровке вероятностей и обходу неочевидных подводных камней.

Инструмент представляет собой неавторегрессионную System 1 модель: вместо генерации текстовой последовательности кодер на 421 миллион параметров анализирует входной текст и набор типизированных вопросов, выдавая вероятности для каждого варианта за один проход с нулевым количеством выходных токенов. Для демонстрации я опираюсь на реальные размеченные данные банковского домена из датасета CLINC150.

Установка Laya и фиксация ревизии чекпоинта

Мы устанавливаем актуальный пакет версии 0.3.27 и загружаем англоязычные веса. Чтобы результаты были воспроизводимы, важно зафиксировать ревизию, которую проверили авторы библиотеки, используя константу laya.PINNED_REVISIONS. Также при работе на графическом ускорителе CUDA стоит отключить автоматическое приведение типов к половинной точности, переключив устройство в стандартный режим fp32, что исключит расхождения с результатами на CPU.

Проверка базовых температур, поставляемых с моделью, выявляет любопытный нюанс: значение для категориальных вопросов с 11 и более вариантами ответа задано как 0.10, что выходит за допустимые рамки, поэтому модуль загрузки принудительно устанавливает его на отметке 0.5 и выдает предупреждение. Температура ниже единицы делает вероятности более резкими, из-за чего ответы на крупные вопросы будут казаться вдвое более уверенными, чем модель предполагает изначально.

Один проход, три типизированных вопроса и нулевой объем токенов

Один вызов метода предсказания обрабатывает сразу три вопроса о поддержке: определение департамента как выбор из списка, оценку срочности по шкале от 0 до 2 и риск оттока клиента в формате да/нет. Результат содержит вероятности для каждой опции, а также два поля уверенности, которые легко перепутать:

answer_confidence — это вероятность выбранного ответа, то есть максимум среди всех вероятностей (max(p)), которая используется для калибровки и пороговых фильтров.

Реклама

confidence — это величина, рассчитываемая как единица минус нормализованная энтропия, шкала которой зависит от количества доступных вариантов.

В блоке использования токенов вы увидите нулевое значение для выходных токенов, так как движок оценивает переданные варианты, но никогда не генерирует текст самостоятельно.

Оценка затрат: почему вопросы выгоднее объединять в списки

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

В итоге один вопрос с сорока вариантами ответа выполняется гораздо быстрее, чем сорок отдельных вопросов «да/нет». Отсюда рождается ключевое правило проектирования: задавайте один вопрос со множеством вариантов, а не множество мелких проверок.

Реальные размеченные данные: Zero-shot против классификатора

Для тестирования в боевых условиях я использую банковский домен датасета CLINC150, содержащий пятнадцать интентов с разметкой для обучения, валидации и тестов. Запустив модель в режиме zero-shot с краткими описаниями интентов, я получаю точность 0.804 без единого обучающего примера. Для сравнения, классификатор на базе TF-IDF и логистической регрессии достигает схожих результатов лишь при наличии от трех до десяти размеченных примеров на каждый класс.

Как формулировки критериев и порядок опций меняют ответы

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

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

Насколько честны вероятности «из коробки»?

Анализ калибровки на тестовой выборке показывает, что 92 процента ответов заявляют об уверенности не менее 0.9, но корректными из них оказываются лишь 91.1 процента. Средняя уверенность модели составляет 0.974, что заметно превышает фактическую точность 0.878, а ожидаемая ошибка калибровки (ECE) равняется 0.102. Метрика калибровки зависит от конкретного распределения данных, поэтому ее необходимо измерять на собственных размеченных примерах.

Подгонка температуры на валидационных данных

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

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

Шлюз воздержания под заданный бюджет ошибок

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

Запросы вне сферы охвата: шлюз против специальной опции

Работая с реальным трафиком, система неизбежно сталкивается с запросами, на обработку которых она не была рассчитана. Добавив 150 нерелевантных запросов, мы видим, что откалиброванная уверенность отлично разделяет потоки: банковские запросы имеют среднюю уверенность 0.912, тогда как чужие домены — около 0.25.

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

Смещенные вопросы «да/нет» и ограничения температурного скейлинга

При создании выделенной проверки на принадлежность к банковской сфере с помощью вопроса «да/нет» мы получаем отличную метрику AUROC на уровне 0.945, но наблюдаем сильное смещение в сторону отрицательных ответов. Попытка применить температурное скейлинг упирается в ограничение, так как деление логитов на константу не меняет соотношение их величин — температура исправляет масштаб, но не смещение.

Решением здесь становится трактовка вероятности как обычной оценки (скора) и подбор порога срабатывания на размеченной выборке, что позволяет достичь высокой полноты и специфичности на тесте.

Типизированные решения через схемы Pydantic

Интеграция движка в прикладной код реализуется через Pydantic-схемы с помощью функции laya.decide_batch. Поля типа Literal автоматически превращаются в выбор из чистых имен интентов, а булевы поля — в вопросы «да/нет». Передача шлюза уверенности в качестве параметра позволяет автоматически превращать неопределенные ответы в None, реализуя надежный сигнал для передачи запроса оператору-человеку.

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