Мы обучили и выложили в открытый доступ двуязычную модель семантического выделения для производственного RAG и ИИ-поиска

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

Большинство систем по-прежнему полагаются на выделение по ключевым словам. Если пользователь ищет "производительность iPhone", система выделяет именно лексемы "iPhone" и "производительность". Но этот способ перестает работать, как только в тексте одна и та же идея выражается разными формулировками. Описание вроде "Чип A15 Bionic, более миллиона бенчмарков, плавная работа без задержек" явно относится к производительности, но при этом ничего не выделяется, потому что ключевые слова не появляются.

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

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

• Наша модель семантического выделения: zilliz/semantic-highlight-bilingual-v1

• Расскажите нам о своем мнении - присоединяйтесь к нашему Discord, следите за нами на LinkedIn или запишитесь на 20-минутную сессию Milvus Office Hours с нами.

Как работает выделение на основе ключевых слов - и почему оно не работает в современных системах искусственного интеллекта

Традиционные поисковые системы реализуют выделение с помощью простого подбора ключевых слов. Когда результаты возвращаются, движок находит точные позиции лексем, которые соответствуют запросу, и упаковывает их в разметку (обычно это теги <em> ), оставляя фронтенду возможность отобразить подсветку. Это отлично работает, когда термины запроса встречаются в тексте дословно.

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

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

Предположим, пользователь спрашивает: "Как повысить эффективность выполнения кода Python?". Система извлекает технический документ из векторной базы данных. Традиционная подсветка может отмечать только буквальные совпадения, такие как "Python", "код", "выполнение" и "эффективность".

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

• Используйте векторные операции NumPy вместо явных циклов

• Избегайте многократного создания объектов внутри циклов.

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

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

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

Между тем, наиболее ценные сведения могут выглядеть следующим образом:

• Серия iPhone 15 способствовала более широкому восстановлению рынка.

• Ограничение поставок микросхем привело к росту стоимости на 15 %.

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

Что такое семантическое выделение и болевые точки современных решений

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

Такой подход решает основную проблему традиционного выделения, которое работает только в том случае, если термины запроса встречаются дословно. Если пользователь ищет "производительность iPhone", выделение по ключевым словам игнорирует такие фразы, как "чип A15 Bionic", "более миллиона бенчмарков" или "плавная работа без задержек", даже если эти строки явно отвечают на вопрос. Семантическое выделение улавливает эти смысловые связи и выводит на поверхность те части текста, которые действительно важны для пользователей.

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

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

opensearch-semantic-highlighter

В прошлом году OpenSearch выпустил специальную модель для семантического выделения: opensearch-semantic-highlighter-v1. Хотя это осмысленная попытка решить проблему, у нее есть два критических недостатка.

• Маленькое контекстное окно: Модель основана на архитектуре BERT и поддерживает максимум 512 лексем - примерно 300-400 китайских иероглифов или 400-500 английских слов. В реальных сценариях описания продуктов и технические документы часто состоят из тысяч слов. Контент, выходящий за пределы первого окна, просто обрезается, заставляя модель определять основные моменты на основе лишь небольшой части документа.

• Плохое обобщение за пределами области: Модель хорошо работает только на распределениях данных, схожих с обучающим набором. При применении к данным, выходящим за пределы домена, например, при использовании модели, обученной на новостных статьях, для выделения контента электронной коммерции или технической документации, эффективность резко снижается. В наших экспериментах модель достигает оценки F1 около 0,72 на доменных данных, но падает примерно до 0,46 на внедоменных наборах данных. Такой уровень нестабильности проблематичен в производстве. Кроме того, модель не поддерживает китайский язык.

Прованс / XProvence

Provence - это модель, разработанная компанией Naver, которая изначально обучалась для обрезки контекста -задачи, тесно связанной с семантическим выделением.

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

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

Однако на практике и Provence, и XProvence имеют несколько заметных недостатков:

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

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

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

• Ограничительное лицензирование: И Provence, и XProvence выпускаются под лицензией CC BY-NC 4.0, которая не допускает коммерческого использования. Уже одно это ограничение делает их непригодными для многих производственных развертываний.

Open Provence

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

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

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

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

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

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

• Достаточно большое контекстное окно для работы с длинными документами

• Надежное обобщение вне области

• Высокая точность в задачах семантического выделения

• Разрешительная, удобная для производства лицензия (MIT или Apache 2.0).

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

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

Наиболее сложной частью этого процесса является создание данных. Во время аннотирования мы просим LLM (Qwen3 8B) выводить не только выделенные фрагменты, но и все рассуждения, лежащие в их основе. Этот дополнительный сигнал рассуждений обеспечивает более точный и последовательный контроль и значительно повышает качество результирующей модели.

На высоком уровне конвейер аннотирования работает следующим образом: LLM-рассуждения → выделение меток → фильтрация → конечная обучающая выборка.

На практике такая схема дает три конкретных преимущества:

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

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

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

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

Для обучения модели мы начали с BGE-M3 Reranker v2 (0,6 ББ параметров, контекстное окно на 8 192 ток-ена), использовали фреймворк обучения Open Provence и обучались в течение трех эпох на 8× A100 GPU, завершив обучение примерно за пять часов.

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

Бенчмаркинг двуязычной модели семантического выделения Zilliz

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

Наборы данных

В нашей оценке мы использовали следующие наборы данных:

• MultiSpanQA (английский) - набор данных для многопространственных ответов на вопросы в домене.

• WikiText-2 (английский) - внедоменный корпус Википедии

• MultiSpanQA-ZH (китайский) - китайский многопространственный набор данных для ответов на вопросы

• WikiText-2-ZH (китайский) - внедоменный корпус китайской Википедии

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

В сравнении участвовали следующие модели:

• Открытые модели Provence

• Provence / XProvence (выпущена компанией Naver)

• OpenSearch Semantic Highlighter

• Двуязычная модель семантического выделения Zilliz

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

Английские наборы данных:

Китайские данные:

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

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

• Open Provence поддерживает только английский язык.

• XProvence жертвует производительностью на английском языке по сравнению с Provence

• OpenSearch Semantic Highlighter не поддерживает китайский язык и демонстрирует слабую обобщенность.

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

Конкретный пример на практике

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

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

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

1. Убийство священного оленя" - психологический триллер 2017 года режиссера Йоргоса Лантимоса, сценарий которого написали Лантимос и Эфтимис Филиппу.

2. В фильме снимались Колин Фаррелл, Николь Кидман, Барри Кеоган, Рэффи Кэссиди, Санни Сульджич, Алисия Сильверстоун, Билл Кэмп.

3. Сюжет основан на древнегреческой пьесе Еврипида "Ифигения в Аулисе".

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

5. Он знакомит мальчика со своей семьей, после чего с ним начинают происходить загадочные болезни.

Правильный ответ: Предложение 1 - правильный ответ, поскольку в нем прямо указано, что сценарий написали Йоргос Лантимос и Эфтимис Филиппу.

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

Результаты:

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

Модель	Определен правильный ответ	Результат
Наша (двуязычная M3)	✓	Выбрали предложение 1 (правильно) и предложение 3
XProvence v1	✗	Выбрал только предложение 3, пропустил правильный ответ
XProvence v2	✗	Выбрал только предложение 3, пропустил правильный ответ

Сравнение баллов на уровне предложения

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

Где XProvence не справляется

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

• В то же время он в значительной степени игнорирует правильный ответ в предложении 1, присваивая ему крайне низкие баллы (0,133 и 0,081).

• Даже после снижения порога принятия решения с 0,5 до 0,2 модель по-прежнему не обнаруживает правильного ответа.

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

Как наша модель ведет себя по-другому

• Наша модель присваивает высокий балл (0,915) правильному ответу в предложении 1, верно указывая сценаристов фильма.

• Она также присваивает умеренный балл (0,719) предложению 3, поскольку в этом предложении упоминается понятие, связанное со сценарием.

• Очень важно, что разделение является четким и осмысленным: 0,915 против 0,719, разрыв почти 0,2.

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

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

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

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

Параллельно мы работаем над готовым к выпуску сервисом вывода и интегрируем модель непосредственно в Milvus в качестве встроенного API Semantic Highlighting. Эта интеграция уже осуществляется и скоро будет доступна.

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

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