Если вы говорите более чем на одном языке, вам знакомо это чувство, когда ментальный переключатель в вашей голове запускается с дребезжащим звуком сбоящего двигателя, смешивая каждое слово, которое вам нужно произнести, в некий денглиш, френглиш или спанглиш. Мысли, связанные с работой, приходят из вашего внутреннего поисковика мозга на английском, житейская мудрость – на родном языке, и эта смесь непредсказуема, немного странна, но она работает.
Реальные базы знаний смешивают языки таким же образом: многие компании ЕС, например, хранят внутренние документы сразу на двух или трех языках, и задать вопрос такой базе знаний становится лотереей, какой язык содержит ответ. Извлечение знаний здесь неизбежно означает работу с многоязычным RAG (retrieval-augmented generation) над коллекцией, где вопросы и документы смешивают разные языки.
В идеальном мире информационного поиска язык запроса или документа не имеет значения; важно то, что извлеченный ответ отвечает на вопрос. Производство и идеальный мир пересекаются примерно в… 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-мерные векторы.
Таким образом, распространенные решения либо обходятся дорого для хранения и поиска в масштабе, либо дорого для создания и поддержки, как, например, конвейеры перевода.
Мы постоянно отслеживаем исследования в области информационного поиска, чтобы находить небольшие «чит-коды» для извлечения. И недавняя статья SHIFT заявляет о дешевом, не требующем обучения, обобщаемом решении для смещения многоязычных кодировщиков. Что привлекло наше внимание: главной звездой статьи является multilingual-e5-large, а мы предоставляем его младшего брата в Cloud. Поэтому мы потянулись за этим легкодоступным, универсальным решением; спойлер: оно работает, но его следует использовать с осторожностью.
Идея: Каждый язык — это смещение
(«Семантическая гармонизация посредством преобразования признаков на стороне индекса для многоязычного информационного поиска», июнь 2026 г.) моделирует каждый язык как примерно фиксированное языковое смещение поверх смысла: кодировщик размещает тексты по их значению, но каждый язык также перемещает свои векторы в одном согласованном направлении.
Вычтите немецкое смещение из немецких векторов, и они переместятся к своим английским эквивалентам, при этом сохраняя смысловое расположение.
Одно изученное смещение перетаскивает весь немецкий кластер на английский
Чтобы найти смещение, авторы берут большой набор пар переводов (533 тыс. пар из mMARCO), встраивают их с помощью выбранной модели, затем вычитают и усредняют векторы:
Если переводы действительно параллельны, каждая пара говорит одно и то же дважды, поэтому вычитание отменяет смысловую составляющую и оставляет языковое направление; усреднение по многим парам отменяет оставшийся шум.
Затем, во время индексации, они переносят каждый документ не-опорного языка в пространство опорного языка:
Альфа определяет, насколько сильно вы сдвигаете. Авторы перебирают значения от 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, поскольку сдвиг векторов может нарушить граф и, следовательно, снизить качество приблизительного поиска до невыносимого уровня.
Модель. : 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.
Переоценивайте смещения всякий раз, когда меняете модель или опорный язык.
Переоценивайте смещения всякий раз, когда меняете модель или опорный язык.
Заключение
Используйте метод SHIFT, когда у вас есть ресурсы только для одного общего индекса, когда ответы часто встречаются на языке, отличном от языка запроса, и когда у вас нет времени или сил на этап перевода.
- Сначала измерьте свое соотношение языков ответов. Выберите реальные запросы и разметьте, где находятся их ответы с точки зрения языка. В основном тот же язык? Пропустите сдвиг.
- Если можете, создавайте смещения на основе собственных текстов. Языковое смещение оказалось зависимым от корпуса (согласованность около 0.93 между версиями mMARCO и OPUS). Несколько сотен пар перевода ваших собственных документов лучше, чем полмиллиона из чужого корпуса, хотя публичные все еще можно использовать.
- Следите за префиксами. Модели семейства e5 используют passage: для документов и query: для запросов. Оценивайте каждое смещение с тем же префиксом, который вы к нему применяете. Наш Cloud Inference добавляет нужный префикс автоматически.
- Значение Alpha = 1 здесь сработало, но лучше настроить его под вашу собственную конфигурацию. Если трафик на одном языке велик, подберите alpha на размеченной выборке (скажем, 2-3 тыс. запросов, половина для настройки и половина для валидации; достаточно грубой сетки) и выберите свой собственный баланс.
Если вы создаете многоязычную RAG-систему, свяжитесь с нами по адресу Discord. Мы также изучаем сейчас межъязыковой разреженный нейронный поиск и будем рады получить интересные варианты использования для тестирования наших подходов!
