Вы даёте модели договор на сорок страниц и спрашиваете про пункт, который стоит примерно посередине. В карточке модели написано число, в которое этот договор укладывается с многократным запасом. Модель отвечает уверенно, связно и мимо: пересказывает начало документа, а про нужный пункт сообщает то, чего в нём нет. Тот же вопрос по первым пяти страницам она разбирает безошибочно.
Это не сбой и не невезение. Между числом в карточке и длиной, на которой модель ещё надёжно работает с содержанием, лежит разрыв, и он бывает кратным. Хуже того, ограничителей на самом деле два, и второй чаще всего оказывается ниже первого — про него забывают.
Дата написания — 25 августа 2026 года. Конкретных моделей и процентов ниже нет: профиль деградации у каждой модели свой, а вот его форма и способ измерения общие.
#Короткий ответ
Заявленное контекстное окно — это техническая граница, за которой рантайм откажется принимать вход. Полезная длина — та, на которой модель ещё находит нужный факт, сопоставляет разнесённые куски и не подменяет содержание правдоподобным пересказом. Вторая величина меньше первой, у некоторых моделей — в разы, и в карточке она не публикуется, потому что зависит от типа задачи.
Проверяется это за час собственным тестом. Ниже — как он устроен и что искать в результатах.
#Два разных ограничителя, которые постоянно путают
Первый — окно самой модели. Число из карточки: сколько токенов архитектура принимает на вход. Что такое токен и как устроено само окно, разобрано в справке о том, что такое контекстное окно.
Второй — окно, выставленное в рантайме. У локальных рантаймов есть собственный параметр длины контекста (в Ollama это num_ctx) со значением по умолчанию, и оно, как правило, заметно меньше заявленного окна модели, потому что каждый лишний токен занимает память под KV-кэш. Конкретная величина по умолчанию зависит от версии рантайма — посмотрите её в своей конфигурации, а не предполагайте.
Практическое следствие неприятное: если вы подали документ длиннее выставленного окна, ошибки вы обычно не увидите. Рантайм молча отбросит то, что не поместилось — чаще всего начало диалога или начало документа, — и модель ответит по остатку, ничем не выдав пропажу. Симптом «модель уверенно отвечает по тексту, которого не видела» в половине случаев объясняется не деградацией, а тихой обрезкой.
#Почему полезная длина короче заявленной
Три причины, все структурные.
Обучение шло преимущественно на коротких текстах. Большие окна у многих моделей получены расширением позиционного кодирования уже после основного обучения: вход модель принимает, но обучающего опыта на дальних позициях меньше, и поведение там менее отработанное.
Внимание размывается. Механизм внимания распределяет ограниченный бюджет между всеми токенами входа: чем длиннее вход, тем слабее выделяется один конкретный факт, особенно если вокруг много похожих формулировок.
Позиции неравноценны. Начало и конец входа удерживаются устойчивее середины — эффект настолько регулярный, что получил собственное название и отдельный разбор в статье про контекстное окно и потерю в середине.
Добавьте разницу типов задач: достать одну строчку из длинного текста модель умеет заметно дольше, чем сопоставить два разнесённых факта. Заявления о поддержке очень длинного контекста обычно опираются на первый тип — переносится ли это на второй, разбирается в материале про окно в миллион токенов.
#Тест «иголка в стоге сена» своими руками
Идея простая: спрятать в длинном тексте проверяемый факт и смотреть, находит ли его модель в зависимости от длины текста и от места закладки.
- Возьмите свой текст, а не случайный. Тематически однородный документ из вашей работы — это честнее, чем склейка новостей: на разнородном тексте иголка выделяется контрастом и находится легче, чем в реальности.
- Придумайте иголку. Короткая фраза с сочетанием, которого в тексте больше нигде нет: выдуманное имя, редкий термин, точное число. Проверьте поиском по файлу, что совпадений нет.
- Соберите версии разной длины. Четверть выставленного окна, половина, три четверти и почти предел. Считайте в токенах, а не в символах, с запасом на промпт и ответ.
- Расставьте иголку по позициям. Для каждой длины сделайте отдельные версии: иголка в начале, на четверти, в середине, на трёх четвертях, в конце. Получится сетка «длина × позиция».
- Задавайте один и тот же вопрос. Формулировка вопроса не должна дословно повторять формулировку иголки, иначе вы измеряете поиск по подстроке. Температура — ноль, системный промпт — общий для всех прогонов, каждая ячейка сетки прогоняется в чистой сессии.
- Считайте попадания по ячейкам. Факт засчитывается, только если воспроизведён точно; «примерно про то же» — промах.
- Добавьте второй уровень сложности. Две иголки в разных частях текста и вопрос, требующий их сопоставить: здесь граница проходит заметно раньше.
Ту же дисциплину — фиксированные условия, одинаковый промпт, запись результатов в форму — стоит соблюдать и в остальных проверках; полная процедура описана в гайде о том, как тестировать модель на своих задачах.
#Качественный профиль падения по длине
Таблица ниже — не измерение и не средние по моделям, а описание симптомов, которые появляются по мере приближения к пределу окна. У каждой модели своя граница, и найти её можно только тестом выше: вторая колонка — признаки, третья — что с ними делать.
| Доля окна | Что обычно наблюдается | Как проверить |
|---|---|---|
| До четверти | Факты находятся независимо от позиции, сопоставление разнесённых кусков работает | Одна иголка в каждой позиции — попадания должны быть везде |
| Около половины | Начало и конец держатся, середина начинает теряться первой | Сравнить попадания в середине и по краям при одинаковой длине |
| Три четверти | Извлечение одного факта ещё работает, сопоставление двух разнесённых — уже нестабильно | Тест с двумя иголками против теста с одной |
| У самого предела | Ответ становится пересказом общего содержания, детали подменяются правдоподобными | Спросить дословную цитату вокруг иголки |
| За пределом | Тихая обрезка: модель отвечает по остатку и не сообщает о пропаже | Спросить про первую фразу документа |
Вывод из таблицы: деградация нарастает постепенно, и раньше всего страдает не извлечение, а связывание фактов из разных частей текста. Задача «найди пункт про сроки» получается дольше, чем «сравни сроки в двух приложениях», хотя обе выглядят одинаково.
#Что из этого следует на практике
Планируйте бюджет длины, а не полагайтесь на предел. Разумная рабочая привычка — держаться в пределах той доли окна, на которой ваш тест показал устойчивые попадания, и считать остальное аварийным запасом.
Режьте документ сами. Осмысленное разбиение на разделы с последующей сборкой ответа обычно точнее, чем подача всего файла целиком: вы контролируете, что попало в запрос, а модель работает с фрагментами из зоны уверенной работы.
Кладите важное по краям. Инструкцию и ключевое условие — в начало и продублируйте в конце запроса. Это дешёвый приём, который заметно улучшает результат на длинном входе.
Проверяйте цитатой. Попросите привести дословную фразу из документа рядом с ответом: подмена содержания правдоподобным пересказом на цитате видна сразу.
Помните про цену длины. Длинный контекст занимает память под KV-кэш и замедляет ответ. Модели с заявленным очень длинным окном — включая семейства, разобранные в обзоре моделей GLM и Kimi, — требуют этой памяти реально, а не в теории.
Поправка для ассистентов с памятью: к документу там добавляются выдержки из прошлых разговоров и заметок. В Persona такой блок собирается перед каждым ответом и занимает то же окно, поэтому бюджет длины меньше, чем кажется по размеру файла.
#Где интуиция подводит
«Влезло — значит, обработано». Отсутствие ошибки означает только то, что вход поместился в окно. Качество работы с содержанием на границе окна и в его начале различается принципиально.
«Модель забыла — надо взять модель с окном побольше». Большее заявленное окно не обязано означать большую полезную длину: у модели с вдвое большим числом в карточке профиль может проседать на той же абсолютной длине. Сравнивать нужно результаты теста, а не цифры карточек, — и делать это внутри того размерного класса, который вообще помещается в вашу память, как описано в разборе того, какую модель выбрать под задачу и железо.
«Проблема в модели». До измерения это неизвестно. Первым делом проверяется значение длины контекста в рантайме: тихая обрезка входа даёт ровно ту же картину, что и деградация, и встречается чаще.
#Частые вопросы
#Почему модель теряет информацию из середины документа?
Начало и конец входа удерживаются устойчивее середины — это регулярный эффект, связанный и с распределением внимания, и с тем, как модель обучалась на длинных последовательностях. Практическое следствие: важные условия стоит помещать в начало запроса и дублировать в конце, а не оставлять в середине большого текста.
#Чем заявленный контекст отличается от реального?
Заявленный — это техническая граница входа, за которой запрос не будет принят. Реальный, или полезный, — длина, на которой модель ещё находит нужные факты и связывает их между собой. Вторая величина меньше первой и в карточках не публикуется, потому что зависит от типа задачи.
#Как проверить реальный контекст модели самому?
Спрятать в своём длинном документе фразу, которой там больше нигде нет, собрать версии разной длины с закладкой в разных позициях и задавать один и тот же вопрос при нулевой температуре. Ответ засчитывается только при точном воспроизведении факта. Отдельно стоит прогнать вариант с двумя иголками, которые нужно сопоставить: там граница проходит раньше.
#Что такое num_ctx и почему это важно?
Это параметр длины контекста в рантайме — то, сколько токенов он готов держать в KV-кэше для данной модели. Значение по умолчанию обычно меньше заявленного окна модели, и всё, что не поместилось, отбрасывается без предупреждения. Проверять его нужно до любых выводов о качестве работы модели с длинным текстом.
#Модель с окном в миллион токенов действительно читает целую книгу?
Она принимает такой объём на вход, и это правда. Насколько устойчиво она при этом связывает факты из разных глав — вопрос отдельный, и ответ на него даёт только проверка на вашем материале. Извлечение одного факта держится существенно дольше, чем сопоставление нескольких разнесённых.
#Вывод
Число в карточке модели отвечает на вопрос «что примет вход». Ваш вопрос звучит иначе: «на какой длине ответы ещё можно использовать без перепроверки». Между этими двумя величинами стоит разрыв, у каждой модели свой, и никакая таблица за вас его не измерит.
Если вы работаете с текстами в пределах нескольких страниц — разрыв вас не касается, берите любую модель подходящего класса. Если ваша работа — длинные документы, потратьте час на тест с иголкой, зафиксируйте долю окна, на которой попадания устойчивы, и стройте работу внутри неё. И прежде чем менять модель на другую с более впечатляющим числом, проверьте значение длины контекста в рантайме: очень часто теряет факты не модель, а настройка.