Qdrant или pgvector: брзина није једини трошак RAG-а

За RAG тим који већ чува документе и права приступа у PostgreSQL-у, pgvector је разуман почетни избор. Вектори остају уз пословне податке, а pgvector документација описује тачну и приближну претрагу у PostgreSQL-у, SQL спајања и трансакције. Qdrant постаје убедљивији када претрага под очекиваним оптерећењем оправда засебну базу и рад потребан за њено одржавање.

Измерена предност Qdrant-а зато није довољна за избор. Тим треба да одмери латенцију и број упита које систем обрађује уз стварне филтере, али и начин ажурирања података, резервне копије и расположиво DevOps време. Ако претрага већ испуњава захтеве производа у PostgreSQL-у, додатни сервис доноси посао који само убрзање мора да оправда.

Шта је измерено, а шта остаје питање за RAG

На скупу SIFT1M, са милион вектора од 128 димензија, упоредно истраживање векторских система бележи 216 упита у секунди за Qdrant и 154 за pgvector у једнонитном мерењу; Qdrant је међу пуним базама имао и најнижу медијану латенције, 4,55 милисекунди. То је предност конкретних конфигурација и услова теста, а не очекивана разлика у свакој апликацији.

Системи су мерени са подразумеваним подешавањима, без исцрпног подешавања за сваки производ. SIFT1M представља векторе из области рачунарског вида, док RAG над текстом може користити другачије векторе и другачију расподелу докумената. Резултат зато добро показује да вреди мерити оба решења, али сам по себи не одређује величину корпуса при којој једно треба заменити другим.

Пропусност и латенција одговарају на различита питања. Број упита у секунди говори колико посла претрага обавља, док време одговора говори шта чека појединачни захтев. У RAG систему пре претраге настаје вектор упита, а после ње следе преузимање садржаја и генерисање одговора. Ако претрага чини мали део тог трајања, њено убрзање ће имати ограничен ефекат на одговор који корисник види. Ако успорава при истовременим захтевима, разлика постаје важнија.

Филтери одлучују које резултате корисник сме да добије

У SaaS претрази није довољно наћи најсличније пасусе у целом корпусу. Упит често мора да остане у оквиру налога, пројекта или статуса документа. Ако претрага врати суседе који не испуњавају те услове, накнадно одбацивање може оставити премало корисних резултата за одговор. Зато поређење брзине има смисла тек уз исти услов приступа и исти тражени број резултата.

Qdrant чува векторе са пратећим подацима у колекцијама. Његов преглед филтрирања објашњава да индекс поља пратећих података може да укључи услов у пролаз кроз HNSW граф. За поља по којима се редовно филтрира индекс је користан, али троши додатне ресурсе и најбоље га је планирати пре уноса података.

У pgvector-у се услов може изразити у SQL упиту и повезати са постојећим колонама. Код приближног векторског индекса филтрирање се примењује после скенирања индекса, па селективан услов може да остави премало резултата. Итеративно скенирање може да прошири претрагу; делимични индекси и партиционисање су друге могућности, зависно од распореда закупаца и података. То значи да једноставност SQL упита не гарантује и једнаку цену његовог извршавања.

Шта доноси задржавање података у PostgreSQL-у

Предност pgvector-а највећа је када вектор мора да прати документ и његово важеће пословно стање. Апликација може да мења документ, статус и вектор у истој бази, а претрага може да повеже резултат са другим табелама. Тим тада користи постојеће поступке за приступ, надзор и опоравак базе. То је уштеда у архитектури и раду, а не тврдња да ће сваки SQL упит бити бржи.

Са Qdrant-ом апликација мора да одлучи који су подаци меродавни у PostgreSQL-у, а који се копирају у колекцију за претрагу. Измена документа или права приступа тада захтева и ажурирање претраживог записа. Ако ажурирање касни или не успе, претрага може кратко да ради над старим стањем; због тога су редослед измена и поновно усклађивање део пројектовања система. Заузврат, оптерећење претраге може да се издвоји из главне трансакционе базе.

Величина корпуса сама не решава избор. Велики корпус са ретким упитима и једноставним условима може имати другачије захтеве од мањег корпуса са много истовремених корисника и строгим правима приступа. Важно је и колико често се документи мењају: што су измене чешће, то је значајније кашњење између изворне табеле и засебног индекса. Ако тим нема времена да одржава ту везу, вредност једне базе расте чак и када засебна претрага има бољи резултат у тесту.

Опоравак је трошак који benchmark не мери

Када су вектори у PostgreSQL-у, могу бити обухваћени истим планом опоравка као и остале табеле. PostgreSQL упутство за WAL архивирање описује враћање основне копије и поновно извршавање архивираних записа до изабраног тренутка. Та могућност зависи од исправно подешеног архивирања и проверених резервних копија, али задржава векторе и пословне податке у истој временској линији опоравка.

Засебан Qdrant захтева и засебан план за претраживе податке. упутство за Qdrant Cloud копије описује аутоматске резервне копије, враћање кластера и snapshot API; измене настале после snapshot-а губе се при његовом враћању. Ако је PostgreSQL извор меродавних података, колекција се може поново изградити, али то троши време док претрага није потпуно обновљена.

Одлука према оптерећењу и времену тима

За корпус који PostgreSQL већ обрађује у оквиру тражене латенције, уз умерен очекивани број упита и честа SQL спајања, pgvector обично има јачи почетни аргумент. То посебно важи када су права приступа и статуси докумената већ у табелама и када је DevOps време ограничено. Ниједан објављени број вектора или упита у секунди не замењује проверу тих услова у сопственој апликацији.

Qdrant има јачи аргумент када претрага под стварним филтерима и истовременим захтевима постане уско грло, а тим може да одржава синхронизацију и опоравак засебне базе. Упоредиво мерење користи исти корпус, исте упите, исти циљ квалитета и иста правила приступа; затим прати латенцију при очекиваном оптерећењу, потрошњу ресурса и време до појаве измењеног документа у резултатима. Тек тада се добитак у претрази може одмерити према раду који нови сервис захтева.