Утверждение за заголовком
Пришла волна компактных моделей принятия решений. Microsoft-Decision-1 и Drex 1.5 от Nace AI обе представляют принятие решений как оценку, а не генерацию: получив набор вариантов и цель, модель возвращает оценку или ранжирование. Это полезный сдвиг. Оценка — это ограниченная операция. Она требует фиксированного набора вариантов и фиксированной цели. Эта цель должна откуда-то взяться, и источник — это документ политики, а не веса.
Сжатие — это и есть суть. Модель на 9B, которая оценивает варианты, — это сжатие политики, которую вы уже написали. Если вы выпускаете её без версионируемого реестра решений, вы не устранили проблему управления. Вы переместили её в чекпоинт.
Рассмотрим, что содержит чекпоинт. Он содержит обученную функцию от (контекст, вариант, цель) к оценке. Функция была подогнана под примеры. Эти примеры кодируют выборы, сделанные кем-то, по какой-то политике, в какое-то время. Чекпоинт не несёт текст политики. Он несёт её статистическое резюме. Когда политика меняется, резюме не обновляется само. Когда политика молчит, резюме всё равно выдаёт число.
Это и есть режим отказа. Модель оценки уверена по построению. Она возвращает оценку для каждого варианта, который вы ей даёте. Если ваша политика не определяет правило разрешения ничьих, модель изобретёт его из своего обучающего распределения. Изобретение не видно в выводе. Оно видно только в журнале решений, если вы его вели, и только если журнал включает набор вариантов и цель, которые породили оценку.
К чему на самом деле обязывает оценённое решение
Каждая оценка подразумевает класс сравнения и правило разрешения ничьих. Класс сравнения — это набор вариантов. Если набор вариантов не записан, оценка бессмысленна. Оценка 0,82 для варианта A ничего не значит без знания, какими были B, C и D. Она также ничего не значит без знания цели: 0,82 за экономическую эффективность — это другое решение, чем 0,82 за удержание клиентов.

Правило разрешения ничьих — это место, где живёт большинство инцидентов с агентами. Модель уверена, политика молчит. Два варианта получают оценки в узком диапазоне. Модель выбирает более высокий. Политика никогда не говорила, какое измерение доминирует, когда оценки близки. Отчёт об инциденте говорит, что агент сделал неожиданный выбор. Корневая причина — отсутствующая строка в реестре.
Оценка без записанного набора вариантов не может быть воспроизведена после факта. Воспроизведение требует тех же входных данных: той же схемы вариантов, той же цели, того же порога. Если схема вариантов изменилась между решением и аудитом, оценка не воспроизводима. Если цель была отредактирована в шаблоне промпта, оценка не воспроизводима. Если порог был гиперпараметром, настроенным во время оценки, оценка не воспроизводима.
Это не проблема модели. Это проблема артефакта. Модель — это среда выполнения. Реестр — это артефакт.
Реестр — это артефакт, модель — это среда выполнения
Реестр решений — это версионируемая запись решений, которые агент может принимать. У него есть три части, которые должны версионироваться отдельно от чекпоинта:
- Схема вариантов: какие варианты существуют, как они идентифицируются и какие поля несёт каждый вариант.
- Цель: оцениваемые измерения, их относительные веса и направление предпочтения.
- Разрешение ничьих: правило, разрешающее близкие оценки, включая порог, определяющий близкую оценку.
Версионирование их отдельно важно, потому что они меняются с разной скоростью. Чекпоинт меняется, когда вы переобучаете или заменяете модели. Схема вариантов меняется, когда бизнес добавляет новый уровень продукта. Цель меняется, когда команда политики перевешивает стои.jpg)ит пробел.

Относитесь к порогам оценок как к конфигурации с владельцем, а не как к гиперпараметру. Порог — это утверждение политики: ниже этой оценки эскалируйте человеку; выше — действуйте. Это утверждение нуждается в имени, версии и человеке или роли, ответственной за него. Если порог живёт в скрипте обучения, он будет дрейфовать вместе с моделью. Если он живёт в конфигурационном файле с владельцем, его можно проверять.
Записывайте набор вариантов вместе с оценкой, чтобы аудитор мог восстановить решение. Запись в журнале должна включать версию реестра, идентификаторы вариантов, версию цели, версию порога и необработанные оценки. С такой записью аудитор может воспроизвести решение против того же реестра и увидеть, соответствовал ли вывод модели политике. Без неё аудитор может только исследовать модель, что говорит ему, что модель может сделать, а не что она сделала.
Конкретный механизм: схема журнала решений, которая хранит хеш реестра с каждым решением. Хеш покрывает схему вариантов, цель и разрешение ничьих. Когда реестр меняется, хеш меняется. Решения, принятые по старому реестру, остаются доступными для запросов по старому хешу. Это небольшой кусок инженерии. Это разница между воспроизводимым решением и правдоподобной историей.
Правило проектирования
Если решение не может быть выражено как строка в реестре, модель оценки не сделает его управляемым. Строка — это тест. Она заставляет вас назвать варианты, цель и разрешение ничьих. Если вы не можете их назвать, у вас нет политики. У вас есть надежда, что обучающее распределение модели соответствует вашему замыслу.
Модели решений должны стоять за реестром, а не вместо него. Реестр определяет пространство решений. Модель оценивает внутри него. Среда выполнения применяет порог и регистрирует результат. Этот порядок сохраняет политику видимой, а модель заменяемой. Вы можете заменить оценщик на 9B на другой оценщик на 9B или на более крупную модель, не переписывая политику. Вы можете обновить политику без переобучения модели.
Компромисс реален. Поддержание реестра — это работа. Она требует схемы, процесса проверки и конвейера логирования. Это замедляет первое развёртывание. Команды, которые пропускают это, выпускают быстрее и накапливают невидимый долг: решения, которые нельзя воспроизвести, пороги, которыми никто не владеет, разрешения ничьих, которые живут только в весах модели. Долг наступает во время проверки инцидента или аудита, когда вопрос не в том, что модель может сделать, а в том, что она сделала.
Модели оценки — это подлинное улучшение по сравнению со свободной генерацией для ограниченных решений. Они делают вывод сравнимым, а операцию дешевле. Они не заставляют политику исчезнуть. Они сжимают её. Сжатие с потерями. Реестр — это место, где фиксируются потери.
