Нейросети для работы с большими текстами держат договор на сто страниц или стенограмму совещания целиком, если документ разбит на смысловые части с общей инструкцией либо загружен через поиск по фрагментам вместо разовой вставки в чат. Дальше — что такое контекстное окно, какие модели держат длинный текст, три приёма разбивки и готовый промпт для выжимки из документа.
Что такое контекст
Контекстное окно — объём текста, который модель держит за один раз: у популярных моделей это от нескольких десятков тысяч токенов до 1 млн у DeepSeek (по документации вендора, сентябрь 2026); за границей окна начало документа выпадает из внимания модели, и ответ строится на обрывке вместо целого текста.
Каждая нейросеть работает с ограниченным объёмом текста за один запрос — это и называется контекстным окном (подробнее — в словаре: контекстное окно). Договор на сто страниц, стенограмма трёхчасового совещания или регламент компании легко превышают этот объём, если вставить текст в чат целиком одним куском. Модель тогда обрезает вход по границе окна либо держит в внимании начало и конец, а середина документа тонет — отсюда типичная жалоба «нейросеть забыла, что было в середине файла». Проблема решается на уровне подготовки текста, а модель тут ни при чём: разбивка на части, суммаризация по слоям и поиск по фрагментам (RAG) — три рабочих приёма для документа, который выходит за границы окна. Размер окна считают в токенах, а страницы и символы для этого расчёта — единица неудобная: один токен — это примерно часть слова, и русский текст обычно занимает больше токенов на тот же объём символов, чем английский, из-за особенностей разбивки слов на части.
Модели с длинным окном
Разница между моделями по длине контекста ощутима на практике, и выбор стоит делать под объём документа. Claude уверенно держит крупный файл целиком и хорошо помнит начало на длинной сессии — подходит для разбора договора или книги регламентов за один проход. DeepSeek заявляет контекст до 1 млн токенов на входе (по документации вендора на сентябрь 2026) — годится для сверки объёмного массива документов. YandexGPT рассчитан скорее на короткие и средние по объёму русскоязычные тексты — для крупного файла его стоит сочетать с разбивкой на части вместо расчёта на разовую загрузку целиком. Проверять заявленный лимит контекста стоит на своём документе, а общие цифры из рекламы сервиса тут плохой советчик: реальная стабильность памяти модели на всей длине текста часто заметно ниже паспортного значения, особенно ближе к самой границе окна.
| Модель | Длина контекста | Когда выбрать |
|---|---|---|
| Claude | держит документ целиком, крупные файлы без потери начала | разбор договора, книги регламентов за один проход |
| DeepSeek | до 1 млн токенов на входе (данные вендора, сентябрь 2026) | сверка объёмного массива документов |
| YandexGPT | рассчитан на короткие и средние русскоязычные тексты | короткие регламенты и письма, крупный файл — через разбивку |
Три приёма разбивки
Три приёма закрывают почти любую задачу с объёмным текстом, и комбинировать их обычно продуктивнее, чем держаться одного универсального способа.
- Разбивка на части с общей инструкцией: документ делится по границам смысла — глава, раздел, спикер в стенограмме — и в начало каждой части добавляется одна и та же инструкция про роль и формат ответа, чтобы куски обрабатывались одинаково.
- Суммаризация по слоям: сначала модель сжимает каждую часть до ключевых фактов, потом отдельным запросом собирает выжимку из выжимок — так объём падает в разы, а структура документа сохраняется на каждом шаге (подробнее — суммаризация).
- Поиск по фрагментам через RAG: документы разбиваются на куски (chunking), индексируются, и модель получает только релевантные фрагменты под конкретный вопрос вместо всего файла — приём дороже в настройке, зато переживает рост архива документов без пересборки процесса.
Какой у вас самый объёмный документ на работе?
Промпт для выжимки
Шаблон промпта для выжимки собирает четыре поля — роль, формат, объём и то, что модель обязана процитировать дословно, — и одинаково работает что на одной части документа, что на суммарии суммарий с предыдущего шага.
Ты — {роль: аналитик/юрист/редактор}. Вот часть документа: {текст части}. Собери выжимку из {N} пунктов, каждый пункт — факт из текста плюс дословная цитата в кавычках как подтверждение. Формат: нумерованный список. Пропусти общие фразы и вступления — только факты с числами, датами, именами и обязательствами сторон.
Короткий вариант для мелкой части: «Выдели из текста ниже три главных факта с цитатой на каждый». Вариант для сборки суммарии из суммарий: «Вот {N} выжимок по частям одного документа. Собери из них единый список без повторов, сохрани все цифры и даты».
Три проверки перед сдачей
Три проверки экономят больше времени, чем повторная генерация всего разбора. Первая — границы частей: если резка прошла посреди предложения или пункта договора, смысл рвётся, и это стоит поймать до отправки выжимки дальше по цепочке. Вторая — фрагменты RAG: модель иногда получает кусок текста мимо сути вопроса и достраивает ответ из общих знаний вместо документа — такой ответ стоит сверять с источником построчно. Третья — числа и даты: суммаризация по слоям быстрее всего теряет именно цифры, потому финальную выжимку сверяют с оригиналом хотя бы по датам и суммам обязательств. Ручная проверка занимает считаные минуты на документ среднего объёма, зато снимает риск, что ошибка из суммаризации уйдёт дальше в отчёт или письмо клиенту незамеченной.
Возьмите документ, который недавно резали руками на части для чтения, и прогоните тем же промптом выжимки. Метрика проверки: все даты и суммы из оригинала нашлись в выжимке дословно — если хоть одна пропала, часть промпта про цитаты работает слабо и её стоит ужесточить.
Как нейросеть держит документы целиком, разобрано в статье Claude для документов, а разница между RAG и дообучением модели под задачи компании — в материале RAG или дообучение модели. Если нужен контур, который читает архив документов компании и отвечает по нему постоянно, — это к нам, в раздел нейросетей и RAG-систем для документов. Для разового разбора хватает трёх приёмов выше — постоянный контур собирают, когда объём документов растёт каждую неделю, а разовый разбор уже перестаёт справляться.