TL;DR
Когда просишь Claude проверить длинный документ целиком, модель «забывает» начало к концу — и пропускает противоречия между разделами. Исследование OpenAIReview нашло решение: делить документ на части и вести накопленный конспект определений, ключевых утверждений и формул. Каждую следующую часть проверяешь с учётом уже прочитанного.
Главный инсайт: prose-уровневые ошибки — логические противоречия, неподкреплённые утверждения, сломанные рассуждения — модель ловит вдвое лучше при накопленном контексте (68% против 37% при проверке всего за раз). Локальные технические ошибки (опечатки, мелкая арифметика) — система ловит плохо в любом случае. Главная жалоба реальных пользователей — ложные срабатывания и мелкие придирки, не пропуски серьёзных проблем.
Метод работает в три хода внутри одного диалога: [1] передаёшь первую часть документа с чеклистом проверки, [2] модель выдаёт комментарии и обновляет конспект ключевых утверждений, [3] повторяешь для каждой следующей части — конспект идёт с собой.
Схема метода
ШАГ 0: Раздели документ на части по 500-800 слов
ШАГ 1 (первый запрос):
Входные данные → Часть 1 + чеклист проверки
Вывод → [Комментарии к части 1] + [Конспект: ключевые
утверждения, термины, данные из части 1]
ШАГ 2 (второй запрос):
Входные данные → Часть 2 + конспект из шага 1 + чеклист
Вывод → [Новые комментарии] + [Обновлённый конспект]
ШАГ 3…N: Повторяй до конца документа
ФИНАЛ (последний запрос): Объедини все комментарии, убери
дубли, сгруппируй по серьёзности
Каждый шаг — отдельный запрос в одном диалоге. Конспект передаёшь вручную от запроса к запросу.
Пример применения
Задача: Ты написал инвест-меморандум для привлечения раунда в стартап на 50 млн рублей. Документ — 8 страниц. Хочешь найти противоречия, неподкреплённые утверждения и логические дыры до того, как отправишь Baring Vostok.
Промпт (Шаг 1 — первая часть документа):
Ты — опытный инвестиционный аналитик. Проверяй документ по частям.
ЧЕКЛИСТ ПРОВЕРКИ (применяй к каждой части):
- Утверждения без доказательств: заявлено что-то важное, но не подкреплено данными?
- Противоречия: что-то в этом тексте противоречит тому, что было раньше?
- Сломанная логика: вывод не следует из предпосылок?
- Слишком смелые claims: «лучший», «единственный», «100%» — есть основания?
- Неопределённые термины: ключевое слово используется, но не объяснено?
ВАЖНО: если сомнение снимается контекстом того же абзаца — не поднимай.
Только реальные проблемы.
После комментариев — дай КОНСПЕКТ: список ключевых утверждений,
цифр и терминов из этой части, которые нужно помнить при проверке
следующих разделов.
---
ЧАСТЬ 1 (стр. 1-2):
[вставь текст]
Промпт (Шаг 2 — следующая часть):
Продолжаем проверку. Вот что было установлено в предыдущих разделах:
КОНСПЕКТ ИЗ ЧАСТИ 1:
[вставь конспект из предыдущего ответа]
Теперь проверь Часть 2 по тому же чеклисту.
Особое внимание: нет ли противоречий с тем, что в конспекте?
ЧАСТЬ 2 (стр. 3-4):
[вставь текст]
Результат:
Модель выдаст пронумерованные комментарии с цитатой проблемного места и объяснением — почему это проблема. В конце — обновлённый конспект для следующей части. На финальном шаге попроси объединить все комментарии и отсортировать по серьёзности: критические → важные → мелкие. Мелкие можно сразу проигнорировать — это главный источник ложных срабатываний.
Почему это работает
Слабость LLM: модель держит в голове то, что видит сейчас. Длинный документ — это как читать книгу, но помнить только последние 10 страниц. Противоречие между введением и выводами она не поймает, если они не помещаются в один запрос.
Сильная сторона LLM: модель отлично работает с явно заданным контекстом. Если написать ей «вот что было утверждено раньше» — она будет с этим сверяться. Конспект — это искусственная «долговременная память», которую ты создаёшь руками.
Как метод использует это: конспект превращает разрозненные запросы в связную проверку. Модель не читает заново — она сверяется с накопленным списком утверждений. Именно поэтому логические и смысловые ошибки ловятся вдвое лучше — они часто и есть противоречия между разными частями документа.
Рычаги управления: - Чеклист → убери пункты, которые не нужны (например, для художественного текста уберёшь "утверждения без данных") - Размер части → меньше 500 слов = больше запросов, но точнее; больше 800 = быстрее, но модель может упустить детали - «Только реальные проблемы» → ключевая инструкция против ложных срабатываний; можно ужесточить: "поднимай только то, что требует правки" - Конспект → можно попросить фиксировать не только утверждения, но и конкретные цифры, даты, имена — зависит от типа документа
Шаблон промпта
Ты — {роль эксперта}. Проверяй документ по частям.
ЧЕКЛИСТ ПРОВЕРКИ:
- {критерий 1}
- {критерий 2}
- {критерий 3}
- {критерий 4}
ВАЖНО: если сомнение снимается контекстом этого же абзаца —
не поднимай. Только реальные проблемы.
---
КОНСПЕКТ ИЗ ПРЕДЫДУЩИХ ЧАСТЕЙ:
{конспект — пусто для первой части}
---
ТЕКУЩАЯ ЧАСТЬ:
{текст части}
---
После комментариев дай ОБНОВЛЁННЫЙ КОНСПЕКТ:
ключевые утверждения, цифры и термины из этой части,
которые важно помнить при проверке следующих разделов.
Что подставлять:
- {роль эксперта} → инвестиционный аналитик / редактор / юрист / технический рецензент
- {критерий 1-4} → выбери из чеклиста выше или адаптируй под тип документа
- {конспект} → копируй из предыдущего ответа модели
- {текст части} → 500-800 слов из твоего документа
🚀 Быстрый старт — вставь в чат:
Вот шаблон для пошаговой проверки длинного документа
с накопленным конспектом. Адаптируй под мою задачу:
{опиши свой документ и что хочешь проверить}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит тип документа, роль эксперта и критерии проверки — потому что без этого она не знает, что считать ошибкой. Она адаптирует чеклист и структуру конспекта под твою задачу.
Ограничения
⚠️ Локальные технические ошибки: метод плохо ловит мелкие опечатки, числовые ошибки внутри одного уравнения или абзаца. Для этого лучше отдельный запрос с фокусом на конкретный раздел.
⚠️ Ложные срабатывания: главная жалоба реальных пользователей — модель поднимает несуществующие проблемы и придирается к мелочам. Инструкция «только реальные проблемы» снижает, но не устраняет. Всегда проверяй комментарии вручную.
⚠️ Ручной труд: конспект нужно копировать между запросами руками. Если документ больше 20 страниц — это 10+ запросов. Для очень длинных документов (договоры, отчёты на 50+ стр.) метод трудоёмок.
⚠️ Субъективные критерии: метод слабее работает для оценки стиля, тона, убедительности. Хорошо — для фактических противоречий и логических дыр.
Как исследовали
Команда из Чикагского университета взяла четыре системы автоматического рецензирования — OpenAIReview, 'coarse, Reviewer3 и простой zero-shot промпт — и прогнала через них реальные статьи с ICLR и NeurIPS 2021-2022. Проверяли простую гипотезу: слабые статьи должны получать больше комментариев. Сравнивали с внешними сигналами качества — числом цитирований, наградами конференций, оценками рецензентов. Все системы оказались выше случайного уровня: лучшая конфигурация (OpenAIReview + GPT-5.5) правильно определяла более слабую статью из пары в 83% случаев — и это без какого-либо специального обучения на задачу отбора статей.
Но корреляция с качеством не равна поимке конкретных ошибок. Поэтому команда построила второй бенчмарк: взяла 74 чистые статьи из 8 областей (от эконометрики до геномики), вручную внедрила известные ошибки четырёх типов и замерила, сколько из них системы поймают. Неожиданный результат: накопленная подсистема резюме OpenAIReview подняла обнаружение логических ошибок с 37% до 68% — почти вдвое, — но на математических опечатках внутри формул дала почти такой же результат, что и zero-shot. Это логично: локальная ошибка в уравнении не требует памяти о предыдущих разделах, а вот «в разделе 3 заявлено X, но в разделе 5 используется не-X» — требует. Ещё любопытная находка: разные модели ловят разные ошибки. Объединение всех шести моделей дало 83% recall против 72% у лучшей одиночной — прямое доказательство того, что несколько проходов разными «взглядами» лучше одного.
Адаптации и экстраполяции
🔧 Техника: несколько проходов с разным фокусом → больше ошибок поймано
Один проход ловит ~70% проблем. Исследование показало: разные модели ловят разные ошибки. Значит — два прохода с разными инструкциями лучше одного.
Первый проход — чеклист на логику и противоречия (как в шаблоне выше). Второй проход — другой фокус:
Ты — скептичный читатель. Найди места, где автор утверждает
X, но доказательств X нет. Не трогай логику и структуру —
только голословные заявления и притянутые выводы.
ТЕКУЩАЯ ЧАСТЬ:
{текст}
КОНСПЕКТ ЗАЯВЛЕННЫХ ФАКТОВ ИЗ ПРЕДЫДУЩИХ ЧАСТЕЙ:
{конспект}
Объедини комментарии обоих проходов — и убери дубли в финальном запросе.
🔧 Техника: финальный шаг фильтрации — против ложных срабатываний
Главная жалоба реальных пользователей: слишком много мелких придирок. Добавь финальный промпт после сбора всех комментариев:
Вот список комментариев к документу:
{все комментарии}
Отфильтруй по критериям:
- УБЕРИ: стилистические пожелания, форматирование,
«можно было бы написать лучше»
- УБЕРИ: комментарии, где проблема снимается контекстом
того же абзаца
- ОСТАВЬ: только то, что требует фактической правки
Сгруппируй оставшееся: Критические → Важные → Мелкие
Ресурсы
Benchmarking Agentic Review Systems — Dang Nguyen, Wanqing Hao, Yanai Elazar, Chenhao Tan. University of Chicago, Bar-Ilan University, 2025/2026.
OpenAIReview — открытый инструмент Chicago Human+AI Lab: github.com/ChicagoHAI/openreview-agent
Связанные работы: Liu & Shah (2023), Tyser et al. (2024) — более ранние бенчмарки AI-рецензентов; FLAWS (Xi et al., 2025), SPECS (Biswas et al., 2026) — параллельные бенчмарки на другом материале.