Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Peiying Zhu и Sidi Chang разработали ClaimReceipt — формат доказательств и проверяющий механизм для оценки ИИ-агентов; работа опубликована как препринт, не проходивший рецензирования. В проспективном эксперименте изъятие одной итоговой квитанции переводило вывод о полноте из подтверждённого в неопределённый. Подход важен командам, которые сравнивают модели, агентные сценарии или защитные механизмы и затем принимают по этим замерам продуктовые решения.
Что сделали
Авторы разделили две задачи, которые обычный журнал событий смешивает. Достаточность доказательств означает, что заявленный показатель можно заново вычислить из сохранённых данных. Покрытие означает, что сохранены результаты всего заранее заявленного эксперимента, а не удобная выборка запусков.
Для этого ClaimReceipt связывает каждый вывод с типизированной квитанцией. В неё входят назначение экспериментальной группы, упорядоченная трасса действий, исходные и нормализованные предложения агента, решение другой стороны, входы оценщика, версии обработчиков и ссылки на закрытые данные. Состав зависит от проверяемого утверждения: например, расчёт экономического результата требует иных полей, чем проверка одинакового протокола в экспериментальных группах.
На уровне эксперимента используется подписанный манифест. До запуска он фиксирует ожидаемые назначения, различия между группами, правила повторов, версии подсказок, парсеров и оценщиков, а также способ расчёта результата. Благодаря этому отсутствие ожидаемой итоговой квитанции становится видимым. Хеши и цепочки подписей защищают уже сохранённые байты от изменения, но сами по себе не доказывают, что журнал содержит необходимые поля или все запуски.
Проверяющий механизм возвращает отдельный вердикт для каждого утверждения: PASS, если его можно подтвердить; INVALID, если данные ему противоречат; INCONCLUSIVE, если доказательств недостаточно. Для стохастической генерации авторы не пытаются повторно получить тот же текст от LLM: воспроизведение начинается с записанного сырого ответа и охватывает парсинг, ограничения, выбор действия и расчёт показателей.
Что показали
По замерам авторов, проверяющий механизм воспроизвёл пять из пяти вручную размеченных аудиторских вердиктов на историческом корпусе. Это показывает соответствие прежней ручной проверке, но не является независимым подтверждением её правильности. Авторы отдельно подчёркивают, что постоянный классификатор мог бы совпасть с таким небольшим набором меток, поэтому механизм также пересчитывал лежащие в их основе показатели.
Для детерминированных сценариев удалось полностью повторить цепочку от политики до итоговой метрики. В экспериментах с LLM точно воспроизводилась часть после генерации: от сохранённого ответа модели до экономического результата. Удаление каждой заявленной группы полей делало хотя бы один тип вывода неопределённым, то есть реализация не подменяла отсутствующие доказательства записанным итоговым числом.
В замороженном наборе проверок все специально внесённые смысловые ошибки дали ожидаемый вердикт, а допустимые изменения представления данных не вызвали ложных срабатываний. Инструментирование с выпуском входного билета заняло по медиане 0,021% времени модельного вывода, а объём данных составил 9,9 КБ на транзакцию.
Ограничения
Историческая часть охватывает 1 392 терминальные записи из одного настраиваемого сценария торговли гостиничными услугами. Проспективная часть ограничена 30 назначениями и одной конфигурацией Qwen2.5-Instruct 3B с единственной генерацией на назначение. Работа не проверяет переносимость схемы на другой предметный домен, независимую реализацию или эксплуатацию ролей разными организациями.
Набор смысловых неисправностей состоял из 11 спроектированных авторами случаев, а не ошибок из реальной производственной эксплуатации. Исторические манифесты были восстановлены после запусков, поэтому они демонстрируют механизацию аудита, но не предварительную фиксацию условий. В прототипе разные ключи разделяют роли, однако всеми ролями управляет один оператор; независимого свидетеля входящих транзакций нет.
ClaimReceipt подтверждает полноту только относительно заранее зарегистрированного входящего потока. Если оператор не допустит запуск до точки регистрации, система этого не обнаружит. Кроме того, собственная проверка читаемости спецификации не дала подтверждающего результата: независимый интерпретатор не смог надёжно предсказывать вердикты, поэтому однозначность контракта пока не показана.
Что это значит
Работа меняет планы команд, которые собираются обосновывать выбор модели или агентной архитектуры экспериментами. Схему доказательств и полный набор запусков стоит проектировать до начала оценки, а не добавлять журналирование после получения результата. Иначе сохранённые трассы могут позволить пересчитать показатель, но не доказать отсутствие пропущенных запусков или различий в протоколах.
ClaimReceipt не выглядит готовым универсальным стандартом: область утверждений ограничена, управление ключами и закрытыми данными оставлено внедряющей стороне, а независимая воспроизводимость реализации не проверена. Практическая ценность работы — в архитектурном разделении целостности файлов, достаточности данных и полноты эксперимента. Для внутренних прототипов это может быть избыточно; для сравнений, влияющих на выпуск продукта, закупку модели или заявление о причинном эффекте, такая граница позволяет не превращать неполные данные в положительный вывод.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
