
Weaviate или Milvus: високата размерност може да обърне избора

За RAG изберете между Weaviate и Milvus според данните и заявките, които базата действително ще обслужва. В емпирично сравнение на векторни бази върху шест набора с общо над четири милиона вектора Weaviate води по Recall@100 при четири набора, а Milvus има най-висок резултат при GIST1M с 960 измерения — 0,971; тестовете са с настройки по подразбиране, на един възел и без филтри.
Това прави Milvus особено важен кандидат при вектори с висока размерност, но не превръща резултата от визуални дескриптори в прогноза за текстов RAG. Ако приложението ограничава търсенето по клиент или достъп, приема нови документи постоянно или изисква управлявана услуга, тези условия могат да тежат повече от класирането при нефилтрирана заявка.
Какво показва предимството при висока размерност
Размерността е броят стойности във всеки вектор. Тя влияе върху обема на данните и работата при търсене, но в бенчмарка се променя заедно с вида и структурата на наборите. Затова предимството на Milvus при GIST1M не доказва, че самото добавяне на измерения ще го направи по-добър при всеки embedding модел.
Разликата е съществена за избора на метрика. Recall@100 измерва какъв дял от действително най-близките съседи присъства сред върнатите кандидати; тя не измерва дали генерираният отговор е верен. При RAG, който подава малко откъси към езиковия модел, качеството на краткия списък е важно. При система с последващо пренареждане има смисъл да се оценява и по-дълбокият списък, от който пренареждащият модел избира.
Скоростта също трябва да се разглежда заедно с качеството. По-краткото време за отговор не компенсира пропуснат подходящ документ, ако той е нужен за отговора. Обратно, по-високото извличане на близки съседи може да не оправдае разхода, когато забавянето надхвърля изискването на приложението. Полезното сравнение е между конфигурации, които постигат една и съща приемлива точност при сходен поток от заявки.
Как филтрите променят сравнението
Корпоративният RAG рядко търси във всички записи безусловно. Заявката може да е ограничена до документи на конкретен клиент, език, проект или ниво на достъп. Когато допустимите записи са малка част от колекцията, системата трябва едновременно да спази ограничението и да намери близките вектори сред тях.
Документацията за филтриране на Weaviate описва предварителен списък с допустими обекти от инвертиран индекс, който се подава към HNSW търсенето; за този индекс ACORN е стратегията по подразбиране от версия 1.34. Това обяснява как се съчетават структурирано условие и векторно търсене, но не дава време за отговор при конкретна колекция. Milvus също поддържа филтрирани заявки, така че наличието на функцията само по себе си не решава сравнението.
При измерване използвайте еднакви ограничения за достъп и отделете често срещаните филтри от силно ограничаващите. Времето и качеството може да се променят и когато един клиент има много повече документи от останалите. Именно тези заявки липсват в цитирания нефилтриран бенчмарк; пренасянето на неговото класиране върху тях би било допускане, а не измерен резултат.
Обемът и управлението са свързани решения
При самостоятелно хостване изборът на Milvus включва и избор на режим. Официалният преглед на Milvus описва Lite като библиотека за локална употреба, Standalone като сървър на една машина и Distributed като разгръщане върху Kubernetes с отделни възли за приемане на данни и търсене. Последният режим позволява ресурсите за тези задачи да се настройват поотделно, но изисква екипът да управлява по-сложна инсталация.
Голямата колекция не означава непременно тежко обслужване: тя може да се обновява рядко и да получава малко заявки. По-малка колекция може да е по-трудна за обслужване, ако новите документи пристигат непрекъснато, а търсенето има пикове. Затова броят вектори трябва да се разглежда заедно с темпа на запис, едновременните заявки, времето за изграждане на индекс и необходимата памет.
Тук сравнението между софтуерни двигатели се разделя от сравнението между услуги. Резултат на един възел не показва как ще работи разпределен клъстер или управляван план със споделени ресурси. Ако екипът иска да контролира инфраструктурата, оценката включва поддръжка, наблюдение и възстановяване. Ако предпочита управлявана услуга, предметът на сравнение стават конкретните облачни конфигурации и техните ограничения.
Какво казва цената — и какво пропуска безплатният план
Според ценовата страница на Weaviate безплатният облачен план допуска до 100 000 обекта, 1 GB памет и 10 GB дисково пространство, а Flex започва от 45 щатски долара месечно; при Flex размерността на векторите и съхранението участват в ценообразуването, а архивите се таксуват допълнително. Началната цена е праг за достъп до плана, а не достатъчна прогноза за сметка при растяща колекция.
Документацията на Zilliz Cloud представя управляван Milvus с варианти Free, Serverless и Dedicated: Serverless се таксува според използването и може да намали ресурсите до нула, докато Dedicated предоставя отделени ресурси. Тези варианти отговарят на различен трафик и нужда от постоянен капацитет. Безплатният лимит на единия доставчик и началната цена на другия не описват разход за еднакво натоварване.
За бюджетно сравнение са нужни поне размерът на колекцията, размерността, обемът на съхраняваните обекти, заявките и нуждата от архиви. Ако трафикът е неравномерен, моделът на таксуване и поведението при периоди без заявки също имат значение. Самостоятелното хостване добавя собствен разход за инфраструктура и оперативна работа, който не присъства в цената на управляван план.
Дърво на избора за RAG
- Ако основната задача е текстово извличане и приоритет е качеството с настройки по подразбиране, започнете с Weaviate като кандидат. Оценете го с вашите текстове и с броя откъси, които приложението действително използва.
- Ако векторите са с висока размерност или данните приличат на визуалния набор от бенчмарка, включете Milvus при същите условия. Измеренията са причина да го проверите, а не гаранция за предимство.
- Ако почти всяка заявка има филтър, сравнете двата продукта при обичайна и висока селективност. Запазете еднакви документи, метрика за близост и брой върнати резултати.
- Ако обемът надхвърля удобното управление на една машина, преценете дали екипът ще поддържа разпределена инсталация, или ще плаща за управляван капацитет. При облачен избор сравнете конкретни планове при прогнозния трафик, а не само входната им цена.
Решението е най-надеждно, когато кандидатите се сравнят при едно и също качество на извличане, с реалните филтри и с обичайното и пиковото натоварване на приложението. Така се вижда дали предимството, което е важно за RAG системата, е в резултатите, времето за отговор, управлението или общия разход.
Прочетете също:
Свързани статии


RAG може да звучи вярно и пак да търси грешния документ

Семантичният кеш пести LLM заявки — TTL пази от остарели отговори

Оценявайте RAG на две места — верният отговор може да крие слабо извличане

RAG или fine-tuning: знание срещу поведение в AI проект

DuckDB или SQLite: бързата база зависи от формата на заявката
Абонирайте се за нашия бюлетин
Получавайте най-новите новини за Web3, AI и криптовалути директно във входящата си поща.