Когда локальные проверки позволяют доверять ответу LLM

Ответ LLM можно принять без доступа к внутренним рассуждениям модели, если разбить его проверку на диагностические шаги и правильно накапливать их результаты. В препринте NYU и Amazon, который не прошёл рецензирование и где все числа получили сами авторы, доказано: вероятность когда-либо принять ложное утверждение можно удержать ниже заранее выбранного уровня даже при адаптивных ответах модели. Для продукта это сдвигает задачу с объяснения работы LLM на проектирование проверок, которые человек действительно способен выполнить.

Гарантию дают проверки, а не убедительный диалог

Схема начинается с фиксированного утверждения. LLM может объяснять его, предъявлять подробности и отвечать на возражения, но не должна незаметно заменять исходный тезис другим. Человек выбирает следующий запрос, проверяет ответ и решает, достаточно ли накоплено свидетельств для принятия.

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

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

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

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

Локальная проверка выигрывает только при снижении нагрузки

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

Поэтому разбиение большого анализа на малые шаги не даёт преимущества автоматически. Оно помогает, когда отдельный шаг заметно проще для человека и это улучшение перекрывает затраты на выбор вопросов, поиск данных и повторные проверки. Усталость, опыт и объём внимания входят в модель как ограничения, а не как внешние детали интерфейса.

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

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

Формальная схема охватывает утверждения с определённым критерием истины и доступными свидетельствами. Проверка формулы не доказывает, что она верно передаёт исходную формулировку, а сверка с документом не подтверждает достоверность самого документа. Свободные суждения, творческие задачи и спорные предпочтения могут выиграть от обсуждения, но не получают описанной гарантии.

Планы меняет не выбор модели, а устройство контура проверки

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

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

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

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

Для команд вывод узкий: схема пригодна там, где уже можно назвать локальный тест, источник свидетельства и допустимую ошибку. Если эти элементы нельзя определить, подробные объяснения LLM повышают удобство разбора, но не превращают ответ в доказанный.

Источники

• Human-LLM Deliberation as Interactive Proof: Conditions for Verifiability Without Transparency

Иллюстрация: рисунок из статьи «Human-LLM Deliberation as Interactive Proof: Conditions for Verifiability Without Transparency», Baotong Zhang, Dean Foster, Jo\~ao Sedoc, CC BY-SA 4.0