Более большое окно контекста не решит проблемы вашего агента: бюджет внимания и кэширование

Провайдер может рекламировать окно контекста объемом в миллион токенов, но модель все равно будет использовать гораздо меньше ресурсов при стабильной работе. Тестирование RULER от NVIDIA определяет длину, на которой модель сохраняет высокую производительность. Для двух из семнадцати протестированных моделей — Yi-34B и GPT-4 (1106 preview) — стабильная длина использования составила примерно 32 К токенов при заявленных 200 К, а также 64 К токенов при заявленных 128 К. Самые слабые модели теряют эффективность уже на крайне малой доле от заявленных показателей. После этой точки рекламируемый размер представляет собой лишь цифру в таблице цен, а не реальную производственную способность.

Вы видите одну и ту же основную проблему в нескольких местах. Агент забывает архитектурное решение, принятое на первом этапе. Система RAG находит нужный документ, но всё равно отвечает неверно. Автоматическое резюме сессии удаляет именно ту строку конфигурации, которая вам была нужна. Обычной реакцией является увеличение объёма памяти, но это не помогает агентам, поскольку проблема никогда не была в её объёме. Проблема заключается в том, как модель распределяет своё внимание между всеми данными, уже занимающими этот объём.

Kраткая версия

Окно контекста — это не единая память. Это ресурс с лимитом внимания, который исчерпывается задолго до достижения лимита токенов. Материал в начале или конце контекста используется эффективнее, чем материал в середине, до такой степени, что модель, получившая документ, спрятанный глубоко внутри запроса, может давать худшие результаты, чем та, которой ничего не дали. Конкретный пример: агент, получающий длинный журнал операций инструментов, набор извлеченных фрагментов и инструкции всё в одном запросе, будет склонен уделять внимание элементам, находящимся по краям, и стараться игнорировать остальное.

Три инструмента управляют этим лимитом, причем каждый теряет что-то своё:

• Сжатие запроса позволяет удалять токены с низкой информативностью. На эталонных данных это даёт хорошие результаты, но при независимых тестах возникают проблемы с структурированным контентом, таким как нумерация, точные строки и фрагменты кода.

Слайдинг-окна и сжатие контролируют длительность сессии. Первый метод удаляет старейшие данные, а второй заменяет их кратким резюме; при этом уровень потерь в каждом случае различается.

Кэширование подсказок может снизить затраты на ввод примерно на 90 процентов без потери информации, при условии, что префикс остается идентичным во всех вызовах.

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

Контекст — это ограничение ресурсов, а не место хранения

Сначала два термина. Токен — это единица текста, с которой работает модель; он состоит примерно из четырех символов или равен трём четвертям слова на английском языке. Окно контекста — это максимальное количество токенов, обрабатываемых за один вызов; это скорее максимальный размер матрицы внимания за один проход, чем объём оперативной памяти.

Андрей Карпати описал инженерию контекста как искусство заполнения «окна» именно тем, что необходимо для следующего шага, причем модель выступает в роли процессора, а «окно» — её рабочей памяти. Эта аналогия полезна, но охватывает лишь половину сути. Другая половина связана с бюджетом внимания. Руководство компании Anthropic по инженерии контекста для агентов рассматривает контекст как ограниченный ресурс с убывающей отдачей, при котором каждый добавленный токен потребляет часть ограниченного запаса внимания. Это арифметика, а не поэзия: количество пар внимания растёт квадратично, так что тысяча токенов означает примерно миллион связей, а сто тысяч — десять миллиардов.

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

Кривая в форме буквы U

Лю и его коллеги (Стэнфорд и Беркли, 2023) измеряли точность в задачах ответов на вопросы на основе нескольких документов и обнаружили кривую в форме буквы U. Ответы были наиболее надежными, когда соответствующий отрывок находился в начале или в конце, а наименее надежными — когда он располагался посередине. Название «Потеряно посередине» быстро закрепилось, опередив любые другие согласованные объяснения.

На самом деле беспокоит побочный эффект. Когда в запросе было двадцать или тридцать документов, правильный ответ, расположенный в середине контекста, получал более низкую оценку, чем базовый результат при работе без доступа к документам, когда модель вообще не видела никаких документов. Предоставление правильных доказательств в неподходящем месте может ухудшить ситуацию системы по сравнению с тем, когда ей вообще ничего не дают.

Почему это происходит: вопрос остается открытым

Спустя годы до сих пор нет единого мнения относительно причины. Существует несколько объяснений:

• эффект, связанный с данными обучения, поскольку авторы склонны размещать ключевые моменты в начале и конце текста,
• способ поведения позиционного кодирования и маскировки причинно-следственных связей,
• особенности геометрии декодера, существующие с момента инициализации ещё до начала обучения,
• адаптация, возникающая во время предобучения, когда модель сбалансировывает противоречивые требования к памяти.

Каждая причина требует своего решения: других данных для обучения, другой маски внимания, калибровки механизма внимания или просто изменения порядка запроса. Сведение всего этого в одно лаконичное объяснение может ввести в заблуждение.

Что решено, а что нет

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

Существуют также доказательства того, что эта закономерность не является универсальной. В исследовании Chroma’s Context Rot было протестировано восемнадцать передовых моделей, и оказалось, что случайно смешанный, логически некоherentный набор данных превосходил коherentный во всех случаях, причем эксперименты также не показали стабильного преимущества от использования коherentных данных. Разумный вывод заключается в том, что существует более одного механизма ухудшения качества, а подход Lost in the Middle — лишь один из них.

Одно предложение, которое повысило оценку с 27% до 98%

Компания Anthropic привела показательный пример использования Claude 2.1 в тесте на поиск иголки в стоге сена. Точность составляла 27 процентов, пока в начало ответа модели не была добавлена одна строка с указанием выбрать наиболее релевантное предложение из контекста. После этого показатель вырос до 98 процентов. Никаких новых возможностей модели не было добавлено; лишь инструкция изменила своё местоположение. Речь шла об одной оценке, одной версии модели и одном типе задачи, поэтому её следует рассматривать как пример, а не как общее правило для всех запросов.

Механизм: «ямы внимания»

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

Команда из MIT (Сяо и его коллеги) превратила эту особенность в инструмент. Они обнаружили, что простое окно скроллинга разрушается именно в тот момент, когда первый токен удаляется из кэша. Фиксация лишь первого небольшого числа токенов в качестве стабилизирующих элементов позволяет поддерживать стабильную генерацию даже при потоках в миллионы токенов, причем скорость работы увеличивается до 22,2 раза по сравнению с пересчетом каждого окна. В популярных обзорах часто игнорируется одно ограничение: такой подход не добавляет ни одного токена в реальную память. Выходной текст остается плавным, пока старые токены исчезают, но любые данные, вышедшие за пределы окна, теряются навсегда. Стабильность и использование памяти — это разные вещи.

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

Компрессия, окно и упаковка

Представьте чемодан, который не может вместить всё. Вы можете выбросить менее важные предметы, упаковать только самые новые или написать записку о том, что осталось дома. Каждый из этих вариантов приводит к потере чего-то своего.

Быстрая компрессия

Семейство моделей LLMLingua оценивает уровень неожиданности каждого токена с помощью небольшой вспомогательной модели и удаляет те, которые содержат мало информации. Результаты впечатляющие: до 20-кратной компрессии у LLMLingua, а у модели LongLLMLingua, учитывающей запрос, — улучшение на 21,4 процента в задаче NaturalQuestions при использовании в четыре раза меньшего количества токенов. Речь идет о двух вариантах, а не об одном единственном результате.

Независимые тесты усложняют картину. В одном из исследований, посвящённых референтному хранилищу, было отмечено, что полностью распакованный вводные данные значительно превосходят по качеству сжатые, что противоречит выводам статьи. В другом исследовании было обнаружено, что точность подсчёта фрагментов снижается из-за того, что сжатие уничтожает порядковые номера и точные строки текста. Вывод не в том, что сжатие неэффективно; его надёжность оспаривается и зависит от типа данных. Нарративный текст хорошо переносит сжатие, в то время как нумерованные разделы, идентификаторы, код и числа — нет.

Три способа управления сессией

• Скользящее окно. Простая система «первый вошёл — первым вышел»: сохраняются последние k сообщений или N токенов, а остальные удаляются. Этот метод не требует значительных вычислительных ресурсов, но приносит серьёзные потери в качестве результата — решение, принятое на первом шаге, исчезает к пятому шагу, и модель может предложить что-то противоречащее ему.

Компактизация. Замените старый диалог на краткое резюме. Риск заключается в том, что резюме может оказаться слишком кратким и потерять детали, важность которых проявляется позже. Пороги для разных инструментов сильно различаются, но распространённой рекомендацией является запуск процедуры компактизации при заполнении 70–75 процентов емкости, а не 95, поскольку модель без свободного пространства будет создавать худшее резюме.

Внешняя память. В стиле MemGPT данные хранятся вне окна обработки, и модель запрашивает их обратно посредством вызова функции при необходимости. Ничего не теряется навсегда, но каждый запрос увеличивает задержку и требует дополнительного вызова модели; к тому же модель должна знать заранее, стоит ли запрашивать тот или иной факт, что само по себе может привести к ошибкам. Используйте этот механизм для фактов, которые необходимо получать по запросу, таких как предпочтения пользователей или ранее принятые решения, а не для всего.

Ловушка: сжатие уничтожает скидку за кэширование

Благодаря оперативному кэшированию провайдер запоминает неизменную версию вашего запроса и берёт плату за последующие его обработки в небольшой доле от обычной ставки. KV-кэш хранит вычисленное состояние предыдущих токенов, чтобы модели не приходилось повторять эту работу.

Цена такой скидки — жёсткость: префикс должен быть идентичен по байтам при каждом вызове. Это исключает возможность использования переменного временной метки в начале запроса, случайного идентификатора сессии перед инструкциями или перестроенных ключей в JSON-словаре. Всё переменное должно находиться в «нестабильной» части запроса. Команды, использующие производственные агенты, считают коэффициент попаданий в кэш самой важной системной метрикой, причём разница в стоимости между случаями попадания и неудачи составляет примерно в десять раз.

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

В маркетинговых материалах циркулирует анекдот о том, что после внедрения сжатия ежемесячный счет снизился с примерно 42 000 долларов до 2 100 долларов, причем не указываются ни компания, ни дата, ни метод. Невозможно определить, учитывался ли при этом сжатый кэш — именно эта переменная определяет, повторится ли подобный результат.

План на понедельник

Этот список не заменяет тестирование на собственных данных. Он помогает избежать самой распространённой ошибки — обращения к сжатию или использованию более длительных временных интервалов, не проверив сначала более дешёвые и безопасные варианты.

1. Классифицируйте задачу. Простое извлечение фактов или многоэтапное рассуждение на основе длинного контекста? Это определяет, насколько серьезной является деградация качества ответа.
2. Проверьте местоположение ключевой инструкции. Если она находится глубоко внутри запроса, переместите ее в конец и снова протестируйте. Это изменение одного предложения — единственный доступный способ улучшения качества.
3. Проверьте стабильность префикса запроса. Если системный промпт отличается даже на один байт при разных вызовах, кэширование бесполезно, поэтому сначала необходимо устранить эту проблему. В обзорах на это обращают внимание гораздо реже, чем на выбор модели, хотя это может существенно повлиять на результат.

Сначала определите проблему, прежде чем выбирать инструмент. Проблемы с затратами означают необходимость проверки кэша перед компрессией. Снижение качества в течение длительной работы указывает на необходимость сжатия при уровне 70–75 процентов. Забывание конкретных фактов говорит о использовании механизма скользящего окна или внешней памяти, в зависимости от того, требуется ли восстановление фактов по запросу.

Если вы всё же используете компрессию, протестируйте её на собственных данных, особенно на данных с точными числами, идентификаторами и кодом, поскольку опубликованные результаты часто не позволяют воспроизвести такие данные.

Что взять с собой

Большее окно не решает проблему агента, поскольку оно увеличивает объём ресурса, проблемой которого никогда не была его емкость.

• Окно представляет собой бюджет внимания, а не объём хранилища; каждый дополнительный токен, добавленный на всякий случай, отбирается из того же пула, что и токены, предназначенные для важных данных.

Дискуссия о моделях типа «Lost in the Middle» ведётся неверно: извлечение фактов в основном обрабатывается с помощью передовых моделей, тогда как многократные выводы на основе длинного контекста по-прежнему сильно ухудшают качество результата.

Позиционирование — это самый дешёвый инструмент, который у вас есть, поэтому оцените его перед тем, как тратить средства на более дорогие решения.

Компрессия показывает известные слабости в независимых тестах, особенно для контента, который должен сохраняться без изменений.

Хранение в кэше и компрессия экономически нейтрализуют друг друга, поэтому сначала рассчитайте общую экономию.

Настоящее изменение в повседневной работе заключается в порядке задаваемых вопросов во время обзора дизайна. Сначала необходимо узнать, что содержится в контексте и где находится каждый элемент, а уже затем — каков его размер. Если поменять порядок, это приведет к тому, что важные факты окажутся в более широком пространстве, где они могут быть упущены. Краткое правило для запоминания: сначала проверяйте положение, затем стабильность, потом объем, и только в последнюю очередь обращайтесь к вопросам компрессии.