„Qdrant“ ir „pgvector“: sparta nelemia pasirinkimo

Jei RAG dokumentai ir jų metaduomenys jau tvarkomi „PostgreSQL“, pagrįstas pradinis pasirinkimas yra „pgvector“. „Qdrant“ verta skirti atskirą vaidmenį, kai filtruojamos paieškos apkrova pateisina papildomą paslaugą. Šešių duomenų rinkinių tyrime SIFT1M vienos gijos bandyme „Qdrant“ pasiekė 216 užklausų per sekundę (QPS) ir 0,959 „Recall@100“, o „pgvector“ – 154 QPS ir 0,937 „Recall@100“. Šie skaičiai apibūdina bandytas konfigūracijas, o ne būsimos RAG sistemos spartą.

Sprendimas priklauso nuo to, kur laikomi pagrindiniai duomenys, kaip ribojama prieiga prie fragmentų ir kiek paieškos apkrovos tenka aptarnauti. „pgvector“ leidžia vektorinę paiešką įtraukti į esamas SQL užklausas. „Qdrant“ suteikia paieškai atskirą išteklių ir priežiūros ribą, tačiau dokumentų pakeitimus tuomet reikia perduoti iš pagrindinės sistemos į paieškos saugyklą.

Ką rodo publikuotas spartos skirtumas

Tyrime lygintos numatytosios, išsamiai nederintos sistemų konfigūracijos. SIFT1M sudaro vaizdų požymių vektoriai, todėl jo paieškos apkrova nėra tas pats, kas tekstinių dokumentų fragmentų paieška. Bandymas matavo gryną vektorinę paiešką be atributų filtrų; kliento, dokumento būsenos ar prieigos lygio sąlygos galėtų pakeisti ir užklausos planą, ir abiejų sistemų santykinę spartą.

QPS parodo, kiek užklausų apdorojama per laiką, o „recall“ – kokia tikslios paieškos rastų artimiausių kaimynų dalis grąžinama. RAG sistemoje abu rodikliai svarbūs kartu: greitas kandidatų sąrašas mažiau naudingas, jei jame trūksta atsakymui reikalingo fragmento. Delsa taip pat svarbi, nes vartotojas laukia viso atsakymo, kurio generavimas prasideda tik gavus paieškos rezultatus. Todėl vienas pralaidumo matavimas neparodo visos užklausos patirties.

Kada „pgvector“ išnaudoja esamą „PostgreSQL“

„pgvector“ dokumentacijoje aprašoma tiksli paieška pagal numatytąją veikseną ir apytiksliai HNSW bei IVFFlat indeksai, kurie dalį paieškos tikslumo iškeičia į spartą. Vektorius galima laikyti greta dokumento laukų ir užklausose naudoti „PostgreSQL“ lentelių jungtis. Kai dokumento savininkas, būsena ir matomumo taisyklės jau saugomi reliacinėje schemoje, paieškos rezultatus galima susieti su tais pačiais duomenimis vienoje duomenų bazėje.

Filtruotai užklausai apytikslis indeksas ne visada yra geriausias kelias. Jei sąlygą atitinka nedaug eilučių, įprastas filtro lauko indeksas gali padėti tiksliai apskaičiuoti jų atstumus iki užklausos vektoriaus. Naudojant apytikslį vektorių indeksą filtras taikomas nuskenavus jo kandidatus, tad griežta sąlyga gali palikti per mažai rezultatų. Iteracinis skenavimas leidžia ieškoti toliau, kol randama pakankamai tinkamų įrašų arba pasiekiama nustatyta riba.

Jei paieška dažnai ribojama keliomis pasikartojančiomis reikšmėmis, gali padėti daliniai indeksai; kai skirtingų reikšmių daug, svarstytinas lentelės skaidymas. Tai reiškia, kad „pgvector“ pasirinkimas neatleidžia nuo indeksų projektavimo. Vis dėlto jis leidžia pradėti be papildomo duomenų perdavimo kelio ir naudoti jau turimus „PostgreSQL“ atsarginių kopijų, stebėsenos bei prieigos valdymo procesus.

Ką suteikia atskira „Qdrant“ paieška

„Qdrant“ filtravimo dokumentacijoje aprašytos tikslaus atitikimo, intervalų ir jungiamos loginės sąlygos, kurias galima pateikti kartu su vektorine užklausa. Dokumentų paieškai tai leidžia vienoje užklausoje apriboti rezultatus, pavyzdžiui, kliento identifikatoriumi, leidžiamu rinkiniu ir dokumento būsena. Laukams, pagal kuriuos dažnai filtruojama, reikalingi metaduomenų indeksai: vien galimybė užrašyti sąlygą dar negarantuoja mažos delsos.

Atskira paslauga leidžia paieškos pajėgumą didinti nepriklausomai nuo pagrindinės „PostgreSQL“ apkrovos. Tai gali būti svarbu, kai tas pats korpusas aptarnauja daug paieškos užklausų, o pagrindinė duomenų bazė kartu vykdo operacinius įrašymus ir reliacines užklausas. Už šią ribą mokama integracijos darbu: į paieškos kolekciją turi patekti nauji fragmentai, pakeisti metaduomenys ir ištrynimai. Indekso atsilikimas tampa ypač svarbus, kai keičiasi dokumento matomumas.

Kodėl filtravimo mechanizmas keičia pasirinkimą

„Qdrant“ filtravimo strategijos gairėse aiškinama, kad sistema, įvertinusi filtrą atitinkančių įrašų kiekį, gali tiksliai apskaičiuoti jų atstumus arba ieškoti filtruojamame HNSW grafe. Metaduomenų indeksai padeda įvertinti tą kiekį ir sudaryti papildomas grafo jungtis. Kai derinamos kelios griežtos sąlygos, tinkami taškai gali būti sunkiau pasiekiami; ACORN paieška gali pagerinti jų radimą papildomo skaičiavimo sąskaita.

Abi sistemos gali vykdyti filtruotas užklausas, bet skirtingai pasirenka darbą tarp filtro ir panašumo paieškos. „pgvector“ turi „PostgreSQL“ užklausų planuoklį, reliacinius indeksus ir galimybę išplėsti apytikslio indekso skenavimą. „Qdrant“ planuoja paiešką pagal metaduomenų indeksus ir filtruojamą grafą. Kuri schema bus greitesnė, lemia ne filtro pavadinimas, o tai, kokia korpuso dalis jį atitinka ir kiek kandidatų reikia grąžinti.

Eksploatavimo kaina ir galutinis pasirinkimas

„pgvector“ taupo atskiros paslaugos priežiūrą, tačiau vektoriai, jų indeksai ir paieškos užklausos naudoja bendrus „PostgreSQL“ išteklius. Jei ši duomenų bazė aptarnauja svarbias operacines užklausas, paieškos augimą reikia vertinti kartu su jų delsa, indeksavimo trukme ir saugyklos poreikiu. Turima infrastruktūra sumažina integracijos darbą, bet savaime nesuteikia neriboto pajėgumo.

„Qdrant“ paieškos apkrovą atskiria, tačiau bendrą kainą papildo jos stebėsena, atsarginės kopijos ir duomenų sinchronizavimas. Jei prieigos teisės keičiasi dažnai, reikia nuspręsti, kiek gali atsilikti paieškos indeksas ir kur prieš pateikiant fragmentą galutinai patikrinamas leidimas. Tai architektūros sprendimas, kurio QPS matavimas neapima.

Esamai „PostgreSQL“ sistemai „pgvector“ yra racionalus pradinis pasirinkimas, jei paieška telpa į priimtiną bendrų išteklių biudžetą. Atskira „Qdrant“ paslauga labiau pagrįsta, kai filtruotų užklausų apimtis arba poreikis nepriklausomai didinti paieškos pajėgumą nusveria sinchronizavimo ir priežiūros darbą. Lyginant šiuos variantus konkrečiai RAG sistemai, reikšmingi tos pačios dokumentų imties, filtrų ir grąžinamų fragmentų kiekio delsos bei „recall“ rezultatai – kartu su poveikiu pagrindinei duomenų bazei.

Taip pat skaitykite: