pgvector или Qdrant: строгите филтри можат да го сменат победникот

Ако апликацијата веќе работи со PostgreSQL, pgvector е разумниот почетен избор: векторите остануваат покрај релациските податоци, без посебна услуга за пребарување. Qdrant станува посилен кандидат кога строгите филтри го отежнуваат приближното пребарување, а апликацијата бара висок recall и кратко време на одговор.

Одлуката зависи од резултатот при исти услови, а не од најмалата милисекунда во бенчмарк. Прво треба да се утврди дали двата системи го достигнуваат потребниот recall со вистинските филтри; потоа латентноста се споредува со цената за одржување уште една услуга.

Кога бенчмаркот го менува победникот

Пошироките мерења помагаат да се види каде се разликуваат векторските системи, но не даваат готов одговор за секоја апликација. Емпириска евалуација на векторски системи опфаќа седум системи и шест множества со вкупно над четири милиони вектори, а ги мери точноста, брзината и потрошувачката на ресурси. Нејзиниот широк опфат е корисен контекст; за избор меѓу pgvector и Qdrant, пресудно е како се однесува пребарувањето со филтерот што навистина ќе се користи.

Објавениот тест на pgContext покажува зошто брзината и recall мора да се читаат заедно. На множеството SciFact, со филтер што задржува 10% од точките, итеративното приближно пребарување со pgvector има медијална латентност од 0,524 ms и recall@10 од 0,963; филтрираното пребарување со Qdrant има 0,677 ms и recall@10 од 1,000. Ако во тие конфигурации се избира само според медијалната латентност, води pgvector. Ако условот е recall поголем од 0,963, измерената конфигурација на pgvector не го исполнува, а Qdrant го исполнува. Тоа не кажува колку брз би бил pgvector по дополнително подесување до ист recall.

Истиот тест содржи и одделно, нефилтрирано мерење на GloVe-100-angular со 1.183.514 вектори. При наведена поставка од 512, pgvector достигнува recall 0,910 со медијана од 12,97 ms, а Qdrant recall 0,963 со 2,38 ms. Ова е резултат за таа збирка и тие поставки, не мерење на строги филтри. Системите биле поставени во Docker, но тестот е изведен на една машина Apple M4 Pro, со топол кеш и еден клиент; Qdrant пребарувал низ седум сегменти, па истата номинална поставка не значи ист број разгледани кандидати.

Зошто pgvector може да изгуби резултати по филтрирањето

Кај приближните индекси на pgvector, условот од SQL се применува по скенирањето на векторскиот индекс. Документацијата на pgvector дава пример: ако условот задржува 10% од редовите, стандардната вредност hnsw.ef_search од 40 во просек остава само четири реда што го исполнуваат условот. Пребарувањето затоа може да врати премалку резултати или да испушти блиски вектори што го исполнуваат филтерот.

Тоа однесување не значи дека PostgreSQL мора да остане со кратката листа. Итеративното скенирање бара дополнителни кандидати до зададените граници, со соодветен трошок во време. Ако условот остава мал број редови, индекс на колоната за филтрирање може да ги најде тие редови, по што растојанието до нив се пресметува точно. За чести, стабилни услови, делумен векторски индекс или партиционирање може дополнително да го смени патот на пребарување.

Затоа зборот „строг“ сам по себе не е доволен критериум. Важни се бројот на редови што остануваат по условот, распределбата на вредностите и тоа дали истите услови се повторуваат. Филтер што остава мал број кандидати може да го направи точното пребарување во PostgreSQL практично; друг филтер може да го принуди приближниот индекс да помине низ многу одбиени кандидати.

Како Qdrant го вклучува условот во пребарувањето

Qdrant може да го користи филтерот додека пребарува, наместо дури по изборот на блиски кандидати. Документацијата на Qdrant за филтрирање опишува како индексите на метаподатоци го проценуваат бројот на погодени точки: за мал број системот може директно да ги пресмета растојанијата, а за поголем број да користи филтрирачки HNSW. Тој граф добива дополнителни врски меѓу точки што делат вредност на индексирано поле, што му помага на пребарувањето да стигне до соодветни кандидати.

Предноста зависи од подготовката на збирката. Полето што се користи за филтрирање треба да има индекс на метаподатоци пред да се изгради векторскиот граф. Индекс додаден подоцна може да го обработи условот, но дополнителните врски во графот се добиваат дури по повторно градење. Индексите заземаат ресурси, па нивниот број и времето за градење се дел од оперативната пресметка.

И филтрирачкиот HNSW има граница: врските се создаваат по поле, а не за секоја комбинација од услови. Кога барањето спојува повеќе строги филтри, точките што ги исполнуваат сите услови може да бидат слабо поврзани и recall да падне. Qdrant нуди ACORN, кој при пребарување разгледува и соседи на одбиените точки; тоа може да помогне, но додава пресметки на секое такво барање.

Што добива тимот ако векторите останат во PostgreSQL

pgvector ја зачувува едноставноста на апликација што веќе ги чува главните податоци во PostgreSQL. Векторската колона и релациските редови можат да учествуваат во истите SQL барања, филтри и поврзувања. Кога запис и неговиот вектор се менуваат заедно, тимот работи со еден систем за податоци, со постојните процедури за пристап, резервни копии и набљудување.

Со Qdrant покрај PostgreSQL се појавува уште една копија на податоците потребни за пребарување: вектори, идентификатори и метаподатоци за филтрите. Апликацијата мора да ги пренесе промените и да одлучи што ќе прави ако ажурирањето на двата системи не заврши истовремено. Доцнењето во таа синхронизација може да значи дека филтрираното пребарување кратко време користи постара вредност, дури и ако PostgreSQL веќе ја содржи новата.

Оваа сложеност има смисла ако подобрувањето во пребарувањето е важно за производот. Ако pgvector и Qdrant го исполнуваат истиот праг на recall и време на одговор, постојната PostgreSQL инфраструктура има предност што бенчмарк на едно барање не ја прикажува. Ако разликата се јавува токму кај честите, строги услови, посебната услуга може да го оправда дополнителното одржување.

Избор според збирката, филтрите и бараниот recall

Големината на збирката е почетен податок, но не постои универзален број вектори по кој pgvector треба да се замени со Qdrant. Корисната граница е комбинацијата од бројот на погодени записи по филтер, потребниот recall, латентноста под реално оптоварување и можноста тимот да одржува уште една услуга.

• Постоен PostgreSQL и збирка што лесно се пребарува по услов: pgvector има јасна предност во едноставноста. Точното пребарување по релациски филтер може да биде доволно брзо, а приближниот индекс останува опција за пошироки услови.
• Чести строги филтри и висок праг на recall: прво е важен резултатот што го исполнува прагот, па дури потоа неговата латентност. Qdrant е посилен кандидат кога неговите индекси на метаподатоци и филтрирачкиот граф ја зачувуваат точноста што конфигурацијата на pgvector не ја постигнува.
• Голема збирка со разновидни комбинации од услови: ниту еден систем не добива автоматски. Делумните индекси или партиционирањето може да му помогнат на PostgreSQL кај повторливи услови; кај Qdrant, комбинираните строги филтри може да побараат дополнителна работа при пребарување.
• Мала толеранција за дополнителна услуга: ако разликата во точноста и брзината е мала, синхронизацијата, резервните копии и надзорот на Qdrant може да чинат повеќе од добивката. Ако таа разлика е голема за најважните барања, истиот трошок станува оправдан дел од архитектурата.

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

• Qdrant или Weaviate: брзината и recall не избираат ист победник
• Docker или Podman во rootless режим: мрежата може да го смени победникот
• Podbean или Buzzsprout: часовите за прикачување можат да ја одредат сметката