Публичная критика и результаты, которые не воспроизвелись

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

Правильно читать эту страницу не как «значит, модель плохая», а так: это известные режимы отказов, и ваша система должна их переживать.

Эксперимент с игральной костью

Самый прямой. Попросите модель угадать честную кость 400 раз:

Эти числа говорят сразу две вещи. Во-первых, заявленная вероятность может не нести вообще никакой информации — 82.9% ничего надёжного не сказали о задаче с долей попаданий 19%. Во-вторых, модель не выражает «я не знаю». На честной кости правильный ответ — «примерно по 16.7% на грань», а форма вывода — один предпочтительный вариант с высокой вероятностью — не имеет способа это сказать.

Ещё один результат того же автора стоит запомнить: на синтетическом документе прогноза риск дефицита 30% превратился в 5.3% через Choice и в 26.7% через Noul. Тот же вход, тот же смысл, другой примитив — разница в пять раз. Выбор примитива меняет ответ, и более веские доказательства этого есть на странице оценки.

«Jev Can’t Be Calibrated»

Широко разошедшаяся критика доказывает на статистическом уровне, что утверждение о калибровке не выдерживает имеющихся данных. Весьма популярное обсуждение формулирует ту же мысль осторожнее:

Гарантия типобезопасности реальна (подтверждена с нескольких сторон), но за утверждением о калибровке не стоит ни опубликованной ECE, ни кривой надёжности.

Заметьте точность: не говорится, что калибровка ложна, говорится, что публичные доказательства в её поддержку отсутствуют. Это разные утверждения, и для инженерного решения они ведут в одно место — нельзя задать производственный порог на основании чего-то, для чего не опубликована кривая надёжности.

Реранкинг: полностью отрицательный результат

Этот класс результатов самый ценный, потому что он конкретен, воспроизводим и опровергает ровно то следствие «она умеет всё».

Оценка реранкинга использовала 33,047 элементов, 164 реальных запроса и 9,831 оценённую пару, и пришла к выводу, что чистый реранкинг моделью принятия решений проигрывает векторному поиску.

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

Раздельное решение

Некоторые результаты зависят от того, какую строку читать. Одно сравнение оценивания с генерацией:

На японском NLI многомерное оценивание с локально подобранными весами победило прямой вопрос (0.9076 против 0.8373). Но оно пометило примерно в 25 раз больше трудных доброкачественных строк как атаки (37.2% против 1.5%).

Среднее улучшилось, пока доля ложных срабатываний одного класса выросла в 25×. Если ложная пометка доброкачественного входа дорого обходится в вашей системе, это улучшение для вас отрицательно — даже хотя выглядит положительным.

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

Документация самого поставщика это признаёт

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

Как превратить эту страницу в правила

Из неё вытекают три инженерных правила:

1. Никогда не рассуждайте о разных задачах по абсолютному значению уверенности. «0.9 значит 90% верных» просто неверно на такой задаче, как кость.
2. Выбор примитива — экспериментальная переменная, а не вопрос стиля. Один и тот же вопрос, заданный как Choice или как Noul, может различаться в пять раз. Измеряйте эту разницу, а не выбирайте один произвольно.
3. Смотрите на подклассы, а не на итоги. Пример с 25-кратным ростом ложных срабатываний совершенно невидим в агрегате.

В одном предложении

Ничто из этого не причина не использовать эти модели — это причина не доверять настройкам по умолчанию. Каждый паттерн в этом руководстве (код владеет порогом, gating, conformal-отказ) — способ работать внутри ограничений этой страницы.