Weaviate ці Milvus: адзін бенчмарк не выбірае вектарную базу

Для RAG і семантычнага пошуку выбар паміж Weaviate і Milvus пачынаецца з патрэбнай паўнаты выдачы, а не з найбольшага QPS. Хуткасць варта параўноўваць на аднолькавых даных, пры аднолькавай глыбіні выдачы і прымальным для прыкладання recall. Адзін вынік бенчмарку не ўлічыць фільтры доступу, паралельныя запыты і працу базы пасля росту калекцыі.

У незалежным даследаванні вектарных баз сем сістэм параўналі на шасці наборах з больш як чатырма мільёнамі вектараў: на SIFT1M Weaviate дасягнуў Recall@100 0,996 пры 87 запытах за секунду, Milvus — 0,954 пры 88, а на GIST1M з размернасцю 960 Milvus выйшаў наперад па Recall@100 з вынікам 0,971. Блізкія паказчыкі хуткасці на SIFT1M атрыманы пры рознай паўнаце выдачы, таму яны не адказваюць на пытанне, якая база хутчэйшая пры аднолькавым recall. Даследаванне выкарыстоўвала стандартныя налады і аднаплыневыя запыты на адным вузле без фільтраў; гэта добрая адпраўная кропка, але іншыя ўмовы могуць змяніць вынік.

Што мяняе набор даных і глыбіня выдачы

SIFT1M змяшчае вектары, атрыманыя з выяў, а GIST1M правярае значна больш высокую размернасць. Перавага на адным з гэтых набораў не пераносіцца аўтаматычна на тэкставыя фрагменты ў RAG: там вынік залежыць таксама ад мадэлі эмбедынгаў, метрыкі адлегласці і размеркавання саміх дакументаў. Таму параўнанне сістэм трэба весці ў межах аднаго набору і адной канфігурацыі запыту. Пераход да іншага набору дае новы вынік, а не працяг таго ж рэйтынгу.

Recall@K паказвае, якая доля сапраўдных найбліжэйшых суседзяў трапіла ў выдачу зададзенай глыбіні K. Для RAG гэта мае практычны сэнс: калі патрэбны фрагмент не знойдзены на этапе пошуку, наступнае ранжыраванне ўжо не зможа вярнуць яго ў кантэкст. Кароткая выдача і шырэйшы спіс кандыдатаў ставяць перад індэксам розныя задачы. Таму перад параўнаннем QPS варта вызначыць, колькі фрагментаў прыкладанне забірае з базы і якую паўнату выдачы лічыць дастатковай. Інакш хутчэйшы адказ можа проста ўтрымліваць менш патрэбных фрагментаў.

Чаму QPS з розных тэстаў не складаецца ў адзін рэйтынг

Методыка ANN-тэсту Weaviate вымярае Recall@10 і Recall@100, QPS пры паралельных запытах, сярэднюю затрымку, p99 і час імпарту на серыях па 10 000 запытаў. Час адказу ўключае сеткавую перадачу і атрыманне знойдзеных аб’ектаў з дыска. Такі QPS нельга непасрэдна супастаўляць з аднаплыневым паказчыкам незалежнага даследавання: змяняюцца паралельнасць, асяроддзе і абсяг працы ўнутры запыту.

Нават у адным тэставым асяроддзі прапускная здольнасць не замяняе затрымку асобнага запыту. Пры росце колькасці адначасовых кліентаў агульны QPS можа павялічыцца, пакуль павольныя адказы пачынаюць перашкаджаць карыстальнікам. Таму разам з QPS патрэбны медыяна і p99 пры зададзенай паралельнасці. Важны і склад адказу: пошук, які вяртае толькі ідэнтыфікатары, выконвае менш працы, чым запыт, які дастае тэкст фрагментаў і метаданыя. Абедзве базы трэба вымяраць з тымі палямі, якія сапраўды атрымлівае прыкладанне.

Фільтры могуць змяніць і паўнату, і затрымку

У пошуку па карпаратыўных дакументах запыт можа быць абмежаваны арганізацыяй, калекцыяй, мовай або правамі карыстальніка. Такі фільтр змяняе мноства даступных кандыдатаў і працу індэкса. На старонцы бенчмаркаў Weaviate апублікаваны тэст нефільтраванага ANN і код для яго паўтарэння, а тэсты фільтраванага ANN і вялікага маштабу пакуль пазначаны як будучыя. Гэта статус апублікаваных тэстаў, а не сцвярджэнне пра адсутнасць функцый у базе.

Дакументацыя Milvus пра фільтры адрознівае стандартны пошук, дзе метаданыя абмяжоўваюць мноства перад ANN, і ітэрацыйны, дзе знойдзеныя кандыдаты паслядоўна праходзяць фільтр. Складаныя ўмовы могуць павялічыць затрымку стандартнага спосабу; ітэрацыйны спосаб таксама патрабуе часу, калі даводзіцца правяраць шмат кандыдатаў. Для супастаўлення баз істотныя аднолькавыя палі, умовы доступу і доля дакументаў, якія праходзяць фільтр. Шырокі фільтр і жорсткае абмежаванне доступу варта разглядаць як розныя нагрузкі: іх сярэдняе значэнне схавае важную для прыкладання розніцу.

Што дадае маштабаванне да кошту выбару

Варыянты разгортвання Milvus ахопліваюць Lite, Standalone і Distributed; у размеркаваным рэжыме загрузку даных і пошукавыя запыты апрацоўваюць асобныя вузлы. Гэта дазваляе выдзяляць ім рэсурсы незалежна, але ўскладняе эксплуатацыю: камандзе даводзіцца ўлічваць стан дадатковых кампанентаў і аднаўленне пасля збояў. Калі дастаткова адной машыны, магчымасць размеркаванага разгортвання сама па сабе не паскорыць сённяшнія запыты. Калі калекцыя і нагрузка вырастуць за межы аднаго вузла, аднавузлавы тэст ужо не пакажа кошт гэтага росту.

Эксплуатацыйны кошт лепш фіксаваць побач з recall і затрымкай: колькі часу займаюць імпарт і пабудова індэкса, колькі патрабуецца памяці і дыска, як пошук працуе падчас абнаўленняў. Для абранага рэжыму разгортвання мае значэнне і паводзіны пры збоі вузла. Гэтыя вымярэнні могуць вырашыць выбар, калі абедзве базы дасягаюць патрэбнай паўнаты і хуткасці, але патрабуюць рознага аб’ёму інфраструктуры і працы каманды.

Які proof of concept дасць супастаўны адказ

Кароткая праверка мае сэнс, калі яе вынікі можна прайграць. Патрэбны адны і тыя ж фрагменты, эмбедынгі, метрыка адлегласці, палі адказу і запыты для абедзвюх баз. Версіі сістэм, налады індэксаў, рэжым разгортвання і выдзеленыя рэсурсы трэба захаваць разам з вынікамі: без іх розніцу ў лічбах немагчыма звязаць з прычынай.

1. Складзіце выбарку з дакументаў і запытаў, падобных да прадукцыйнай нагрузкі. Асобна вылучыце пошук без фільтра, з тыповым фільтрам і з жорсткім абмежаваннем доступу.
2. Для кожнай групы зафіксуйце патрэбную глыбіню выдачы. На кантрольнай выбарцы атрымайце эталонных найбліжэйшых суседзяў дакладным пошукам і вымярайце recall адносна гэтага эталона.
3. Наладзьце сістэмы да адной прымальнай мяжы recall. Пасля гэтага параўнайце QPS, медыяну і p99 пры аднолькавай колькасці адначасовых запытаў і аднолькавым складзе адказу.
4. Паўтарыце прагоны пасля імпарту і падчас абнаўленняў. Запішыце час пабудовы індэкса, спажыванне памяці і дыска, а таксама аднаўленне пасля збою ў запланаваным рэжыме разгортвання.

Выбар будзе абгрунтаваны той базай, якая дасягае патрэбнага recall і затрымкі на вашых запытах пры прымальным эксплуатацыйным кошце. Калі гэтыя ўмовы выконвае Weaviate, яго вынік на SIFT1M не патрабуе дадатковага апраўдання; калі іх лепш выконвае Milvus, перавага на GIST1M таксама не з’яўляецца адзінай прычынай выбару. Вырашае вынік уласнай нагрузкі пры загадзя вызначаных патрабаваннях.

Чытайце таксама:

• Pinecone ці Weaviate: нізкая затрымка не вырашае выбар вектарнай БД
• PostgreSQL ці MySQL: адзін бенчмарк не выбірае базу на гады
• Data room для інвестара: адзін няпоўны спіс можа затрымаць увесь раўнд