pgvector или Pinecone: три пута већа брзина коштала је 4,8 пута више

У тесту Markaicode-а са милион вектора, Pinecone конфигурација је обрадила 1.200, а pgvector конфигурација 400 упита у секунди, уз потпуност проналажења од око 99% у оба случаја; обрачуната цена била је 0,12 према 0,025 долара на хиљаду упита. То је три пута већи проток за 4,8 пута већу цену по упиту у том тесту, а не измерено обећање за сваку инсталацију.

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

Шта мери објављено поређење

Поређени су Pinecone pod и pgvector индекс IVFFlat у PostgreSQL-у на AWS RDS-у. Корпус је био синтетички, а упити насумични. Зато резултат обухвата и различиту инфраструктуру, мрежни пут и избор индекса: не издваја брзину самог Pinecone-а од брзине самог pgvector-а. Измерени проток је такође друга метрика од времена одзива једног упита; систем који завршава више истовремених захтева не мора у свакој примени пропорционално скратити чекање корисника.

Опис конфигурације тражи опрез. Тест означава pgvector индекс као IVFFlat, али део резултата везује за параметар ef_search. Документација pgvector-а раздваја ef_search, који подешава HNSW претрагу, од параметра probes за IVFFlat. Без јасног објашњења те ознаке није могуће поуздано пресликати објављену конфигурацију у сопствену базу. Ни за обрачунату цену нису наведене конкретне сатнице инфраструктуре које би омогућиле независан поновни прорачун.

И друге методологије дају другачију врсту одговора. Истраживање засновано на скупу MAIR обухвата 14 скупова података и 10.038 упита и међу поређеним системима наводи Pinecone и PGVector. Предмет рада је архитектура претраге заснована на бинарним представама, па се његови резултати не могу претворити у цену упита из теста са синтетичким векторима. Корисна поука за избор је конкретнија: скуп података, начин мерења и архитектура могу променити поредак система.

Сто хиљада и милион вектора нису исти задатак

За условни корпус од 100.000 вектора прво је важно да ли постојећи PostgreSQL већ испуњава захтевано време одзива и потпуност резултата. Ако су текст документа, дозволе и пословни подаци у истој бази, векторски резултат може се повезати са важећим релационим подацима у истом систему. Засебан индекс у другој услузи уводи синхронизацију: измена или брисање документа морају се одразити и тамо где се претражују вектори.

Код условног корпуса од милион вектора више простора заузимају индекс и радни подаци, а векторски упити се такмиче за ресурсе са осталим PostgreSQL оптерећењем. HNSW у pgvector-у обично нуди бољи однос брзине и потпуности од IVFFlat-а, али спорије гради индекс и користи више меморије. IVFFlat може бити погодан када је тај трошак важнији, уз пажљиво подешавање броја листа и претражених делова индекса. Поређење са Pinecone-ом зато треба да укључи индекс који би инжењер заиста користио, а не само конфигурацију објављеног теста.

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

Филтери мењају квалитет резултата

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

У Pinecone-овом поређењу описано је филтрирање током претраге, али компанија признаје да није објавила потпуност проналажења за сваки ниво селективности филтера. Иста страница приказује Pinecone као јефтинији у сопственом сценарију са другим скуповима података, HNSW индексом и другачијим обрасцем упита. Та процена и виша цена Pinecone pod-а у раније наведеном тесту односе се на различите конфигурације и начине обрачуна. Ниједан однос цена не треба преносити на филтрирану претрагу без мерења њене потпуности.

Цена упита и цена система

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

Код Pinecone-а трошак зависи од изабраног режима и стварне потрошње. Pinecone-ов ценовник раздваја складиштење, читања и уписе, а приказује и засебан капацитет за читање. Уз то долази рад на преносу измена из примарне базе у векторски индекс. Цена старог pod-а из објављеног теста зато није замена за прорачун понуде која ће се заиста користити, нарочито када саобраћај долази у налетима или се документи често мењају.

Каква проба може да реши избор

Сопствена проба треба да користи исти корпус, модел вектора, метрику удаљености и скуп упита у оба система. Поред обичних упита, у њу треба укључити стварне услове приступа и селективне филтере. За pgvector има смисла одвојено мерити егзактну претрагу и оне приближне индексе који су кандидати за продукцију, са записаним подешавањима. Тако се разлика у алгоритму не меша са разликом у квалитету вектора или структури података.

На условних 100.000 и милион вектора треба упоредити потпуност проналажења према егзактним најближим суседима, време одзива типичних и спорих упита, проток при очекиваној истовремености и резултате после измена докумената. За филтриране упите треба забележити и колико је погодака враћено, јер пун списак није исто што и исправан поредак најближих докумената. Месечни трошак затим треба рачунати за исти број читања и уписа, уз додатни PostgreSQL капацитет и рад на одржавању или синхронизацији засебног индекса.

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

Прочитајте и:

• Qdrant или pgvector: брзина није једини трошак RAG-а
• Дуг контекст или RAG: више токена не значи увек бољи одговор
• beehiiv мења цене: постојећи корисници плаћају више од обнове