Главная / Статьи / Как выбрать модель эмбеддингов для RAG: цена перехода важнее цены

Как выбрать модель эмбеддингов для RAG: цена перехода важнее цены

Сравнение моделей эмбеддингов OpenAI, Cohere и локальных моделей для продакшен-RAG: почему ежемесячные расходы почти не важны, а выбор решает стоимость перестройки индекса.

1624 слов

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

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

Три оси, которые обычно взвешивают наоборот

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

  • Качество поиска бенчмаркают первым. Его публично измеряют на MTEB, и разница реальна, но разброс среди лидеров гораздо меньше, чем намекает маркетинг.
  • Стоимость попадает в презентацию. Её обычно указывают за миллион токенов, и из-за этого она выглядит главной переменной. Это не так, что и показывают цифры ниже.
  • Эксплуатационную сторону почти никогда не оценивают. Кто запускает модель? Что будет, когда провайдер её выведет из обращения? Сколько занимает полная перестройка индекса? Сможет ли модель вообще работать, если комплаенс потребует, чтобы документы не покидали сеть?

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

Сколько на самом деле стоят эмбеддинги

Цена задаёт точку отсчёта для всего, так что начнём с неё. text-embedding-3-small от OpenAI стоит $0.02 за миллион токенов, что делает её одним из самых экономичных облачных вариантов в 2026 году.

Теперь применим это к реалистичной нагрузке. Возьмём корпус в сто миллионов токенов — это по-настоящему большая внутренняя база знаний — и проиндексируем его целиком:

corpus_tokens      = 100_000_000
price_per_million  = 0.02            # text-embedding-3-small
index_build_cost   = corpus_tokens / 1_000_000 * price_per_million
# 2.0

Два доллара. Это весь счёт за API, чтобы один раз построить эмбеддинги для корпуса в сто миллионов токенов.

Со стороны запросов картина похожая. При пятистах тысячах запросов в месяц на text-embedding-3-small эмбеддинги запросов обходятся примерно в $3.25 в месяц. На фоне счёта за инференс, счёта за векторное хранилище и одного рабочего вечера инженера это шум.

А что с более крупной text-embedding-3-large? Она дороже за токен и выше на публичных бенчмарках. Честное правило, когда к ней обращаться: только после того, как вы измерили провал поиска, который исправили бы более качественные эмбеддинги. Если верхний результат неверен из-за плохо нарезанных чанков или потому, что запросы не похожи на документы с точки зрения косинусного сходства, более сильный энкодер не поможет. Он лишь сделает неверный результат поиска чуть увереннее.

То же рассуждение применимо к вопросу старой ada-002 против 3-small. 3-small дешевле и в целом сильнее, так что для проекта с нуля ответ прост. Если индекс уже построен, цена вообще не играет роли — почему, объясняет раздел о миграции ниже.

OpenAI против Cohere

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

Cohere позиционировала Embed v3 как модель для многоязычного поиска и релевантности, а не как самый дешёвый энкодер общего назначения. Для по-настоящему многоязычного корпуса, особенно когда пользователи спрашивают на одном языке, а документы написаны на другом, именно эту ось и стоит проверять на собственных данных, а не доверять лидерборду. Межъязыковой поиск — то место, где выбор модели всё ещё меняет то, что видят пользователи, потому что модель, которая плохо с ним справляется, не деградирует плавно. Она возвращает уверенно нерелевантные документы.

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

Локальные модели меняют сам вопрос

Одна цифра меняет картину: локальные модели эмбеддингов вроде Nomic Embed и BGE отстают от text-embedding-3-large на MTEB не более чем на пять процентов и при большом объёме снижают стоимость за токен до нуля.

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

Поэтому локальный запуск модели — не про экономию. Счёт за облачный API и так был крошечным, а самостоятельный хостинг модели в стиле sentence-transformers на своей GPU тоже стоит денег: инстанс, деплой и тот, кто дежурит по нему в три часа ночи.

Самостоятельный хостинг выигрывает по трём пунктам, и все они эксплуатационные:

  1. Резидентность данных. Если документы не могут покидать вашу инфраструктуру, спор окончен, и открытым остаётся лишь вопрос, какую локальную модель выбрать.
  2. Предсказуемая пропускная способность. Запросы ограничены только выбранными вами настройками, и не нужно прогнозировать счёт по тарифу. Конвейер, который перестраивает индекс круглосуточно, выигрывает от этой стабильности больше, чем от отказа от платы за токены.
  3. Контроль над собственным векторным пространством — то, что важнее всего и обсуждается меньше всего.

Настоящая цена перехода

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

Значит, замена модели означает перестройку всего индекса. Здесь привычная подача стоимости вводит в заблуждение. За повторное построение эмбеддингов большого корпуса называют пугающие суммы, но при реальных ценах за токены доля API невелика. Возьмём сто миллионов токенов по $0.02 за миллион: это два доллара, и даже модель в десять раз дороже оставит итог в пределах пары сотен.

Настоящая стоимость — не строка в бюджете токенов. Это всё, что вокруг неё:

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

Вот в чём ловушка. Она приходит не неожиданным счётом. Она приходит неожиданным проектом.

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

Краткое руководство по выбору

  • Английский корпус, новая система: text-embedding-3-small. Это самый дешёвый достойный старт, и при реальных объёмах его стоимость пренебрежимо мала.
  • Измеренные провалы поиска, которые исправил бы более сильный энкодер: text-embedding-3-large, но только при наличии доказательств.
  • Многоязычный или межъязыковой поиск: Cohere Embed v3 с проверкой на собственных данных, ведь здесь выбор модели всё ещё заметен в пользовательском опыте.
  • Документы, которые не могут покидать сеть: самостоятельно размещённые Nomic Embed или BGE. Здесь решает комплаенс, а не стоимость.
  • Очень большой объём непрерывной переиндексации: локальная модель, которая убирает из архитектуры лимиты запросов и оплату за каждый запрос.

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

Частые вопросы

Какая модель эмбеддингов самая дешёвая в 2026 году? Среди облачных вариантов text-embedding-3-small за $0.02 за миллион токенов находится почти в самом низу по цене, оставаясь достойной. У локальных вариантов вроде Nomic Embed и BGE платы за токен нет вовсе, но вы платите железом и сопровождением. В любом случае суммы настолько малы, что для большинства команд цена не должна решать вопрос.

Брать эмбеддинги у OpenAI или у Cohere? Для нагрузок только на английском решайте по эксплуатационным соображениям, ведь продукт будет ограничивать не разница в качестве. Для многоязычных или межъязыковых нагрузок соберите оценочный набор на реальных языках и проверьте обе, потому что именно здесь пользователи видят разницу.

Сколько стоит повторно построить эмбеддинги большого корпуса? В плате за API — меньше, чем думает большинство: около двух долларов за сто миллионов токенов по $0.02 за миллион. Больно бьёт работа вокруг: повторное извлечение и нарезка каждого документа, поддержка двух индексов на время переключения и повтор всех оценок поиска в новом векторном пространстве. Планируйте в неделях, а не в токенах.

Вывод: сравнивайте модели, но сэкономленную тревогу потратьте на путь миграции, а не на прайс-лист. Выбор модели — решение меньше, чем кажется. Индекс, построенный вокруг неё, — решение куда крупнее.