LLM Context Pruning: Руководство разработчика для улучшения результатов RAG и агентного ИИ

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

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

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

В этой статье мы поговорим о том, почему длинный контекст часто ведет себя не так, как вы ожидаете, как обрезка помогает держать ситуацию под контролем и как инструменты обрезки, такие как Provence, вписываются в реальные RAG-конвейеры, не усложняя вашу настройку.

Четыре распространенных способа отказа в системах с длинным контекстом

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

1. Столкновение контекстов

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

Например, пользователь может сказать: "Я люблю яблоки" в начале разговора, а позже заявить: "Я не люблю фрукты". Когда оба утверждения остаются в контексте, у модели нет надежного способа разрешить конфликт, что приводит к непоследовательным или нерешительным ответам.

2. Контекстная путаница

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

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

3. Отвлечение контекста

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

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

4. Отравление контекста

Отравление контекста происходит, когда неверная информация попадает в контекст и неоднократно упоминается и подкрепляется в течение нескольких поворотов.

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

Что такое обрезка контекста и почему она важна

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

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

Другие стратегии могут реорганизовать контекст, сжать его или отложить некоторые части на потом. Обрезка более прямолинейна: она отвечает на вопрос: "Должна ли эта часть информации вообще попасть в подсказку?".

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

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

На практике обрезка является одной из самых эффективных оптимизаций в длинноконтекстном или RAG-конвейере - простая идея, большое влияние.

Provence: Практическая модель обрезки контекста

Изучая подходы к обрезке контекста, я наткнулся на две привлекательные модели с открытым исходным кодом, разработанные в Naver Labs Europe: Provence и ее многоязычный вариант, XProvence.

Provence - это метод обучения облегченной модели обрезки контекста для генерации с расширенным поиском, с особым акцентом на ответы на вопросы. Учитывая вопрос пользователя и найденный отрывок, она определяет и удаляет нерелевантные предложения, оставляя только ту информацию, которая вносит вклад в окончательный ответ.

Обрезая малозначимый контент перед генерацией, Provence уменьшает шум на входе модели, сокращает количество подсказок и уменьшает время ожидания вывода LLM. Кроме того, Provence является plug-and-play и работает с любой системой LLM или поисковой системой, не требуя тесной интеграции или архитектурных изменений.

Provence предлагает несколько практических возможностей для реальных конвейеров RAG.

1. Понимание на уровне документов

Provence рассматривает документы в целом, а не оценивает предложения по отдельности. Это важно, поскольку реальные документы часто содержат такие ссылки, как "это", "это" или "метод, описанный выше". В отдельности эти предложения могут быть неоднозначными или даже бессмысленными. Если рассматривать их в контексте, их значение становится очевидным. Благодаря целостному моделированию документа Provence принимает более точные и последовательные решения по обрезке.

2. Адаптивный отбор предложений

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

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

3. Высокая эффективность благодаря интегрированному рерайтингу

Provence создан для того, чтобы быть эффективным. Это компактная, легкая модель, что делает ее значительно быстрее и дешевле в исполнении, чем подходы к обрезке на основе LLM.

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

4. Многоязычная поддержка с помощью XProvence

У Provence также есть вариант под названием XProvence, который использует ту же архитектуру, но обучается на многоязычных данных. Это позволяет ему оценивать запросы и документы на разных языках, таких как китайский, английский и корейский, что делает его подходящим для многоязычных и межъязыковых систем RAG.

Как происходит обучение Provence

Provence использует чистый и эффективный дизайн обучения, основанный на архитектуре кросс-кодирования. Во время обучения запрос и каждый найденный отрывок объединяются в один вход и кодируются вместе. Это позволяет модели видеть полный контекст вопроса и отрывка одновременно и напрямую рассуждать об их релевантности.

Такое совместное кодирование позволяет Provence обучаться на основе тонких сигналов релевантности. Модель отлажена на DeBERTa как легком кодере и оптимизирована для выполнения двух задач одновременно:

1. Оценка релевантности на уровне документа (rerank score): Модель предсказывает оценку релевантности для всего документа, показывая, насколько хорошо он соответствует запросу. Например, оценка 0,8 означает высокую релевантность.

2. Маркировка релевантности на уровне токенов (бинарная маска): Параллельно модель присваивает двоичную метку каждой лексеме, отмечая, релевантна (1) или нерелевантна (0) она запросу.

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

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

Очень важно, что Provence использует шаг реранжирования, который уже есть в большинстве конвейеров RAG. Это означает, что контекстная обрезка может быть добавлена практически без дополнительных накладных расходов, что делает Provence особенно практичным для реальных RAG-систем.

Оценка эффективности контекстной обрезки в разных моделях

До сих пор мы сосредоточились на разработке и обучении Provence. Следующий шаг - оценить, как он работает на практике: насколько хорошо он обрезает контекст, как он сравнивается с другими подходами и как он ведет себя в реальных условиях.

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

Эксперименты направлены на достижение двух основных целей:

• Эффективность обрезки: Мы измеряем, насколько точно каждая модель сохраняет релевантный контент, удаляя нерелевантную информацию, используя стандартные метрики, такие как Precision, Recall и F1 score.

• Обобщение вне домена: Мы оцениваем, насколько хорошо каждая модель работает с распределениями данных, которые отличаются от обучающих данных, оценивая устойчивость в сценариях вне области.

Сравниваемые модели

• Прованс

• XProvence

• OpenSearch Semantic Highlighter (модель обрезки, основанная на архитектуре BERT, разработанная специально для задач семантического выделения)

Набор данных

В качестве оценочного набора данных мы используем WikiText-2. WikiText-2 получен из статей Википедии и содержит разнообразные структуры документов, в которых релевантная информация часто распределена по нескольким предложениям, а семантические связи могут быть нетривиальными.

Важно отметить, что WikiText-2 существенно отличается от данных, обычно используемых для обучения моделей обрезки контекста, но при этом напоминает реальный мир, содержащий большой объем знаний. Это делает его хорошо подходящим для оценки вне домена, что является основным направлением наших экспериментов.

Генерация запросов и аннотация

Чтобы построить задачу обрезки вне домена, мы автоматически генерируем пары "вопрос-ответ" из исходного корпуса WikiText-2 с помощью GPT-4o-mini. Каждая оценочная выборка состоит из трех компонентов:

• Запрос: Вопрос на естественном языке, сгенерированный из документа.

• Контекст: Полный, немодифицированный документ.

• Истина: аннотации на уровне предложений, указывающие, какие предложения содержат ответ (должны быть сохранены), а какие не имеют отношения к делу (должны быть обрезаны).

Такая схема естественным образом определяет задачу обрезки контекста: при наличии запроса и полного документа модель должна определить предложения, которые действительно имеют значение. Предложения, содержащие ответ, помечаются как релевантные и должны быть сохранены, в то время как все остальные предложения считаются нерелевантными и должны быть обрезаны. Такая формулировка позволяет количественно оценить качество обрезки с помощью показателей Precision, Recall и F1.

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

Конвейер оценки

Оптимизация гиперпараметров: Для каждой модели мы выполняем сеточный поиск в заданном пространстве гиперпараметров и выбираем конфигурацию, которая максимизирует результат F1.

Результаты и анализ

Результаты показывают явные различия в производительности трех моделей.

Provence достигла самой высокой общей производительности, получив оценку F1 66,76 %. Показатели Precision(69,53 %) и Recall(64,19 %) хорошо сбалансированы, что свидетельствует о надежном обобщении за пределами домена. В оптимальной конфигурации используется порог обрезки 0,6 и α = 0,051, что говорит о том, что оценки релевантности модели хорошо откалиброваны, а поведение обрезки интуитивно понятно и легко настраивается на практике.

XProvence достигает F1 58,97 %, характеризуясь высоким показателем recall (75,52 %) и низким показателем precision (48,37 %). Это отражает более консервативную стратегию обрезки, в которой приоритет отдается сохранению потенциально релевантной информации, а не агрессивному удалению шума. Такое поведение может быть желательным в областях, где ложноотрицательные результаты дорого обходятся - например, в здравоохранении или юридических приложениях, - но оно также увеличивает количество ложноположительных результатов, что снижает точность. Несмотря на этот компромисс, многоязыковые возможности XProvence делают его сильным вариантом для неанглийских или межъязыковых приложений.

В отличие от него, OpenSearch Semantic Highlighter работает значительно хуже, его результат F1 составляет 46,37 % (Precision 62,35 %, Recall 36,98 %). Отставание от Provence и XProvence указывает на недостатки как в калибровке оценок, так и в обобщении, особенно в условиях внедоменного использования.

Семантическое выделение: Еще один способ найти в тексте то, что действительно важно

Теперь, когда мы поговорили об обрезке контекста, стоит взглянуть на смежную часть головоломки: семантическое выделение. Технически обе функции выполняют практически одну и ту же основную работу - они оценивают фрагменты текста на основе того, насколько они релевантны запросу. Разница заключается в том, как результат используется в конвейере.

Большинство людей, услышав слово "выделение", думают о классических выделителях ключевых слов, которые можно увидеть в Elasticsearch или Solr. Эти инструменты в основном ищут дословные совпадения ключевых слов и оборачивают их в нечто вроде <em>. Они дешевы и предсказуемы, но работают только тогда, когда в тексте используются те же слова, что и в запросе. Если документ перефразируется, использует синонимы или формулирует идею по-другому, традиционные выделители полностью пропускают ее.

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

Проблема в том, что большинство существующих решений для выделения семантики не предназначены для производственных нагрузок ИИ. Мы протестировали все доступные решения, и ни одно из них не обеспечило того уровня точности, задержки и многоязычной надежности, который был необходим нам для реальных систем RAG и агентов. В итоге мы обучили и выложили в открытый доступ собственную модель: zilliz/semantic-highlight-bilingual-v1

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

• Контекстная обрезка отбрасывает нерелевантные части перед генерацией.

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

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

Семантическое выделение в Milvus и Zilliz Cloud

Семантическое выделение теперь полностью поддерживается в Milvus и Zilliz Cloud (полностью управляемый сервис Milvus), и оно уже оказалось полезным для всех, кто работает с RAG или поиском на основе искусственного интеллекта. Функция решает очень простую, но болезненную проблему: когда векторный поиск возвращает тонну фрагментов, как быстро понять , какие предложения в этих фрагментах действительно важны?

Без подсветки пользователи вынуждены читать целые документы, чтобы понять, почему что-то было найдено. Благодаря встроенной семантической подсветке Milvus и Zilliz Cloud автоматически выделяют фрагменты, которые семантически связаны с вашим запросом - даже если формулировки отличаются. Больше не нужно искать совпадения ключевых слов или гадать, почему появился тот или иной фрагмент.

Это делает поиск гораздо более прозрачным. Вместо того чтобы просто возвращать "релевантные документы", Milvus показывает , где находится релевантность. Для конвейеров RAG это особенно полезно, поскольку вы можете сразу увидеть, на что должна обратить внимание модель, что значительно упрощает отладку и построение подсказок.

Мы встроили эту поддержку непосредственно в Milvus и Zilliz Cloud, поэтому вам не придется подключать внешние модели или запускать другой сервис, чтобы получить полезную атрибуцию. Все работает внутри пути поиска: векторный поиск → скоринг релевантности → выделенные диапазоны. Он работает в масштабе "из коробки" и поддерживает многоязычные рабочие нагрузки с помощью нашей модели zilliz/semantic-highlight-bilingual-v1.

Перспективы

Контекстная инженерия все еще довольно нова, и нам еще многое предстоит выяснить. Даже если обрезка и семантическое выделение хорошо работают в Milvus и Zilliz Cloud, мы еще не приблизились к концу истории. Есть куча областей, которые все еще нуждаются в настоящей инженерной работе: повышение точности моделей обрезки без замедления работы, улучшение обработки странных или внедоменных запросов и соединение всех частей вместе, чтобы поиск → ранжирование → обрезка → выделение ощущались как один чистый конвейер, а не как набор хаков, склеенных вместе.

По мере роста контекстных окон эти решения становятся все более важными. Хорошее управление контекстом больше не является "приятным бонусом", оно становится основной частью надежной работы систем с длинным контекстом и RAG.

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

Если вы хотите обсудить что-то из этого - или вам просто нужна помощь в отладке - вы можете зайти на наш канал Discord или заказать 20-минутную индивидуальную сессию, чтобы получить знания, рекомендации и ответы на свои вопросы в Milvus Office Hours.

Всегда рады пообщаться и обменяться замечаниями с другими строителями.