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

Например, посетитель пишет: «Когда привезут мою покупку?», а в справке нужный раздел называется «Сроки и способы доставки». Обычный поиск по словам может не увидеть связь. Смысловой поиск — может. Но только если модель достаточно хорошо сопоставляет именно такие формулировки.

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

Сначала выбирают модель, а не поставщика

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

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

Что меняет качество эмбеддингов

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

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

Экономика эмбединга

Цены внешних API за 1 млн входных токенов:

  • OpenAI, малая модель — $0.02;
  • OpenAI, большая модель — $0.13;
  • Cloudflare, bge-m3 — $0.012;
  • Voyage — от $0.02.

Для оценки возьмём фрагмент в 500 токенов. В измерении dzen_embedder на GTX 1080 обрабатывал около 248 фрагментов в секунду. При непрерывной работе это до 640 млн фрагментов, или около 320 млрд токенов в месяц. Это теоретический предел: длинные фрагменты и реальная смешанная нагрузка снижают скорость.

Такой объём за месяц обойдётся примерно в:

  • OpenAI, малая модель — $6,400;
  • OpenAI, большая модель — $41,800;
  • Cloudflare, bge-m3 — $3,900;
  • Voyage — от $6,400.

Вывод. Сервер с минимальным GPU за $100 в месяц может окупиться при стабильно высокой загрузке: даже теоретический предел стоит у внешнего API тысячи долларов в месяц. На практике расчёт нужно делать с учётом объёмов ваших данных и нагрузки. Локальную модель выбирают также ради безопасности: документы и запросы для эмбеддингов остаются внутри вашей инфраструктуры и не уходят внешнему провайдеру. Дополнительно можно выбрать модель, лучше понимающую язык и терминологию базы знаний.

Что делает dzen_embedder

dzen_embedder — самостоятельный сервис эмбеддингов для Dzen Chat. При запуске он загружает выбранную модель из Hugging Face и принимает запросы через OpenAI-совместимый endpoint /v1/embeddings. Подобрать кандидата помогает MTEB Leaderboard — публичная страница сравнения моделей эмбеддингов. Веб-приложение и фоновые задачи не загружают ещё по копии модели и не конкурируют за память одной видеокарты.

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

Ниже — измерение до первой ошибки при нагрузке от 1 до 64 параллельных соединений. Красный крест отмечает первый уровень с неуспешным ответом.

График пропускной способности на Apple M2 Max, GTX 1080 и CPU для интерактивной, фоновой и смешанной нагрузки
Нагрузка до точки отказа: интерактивные запросы, фоновая индексация и их сочетание.

Выводы: GPU и Apple Silicon прошли смешанную нагрузку до 64 соединений без ошибки; CPU дал первые два тайм-аута при 64 соединениях. Отдельный сервис с одной моделью позволяет сохранить приоритет запросов посетителей, пока фоновая индексация ждёт свободного времени.

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

Как начать использовать проект

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

Откройте репозиторий dzen_embedder на GitHub и следуйте инструкции. Либо скопируйте этот промпт в своего агента:

Read and follow the deployment instructions at:
https://raw.githubusercontent.com/dzenplatform/embedder/master/llm-setup.txt

Агент запросит доступ к серверу и развернёт сервис самостоятельно.

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

Удачного эмбединга!