Векторная база данных: что это и зачем она нужна в RAG

Что такое векторная база данных?

Векторная база хранит записи из трех частей: идентификатор, вектор и метаданные. Вектор описывает смысл фрагмента набором чисел, его считает модель эмбеддингов. Как она это делает, я объяснил в статье «Эмбеддинг простыми словами: как ИИ находит смысл в тексте».

Обычная база вроде PostgreSQL или MySQL ищет по точному условию, например по номеру договора или фамилии сотрудника в карточке. Векторная получает вектор вопроса и возвращает несколько записей с ближайшими векторами. Слова в вопросе и во фрагменте могут не совпадать: важен смысл.

Метаданные нужны для фильтров и ссылок, поэтому в них пишут отдел, дату документа, уровень доступа и адрес исходного файла в хранилище компании. В Qdrant это поле называется payload, в Chroma его называют metadata.

Записи одного назначения собирают в коллекцию. Так набор записей называется в Qdrant, Chroma и Milvus, а в pgvector ту же роль играет обычная таблица PostgreSQL с колонкой типа vector.

Зачем векторная база нужна в RAG?

RAG сначала ищет фрагменты документов и потом передает их модели вместе с вопросом. Всю цепочку я описал в статье «RAG простыми словами: как ИИ отвечает по документам компании».

На векторной базе держится шаг поиска. Она хранит векторы всех фрагментов, получает вектор вопроса и отдает ближайшие фрагменты с метаданными. Из метаданных модель берет ссылку на документ и пункт.

Свою базу ставят, когда документы должны остаться на серверах компании или нужны свои фильтры по правам. Если облако подходит, поиск берут готовым у поставщика модели, например в Yandex AI Studio.

Восемь частей RAG-системы и место индекса среди них я разобрал в статье «RAG-система: из каких частей состоит и как ее собрать для компании». Там же есть пределы pgvector по длине вектора, здесь я их не повторяю.

Какие векторные базы данных бывают?

Код всех пяти баз открыт, часть функций Weaviate требует корпоративной лицензии. Их ставят на собственный сервер компании, а различаются они устройством, способом установки и тем, кто обслуживает базу после запуска.

1. pgvector. Расширение PostgreSQL с типами vector, halfvec, bit и sparsevec, векторы лежат рядом с остальными данными. Агенту базу открывает Postgres MCP Pro, у него есть режим только чтения.
2. Qdrant. Отдельная база на языке Rust, запускается одним контейнером Docker. Кроме своего сервера есть облако Qdrant Cloud и встраиваемая версия Qdrant Edge. Для агента есть Qdrant MCP Server.
3. Chroma. Работает на компьютере разработчика, на своем сервере или в облаке Chroma Cloud. К ней подключается Chroma MCP Server.
4. Milvus. Выходит в трех вариантах: библиотека Python Milvus Lite, один образ Docker Standalone и кластер Distributed на Kubernetes. Агенту базу открывает MCP-сервер для Milvus.
5. Weaviate. Отдельная база, у которой каждый арендатор хранится в своем шарде. Часть ее функций работает только с корпоративным ключом.

Для прототипа на ноутбуке разработчика хватит Chroma или Milvus Lite, а для рабочей системы отдела я бы сравнивал pgvector, Qdrant и Milvus Standalone. Это выбор по документации. Замеров на ваших данных он не заменяет.

Чем отличаются Qdrant, Chroma, pgvector, Milvus и Weaviate?

В таблице пять баз по четырем признакам из задачи компании. Скорость поиска в таблицу не попала. Цифры скорости публикуют сами разработчики, и мерить ее нужно на своих данных.

Для размещения в России pgvector удобнее остальных. Расширение vector входит в управляемый сервис Yandex Managed Service for PostgreSQL. Остальные четыре базы я сверял в варианте установки на свой сервер или виртуальную машину.

Версия расширения в Yandex Cloud отстает от последней, поэтому перед проектом проверьте, есть ли в ней нужная вам функция из свежего README pgvector. Параметры всех баз я сверил с официальной документацией 23 октября 2026 года.

Как разграничить доступ по отделам?

Права в векторной базе работают на двух уровнях. Первый решает, кто подключается к базе и к какой коллекции. Второй отсекает чужие фрагменты внутри коллекции фильтром по метаданным.

Qdrant

С версии 1.7.0 в Qdrant есть ключ только на чтение. С версии 1.9.0 появились ключи JWT с доступом на чтение или запись к отдельной коллекции. Агенту поиска я бы выдавал ключ только на чтение, а загрузку документов оставил отдельному процессу.

Отделы внутри одной коллекции Qdrant предлагает различать полем арендатора, например group_id. По нему строят индекс с признаком is_tenant, и каждый запрос фильтруют по этому полю.

pgvector

В pgvector права дает сам PostgreSQL. Роли ограничивают доступ к таблицам, политики защиты строк скрывают строки чужого отдела. Для изоляции арендаторов README pgvector советует секционирование по списку или отдельные таблицы.

Chroma, Milvus и Weaviate

Chroma с версии 1.0.0 встроенную аутентификацию не поставляет. Защиту ставят снаружи. Сервер Chroma я бы держал во внутренней сети за обратным прокси с TLS и проверкой доступа.

Milvus отделяет арендаторов на уровне базы, коллекции, раздела или ключа раздела. Ключ раздела по документации выдерживает миллионы арендаторов, а баз по умолчанию можно создать 64. В Weaviate права ролей сужаются до коллекции и арендатора.

Если во фрагментах есть персональные данные и база стоит в облаке, проверьте две нормы закона 152-ФЗ. Статья 12 регулирует передачу данных за рубеж, часть 5 статьи 18 требует вести первичную базу в России. Как собрать поиск целиком внутри компании, я описал в статье «Локальная LLM и RAG в компании: когда данные нельзя отдавать в облако».

Как создать векторную базу данных?

Шаги ниже даны на примере Qdrant. Для pgvector и Milvus порядок тот же, меняются только команды.

1. Выберите модель эмбеддингов и запишите длину ее вектора. Коллекцию создают под эту длину, векторы другой модели в нее не загрузить.
2. Запустите базу. Qdrant стартует командой docker run -p 6333:6333 qdrant/qdrant, и документация называет такой запуск незащищенным. Ключ API и TLS включают до загрузки документов.
3. Создайте коллекцию с длиной вектора и мерой близости, для текста подходит косинусная.
4. Постройте индексы по полям фильтра: отдел, уровень доступа, дата документа.
5. Загрузите фрагменты с вектором, ссылкой на документ и метками. Текст из PDF и DOCX достает библиотека Docling, для агента у нее есть Docling MCP.
6. Проверьте поиск на реальных вопросах отдела с фильтром по правам сотрудника.

В Chroma шагов меньше, потому что коллекция сама считает векторы встроенной функцией. По умолчанию это модель all-MiniLM-L6-v2, обученная на английском. Длина ее вектора 384 числа, а текст длиннее 256 словесных частей она обрезает. Для русских регламентов я бы сразу взял другую модель эмбеддингов с поддержкой русского языка.

Первую коллекцию удобно собрать на документах одного отдела, а остальные отделы подключать после того, как поиск с фильтром по правам прошел проверку на их вопросах.

Где граница между базой и человеком?

Векторная база хранит фрагменты и отдает ближайшие к вопросу. Ответов она не пишет. Смысл документов она не проверяет и о версиях не знает.

Агент через MCP-сервер видит только коллекции, на которые у его ключа есть права. Из них он получает лишь найденные фрагменты с метаданными.

Человек решает, какие документы попадут в коллекцию и какой меткой доступа пометить каждый фрагмент. Ответственный за тему удаляет старые версии, иначе поиск найдет обе. Ошибка в метке покажет сотруднику фрагмент чужого отдела, поэтому метки сверяют на выборке до запуска.

С перечнем документов и схемой прав по отделам можно прийти на разбор ИИ-базы знаний компании.