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

Реальные базы знаний смешивают языки точно так же: многие компании в ЕС, например, хранят внутренние документы сразу на двух или трех языках, и задать вопрос такой базе знаний — это лотерея, в которой неясно, на каком языке найдется ответ. Поиск знаний здесь неизбежно означает работу с многоязычным RAG (генерацией с дополнением поиска) по коллекции, где вопросы и документы написаны на разных языках.

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

Языковые утечки в вашем поиске

Поиск по смыслу якобы решен с помощью семантического поиска, и язык не должен быть препятствием. Возьмите многоязычную модель эмбеддингов (ту, что отображает текст на многих языках в одно и то же векторное пространство, например multilingual-e5-small или bge-m3), и тексты с одинаковым значением должны оказаться рядом. Должны…

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

Мы проверили это с помощью intfloat/multilingual-e5-small, модели, которую наш Cloud Inference предоставляет бесплатно. На XRAG, 15 277 реальных новостных статей на пяти языках, ответ на том же языке попадает в топ-10 в 61% случаев, в то время как столь же релевантный ответ на другом языке оказывается там лишь в 8% случаев.

Английские и испанские документы из XRAG, закодированные с помощью «multilingual-e5-small», разделяются на отдельные кластеры вместо того, чтобы смешиваться по смыслу.

Обычные способы исправления этого смещения довольно затратны: перевод каждого документа и хранение копии для каждого языка, а затем выполнение одного поиска на язык и объединение результатов. Либо использование более крупной, казалось бы, беспристрастной модели; так, в нашем недавнем исследовании мы заметили, что Qwen3-Embedding-8B — настоящий чемпион в борьбе с языковым смещением в эмбеддингах.

Qwen3-8B сохраняет английские и испанские точки смешанными по смыслу.

…но векторы Qwen-8B имеют размерность 4096; для сравнения, multilingual-e5-small создает 384-мерные векторы.

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

Мы постоянно следим за исследованиями в области IR, чтобы находить небольшие «читы» для поиска. И недавняя статья SHIFT предлагает дешевое, не требующее дообучения и универсальное решение для смещения многоязычных энкодеров. Что привлекло наше внимание: главная звезда статьи — multilingual-e5-large, а мы предоставляем ее «младшего брата» в Cloud. Мы решили воспользоваться этим низковисящим фруктом; спойлер: это работает, но использовать нужно с осторожностью.

Идея: каждый язык — это смещение

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

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

Одно изученное смещение перетаскивает весь немецкий кластер на английский

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

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

Затем, во время индексации, они переносят каждый документ, не относящийся к опорному языку, в пространство опорного языка:

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

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

В результате общие метрики поиска должны улучшиться. Для multilingual-e5-large средний nDCG@20 вырастает с 0,633 до 0,737 по всем бенчмаркам статьи, при этом метрика кросс-языкового поиска, TLR@20 (Target-Languages Recall), совершает наибольший скачок, освободившись от смещения.

Можно ли это использовать повторно?

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

Авторы показывают, что метод работает с разными моделями многоязычных эмбеддингов (с лучшими результатами на multilingual-e5-large). Если мы попробуем его на нашей меньшей multilingual-e5-small, увидим ли мы улучшения?
Не скрывают ли общие метрики регрессию на том же языке? После сдвига запрос может перестать находить наиболее релевантный ответ на своем собственном языке. Статья фокусируется на общих и кросс-языковых метриках, но для продакшна вы должны знать о компромиссах.
Имеет ли язык фиксированное смещение, которое можно повторно использовать в разных доменах, или смещение зависит от набора данных и темы? Если оно зависит от набора данных, сколько параллельных пар достаточно для его оценки?
Как метод ведет себя на наборе данных, который действительно похож на многоязычный RAG?

Быстрая проверка

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

Модель. : 384 измерения, идентично той, что используется в нашем Qdrant Cloud Inference.

Данные. : 15 277 новостных статей на английском, немецком, испанском, арабском и китайском языках.

6 200 вопросов, на которые ответили люди (1 000 на английском и по 1 300 на каждом из других четырех языков)
Около 73% статей на английском языке
Вопрос может иметь релевантные ответы на более чем одном языке
Большинство этих вопросов действительно требуют кросс-языкового поиска: 83% имеют релевантный ответ на языке, отличном от их собственного, и только 34% имеют ответ на своем собственном языке.

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

В XRAG отсутствуют языковые метки, которые необходимы для выбора смещения (offset) для каждого языка, поэтому мы пометили документы с помощью простого детектора языка (точность в целом около 74%, надежно для арабского и китайского, хуже для немецкого и испанского).

Проверка на здравый смысл. Мы также запустили Multi-EuP (фрагменты парламентских дебатов) и XQuAD (вопросно-ответные абзацы) на их английских/немецких/испанских срезах в качестве проверки на здравый смысл, чтобы увидеть, воспроизводятся ли результаты статьи на нашей небольшой модели.

Метрика. Recall@10, разделенный на три части: общий (все релевантные ответы), на том же языке (только ответы на языке запроса) и кросс-языковой (только ответы на других языках). Recall на том же и на других языках рассчитывается как макросреднее по языкам запросов. Мы выбрали @10 вместо @20 из статьи намеренно: в промышленном RAG чем меньше чанков вы подаете модели, тем меньше вы ее отвлекаете.

Смещение (Offset)

Авторы оценили свои смещения на основе 533 тыс. пар mMARCO. Повторение такого масштаба для эксперимента показалось избыточным, поэтому мы проверили две вещи: (а) сходится ли смещение на гораздо меньшем количестве пар, чем полмиллиона, и (б) является ли смещение универсальным или на него влияет домен набора данных. Если оно зависит от домена, насколько сильно различаются смещения в разных наборах данных?

Мы оценили языковые смещения на OPUS-100, увеличивая выборку до тех пор, пока смещение не переставало меняться, а затем сравнили их со смещениями, оцененными таким же образом на mMARCO.

Примечание о смещениях для «multilingual-e5-small». Модели семейства e5 ожидают префикс passage: перед документами и query: перед запросами, поэтому смещение для небольшой модели должно быть оценено дважды, по одному разу в каждом пространстве, и применено к соответствующей стороне.

Примечание о смещениях для «multilingual-e5-small». Модели семейства e5 ожидают префикс passage: перед документами и query: перед запросами, поэтому смещение для небольшой модели должно быть оценено дважды, по одному разу в каждом пространстве, и применено к соответствующей стороне.

Результаты:

Вам не нужны полмиллиона пар. Смещение стабилизируется быстро: две независимые выборки одного и того же корпуса согласуются с косинусным сходством 0.9999, и оно почти не меняется после тысячи пар. Нескольких сотен (мы использовали 3000) уже достаточно, чтобы зафиксировать направление.
Смещения действительно различаются между наборами данных, как и ожидалось (иначе этот языковой вектор был бы найден и опубликован давным-давно :D). Значение нельзя полностью отделить от языка. Но разница меньше, чем мы предполагали: смещения из двух разных корпусов (Opus и mMARCO) согласуются с косинусным сходством около 0.93 (de 0.933, es 0.926).
В рамках одного набора данных подвыборка почти не имеет значения. Вы быстро сходитесь к одному и тому же смещению независимо от того, какой срез вы берете; в нашем случае две случайные непересекающиеся выборки одного и того же корпуса имели косинусное сходство 0.9999.

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

Воспроизводимо ли это?

В коллекции XRAG обмен выгоден: ответы распределены по разным языкам, поэтому выигрыш в кросс-языковом recall перевешивает потерю в recall на том же языке. Например, для испанского запроса о решении по зимним топливным выплатам в Великобритании («¿Qué acontecimiento fue más polémico: la advertencia de la investigación del Partido Laborista sobre las muertes o la decisión de recortar los pagos del combustible en invierno?»): соответствующая английская статья находится на 438-й позиции, слишком далеко, чтобы иметь значение, а после сдвига она перемещается на 5-ю.

Кросс-языковой recall увеличивается в три-четыре раза.
Recall на том же языке платит за это. Это ожидаемо: мы перенаправили каждый неанглийский документ на английский, поэтому немецкий запрос теперь находит свои немецкие ответы менее надежно. Немецкий язык страдает больше всего: его recall на том же языке в XRAG падает с 0.61 до 0.35.
Общий показатель здесь растет, потому что в этих наборах данных многие ответы находятся вне языка запроса.

Если ваши пользователи в основном задают немецкие вопросы о немецких документах, SHIFT повредит качеству поиска. Измерьте свое собственное соотношение языков ответов, прежде чем что-либо менять.

HNSW

Если метод работает при полном сканировании, выживет ли он при HNSW? Сдвиг векторов может исказить структуру графа и приближенный поиск ближайших соседей.

При таком размере корпуса коллекция Qdrant по умолчанию остается в режиме полного сканирования, поэтому для измерения HNSW мы снизили порог индексации до 1000 КБ.

При таком размере корпуса коллекция Qdrant по умолчанию остается в режиме полного сканирования, поэтому для измерения HNSW мы снизили порог индексации до 1000 КБ.

На тех же сдвинутых векторах recall индекса HNSW совпал с точным поиском с погрешностью около 0.005:

Сила сдвига

alpha задает силу сдвига. Лучшее значение зависит от модели: для более крупной модели multilingual-e5-large из статьи пик приходится на 0.6, другие модели работают лучше всего при 1.0. Для multilingual-e5-small recall растет прямо до alpha = 1.

Анализ Alpha. recall@10 неуклонно растет до 1.0 для multilingual-e5-small, без пиков посередине.

Лучшее значение alpha зависит от вашего варианта использования, поэтому, если вы хотите что-то лучшее, чем значение по умолчанию 1.0: получите несколько сотен или тысяч размеченных вопросов (qrels), а затем настройте. Разделите их, прогоните alpha на одной половине и примените лучшее значение к другой для проверки.

Рецепт

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

Чтобы сдвинуть свои данные, вам нужно:

Переведенные пары для создания каждого смещения: публичные параллельные корпуса, такие как или Tatoeba, или переведенная машинным способом выборка ваших собственных документов. Нескольких сотен пар уже достаточно для стабилизации направления (мы использовали 3000 на язык). Однако смещение не является универсальной константой, поэтому создавайте его на основе текста, который похож на ваши документы.
Опционально: детектор языка для пометки каждого документа и запроса при приеме.

Эталонная реализация статьи на GitHub.

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