TL;DR
Модель может идеально процитировать конкретный пункт из огромного документа, но при этом полностью проигнорировать его, когда принимает финальное решение на основе этого документа. Это два разных навыка — найти информацию и использовать её, — и они расходятся по мере роста объёма текста вокруг важного факта.
Представь: просишь LLM прочитать 100-страничный отчёт компании и дать рекомендацию — покупать акции или нет. Спроси её прямо: "какой там порог по кредитному ковенанту?" — она процитирует точно, даже если документ на 128 тысяч токенов. Но попроси финальную рекомендацию с учётом всего документа — и этот критичный пункт как будто исчезает, решение выглядит так, будто его там вообще не было. Причина: по мере чтения длинного текста модель сжимает прочитанное во что-то вроде краткого резюме в голове, и конкретные детали из середины документа вымываются из этого резюме — хотя сам текст остаётся доступен для точечного поиска.
Решение простое: не полагаться на то, что модель "просто прочитала" весь документ и всё учла. Нужно вручную (или отдельным запросом) вытащить ключевой факт, сформулировать его как короткий структурированный тезис и разместить прямо перед финальным вопросом-решением, оставив полный документ доступным. Просто скопировать фрагмент текста туда же — не работает, нужен именно пересказ по сути.
Схема метода
ШАГ 1: Дать модели документ + прямой вопрос "найди и процитируй факт X" → точная цитата (отдельный запрос)
ШАГ 2: Взять эту цитату и сжать в 2-3 структурированных предложения → короткий тезис
ШАГ 3: Вставить тезис прямо перед финальным вопросом-решением, документ выше остаётся в контексте → запросить итоговое решение
Шаги 1 и 2 можно сделать в одном сообщении. Шаг 3 — либо в том же чате, либо новым сообщением сразу после.
Пример применения
Задача: Основатель стартапа получил term sheet от инвестора на 40 страниц и просит ChatGPT дать рекомендацию — подписывать или нет. Где-то в середине документа зарыт пункт про ликвидационную преференцию 3x — критично важная деталь, которая означает, что инвестор забирает тройной размер своих денег раньше основателей при продаже компании.
Промпт:
Вот term sheet: [вставить документ]
Шаг 1: Найди и процитируй точно пункт про ликвидационную преференцию.
Шаг 2: Ключевой факт для решения: ликвидационная преференция 3x означает,
что при продаже компании инвестор первым забирает тройной размер своих
вложений, и только остаток делится между основателями и другими
акционерами.
С учётом этого факта и всего документа выше — дай рекомендацию:
стоит ли подписывать этот term sheet, и на что обратить внимание при
переговорах?
Результат: Модель даст рекомендацию, которая явно упоминает риск ликвидационной преференции и взвешивает его в обосновании — например, посоветует пересмотреть этот пункт на переговорах. Без явного выноса факта вперёд, при длинном документе, модель скорее всего даст общую положительную рекомендацию и не упомянет этот риск вовсе — не потому что не "видела" пункт, а потому что он не попал в финальное суждение.
Почему это работает
Модель читает документ последовательно и по ходу дела сжимает всё в компактное резюме — рабочую память ограниченного объёма. Конкретные цифры и детали из середины текста в этом резюме теряются, хотя оригинальный текст остаётся доступен для прямого поиска — модель может "подсмотреть" туда, если её прямо спросить.
Модель отлично умеет находить факт по запросу — это её сильная сторона, и она не деградирует даже на очень длинных документах. Метод использует именно эту силу: вместо того чтобы надеяться, что нужный факт сам "всплывёт" в резюме к моменту решения, мы вручную достаём его через точечный retrieval и физически кладём рядом с вопросом-решением. Модели не нужно вспоминать факт из сжатой памяти — он уже прямо перед глазами.
Рычаги управления: объём тезиса (2-3 предложения работают лучше, чем целый абзац исходного текста — важна структура, не копипаста); количество фактов, которые выносишь вперёд (можно вынести несколько критичных пунктов списком); момент вставки (сразу перед финальным вопросом, не в начале документа).
Шаблон промпта
Вот документ: {документ}
Шаг 1: Найди и процитируй точно: {конкретный_факт}
Шаг 2: Ключевой факт для решения: {краткое изложение факта своими словами, 2-3 предложения}
С учётом этого факта и всей информации в документе выше, ответь на вопрос:
{финальный_вопрос_или_решение}
🚀 Быстрый старт — вставь в чат:
Вот шаблон метода "вынос ключевого факта перед решением". Адаптируй под
мою задачу: {твоя задача}. Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой документ ты анализируешь, какой факт в нём критичен для решения и какое именно решение нужно принять — потому что без этого невозможно понять, что именно вынести вперёд и в каком виде.
Ограничения
⚠️ Повторение текста не помогает: просто вставить исходный фрагмент документа целиком рядом с вопросом почти ничего не даёт — нужен именно короткий структурированный пересказ сути, не копипаста.
⚠️ Суммаризация по кускам вредит: если попросить модель сначала сжать документ по частям, а потом решать на основе этих заметок — важный факт может потеряться ещё на этапе сжатия, раньше, чем дойдёт до решения.
⚠️ "Подумай дольше" не спасает: включение расширенного размышления (reasoning) не восстанавливает влияние факта, а на коротких документах даже немного его снижает.
⚠️ Более мощные модели не иммунны, просто выносливее: топовые модели держат факт в решении на более длинных документах, но при достаточно большом объёме текста разрыв между "нашла" и "использовала" появляется и у них.
Как исследовали
Исследователи взяли 12 реальных американских компаний и для каждой придумали проверяемый риск-факт — порог по кредитному ковенанту, сумму штрафа, лимит компенсации — который выглядит естественно в отчёте 10-K. Дальше замеряли раздельно две вещи: может ли модель точно процитировать этот факт (retrieval) и насколько его присутствие меняет итоговое инвестиционное решение по сравнению с версией, где вместо факта — нейтральный текст такой же длины (это и назвали marginal decision influence).
Ключевой трюк дизайна: окружающий несвязанный текст постепенно увеличивали с 2 000 до 128 000 токенов, а сам важный факт не трогали — это отделило эффект "слишком много лишнего текста" от эффекта "модель узнала что-то ещё существенное". Результат оказался резким: на коротком документе факт двигал решение на несколько процентных пунктов, но уже на 8-32 тысячах токенов влияние падало до уровня шума — то есть было неотличимо от вставки случайного нейтрального текста, — и оставалось там до 128 тысяч токенов. При этом retrieval оставался почти идеальным на всех длинах.
Эффект проверили на трёх разных семействах моделей и на 20 реальных 10-K отчётах — убирая из них подлинные раскрытия информации — и картина повторилась. Через анализ внутренних представлений модели и причинные интервенции (перенос "сжатого состояния" между документами) выяснили механизм: факт остаётся закодирован там, где был прочитан, но плохо "доезжает" до места принятия решения. Именно это натолкнуло на рабочее решение — вынести факт структурированно прямо к месту решения, что восстановило его влияние даже на самом длинном контексте.
Ресурсы
"Reading Is Not Using: Retrieval, Judgment, and the Design of AI Financial Research Workflows" — Miao Liu (Boston College, Carroll School of Management), Zhizhe Liu (Columbia Business School), препринт, август 2026.