Договор аренды на 180 страниц, регламент с приложениями на 60 листов, годовой отчёт с таблицами в каждом разделе: для такого объёма нужна не обычная чат-модель, а нейросеть для больших текстов, которая удерживает всё в одном окне. Без неё текст обрывается на середине, модель забывает начало к концу разговора, а штраф за просрочку платежа из пункта 7.3 растворяется где-то между вашими сообщениями. Переписывать запрос по частям и вручную склеивать ответы не вариант: при каждом разделении риск упустить деталь растёт, а время на проверку съедает всю экономию от использования нейросети.
Статьи про сокращение текста нейросетью решают другую задачу: взять одну страницу и сжать её до абзаца. Здесь ситуация обратная: документ большой, и терять в нём нельзя ничего, ни одну сумму, ни один срок, ни одну оговорку в скобках. Нужна не компрессия смысла, а точная выжимка фактов из тысяч слов.
Контекстное окно у современных моделей измеряется сотнями тысяч и миллионами токенов, но для точной суммаризации одного объёма недостаточно. Важны ещё структура исходного документа и порядок, в котором вы просите модель искать детали. Чем крупнее документ, тем сильнее на итоговый результат влияет не сам объём окна, а то, как вы формулируете, что нужно найти и в каком виде это показать.
Какие нейросети для больших текстов держат контекст на миллион токенов
Токен это кусочек слова, в среднем три четверти обычного слова русского или английского текста. Миллион токенов это примерно 750 000 слов, то есть условный роман на тысячу страниц или увесистый пакет договоров сразу.
У моделей Claude Sonnet 5 и Claude Opus 4.8 окно на 1 000 000 токенов включено по умолчанию, без специальных настроек и без наценки за длинный запрос: цена остаётся стандартной независимо от объёма. У Gemini 2.5 Pro контекст составляет 1 048 576 токенов на обычном доступе, а в части корпоративных тарифов Vertex AI расширен до 2 000 000. У GPT-5 через API суммарное окно 400 000 токенов: 272 000 на входящий текст и 128 000 на ответ.
Выбор модели влияет не только на то, влезет ли документ целиком, но и на стоимость запроса: чем больше токенов на входе, тем выше цена ответа, даже если итоговая суммаризация занимает всего несколько абзацев. Для разовой задачи это не критично, а для потока из сотен документов в месяц разница в цене между моделями становится ощутимой статьёй расходов.
Для сравнения: модели с окном в 8 000 или 32 000 токенов, привычные по более ранним версиям чат-ботов, вмещают пять-десять страниц текста. Разница в сто раз, это разница между «вставьте выдержку из договора» и «загрузите договор целиком, со всеми приложениями».
Сколько это в страницах договора или отчёта
Один миллион токенов это примерно 750 000 слов. Типичная страница договора или регламента занимает от 300 до 400 слов, значит в окно влезает документ объёмом от 1800 до 2500 страниц. На практике это означает, что годовой отчёт, регламент со всеми приложениями и переписка по проекту помещаются в один запрос без разбиения на части.
Но вместить документ и правильно его обработать, это разные вещи. Чем ближе запрос к пределу окна, тем выше цена запроса и тем менее внимательно модель читает середину текста. Для большинства задач лучше оставлять запас: загружать документ на объём от 60 до 70% от максимума окна, а не впритык к лимиту.
На практике запас нужен и по другой причине: модель тратит часть окна на сам промпт, инструкции и собственный ответ, а не только на загруженный документ. Если не оставить резерва, часть текста рискует не поместиться вовсе, и об этом система предупредит отказом, а не тихой потерей куска.
Почему большое окно не гарантия, что деталь не потеряется
Google проверяла Gemini 2.5 Pro тестом на поиск конкретного факта, спрятанного в разных местах длинного текста. Результат: 100% точность при объёме до 530 000 токенов и 99,7% на полном окне в миллион токенов. Цифра выглядит почти идеальной, но на практике 0,3% это один упущенный факт из трёхсот, а в договоре таким фактом может быть условие о неустойке.
Отсюда правило: чем критичнее деталь, тем меньше ей место «где-то в большом контексте». Суммы, даты, стороны договора и штрафные санкции стоит либо запрашивать отдельным точечным вопросом после общей суммаризации, либо просить модель каждый раз указывать номер пункта, откуда взят факт. Проверить ссылку на пункт быстрее, чем перечитывать весь документ заново. Такой способ работы требует лишних пары минут, но экономит часы на повторном прочтении документа, если ошибка обнаружится только после подписания.
Как подготовить документ перед загрузкой
Качество подготовки документа определяет качество суммаризации сильнее, чем выбор конкретной модели: даже лучшая нейросеть не восстановит текст, который распознался с ошибками или потерял структуру при копировании.
- Сохраните структуру: заголовки разделов, нумерацию пунктов и подпунктов не убирайте, по ним модель ориентируется и на них же будет ссылаться в ответе.
- Прогоните сканы через распознавание текста до загрузки: нейросеть работает с текстом, а не с картинкой страницы, и качество распознавания напрямую влияет на точность суммаризации.
- Разделите основной договор и приложения на отдельные блоки в запросе и явно укажите в промпте, меняют ли приложения смысл основных пунктов.
- Уберите повторяющиеся колонтитулы и технический мусор: номера страниц и штампы «конфиденциально» на каждом листе забирают токены впустую.
- Если документ на несколько языков или содержит смешанную терминологию, укажите это в промпте явно: модель точнее подбирает термины, когда знает контекст заранее, а не угадывает его по ходу ответа.
Если документы содержат коммерческую тайну или персональные данные, часть компаний разворачивает модель на своём оборудовании, чтобы текст не уходил во внешний API: об этом подходе мы писали в статье про локальные LLM на своём железе.
Три способа суммаризировать большой документ
Одна длина окна не решает задачу суммаризации. Есть три рабочих подхода, и выбор между ними зависит от объёма документов и от того, нужен ли ответ по одному файлу или по целому архиву. Переключаться между подходами внутри одной задачи нормально: можно начать с загрузки всего документа целиком, а при разборе архива из похожих файлов перейти на индексацию и поиск по фрагментам.
| Подход | Как работает | Когда уместен |
|---|---|---|
| Весь документ в одном запросе | Документ целиком помещается в контекстное окно модели за один раз | Один договор или отчёт, разовая задача, объём укладывается в окно с запасом |
| Разбиение и свод (map-reduce) | Документ делится на части, каждая суммаризируется отдельно, затем сводится в общий вывод | Документ больше окна модели или нужно отдельное резюме по каждому разделу |
| RAG, поиск по фрагментам | Текст заранее разбит на куски и проиндексирован, модель получает только релевантные фрагменты под конкретный вопрос | Архив из десятков и сотен документов, повторяющиеся вопросы, нужна ссылка на источник |
Третий подход устроен иначе, чем просто большое окно: вместо того чтобы читать всё, модель находит нужный фрагмент и отвечает по нему. Принцип такого поиска по документам разобран в статье о том, что такое RAG простыми словами.
Промпт, который не даёт нейросети упускать важное
Запрос «сделай краткое содержание договора» почти гарантированно потеряет детали. Рабочий промпт для юридического или финансового документа обычно просит модель явно перечислить:
- стороны договора, их реквизиты и роли;
- все суммы, сроки и даты с указанием пункта, где они указаны;
- условия штрафов, неустоек и оснований для одностороннего расторжения;
- ссылки на приложения и то, меняют ли они основные условия;
- противоречия между пунктами, если модель их заметила.
Полезно дополнительно попросить модель указывать степень уверенности там, где формулировка в документе неоднозначна: это отделяет факт, который прочитан дословно, от интерпретации, которую модель сделала самостоятельно.
Дальше имеет смысл второй проход: попросить модель перепроверить собственную суммаризацию на пропуски, задав прямой вопрос «какие пункты документа не попали в резюме». Этот шаг занимает один дополнительный запрос, но ловит именно те детали, которые выпадают при первом быстром прогоне.
Частые ошибки при суммаризации больших документов
- Доверяют итоговым цифрам без проверки: сумму или дату из суммаризации сверяют с оригиналом только после того, как договор уже подписан.
- Загружают несколько разных договоров в один запрос, и модель начинает путать условия одного документа с другим.
- Просят «пересказать» без заданной структуры ответа и получают текст, из которого так же сложно выдернуть конкретный пункт, как из оригинала.
- Не указывают формат ответа и получают текст без структуры, а не таблицу или список, по которому легко свериться с оригиналом.
- Игнорируют версию документа: в архиве из десяти редакций одного регламента модель суммаризирует не ту версию, если дата и номер редакции не указаны в запросе явно.
Частые вопросы
Сколько страниц текста влезает в один запрос к нейросети?
При окне на миллион токенов, которое сейчас есть у Claude Sonnet 5, Claude Opus 4.8 и Gemini 2.5 Pro, в запрос помещается документ объёмом от 1800 до 2500 страниц обычного текста. Модель GPT-5 через API, с окном в 400 000 токенов, вмещает примерно от 500 до 700 страниц за один раз.
Теряются ли детали при суммаризации длинного документа?
Да, частично. Тест Google на поиск факта в длинном тексте показал у Gemini 2.5 Pro точность 99,7% на полном окне в миллион токенов против 100% при объёме до 530 000 токенов: на практике это один упущенный факт из нескольких сотен. Критичные суммы и сроки стоит перепроверять отдельным точечным запросом.
Чем суммаризация большого документа отличается от сокращения текста?
Сокращение берёт готовый короткий текст и сжимает его до нескольких фраз, сохраняя общий смысл. Суммаризация большого документа работает с тысячами слов и обязана сохранить каждую отдельную деталь: сумму, дату, сторону договора. Для короткой заметки подойдёт обычное сокращение текста, а для договора на сто страниц нужен другой подход: большой контекст и точечная проверка деталей.
Можно ли загрузить юридический договор целиком в нейросеть, если в нём есть персональные данные?
Технически да, если окно модели вмещает документ. Но для данных с коммерческой тайной или персональными данными многие компании выбирают модель, развёрнутую на собственном оборудовании, а не облачный API: это снимает вопрос о том, куда уходит текст договора после отправки запроса.
Нужен ли RAG, если у модели уже контекст на миллион токенов?
Для одного документа нет: он целиком помещается в окно, и RAG избыточен. Для архива из сотен договоров и регламентов RAG эффективнее: вместо того чтобы каждый раз прогонять через модель весь архив, система находит только релевантные фрагменты под конкретный вопрос.
С чего начать
Если документов немного и они укладываются в контекст одной модели, начните с простого: выгрузите текст без сканов и картинок, сохраните нумерацию пунктов и задайте один точный промпт со списком того, что нужно извлечь. Первый прогон лучше делать на одном документе, а не сразу на всём архиве, чтобы оценить, какие детали модель упускает и как доработать промпт.
- Соберите документы в текстовом виде и проверьте, что распознавание не искажает цифры и даты.
- Выберите модель по объёму архива: для одного договора подойдёт окно от 200 до 400 тысяч токенов, для архива из десятков файлов понадобится RAG или модель с окном на миллион токенов.
- Составьте промпт со списком обязательных пунктов: стороны, суммы, сроки, штрафы, ссылки на приложения.
- Добавьте контрольный проход: попросите модель перепроверить собственную суммаризацию на пропуски.
Если разбираться с этим самостоятельно не хочется, превращение потока договоров, отчётов и регламентов в структурированные данные для аналитики берут на себя при оцифровке документов для BI.
