Векторная база данных для RAG выбирается по требованиям к поиску, правам доступа, обновлению документов и работе команды с инфраструктурой. Qdrant, pgvector и Weaviate стоит сравнивать на одинаковом корпусе и запросах, без опоры на общее обещание скорости. Для внутренних документов первым условием служит запрет выдачи чужих фрагментов.
Роль базы
В RAG векторная база хранит представления фрагментов и помогает находить подходящий контекст; безопасность ответа зависит также от фильтров прав и правил обновления.
Схема RAG состоит из документов, подготовки фрагментов, поиска и ответа модели с указанием источника. База хранит фрагменты и выбирает кандидатов; проверку фактов и оформление ответа выполняют другие части системы. Если исходный документ устарел или фрагмент обрезан посередине условия, быстрый поиск принесёт неверный контекст ещё до генерации.
Сначала опишите корпус: регламенты, переписка, карточки товара или инструкции. Для каждого документа нужны владелец, версия, права чтения и дата обновления. Число файлов без этих признаков плохо помогает выбрать движок. Выбор становится осмысленным, когда понятно, какие фильтры применяются к запросу сотрудника и как исключается удалённая версия.
Архитектуру всей цепочки раскрывает разбор архитектуры RAG. Здесь фокус уже: сравнение хранилищ на условиях одного процесса. Отдельный материал о Qdrant полезен для деталей продукта; эта статья помогает понять, когда включать его в короткий список и с чем сопоставлять.
Поисковая релевантность проверяется на вопросах сотрудников с заранее известными ответами. Если правильный фрагмент отсутствует среди найденных, настройка генерации бессильна исправить ситуацию. Поэтому до выбора базы приготовьте тестовые вопросы, ожидаемые источники и случаи, где ответ должен быть пустым.
Фильтры доступа
Внутренняя база знаний содержит документы разных отделов. Метаданные фрагмента должны позволять применить право пользователя к поиску ещё до выдачи контекста модели. Фильтрация после получения ответа опаздывает: закрытый текст уже участвовал в генерации. Проверяйте маршрут на реальной схеме ролей, включая смену отдела и отзыв доступа.
| Критерий | Вопрос для проверки | Пробный сценарий |
|---|---|---|
| Права | Где действует фильтр роли? | Закрытый документ |
| Обновление | Когда исчезает старая версия? | Замена регламента |
| Поиск | Как сочетаются слова и смысл? | Точное название формы |
| Эксплуатация | Кто восстанавливает индекс? | Сбой загрузки |
Права бывают на документ, раздел и отдельный фрагмент. Если одна инструкция включает приложение только для руководителей, простая метка на уровне файла может оказаться грубой. Лучше разделить источник по границам доступа при загрузке. Для теста задайте одинаковый вопрос пользователям с разными ролями и сравните список найденных фрагментов, наряду с готовыми ответами.
Проверяйте фильтры вместе с режимом поиска, который нужен сценарию. Запрос с точным номером договора требует иной проверки, чем вопрос на естественном языке. У нескольких движков есть разные варианты совмещения поиска и фильтрации; решение принимайте по воспроизводимым результатам на своём корпусе, без заявлений о победителе по чужому тесту.
Правило доступа относится ко всей цепочке: загрузчику, хранилищу, журналу запросов и экрану цитат. База может корректно отфильтровать кандидатов, а приложение потом показать ссылку на закрытый оригинал. Протокол испытания должен включать и такой экран, иначе вывод о безопасности будет неполным.
Три варианта
Qdrant подходит для рассмотрения, когда команда готова вести отдельный поисковый сервис и хочет явно настроить коллекции, метаданные и операции индекса. pgvector разумно проверить, если документы и права уже живут в PostgreSQL и команда предпочитает знакомый контур эксплуатации. Weaviate имеет смысл включить в сравнение, когда нужна его модель организации коллекций и поисковых возможностей. Это гипотезы для теста; готовый рейтинг продуктов потребует результатов испытания.
Сравнивайте один набор документов и одинаковые правила разбиения на фрагменты. Если для одного варианта взять свежий индекс, а для другого старые документы, результат покажет разницу в загрузке вместо свойств баз. Зафиксируйте модель представлений, запросы, фильтры и способ оценки до первого прогона. Затем изменяйте по одному параметру.
- Составьте перечень обязательных метаданных и ролей.
- Загрузите одинаковый корпус во все выбранные варианты.
- Выполните вопросы с ожидаемыми и пустыми ответами.
- Проверьте отзыв прав, замену версии и удаление документа.
- Сравните журнал ошибок и труд команды при восстановлении.
Для малого пилота удобство команды часто важнее абстрактной предельной мощности. Отдельный сервис добавляет мониторинг, резервное копирование и дежурство. Расширение PostgreSQL добавляет нагрузку на привычную базу и требует оценки влияния на соседние задачи. Для Weaviate также оцените правила развёртывания и обновления в вашей инфраструктуре. Смета эксплуатации зависит от этих действий, помимо названия движка.
После сравнения сохраните протокол со ссылками на тестовые документы и найденные фрагменты. Внедрение ИИ в рабочий процесс включает этот технический выбор как часть проекта. Если в вашем процессе критичен отзыв прав, именно его сценарий должен быть показан до согласования контура.
Какие права и обновления документов определяют выбор базы у вас?
Жизнь индекса
Документ меняется после утверждения новой редакции, удаления файла или корректировки доступа. Для каждого события определите действие с фрагментами: заменить, скрыть или удалить. Техническое завершение загрузки и готовность индекса к поиску могут быть разными состояниями; интерфейс должен учитывать это, чтобы исключить выдачу сотруднику цитаты из старого правила.
Добавьте в запись фрагмента идентификатор документа, версию и ссылку на разрешённый оригинал. Тогда после исправления источника можно найти все связанные элементы и проверить, что устаревшая версия исчезла из выдачи. При ошибке индексации лучше временно убрать документ из поиска и направить вопрос человеку, чем молча выдавать прежний текст.
Сценарий восстановления проверяйте так же серьёзно, как качество поиска. Резервную копию проверьте восстановлением нужной версии документов. Прогоните повторную загрузку на тестовом корпусе, сравните количество документов, метаданные прав и контрольные ответы. Расхождение в правах требует остановки выдачи.
Журнал событий помогает установить причину ошибки: источник изменился, загрузчик пропустил файл, поиск выбрал соседний раздел или модель неверно сформулировала ответ. При одинаковом симптоме меры разные. Материал о базе знаний для компании показывает пользовательский результат; выбор векторной базы проверяется прежде всего на управляемости этого жизненного цикла.
Измените один тестовый регламент после первой загрузки и отзовите доступ к другому. Повторите те же вопросы от разных ролей. Зафиксируйте момент исчезновения старой цитаты и того, кто отвечает за сбой обновления. Этот опыт даст больше для выбора, чем общий демонстрационный запрос.
Решение команды
После пилота команда должна назвать выбранный вариант и причину: качество найденных источников, соблюдение прав, предсказуемость обновления и понятная эксплуатация. При равных результатах берите контур, который сотрудники способны сопровождать. Запишите ограничения решения: типы документов, нагрузку теста и правила доступа, на которых оно проверено.
Переход на другие источники требует нового испытания. Регламенты с ровной структурой и переписка с короткими сообщениями создают разный характер поиска. Новый отдел меняет права, а новый формат файлов — загрузчик и разбиение. Результат пилота служит основанием для следующего шага; перед подключением всего архива проведите отдельную проверку.
Отдельно назначьте владельца качества ответов и владельца индекса. Первый разбирает, помог ли найденный фрагмент сотруднику. Второй отвечает за загрузку, удаление, доступность и восстановление. Когда одна команда видит обе метрики, можно отличить ошибку базы от ошибки промпта или модели и исправить нужный слой.
Решение о базе оформите как короткую запись: задача, корпус, права, тестовые вопросы, результаты каждого варианта, способ восстановления и дата следующей проверки. Такой документ позволяет спустя время понять, почему выбрали Qdrant, pgvector или Weaviate и какие условия должны сохраниться при расширении RAG.
При следующей проверке используйте тот же набор вопросов и добавьте новые случаи из замечаний сотрудников. Так видна причина изменения результата: обновились документы, изменился поиск или выросла сложность корпуса. Решение о смене движка появляется только после такого разбора.