Qdrant vai pgvector? Neljän miljoonan vektorin testi paljasti viive-eron

Jos RAG-sovelluksen tiedot ovat jo PostgreSQL:ssä eikä vektorihaku tarvitse omaa kapasiteettiaan, pgvector on luonteva lähtökohta. Qdrant kannattaa ottaa vakavasti, kun haku kuormittaa päätietokantaa, kokoelmaa halutaan hajauttaa tai metatietosuodattimet ovat hakupalvelun keskeinen osa. Nopeampi yksittäinen haku ei yksin korvaa arviota toisen palvelun ylläpidosta.

Yli neljä miljoonaa vektoria yhteensä kattanut seitsemän järjestelmän ja kuuden aineiston vertailu mittasi SIFT1M-aineistolla Qdrantille täysistä tietokantajärjestelmistä pienimmän mediaaniviiveen, 4,55 millisekuntia. Samassa yksisäikeisessä läpimenomittauksessa Qdrant käsitteli 216 kyselyä sekunnissa ja pgvector 154; pgvectorin mediaaniviive oli Qdrantia suurempi. Neljä miljoonaa on kaikkien aineistojen yhteenlaskettu koko, kun taas mainitut nopeusluvut koskevat yhtä aineistoa. Kokoonpanot olivat oletusasetuksilla toimivia yhden solmun järjestelmiä, ja kyselyistä puuttuivat metatietosuodattimet.

Mitä mitattu viive-ero merkitsee?

SIFT1M koostuu kuvapiirteiden vektoreista. Tekstikatkelmia hakevan RAG-sovelluksen vektorit, etäisyysmitta ja kyselyiden jakauma voivat olla erilaisia, joten millisekuntilukuja ei voi siirtää sellaisinaan tuotantopalveluun. Hakua seuraavat myös mahdollinen tulosten uudelleenjärjestys ja kielimallin vastaus; tietokannan osuus käyttäjän odotusajasta riippuu koko ketjusta.

Läpimenolukema kertoo tässä, kuinka monta kyselyä testijärjestelmä suoritti sekunnissa yksisäikeisessä kokeessa. Se ei mittaa samanaikaisia käyttäjiä, ruuhkahuippua tai hajautetun Qdrant-klusterin kapasiteettia. Jos sovelluksen haku on harvaa ja muu käsittely hallitsee vasteaikaa, ero voi jäädä käyttäjälle vähäiseksi. Tiheässä hakukuormassa pienempi kyselyviive voi sen sijaan antaa enemmän liikkumavaraa ennen kuin hakupalvelu alkaa rajoittaa koko sovellusta.

Myös indeksin rakentaminen ja tallennustila kuuluvat nopeusvertailun hintaan. Mittauksessa Qdrantin indeksi valmistui pgvectorin indeksiä nopeammin, ja pgvector käytti enemmän levytilaa SIFT1M-aineistolla. Nämä havainnot koskevat juuri mitattuja oletuskokoonpanoja: PostgreSQL:n indeksiasetukset, käytettävissä oleva muisti ja aineiston rakenne voivat muuttaa rakentamisen aikaa. Nopeaa hakua ei kannata arvioida irrallaan siitä, kuinka usein vektoreita lisätään tai indeksi joudutaan rakentamaan uudelleen.

Hakulaatu kuuluu samaan vertailuun

Likimääräinen haku säästää työtä jättämällä osan mahdollisista naapureista tutkimatta. Siksi vasteajan rinnalla on katsottava palautusastetta: kuinka moni todellisista lähimmistä vektoreista päätyy tuloksiin. SIFT1M-kokeessa Qdrant saavutti pgvectoria paremman palautusasteen käytetyillä asetuksilla, mutta tulos muuttui aineiston ja haettujen osumien määrän mukaan. Yhden asetuksen nopeutta ei pidä verrata toisen asetuksen laatuun ikään kuin ne olisivat sama palvelutaso.

RAG-haussa ero tuntuu erityisesti silloin, kun hakutuloksista valitaan tekstikatkelmia myöhempää uudelleenjärjestystä varten. Jos hyödyllinen katkelma jää ensimmäisen haun ulkopuolelle, myöhempi vaihe ei voi palauttaa sitä. Toisaalta sovelluksen kannalta riittävän hyvä osumajoukko voi tehdä lisänopeudesta arvokkaampaa kuin palautusasteen pienestä parannuksesta. Ratkaiseva mittari on oman sisältöaineiston osumien käyttökelpoisuus samalla viivevaatimuksella.

Suodatus muuttaa hakupolkua

PostgreSQL:n vahvuus on mahdollisuus yhdistää vektorihaku muuhun tietoon SQL-kyselyssä. pgvectorin dokumentaatio kuvaa tarkan haun sekä HNSW- ja IVFFlat-indeksit: oletusarvoinen tarkka haku löytää lähimmät osumat ilman likimääräisen indeksin hakuhävikkiä, kun taas indeksit vaihtavat osan tarkkuudesta nopeuteen. Erittäin valikoiva WHERE-ehto voi hyötyä tavallisesta sarakeindeksistä, jolloin etäisyydet lasketaan vain ehdon täyttäville riveille.

Likimääräistä pgvector-indeksiä käytettäessä WHERE-suodatus tehdään indeksiskannauksen jälkeen. Jos suuri osa ehdokkaista hylätään, pyydetty osumamäärä voi jäädä vajaaksi. Iteratiivinen indeksiskannaus hakee tarvittaessa lisää ehdokkaita; osittainen indeksi tai taulun osiointi voi sopia toistuvaan rajausehtoon. Niiden hyöty riippuu siitä, kuinka valikoiva ehto on ja kuinka usein samaa rajausta käytetään.

Qdrant käsittelee suodatusta toisella tavalla. Sen suodatusohje kuvaa, kuinka indeksoitu metatietokenttä auttaa valitsemaan hakutavan ja lisää suodatusta tukevia yhteyksiä HNSW-rakenteeseen. Vähän osumia tuottava rajaus voidaan käsitellä myös laskemalla ehdon täyttävien pisteiden etäisyydet suoraan. Usean tiukan ehdon yhdistelmä voi silti heikentää palautusastetta ja vaatia erillistä viritystä. Alkuperäisen nopeusmittauksen järjestystä ei voi käyttää suodatetun haun tuloksena, koska siinä ei ollut tällaisia ehtoja.

Erillinen palvelu lisää oman ylläpitotyönsä

Qdrantissa vektorit ja niihin liittyvät metatiedot tallennetaan kokoelmiin. Qdrantin arkkitehtuurikuvaus kertoo asiakas–palvelinmallista sekä kokoelmien jakamisesta sirpaleisiin hajautetussa käytössä. Tämä antaa mahdollisuuden mitoittaa hakua erillään PostgreSQL:n muista kyselyistä. Vastineeksi käyttöön tulee oma palvelu, jonka kapasiteettia, valvontaa ja palautumista on hallittava.

Jos PostgreSQL on jo sovelluksen ensisijainen tietokanta, pgvectorin vektorisarake voi elää dokumenttien ja käyttöoikeustietojen rinnalla. Päivitys voidaan tehdä saman tietokannan tapahtumassa, eikä erilliseen hakuvarastoon tarvitse lähettää muuttunutta dokumenttia. Hakuindeksi ja vektorikyselyt käyttävät kuitenkin saman PostgreSQL-ympäristön muistia, levyä ja laskentakapasiteettia kuin sovelluksen muu työ. Hakukuorman kasvu voi siksi johtaa päätietokannan lisäkapasiteetin tarpeeseen.

PostgreSQL:n rinnalle lisätty Qdrant tarvitsee tavan välittää lisäykset, muutokset ja poistot hakukokoelmaan. Jos välitys viivästyy, hakutulos voi kuvata vanhempaa tilaa kuin päätietokanta. Virheiden uudelleenkäsittely, kokoelman uudelleenrakentaminen ja käyttöoikeusmuutosten ajantasaisuus ovat silloin osa ratkaisun ylläpitokustannusta. Vastaavasti erillinen palvelu voi rajata raskaan hakukuorman vaikutusta sovelluksen muihin tietokantakyselyihin.

Valinta työkuorman mukaan

Alle miljoonan vektorin kokoelma on hyödyllinen lähtötilanne päätökselle, ei osoitettu tekninen raja kummallekaan tuotteelle. Pieni kokoelma voi vaatia erillisen hakupalvelun, jos kyselyitä tulee paljon tai rajausehdot ovat hankalia. Suurempi kokoelma voi toimia PostgreSQL:ssä, jos kyselymäärä ja vasteaikavaatimus sallivat sen. Kokoelman koko kannattaa suhteuttaa siihen, mikä osa nykyisestä järjestelmästä on jo kuormittunut.

• PostgreSQL on jo käytössä ja haku on rajattua: pgvector säilyttää vektorit muun sovellustiedon yhteydessä ja vähentää siirrettävien tietojen sekä ylläpidettävien palvelujen määrää.
• Suodattimet ovat tiukkoja tai vaihtelevia: vertaa Qdrantin indeksoitua metatietosuodatusta PostgreSQL:n sarakeindekseihin, osiointiin ja iteratiiviseen indeksiskannaukseen samalla osumien laatutasolla.
• Haulle tarvitaan oma kapasiteetti: Qdrant antaa hakukuormalle erillisen palvelun ja hajautusmahdollisuuden, kun tietojen synkronoinnin ja palvelun ylläpidon kustannus on perusteltu.

Arkkitehtuurivalinnassa hyödyllisin vertailu käyttää samoja dokumentteja, kyselyitä, suodattimia ja hyväksyttävää osumalaatua molemmissa järjestelmissä. Tavallisen viiveen lisäksi hitaat kyselyt, resurssien käyttö ja tietojen päivittymisen viive paljastavat, kumman ratkaisun hinta osuu juuri oman sovelluksen kriittiseen kohtaan.

Lue myös:

• Framer vai Webflow? Neljän sivun testi paljasti ilmaistason rajan
• Bitwarden vai 1Password? Perhekäyttö paljastaa hinnan todellisen eron
• DeepL vai Google Kääntäjä? Suomen sijamuodot paljastavat eron