Почти у любого крупного цифрового сервиса есть база данных, где хранятся сведения о клиентах, контенте, платежах и других доступных объектах. Например, база онлайн-кинотеатра позволяет найти фильм по идентификатору, отобрать картины определенного жанра или показать все подписки конкретного пользователя. То есть если системе заранее известно, по какому признаку искать, обычная СУБД вроде PostgreSQL или MySQL быстро и точно выполнит запрос.
Однако в реальности поиск в базе данных не всегда строится на заранее известных значениях. Так, вместо названия, жанра или имени актера пользователь может просто описать желаемый сюжет или настроение — к примеру, ввести «легкая комедия о программистах» или «вдохновляющая драма о спортсмене, который преодолевает трудности». В такой ситуации поиск по ключевым словам может не найти подходящий фильм или ранжировать его ниже менее релевантных результатов. Чтобы этого избежать, важно искать не по совпадению слов, а по смыслу — и для этого нужны векторные базы данных.
В этой статье мы разберемся, как устроены векторные базы данных и как они работают. Затем рассмотрим Chroma, Qdrant, FAISS, pgvector и другие популярные решения — выясним, для каких задач они лучше всего подходят. А в конце немного попрактикуемся и соберем поиск на Python с помощью Chroma.
Что такое векторная база данных и как она работает
Начнем с определения: векторная база данных — это система, которая хранит векторы и позволяет находить объекты, близкие друг к другу по смыслу или другим признакам. Под вектором здесь понимается эмбеддинг — числовое представление текста, изображения, аудиозаписи или другого объекта, созданное специальной моделью. Вместе с таким представлением в базе обычно хранится идентификатор объекта, исходные данные или ссылка на них, а также всевозможные метаданные — например, категорию, дату создания или автора.
Звучит тяжеловато, поэтому давайте рассмотрим принцип работы на примере онлайн-кинотеатра, о котором мы говорили во введении. Мы допустили, что пользователь может ввести в свободной форме запрос «вдохновляющая драма о спортсмене, который преодолевает трудности». Чтобы найти подходящие картины, система должна сопоставить смысл запроса с описаниями фильмов и затем определить, какие из них ближе всего к пожеланию зрителя.
Если упростить, весь процесс можно разбить на пять основных этапов:
- Подготовка данных. На первом шаге модель эмбеддингов превращает описания фильмов в векторы — наборы чисел, которые кодируют смысл текста. За счет этого фильмы о соревнованиях, тренировках и воле к победе оказываются ближе друг к другу, чем, скажем, к детективам. Подробно о том, как текст превращается в числа, мы писали в статье про эмбеддинги.
- Сохранение векторов. После этого векторы сохраняются в базе вместе с идентификаторами и метаданными — жанром, годом выпуска, возрастным рейтингом и другими параметрами. Так система связывает найденный вектор с конкретным фильмом и при необходимости может фильтровать результаты.
- Преобразование запроса. Когда зритель описывает, что хочет посмотреть, та же модель эмбеддингов превращает введенную фразу в вектор. В результате пожелание пользователя и описания фильмов оказываются в одном векторном пространстве — на своеобразной карте, где близкие по смыслу тексты располагаются рядом. В нашем случае получившийся вектор будет ближе к спортивным драмам вроде «Рокки», «Тренера Картера», «Воина» и «Крида», чем к детективам, ужасам или семейным комедиям.
- Поиск ближайших векторов. На предыдущем шаге пожелание зрителя было преобразовано в вектор. Теперь база может сравнить его с сохраненными векторами и определить, какие из них ближе всего по смыслу. Для этого используются разные меры близости или расстояния — чаще всего косинусное сходство, евклидово расстояние или скалярное произведение. А если в хранилище находятся миллионы векторов, сравнивать запрос с каждой записью слишком долго. Поэтому поиск ускоряют с помощью специальных индексов (HNSW, IVF и других), которые сильно сужают область поиска.
- Формирование выдачи. На последнем этапе база данных возвращает заданное количество ближайших записей вместе с их идентификаторами, метаданными и показателями близости. По идентификаторам система получает названия, постеры и другие записанные сведения о фильмах, а затем располагает наиболее релевантные варианты выше остальных. Поэтому выше окажутся спортивные драмы о тренировках, соревнованиях и трудностях — даже если в их описаниях нет слов из введенной фразы.
Мы по пунктам рассмотрели общий принцип работы векторных баз данных. Однако реализовать хранение и поиск векторов можно по-разному: с помощью отдельной библиотеки, расширения для обычной СУБД, специализированной базы или облачного сервиса. В следующем разделе мы разберемся, чем отличаются эти подходы и для каких задач лучше всего подходит каждый из них.
Какие бывают решения для векторного поиска и что выбрать
Сразу оговоримся: универсально лучшего варианта не существует. Выбор подходящего инструмента зависит от объема и размерности векторов, частоты запросов и обновлений, требований к задержке и качеству поиска, поддержки фильтров и гибридного поиска, технологического стека, способа развертывания, бюджета и множества других параметров. Ниже мы собрали несколько популярных сценариев и решения, с которых обычно начинают в каждом из них.
Эксперимент или локальный прототип. Если вы хотите исследовать алгоритмы поиска, работать с векторами внутри Python- или C++-приложения и вручную управлять индексом, то можно выбрать FAISS. Это библиотека для точного и приближенного поиска по плотным векторам, которая поддерживает разные типы индексов и может ускорять вычисления на GPU. Однако важно учитывать, что FAISS — не готовая база данных. Это означает, что хранение исходных объектов и метаданных, сетевой API, контроль доступа, бэкапы и отказоустойчивость сервиса вам придется организовать самостоятельно.
Если для проекта нужен не только поисковый индекс, но и полноценная система для работы с данными, то удобнее использовать Chroma. Она хранит документы, метаданные и эмбеддинги, поддерживает фильтрацию и поиск по содержимому. Chroma вы можете запустить локально, развернуть в клиент-серверном режиме или подключить как облачный сервис. Поэтому она хорошо подходит для обучения, прототипирования и сборки несложных AI‑приложений.
Векторный поиск внутри системы. Если проект уже работает на PostgreSQL и вы не хотите добавлять в архитектуру отдельный сервис, установите расширение pgvector. Оно добавляет в Postgres векторный тип данных и операции для сравнения векторов, поддерживает точный поиск и индексы HNSW и IVFFlat. В результате эмбеддинги можно хранить вместе с остальными данными и использовать для них привычные SQL-запросы, транзакции и фильтры.
Такой подход особенно удобен в случаях, когда векторный поиск — лишь одна из функций продукта, а результаты нужно отбирать с учетом других данных из базы. Например, в корпоративной базе можно искать документы по смыслу и одновременно ограничивать выдачу по отделу или правам доступа пользователя.
Отдельная векторная база. Если векторный поиск становится одной из главных функций продукта, имеет смысл вынести его в специализированную базу данных. В отличие от библиотеки FAISS или расширения pgvector, такая система работает как отдельный сервис: хранит векторы и метаданные, предоставляет API, поддерживает фильтрацию, индексы и разные варианты масштабирования.
Среди распространенных решений рекомендуем обратить внимание на Qdrant — базу с развитой фильтрацией и поддержкой гибридного поиска, Weaviate — систему, объединяющую векторный и полнотекстовый поиск, а также Milvus — мощную базу с локальным, односерверным и распределенным режимами работы.
Управляемый облачный сервис. Если команда не хочет самостоятельно разворачивать инфраструктуру для поиска, можно выбрать готовую облачную векторную базу. В этом случае провайдер берет на себя серверы, обновления, масштабирование и доступность системы, а разработчикам остается загружать данные и выполнять запросы через API. Такой подход ускоряет запуск проекта, но требует оплаты по тарифам провайдера и может ограничивать объем доступных ресурсов, размещение данных и сценарии использования базы.
Один из самых известных управляемых сервисов — Pinecone. Он поддерживает плотные и разреженные векторы, фильтрацию по метаданным и гибридный поиск. Кроме того, у Chroma, Qdrant и Weaviate также есть свои облачные версии, а управляемая версия Milvus доступна на платформе Zilliz Cloud.
Чтобы вам было проще сравнить рассмотренные варианты, соберем их основные особенности в таблице:
| Инструмент | Как запускается | Когда выбрать | Что учитывать |
| FAISS | Внутри Python- или C++-приложения, на CPU или GPU | Для экспериментов с алгоритмами, офлайн-поиска и ручного управления индексами | Это не готовая база: хранение данных, API и резервное копирование нужно организовать самостоятельно |
| Chroma | Локально, как отдельный сервер или в Chroma Cloud | Для изучения векторного поиска, создания прототипов и разработки несложных AI-приложений | Перед запуском в продакшене нужно проверить требования к нагрузке, безопасности и масштабированию |
| pgvector | Как расширение для существующей или новой базы PostgreSQL | Когда проект уже использует PostgreSQL, а векторный поиск нужно сочетать с обычными данными, SQL-запросами и фильтрами | Векторный поиск использует ресурсы той же базы, поэтому при больших объемах данных важно заранее протестировать нагрузку |
| Qdrant | На своих серверах или в Qdrant Cloud | Для отдельного сервиса векторного поиска с фильтрацией по метаданным и поддержкой гибридных запросов | При самостоятельном размещении нужно обслуживать отдельный сервис |
| Weaviate | На собственной инфраструктуре или в Weaviate Cloud | Когда в одном решении нужны векторный и полнотекстовый поиск, фильтры и интеграции с моделями | Нужно настроить схему данных, параметры поиска и инфраструктуру |
| Milvus | В режимах Lite, Standalone и Distributed или в Zilliz Cloud | Для работы с крупными коллекциями и масштабирования поиска до распределенной системы | Распределенный режим сложнее разворачивать и обслуживать |
| Pinecone | Как управляемый сервис через облачный API | Когда важно быстро запустить векторный поиск без самостоятельного обслуживания инфраструктуры | Нужно учитывать тарифы, лимиты, расположение данных и зависимость от провайдера |
Практика: создаем семантический поиск с Chroma на Python
Чтобы лучше понять, как работают векторные базы данных, в этом разделе мы соберем небольшой семантический поиск по каталогу онлайн-кинотеатра. Работать это будет так: предполагаемый пользователь своими словами описывает сюжет, а система находит фильмы с наиболее близкими по смыслу описаниями.
Поскольку мы будем реализовывать учебный проект, для хранения и поиска данных подойдет база Chroma — она может работать локально и хранить в одной коллекции векторы, исходные тексты и метаданные. А чтобы не тратить время на настройку рабочего окружения, весь код мы выполним в бесплатном сервисе Google Colab, где достаточно зарегистрироваться и создать новый блокнот.
Шаг 1. Устанавливаем зависимости и готовим данные
Для работы нам понадобятся две библиотеки: Chroma и sentence-transformers. Chroma будет отвечать за хранение данных и поиск по ним, а sentence-transformers — за загрузку модели и создание эмбеддингов. Вставьте следующую команду в первую ячейку Google Colab и нажмите кнопку запуска:
!pip install -q chromadb sentence-transformers
Теперь подготовим небольшой каталог из шести фильмов. Для каждого сохраним описание, уникальный идентификатор и основные метаданные — название, жанр и год выхода. Конечно, в реальном онлайн-кинотеатре набор полей был бы шире: можно указать возрастное ограничение, страну, режиссера, доступность по подписке и другие параметры. Для учебного проекта ограничимся минимальным набором, которого достаточно, чтобы позднее показать фильтрацию результатов.
Вставьте следующий код в новую ячейку Google Colab и запустите ее:
documents = [ "Малоизвестный боксер получает шанс выйти на ринг против чемпиона и начинает изнурительные тренировки, чтобы доказать, что способен выдержать бой.", "Тренер школьной баскетбольной команды требует от игроков не только побед на площадке, но и дисциплины, хорошей учебы и ответственности.", "Два брата с тяжелым прошлым готовятся к крупному турниру по смешанным единоборствам и в решающем бою сталкиваются друг с другом.", "Сын знаменитого боксера пытается построить собственную карьеру и обращается за помощью к опытному наставнику.", "Частный детектив расследует загадочную смерть писателя и постепенно раскрывает тайны его большой семьи.", "Юный сотрудник необычного отеля оказывается в центре истории о дружбе, приключениях и похищенной картине.",]
ids = [ "rocky", "coach_carter", "warrior", "creed", "knives_out", "grand_budapest",]
metadatas = [ {"title": "Рокки", "genre": "спортивная драма", "year": 1976}, {"title": "Тренер Картер", "genre": "спортивная драма", "year": 2005}, {"title": "Воин", "genre": "спортивная драма", "year": 2011}, {"title": "Крид", "genre": "спортивная драма", "year": 2015}, {"title": "Достать ножи", "genre": "детектив", "year": 2019}, {"title": "Отель „Гранд Будапешт“", "genre": "комедия", "year": 2014},]
Шаг 2. Превращаем описания в эмбеддинги
На этом этапе мы преобразуем описания фильмов в эмбеддинги с помощью многоязычной модели paraphrase-multilingual-MiniLM-L12-v2. Она поддерживает русский язык и для каждого текста создает вектор из 384 чисел.
Еще при вызове модели мы передадим параметр normalize_embeddings=True, который будет приводить все векторы к единичной длине и пригодится нам при дальнейшем сравнении по косинусной близости. В результате каждый фильм получит числовое представление своего описания, а близкие по смыслу тексты окажутся рядом в векторном пространстве. Вот необходимый код для запуска:
from sentence_transformers import SentenceTransformer
model = SentenceTransformer( "sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2")
embeddings = model.encode( documents, normalize_embeddings=True,).tolist()
print("Фильмов:", len(embeddings))print("Размерность вектора:", len(embeddings[0]))
Вот так этот этап выглядит в Google Colab:
Шаг 3. Создаем коллекцию Chroma
На предыдущем этапе мы получили эмбеддинги описаний, а теперь сохраним их в Chroma вместе с идентификаторами, исходными текстами и метаданными. Код ниже создаст локальное хранилище в папке chroma_db, подготовит в нем коллекцию movie_catalog и добавит наши шесть фильмов. Для сравнения векторов будем использовать косинусную меру. Если запустить ячейку повторно, записи с теми же идентификаторами обновятся, поэтому дубликаты не появятся.
Созданная база хранится в папке chroma_db. На компьютере ее файлы остаются между запусками программы, а в Google Colab доступны только до сброса среды выполнения, если не сохранить папку на Google Drive. Для нашего учебного примера такого временного хранения достаточно. Если вы запустите код и все выполнится правильно, внизу появится сообщение: Фильмов в коллекции: 6.
import chromadb
client = chromadb.PersistentClient(path="./chroma_db")
collection = client.get_or_create_collection( name="movie_catalog", configuration={"hnsw": {"space": "cosine"}},)
collection.upsert( ids=ids, documents=documents, metadatas=metadatas, embeddings=embeddings,)
print("Фильмов в коллекции:", collection.count())
Шаг 4. Ищем фильмы по описанию
Сейчас нам нужно проверить, как Chroma ищет фильмы по смыслу. Для этого создадим функцию search_movies, которая будет принимать описание от пользователя, превращать его в эмбеддинг с помощью той же модели и передавать в базу. Далее Chroma сравнит запрос с сохраненными векторами, вернет нужное число ближайших записей, а функция выведет для каждого результата название, год, жанр, расстояние до запроса и исходное описание.
def search_movies(description, top_k=3, genre=None): query_embedding = model.encode( [description], normalize_embeddings=True, ).tolist()
params = { "query_embeddings": query_embedding, "n_results": top_k, "include": ["documents", "metadatas", "distances"], }
if genre is not None: params["where"] = {"genre": genre}
result = collection.query(**params)
rows = zip( result["metadatas"][0], result["documents"][0], result["distances"][0], )
for metadata, document, distance in rows: print(f"{metadata['title']} ({metadata['year']})") print(f"Жанр: {metadata['genre']}") print(f"Расстояние: {distance:.3f}") print(f"Описание: {document}\n")
Давайте проверим запрос из начала статьи:
search_movies("вдохновляющая драма о спортсмене, который преодолевает трудности")
В результате Chroma вернула три фильма, описания которых оказались ближе всего к сделанному запросу. На первом месте оказался «Рокки», на втором — «Тренер Картер», на третьем — «Крид». Число в строке «Расстояние» показывает косинусное расстояние между вектором запроса и вектором описания фильма: чем меньше значение, тем ближе тексты по смыслу. Поэтому «Рокки» с расстоянием 0,547 выше «Тренера Картера» с 0,570 и «Крида» с 0,609.
Шаг 5. Уточняем поиск с помощью фильтра
На предыдущем шаге мы уже реализовали поиск по смыслу, но чтобы проект можно было считать минимально законченным, осталось добавить фильтрацию по метаданным. В реальном онлайн-кинотеатре пользователь часто сочетает описание с точными условиями — например, выбирает год выхода, возрастное ограничение или доступность по подписке. В нашем примере ограничим выдачу спортивными драмами. Для этого передадим жанр в функцию search_movies:
search_movies( "история о человеке, который добивается успеха благодаря тренировкам", top_k=3, genre="спортивная драма",)
После запуска параметр genre=»спортивная драма» добавит к запросу условие, благодаря которому Chroma сначала отберет фильмы указанного жанра, а затем упорядочит их по смысловой близости к описанию. По сравнению с предыдущим примером результаты немного изменились и теперь на первом месте оказался «Крид», затем — «Тренер Картер» и «Рокки». Это нормально, ведь мы изменили не только условия фильтрации, но и сам текст запроса, поэтому модель построила новый эмбеддинг и пересчитала расстояния до описаний фильмов.
Мы создали небольшую систему семантического поиска, в которой векторная база Chroma хранит эмбеддинги и находит фильмы, близкие к запросу по смыслу. Пока система лишь возвращает подходящие записи, но вы можете ее доработать и превратить в полноценное RAG‑приложение — то есть передавать найденные описания языковой модели, чтобы она составляла персональную подборку и объясняла, почему каждый фильм соответствует пожеланию зрителя. Подробнее о работе таких систем вы можете прочесть в нашей отдельной большой статье.
