TL;DR
PremiseCheck — двухступенчатая проверка. Сначала LLM переписывает комментарий в несколько явных утверждений-предпосылок, при этом документ ей не показывают. Потом каждую предпосылку отдельно сверяют с документом. Оценка комментария равна оценке самой слабой предпосылки: одна ложная — и весь комментарий под подозрением.
Боль в том, что комментарий редко говорит прямо. Вопрос «А вы пробовали другие модели?» молча утверждает, что автор их не пробовал. Маленькая дешёвая проверяющая модель на таком цельном комментарии работает на уровне подбрасывания монетки. Дорогая LLM справляется, но для каждой проверки заново читает весь длинный документ, и счёт растёт. Причина простая: понять, что именно утверждает комментарий, — это одна работа, а искать подтверждение в документе — другая, и делать их одним махом дорого.
Метод их разделяет. Понимание (вытащить явные и скрытые утверждения) делает LLM по короткому тексту комментария. Чтение документа делает дешёвая модель, когда утверждения уже простые и самодостаточные. На одиночных явных утверждениях дешёвая модель не хуже топовой LLM. Итоговая точность получается на уровне топовой LLM при цене примерно вдвое ниже, а в части случаев вчетверо.
Схема метода
ШАГ 1. Разбор: комментарий → 1–6 явных предпосылок
(документа модель НЕ видит; учитывать и неявное, что предполагают вопросы)
ШАГ 2. Маршрут: каждая предпосылка → «проверяется по документу» или «общее знание»
(документа модель НЕ видит; смотрит только на предпосылку)
ШАГ 3. Проверка: документ + предпосылка → вероятность «верно» (отдельно по каждой)
(по документу — «верно согласно документу?», по общему знанию — «верно?»)
ШАГ 4. Итог: оценка комментария = минимальная оценка предпосылок
→ низкая оценка = отправить на ручную проверку
В статье шаги 2–3 выполняет специальная модель-решатель (Jev), которая не пишет текст, а выдаёт вероятность. В чате роль шагов 1 и 3 играют два отдельных запроса к LLM.
Пример применения
Задача: Вы подали заявку на грант в Фонд содействия инновациям. Эксперт написал заключение, и в нём есть подозрительный абзац. Нужно быстро понять, где эксперт мог ошибиться в пересказе вашей заявки, прежде чем писать ответ.
Промпт (чат 1, без заявки):
Ниже комментарий эксперта к заявке на грант. Заявки у тебя нет, и не додумывай её содержание.
Перепиши комментарий как набор из 1–6 явных предпосылок. Каждая предпосылка — одно самодостаточное утверждение о заявке, где названы раздел, таблица или метод, о которых идёт речь. Включи и явные утверждения, и скрытые: что предполагает каждый вопрос эксперта. Не добавляй фактов, которых эксперт не утверждал и не подразумевал.
Комментарий: «В заявке не показан план монетизации, а финансовая модель не учитывает расходы на серверы. Почему тестирование проводилось только в Казани? Также неясно, зачем команде из трёх человек нужен фонд оплаты труда на 4 млн рублей.»
Промпт (чат 2, с заявкой):
Вот текст заявки: {текст заявки}
Ниже пронумерованные предпосылки из заключения эксперта. Для каждой:
1. Реши, проверяется ли она по тексту заявки или это общее знание.
2. Если по заявке — ответь: «верно согласно заявке?» (да / нет / не указано) и процитируй место, где это видно или где этого нет.
3. Если общее знание — ответь: «верно?» (да / нет) с короткой причиной.
В конце выведи предпосылку с самой низкой уверенностью и пометь комментарий на ручную проверку, если такая есть.
Результат: В первом чате придёт список из нескольких коротких утверждений вроде «в заявке нет раздела о монетизации» и «тестирование проведено только в одном городе». Вопросы превратятся в утверждения. Во втором чате по каждой предпосылке будет вердикт с цитатой из заявки. В конце модель назовёт слабейшую предпосылку, то есть наиболее вероятную фактическую ошибку эксперта. Её и стоит вынести в ответ на заключение.
Почему это работает
Слабость. Цельный комментарий содержит несколько утверждений вперемешку, и многие из них неявные. Проверяющая модель, да и LLM, смотрит на всё сразу и теряет скрытые допущения. Заодно длинный документ перечитывается на каждую проверку.
Сильная сторона. LLM хорошо понимает смысл короткого текста и умеет достать из него скрытые допущения. Для этого документ не нужен. А когда утверждение простое и самодостаточное, сверить его с документом может и дешёвая модель.
Как метод это использует. Он делит работу по сильным сторонам. Понимание — у LLM, на 24 словах комментария. Чтение — у решателя, на готовых утверждениях. Агрегация по минимуму отражает логику: комментарий, опирающийся на ложную предпосылку, содержит ошибку.
Рычаги управления: - Число предпосылок (1–6) → меньше для коротких комментариев, больше для длинных. - Требование «называй раздел, таблицу, метод» → убери, если нужны общие утверждения. Оставь, если хочешь точный поиск по документу. - Маршрут «документ / общее знание» → убери, если все утверждения о документе. Нужен, чтобы общеизвестное («бейзлайны — стандартный способ оценки») не заваливали оценку фразой «согласно документу». - Агрегация по минимуму → замени на «выведи все сомнительные предпосылки», если нужен список, а не флаг.
Шаблон промпта
Шаблон из двух запросов: первый без документа, второй с документом.
=== ЗАПРОС 1 (БЕЗ ДОКУМЕНТА) ===
Ты разбираешь чужой комментарий на явные предпосылки. Документа у тебя нет.
Перепиши комментарий как набор из 1–{макс_предпосылок} предпосылок.
Правила:
- каждая предпосылка — одно самодостаточное утверждение;
- в каждой названы документ, раздел, таблица или метод, о которых идёт речь;
- включи явные и неявные предпосылки, в том числе то, что предполагает каждый вопрос;
- не добавляй фактов, которых автор комментария не утверждал и не подразумевал.
{комментарий}
=== ЗАПРОС 2 (С ДОКУМЕНТОМ) ===
{документ}
{список предпосылок из запроса 1}
Для каждой предпосылки сначала определи, чем она проверяется: «ПО ДОКУМЕНТУ» или «ОБЩЕЕ ЗНАНИЕ».
Если «ПО ДОКУМЕНТУ»: верно ли это согласно документу? Ответ: да / нет / не указано. Процитируй место.
Если «ОБЩЕЕ ЗНАНИЕ»: верно ли это? Ответ: да / нет. Дай короткую причину.
Для каждой дай уверенность от 0 до 1.
Оценка комментария = минимальная уверенность среди предпосылок.
Назови слабейшую предпосылку. Если оценка ниже 0.5, пометь комментарий: «на ручную проверку».
В {макс_предпосылок} подставьте число (в статье до 6). В {комментарий}, {документ} вставьте свои тексты. Второй запрос лучше делать в новом чате, чтобы документ не влиял на разбор комментария.
🚀 Быстрый старт — вставь в чат:
Вот шаблон PremiseCheck. Адаптируй под мою задачу: {что проверяю и против какого документа}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой тип комментариев вы проверяете, какой документ служит источником правды и сколько предпосылок обычно в таком комментарии. Это нужно, потому что метод держится на явных самодостаточных утверждениях, а их форма зависит от жанра. Она возьмёт структуру из шаблона и подстроит формулировки.
Ограничения
⚠️ Только факты, не оценки: метод проверяет, верно ли комментарий пересказывает документ. Вопросы вроде «важно ли это замечание» или «сильный ли аргумент» вне задачи.
⚠️ Выигрыш в цене, а не в качестве: точность осталась на уровне топовой LLM. Выгода метода — в сокращении расходов при массовой проверке, а не в улучшении. Если проверяете один-два комментария в чате, преимущество почти незаметно.
⚠️ В чате не проверяли: авторы сверяли не две LLM в чате, а LLM с отдельной маленькой моделью-решателем, выдающей вероятности. Чатовая версия здесь — перенос идеи.
⚠️ Приложения нет в нашем тексте: точные промпты разбора и маршрутизации лежат в приложениях, которых в переданном фрагменте нет. Шаблон выше собран по описанию их требований.
⚠️ Минимум топит всё: одна ошибочно «неверная» предпосылка отправит весь комментарий на ручную проверку. Модель-разборщик может также додумать лишнее, хотя в промпте это запрещено.
⚠️ Редкие ошибки: фактические ошибки встречаются в нескольких процентах комментариев. При массовой проверке будет много срабатываний «всё верно» и редкие находки.
Как исследовали
Идея была простой: развести «понять, что утверждает комментарий» и «прочитать документ». Команда собрала бенчмарк ReviewFact: 9267 комментариев рецензентов и ИИ-рецензентов к 217 научным статьям из трёх областей (NLP, машинное обучение, естественные науки). Новых комментариев не писали, а переразметили готовые экспертные оценки по единому определению «фактической ошибки». Ошибки редки: 4,8% комментариев в NLP и 2,5% в естественных науках. Спорные метки проверили вручную: двое авторов независимо разметили 178 комментариев, и их согласие с автоматической разметкой оказалось высоким.
Сравнивали три подхода: топовая LLM читает всю статью на каждый комментарий; дешёвая модель-решатель оценивает цельный комментарий; PremiseCheck, где LLM без статьи разбирает комментарий, а модель-решатель сверяет предпосылки. Удивительно, что решатель на цельных комментариях в NLP оказался на уровне случайного угадывания, а на разобранных людьми одиночных предпосылках сравнялся с топовой LLM. Отсюда вывод: проблема не в ленивом чтении документа, а в неясной формулировке того, что проверять. PremiseCheck показал качество на уровне топовой LLM примерно за половину стоимости, а разборщик без «размышлений» для NLP удешевил проверку до четверти цены при вдвое меньшей задержке. Четыре разных решателя, в том числе открытая модель, отстали от LLM не более чем на пункт, то есть эффект дала сама схема, а не конкретная модель. Каскад (сначала дешёвая, потом дорогая модель) обошёлся дороже и оказался менее точным.
Адаптации и экстраполяции
🔧 Техника: убрать агрегацию по минимуму → получить список проблем
Замените в блоке
Выведи все предпосылки с уверенностью ниже 0.5 в виде списка «что именно не подтверждается и почему».
Вместо одного флага вы получаете перечень претензий к комментарию, которые можно сразу вставить в ответ.
Экстраполяция: тот же двухшаговый приём подходит, когда нужно проверить чужой пересказ вашего документа. Например, вы получили письмо клиента: «В договоре нет штрафа за просрочку, а срок сдачи не указан». Разбейте письмо на предпосылки в чате без договора, затем сверьте каждую предпосылку с договором в новом чате. Так проверяются отзывы, претензии, жалобы и конспекты встреч.
Ресурсы
- PremiseCheck: Efficient Fact-Checking of Human and AI Peer Reviews — Dingjie Song, Zhiling Yan, Ziqian Zhang, Yuxuan Zhang, Lichao Sun (Lehigh University, University of British Columbia, Vector Institute)
- Код: https://github.com/OpenLAIR/PremiseCheck
- Данные: https://huggingface.co/datasets/songdj/ReviewFact
- Сайт: https://openlair.github.io/premisecheck/
- Связанные работы: ReviewCritique (Du et al., 2024), ReviewScore (Ryu et al., 2025), PeerReview Bench (Kim et al., 2026), Jev (Almeida, 2026)