pgvector ali Pinecone: več hitrosti lahko pomeni skoraj petkrat višji strošek

V primerjavi Markaicode je Pineconov pod s1.x1 pri milijonu sintetičnih vektorjev dosegel navedenih 1.200 poizvedb na sekundo proti 400 za pgvector z indeksom IVFFlat; ocenjeni strošek na tisoč poizvedb je znašal 0,12 proti 0,025 dolarja oziroma 4,8-krat, skoraj petkrat več. To so objavljene vrednosti za določeni konfiguraciji, ne napoved hitrosti ali računa za vsak sistem RAG.

Če PostgreSQL že uporabljate, je pgvector smiselno prvo merilo za manjšo ali pretežno nespremenljivo zbirko, ki ne obremeni obstoječe baze. Pinecone postane zanimivejši, ko potrebujete večjo prepustnost, zahtevno filtriranje ali manj dela z vektorskim indeksom. Izbiro določata predvsem priklic in zakasnitev pri vaših dokumentih ter skupni strošek delovanja, ne samo velikost zbirke.

Kaj zajame preizkus na milijonu vektorjev

Primerjava uporablja naključno ustvarjene vektorje in iskalne poizvedbe. Takšna obremenitev pokaže, kako se preizkušeni konfiguraciji obnašata pri določeni vrsti iskanja, vendar ne zajame porazdelitve odlomkov iz resničnih dokumentov. V zbirki RAG se podobni odlomki lahko ponavljajo, dokumenti se posodabljajo, uporabniki pa iščejo z različnimi omejitvami dostopa. Vsaka od teh lastnosti lahko spremeni število pregledanih kandidatov in uporabnost vrnjenih zadetkov.

Rezultat primerja stalno dodeljeni Pineconov pod s PostgreSQL in indeksom IVFFlat. Zato ga ni mogoče neposredno prenesti na Pineconov način On-Demand ali na pgvector z indeksom HNSW. Opis preizkusa vsebuje tudi metodološke vrzeli: navaja zaporedno pošiljanje poizvedb, a hkrati prepustnost, ki je navedene zakasnitve pri zaporednem izvajanju ne pojasnijo. Pri konfiguraciji IVFFlat omenja še parameter ef_search, ki je namenjen HNSW. Številke so zato uporaben povod za primerjavo možnosti, niso pa dovolj trdna podlaga za načrtovanje zmogljivosti.

Priklic v takem preizkusu pomeni delež najbližjih vektorjev, ki jih približni indeks vrne glede na natančno iskanje. Za RAG je to le del slike: tudi matematično bližnji odlomek je lahko zastarel, nedovoljen za uporabnika ali neuporaben za odgovor. Meritev na lastnih dokumentih mora zato poleg bližine oceniti, ali med vrnjenimi odlomki ostanejo tisti, iz katerih je mogoče sestaviti pravilen odgovor.

Filtri lahko spremenijo priklic in zakasnitev

Pri iskanju po dokumentih posamezne stranke, jeziku ali časovnem obdobju je pomembno, koliko ustreznih zadetkov ostane po filtriranju. Uradna dokumentacija pgvectorja pojasnjuje, da se pri približnem indeksu filter uporabi po pregledu indeksa, zato lahko poizvedba vrne manj zadetkov od zahtevanega števila; iterativni pregled lahko išče naprej do nastavljenih omejitev. Dokumentacija opisuje tudi običajne indekse na filtriranih stolpcih, delne vektorske indekse in razdelitev tabel. Prava možnost je odvisna od selektivnosti pogoja in razporeditve podatkov.

Tu vrsta indeksa spremeni pomen primerjave. HNSW praviloma ponuja ugodnejše razmerje med hitrostjo in priklicem kot IVFFlat, vendar potrebuje več pomnilnika in se gradi počasneje. Pri IVFFlat na priklic vplivata razdelitev vektorjev ob gradnji ter število pregledanih skupin ob poizvedbi. Pri HNSW se prilagaja velikost nabora kandidatov. Če se nastavitve med meritvami razlikujejo, razlika v hitrosti ni nujno razlika med storitvama.

Posebej občutljiva je zbirka z ločenimi podatki strank. Če približni indeks najprej najde podobne odlomke drugih strank, jih naknadni filter odstrani in dovoljenih zadetkov lahko ostane premalo. Pomembna meritev je zato priklic pri dejanskih filtrih in zahtevani količini dovoljenih odlomkov, skupaj s časom poizvedbe. Nefiltriran rezultat na sintetični zbirki tega vprašanja ne razreši.

Obstoječi PostgreSQL spremeni računico upravljanja

pgvector hrani vektorje ob relacijskih podatkih. Aplikacija lahko iskanje poveže z dokumenti, pravicami dostopa in posodobitvami v isti bazi, ekipa pa uporablja svoje obstoječe postopke za varnostne kopije in nadzor. Ta bližina je posebej koristna, kadar mora biti sprememba vektorja usklajena s spremembo pripadajočega zapisa. Vektorski indeks hkrati porablja pomnilnik in procesorski čas, ki ju potrebujejo tudi druge poizvedbe PostgreSQL.

Pinecone v svoji primerjavi s pgvectorjem priznava, da je pgvector dobra izbira za manjšo, večinoma statično zbirko, če se indeks prilega pomnilniku, ki ga za PostgreSQL že plačujete. Pri ločeni upravljani storitvi ni treba dimenzionirati in uglaševati istega vektorskega indeksa v PostgreSQL, aplikacija pa mora vzdrževati povezavo med izvornimi dokumenti in njihovimi vektorji. Spremembe dokumentov, metapodatkov in dovoljenj morajo zato zanesljivo doseči oba sistema.

Strošek poizvedbe ni mesečni strošek

Objavljena skoraj petkratna razlika je ocena za pod in izbrano instanco PostgreSQL pri preizkušenem prometu. Opis izračuna ne poda konkretnih urnih cen, njegova zapisana formula pa ne omogoča jasne ponovitve rezultata. Razmerja zato ni smiselno uporabiti kot cenika. Če baza že teče in indeks ne zahteva večje instance, šteje predvsem dodatna poraba njenih virov; ko vektorsko iskanje povzroči nadgradnjo instance ali upočasni druge naloge, se ta prednost zmanjša.

Pineconov cenik za način On-Demand ločeno obravnava shrambo ter bralne in pisalne enote, pri izbranih paketih pa tudi minimalno porabo; na voljo je še namenska bralna zmogljivost. Mesečna ocena mora zato zajeti branje, dodajanje in posodabljanje vektorjev, shranjene metapodatke ter promet med storitvami. Pri pgvectorju je treba v isti račun vključiti morebitno večjo instanco, vzdrževanje indeksa in vpliv na preostale naloge baze. Čas ekipe ima ceno pri obeh možnostih, čeprav se na računu ponudnika ne pojavi.

Odločitvena matrika za RAG

Velikost zbirke je uporaben začetni podatek, vendar sama ne postavi meje med rešitvama. Pomembni so še dimenzije vektorjev, delež posodobitev, zahtevani priklic, filtri in sočasnost poizvedb.

• Manjša, počasneje spreminjajoča se zbirka in obstoječi PostgreSQL: pgvector ima prednost, če indeks ostane znotraj razpoložljivih virov in iskanje ne poslabša drugih poizvedb. Ločena storitev mora v tem primeru prinesti merljivo korist.
• Hitro rastoča zbirka ali veliko sočasnih poizvedb: primerjajte zakasnitev pri pričakovani obremenitvi, porabo pomnilnika in strošek potrebne zmogljivosti. Višja prepustnost iz objavljenega preizkusa sama po sebi ne pove, katera konfiguracija bo ustrezala vaši zbirki.
• Selektivni filtri in ločeni podatki strank: odločilen je priklic dovoljenih odlomkov po filtriranju. Pri PostgreSQL v primerjavo vključite ustrezne relacijske indekse, iterativno iskanje ali razdelitev podatkov; pri Pineconu uporabite enaka pravila dostopa in merite iste poizvedbe.
• Ekipa z malo časa za upravljanje indeksa: upravljana storitev lahko upraviči višji neposredni strošek, če zmanjša delo z nastavitvami, spremljanjem in rastjo zmogljivosti. Ekipa, ki PostgreSQL že dobro upravlja, ima drugačno izhodišče.

Katere meritve veljajo za vašo aplikacijo

Primerljiva preizkusa potrebujeta iste odlomke, model vdelav, metriko podobnosti, zahtevano število zadetkov in dejanska uporabniška vprašanja. Priklic je treba meriti glede na uporabne in dovoljene odlomke, posebej za pogoste filtre ter za redkejše pogoje, ki lahko izločijo večino kandidatov. Zabeležite tudi vrsto indeksa in njegove nastavitve; sicer ni mogoče ločiti učinka konfiguracije od učinka izbrane storitve.

Pri zakasnitvi ločite običajen odziv od počasnejših odzivov pod pričakovano sočasnostjo, pri strošku pa stalno obremenitev od občasnih sunkov ter branje od posodobitev. Če pgvector doseže zahtevani priklic in odzivnost brez povečanja obstoječe baze, ostane prednost enega sistema konkretna. Če za isti rezultat potrebuje več pomnilnika, zapleteno delitev podatkov ali preveč vzdrževanja, primerjava z upravljano storitvijo dobi drugačno težo.