Почему нейросеть «теряет» середину документа и что с этим делать?

Вендоры хвастаются окнами в миллион токенов, но недавнее исследование Context Rot Evaluation взорвало эту иллюзию. Оказалось, что модели видят начало и конец документа почти идеально, а вот середина превращается в слепую зону. Статистика поражает: при размещении задачи в центре длинного контекста точность падает до нуля, даже если по краям модель показывает 100%. Разбираем пять вопросов, которые помогут понять проблему и научиться её обходить.

Правда ли, что большое контекстное окно — это гарантия качества?

Нет. Исследование Context Rot доказало: усреднённый скор в 80% может скрывать реальную картину — 100% на концах и 0% в середине. Модель физически не может удерживать внимание равномерно по всему окну. Механизм attention в трансформерах устроен так, что веса распределяются неравномерно: начало и конец получают больше ресурсов, середина остаётся в тени. Это не баг конкретной модели — это архитектурное ограничение семейства трансформеров.

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

Почему модель путает задачу с контекстом?

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

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

Как заставить модель «видеть» середину документа?

Три рабочих приёма:

• Дублирование критичного. Если задача решается по длинному документу, продублируйте ключевую инструкцию в самом конце. Это эффект middle_dup: модель лучше всего обрабатывает последние токены перед генерацией ответа.
• RAG вместо сырого контекста. Не пихайте в окно весь документ целиком. Используйте поиск по векторным базам и передавайте только 3–6 наиболее релевантных фрагментов с понятными заголовками и метаданными.
• Конспектирование длинной истории. Если диалог растянулся, попросите модель самостоятельно составить сводку ключевых договорённостей и используйте её вместо полной истории.

Одинаково ли работают промпты на разных моделях?

Нет. Свежее исследование Spurious Prompts показало: промпт, идеально работающий на одной модели, может провалиться на другой. Причина — в токенизации. У GPT, Claude и Gemini разные токенизаторы, и они по-разному режут слова на части. Если токен не совпадает с естественной морфемой, модель тратит больше ресурсов на сборку смысла. Например, слово «непременно» GPT разбивает на «непр» и «еменно», а «обязательно» — на естественную приставку «об-язательно». Reasoning-модели это компенсируют, но на размышления уходят токены — то есть ваши деньги.

Практический совет: избегайте составных конструкций с дефисами и редких слов. Вместо «cost-effective» пишите «cheap». Это не упрощение ради упрощения — это снижение когнитивной нагрузки на модель и экономия токенов.

Что делать, если задача требует точного подсчёта или проверки условия?

Выносите её в код через Tool Calling. Современные reasoning-модели решают такие задачи лучше, потому что заставляют себя рассуждать пошагово и перепроверять. Но даже они спотыкаются на нестандартных формулировках. Если вам нужен точный результат — подсчёт символов, проверка условия, разбор по формату — не уговаривайте модель «стараться лучше». Напишите функцию на Python или JavaScript и дайте модели возможность вызвать её явно.

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

Можно ли полностью избежать «контекстной гнили»?

Полностью — нет, но можно минимизировать. Главное — понимать, что контекстное окно — это не монолитное пространство с равномерным вниманием. Это градиент, где края работают лучше середины. Стройте архитектуру с учётом этого ограничения: используйте RAG, дублируйте критичные инструкции, структурируйте данные, выносите точные операции в код. И всегда тестируйте реальные сценарии, а не только усреднённые метрики.

Все упомянутые модели — GPT, Claude, Gemini — доступны в GEMERA AI через единый интерфейс. Попробуйте разные подходы к работе с длинным контекстом и найдите оптимальную стратегию для ваших задач.