
Qdrant ili Milvus: mali test i veliki klaster ne daju istog pobjednika

Za RAG na jednom poslužitelju Qdrant je razuman početni izbor, ali rezultat manjeg testa nije prognoza za veliki klaster. U testu na skupu SIFT1M imao je najnižu medijalnu latenciju među punim bazama, 4,55 ms, te 216 upita u sekundi, prema 88 za Milvus. Milvus može biti prikladniji kada veliki sustav mora zasebno skalirati obradu upita i pristiglih podataka; to je arhitekturna prednost, a ne izmjerena pobjeda u testu klastera.
Brzina se mijenja i bez prelaska na klaster. U drugom ispitivanju s indeksom HNSW Milvus je pri jednom upitnom toku imao do 75,6 % nižu latenciju P99 od Qdranta. Na skupu Cohere 10M, uz 256 istodobnih upitnih tokova, Qdrant je pak imao 17,6 % nižu latenciju P99. Za izbor baze stoga su presudni vlastiti vektori, tražena kvaliteta dohvata i stvarna konkurentnost upita.
Što se zapravo razlikuje u mjerenjima
SIFT1M sadrži vektore slikovnih značajki, dok se u tekstualnom RAG-u obično pretražuju vektori odlomaka. Prvo je istraživanje koristilo zadane, iscrpno nepodešavane konfiguracije na jednom čvoru. Njegov rezultat pokazuje kako su se te konfiguracije ponašale pod jednakim uvjetima testa, ali ne govori koliko će brzo vraćati odlomke iz određene zbirke dokumenata. U istom je mjerenju Qdrantov recall na SIFT1M bio neznatno viši od Milvusova, pa njegovu veću propusnost u tom paru ne treba pripisati slabijem pronalaženju susjeda.
Drugo istraživanje koristilo je tekstualne vektore, usporedilo više indeksa i povećavalo broj istodobnih upitnih tokova. Pratilo je latenciju P99, odnosno granicu ispod koje završava velika većina upita; medijan iz prvog rada opisuje tipičniji odziv. Propusnost pak govori koliko upita sustav obradi u vremenu. Te tri mjere odgovaraju na različita pitanja: dobar medijan može prikriti povremeno spor upit, a veća ukupna propusnost ne mora značiti kraće čekanje pojedinog korisnika pod opterećenjem.
Indeks može promijeniti izbor prije promjene baze
HNSW omogućuje izravniju usporedbu jer ga koriste oba sustava. Milvus uz njega podržava i IVF te DiskANN, pa se može birati drukčiji odnos memorije, brzine i kvalitete dohvata. U drugom je istraživanju Milvusov HNSW imao veću propusnost od njegova IVF-a, dok je DiskANN u dijelu pokusa bio između njih. To su rezultati konkretnih konfiguracija: naziv indeksa sam po sebi ne određuje ishod, a parametri pretraživanja mijenjaju koliko kandidata sustav pregledava.
Usporedba korisna za RAG zato traži isti skup vektora, metriku udaljenosti, broj vraćenih odlomaka i ciljanu kvalitetu rezultata. Tek pri usporedivom dohvaćanju relevantnih odlomaka niža latencija postaje stvarna prednost. Ako jedna konfiguracija ubrza upit tako što preskače korisne odlomke, jezični model dobiva slabiji kontekst. Važni su i memorija te vrijeme izgradnje indeksa, osobito kada se zbirka često obnavlja ili više zbirki dijeli isti poslužitelj.
Filtrirani RAG zaseban je slučaj
Aplikacija često traži slične odlomke samo među dokumentima određenog jezika, vrste sadržaja ili skupa korisničkih prava. Filter tada mijenja skup kandidata koji sudjeluju u pretraživanju. Mjerenje čistog vektorskog upita ne pokazuje kako će se baza ponašati kada svaki zahtjev mora poštovati takav uvjet. Prvi navedeni benchmark mjerio je pretraživanje bez filtriranja atributa, pa njegov poredak ne rješava taj dio odluke.
Za filtrirani RAG mjerodavan je upit kakav aplikacija šalje u radu: s istim filtrom, dubinom dohvata i raspodjelom istodobnih zahtjeva. Uz medijan i P99 treba promatrati propusnost te kvalitetu vraćenih odlomaka nakon filtriranja. Uvjetni primjer je zbirka u kojoj korisnik smije vidjeti samo vlastite dokumente na hrvatskom jeziku. Rezultat pretraživanja cijele zbirke ne može zamijeniti mjerenje takvog upita, jer aplikacija ne smije naknadno nadoknaditi odlomke koje baza nije dohvatila.
Prototip i jedan poslužitelj
Milvus nije nužno distribuirana instalacija. Milvusove mogućnosti postavljanja uključuju Lite kao lokalnu biblioteku, Standalone kao poslužitelj na jednom stroju te Distributed za Kubernetes. Standalone pakira komponente u jednu Docker sliku. Zbog toga je poštena usporedba za rad na jednom poslužitelju Qdrant prema Milvusu Standalone, a za brzi lokalni pokus može biti relevantan i Milvus Lite.
Qdrantov odziv na SIFT1M daje dobru početnu hipotezu za manju instalaciju, ali operativni izbor uključuje više od brzine pretraživanja. Treba uračunati potrošnju memorije, vrijeme ponovne izgradnje indeksa, sigurnosne kopije, nadogradnje i ponašanje pri ponovnom pokretanju. Ako zbirka stane na jedan stroj i promet je umjeren, dodatna arhitektura sama po sebi nema vrijednost. Ako je potreban indeks koji odgovara drukčijem odnosu memorije i brzine, Milvus Standalone zaslužuje mjerenje na istom hardveru prije konačne odluke.
Veliki klaster mijenja operativnu računicu
Qdrant podržava raspodjelu zbirke na shardove i njihove replike, ali širenje samostalno postavljenog klastera traži plan. Qdrantove upute za distribuirani rad navode da novi čvor ne preuzima postojeće podatke automatski i da se shardovi izvan Qdrant Clouda uravnotežuju ručno. Broj shardova valja predvidjeti pri stvaranju zbirke: ako ih nema dovoljno za buduće čvorove, kasnije širenje može zahtijevati novu zbirku. To je posao koji se ne vidi u benchmarku jednog čvora.
Milvusova arhitektura razdvaja pristupne poslužitelje, koordinaciju, čvorove za pristigle podatke, čvorove za upite, obradu povijesnih podataka i pohranu. Takav raspored omogućuje odvojeno povećavanje kapaciteta kada čitanje i unos rastu različitim tempom. Zauzvrat, tim održava više vrsta komponenti i njihove ovisnosti. Prednost Milvusa u velikom Kubernetes klasteru zato je mogućnost preciznijeg rasporeda resursa, dok je cijena te mogućnosti složeniji rad sustava.
Izbor se mijenja s opterećenjem: za prototip i jedan poslužitelj Qdrant je uvjerljiva polazna opcija, za filtrirani RAG odlučuje mjerenje cijelog filtriranog upita, a za veliki klaster treba usporediti ručno upravljanje shardovima s održavanjem Milvusovih odvojenih slojeva. Objavljene latencije i propusnosti pripadaju hardveru, indeksima i obrascima upita na kojima su izmjerene. Na drukčijem stroju ili uz drukčiju konkurentnost upita valja ih ponovno izmjeriti.
Pročitajte i:
Povezani članci


RAG ili fine-tuning: znanje i ponašanje traže različita ulaganja

RAG zvuči uvjerljivo, ali četiri metrike otkrivaju gdje je puknuo

Perplexity razbija PDF na vektore — pretraživanje više ne traži OCR

LangChain ili LlamaIndex: orkestracija i RAG nisu isti problem

PostgreSQL ili MySQL: jednostavan OLTP i analitika daju drugog pobjednika
Pretplatite se na naš newsletter
Primajte najnovije vijesti o Web3-u, AI-ju i kriptovalutama izravno u svoj sandučić.