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

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

Ви бачите ту саму основну проблему в кількох місцях. Агент забуває архітектурне рішення, прийняте ще на першому кроці. Система RAG знаходить правильний документ, але все одно дає неправильну відповідь. Автоматичний підсумок сеансу пропускає саме ту рядок конфігурації, яка вам була потрібна. Звичайною реакцією є збільшення обсягу пам’яті, але це не допомагає агентам, адже проблемою ніколи не була їхня потужність. Проблема полягає у тому, як модель розподіляє свою увагу між усім, що вже поміщається в цей обсяг.

Коротка версія

Вікно контексту — це не однорідна пам’ять. Це ресурс із бюджетом уваги, який вичерпується задовго до досягнення ліміту токенів. Матеріал на початку чи в кінці контексту використовується ефективніше, ніж матеріал у середині, до такої міри, що модель, якій надали документ, розташований посеред запиту, може відповісти гірше, ніж та, якій нічого не дали. Конкретний приклад: агент, який отримує довгий журнал інструментів, низку отриманих фрагментів та інструкції всього в одному запиті, схильний приділяти увагу лише елементам на краях та неуважно ігнорувати решту.

Три інструменти керують цим бюджетом, причому кожен втрачає щось інше:

• Стиснення запиту видаляє токени з низькою інформаційною цінністю. Це добре працює на базових тестах, але при незалежному виконанні з’являються проблеми зі структурованим контентом, таким як нумерація, точні рядки та фрагменти коду.

Слайдингові вікна та компактація контролюють тривалість сеансу. Перший метод видаляє найстаріші дані, а другий замінює їх на резюме; їхні втрати відрізняються.

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

Ось у чому підступ: і стиснення, і компактація руйнують кеш, а економія через кеш часто перевищує економію від стиснення. Використання неправильного інструменту для неправильної проблеми призводить до прихованих збоїв у роботі, які складно діагностувати згодом.

Контекст — це бюджет, а не місце зберігання

Спочатку два терміни. Токен — це одиниця тексту, над якою працює модель; це приблизно чотири символи або три чверті слова в англійській мові. Вікно контексту — це максимальна кількість токенів, які обробляються за один виклик; це скоріше максимальний розмір матриці уваги за один прохід, ніж обсяг оперативної пам’яті.

Андрій Карпати описує інженерію контексту як мистецтво заповнення „вікна“ саме тим, що потрібно на наступному кроці, де модель виступає процесором, а „вікно“ — її робочою пам’яттю. Ця аналогія корисна, але охоплює лише половину суті. Інша половина — це бюджет уваги. Керівництво Anthropic щодо інженерії контексту для агентів розглядає контекст як обмежений ресурс із зменшуваними результатами, де кожен доданий токен використовує обмежений запас уваги. Це арифметика, а не поезія: кількість пар уваги зростає квадратично, тож тисяча токенів означає приблизно мільйон взаємозв’язків, а сто тисяч — десять мільярдів.

Отже, додавання контексту на випадок потреби ніколи не є безкоштовним. Ще кілька прикладів типу „кілька запитань – кілька відповідей“, повна історія розмови чи двадцять визначень інструментів замість п’яти — усе це походить з того самого джерела, що й факти, які мають значення. Перше запитання під час огляду архітектури не повинно стосуватися кількості доступних токенів; його метою має бути визначення того, яка частина бюджету насправді сприяє досягненню результату.

Крива у формі літери U

Лю та його колеги (Стенфорд та Берклі, 2023) вимірювали точність у багатодокументних завданнях на відповіді на запитання та виявили криву у формі літери U. Відповіді були найнадійнішими, коли відповідний уривок стояв на початку чи в кінці, а найменш надійними — коли він знаходився посередині. Назва „Втрачене посередині“ швидко закріпилась, значно перевершивши будь-які інші узгоджені пояснення.

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

Чому це відбувається: питання залишається відкритим

Через багато років не існує єдиної думки щодо причини. Існує кілька пояснень:

• це наслідок даних для навчання, адже автори схильні розміщувати ключові моменти у початку та кінці тексту,
• спосіб функціонування позиційного кодування та маскування причинно-наслідкових зв’язків,
• загальна геометрія декодера, яка існує з моменту ініціалізації ще до початку навчання,
• адаптація, яка виникає під час попереднього навчання, коли модель знаходить баланс між суперечливими вимогами до пам’яті.

Кожна причина вимагає іншого рішення: інших даних для навчання, іншої маски уваги, калібрування механізму уваги чи просто переупорядкування запиту. Об’єднання всього цього в одне зрозуміле пояснення може ввести в оману.

Що вирішено, а що — ні

Запитання про те, чи вже вирішена проблема, неправильно її формулює. Просте отримання фактів у більшості випадків вже вирішено: сучасні передові моделі можуть знайти буквально описаний елемент у дуже великій кількості інформації, де б він не знаходився. Багатоетапне міркування ще не вирішено. Синтез кількох документів чи редагування коду в великому репозиторії — це інша задача, ніж пошук окремого факту, і опубліковані оцінки роботи моделей з довгим контекстом показують, що рівень успішності різко знижується зі збільшенням довжини вхідних даних для однакової моделі та типу завдання.

Існують також докази проти універсальності цього закономірного патерну. У дослідженні Chroma’s Context Rot було протестовано вісімнадцять передових моделей, і з’ясувалося, що навіть безладний, логічно несуворозмірений набір даних перевершує суворозмірений у всіх випадках, крім того, експерименти не показали стабільної переваги від суворозміреного формату. Логічний висновок полягає у тому, що існує більше одного механізму погіршення якості, а метод 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 відсотків. Забуття конкретних фактів вказує на використання механізму змінного вікна або зовнішньої пам’яті, залежно від того, чи потрібно отримувати ці факти за запитом.

Якщо ви все ще використовуєте стиснення, протестуйте його на власних даних, особливо на даних із точними числами, ідентифікаторами та кодом, адже опубліковані результати часто не дозволяють повторити такий ефект.

Що варто запам’ятати

Більше обсягу пам’яті не вирішує проблеми агента, оскільки це лише збільшує ємність ресурсу, проблемою якого ніколи не була ємність.

• Обсяг пам’яті — це бюджет уваги, а не місце зберігання, і кожен доданий токен витягує ресурси з того ж пулу, що й важливі дані.

Дискусія про „The Lost in the Middle“ є хибно сформульованою: отримання фактів у більшості випадків здійснюється за допомогою передових моделей, тоді як багатоетапне міркування з довгим контекстом все ще значно погіршується.

Позиціонування — це найдешевший інструмент, який у вас є, тому перевірте його перед тим, як витрачати гроші на щось дорожче.

У стандартних тестах було виявлено слабкості компресії, особливо щодо контенту, який має зберігатися без змін.

З точки зору економії коштів кешування та компресія взаємно скасовують одна одну, тому спочатку розрахуйте загальну економію.

Справжня зміна у повсякденній роботі полягає у порядку запитань під час перегляду дизайну. Спочатку потрібно з’ясувати, що містить контекст та де розташований кожен елемент, а вже потім — яким є його розмір. Якщо змінити порядок, ви отримаєте більший простір, який лише дає важливим фактам більше можливостей для „зникнення“ серед іншої інформації. Коротке правило для запам’ятовування: спочатку перевіряйте положення, потім — стабільність, далі — об’єм, а компресію застосовуйте востаннє.