Векторные базы данных

Векторная БД хранит высокоразмерные эмбеддинги и быстро отвечает на запросы ближайших соседей — основа для RAG, семантического поиска и рекомендаций. Используют ANN-индексы вроде HNSW или IVF-PQ, разменивая точный recall на сублинейную латентность при масштабе. Выбор зависит от задачи: pgvector если уже есть Postgres, Qdrant или Weaviate для self-hosted с гибридным (dense + sparse) поиском, Pinecone для managed-масштаба, FAISS для встраивания. В любом случае продумайте метаданные-фильтры, гибридный поиск и измеряйте recall@k на своих данных — дефолты редко подходят.

Как это работает

Векторные базы данных (Retrieval-Augmented Generation) дополняет LLM-output релевантным контекстом из вашей knowledge base. Pipeline: embed документов → vector DB → на запросе embed query → retrieve top-k похожих chunks → включить как контекст в LLM-промпт → сгенерировать ответ. Embedding-модели: text-embedding-3-large (OpenAI), bge-large, e5-mistral, voyage-3. Vector DB: Postgres + pgvector, Qdrant, Weaviate, Chroma, Pinecone. Re-rankers (Cohere, BGE) улучшают качество top-k.

Когда применять

RAG — когда LLM нужно отвечать по знаниям, которые (а) превышают context window, (б) после knowledge cutoff модели, (в) проприетарны. Начните с Postgres + pgvector — дешевле, проще, масштабируется дальше ожидаемого. Re-ranker — когда качество retrieval плато. Тюньте chunk-size (256-1024 токена) + overlap (10-20%). Меряйте retrieval recall + качество ответа раздельно.

Типичные ошибки

Ловушки Векторные базы данных: chunk слишком маленький (теряет контекст) или большой (нерелевантный контекст доминирует); нет метаданных (источник, timestamp, секция) для фильтрации + цитирования; расчёт, что embedding-модели взаимозаменяемы (нет — качество сильно варьируется); пропуск re-ranking + удивление, что ответы плохие на close-but-wrong retrieval.

Связанные понятия

• RAG (генерация с использованием поиска)
• Вложения
• Стратегии разбиения
• Стратегии извлечения