Проще говоря, обычная база хорошо отвечает на запрос “найди документ с таким ID или словом”, а векторная база помогает с запросом “найди документы, которые похожи по смыслу на этот вопрос”. Для AI-агентов и RAG это один из ключевых слоев: агент получает вопрос, система создает embedding запроса, ищет ближайшие chunks в векторной базе и передает найденный контекст в LLM.
В векторной базе обычно хранят не только сам вектор. Рядом нужны `chunk_id`, текст фрагмента или ссылка на него, source URL, название документа, версия, дата обновления, автор, права доступа, язык, продукт, раздел, статус проверки и другие metadata. Без метаданных сложно фильтровать результаты, показывать citations, соблюдать ACL и удалять устаревшие данные.
Векторная база не заменяет все остальные хранилища. Исходные документы часто лежат в Google Drive, Confluence, Notion, S3 или обычной SQL-базе. Векторная база хранит поисковый индекс: embeddings и служебные данные для retrieval. Поэтому важно синхронизировать изменения: если документ удалили, обновили или закрыли по правам, соответствующие embeddings тоже нужно обновить или удалить.
Для маленького прототипа можно начать с Chroma, pgvector или локального индекса. Для production часто выбирают Qdrant, Weaviate, Pinecone, Redis Vector Search или managed-вариант внутри облака. Выбор зависит от объема данных, latency, фильтров по metadata, гибридного поиска, self-hosted требований, бюджета, резервного копирования и удобства эксплуатации.
Главная ошибка - думать, что векторная база сама сделает RAG качественным. На качество сильнее всего влияют документы, chunking, embedding-модель, metadata, top k, reranking, hybrid search и тесты на реальных вопросах. Если chunks плохие или в индексе лежат устаревшие документы, даже самая сильная vector DB вернет плохой контекст.
В безопасных AI-сценариях векторную базу настраивают вместе с правами доступа, data retention, логами retrieval, citations и evals. Пользователь не должен получить фрагмент из закрытого документа только потому, что он похож по смыслу на вопрос. Поэтому metadata filtering и ACL - не опция, а базовая часть production RAG.
Примеры
- RAG-бот хранит chunks инструкций и embeddings в Qdrant, а при вопросе сотрудника достает 5 наиболее релевантных фрагментов.
- Внутренний поиск по Confluence и Notion сохраняет page_id, access_group, updated_at и embedding, чтобы не показывать закрытые страницы.
- Интернет-магазин использует embeddings карточек товаров, чтобы находить похожие товары по описанию, а не только по названию.
- Локальный агент на компьютере хранит embeddings личных PDF в Chroma или pgvector и отвечает по документам без ручного поиска.
- Команда после смены embedding-модели пересоздает индекс, потому что старые и новые vectors нельзя надежно смешивать без проверки качества.
Где используется
- RAG по базе знаний
- семантический поиск по документам
- чат по PDF, DOCX и wiki
- поиск похожих товаров
- поиск дублей и похожих записей
- локальный AI-ассистент с документами
- retrieval для AI-агентов
- metadata filtering и ACL
- hybrid search вместе с keyword search
- evals качества поиска
Связанные термины
Частые вопросы
Что такое векторная база простыми словами?
Это база для поиска по смыслу. Она хранит embeddings и помогает найти похожие документы, фрагменты, товары или записи даже тогда, когда в запросе нет точных слов из источника.
Векторная база нужна для любого RAG?
Нет. Для маленького прототипа можно использовать keyword search, SQL или локальный индекс. Но когда документов много и нужен поиск по смыслу, векторная база сильно упрощает retrieval.
Чем векторная база отличается от обычной SQL-базы?
SQL-база отлично хранит структурированные данные и ищет по точным условиям. Векторная база оптимизирована для поиска ближайших vectors по смысловой близости и часто хранит metadata для фильтрации результатов.
Какую векторную базу выбрать?
Для старта часто берут Chroma или pgvector. Для production RAG смотрят на Qdrant, Weaviate, Pinecone или Redis Vector Search. Важно оценивать metadata filters, latency, backup, self-hosted режим, гибридный поиск и удобство поддержки.
Почему векторная база может находить неправильные документы?
Причины обычно не в одной базе: плохой chunking, слабая embedding-модель, мало metadata, неверный top k, отсутствие reranking, устаревшие документы или запросы с точными номерами, где нужен keyword search.
