Векторные базы данных

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

Как устроена векторная база

Текст или объект пропускается через модель-эмбеддер и превращается в вектор фиксированной размерности. Близость по смыслу — это близость векторов по выбранной метрике (косинус, евклид, скалярное произведение). Полный перебор работает на маленьких коллекциях и не работает на больших; поэтому в проде используют приближённый поиск ближайших соседей (ANN) — индексы HNSW, IVF, PQ. Они дают околомгновенный отклик ценой контролируемой погрешности.

Векторная и реляционная база данных — это разные задачи

Реляционная БД отвечает на точные вопросы и держит транзакции; векторная отвечает на «что похоже» и не подменяет первое. На практике они живут вместе: реляционная хранит сущности и связи, векторная — представления для поиска по смыслу. Метаданные (автор, дата, проект, доступ) часто хранятся в обеих, и именно по ним фильтруется выдача векторного поиска — иначе «похожее» легко окажется не из той коллекции, не той свежести или не для этого пользователя.

Где векторный поиск действительно работает

• RAG — извлечение релевантных фрагментов для подачи в модель. Здесь векторная база — один из шагов, а не вся RAG-система.
• Рекомендации и поиск похожих — товары, документы, заявки, обращения.
• Дедупликация и связывание — найти, что одно и то же написано разными словами.
• Кластеризация — группировка обращений, тегирование тем, диагностика «о чём вообще спрашивают».
• Антифрод и аномалии — то, что не похоже ни на что нормальное, выделяется именно на векторах.

Обзор популярных систем — инженерный взгляд

Из работающих в проде на рынке: Qdrant (Rust, фильтры по метаданным первого класса), Weaviate (модульные эмбеддеры, GraphQL), Milvus (масштаб, кластеризация), Chroma (минимум зависимостей, удобно для прототипов), pgvector (расширение PostgreSQL — векторы рядом с уже имеющимися данными), Faiss (библиотека от Meta, не сервер). Универсального «лучшего» нет: выбор определяется тем, что уже есть в вашей инфраструктуре, объёмом коллекций, типами фильтров и требованиями к развёртыванию. Часто корректный старт — pgvector рядом с существующим PostgreSQL; переход на специализированную базу — когда упёрлись в производительность или в типы запросов.

Частые ошибки

«Выбрать БД до выбора эмбеддингов» — самый дорогой шаг назад. Сначала качество модели-эмбеддера и схема метаданных, потом база. «Замерить косинус на не-нормированных векторах» — даёт случайный шум вместо смысла. «Игнорировать фильтры по метаданным» — выдача превращается в кашу, и никакой переранкер уже не помогает. «Считать, что векторная база = RAG» — самая частая стратегическая ошибка: она отвечает «что похоже», а RAG-система отвечает «что подать в модель, чтобы ответ был обоснован».

Как мы это делаем

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

Глубже по теме

• Архитектура RAG-системы: источники, индексация, переранжирование
• Как создать RAG-систему, которая не врёт в проде
• Локальная RAG-система: когда она оправдана, а когда нет
• RAG-системы — инженерный обзор