Как мы построили модель семантического выделения для обрезки контекста RAG и сохранения токенов

Проблема: Шум RAG и пустая трата жетонов

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

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

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

Традиционное выделение на основе ключевых слов не может решить эту проблему. Например, если пользователь спрашивает: "Как повысить эффективность выполнения кода Python?", выделитель ключевых слов выделит слова "Python" и "эффективность", но пропустит предложение, которое действительно отвечает на вопрос - "Использовать векторные операции NumPy вместо циклов" - потому что в нем нет общих ключевых слов с запросом. Вместо этого нам нужно семантическое понимание, а не сопоставление строк.

Модель семантического выделения для фильтрации шумов и обрезки контекста в RAG

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

Детали модели

• HuggingFace: zilliz/semantic-highlight-bilingual-v1

• Лицензия: MIT (коммерческая)

• Архитектура: 0.6B только кодирующая модель, основанная на BGE-M3 Reranker v2

• Контекстное окно: 8192 лексемы

• Поддерживаемые языки: Английский и китайский

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

• Улучшенная интерпретируемость, показывающая, какие части документа действительно имеют значение

• Снижение стоимости токенов на 70-80 % за счет отправки в LLM только выделенных предложений

• Повышение качества ответов, поскольку модель видит меньше нерелевантного контекста

• Более простая отладка, поскольку инженеры могут напрямую проверять совпадения на уровне предложений.

Результаты оценки: Достижение производительности SOTA

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

В число эталонных наборов вошли:

• английский многопространственный QA: multispanqa

• Английская внедоменная Википедия: wikitext2

• Китайская многопространственная QA: multispanqa_zh

• Китайская внедоменная Википедия: wikitext2_zh

Оцененные модели включают:

• серия Open Provence

• Серия "Прованс/XProvence" от Naver

• Семантический хайлайтер OpenSearch

• Наша обученная двуязычная модель: zilliz/semantic-highlight-bilingual-v1

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

Как мы построили эту модель семантического выделения

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

• Архитектура модели: использование только кодировщика для быстрого вывода.

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

Архитектура модели

Мы построили модель в виде легкой сети, работающей только с кодировщиком, которая рассматривает обрезку контекста как задачу оценки релевантности на уровне токенов. Этот дизайн вдохновлен Provence, подходом к обрезке контекста, представленным компанией Naver на ICLR 2025, который пересматривает обрезку с "выбора правильного куска" на "оценку каждого токена". Такая постановка вопроса естественным образом сочетается с семантическим выделением, где важны тонкие сигналы.

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

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

Процесс вывода

Во время работы наша модель семантического выделения следует простой схеме:

1. Вход - процесс начинается с запроса пользователя. Полученные документы рассматриваются как контекст-кандидат для оценки релевантности.

2. Обработка модели - Запрос и контекст объединяются в одну последовательность: [BOS] + запрос + контекст

3. Оценка токенов - каждому токену в контексте присваивается балл релевантности от 0 до 1, отражающий степень его связи с запросом.

4. Агрегирование предложений - оценки токенов агрегируются на уровне предложений, обычно путем усреднения, чтобы получить оценку релевантности для каждого предложения.

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

Базовая модель: BGE-M3 Reranker v2

Мы выбрали BGE-M3 Reranker v2 в качестве базовой модели по нескольким причинам:

1. В ней используется архитектура кодировщика, подходящая для оценки токенов и предложений.

2. Поддерживает несколько языков с оптимизацией для английского и китайского

3. Обеспечивает контекстное окно на 8192 токена, подходящее для длинных документов RAG

4. Поддерживает 0.6B параметров - достаточно сильных, но не требующих больших вычислительных затрат

5. Обеспечивает достаточное знание мира в базовой модели

6. Обучена для повторного ранжирования, что тесно связано с задачами оценки релевантности

Обучающие данные: Аннотация LLM с рассуждениями

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

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

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

Включение обоснования оказалось удивительно ценным:

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

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

• Более простая отладка: Если что-то кажется неправильным, обоснование позволяет легко определить, в чем проблема - в подсказке, домене или логике аннотации.

• Многократно используемые данные: Даже если в будущем мы перейдем на другую модель маркировки, следы рассуждений останутся полезными для повторной маркировки или аудита.

Рабочий процесс аннотирования выглядит следующим образом:

Qwen3 8B для аннотации

Для аннотирования мы выбрали Qwen3 8B, потому что она поддерживает "режим мышления" через выходы, что значительно упрощает извлечение последовательных следов рассуждений. Маленькие модели не давали нам стабильных меток, а большие модели были медленнее и неоправданно дорогими для такого рода конвейера. В Qwen3 8B найден правильный баланс между качеством, скоростью и стоимостью.

Мы выполняли все аннотации, используя локальный сервис vLLM, а не облачные API. Это обеспечило нам высокую пропускную способность, предсказуемую производительность и гораздо меньшую стоимость - по сути, мы обменяли время работы на GPU на плату за токены API, что является более выгодным предложением при генерации миллионов образцов.

Масштабность набора данных

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

• Английские источники: MS MARCO, Natural Questions, GooAQ.

• Китайские источники: DuReader, китайская Википедия, mmarco_chinese.

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

Все аннотированные обучающие данные также доступны на HuggingFace для развития сообщества и использования в обучении: Наборы данных Zilliz

Метод обучения

После того как архитектура модели и набор данных были готовы, мы провели обучение модели на 8× A100 GPU в течение трех эпох, что заняло примерно 9 часов.

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

Пример из реального мира

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

Запрос: Кто написал "Убийство священного оленя"?

Контекст (5 предложений):

1\. The Killing of a Sacred Deer is a 2017 psychological horror film directed by Yorgos Lanthimos,
with a screenplay by Lanthimos and Efthymis Filippou.
2. The film stars Colin Farrell, Nicole Kidman, Barry Keoghan, Raffey Cassidy,
Sunny Suljic, Alicia Silverstone, and Bill Camp.
3. The story is based on the ancient Greek playwright Euripides’ play Iphigenia in Aulis.
4. The film tells the story of a cardiac surgeon (Farrell) who secretly
befriends a teenager (Keoghan) connected to his past.
5. He introduces the boy to his family, who then mysteriously fall ill.

Правильный ответ: Предложение 1 (прямо указано "сценарий Лантимоса и Эфтимиса Филиппу").

В этом примере есть ловушка: в предложении 3 упоминается, что "Еврипид" написал оригинальную пьесу. Но в вопросе спрашивается, "кто написал фильм "Убийство священного оленя"", и отвечать следует сценаристам фильма, а не греческому драматургу тысячелетней давности.

Результаты моделирования

Модель	Находит правильный ответ?	Предсказание
Наша модель	✓	Выбраны предложения 1 (правильное) и 3
XProvence v1	✗	Выбрал только предложение 3, пропустил правильный ответ
XProvence v2	✗	Выбрано только предложение 3, пропущен правильный ответ

Сравнение ключевых баллов предложений:

Предложение	Наша модель	XProvence v1	XProvence v2
Предложение 1 (сценарий фильма, правильный ответ)	0.915	0.133	0.081
Предложение 3 (оригинальная пьеса, дистрактор)	0.719	0.947	0.802

Модели XProvence:

• Сильно привлекает "Еврипид" и "пьеса", давая предложению 3 почти идеальные оценки (0,947 и 0,802)

• Полностью игнорирует фактический ответ (предложение 1), давая крайне низкие оценки (0,133 и 0,081)

• Даже при снижении порога с 0,5 до 0,2 он все равно не может найти правильный ответ.

Наша модель:

• Правильно присваивает предложению 1 наивысший балл (0,915)

• Присваивает предложению 3 некоторую значимость (0,719), поскольку оно связано с фоном.

• Четко разделяет эти два предложения с отрывом ~0,2 балла.

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

Попробуйте и скажите нам, что вы думаете

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

• Скачать с HuggingFace: zilliz/semantic-highlight-bilingual-v1

• Все аннотированные обучающие данные: https://huggingface.co/zilliz/datasets.

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

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

Попробуйте семантическое выделение в полностью управляемом облаке Zilliz Cloud бесплатно.

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

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

Благодарности

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

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

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

Поверх этой основы мы добавили несколько собственных разработок:

• Использование LLM-рассуждений для генерации более качественных меток релевантности

• Создание почти 5 миллионов двуязычных обучающих образцов, согласованных с реальными рабочими нагрузками RAG

• Выбор базовой модели, лучше подходящей для оценки релевантности в длинном контексте(BGE-M3 Reranker v2)

• Обучение только головки обрезки для специализации модели для семантического выделения

Мы благодарны командам Provence и Open Provence за открытую публикацию своих работ. Их вклад значительно ускорил наше развитие и сделал этот проект возможным.