Комментарии 9
Сначала порывался написать токсичный комментарий потому что тема вроде уже изъезжена, ну после первого абзаца счел вашу статью полезной. Спасибо!
Комментарий:
Очень хорошо сформулировано ключевое заблуждение про длинный контекст: техническая возможность «проглотить» токены ≠ способность с ними рассуждать. По сути, здесь ровно та же проблема, что и в железе или распределённых системах — рост объёма без архитектурных ограничений снижает управляемость.
Context rot, падение SNR и деградация reasoning выглядят как следствие отсутствия жёсткой границы между «разрешённым» и «шумом». Модель не ломается по памяти, она ломается когнитивно: внимание размазывается, конфликты не подавляются, синтез становится нестабильным.
Очень показательно, что практические решения все сводятся не к «ещё больше контекста», а к архитектурным приёмам: отсечка дистракторов, иерархическая саммаризация, кэширование статики, явное разделение ролей данных. То есть не усиление модели, а сжатие и формализация пространства допустимого.
По ощущениям, следующий реальный прорыв в long-context будет не в размере окна, а в механизмах активного ограничения и валидации контекста — примерно как тактирование и запрещённые состояния когда-то сделали цифровую электронику устойчивой.
Спасибо за статью!
Получается в случае RAG, если вопрос достаточно простой и для ответа на него достаточно "найти пароль в тексте", то можно делать огромный контекст на 1м токенов. А если для вопроса необходимо прочитать и сопоставить несколько разных отрывков, то лучше контекст ограничивать воизбежание когнитивной перегрузки модели.
Тогда возникает вопрос. А что если для ответа на вопрос достаточно взять конкретный кусок контекста на 10к токенов и немного его перефразировать. Снижает ли в этом случае огромный контекст качество ответа? Это довольно популярный кейс, когда имплементируется RAG по внутренней базе знаний и на этапе ретривела находится несколько десятков страниц и скорее всего только одна из них содержит ответ.
Я вот DeepSeek использую для посчёта голосов в одной онлайн игре. Так вот заметил , при том , что он крайне подробно описывает процесс подсчёта, после 4-5 подсчёта он впадает в "белую горячку" и ошибается даже на действиях вида 1+1. При то, что вроде все его хвалили за способность оперировать с большими объёмами текста.
Как я борюсь с гниением.
Протокол верификации. (Я называю его «Стоп-кран».) Это лучшая защита, на мой взгляд, от Lost-in-the-Middle и галлюцинаций. Я заставляю модель остановиться и пересказать задачу, перенося её понимание из пассивного контекста (допустим, моего длинного сообщения) в активный (её собственный свежесгенерированный текст). Это «прибивает» внимание модели к цели гвоздями.
Дифференциация методологий. (Я называю это «Диспетчер».) Я не просто даю инструкции, я даю «ветвление логики»: а) если задача структурная — один алгоритм, б) если это «сон/идея» (исследование) — другой. Это предотвращает ситуацию, когда модель пытается применять жесткие рамки к творческому хаосу, и наоборот.
Управляемая память. (Я называю это «Протокол каноничности».) Я ввел понятие «Единственного источника истины». Это прямое решение проблемы «гниения контекста». В системном промпте есть инструкция «ПОЛНОСТЬЮ ИГНОРИРОВАТЬ все свои прошлые рассуждения». Она говорит модели: «Не смотри в середину истории, смотри только на последний Summary».
Десятичная нумерация версий. (Например, Документ 2.4). Это кажется мелочью, но это мощнейший attention anchor. Когда модель вынуждена присваивать номера версиям, она постоянно сверяется с иерархией данных. Это заставляет её «держать в уме» структуру проекта, не давая ей расплыться.
Синдром бесконечного окна: почему 1 миллион токенов в LLM не решает ваши проблемы (пока)