Модели доказательств и модели решений — это разные артефакты

Две задачи, которые выглядят как одна

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

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

Это не два размера одного и того же. Это две разные спецификации.

У моделей решений и моделей доказательств разные наборы требований

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

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

Требования тянут в противоположные стороны. Модели решений выигрывают от агрессивного сжатия контекста и уверенных, решительных выводов. Модели доказательств выигрывают от консервативных выводов и явной неуверенности. Модель, обученная или настроенная быть решительной, по построению плохо подходит для задачи сказать «я не уверена, что это правильно».

Почему общие веса ломают оценку

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

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

Циклы самоулучшения усиливают проблему. Если исполнитель дообучается или оптимизируется по промптам против оценок судьи, он учит предпочтения судьи, а не задачу. Градиент указывает на то, что судья случайно вознаграждает, включая его идиосинкразии. С итерациями система становится лучше в удовлетворении судьи и не лучше в работе. Метрика оценки растёт; продукт — нет.

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

Паттерн разделения

Относитесь к судье как к зависимости с собственным жизненным циклом.

Версионируйте судью независимо и фиксируйте его для каждого набора тестов

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

Конкретный механизм: храните манифест судьи рядом с каждым набором.

suite: checkout-agent-v4
judge:
  model: evidence-judge-2024-11
  prompt_hash: 9f2c1a
  decoding: {temperature: 0.0, top_p: 1.0}
  rubric_version: 3
actor:
  model: checkout-actor-2024-11
  prompt_hash: 4b7e02

Каждая строка оценки, записанная харнессом, несёт идент![Abstrjpg).

Выделите размеченный людьми холдаут для обнаружения дрейфа судьи

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

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

Записывайте идентичность судьи с каждой оценкой

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

Компромиссы, которые нужно принять

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

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

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

Граница — это проектное решение

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