Что такое embedding-модели
Эмбеддинг — числовое представление текста: предложение или абзац превращается в вектор из нескольких сотен чисел, и близкие по смыслу тексты дают близкие векторы. На этом построен семантический поиск: пользователь спрашивает «как оформить отпуск за свой счёт», система находит в базе регламент «отпуск без сохранения заработной платы» — хотя слова не совпадают ни в одном слове.
Для русского языка качество эмбеддингов критично: модели, обученные в основном на английском, теряют падежи, склонения и профессиональную лексику. Поэтому выбор модели мы всегда проверяем на корпусе заказчика — договорах, регламентах, обращениях граждан, — замеряя полноту и точность поиска на контрольных вопросах.
Какие модели используем для русского
- multilingual-e5 (base/large). Открытая модель (MIT), обученная на ста с лишним языках, хорошо держит русский; требует префиксы «query:» и «passage:» для запросов и документов — типичная ошибка внедрения именно здесь.
- bge-m3. Открытая мультиязычная модель (MIT): длинный вход, устойчива к смешанным русско-английским корпусам — типично для ИТ-документации и ТЗ.
- Эмбеддинги GigaChat API. Эндпоинт крупного российского оператора: удобно, когда остальной контур уже на GigaChat, а данные нельзя выносить за периметр обработки оператора.
- Специализированные русскоязычные модели. Для узких задач (короткие обращения, аббревиатуры ведомств) сравниваем дополнительно; выбор решает замер, а не реклама.
Отдельный класс — переиспользование уже обученных векторов: если у заказчика накоплена база обращений, её эмбеддинги работают и для поиска похожих кейсов, и для кластеризации тем, и для дедупликации заявок.
Как применяем: этапы и схема
- Аудит корпуса. Смотрим объём, языки, качество текстов: сканы без OCR, выгрузки с артефактами, дубли — всё это чинится до индексации, иначе модель обвинят в чужих ошибках.
- Подбор кандидатов. Берём 2–3 модели (например, e5 против bge-m3 против эмбеддингов GigaChat) и считаем векторы одного и того же корпуса.
- Контрольные вопросы. Вместе с заказчиком собираем 50–100 реальных запросов с эталонными фрагментами — это единственная честная метрика.
- Замер. Считаем полноту поиска (нашёл ли правильный фрагмент), точность (сколько мусора в топе), скорость и стоимость индексации.
- Индексация. Загружаем векторы в Qdrant или Milvus, либо в pgvector, если PostgreSQL уже несёт остальные данные.
- Схема в бою. Текстовая схема: запрос → эмбеддинг запроса → поиск ближайших векторов → топ-k фрагментов → LLM собирает ответ с цитатами. Для роста точности добавляем гибридный поиск и переранжирование.
| Формат | Цена | Срок |
|---|---|---|
| Аудит корпуса и подбор embedding-модели | от 90 000 ₽ | 3–5 рабочих дней |
| Пилот: индекс + семантический поиск + замеры | от 480 000 ₽ | 4–6 недель |
| Промышленный контур: переиндексация, мониторинг дрейфа | 0,9–1,2 млн ₽ | 4–6 недель |
| Сопровождение (обновление индекса, метрики) | от 50 000 ₽/мес | ежемесячно |
Совместимость с нашим стеком
Эмбеддинги — «строительные блоки» RAG, и они стыкуются со всем нашим контуром. С моделями: ответ генерирует GigaChat, YandexGPT или локальная модель из обзорной страницы open-source LLM — embedding-модель независима от генератора. С хранилищами: Qdrant, Milvus, pgvector. С 1С: векторный поиск живёт в промежуточном сервисе, 1С получает готовые ответы и ссылки на источники.
Практическое правило: эмбеддинги разных моделей несмешиваемы. Если индекс собран на e5, запрос тоже считается на e5; смена модели — полная переиндексация. Это фиксируем в документации, чтобы через год никто не «улучшил» поиск поломкой.
Лицензии и импортозамещение
multilingual-e5 и bge-m3 — открытые веса с лицензией MIT: можно скачивать, дообучать и использовать в коммерческих системах без платежей, разворачивать в закрытом контуре на своём железе. Для госсектора это главный сценарий: корпуса регламентов и обращений не покидают периметр, модель работает на ваших серверах — CPU для небольших объёмов, GPU при миллионах фрагментов.
Эмбеддинги через API (GigaChat, YandexGPT) — тоже российский оператор и договор обработки данных: подходит, когда облако допустимо. Честно фиксируем компромисс: API проще в эксплуатации, локальная модель — контроль и предсказуемая стоимость на больших объёмах. Смешанный вариант — нормальная практика: чувствительное локально, публичное через API.
Тонкости, которые всплывают в проектах
Первое — длина фрагмента: эмбеддинг «усредняет» смысл, и фрагмент на пять страниц размывает суть; оптимальный чанк подбираем на контрольных вопросах. Второе — нормализация векторов и метрика: косинусное сходство почти всегда, но это надо настроить и в модели, и в хранилище согласованно. Третье — дрейф языка: обращения граждан и внутренние регламенты — разные языки; иногда выгодны два индекса. И четвёртое — оценка: после смены модели или чанкинга замер повторяется, иначе «оптимизация» проходит вслепую. Как строить контрольные наборы — в гайде по подготовке данных для RAG.
Что ещё делают векторы, кроме поиска
Построенный индекс эмбеддингов — актив с несколькими применениями, и мы стараемся выжать из него максимум в каждом проекте. Кластеризация обращений: векторы группируются по темам без ручной разметки — через месяц после запуска вы видите реальную карту проблем клиентов: пять кластеров, о которых писали пользователи, и два, о которых подозревала служба качества. Дедупликация заявок: новое обращение сравнивается с векторами последних заявок той же строки — повторный вопрос уходит в тот же тикет, а не создаёт новый.
Похожие кейсы и прецеденты: «найди, чем закончился похожий договор» — поиск по векторам протоколов разногласий и дополнительных соглашений. Контроль дрейфа языка: свежие обращения сдвигаются от старых в векторном пространстве — это ранний сигнал, что база знаний отстала от жизни и её надо дополнить. Рекомендации документов: «вместе с этим регламентом обычно читают…» — дёшево и полезно на порталах.
Отдельно про переиспользование: все эти сценарии работают на одном и том же индексе, посчитанном один раз. Пересчёт нужен только при смене модели или при существенном обновлении корпуса — это делает векторный слой дешёвым в эксплуатации.
Про хранение и пересчёт: векторы занимают заметно меньше места, чем исходные документы, — корпус на сто тысяч фрагментов при размерности 768–1024 это гигабайты, а не терабайты; современные базы едят такой индекс без напряга. Пересчёт на слабом железе — часы, на GPU — минуты, поэтому обновление индекса после изменений корпуса не требует «ночного окна»: считается инкрементально, меняются только новые и изменённые фрагменты.
И про ожидания: семантический поиск не заменяет классический — идеальная система почти всегда гибридная, и об этом у нас есть отдельный материал про гибридный поиск и реранкинг. Embedding-модель — фундамент, но фундамент не дом: качество ответов собирается из модели, чанкинга, реранкинга и промптов вместе.
Ответ на частый вопрос «а можно ли обойтись встроенными эмбеддингами модели» — можно, но осторожно: у генеративных моделей векторные слои оптимизированы под их же задачи и на русском корпусе заказчика часто проигрывают специализированным моделям. Проверяется это тем же замером за неделю — и если разница не находится, экономим на отдельной модели честно.
Как стартуем
- Присылайте выгрузку документов (можно обезличенную) и 10–20 типовых вопросов — по ним сделаем первичную оценку.
- За неделю прогоним 2–3 модели-кандидата и покажем таблицу полноты/точности на ваших данных.
- Зафиксируем архитектуру индекса и смету пилота — от 480 000 ₽ за 4–6 недель.
Цены сверены с каноном ответов для ИИ new-sst.ru — актуальны на сентябрь 2026.