Контекст на 5-8 тысяч токенов может оставаться несвязным, даже если он формально помещается в окно модели. Сжатие уменьшает объем истории, но автоматически не проверяет точность пересказа, актуальность решений и согласованность разных фрагментов.
Причина обычно связана с загрязнением смыслового контекста. В компактный prompt попадают устаревшие указания, ошибочные формулировки, смешанные версии одного решения или потерянная хронология. Модель получает короткий текст, но опирается на состояние, которое уже не совпадает с ходом задачи.
Типовая схема с L1- и L2-саммари помогает контролировать размер истории, если хранит происхождение фактов, статус решений и свежие необработанные сообщения. Без этих правил рекурсивное резюме превращается в цепочку пересказов, где небольшая ошибка постепенно выглядит как подтвержденный факт. Ниже описана общая архитектурная модель, а не результат тестирования конкретной LLM.
Почему сжатие контекста не гарантирует связность диалога
Compaction решает задачу вместимости: старые сообщения заменяются более коротким описанием. Связность требует другого набора проверок. Нужно сохранить цель, ограничения, причины решений, порядок изменений и различие между фактом, гипотезой и обсуждавшимся вариантом.
Переполнение токенами и загрязнение смысла - разные сбои
При переполнении токенами запрос физически не помещается в доступное окно. Конкретная система может отклонить запрос, удалить часть истории или оставить слишком мало места для ответа. Это проблема размера.
При загрязнении смыслового контекста места достаточно, но внутри находится неверное или конкурирующее состояние. Модель видит нужный объем текста, однако не получает надежного ответа на вопрос, какая версия факта актуальна.
| Сбой | Что происходит | Типичный признак |
|---|---|---|
| Физическое переполнение | Сумма системных инструкций, истории, служебных данных и будущего ответа превышает доступный лимит. | Запрос не отправляется, часть сообщений исчезает или ответ обрывается из-за нехватки места. |
| Загрязнение смысла | Запрос помещается, но содержит противоречивые, устаревшие или искаженные сведения. | Модель уверенно возвращается к отмененному решению, путает статус задачи или повторяет уже исправленную ошибку. |
Дальнейшее сокращение prompt помогает только в первом случае. Во втором оно способно ухудшить результат, если вместе с шумом удалить причину решения или признак того, что факт уже устарел.
Почему маленький prompt может оставаться плохим
Summary представляет исходную переписку в новой форме. Модель пересказывает сообщения, выбирает детали и связывает их в общий текст. При этом она может потерять отрицание, число, имя переменной, условие применимости или временной статус события.
Условный пример: в старом L1 записано, что команда выбрала PostgreSQL, а в свежем сообщении решение отменено до завершения проверки миграции. Если в L2 попала только фраза о выборе PostgreSQL, компактный prompt будет выглядеть аккуратно, но подтолкнет модель к устаревшему действию.
Сжатый контекст становится надежнее, когда summary хранит не пересказ всех реплик, а рабочее состояние задачи. Для каждого важного пункта нужны источник, статус, время последнего подтверждения и связь с заменившим его решением. Практический разбор выбора между полной историей, ручной сводкой и автоматической компактацией приведен в статье о сжатии контекста в длинных AI-цепочках.
Сжатие контекста в LLM: как работают уровни L1 и L2
Уровни L1 и L2 удобно воспринимать как разные степени агрегации состояния. Исходные сообщения сохраняют детали. L1 описывает отдельный фрагмент работы. L2 объединяет несколько устойчивых L1 в более короткую картину. Свежий хвост временно остается в исходном виде.
исходные сообщения -> L1 -> L2
Это модель проектирования памяти, а не обязательный стандарт. Конкретный агент может использовать один уровень, несколько сводок или внешнее хранилище фактов.
Что должно храниться в L1-саммари
L1 нужен для локального состояния фрагмента диалога. Он должен отвечать на вопрос, что изменилось в этом участке работы и что понадобится в ближайших шагах.
- Цель: какую задачу решал пользователь или агент.
- Принятые решения: что выбрано и почему.
- Факты: подтвержденные значения, файлы, ограничения и результаты действий.
- Незавершенные действия: что уже начато и какой результат ожидается.
- Неопределенности: какие сведения требуют проверки.
- Источники: сообщение пользователя, результат инструмента или состояние приложения.
В L1 не стоит собирать весь текст обсуждения. Реплику можно отбросить, если она не влияет на будущий ответ и не объясняет принятое решение. Удаление становится рискованным, когда вместе с формулировкой исчезает условие, отрицание или причина выбора.
Как L1 превращается в L2
L2 объединяет устойчивые сведения из нескольких L1. Его задача состоит в экономии места и сохранении общей картины, а не в механическом пересказе каждого промежуточного шага.
Перед объединением нужно решить, какие данные стабильны, какие изменились, а какие отменены. Если один L1 содержит решение использовать Redis, а более свежий L1 фиксирует отказ от него из-за ограничений памяти, L2 должен хранить актуальную версию и связь с причиной изменения.
Для конфликтов требуется явное правило. Например, подтвержденное более новое решение получает приоритет над старым предложением, а спорный факт не превращается в утверждение без дополнительной проверки. Простое расположение нового текста ниже старого не заменяет такую политику.
Почему рекурсивное резюме не является архивом
Архив хранит исходную запись. Рекурсивное резюме хранит производное описание, созданное на основе предыдущего описания. На втором цикле модель уже может не видеть первоначальную реплику и работает с тем, что попало в L1.
Если в первом саммари пропало слово не, число 12 стало 120, а предложение превратилось в подтвержденный факт, следующий уровень способен закрепить ошибку. Повторный пересказ повышает плотность текста, но не восстанавливает потерянную информацию.
Поэтому важные сведения должны иметь ссылку на первоисточник или хотя бы указание на его тип. Summary подходит для рабочего состояния. Оно не должно оставаться единственным местом, где хранится критический факт.
Зачем сохранять последние необработанные сообщения
Свежий хвост удерживает точные формулировки текущего запроса, последние изменения и локальную хронологию. Он защищает от потерь, которые появляются при очередном пересказе.
В хвосте обычно остаются последние сообщения пользователя, ответ агента, результат последнего инструмента и еще не зафиксированное изменение состояния. После завершения локального действия эти сообщения можно свернуть в новый L1.
Хвосту нужен ограниченный объем. Если оставлять в нем всю историю, compaction теряет смысл. Если сворачивать его сразу, модель лишается точного контекста текущей операции. Граница должна зависеть от задачи: для отладки важнее последние логи и команды, для планирования важнее решения и зависимости.
Пять причин, почему многоуровневый контекст начинает расходиться
Многоуровневая память снижает размер prompt, но добавляет несколько мест, где состояние может измениться. Ниже перечислены независимые источники деградации. В конкретной модели они проявляются по-разному и не обязаны возникать одновременно.
Накопление ошибок при пересказе
Первый риск появляется, когда новый summary строится поверх старого, а не сверяется с исходными сообщениями. Потеря одного условия на раннем уровне меняет смысл последующих выводов.
Чаще всего страдают отрицания, числа, имена файлов, названия переменных и границы применимости. Фраза пользователь не разрешил удалять миграцию может превратиться в миграцию можно удалить после обсуждения. На следующем уровне обсуждение исчезает, остается только действие.
Снизить риск помогает формат с отдельными полями и запретом добавлять новые факты без источника. Для чисел, идентификаторов и команд полезно сохранять точное значение, а не пересказ в свободной форме.
Конфликт L1, L2 и свежего хвоста
Модель может одновременно увидеть три версии состояния: обобщенный L2, более подробный L1 и последние сообщения. Все они выглядят частью одного prompt, но относятся к разным моментам времени.
Условный конфликт выглядит так: L2 сообщает, что задача завершена, L1 фиксирует ошибку при проверке, а свежий хвост содержит просьбу пользователя повторить операцию с другим параметром. Без приоритетов модель может ответить по старому статусу или повторить уже отмененное действие.
В prompt нужно явно разделять уровни и описывать порядок доверия. Текущий подтвержденный статус должен иметь приоритет над старой сводкой. Свежая реплика получает право изменить состояние, когда она содержит явное новое решение, а не случайное упоминание варианта.
Потеря хронологии
Тематический список фактов не показывает, что было предложено, что подтверждено, что отменено и что ожидает проверки. Для многошаговой задачи это критично: причинная связь часто важнее самого факта.
Например, запись использовали библиотеку X не объясняет, что ее выбрали временно, затем заменили библиотекой Y, а после теста вернули X из-за ошибки совместимости. Без порядка событий модель может предложить старый вариант как новое решение.
В сводке стоит сохранять время или хотя бы последовательный номер изменения, статус и связь с предыдущей версией. Полезны статусы предложено, подтверждено, отменено, заменено и требует проверки.
Избыточный шум в компактном контексте
Размер prompt сам по себе не показывает, сколько конкурирующих сигналов находится внутри. Восемь тысяч токенов могут содержать меньше полезного состояния, чем две тысячи, если значительная часть текста состоит из повторов и отвергнутых веток.
Источниками шума становятся служебные сообщения, длинные логи, повторенные инструкции, промежуточные рассуждения, неактуальные варианты плана и несколько формулировок одного факта. При этом удаление по длине способно убрать единственное объяснение, почему решение приняли.
Фильтровать нужно по влиянию на текущую задачу. Отвергнутый вариант можно удалить из активного состояния, но для важных решений полезно оставить короткую запись о причине отказа. Она предотвращает повторное движение по уже проверенному тупику.
Неудачная структура prompt
Плоский блок текста смешивает правила ответа, факты, историю, служебные инструкции и сомнительные сведения. Модель должна сама определить, что считать командой, что считать данными, а что считать архивом.
Отдельный риск появляется, когда старая реплика пользователя выглядит как действующая инструкция. Например, в истории есть просьба отвечать в формате таблицы, но текущая задача требует короткого списка. Если статус старой реплики не обозначен, она продолжает конкурировать с текущими правилами.
Практичнее разделять prompt на блоки: текущая задача, правила ответа, подтвержденные факты, актуальные решения, открытые вопросы, свежие сообщения и сведения, требующие проверки. Заголовки не исправляют ошибки сами по себе, но делают приоритеты явными и упрощают диагностику.
Лимит контекста нейросети: почему заявленное окно не равно рабочей истории
Размер окна контекста описывает максимальный объем токенов, который система может обработать в одном запросе при конкретных условиях. Эта цифра не обещает одинаково надежное использование каждой части длинной истории.
Что на самом деле означает размер окна контекста
В общий объем входят системный prompt, правила разработчика, история сообщений, L1 и L2, результаты инструментов, схемы доступных функций и место под будущий ответ. В некоторых системах учитываются дополнительные служебные данные или особенности токенизации.
Поэтому окно на 5-8 тысяч токенов не означает, что вся эта величина доступна под полезную переписку. Если системные инструкции занимают 1 тысячу токенов, а под ответ нужно оставить еще 1 тысячу, для истории остается другой объем. Точный расчет зависит от модели и API.
Физическая вместимость тоже не гарантирует качество. Запрос может успешно пройти проверку лимита, а модель все равно ошибиться из-за конфликтующих сведений, плохого порядка блоков или неверного summary.
Почему расположение и форма сведений имеют значение
Одинаковый факт можно представить одной строкой в блоке актуального состояния или спрятать среди нескольких страниц обсуждения. В первом случае модели проще сопоставить его с текущей задачей. Во втором факт конкурирует с повторами, исключениями и старыми версиями.
Для важных сведений полезно хранить короткую актуальную запись в начале или в отдельном явно названном блоке. Рядом нужно указать статус, время последнего подтверждения и приоритет относительно архива. Это не гарантирует правильный ответ, но сокращает число неоднозначностей.
Организация контекста особенно важна для инструкций. Разбор случаев, когда большие LLM хуже следуют указаниям при изменении контекста, настроек и условий запроса, приведен в статье о потере нити диалога и следовании инструкциям.
Почему нельзя переносить выводы между моделями
Один и тот же prompt может вести себя по-разному у разных моделей и провайдеров. На результат влияют шаблон чата, настройки генерации, токенизация, способ передачи инструментов, объем зарезервированного ответа и правила работы с памятью.
Даже внутри одной модели результат может измениться после перестановки блоков, замены свободного текста на таблицу или удаления свежего хвоста. Поэтому порог, который оказался приемлемым в одном агенте, нельзя объявлять универсальным для всех LLM.
Корректный вывод должен содержать условия: модель, режим вызова, состав prompt, тип задачи и способ измерения ошибки. Без этих данных можно описывать архитектурный риск, но нельзя обещать стабильное качество на конкретной длине истории.
Как отличить переполнение контекста от испорченной сводки
Диагностика начинается с наблюдаемых данных. Нужно понять, сколько токенов занимает каждый блок, где впервые появляется ошибка и какая версия факта попадает в итоговый запрос.
Сначала проверьте состав и размер запроса
Логируйте компоненты отдельно: системные инструкции, правила разработчика, L2, набор L1, свежие сообщения, результаты инструментов и резерв под ответ. Фиксируйте состояние до compaction и после него.
- Запишите число токенов для каждого блока.
- Сохраните порядок блоков в итоговом prompt.
- Отдельно отметьте удаленные сообщения и замененные сводки.
- Зафиксируйте причину сжатия: лимит, ручная команда или политика агента.
- Сохраните параметры вызова модели, если они влияют на формат ответа.
Если запрос превышает окно или оставляет слишком маленький резерв под ответ, сначала исправляется состав и бюджет. Если размер допустим, переходите к проверке происхождения спорного факта.
Сравните исходные сообщения и summary
Для каждого важного утверждения пройдите цепочку: исходная реплика, L1, L2, итоговый prompt, ответ модели. Ищите первое место, где изменился смысл, пропало отрицание, исчезло число или поменялся статус.
Условный пример цепочки: пользователь сообщил, что удаление запрещено; L1 сохранил запрет; L2 записал удаление после согласования; итоговый prompt представил действие разрешенным. Ошибка появилась при сборке L2, поэтому дальнейшее уменьшение текста ее не исправит.
Полезно проверять не весь диалог, а набор критичных утверждений: текущая цель, последний подтвержденный выбор, ограничения, незавершенные действия и условия запуска опасной операции.
Проведите контрольную пересборку
Соберите отдельный prompt из подтвержденных фактов, актуальных решений и последних сообщений. Исключите старые производные L1 и L2, если у них нет подтвержденного источника.
- Выберите несколько фактов, на которых зависит текущий шаг.
- Отделите отмененные и спорные сведения.
- Восстановите порядок последних изменений.
- Добавьте короткий свежий хвост.
- Сравните ответ с результатом старой схемы.
Такое сравнение показывает, связана ли ошибка с накопленной цепочкой summary. Оно не доказывает, что новая схема лучше во всех задачах. При оценке нужно учитывать различия в количестве токенов, задержке и составе исходных данных.
Разделите фактические ошибки и ошибки следования инструкции
Сначала выясните, знает ли модель нужный факт. Если факт отсутствует или искажен в summary, проблема относится к compaction. Если факт записан правильно, но модель его игнорирует, ищите конфликт приоритетов, неудачную структуру prompt или конкурирующую инструкцию.
| Наблюдение | Вероятное направление проверки |
|---|---|
| Факт исчез уже в L1 | Формат локального саммари, поля обязательных данных и выбор исходных сообщений. |
| Факт есть в L1, но исчез в L2 | Правила объединения уровней и разрешение конфликтов. |
| Факт есть в итоговом prompt, но ответ его нарушает | Приоритет блоков, формулировка инструкции и настройки вызова. |
| Запрос не проходит по размеру | Распределение бюджета токенов, размер служебных блоков и резерв ответа. |
Для оценки новых моделей и длинных сценариев пригодится отдельный чек-лист сравнения контекста, качества и условий работы. Он помогает отделить изменение самой модели от изменения prompt и режима запуска.
Как сделать сжатие контекста в LLM устойчивее
Устойчивый compaction хранит состояние задачи, а не пытается пересказать каждую реплику. Для этого нужны отдельные типы данных, понятный контракт обновления и ограниченный свежий хвост.
Отделите факты, решения и журнал диалога
Минимальная структура может включать несколько блоков:
- Цель: текущий результат, которого нужно достичь.
- Подтвержденные факты: значения, ограничения и результаты действий с указанием происхождения.
- Принятые решения: активный вариант и причина его выбора.
- Открытые вопросы: сведения, без которых следующий шаг остается неопределенным.
- Журнал изменений: короткая хронология важных обновлений.
- Сомнительные сведения: гипотезы и данные, требующие проверки.
Обсуждавшийся вариант не должен автоматически попадать в список фактов. Если пользователь предложил решение, но не подтвердил его, сохраняйте статус предложения. Результат инструмента и сообщение пользователя тоже стоит различать, поскольку они имеют разное происхождение и разную степень доверия.
Задайте явный контракт для L1 и L2
Каждый уровень должен иметь фиксированные поля. Для L1 достаточно описывать локальную цель, изменения, решения, незавершенные действия и источники. Для L2 полезнее хранить стабильные зависимости, актуальный статус, общие ограничения и связь между версиями решений.
В контракте стоит запретить свободное добавление новых фактов. Если сводка не находит подтверждения в исходных данных, она должна пометить сведения как неопределенные или пропустить их.
Перед сохранением саммари полезна механическая проверка:
- есть ли текущая цель;
- указан ли статус каждой незавершенной задачи;
- отделены ли факты от предположений;
- сохранены ли числа, имена и отрицания;
- есть ли источник у критичных утверждений;
- отмечены ли отмененные решения.
Добавьте актуальность и временные метки
Для каждого решения храните момент создания, момент последнего подтверждения и текущий статус. Поле времени может быть календарной датой, номером шага или последовательным идентификатором события. Главное, чтобы порядок изменений восстанавливался однозначно.
Отмененное решение не нужно оставлять рядом с активным без пометки. Свяжите его с новой версией: старый вариант отменен, новый выбран после проверки. Такая запись сохраняет причинную связь и снижает риск возврата к устаревшему состоянию.
Актуальность полезна и для внешних данных. Результат инструмента, полученный до изменения файла или настроек, нельзя считать свежим только потому, что он записан в L2. Для него нужен срок действия или условие повторной проверки.
Определите приоритет источников
Порядок доверия следует записать прямо в правилах prompt. Один из рабочих вариантов:
- текущие системные правила и ограничения безопасности;
- актуальное состояние приложения и подтвержденные результаты инструментов;
- явные новые решения пользователя;
- структурированное состояние задачи;
- свежий диалоговый хвост;
- архивные L1 и L2;
- неподтвержденные гипотезы.
Порядок может отличаться для конкретного агента. Главное, чтобы правило существовало и объясняло конфликт. Свежая реплика не должна автоматически отменять подтвержденный факт, однако явное новое решение пользователя должно обновлять состояние, а не оставаться еще одной строкой в истории.
Сохраняйте короткий хвост исходных сообщений
Хвост нужен для точности текущего обмена. В нем стоит оставлять сообщения, которые еще не превратились в устойчивое состояние: новый запрос, последний результат инструмента, исправление пользователя и ответ на него.
Свернуть сообщение можно после фиксации его результата в L1. До этого удаление исходной формулировки опасно, особенно если она содержит исключение, отрицание или точное значение параметра.
Универсальный размер хвоста задавать нельзя. Для короткого вопроса хватит нескольких последних реплик. Для отладки кода понадобятся связанные команды, ошибки и изменения между ними. Бюджет выбирается по влиянию на задачу, а не по красивому фиксированному числу токенов.
Периодическая пересборка состояния: когда L1/L2 лучше заменить
Рекурсивная схема не обязана продолжаться бесконечно. Если уровни потеряли происхождение фактов или начали противоречить друг другу, продолжение compaction закрепляет проблему.
Признаки, что цепочка саммари исчерпала себя
- Модель несколько раз возвращается к уже исправленному факту.
- L1 и L2 содержат разные версии текущего решения.
- В сводке нет причины, по которой был выбран активный вариант.
- Статус задачи нельзя определить без чтения старой переписки.
- В prompt растет доля служебного текста и повторов.
- Критичные факты не имеют ссылки на первоисточник.
- Каждый новый цикл требует ручных исправлений.
Один такой признак не доказывает поломку. Несколько признаков подряд означают, что текущая цепочка перестала быть надежным представлением состояния.
Как пересобрать состояние с нуля
Пересборка начинается с первичных данных, а не с последнего L2.
- Соберите подтвержденные сообщения пользователя, результаты инструментов и актуальное состояние приложения.
- Отделите активные факты от отмененных, спорных и устаревших.
- Восстановите порядок ключевых изменений и причины решений.
- Сформируйте новую сводку по фиксированному контракту L1 или L2.
- Добавьте только релевантный свежий хвост.
- Проверьте критичные утверждения перед следующим вызовом модели.
Пересборка требует дополнительных токенов, времени и аккуратного выбора источников. Она оправдана, когда ошибка в состоянии обходится дороже разовой задержки или повторной обработки истории. Для дешевой однократной операции полная пересборка может быть избыточной.
Что считать источником истины после пересборки
Источник истины нужно определить заранее. Им может быть подтвержденное сообщение пользователя, состояние приложения, результат инструмента, внешний документ, который уже передан системе, или комбинация этих данных.
Summary должно представлять это состояние, а не заменять его. Если сводка расходится с подтвержденным результатом инструмента, приоритет получает результат, а сводка обновляется. Если пользователь явно изменил требование, активное состояние тоже нужно переписать, а старую версию пометить как отмененную.
Такой подход отделяет хранилище данных от удобного текста для модели. При следующем цикле можно заново получить компактный prompt, не продолжая цепочку ошибок.
Вывод: compaction должен сохранять состояние, а не просто сокращать текст
Сжатие контекста решает проблему размера, но не гарантирует сохранность смысла. Контекст на 5-8 тысяч токенов способен потерять связность, если в нем смешаны старые решения, ошибки пересказа, неразмеченные гипотезы и свежие сообщения с другим статусом.
Для устойчивой схемы нужны пять базовых правил: разделять физическое переполнение и семантическое загрязнение, хранить факты отдельно от журнала диалога, задавать контракт для L1 и L2, отмечать актуальность и происхождение, сохранять ограниченный хвост исходных сообщений.
При сбое сначала измерьте состав prompt и найдите первое место искажения. Затем сравните старую цепочку summary с контрольной пересборкой. Если уровни расходятся, соберите состояние из первичных фактов и снова зафиксируйте приоритеты. Хороший compaction оставляет модели короткую, актуальную и проверяемую картину задачи.