Лучшая модель эмбеддингов для RAG - та, что побеждает на ваших данных

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

Через полгода появляются проблемы.

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

Изначальная модель, возможно, была неплохой. Незавершённым был процесс принятия решения.

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

Что на самом деле контролирует модель эмбеддингов

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

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

Загрузка документов - парсинг - чанкинг - эмбеддинг - индексация - поиск - реранкинг - генерация

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

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

Именно поэтому выбор эмбеддингов следует рассматривать как архитектурное решение, а не как подбор модели.

Почему публичные рейтинги полезны - и недостаточны

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

Рейтинг может ответить:

Какие модели заслуживают тестирования?

Он не может надёжно ответить:

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

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

Для RAG релевантная категория бенчмарка - обычно поиск. Даже тогда средний балл поиска может скрывать серьёзные слабости именно в тех типах запросов, которые важны для вашего бизнеса.

Что должно определять выбор модели

Качество поиска на вашем корпусе

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

Ваш оценочный набор должен включать несколько классов запросов:

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

Соответствие домену и языку

"Мультиязычность" - не бинарное свойство.

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

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

Qwen3 Embedding поддерживает более 100 языков и настраиваемые размерности до 4096. BGE-M3 поддерживает плотный, разреженный и мультивекторный поиск и обрабатывает входные данные до 8192 токенов. Snowflake Arctic Embed 2.0 спроектирован для мультиязычного поиска под лицензией Apache 2.0. Это полезные кандидаты в шортлист, а не автоматические победители. (Hugging Face)

Поведение при запросах и документах

Некоторые модели поддерживают отдельные режимы для запросов и документов или инструкции, специфичные для задачи.

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

Использование неправильного режима ввода может снизить качество поиска, даже если сама модель сильна.

Поэтому оценка должна воспроизводить точную продакшен-конфигурацию: правильный префикс или инструкцию запроса; правильный режим документа; одинаковую нормализацию; одинаковую выходную размерность; одинаковую метрику схожести.

Тестирование модели с настройками по умолчанию и развёртывание с другой конфигурацией обесценивает сравнение.

Размерности векторов и стоимость индекса

Большие векторы не обязательно лучше.

Они могут увеличить: объём хранения; память индекса; сетевой трафик; стоимость вычисления расстояний; размер резервных копий; время переиндексации.

Несколько управляемых моделей теперь поддерживают гибкие размерности. Модели эмбеддингов третьего поколения OpenAI по умолчанию используют 1536 и 3072 размерности, тогда как API может сокращать их вывод. Cohere Embed v4 поддерживает 256-1536 размерностей, а Voyage 4 поддерживает 256-2048. (OpenAI Platform)

Для миллиона float32-векторов разница в хранении существенна:

Эти цифры исключают векторный индекс, метаданные, реплики и резервные копии.

Правильный вопрос не:

Какая наибольшая доступная размерность?

Правильный вопрос:

При какой размерности дополнительное качество поиска перестаёт оправдывать дополнительные затраты на инфраструктуру?

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

Длина контекста и стратегия чанкинга

Большой лимит контекста полезен, но не устраняет необходимость проектирования документов.

Cohere Embed v4 поддерживает контекст 128K, Voyage 4 поддерживает 32K, а текущие модели эмбеддингов третьего поколения OpenAI принимают до 8192 токенов. (Документация Cohere)

Это не значит, что весь 100-страничный отчёт должен стать одним вектором.

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

Поэтому ваше тестирование должно оценивать комбинации модели и чанкинга:

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

Развёртывание, governance и лицензирование

Шортлист моделей должен меняться, когда система обрабатывает: конфиденциальные данные клиентов; регулируемые записи; интеллектуальную собственность; информацию с юрисдикционными ограничениями; документы с детализированными правами пользователей; нагрузки, которые должны оставаться on-premises.

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

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

Открытые веса также не гарантируют коммерческое разрешение. Jina Embeddings v5 Text Small, например, опубликована под CC BY-NC 4.0, тогда как BGE-M3 использует MIT, а Qwen3 Embedding - Apache 2.0. (Hugging Face)

Анализ лицензий должен произойти до того, как тестирование производительности перейдёт в продакшен-внедрение.

Миграция и устойчивость к смене поставщика

Пространства эмбеддингов специфичны для модели. Векторы, созданные несвязанными моделями, обычно нельзя сравнивать внутри одного индекса.

Смена моделей может потребовать: повторного эмбеддирования полного корпуса; создания второго индекса; синхронизации новых и обновлённых документов в оба индекса; запуска A/B-тестов поиска; миграции трафика; вывода старого индекса из эксплуатации.

Чем больше корпус и чем чаще он меняется, тем важнее становится стоимость миграции.

Семейство моделей четвёртого поколения Voyage необычно тем, что его варианты large, standard и lite производят совместимые эмбеддинги, что может снизить трение миграции между уровнями моделей внутри этого семейства. (Voyage AI)

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

Оценочная карта для моделей эмбеддингов

Модель должна оцениваться как часть полной операционной системы, а не изолированно.

Следующее распределение весов по умолчанию можно адаптировать под бизнес-кейс:

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

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

Как провести оценку

Определите операционную проблему

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

Без этого шага команда оценивает технологию, не определив, что считать успехом.

Создайте репрезентативный эталонный набор

Создайте примерно 100-300 проверенных вопросов для первоначальной оценки, ориентированной на продакшен.

Каждый вопрос должен содержать ожидаемый исходный документ; ожидаемый фрагмент доказательства; допустимые альтернативные фрагменты; категорию запроса; язык; сложность; является ли правильным результатом "доказательств не найдено".

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

Тестируйте намеренно короткий шортлист

Разумный шортлист может содержать одну недорогую управляемую модель; одну управляемую модель более высокого качества; один мультиязычный вариант; одну коммерчески допустимую модель с открытыми весами; одну гибридную конфигурацию поиска.

Текущие примеры включают OpenAI text-embedding-3-small и text-embedding-3-large, Voyage 4, Cohere Embed v4, BGE-M3, Qwen3 Embedding и Snowflake Arctic Embed 2.0. Их официальная документация показывает существенно различающиеся размерности, контекстные окна, модальности, лицензии и характеристики развёртывания. (OpenAI Platform)

Шортлист должен оставаться достаточно коротким для полноценной оценки.

Измерьте качество и операционные затраты

Как минимум, зафиксируйте:

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

Проведите сквозной приёмочный тест

Метрики поиска необходимы, но недостаточны.

Подключите выбранные конфигурации поиска к предполагаемым: векторной базе данных; фильтрам; реранкеру; промпту; LLM; уровню контроля доступа.

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

This end-to-end validation follows the same principles we describe in our guide to evaluating AI agents before production -task-level success, trace inspection, policy compliance, and economics should all be measured before committing to full-corpus indexing.

Какой класс моделей подходит для какой ситуации?

Cohere Embed v4 поддерживает текст, изображения и смешанный PDF-контент. BGE-M3 может создавать плотные, разреженные и мультивекторные представления в одной модели. Эти возможности ценны, только когда существует соответствующая задача поиска. (Документация Cohere)

Где ошибаются проекты по выбору

Выбор наивысшего балла в рейтинге

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

Выбор только по цене API

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

Выбор по контекстному окну

Поддержка длинного ввода не доказывает точного поиска из длинных документов.

Предположение, что open source означает бесплатную эксплуатацию

Счёт за API исчезает, но мощности GPU, развёртывание, мониторинг, обновления и инженерный труд остаются.

Тестирование моделей с разными пайплайнами

Изменение размера чанка, реранкера или top-K одновременно с моделью делает невозможным определение причины улучшения.

Игнорирование случая отсутствия ответа

Система, которая всегда что-то извлекает, в конечном итоге представит нерелевантные доказательства как подтверждение.

Откладывание контроля доступа как более поздней функции

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

Что решить до выбора модели

Не начинайте с вопроса:

Какую модель эмбеддингов нам использовать?

Начните с вопроса:

Какие доказательства должна извлекать эта система, для кого, при каких ограничениях и что происходит, если извлечение неверно?

Когда на эти вопросы получены ответы, шортлист моделей становится короче, а оценка - измеримой.

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

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

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