Pinecone czy pgvector? Filtry potrafią zmienić zwycięzcę

Dla prototypu RAG lub małego, rzadko zmienianego zbioru, którego dane są już w PostgreSQL, zwykle wystarczy pgvector. Pinecone staje się mocniejszym kandydatem, gdy indeks rośnie, zapytania często zawężają wyniki po metadanych, a zespół chce ograniczyć pracę przy strojeniu i utrzymaniu wyszukiwania wektorowego.

Granica między tymi wyborami zależy od obciążenia, nie od samej liczby wektorów. Znaczenie mają odsetek rekordów przechodzących przez typowy filtr, wymagana liczba fragmentów RAG, dostępna pamięć i oczekiwana trafność. Zapytanie szybkie bez filtra może zwrócić zbyt krótką albo mniej trafną listę po dodaniu warunku dotyczącego klienta, języka czy kategorii.

Dlaczego filtr może skrócić wyniki

W pgvector indeksy przybliżone HNSW i IVFFlat wybierają kandydatów wektorowych, zanim PostgreSQL zastosuje warunek z klauzuli WHERE. Przykład z dokumentacji pgvector pokazuje, że gdy filtr przepuszcza 10% wierszy, z domyślnej puli 40 kandydatów HNSW pasują do niego średnio cztery. Jeśli aplikacja potrzebuje więcej fragmentów, wynik może być niepełny, choć w tabeli są kolejne pasujące rekordy.

Długość listy i jej trafność to osobne kwestie. Wyszukiwanie przybliżone może pominąć najbliższy rekord spełniający filtr nawet wtedy, gdy zwróci żądaną liczbę pozycji. Zwiększenie limitu odpowiedzi nie poszerza samo w sobie puli kandydatów sprawdzonych przez indeks. Dlatego filtr, który pozostawia niewielką część tabeli, potrafi zmienić zarówno czas odpowiedzi, jak i jakość kontekstu przekazanego modelowi.

Kiedy dokładne wyszukiwanie i IVFFlat mają przewagę

Przy małym zbiorze lub wąskim filtrze sensownym punktem wyjścia jest wyszukiwanie dokładne: PostgreSQL wybiera wiersze spełniające warunek, oblicza ich odległość od wektora zapytania i szereguje je. Zwykły indeks na kolumnie filtra może ograniczyć liczbę wierszy do porównania. Taka ścieżka zachowuje pełną trafność wśród dopuszczonych rekordów, ale staje się droższa, gdy filtr pozostawia ich dużo.

W badaniu Amanbayeva i współautorów planista pgvector wybierał czasem skan przybliżony, choć skan dokładny dawał pełną trafność przy porównywalnym czasie; przy filtrach przepuszczających małą część danych IVFFlat osiągał też w części konfiguracji lepszą relację przepustowości do trafności niż HNSW. Eksperyment obejmował filtry nierównościowe na atrybutach liczbowych, pojedyncze zapytania i indeksy mieszczące się w pamięci. Nie wyznacza więc progu, który można bezpośrednio przenieść na każdy filtr tekstowy, ruch współbieżny lub bazę korzystającą z dysku.

IVFFlat grupuje wektory w listy podczas budowy indeksu i przeszukuje wybraną część tych list. Buduje się szybciej i zużywa mniej pamięci niż HNSW, lecz wymaga dobrania liczby list oraz zakresu przeszukiwania. Ponieważ podział powstaje na podstawie danych obecnych przy budowie, przy stale zmieniającym się zbiorze trzeba uwzględnić możliwą przebudowę i ponowną ocenę trafności.

Pamięć indeksu i koszt drugiego systemu

HNSW wymaga miejsca na graf indeksu, a jego budowa wyraźnie zwalnia, gdy zabraknie przeznaczonej na nią pamięci. W porównaniu Pinecone pamięć indeksu HNSW wynosiła w testach dostawcy z kwietnia 2024 r. od 1,2 do ponad 5 razy tyle, ile zajmował surowy zbiór danych. To pomiar konkretnych zbiorów i konfiguracji, wykonany przed dodaniem skanów iteracyjnych do pgvector, a nie uniwersalny przelicznik potrzebnej pamięci.

W pgvector wektory pozostają przy danych relacyjnych. Zapytanie może korzystać z połączeń tabel, istniejących uprawnień i transakcji PostgreSQL; zespół utrzymuje za to instancję, indeks, plany zapytań i zasoby współdzielone z innymi operacjami bazy. Przeniesienie wyszukiwania do Pinecone oddaje obsługę indeksu osobnej usłudze, lecz dodaje synchronizację rekordów i metadanych z bazą aplikacji. Gdy odpowiedź RAG zależy od świeżych uprawnień lub relacji, opóźnienie tej synchronizacji staje się częścią oceny rozwiązania.

Co daje filtrowanie w Pinecone

W Pinecone warunek metadanych można przekazać razem z zapytaniem o podobieństwo. Dokumentacja filtrowania Pinecone pokazuje wyszukiwanie semantyczne ograniczone do rekordów o wskazanej kategorii. Dla RAG pracującego na wycinkach wspólnego zbioru jest to prostszy model zapytania niż strojenie skanu przybliżonego, po którym PostgreSQL odrzuca niedopasowanych kandydatów.

Ta wygoda nie usuwa wymagań dotyczących jakości. Pełna lista wyników mówi, że znaleziono wystarczająco dużo rekordów spełniających filtr; nie mówi jeszcze, czy są to najlepsze fragmenty dla pytań użytkowników. W systemie wielodostępnym równie istotne jest, skąd pochodzą metadane klienta i jak szybko zmiany dostępu trafiają do indeksu. Te warunki mogą przeważyć korzyść z osobnej usługi, jeżeli aplikacja potrzebuje transakcyjnego połączenia z danymi PostgreSQL.

Wybór dla typowych obciążeń RAG

• Prototyp: pgvector bez indeksu przybliżonego pozwala zacząć w istniejącym PostgreSQL i uzyskać dokładny punkt odniesienia dla trafności. Indeks HNSW ma sens, gdy czas odpowiedzi dokładnego wyszukiwania przestaje spełniać wymagania projektu.
• Mały, stabilny zbiór: pgvector jest naturalnym wyborem, jeśli dane mieszczą się w dostępnym budżecie pamięci, a zespół już utrzymuje PostgreSQL. Przy wąskich filtrach zwykły indeks na metadanych i dokładne sortowanie wektorów mogą okazać się prostsze niż HNSW.
• System wielodostępny: wspólny indeks przybliżony w pgvector może tracić kandydatów po odfiltrowaniu danych innych klientów. Partycjonowanie lub osobne tabele ograniczają ten problem, ale zwiększają pracę administracyjną. Pinecone zasługuje na porównanie, gdy wyszukiwanie i tak może działać poza transakcją bazy aplikacji.
• Duży indeks z częstymi filtrami: Pinecone jest mocnym kandydatem, zwłaszcza gdy pamięć potrzebna HNSW i strojenie zapytań obciążają zespół. Warto jednak zestawić go z pgvector po włączeniu dostępnych mechanizmów łagodzących problem filtrów; wyniku starszego testu dostawcy nie należy traktować jak prognozy dla własnych danych.

Jak przesunąć granicę pgvector

Jeśli HNSW zwraca za mało wyników po filtrze, można włączyć skan iteracyjny, który szuka dalej do uzyskania wymaganej liczby pozycji albo osiągnięcia limitu skanowania. Zwiększenie hnsw.ef_search również poszerza pulę kandydatów, lecz zwiększa pracę wykonywaną przy zapytaniu. Tryb strict_order zachowuje kolejność według odległości, a relaxed_order dopuszcza niewielkie odstępstwa w zamian za lepszą trafność wyszukiwania przybliżonego.

Przy IVFFlat podobną rolę pełni zwiększenie ivfflat.probes. Dla powtarzalnego warunku można rozważyć częściowy indeks wektorowy, a dla wielu odrębnych grup — partycjonowanie; oba rozwiązania zmieniają koszt utrzymania struktury danych. Gdy ograniczeniem jest pamięć, halfvec lub kwantyzacja zmniejszają rozmiar indeksu, ale wymagają oceny wpływu na trafność, ewentualnie z ponownym szeregowaniem kandydatów według oryginalnych wektorów.

Porównanie wariantów ma sens przy tych samych danych, filtrach i wymaganej liczbie fragmentów. Wynik dokładny wyznacza punkt odniesienia dla trafności, a osobne pomiary filtrów szerokich i wąskich pokazują, gdzie przybliżony indeks traci kandydatów. Jeżeli dostrojony pgvector mieści się w budżecie pamięci i spełnia wymagania jakości oraz czasu odpowiedzi, pozostanie w PostgreSQL oszczędza utrzymywania drugiego magazynu. Gdy koszt takiego strojenia lub synchronizacji danych jest większy od korzyści, wybór zmienia się wraz z obciążeniem.