Weaviate: egy vektordatabázis, amelynek a keresésben kell nyernie, nem csak a hasonlóságban

A Weaviate olyan vektordatabázis, amely az objektumokat és az embeddingjeiket egymás mellett tárolja, és egyetlen lekérdezésre egyszerre válaszol BM25 kulcsszavas kereséssel, vektorhasonlósággal és strukturált szűrőkkel. Ez a nyílt forrású kategória legteljesebb keresőmotorja. A kételyem nem a visszakeresési minőségre vonatkozik, hanem a memóriaszámlára és arra, hány index- és kvantálási döntést kell meghozni az első import előtt.

Qdrant-tal a memóratakarékos indexeken, Pinecone-nal a menedzselt üzemeltetésen, pgvectorral azon érvvel verseng, hogy egy csapat, amely már adatbázist futtat, ne építsen másodikat. A Weaviate válasza az, hogy először is egy teljes adatbázis: replikáció, mentések, többértékűség, RBAC és inkrementális séma módosítás, és mellette a legközelebbi szomszéd keresés.

Mi ez

A projekt a holland Weaviate B.V.-től származik, Go nyelven írták, és a jelenlegi kiadás az 1.40.0, megjelölve 2026. október 7-én. Hivatalos kliensek vannak Pythonhoz, JavaScripthoz, Java-hoz, Go-hoz és C#-hez, és beszél REST, gRPC és GraphQL felületen. Az összehasonlítás előtt érdemes tudni alapvető tényeket:

• A hibrid keresés egy lekérdezésben fuzionálja a BM25 és a vektor eredményeket, az alpha paraméter súlyozza a két felet.
• Négy vektorindex: flat, HNSW, dynamic, amely magától áll át HNSW-re, és HFresh, az 1.36-ban bevezetett lemezes index, amely 1.38 óta általánosan elérhető.
• A kvantálás skálár, termék, bináris és rotációs eljárásokat ismer; a 4 bites rotációs kvantálás előnézet, az 1.40 pedig RQ-4 támogatást ad HNSW indexekhez.
• A beépített MCP-kiszolgáló 1.38 óta általánosan elérhető, és négy eszközt tesz elérhetővé a /v1/mcp útvonalon a REST porton.
• A többértékűség, a replikáció, a mentések, az inkrementális mentések, az objektum TTL és a collection aliasok mind az open source buildben vannak, nem csak a fizetősben.

Hogyan működik

Egy lekérdezés két indexcsaláddal találkozik. Az objektumtulajdonságok fordított indexekben élnek, ugyanabban a BM25 gépezetben, amelyet egy fordított indexű keresőmotor is használ, így a szűrő még a drága művelet előtt szűkíti a jelöltek halmazát. A vektorok a vektorindexben vannak, ahol az HNSW egy memóriában tartott rétegzett gráfon halad végig. Az eredmény összefúzódik, opcionálisan boostolódik és opcionálisan újrarangsorolódik.

Két következmény adódik. A szűrt keresés olcsó marad, mert a szűrő először fut. Az drága rész mindig a vektorindex, és ott van az üzemeltetési költség. A QUERY_HYBRID_MAXIMUM_RESULTS alapértéke 200, vagyis a hibrid lekérdezés mindkét fele legalább ennyi jelöltet szed be a fúzió előtt; ez az első gomb, amit meg kell fordítani, ha egy lekérdezés lassabb a benchmarknál.

Első lépések

A Python kliens az, amivel érdemes kezdeni. Egy collection HNSW indexszel, kvantálással, hibrid kereséssel, szűrővel, boosttal és diverzitásválasztással, körülbelül harminc sorban:

from datetime import timedelta

import weaviate
from weaviate.classes.config import Configure, VectorDistances
from weaviate.classes.query import Boost, Diversity, Filter

client = weaviate.connect_to_local()  # or connect_to_cloud(cluster_url, auth)

client.collections.create(
    "Product",
    vector_config=Configure.Vectors.text2vec_openai(
        source_properties=["name", "description"],
        vector_index_config=Configure.VectorIndex.hnsw(
            distance_metric=VectorDistances.COSINE,
            quantizer=Configure.VectorIndex.Quantizer.rq(bits=8),
        ),
    ),
)

products = client.collections.get("Product")
products.data.insert_many([
    {"name": "Kestrel Wireless Headphones", "in_stock": True, "released": "2026-09-20"},
    {"name": "Aurora Wireless Headphones", "in_stock": False, "released": "2025-11-02"},
    {"name": "Nimbus Wireless Headphones", "in_stock": True, "released": "2026-10-05"},
])

boost = Boost.blend(
    [
        Boost.filter(Filter.by_property("in_stock").equal(True), weight=2.0),
        Boost.time_decay("released", scale=timedelta(days=30)),
    ],
    weight=0.3,   # 30 percent boost, 70 percent original relevance
    depth=200,    # re-score the top 200 candidates
)

hits = products.query.hybrid(
    query="wireless headphones",
    limit=4,
    filters=Filter.by_property("released").greater_than("2025-01-01"),
    boost=boost,
    diversity_selection=Diversity.mmr(limit=4, balance=0.3),
)
for hit in hits.objects:
    print(hit.properties["name"])

Négy részlet ebben a snippetben dönti el, milyen lesz az oldal. A Boost.blend soha nem töröl eredményt, csak újrarangsorol, tehát a feltétel negatív súlya süllyeszt és nem szűr. A depth megadja, hány jelöltet értékelünk újra, a külső weight pedig azt, hogy a boost hányadrészt birtokolja a végső pontszámból. Az MMR kliens 4.23.0 vagy újabb verziót igényel, és a balance alapértéke 0.0, ami tiszta diverzitást jelent, nem semleges középet. Ha a boostot és a reranket együtt használod, a reranker fut utolsóként, és az mondja ki a végső szót.

Indexek, memória és a számla

Az HNSW a csomópontokat és az éleket a memóriában tartja, és a dokumentáció szokatlanul nyílt a költséggel: egy csomópont dimenzionalitástól függően 2 és 12 kB, tehát egymillió vektor 2 és 12 GB, százmillió vektor 200 és 1200 GB, vektoronként körülbelül 200 bájttal élve. Ez a szám a kapacitástervezésbe megy, nem az átviteli célok közé.

Nagy korpuszoknál az HFresh az érdekes. Csoportosítja a vektorokat lemezes postingokba, a memóriában pedig csak a centroidokon futó, 8 bites kvantálású HNSW indexet tartja, a postingokat magukat 1 bittel. A keresés csak a centroidindex által kiválasztott postingokat olvassa, majd a jelölteket tömörítetlen vektorokon értékeli újra. A dokumentáció pontos: csak koszinusz és l2-squared távolság támogatott, a skalárszorzat nem, és nyers átvitelben nem az HNSW legyőzésére készült. A recall paramétereket latenciaállítóként érdemes olvasni: a searchProbe az, hogy egy lekérdezés hány posting listát jár be, a replicas az, hogy egy vektor hány listába kerül, a maxPostingSizeKB pedig a fürtméret.

A kvantálás a másik emelő. A rotációs kvantálás úgy forgatja el a vektort, hogy az értékei egyenletesen oszoljanak a dimenziókra, majd minden dimenziót kis egész kódként tárol. 4 bitnél és 1536 dimenziónál egy vektor 784 bájt, szemben a nyers float32 6144 bájtjával, ami 7,84, nem kerek 8, mert a 16 bájtos rotációs fejléc megmarad. A tömörítés csökkenti a memóriát és a számítást, de nem a cloud által számlázott dimenziók számát: a Weaviate Cloud Flex csomagban havonta egymillió vektordimenzióonként 0,00465 dollártól számol, a tárolás GiB-nként 0,12 dollártól, havi 45 dolláros minimummal, és az erősebb tömörítés alacsonyabb dimenzióonkénti árban jelenik meg, nem kisebb számlában.

A gyártói benchmarkot csak a módszertannal együtt érdemes olvasni. A DBPedia OpenAI ada002 beágyazásokkal, egymillió objektum 1536 dimenzióval és koszinusz távolsággal az ajánlott efConstruction 256, maxConnections 16 és ef 96 konfiguráció 97,24 százalék Recall@10 értéket ad 5639 lekérdezés másodpercenként, 2,80 ms átlagos és 4,43 ms p99 latenciával. Ez 10 000 szűretlen keresés egyetlen GCP n4-highmem-16 példányon, 16 vCPU-val és 128 GB memóriával, a Go klienssel ugyanabban a VPC-ben, és minden találat objektuma visszaolvasásra kerül a lemezről. A scriptek open source-ok, és ez a legfontosabb részük.

Ahol nyiklik

Először a gyengeségek, mert ezek döntik el, hogy ez-e a megfelelő adatbázis. Az HNSW-en a növekedés memóriagörbe, nem vízszintes görbe: százmillió 1536 dimenziós vektor több száz gigabájtos tervezési feladat, és további csomópontok nem zsugorítják egy shard indexét. A törlés aszinkron, így a törlés utáni keresés még visszaadhatja az objektumot. Az API felület elég széles ahhoz, hogy a GraphQL, a gRPC, a gRPC-Web és egy negyedik, kísérleti REST keresési API egymás mellett létezzen, az 1.39 release note pedig kimondja, hogy az új REST API referenciaválasztása lecserélésre kerül, tehát az arra írt kód még változni fog.

Két üzemeltetési megjegyzés zárja a képet. Az aszinkron replikációt az 1.38-ban klaszterszinten egyetlen ütemezőre építették át, és mostantól minden replikált collectionben alapértelmezetten fut, ami megbízhatósági nyereség és egyben háttérterhelés. Az 1.40-ban pedig az új Namespaces funkció, amely control plane és adatizolációt ad a közös klasztert használó felhasználók között, Weaviate licenckulcs mögé került.

MCP hozzáférés és a licenchatár

Az MCP-kiszolgáló az, amivel a legtöbb csapat először találkozik. Streamable HTTP kiszolgáló a /v1/mcp útvonalon a REST porton, saját telepítésen alapból kikapcsolva, a Weaviate Cloudban mindig bekapcsolva, hitelesítve API kulcs bearer tokenként. Négy eszközt tesz elérhetővé: weaviate-collections-get-config a sémákhoz, weaviate-tenants-list, weaviate-query-hybrid hibrid kereséshez, alapértelmezett 0,75 alpha értékkel, és weaviate-objects-upsert az íráshoz. A jogosultságok a szokásos RBAC szerepek, és eszközhíváskor ellenőrzöttek.

A licencelésben a repository LICENSE egyértelmű: a wl könyvtáron kívüli kód BSD-3-Clause, a benne lévő kód Weaviate B.V. szerzői jogú, és csak külön enterprise licenc alatt érhető el, licenckulccsal feloldva, a BSD licenc pedig nem ad jogot ezeknek a funkcióknak a használatához vagy a kulcs megkerüléséhez. Az 1.40 a Namespaces és a deduplikált mentések funkciókat teszi e vonal másik oldalára. Az adatbázis maga BSD-3 marad és használati korlát nélkül telepíthető, így az egyetlen valódi kérdés az, hogy a roadmap mennyi része kerül a kulcs mögé.

Ítélet

A Weaviate akkor a választott vektordatabázis, ha a visszakeresési minőség és az üzemeltetési teljesség fontosabb a legkisebb memóriaköltségnél, és ha a csapat az indextípust, a kvantálási szélességet és az ef értéket valódi paraméternek tudja kezelni, nem alapértelmezésnek. Rossz válasz azoknak a csapatoknak, amelyek már futtatnak Postgrest, és az embeddingeket a sorok mellé akarják tenni, és azoknak is, akik százmilliós vektorkorpuszt néznek szigorú memória keret mellett.

1. Válaszd, ha a lekérdezéseknek a vektorok mellett szűrő és kulcsszó is kell, és ezt egy menetben akarod megkapni három helyett.
2. Válaszd, ha többértékűség, replikáció, mentések és RBAC kell anélkül, hogy négy szolgáltatást tennél egy meztelen vektorindexre.
3. Válaszd, ha BSD-3 adatbázist tudsz magad üzemeltetni, és ugyanazt az API-t akarod menedzselt opcióként is.
4. Kerüld, ha a korpusz akkora, hogy a HNSW memóriája uralja a számlát, és a kissé magasabb p99 elfogadható; ez az HFresh feladata, vagy egy célra épített motoré.
5. Kerüld, ha azt várod, hogy a teljes roadmap a BSD licenc alatt marad. Nézd meg, mely funkciókat zárja licenckulcs mögé az adott verzió, mielőtt erre tervezel.

Források

1. Weaviate dokumentáció: Vector indexing
2. Weaviate dokumentáció: ANN benchmark
3. Weaviate 1.39 kiadási jegyzék
4. Weaviate 1.38 kiadási jegyzék
5. Weaviate dokumentáció: MCP-kiszolgáló
6. Weaviate Cloud árazás
7. weaviate/weaviate: LICENSE
8. weaviate/weaviate v1.40.0 kiadási jegyzék