В RAG и семантическом поиске Embedding часто становится первым звеном, отданным на аутсорсинг: текст отправляется в облачный API, оттуда возвращается вектор, который записывается в векторную базу. Это быстро на старте, но с ростом объёма, ужесточением комплаенса или непредсказуемым счётом команды начинают искать альтернативы.

Обычно рассматривают три пути: облачный Embedding API, собственное развёртывание моделей с открытыми весами и встроенную векторизацию в векторной базе. Абсолютного превосходства нет; различия сосредоточены в размерности и языках, задержке, приватности, стоимости и эксплуатации.

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

Примечание: OpenAI, Azure, Cohere, Pinecone, Qdrant, Milvus, Weaviate, BAAI, Qwen и другие названия являются товарными знаками их правообладателей. Статья сравнивает технические подходы и не означает сотрудничества или авторизации; спецификации моделей и ограничения интерфейсов могут меняться по версиям, ориентируйтесь на официальную документацию.

1. Сначала разберём три пути

Облачный Embedding API. Сюда входят прямой доступ к вендору модели, модельные сервисы облачных платформ и OpenAI-совместимые шлюзы. Плюсы — не нужно обслуживать инфраструктуру, оплата по факту, быстрое переключение. Минусы — текст покидает вашу сеть, а расход растёт вместе с числом вызовов.

Модели с открытыми весами. Например, BGE-M3, Qwen3-Embedding, EmbeddingGemma, multilingual-e5 и семейство jina. Веса можно скачать и развернуть на своём сервере или в частном облаке. Плюс — данные не выходят за периметр; минус — нужны ресурсы для инференса и самостоятельная работа с версиями, масштабированием и мониторингом.

Встроенная векторизация в векторной базе. Сюда относятся integrated embedding в Pinecone, vectorizer в Weaviate, FastEmbed в Qdrant и embedding function в Milvus. При записи передаётся текст, а вектор создаёт база или вызываемая ею модель — меньше связующего кода. Но встроенная векторизация не обязательно означает локальный инференс: многие реализации по-прежнему обращаются к внешнему сервису модели. pgvector отвечает только за хранение и поиск и векторы не создаёт.

2. Размерность: больше не значит лучше

Размерность определяет выразительность, а также напрямую влияет на хранение и стоимость поиска. Типичные примеры: у OpenAI text-embedding-3-small по умолчанию 1536 измерений, у 3-large — 3072; у BGE-M3 — 1024; у Qwen3-Embedding версии 0.6B, 4B и 8B соответствуют 1024, 2560 и 4096 измерениям; у EmbeddingGemma по умолчанию 768 измерений с возможностью усечения до 512, 256 или 128. Это лишь примеры; сверяйтесь с официальной документацией.

Хранение можно грубо оценить: число векторов × размерность × число байт на одно число с плавающей точкой. Миллион векторов размерности 1024 в float32 занимает около 4 ГБ исходных данных; 3072 измерения — около 12 ГБ, ещё без индекса, реплик и метаданных.

# Оценка сырого объёма векторов без индекса, реплик и метаданных
chunks = 1_000_000
for dim in (768, 1024, 1536, 3072):
    gb = chunks * dim * 4 / 1024**3
    print(f"{dim} измерений: {gb:.1f} ГБ")

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

3. Языковое покрытие: китайский сценарий нужно тестировать отдельно

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

При выборе не ограничивайтесь рейтингами: соберите небольшую оценку на реальных вопросах пользователей, реальных фрагментах документов и трудных примерах (перефразирование, межъязыковые вопросы, пункты с номерами). Как минимум смотрите recall@k и MRR, а затем проверяйте, соответствует ли ранжирование здравому смыслу. Все эти модели подчёркивают многоязычность, но решают ваши данные.

Учитывайте и эффективность tokenizer. При одинаковом лимите 8192 токена китайский, английский и код вмещают разное число символов. Надёжнее оставлять запас при нарезке по токенам.

4. Задержка и пропускная способность: смотрите на p95, а не на среднее

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

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

Встроенная векторизация добавляет ещё одно звено вызова: и запись, и поиск ждут ответа модели. Она экономит сложность кода, но не обязательно задержку. Измеряйте пропускную способность загрузки и p95 запросов отдельно.

5. Приватность и комплаенс: куда уходит текст

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

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

Сам вектор тоже может раскрывать информацию. Embedding — не шифрование: злоумышленник может строить выводы по сходству. К меткам доступа, изоляции арендаторов и журналам обращений следует относиться так же серьёзно, как к исходному тексту.

6. Структура затрат: цена за единицу — лишь одна из статей

При сравнении не ограничивайтесь ценой за миллион токенов. Полная стоимость включает как минимум:

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

Стоимость пересчёта недооценивают чаще всего. Полный прогон может длиться часы или дни. Конкретные цены смотрите на странице тарифов; они меняются вместе с вендорами и версиями, поэтому цифры здесь не фиксируются.

7. Выбор пути по сценарию

Сценарий Приоритетный путь Причина Что учесть
Быстрая проверка небольшой командой Облачный API Не нужна эксплуатация, оплата по факту Фиксируйте имя модели, размерность и версию нарезки
Данные не должны выходить из периметра Собственное развёртывание открытой модели Текст остаётся в вашем VPC Оцените GPU, лицензию и резервное копирование
Уже используется векторная база и объём небольшой Встроенная векторизация Меньше связующего кода Уточните модель и регион запросов
Массовая офлайн-загрузка, чувствительность к цене Открытая модель или батч-облако Пакетная обработка снижает удельную стоимость Сначала оцените полноту поиска, потом масштабируйте
Многоязычная поддержка и трансграничная торговля Многоязычная облачная модель или класс BGE-M3 Широкое языковое покрытие Проверьте редкие языки на реальном корпусе
Чувствительность к задержке онлайн-поиска Облачный API рядом с пользователем или небольшая локальная модель Меньше сетевых обходов Смотрите p95, а не только среднее
Нужен гибридный плотный и разреженный поиск Открытая модель с несколькими выходами Один инференс даёт разные векторы Индекс и логика ранжирования сложнее

Таблица — только отправная точка. Реальный выбор зависит от инфраструктуры: если уже используется облако, сначала смотрите его модельные сервисы; если есть GPU-кластер, предельная стоимость собственного развёртывания ниже; если уже есть векторная база, встроенная векторизация экономит инженерное время.

8. Чек-лист миграции

  1. Зафиксируйте текущее состояние: имя модели, размерность, метрику расстояния, правила нарезки, параметры индекса и суточное число вызовов.
  2. Соберите набор оценки: несколько сотен реальных вопросов и правильных документов для регулярной регрессии.
  3. Выберите два-три кандидата и не меняйте слишком много переменных сразу.
  4. Сделайте малый поток с двойной записью: старые и новые векторы пишутся отдельно, запросы идут в новый индекс, различия в полноте фиксируются.
  5. Проверьте размерность, нормализацию и метрику расстояния: cosine, dot product и конфигурация индекса должны совпадать.
  6. Создайте новую коллекцию для полного пересчёта; не смешивайте векторы разной размерности в старом индексе.
  7. Переключайте трафик по процентам, сохраняя старый индекс и выключатель отката, и наблюдайте минимум один бизнес-цикл.
  8. Архивируйте версию модели, размерность, версию нарезки и дату пересчёта в словаре данных.

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

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

Можно ли полностью заменить Embedding API открытой моделью?

В большинстве сценариев да, особенно если данные чувствительны или объём вызовов стабилен. Но придётся самостоятельно поддерживать инференс, проводить оценку модели и отвечать за обновления версий. На этапе быстрой проверки облачный API проще.

Чем встроенная векторизация в векторной базе отличается от прямого вызова API?

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

Обязательно ли полностью пересчитывать векторы при смене модели?

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

Чем выше размерность, тем лучше качество?

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

Какой GPU нужен для собственного Embedding?

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

Что дальше

Если хочется сначала проверить эффект на облачном решении, создайте тестовый ключ в ZSQH AI Gateway, прогоните загрузку и запросы через OpenAI-совместимый интерфейс и затем решайте, нужно ли собственное развёртывание. Доступность моделей и цены смотрите на странице тарифов.

Читайте также: