Большие языковые модели, семантический поиск и RAG-системы сделали векторные базы данных практически обязательным элементом современной инфраструктуры. Если раньше приложения искали информацию только по ключевым словам, то сегодня они умеют искать по смыслу. Именно для этого и существуют векторные базы данных.
Одной из самых популярных open-source реализаций является Qdrant. Она активно развивается, легко запускается через Docker и отлично подходит как для небольших проектов, так и для высоконагруженных систем.
Что такое векторная база данных
Обычная SQL-база умеет искать:
- по ID;
- по строковым значениям;
- по диапазонам чисел;
- по индексам.
Например:
WHERE title LIKE '%docker%'
Но если пользователь напишет:
контейнеризация приложений
то статья с названием «Запуск сервисов через Docker Compose» может не попасть в результаты поиска.
Для человека эти запросы похожи по смыслу.
Для обычной базы данных — нет.
Именно здесь используются эмбеддинги (Embeddings).
LLM или специальная embedding-модель преобразует текст в длинный массив чисел:
[0.142,
-0.032,
0.771,
...,
0.105]
Этот массив называют вектором.
Чем ближе смысл двух текстов — тем ближе их векторы в многомерном пространстве.
Векторная база данных позволяет находить ближайшие векторы практически мгновенно.
Где используется Qdrant
Наиболее популярные сценарии:
- RAG (Retrieval-Augmented Generation)
- AI-чат с собственной документацией
- поиск похожих документов
- рекомендации товаров
- поиск похожих изображений
- поиск похожей музыки
- поиск кода
- дедупликация контента
- интеллектуальный поиск по FAQ
Практически любой проект, где появляется слово «семантический поиск», скорее всего использует векторную базу данных.
Почему нельзя хранить векторы в PostgreSQL
Технически можно.
Например, существует расширение pgvector.
Однако при росте количества документов начинают проявляться ограничения.
Представим, что имеется:
- 15 миллионов документов;
- embedding размером 768;
- поиск выполняется несколько сотен раз в секунду.
В таком случае полный перебор становится слишком дорогим.
Qdrant использует специальные алгоритмы Approximate Nearest Neighbor (ANN), благодаря которым поиск выполняется за миллисекунды даже на десятках миллионов объектов.
Как устроен Qdrant
Основная единица хранения — Collection.
Она напоминает таблицу в SQL.
Например:
documentation
Внутри коллекции находятся точки (Points).
Каждая точка состоит из трех частей.
ID
Уникальный идентификатор.
12345
Вектор
Embedding.
[
0.21,
0.55,
-0.18,
...
]
Payload
Любые дополнительные данные.
{
"title": "Как работает Docker",
"url": "/blog/docker",
"category": "backend",
"language": "ru"
}
Получается примерно такая структура:
Point
├── id
├── vector
└── payload
Как выглядит поиск
Допустим, пользователь вводит запрос:
Как подключить Redis к Laravel?
Процесс выглядит следующим образом.
Шаг 1
Embedding-модель преобразует запрос в вектор.
Текст
↓
Embedding
↓
Vector
Шаг 2
Qdrant получает этот вектор.
Шаг 3
Система ищет ближайшие по расстоянию векторы.
Не по совпадению слов.
А именно по смыслу.
Шаг 4
Возвращаются наиболее похожие документы.
Например:
Laravel Cache
Redis Configuration
Queue Driver
Horizon Setup
Даже если слово «подключить» нигде не встречается.
Payload позволяет фильтровать результаты
Поиск можно выполнять одновременно по смыслу и по дополнительным условиям.
Например:
искать только статьи:
- категории backend;
- опубликованные после 2025 года;
- только на русском языке.
Такой подход значительно уменьшает количество нерелевантных результатов.
Индексы HNSW
Главная причина высокой скорости Qdrant — использование алгоритма HNSW (Hierarchical Navigable Small World).
Полный перебор миллионов векторов был бы слишком дорогим.
Вместо этого Qdrant строит граф ближайших соседей.
Во время поиска система не просматривает все документы.
Она быстро перемещается по этому графу и за несколько переходов находит наиболее похожие элементы.
Именно поэтому поиск остается быстрым даже при десятках миллионов записей.
Метрики расстояния
Qdrant поддерживает несколько способов измерения близости векторов.
Наиболее популярные:
- Cosine
- Dot Product
- Euclidean
На практике чаще всего используют Cosine, так как большинство современных embedding-моделей обучаются именно для этой метрики.
Пример использования с RAG
Самая популярная схема выглядит так:
Документы
↓
Разбиение на чанки
↓
Embedding Model
↓
Qdrant
↓
Поиск релевантных частей
↓
LLM
↓
Ответ пользователю
Например:
Пользователь спрашивает:
Как настроить Docker Compose?
LLM сама этого не знает.
Она отправляет запрос в Qdrant.
Получает наиболее подходящие куски документации.
Добавляет их в промпт.
После этого формирует ответ.
Так работает большинство современных AI-ассистентов.
Когда стоит использовать Qdrant
Qdrant будет хорошим выбором, если необходимо:
- реализовать поиск по смыслу;
- построить RAG-систему;
- искать похожие изображения;
- рекомендовать товары;
- работать с миллионами embedding-векторов;
- получать быстрый поиск с фильтрацией.
Если же проект хранит несколько тысяч документов и семантический поиск не требуется, обычной SQL-базы данных будет вполне достаточно.
Заключение
Qdrant — это специализированная база данных, созданная для хранения и поиска embedding-векторов. Она значительно ускоряет семантический поиск по сравнению с традиционными реляционными базами данных и стала одним из стандартных компонентов современной AI-инфраструктуры.
Благодаря поддержке фильтрации по payload, быстрому ANN-поиску, HNSW-индексам и простому API Qdrant отлично подходит для построения RAG-систем, AI-помощников, интеллектуального поиска по документации и рекомендательных сервисов.
Если вы начинаете работать с LLM, скорее всего именно Qdrant станет одной из первых технологий, с которой вы познакомитесь после выбора embedding-модели.
Добавить комментарий