Baza wektorowa przechowuje embeddings — wektory o 768 do 3072 wymiarach — i pozwala bardzo szybko znaleźć te najbliższe wektora zapytania (wyszukiwanie po podobieństwie). To warstwa storage RAG: dokumenty indeksuje się raz, a wyszukiwanie wśród milionów chunków zajmuje milisekundy. Bez niej trafiamy na wyszukiwania O(n), które są nie do przyjęcia powyżej kilku tysięcy dokumentów.
Główni gracze w 2026: Pinecone (managed, prosty, droższy), Weaviate (open-source, bogaty funkcjonalnie), Qdrant (open-source, szybki, w Rust), pgvector (rozszerzenie PostgreSQL, sensowne, gdy już macie Postgresa i wolumeny < 10M chunków), Milvus (do dużej skali). Dla większości projektów MŚP/dużych firm pgvector w pełni wystarcza i pozwala uniknąć wprowadzania nowej usługi do operowania. Pinecone staje się trafny powyżej 50M wektorów lub gdy potrzebne jest rozproszone wyszukiwanie.
Parametry, które liczą się w produkcji: algorytm indeksu (HNSW to standard), metryka odległości (cosinus dla tekstu), filtry po metadanych (filtrowanie po kliencie, dacie, języku przed wyszukiwaniem wektorowym), wyszukiwanie hybrydowe (wektorowe + BM25) oraz reranking w postprocessingu. Źle skonfigurowana baza wektorowa zwraca szum — a chatbot lub agent AI na niej oparty będzie halucynował. Tuning stacku RAG to 70% pracy nad poważnym projektem.
Jaka baza wektorowa do jakiego wolumenu
- < 1M chunków: pgvector w istniejącym Postgresie — proste, solidne, bez dodatkowej usługi.
- 1M do 50M chunków: Qdrant lub Weaviate self-hosted — dobry kompromis wydajność/koszt/kontrola.
- > 50M chunków lub ciężki multi-tenant: Pinecone managed lub Milvus rozproszony.
- Zawsze aktywować filtry po metadanych przed wyszukiwaniem wektorowym — łatwy zysk x10 na wydajności.
