Длинный документ для ИИ: целиком или по частям — что надёжнее

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

Маршрут А: один документ, один запрос

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

Недостаток — непрозрачность покрытия. Даже если весь текст технически принят, ответ может подробно пересказать начало и конец, а середину почти не затронуть. Повторный запрос «не забудь важное» плохо диагностирует пропуск: вы не знаете, какой именно раздел не прочитан. Модели иногда приписывают выводу страницу, на которой встречается похожий термин, но нет самого условия. Проверяйте цитируемый фрагмент, а не только наличие номера страницы. Если файл состоит из сканов, к риску суммаризации добавляется риск неверного распознавания; сначала нужен контроль чтения изображения.

Маршрут Б: выписки по разделам

Разделите документ по смысловым границам: глава, раздел договора, приложение, блок таблиц. Не режьте посреди определения или таблицы ради одинаковой длины кусков. Для каждого фрагмента получите короткую структурированную выписку: главный тезис, числовые условия, исключения, неопределённости, место в источнике. Затем попросите объединить выписки, сохраняя ссылки на фрагменты. Этот маршрут похож на map-reduce, но в редакторской работе важнее человеческая проверка карты фактов, чем название схемы.

Плюс — можно увидеть покрытие. Если в таблице выписок отсутствует раздел о штрафах, его легко вернуть до публикации. Локальная ошибка не обязана переписывать весь документ. Минус — разбиение может потерять зависимость между разделами. Например, общий термин определён в начале, а исключение находится в приложении. Поэтому при сборке нужен отдельный проход по перекрёстным ссылкам и спорным пунктам. Финальная модель не должна «сглаживать» противоречие между двумя выписками: оно должно остаться помеченным до ручной сверки.

Как устроить честное сравнение

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

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

В отчётной таблице укажите, кто проверил ответы. Автор модели не должен быть единственным оценщиком собственного результата. Числа пересчитайте формулой или калькулятором, а не повторным вопросом той же модели. В гайде по формулам после ИИ показана аналогичная проверка расчёта отдельно от текста. Если документ содержит множество повторяющихся терминов, система поиска по тексту или пара embedding + reranker может помочь найти места, но найденный фрагмент всё равно нужно прочесть в контексте.

Какой подход выбрать

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

Большое контекстное окно стоит воспринимать как возможность, а не как сертификат полноты. Модель может вместить страницу и всё же неверно трактовать её. Ограничение токенов, формат файла и поведение инструмента при загрузке иногда меняют фактический объём доступного текста; не считайте размер исходного PDF доказательством того, что модель получила каждую страницу. Уточните, появился ли текстовый слой и есть ли предупреждения об обрезке. Перед внешней загрузкой выполните проверку скрытых данных.

Практический вывод

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

Нужно ли делать одинаковые по длине части? Нет. Граница определения, таблицы или приложения важнее равного числа символов.

Можно ли просить модель собрать общий вывод без выписок? Можно, но сложнее доказать, какие разделы она учла; для ответственной публикации сохраните промежуточные заметки.

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