text-embedding-3-large или small: стоимость, качество поиска и выбор для RAG

При построении RAG или семантического поиска многие сталкиваются с одним и тем же вопросом:

Какой embedding-модель выбрать: text-embedding-3-large или более дешевую text-embedding-3-small?

Ответ не в том, что “large всегда лучше”, и не в том, что “small достаточно”.

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

В этой статье разберём, на что реально смотреть при выборе embedding-модели для реальных задач.

Сразу к сути: как выбрать?

Можно ориентироваться на эту таблицу:

Сценарий	Рекомендуемый старт	Почему
Корпоративный FAQ/база знаний	text-embedding-3-large	Качество поиска важнее всего
Многоязычный RAG	text-embedding-3-large	Стоит протестировать для неанглийских и кросс-языковых запросов
Чат-бот поддержки	large или small через A/B тест	Оценить цену ошибки
Внутренний поиск по инструментам	text-embedding-3-small	Приоритет — стоимость, допустимы ошибки
MVP / демо	text-embedding-3-small	Главное — быстро собрать рабочий прототип
Индексация огромных массивов	small или large с понижением размерности	Контроль затрат на хранение и поиск
Поиск по коду/техдокам	large + rerank	Важно и семантическое, и точное совпадение

Если запомнить только одну фразу:

Сначала small для базовой оценки, потом large — для проверки улучшений на реальных запросах.

Чем силён text-embedding-3-large?

text-embedding-3-large — это embedding-модель с более высокими возможностями.

По документации OpenAI, она по умолчанию выдаёт вектор размером 3072, принимает до 8192 токенов, и позиционируется как мощное решение для английских и неанглийских задач.

Её сильные стороны:

1. Более глубокое семантическое понимание
2. Лучше справляется со сложными запросами
3. Эффективнее для многоязычного и кросс-языкового поиска
4. Дружелюбнее к длинным документам
5. Хороший кандидат для продакшн-RAG

Но есть и минусы:

• Дороже за токен
• Вектор больше по размеру
• Дороже хранить векторную базу
• Больше нагрузка на память и индексацию при поиске

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

Когда подходит text-embedding-3-small?

text-embedding-3-small — это про эффективность и экономию.

Подходит для:

• Поиска по FAQ
• Небольших баз знаний
• MVP и прототипов
• Внутренних инструментов
• Одноязычных коллекций
• Сценариев, где ошибки поиска не критичны

Во многих случаях нет смысла сразу брать large.

Особенно если у вас ещё нет реальных пользовательских запросов, тестовой выборки и обратной связи — использование большой модели может казаться “надёжнее”, но вы не сможете доказать, что она реально лучше.

Стоимость — это не только цена API

Затраты на embedding — это не только вызовы модели.

В расчёт стоит брать:

Статья затрат	От чего зависит
Стоимость API	Количество токенов, частота переиндексации
Хранение векторов	Количество документов, чанков, размерность вектора
Задержка поиска	Размер индекса, размерность, top_k
Память/диск	Количество и точность векторов
Поддержка	Переиндексация, миграция версий, тестирование

Простой пример:

Если у вас 1 миллион чанков, каждый вектор — 3072 float32, то только на векторах:

1,000,000 × 3072 × 4 bytes ≈ 12.3 GB

Если уменьшить размерность до 1536 — будет примерно вдвое меньше.

И это без учёта индекса, метаданных и накладных расходов БД.

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

Как использовать параметр dimensions?

В embedding-моделях третьего поколения OpenAI можно управлять размером выходного вектора через параметр dimensions.

Пример:

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

response = client.embeddings.create(
    model="text-embedding-3-large",
    input="How to reduce AI API cost with model routing?",
    dimensions=1536,
    encoding_format="float"
)

vector = response.data[0].embedding
print(len(vector))

Это очень полезно в продакшне.

Можно сравнить:

• large 3072
• large 1536
• large 1024
• small (по умолчанию)

А потом посмотреть на Recall@5, задержку и стоимость.

Не ориентируйтесь только на MTEB

Публичные бенчмарки полезны, но не заменяют реальные данные.

Ваши задачи могут отличаться от тестовых наборов:

• Короткие пользовательские запросы
• Документы на смешанном русском и английском
• Много названий продуктов и кодов ошибок
• Таблицы и параметры в тексте
• Пользователи часто пишут разговорно

Лучше собрать свою небольшую тестовую выборку.

Простейший формат:

Запрос	Ожидаемый документ	Тип
Как посмотреть баланс?	billing.md	FAQ
Что указывать в base_url?	quickstart.md	technical
Как настроить Claude Code?	claude-code.md	integration
Что делать при ошибке 401?	auth-errors.md	troubleshooting

Прогоните каждый вариант модели и посмотрите, попадает ли нужный документ в топ-3/топ-5.

Как провести A/B тестирование моделей

Рекомендую такой подход:

1. Соберите 50-200 реальных запросов

Не придумывайте сами. Лучше взять:

• Логи поиска на сайте
• Вопросы в поддержку
• Вопросы из чатов/групп
• Заголовки тикетов
• Комментарии к документации

2. Проставьте правильные ответы

Для каждого запроса отметьте 1-3 релевантных чанка или документа.

3. Постройте несколько индексов

Например:

• index_small_default
• index_large_3072
• index_large_1536

4. Прогоните тесты на поиск

Ключевые метрики:

Метрика	Описание
Recall@3	Входит ли правильный документ в топ-3
Recall@5	Входит ли правильный документ в топ-5
MRR	Чем выше позиция правильного документа, тем лучше
latency	Время ответа на запрос
cost	Стоимость индекса и поиска

5. Решите, стоит ли переходить на large

Если прирост Recall@5 всего 1%, а расходы сильно выше — возможно, не стоит.

Если же Recall@5 вырос с 78% до 90%, а бизнесу критична точность — переход оправдан.

Плохой RAG — не всегда вина embedding-модели

Часто даже переход на large не спасает, если проблемы в другом:

Проблема	Проявление	Что делать
Плохо нарезаны чанки	Контекст найденного ответа неполный	Перерезать чанки
Нет метаданных	Нельзя фильтровать по языку/правам/продукту	Добавить метаданные
Слишком короткий запрос	“Проблема с оплатой” ищет плохо	Переписывать запросы
Устаревшие документы	Находятся старые ответы	Фильтровать по дате/версии
Нет rerank	Топ-результаты похожи, но не точные	Добавить rerank
Слабый prompt	Модель отвечает “из головы”	Жёстко ограничить ответы только по базе

Перед выбором модели убедитесь, что ваша RAG-пайплайн не слишком “сырая”.

Как переключаться между embedding-моделями через OpenAI-совместимый API

Если вы используете OpenAI SDK, сменить модель очень просто.

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

# Для экономии
small = client.embeddings.create(
    model="text-embedding-3-small",
    input="semantic search for AI documentation"
)

# Для качества
large = client.embeddings.create(
    model="text-embedding-3-large",
    input="semantic search for AI documentation"
)

Если вы используете OpenAI-совместимый шлюз вроде Crazyrouter, обычно менять нужно только имя модели и base URL.

Можно сначала проверить вызовы в Crazyrouter Playground, а затем перенести параметры на сервер.

Рекомендуемая дорожная карта проекта

Этап 1: MVP

• Используйте text-embedding-3-small
• Храните локально или через pgvector
• Поиск top 5
• Без сложного rerank
• Цель — рабочий прототип

Этап 2: Реальное тестирование

• Соберите пользовательские запросы
• Проставьте правильные документы
• Сравните small и large
• Подберите стратегию нарезки чанков
• Цель — найти узкие места поиска

Этап 3: Оптимизация для продакшна

• Используйте large или large с уменьшенной размерностью
• Добавьте гибридный поиск
• Включите rerank
• Фильтрация по правам
• Ссылки на источник
• Цель — стабильность, объяснимость, контроль затрат

Вывод: large — не всегда ответ, но тестировать стоит

text-embedding-3-large даёт более сильное семантическое представление, особенно полезен для сложных RAG, многоязычных баз и продвинутого поиска.

Но не стоит слепо брать самую мощную модель.

Лучше действовать так:

1. Сначала small — для оценки затрат и базового качества
2. Потом large — для проверки реального прироста на ваших данных
3. Управляйте размерностью через dimensions
4. Добавляйте rerank и гибридный поиск, а не только меняйте модель
5. Оценивайте, насколько критичны ошибки для бизнеса

Если RAG влияет на решения пользователей, поддержку или оплату — скорее всего, large оправдан.

Если это внутренний инструмент или ранний прототип — small практичнее.

FAQ

text-embedding-3-large всегда лучше, чем text-embedding-3-small?

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

Снижение dimensions ухудшает качество?

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

В RAG-проекте сначала оптимизировать модель или нарезку чанков?

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

Для многоязычных баз лучше large?

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

Можно ли вызывать text-embedding-3-large через Crazyrouter?

Да, через OpenAI-совместимый эндпоинт /v1/embeddings. Просто укажите https://crazyrouter.com/v1 как base URL в коде.