---
title: Эмбеддинги и Vector DB
description: "Как устроен семантический поиск: выбор эмбеддинг-модели, хранилища (Pinecone, Qdrant, Weaviate, Milvus, pgvector, Chroma) и свойства, которые сложно поменять позже."
---

## Что делает слой

Эмбеддинг-модель превращает фрагмент текста, картинки или кода в вектор — набор чисел, в котором близкие по смыслу объекты оказываются рядом. Векторная база хранит эти векторы и умеет быстро находить ближайшие. Это основа семантического поиска: запрос «как ограничить доступ к админке для роли» находит документ, где написано «права роли редактора», хотя общих слов в них нет.

Без этого слоя [RAG](https://wpcraft.ru/kb/ai/rag.md) превращается в поиск по ключевым словам, а модель — в генератор ответов по памяти.

## Сначала модель, потом база

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

На что смотреть:

- **Домен и язык.** Универсальная модель на русскоязычных регламентах или на коде ведёт себя иначе, чем на английском тексте из её обучения. Проверять надо на своих данных.
- **Размерность.** Больше — не значит точнее: 1024–1536 измерений обычно достаточно, а рост размерности увеличивает индекс и стоимость.
- **Длина входа.** Большинство моделей имеют лимит в 512–8192 токена; фрагмент длиннее лимита молча обрезается.
- **Согласованность.** Запрос и документы должны считаться одной моделью и одной версией. Смешать версии — типичная ошибка при обновлении.
- **Мультиязычность.** Если корпус двуязычный, нужна модель с поддержкой обоих языков, иначе просадка будет выглядеть как «модель тупит».

## Варианты хранилищ

| Решение | Когда подходит |
|---|---|
| **Pinecone** | Нужен полностью управляемый сервис и быстрый запуск без эксплуатации |
| **Qdrant, Weaviate** | Нужен self-hosted контроль, гибкая фильтрация и hybrid search |
| **Milvus / Zilliz** | Масштаб до миллиардов векторов, отдельная инфраструктурная команда |
| **pgvector** | Уже есть PostgreSQL и не хочется второй базы |
| **Chroma, LanceDB** | Прототип, локальная разработка, встраивание в приложение |

Практическое правило: **выбирайте не лучшую векторную базу, а ту, которую команда сможет эксплуатировать**. Отдельный кластер ради 50 тысяч чанков документации — обычно лишняя инфраструктура; `pgvector` рядом с рабочей базой закрывает тот же сценарий и упрощает бэкапы.

## Свойства, которые сложнее заменить потом

- **Hybrid search.** Векторы плюс ключевые слова. Чистый семантический поиск плохо находит точные идентификаторы: `wp_cache_get`, артикулы, коды ошибок, имена функций. Как это устроено — в разделе [Поиск и reranking](https://wpcraft.ru/kb/ai/rag/retrieval.md).
- **Фильтрация по метаданным.** Права, язык, версия документа, проект, дата. Фильтр после поиска по векторам деградирует: вы получаете «похожие, но недоступные» документы.
- **Multi-tenancy.** Изоляция данных между клиентами и проектами на уровне запроса, а не после выдачи.
- **Обновление и удаление.** Документы меняются; база должна уметь переиндексировать чанки, а не только добавлять.

## Схема работы

```text
документы → чанки → эмбеддинг-модель → векторы + метаданные → Vector DB
                                                     ↑
запрос → эмбеддинг той же модели → поиск top-K → фильтр → контекст для модели
```

Два условия корректности: **эмбеддинг-модель для запроса и для документов одна и та же**, а метаданные заполняются при индексации, не при запросе.

## Что проверить в проекте

- **Кто владеет индексом.** Если чанки строятся вручную и разово, через месяц база отстанет от документации.
- **Есть ли план переиндексации.** Смена модели эмбеддингов требует полного пересчёта — это часы и деньги, их стоит планировать.
- **Не хранится ли в векторах то, что нельзя.** Персональные данные и секреты в эмбеддингах — та же утечка, что и в тексте. Заодно проверьте, не восстанавливается ли исходный текст из вектора: для чувствительных полей это реальный риск.
- **Хватает ли фильтрации.** Разграничение доступа после поиска — источник утечек: недоступный документ уже попал в контекст модели.
- **Измеряется ли качество.** Промахи семантического поиска не видны глазу; без набора вопросов сравнить модели и параметры нечем.

## Связанные материалы

- [Чанкинг](https://wpcraft.ru/kb/ai/rag/chunking.md) — что именно превращается в векторы.
- [Поиск и reranking](https://wpcraft.ru/kb/ai/rag/retrieval.md) — как векторы используются вместе с ключевыми словами.
- [Курируемая база знаний](https://wpcraft.ru/kb/ai/rag/knowledge-bases.md) — когда индекс вообще не нужен.
- [Оценка качества](https://wpcraft.ru/kb/ai/agents/evaluation.md) — как измерить эффект смены модели.

## Материалы и источники

- [Системное мышление для агентного ИИ](https://wpcraft.ru/blog/systems-thinking-for-agentic-ai) — статья WPCraft, раздел «Vector DB»
- [MTEB: Massive Text Embedding Benchmark](https://huggingface.co/spaces/mteb/leaderboard) — сравнение эмбеддинг-моделей по задачам и языкам
- [pgvector](https://github.com/pgvector/pgvector) — векторный поиск внутри PostgreSQL
- [Qdrant: документация](https://qdrant.tech/documentation/) — гибридный поиск и фильтрация по метаданным