Vector database в бизнесе: когда нужно, когда переплата
Когда фаундер слышит про RAG, первая мысль — «нужно покупать vector database». Иногда это правда. Часто — преждевременная оптимизация, на которой проекту проще закопаться в инфраструктуре, чем получить продуктовый результат. Покажу, когда vector DB реально нужна, а когда хватит более простых решений.
Когда vector DB точно НЕ нужна
База знаний меньше 100 документов: помещаются прямо в системный промпт LLM с современным контекстным окном. Claude 4.7 имеет 1 миллион токенов — это 700-1000 страниц текста. Просто кладёте весь корпус в промпт, добавляете кеширование (prompt caching) — стоимость инфере падает на 90%, никакой vector DB не нужно.
Корпус не меняется или меняется редко: достаточно prefetch'нуть документы в контекст один раз и закешировать. Каждый новый запрос пользователя обрабатывается за 5-10 центов даже на огромном корпусе. Vector DB начинает имеет смысл когда корпус обновляется чаще раза в неделю.
Поиск по точным совпадениям: для номеров заказов, артикулов, ID, дат — классическая БД (PostgreSQL, Elasticsearch) работает быстрее и точнее. Vector DB нужна именно для семантического поиска «по смыслу», не для точных матчей.
Когда vector DB реально окупается
Большой меняющийся корпус: 1000+ документов, обновления регулярные. Например, корпоративная база знаний на 5-50 тысяч документов: тикеты саппорта, статьи, регламенты, переписка с клиентами. Класть всё в контекст — дорого и не помещается. Векторный поиск находит топ-10 релевантных за миллисекунды.
Поиск по смыслу важнее точного совпадения: «как настроить интеграцию» должно найти статью «инструкция по подключению» — слова разные, смысл один. Полнотекстовый поиск тут не работает, vector search — да.
Multi-tenant система: тысячи пользователей с собственными приватными корпусами. Vector DB позволяет разделить namespace на тенанта и быстро искать только в его данных. Кейсы — SaaS-продукты на базе AI, корпоративные RAG для разных подразделений.
Какой движок выбрать
pgvector (расширение PostgreSQL): идеален когда у вас уже есть Postgres. Добавляете extension, и в той же БД появляется поддержка векторного поиска. Не требует отдельной инфраструктуры. Подходит для корпусов до миллиона векторов, дальше — медленнее специализированных решений.
Qdrant: open-source, self-host или Cloud. Российские корни (основатели — российская команда), быстрее pgvector на больших объёмах. Хороший выбор когда нужна приватность данных (можно поднять на собственном VPS) и масштабируемость.
Pinecone: облачный сервис, managed. Самый простой стартовый выбор: создал индекс через UI, дальше работа через API. Минусы — деньги за всё (compute + хранение), данные в облаке Pinecone (для РФ — это вопрос приватности).
Weaviate, Chroma, Milvus, Vespa: остальные игроки. Имеют смысл для специфических сценариев (Weaviate — мультимодальный поиск, Chroma — для прототипов, Milvus — для огромных объёмов в Китае).
Типичные ошибки внедрения
Ошибка 1: vector DB как «волшебная таблетка». Просто положили документы в Pinecone, запросы возвращают случайные результаты. Корень — плохой chunking (документы разрезаны неудачно), плохие embeddings (модель не подходит под язык/домен), отсутствие reranker.
Ошибка 2: дорогая модель embedding'ов на старте. OpenAI text-embedding-3-large $0.13 за миллион токенов кажется дёшево, но на корпусе 10 миллионов токенов это $1.30, повторно при каждом обновлении. Часто можно стартовать с open-source модели (BGE, E5, multilingual-e5) на собственной инфраструктуре.
Ошибка 3: vector DB первым шагом RAG. Правильный путь — сначала проверить гипотезу на простой реализации: 100 документов в промпте с кешированием, посмотреть качество ответов, понять что вообще нужно. Только потом инвестировать в инфру векторного поиска. Подробнее в нашем подходе — на программе Personal.
Запишитесь на discovery call — на 30-минутном созвоне разберём вашу ситуацию и дадим конкретные шаги.