Малоресурсный язык ломает коммерческие embedding: R@1 0,83 (LaBSE) vs 0,21 (OpenAI) на армянском EPG

TL;DR: Платные модели embedding плохо работают с малоресурсными языками. OpenAI text-embedding-3-large набирает R@1 = 0,21 на армянском -- уровень случайного угадывания. Причина -- токенизатор: cl100k_base не содержит армянских токенов и разбивает текст побайтово, раздувая его в 10 раз по сравнению с английским. Бесплатные мультиязычные модели с SentencePiece/WordPiece-токенизаторами не имеют этой проблемы. Протестировано 19 моделей на 245 триплетах EN/RU/HY из TMDB. Лучший retrieval -- LaBSE (R@1 = 0,83), лучший alignment -- multilingual-e5-large (0,86).

Работая над прототипом IPTV/OTT RecSys, на старте взял коммерческий облачный embedding как baseline -- распространённый шаблон при разработке продуктов с ML. Качество кроссязыкового сопоставления EPG-заголовков оказалось низким. Стал искать подходящую модель -- написал простой бенчмарк из 7 триплетов и 4 синонимных пар. Выяснилось, что бесплатные мультиязычные модели работают значительно лучше платных. Замена модели улучшила RecSys на практике, но размер тестов вызывал сомнения -- 7 примеров всё-таки мало для уверенных выводов.

В итоге это выросло в полноценное исследование: 19 моделей, 245 триплетов, 783 дуплета для теста сокращений -- на домене мультиязычного EPG (английский, русский, армянский).

Результаты подтвердили первоначальные находки по alignment (средний cosine): бесплатная модель с Hugging Face набирает 0,86, OpenAI text-embedding-3-large -- 0,34, Cohere embed-v4.0 -- 0,47. Но добавление retrieval-метрик (Recall@1, MRR) полностью перетасовало рейтинг -- и выявило модели-ловушки с красивым alignment, но нулевой дискриминацией.

Код, весь синтетический/публичный датасет (TMDB-триплеты, тесты на сокращения, синонимные пары) и полные таблицы результатов -- в открытом доступе. Двухнедельный продуктовый EPG-дамп не публикую по понятным причинам; его агрегированные статистики (распределение языков, доля сокращений и т.п.) приведены прямо в тексте.

Постановка задачи

Армянские IPTV/OTT EPG-ленты по природе мультиязычны: в одном и том же фиде регулярно встречаются армянский (HY), русский (RU) и английский (EN). Армянский -- государственный язык. Русский широко распространён и часто доминирует в метаданных вещания на постсоветском пространстве. Английский -- стандарт для международного контента и глобальных источников данных. Поэтому трилингвальное сопоставление заголовков -- это практическое продуктовое требование.

Анализ 14-дневного продуктового дампа EPG (239 каналов, 35 170 записей) показывает языковой состав заголовков:

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

Каждый IPTV-оператор получает EPG-данные из нескольких источников. Одна и та же программа появляется на разных каналах с разными идентификаторами записей, разными названиями, разными транслитерациями и на разных языках. Чтобы агрегировать историю просмотров пользователя по каналам -- и строить на её основе рекомендации -- система должна уметь сопоставлять эти записи между собой. Рекомендательная система, не способная выполнять кросс-языковое сопоставление, даёт некачественные рекомендации для неанглоязычного контента.

Армянский язык (hy) представляет особую сложность:

• Нелатинская, некириллическая письменность (уникальный армянский алфавит: Հ, Ա, Յ, Ե, ...)

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

• Смешение армянского, русского и английского в EPG-заголовках

• Доменно-специфичные сокращения

Методология

Датасет

• 245 триплетов (EN, RU, HY): 7 рукописных EPG-записей + 238 реальных из TMDB API

• 783 дуплета для теста устойчивости к сокращениям (например, "Название" vs "к/ф Название").

• 4 пары HY-HY синонимов для внутриязыковой консистентности

Метрика

Средний косинусный коэффициент по трём кроссязыковым парам:

• cos(embed(EN), embed(RU)) -- EN-RU

• cos(embed(EN), embed(HY)) -- EN-HY

• cos(embed(RU), embed(HY)) -- RU-HY

Итоговый балл = среднее трёх. Почему среднее, а не минимум? Минимум скрывает ситуации, когда модель хороша на двух парах и плоха на одной. Среднее более устойчиво к выбросам в конкретной паре, а детальная разбивка по парам всё равно приведена в таблице результатов.

Устойчивость к сокращениям -- средний cos(embed(title), embed(prefix + title)) по 783 дуплетам (отдельно для RU и HY). Идеальная модель даёт 1.0: добавление "к/ф" или "м/ф" перед названием не должно менять эмбеддинг.

HY-HY внутриязыковая консистентность -- средний cos(embed(A), embed(B)) по 4 парам армянских синонимов (например, "Մարզական ամփոփում" vs "Սպորտային ամփոփագիр"). Проверяет, различает ли модель семантически идентичные фразы на низкоресурсном языке.

Recall@1 -- для каждого заголовка на языке A ищем ближайший по cosine среди всех 245 заголовков на языке B. Если ближайший -- правильный перевод, это hit. Поиск выполняется в обе стороны (A->B и B->A), R@1 = среднее двух направлений. Итоговый R@1 = среднее по трём парам (EN<->RU, EN<->HY, RU<->HY).

MRR (Mean Reciprocal Rank) -- аналогично R@1, но учитывает позицию правильного ответа: если правильный перевод на 1-м месте -- 1,0; на 2-м -- 0,5; на 3-м -- 0,33 и т.д. Среднее по трём парам.

Cross-lang mean измеряет alignment (насколько близки правильные пары). R@1 и MRR измеряют discrimination (отличает ли модель правильную пару от 244 неправильных). Для продакшн-системы нужны оба свойства.

Ограничения методологии

• Instruct-модель исключена. multilingual-e5-large-instruct исключена из бенчмарка: instruct-модели проектируются для асимметричных задач (query -> document) и требуют instruction prefix. В нашей задаче (симметричное попарное сравнение заголовков) использование instruct-модели без префикса некорректно, а добавление префикса меняет саму задачу. Результаты non-instruct e5-моделей -- корректная нижняя граница.

• Нет query prefix для семейства E5. Модели intfloat/multilingual-e5-* и intfloat/e5-* документируют рекомендуемый префикс "query: " для входных текстов. В нашем бенчмарке все тексты передаются без префиксов. Это значит, что результаты E5 -- нижняя граница: с корректными префиксами их результаты могут быть ещё выше.

• Jina v3: task-адаптер активирован. Для jinaai/jina-embeddings-v3 и API, и локальный ST-бэкенд используют task="retrieval.passage" / prompt_name="retrieval.passage". Остаточный разрыв (0,851 vs 0,811) может быть связан с различиями в "технической" части, так как уже исключили "самую частую" причину расхождений.

• HY-HY синонимы (N=4) -- слишком малая выборка для статистически значимых выводов. Метрика приведена как иллюстративная.

• Дисперсия не приведена. Таблица содержит средние по 245 триплетам, но без стандартного отклонения или доверительных интервалов. Для близких моделей (e5-base 0,861 vs e5-large 0,863) разница может быть незначима / различна в пределах шума.

• TMDB != реальный EPG. 238 из 245 триплетов взяты из TMDB -- это community-переводы. Реальные EPG-заголовки грязнее: обрезки, транслитерации, опечатки, смешение языков в одном поле. Бенчмарк может завышать реальную production-эффективность.

Модели

19 моделей, 6 бэкендов:

Локальные (SentenceTransformers):

• intfloat/multilingual-e5-large (2023)

• intfloat/multilingual-e5-base (2023)

• intfloat/e5-large-v2 (2023)

• intfloat/e5-large (2022)

• sentence-transformers/LaBSE (2022)

• BAAI/bge-m3 (2024)

• Alibaba-NLP/gte-multilingual-base (2024)

• Metric-AI/armenian-text-embeddings-1 (2024)

• jinaai/jina-embeddings-v3 -- локально через ST

• paraphrase-multilingual-mpnet-base-v2 (2021)

• paraphrase-multilingual-MiniLM-L12-v2 (2021)

• distiluse-base-multilingual-cased (2020)

• all-MiniLM-L6-v2 (2021)

FlagEmbedding:

• BAAI/bge-m3 -- тот же чекпойнт, другой бэкенд

API:

• OpenAI text-embedding-3-large (2024)

• Cohere embed-v4.0 (2025)

• Cohere embed-multilingual-v3.0 (2023)

• Jina jina-embeddings-v3 (2024)

• Voyage voyage-multilingual-2 (2024)

Железо

MacBook M2 Max, 32 GB RAM. Локальные модели через CPU/Metal, API через интернет. Время замерено на батче из 735 текстов (245 триплетов x 3 языка). Абсолютные значения мс/текст приведены для сравнения моделей между собой, а не как ориентир серверной производительности.

Результаты

Размерность эмбеддингов: 3072 (OpenAI), 1024 (e5-large, Jina, Cohere, Voyage, bge-m3), 768 (e5-base, LaBSE, armenian, mpnet, gte), 512 (distiluse), 384 (MiniLM). Влияет на размер индекса и скорость ANN-поиска.

Рис. 1. Модели, ранжированные по средней кроссязыковой косинусной близости (EN↔RU, EN↔HY, RU↔HY). Зелёная линия -- порог 0,8.

Рис. 2. Разбивка по языковым парам. OpenAI проваливается на любой паре с армянским (EN↔HY = 0,216, RU↔HY = 0,267).

Retrieval: Recall@1 и MRR

Та же таблица, отсортированная по MRR -- способности модели найти правильное соответствие среди 245 кандидатов:

Рис. 3. Recall@1 и MRR -- способность модели найти правильное соответствие среди 245 кандидатов. LaBSE лидирует по обеим метрикам.

Рис. 4. Recall@1 по языковым парам. Монолингвальные e5-large/e5-large-v2 проваливаются на retrieval несмотря на высокий alignment.

Анализ

1. Alignment vs Discrimination: две разные истории

Рейтинг по alignment (cross-lang mean) и по retrieval (MRR) -- не одно и то же. Самые показательные перестановки:

Что происходит? Модели e5-large-v2 и e5-large -- монолингвальные (английские). Они маппят армянский и русский текст в один плотный кластер: cosine высокий для всех пар (и правильных, и неправильных), но R@1 = 0,16 и 0,12 -- модель "угадывает" правильный матч лишь в 12-16% случаев. Высокий alignment без discrimination -- ловушка: метрика выглядит хорошо, а в production поиск не работает.

Аналогичный эффект проявляется у локального Jina v3: alignment 0,811 (#4), но R@1 = 0,605 (#13). API-версия того же чекпойнта показывает R@1 = 0,756 -- разрыв может быть связан с различиями в runtime и precision между SentenceTransformers и Jina API.

LaBSE, наоборот, тренировался на параллельных корпусах с contrastive loss -- именно на задачу различения. Его alignment умеренный (0,746), но R@1 = 0,834 -- лучший результат в бенчмарке.

2. Мультиязычные e5 -- лучший баланс alignment и retrieval

Два мультиязычных варианта e5 стабильно в топ-6 по обеим метрикам. e5-large -- #1 по alignment (0,863) и #2 по MRR (0,837). e5-base (0,861 / 0,794) побеждает большинство моделей по обоим критериям при вдвое меньшем размере.

Почему мультиязычные e5 работают?

• Тренировка на массивных параллельных корпусах (CCMatrix, WikiMatrix)

• Хорошая субсловная репрезентация для нестандартных скриптов

Почему монолингвальные e5 проваливаются на retrieval? У e5-large и e5-large-v2 нет мультиязычных обучающих данных. Нелатинский текст маппится в узкую область пространства -- cosine между любыми двумя армянскими текстами высокий, но неинформативный.

3. armenian-text-embeddings-1: fine-tuning улучшает retrieval, но ломает alignment

Metric-AI/armenian-text-embeddings-1 -- это multilingual-e5-base, дообученный на ~250M токенов армянского текста (пары заголовок/тело с Reddit, переведённые на армянский через Gemma 2 27B). Это единственная пара "родитель-потомок" в бенчмарке, позволяющая напрямую измерить эффект fine-tuning.

Fine-tuning на армянском улучшил retrieval (MRR: #6 -> #3), но обрушил alignment по всем парам. Показательно: EN-RU alignment упал с 0,867 до 0,745 -- пара, не имеющая отношения к армянскому. Это классический catastrophic forgetting: дообучение на одном языке разрушает кроссязыковое выравнивание, выученное при мультиязычном предобучении.

4. Провал коммерческих API на армянском

Детальная разбивка для OpenAI:

• EN-RU: 0,544 (alignment) / 0,894 (R@1) -- дискриминация на EN-RU отличная

• EN-HY: 0,216 / 0,210 -- шум по обеим метрикам

• RU-HY: 0,267 / 0,210 -- шум по обеим метрикам

Примечательно: OpenAI набирает лучший в бенчмарке R@1 EN-RU (0,894), но проваливается на любой паре с армянским. Модель не обучалась на достаточном количестве армянского текста. Армянский алфавит -- не латиница и не кириллица, токенизатор разбивает армянские слова на множество мелких фрагментов, теряя семантику.

Cohere v4 (2025) vs v3 (2023): 0,472 vs 0,749 (alignment), 0,556 vs 0,731 (R@1) -- регрессия на нашей задаче по обеим метрикам. Обновление модели ухудшило поддержку малоресурсных языков.

5. Tokenizer fertility: почему коммерческие API проваливаются

Ключ к пониманию -- в токенизаторе. Мы токенизировали 5 параллельных EPG-заголовков (EN/RU/HY) двумя токенизаторами и усреднили результаты.

Мультиязычные токенизаторы (SentencePiece в e5/bge-m3, WordPiece в LaBSE -- оба с большим мультиязычным словарём):

• Средний HY/EN ratio: ~2x -- армянский лишь вдвое "дороже" английского

• Средний RU/EN ratio: ~1.6x

• Пример: ֆ/ֆ Արարատի գաղտնիքը -> 6 токенов (▁ֆ, /, ֆ, ▁Արարատի, ▁գաղտնի, քը)

OpenAI cl100k_base (byte-level BPE, используется в text-embedding-3-large):

• Средний HY/EN ratio: ~10x. Из 100 277 токенов словаря cl100k_base ни один не декодируется в UTF-8 строку с армянскими символами (U+0530-U+058F, лигатуры U+FB00-U+FB17). На нашей выборке армянский токенизируется строго побайтово (tok/byte = 1.00)

• Средний RU/EN ratio: ~2.9x

• Пример: ֆ/ֆ Արարատի գաղտնիքը -> 37 токенов = 37 UTF-8 байт, каждый токен -- 1 байт

Разница между токенизаторами -- в 5 раз (2x vs 10x). Rust et al. (2021) показали, что сильная переразбивка на субтокены (высокая fertility / over-segmentation) ухудшает качество, и токенизатор по важности сопоставим с объёмом обучающих данных. Мультиязычные SentencePiece/WordPiece-модели обучены на больших мультиязычных корпусах и содержат армянские субслова в словаре. В cl100k_base (OpenAI) армянских мержей нет -- текст разбивается побайтово (tok/byte = 1.00). Не все коммерческие API используют такой токенизатор: например, Jina v3 работает через XLM-RoBERTa и токенизирует армянский наравне с локальными моделями - что отражается на качестве: Jina v3 = 0,851, тогда как OpenAI text-embedding-3-large = 0,342 на той же метрике.

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

И ещё один аспект: коммерческие API тарифицируют по токенам. Армянский текст обходится в ~10x дороже английского -- вы платите больше за худшее качество.

6. Потребление памяти

Для продуктового деплоя важен не только с/текст, но и потребление RAM. В prod мы используем NVIDIA RTX 4000 Ada с 20GB VRAM.

Все перечисленные encoder-модели укладываются в 20 GB VRAM.

7. FlagEmbedding vs SentenceTransformers

Один и тот же чекпойнт BAAI/bge-m3 через разные бэкенды:

• SentenceTransformers (fp32): 13 мс/текст

• FlagEmbedding (fp16): 11 мс/текст (на 15% быстрее)

В нашем бенчмарке метрики качества совпали до округления (cross-lang 0,677, все подметрики идентичны). Часть ускорения объясняется fp16 -- сравнение не строго изолирует runtime от precision. Тем не менее при сопоставимом качестве FlagEmbedding -- практичный выбор для продакшна:

# SentenceTransformers (fp32): ~13 мс/текст from sentence_transformers import SentenceTransformer model = SentenceTransformer("BAAI/bge-m3") embeddings = model.encode(texts, normalize_embeddings=True) # FlagEmbedding (fp16): ~11 мс/текст -- тот же checkpoint, другой runtime + fp16 import numpy as np from FlagEmbedding import BGEM3FlagModel model = BGEM3FlagModel("BAAI/bge-m3", use_fp16=True) embeddings = model.encode(texts)["dense_vecs"] embeddings = embeddings / np.linalg.norm(embeddings, axis=1, keepdims=True)

8. Jina v3: task-адаптер решает всё

Jina v3 использует task-специфичные LoRA-адаптеры -- один и тот же чекпойнт jinaai/jina-embeddings-v3 даёт радикально разные результаты в зависимости от того, активирован ли адаптер.

В ранней версии бенчмарка API-бэкенд передавал task: "retrieval.passage", а локальный ST-бэкенд -- нет. Результат: 0,851 vs 0,705 (разница 0,146). Это был артефакт конфигурации, не баг модели.

После исправления (добавление prompt_name="retrieval.passage" в model.encode()) оба бэкенда используют один и тот же адаптер. Alignment-скор вырос с 0,705 до 0,811 (разрыв сократился с 0,146 до 0,040). Остаточная разница может быть связана с precision (fp32 vs API) и различиями в tokenization.

# API -- task передаётся в JSON payload payload = {"input": texts, "model": "jina-embeddings-v3", "task": "retrieval.passage"} # Локальный ST -- prompt_name активирует тот же LoRA-адаптер model = SentenceTransformer("jinaai/jina-embeddings-v3", trust_remote_code=True) embeddings = model.encode(texts, prompt_name="retrieval.passage")

Вывод: для моделей с task-адаптерами (Jina v3, и аналогичных) обязательно указывайте task/prompt_name -- иначе вы тестируете базовую модель без адаптера и получаете заниженные результаты.

9. Стабильность ранжирования

Ранговая корреляция между 7 рукописными триплетами и полным набором из 245 -- Spearman ρ = 0,80. Топ-2 (семейство multilingual-e5) стабильно, но в середине таблицы есть значимые перестановки: bge-m3 упал с 9-го на 16-е место, LaBSE -- с 5-го на 8-е. 7 примеров достаточно для грубого скрининга, но не для окончательных выводов.

Тест устойчивости к сокращениям

Отдельный эксперимент: 783 пары "чистое название" vs "сокращение + название":

"Тайна Арарата" --> embed_1 "к/ф Тайна Арарата" --> embed_2 score = cos(embed_1, embed_2)

Идеальная модель даёт 1.0 (сокращение не меняет вектор). Реальные результаты:

* Для монолингвальных моделей (e5-large, e5-large-v2) высокий балл -- артефакт: они маппят весь нелатинский текст в один плотный кластер, поэтому cos(текст, префикс+текст) ~ 1.0 тривиально. Их R@1 = 0,12-0,16.

Рис. 5. Устойчивость к сокращениям (RU и HY). Cosine между "Название" и "к/ф Название" -- идеал 1,0. Cohere v4 показывает худший результат (0,695).

Рекомендации

Для продакшна EN+RU+HY

Чего избегать

• e5-large-v2, e5-large -- монолингвальные ловушки: alignment 0,78/0,76, но R@1 = 0,16/0,12. Маппят нелатинский текст в один кластер

• all-MiniLM-L6-v2 -- только для английского (R@1 = 0,03)

• OpenAI text-embedding-3-large -- отличный EN-RU R@1 (0,894), но армянский на уровне шума (R@1 EN-HY = 0,210)

• Cohere embed-v4.0 -- регрессия vs v3 по обеим метрикам

Воспроизведство

pip install -r requirements.txt python benchmark.py --api st --model intfloat/multilingual-e5-base ./run_benchmark.sh # Полный прогон

Всё открыто: код, данные, результаты. MIT.

Выводы

1. Alignment != Retrieval. Рейтинги по alignment и retrieval перетасовываются: e5-large-v2 -- #5 по alignment, #17 по MRR; LaBSE -- #8 по alignment, #1 по MRR. Всегда измеряйте обе стороны.

2. Монолингвальные модели -- ловушка. e5-large и e5-large-v2 маппят нелатинский текст в один кластер: cosine высокий, но R@1 = 0,12-0,16. Красивая цифра alignment скрывает нулевую дискриминацию.

3. Лучшие бесплатные превосходят платные -- мультиязычные модели (LaBSE, multilingual-e5-large, armenian-text-embeddings-1, bge-m3) лидируют по retrieval. Jina API (MRR 0,791) конкурентоспособен. Флагманы OpenAI и Cohere v4 -- в хвосте по армянским парам.

4. Новее не значит лучше. Cohere v4 хуже v3 на армянском по обеим метрикам. Обновлённые версии моделей могут регрессировать.

5. Малая выборка достаточна только для грубого скрининга -- 7 триплетов дали ранговую корреляцию ρ = 0,80 с полным набором из 245. Для уверенности в середине таблицы нужен больший dataset.

6. Препроцессинг сокращений -- низко висящий фрукт. Раскрытие к/ф в "художественный фильм" перед эмбеддингом должно улучшить все модели.

7. Напишите статью о своём бенчмарке. При подготовке этого текста обнаружились пробелы в методологии: некорректное включение instruct-модели для симметричной задачи, расхождение API vs локальный запуск Jina из-за task-адаптера. Добавление R@1/MRR полностью перетасовало рейтинг и изменило рекомендации. Оформление результатов в статью -- дешёвый способ peer review до публикации.

Бенчмарк, датасет и код: https://github.com/s1mb1o/epg-embedding-benchmark. Лицензия MIT.

Разработано при создании рекомендательной системы для IPTV/OTT-платформы с мультиязычным EPG.