A Qdrant szerint a vektorkeresés szűrését menet közben kell kezelni
A metaadatszűrés a vektorkeresésben jelentősen ronthatja a találatok minőségét, miközben a lekérdezés gyorsnak és hibátlannak tűnik. A Qdrant ezért nem egyszerűen elő- vagy utószűrést alkalmaz, hanem lekérdezésenként választja ki, hogyan kezelje a szűrést a keresésen belül.
- Egy széles szűrő 90,8 százalékra, egy széles értékekre épülő AND szűrés 39,7 százalékra csökkentette a visszahívást.
- A Qdrant a szűrést a HNSW gráfon végzett keresés közben alkalmazza.
- A Filterable HNSW extra gráfkapcsolatokkal, az ACORN lekérdezés közbeni javítással segít.
- A lekérdezéstervező négy keresési útvonal közül választ a szűrés becsült mérete alapján.
- Az egyik 1 százalékos AND szűrésnél 500 lekérdezésből 471 a payloadindexet használta.
A szűrés rejtett hatása a találatokra
A Qdrant augusztus 7-én közzétett elemzése szerint egy metaadatszűrő úgy is ronthatja a vektorkeresés eredményeit, hogy közben a lekérdezés gyorsan lefut, találatokat ad vissza, és a működést figyelő rendszerek sem jeleznek problémát.
A cikkben bemutatott benchmarkban egy széles értéktartományra vonatkozó szűrő 90,8 százalékra csökkentette a visszahívást (recall), vagyis a releváns legközelebbi találatok megtalálásának arányát. Két széles értékre épülő AND szűrésnél ez az érték 39,7 százalékra esett. Minden más vizsgált szűrőtípus 97 százalék felett maradt.
A hagyományos megközelítés két lehetőség között választ. Az előszűrés a keresés előtt meghatározza, mely pontok felelnek meg a feltételnek, majd csak ezeken keres. Az utószűrés előbb megkeresi a legközelebbi jelölteket, és csak ezután távolítja el a feltételnek nem megfelelő pontokat.
Miért nehéz jól választani?
Az előszűrés pontos eredményt ad a szűrt részhalmazon, a költsége azonban gyorsan nő. A rendszernek a teljes gyűjtemény minden pontját érintő maszkot kell létrehoznia, és minden egyező pontból pontozási jelölt lesz. Széles szűrő esetén ez a működés a teljes körű, brute force kereséshez közelíthet.
Az utószűrésnél a keresőmotor a kért mennyiségnél több jelöltet kér le, hogy a szűrés után is maradjanak találatok. Ez laza feltételeknél működhet, szigorú szűrőknél azonban a teljes jelöltlista kieshet. A túl kevés jelölt kevés eredményhez vezet, a túl sok pedig ismét a brute force számítási költsége felé tolja a keresést.
A Qdrant ehelyett a szűrőt magában a keresésben alkalmazza. A lekérdezés a HNSW gráfon, vagyis a szomszédos pontok között ugrásokat lehetővé tevő kapcsolt indexen halad végig. Minden elért jelöltet azonnal ellenőriz a szűrő alapján, a kieső pontokat pedig nem pontozza.
A Qdrant négy útvonal közül választ
A menet közbeni szűrésnek saját problémája van: szigorú feltételnél kevés jogosult pont maradhat, ezért a gráfban megszakadhatnak a hozzájuk vezető útvonalak. A Qdrant ezt két megoldással kezeli. A 2019-es Filterable HNSW indexeléskor extra éleket hoz létre olyan pontok között, amelyek egy indexelt payloadmezőben azonos értéket osztanak meg. Az ACORN 2024 óta lekérdezés közben olyan szomszédokon keresztül is elérheti a találatokat, amelyek maguk nem felelnek meg a szűrőnek.
Az extra élek nem fednek le minden esetet. Nem készülnek olyan értékhez, amelyet túl sok pont oszt meg, például egy nagy bérlőhöz vagy népszerű kategóriához. Az AND szűrésnek akkor sincsenek saját élei, ha az egyes mezőkhöz külön-külön tartoznak élek. A cikk elején bemutatott két problémás szűrés ACORN használatával 100 százalékra javult a Qdrant alapértelmezett beállításában.
A lekérdezéstervező minden kérésnél megbecsüli, hány pont felel meg a feltételnek, majd négy útvonal közül választ: a szűrhető HNSW gráfot, annak ACORN-nal kiegészített változatát, közvetlen keresést a payloadindexben vagy teljes körű keresést. Egy, a cikkben vizsgált, a pontok 1 százalékát elérő AND szűrésnél 500 lekérdezésből 471 a payloadindexet használta, 29 pedig a gráfon haladt.
A Qdrant szerint ez a megközelítés a szűrési stratégiát nem általános motorválasztássá teszi, hanem minden lekérdezésnél a rendelkezésre álló információ alapján dönti el. A saját gyűjtemények teszteléséhez a cég az exact: true beállítást javasolja a brute force alapigazság meghatározására, az ACORN bekapcsolásának hasznát pedig a lekérdezések késleltetéséhez köti. A gráfon futó kérésnél ez többszörös késleltetést jelenthet, payloadindexes útvonalnál viszont a hatás elhanyagolható.
