pgvector või Qdrant: haldus ja hübriidotsing

Kui rakenduse dokumendid, metaandmed ja ligipääsuõigused asuvad juba PostgreSQL-is, on pgvector tavaliselt lihtsam lähtevalik: vektorid jäävad põhiandmete kõrvale ning uut andmeteenust pole vaja käitada. pgvectori dokumentatsioon kirjeldab nii täpset otsingut kui ka HNSW- ja IVFFlat-indeksitega ligikaudset lähinaabriotsingut. Väiksem halduskoormus eeldab siiski, et olemasolev PostgreSQL-i paigaldus suudab kanda ka otsinguindeksite tööd.

Qdrant sobib paremini, kui otsingut on vaja põhiandmebaasist eraldi käitada või tulemusi korduvalt mitmest meetodist kokku panna. Selle Query API juhend kirjeldab nimega tihedaid ja hõredaid vektoreid, eelpäringuid, tulemuste ühendamist ning mitmeastmelist järjestamist. PostgreSQL-is saab samuti ühendada vektor- ja tekstiotsingu; valiku määrab see, kus meeskond tahab päringu koostamise loogikat ja otsingu töökoormust hallata.

Millal olemasolev PostgreSQL valiku kallutab?

pgvectori eelis on suurim siis, kui otsitav lõik sõltub juba PostgreSQL-is olevast dokumendist ja selle õigustest. Otsing saab kasutada SQL-i tingimusi ning ühendada tulemuse omaniku, keele või avaldamise olekuga samas andmebaasis. Kui õigus või dokument muutub, saab selle muudatuse hoida koos otsinguandmetega ühes andmemudelis.

See vähendab vajadust kopeerida õigusi ja metaandmeid eraldi otsinguteenusesse, kuid ei tee vektoriotsingut hooldusvabaks. Ligikaudne indeks vahetab osa tulemuste täielikkusest kiiruse vastu; selle ehitamine võtab mälu ja aega ning otsing koormab sama PostgreSQL-i, mida kasutavad rakenduse muud päringud. HNSW sobib sageli siis, kui esikohal on otsingu kiiruse ja leitud vastete kvaliteedi suhe, IVFFlat võib olla mõistlikum väiksema mälukulu ja kiirema indeksiehituse korral.

Majutatud PostgreSQL-i puhul tuleb valikusse arvestada ka seda, kas teenusepakkuja lubab laienduse paigaldada ja uuendada. Kui andmebaasis on ainult dokumendi ID-d, kuid sisu ja selle muutused liiguvad teises süsteemis, ei anna samasse andmebaasi paigutatud vektorid enam sama suurt lihtsuse võitu. Sel juhul sõltub sünkroonimise töö rohkem andmete tegelikust allikast kui valitud otsingumootori nimest.

Millal hübriidotsing annab Qdrantile eelise?

Semantiline vaste aitab leida eri sõnastusega lõike, kuid täpne tootekood, isikunimi või õigusakti tähis võib vajada sõnapõhist vastet. Hübriidotsing ühendab need signaalid üheks järjestatud tulemuseks. pgvectoriga saab kasutada PostgreSQL-i täistekstiotsingut ning ühendada kandidaatide loendid SQL-is või rakenduses, seega pole hübriidotsing ainult Qdranti võimalus.

Qdranti eripära on päringumudel: sama punkt võib sisaldada eri nimega vektoriesitusi ning eelpäringud võivad tuua kandidaate tihedast ja hõredast otsingust enne ühendamist või uut järjestamist. See muutub väärtuslikuks, kui sama otsingutoru peab teenindama paljusid päringuid ja mitut järjestamisetappi. Ühe semantilise päringu ning lihtsa tekstifiltri jaoks võib eraldi teenuse käitamine olla suurem töö kui päringu koostamine PostgreSQL-is.

Ka valmis päringumudel ei vali rakenduse eest sobivat järjestust. Tiheda ja hõreda otsingu tulemuste ühendamisel mõjutab vastete järjekorda ühendamismeetod ning eelpäringute kandidaatide hulk. Kui tähtis on näiteks haruldase nime täpne vaste, peab meeskond hindama, kas see jõuab lõpptulemusse koos semantiliselt sarnaste lõikudega.

Filtri valikulisus võib olla tähtsam kui korpuse suurus

RAG-rakendus ei tohi tagastada lõiku dokumendist, millele kasutajal puudub ligipääs. pgvectori ligikaudse indeksi kasutamisel rakendub tavaline filter pärast indeksiskanni. Kui lubatud ridu on vähe, võib päring anda soovitust vähem vasteid; iteratiivne skannimine jätkab siis otsingut seatud piirini. Väga kitsa filtri korral võib parem olla piirata read esmalt PostgreSQL-i tavalise indeksiga ja arvutada nende seas täpsed vektorikaugused.

Qdrant kasutab filtritega otsingus payload-väljade indekseid. Qdranti filtreerimisjuhis selgitab, et need indeksid aitavad hinnata vastete hulka ja ehitada filtreeritava HNSW-graafi lisaseoseid; seetõttu on kasulik vajalikud väljad indekseerida enne andmete laadimist. Mitme range filtri koosmõju võib siiski vähendada ligikaudse otsingu vastete kvaliteeti ning vajada täiendavat häälestust.

Seega ei anna küsimusele vastust pelk märge, et mõlemad süsteemid toetavad filtreid. Oluline on, kui suur osa kirjetest jääb alles pärast õiguste, keele ja oleku tingimusi ning kui palju tulemusi päring vajab. Sama suur dokumendikogu võib käituda sootuks erinevalt sõltuvalt sellest, kas enamik päringuid otsib kogu korpusest või ainult ühe kasutaja väikesest alamhulgast.

Mida avaldatud jõudlusmõõtmine näitab?

2026. aasta 13. augusti võrdlusuuring hõlmas seitset süsteemi, kuut andmestikku ja kokku üle nelja miljoni vektori, hindas 15 mõõdikut ning sai Qdranti SIFT1M andmestiku vaikeseadistustega katses mediaanlatentsuseks 4,55 millisekundit. Katsed tehti ühel GCP n2-standard-8 masinal. See on konkreetse vektoriotsingu tulemus, mitte valmis RAG-rakenduse vastamisaeg.

Uuringu väärtus on ühine katseraam: lisaks päringu kiirusele vaadeldi vastete kvaliteeti, läbilaset ning indeksi ehitamise ja salvestamise kulu. Võrdlus ei hõlmanud atribuudifiltreid ega hajutatud paigaldust ning süsteeme ei häälestatud põhjalikult. Seetõttu ei saa ühe andmestiku mediaanist järeldada, kumb lahendus on kiirem kasutajaõiguste, hübriidpäringu ja ümberjärjestamisega Eesti tarkvaratiimi rakenduses.

SIFT1M sisaldab pildikirjeldajaid, samal ajal kui paljud RAG-süsteemid otsivad tekstilõike. See erinevus mõjutab, kui hästi mõõdetud kiirus kandub üle päris päringutele. Arhitektuurivaliku jaoks on vaja vaadata koos vastete kvaliteeti, sagedasemaid filtreid ja koormust, mida otsing lisab põhiandmebaasile või eraldi teenusele.

Varundus on osa halduskulust

pgvectoriga saab vektoritabelid kaasata olemasolevasse PostgreSQL-i varundus- ja taastamiskavasse. Kui vektorid on dokumentidest tuletatud, tuleb eraldi arvestada, kuidas taastatud andmed ja hilisemad dokumendimuudatused kokku viiakse. Samuti võivad suure indeksi ehitamine ja taastamise järel käivituvad otsingupäringud jagada ressursse rakenduse tavapärase liiklusega.

Qdrant lisab eraldi taastatava otsinguandmekogu. Selle hetktõmmiste dokumentatsioon ütleb, et kollektsiooni tõmmis sisaldab selle sõlme andmeid ja seadistust; jaotatud paigalduse puhul tuleb tõmmised teha sõlmede kaupa ning kollektsiooni aliased tuleb taastada eraldi. Kui PostgreSQL jääb dokumentide põhiandmete allikaks, vajab taastamine ka viisi, kuidas otsinguindeks pärast katkestust põhiandmetega kooskõlla viia.

Otsustuspuu meeskonnale

Kui PostgreSQL on juba tootmises, õigused ja metaandmed asuvad seal ning otsing on valdavalt ühe vektori põhine, alusta pgvectorist. Eelis tuleb olemasolevast andmemudelist ja haldusrutiinist, mitte eeldusest, et ligikaudne indeks töötab häälestuseta.
Kui tihe ja hõre otsing peavad andma ühise tulemuse, kandidaate tuleb mitmes etapis ümber järjestada või otsingukoormust on vaja põhiandmebaasist eraldi juhtida, kaalu Qdranti. Arvesta päringuvõimaluste kõrval andmete sünkroonimist, seiret ja taastamist.
Kui otsust näib juhtivat ainult vektorite arv, vaata enne sagedasemaid filtreid ja nõutavat vastete hulka. Nendest tõenditest ei tulene universaalset korpuse suurust, mille ületamisel üks lahendus automaatselt teiseks vahetada.

Loe ka: