Chroma: egyszerű vektorkeresés egy bökkenővel

A Chroma nyílt forráskódú vektadatbázis, Apache-2.0 licencsel, amely beágyazott könyvtárként egy alkalmazásban, egyetlen chroma run folyamatként vagy Chroma Cloudként fut. A teszt álláspontja egyszerű: ez a legjobb alapértelmezés egy RAG-rendszer első visszakeresési rétegéhez, mert egy üres repository és egy működő lekérdezés közötti súrlódás majdnem nulla — viszont rossz hosszú távú otthon egy komoly hibrid keresési rendszerhez, mert a lekérdezési nyelv érdekes részei a dokumentáció szerint csak a felhőben léteznek.

A stackben egyetlen helyet foglal el: az embeddingek tárolása és visszakeresése. Versenytárs a pgvector, ha az alkalmazás már fut Postgresen, a Qdrant vagy a Milvus, ha a visszakeresésnek saját szolgáltatás kell, és a Pinecone, ha senki nem akar üzemeltetni semmit. A Chroma egyedi tétele nem az index, hanem a kezelhetőség: a kollekcióhoz kötött embedding funkció, egy szűrőnyelv, amelyhez nem kell indexdeklaráció, és Python-, TypeScript- és Rust-kliensek, amelyek ugyanazt az API-t beszélik.

Mi ez

Az adatmodell három szintből áll. Egy tenant tartalmaz adatbázisokat, egy adatbázis kollekciókat, és a kollekció a tárolás és lekérdezés egysége: minden bejegyzésnek van azonosítója, embeddingje és opcionálisan dokumentuma és metaadat-objektuma. A hozzáférésszabályozás, a kvóta és a számlázás tenant-szinten van definiálva, ami többbérlős SaaS esetén számít, és a legtöbb egypontos vektortárban csendben hiányzik.

• Licenc: Apache 2.0, körülbelül 27 000 csillag a GitHub-repóban, és egy 1.5.9 verziójú kiadás 2026 májusából.
• Három üzemmód: beágyazott könyvtár, egyetlen csomópont, és az a elosztott telepítés, amelyet a Chroma Cloud üzemeltet.
• Három kliens — Python, TypeScript és Rust — azonos collection, add, query és get alakzattal, plusz egy aszinkron HTTP kliens.
• Négy keresési mód egy kollekcióban: sűrű vektorok, ritka vektorok, teljes szöveg és regex a dokumentumokon, valamint metaadat-szűrés.
• Embedding funkciók mint interfész, így a kollekció íráskor beágyaz, és a query_texts-hez nem kell modellhívás az alkalmazáskódban.
• Két lekérdezési API: a klasszikus query és get, valamint egy újabb Search API rangolási kifejezésekkel, elérhető a Chroma Cloudban.

Hogyan működik

A Chroma a tartósságot olyan alrendszerekre bízza, amelyeket nem kell újra feltalálnia: helyben SQLite, az elosztott buildben felhős objektumtároló, ahol a forró adatok SSD gyorsítótárban ülnek. A gyártó érve itt nem egzotikus, hanem gazdasági — a vektorok nagyok, a memória drága, így az igazság forrásának objektumtárolóban tartása a RAM költségének töredékével teszi lehetővé a felhős árat.

Amit a gyártó nem tesz közzé, az egy nyilvános benchmark, aminek lenne módszertana. A felhős dokumentáció azt állítja, hogy a termelési rendszerek meghaladják a 90 százalékos recall értéket, és hogy a tárolási kialakítás egy nagyságrenddel olcsóbbá teszi a Chroma Cloudot az alternatíváknál; mindkettő hihető, és egyik sem reprodukálható a dokumentációból. Kezdd a saját értékelésed pontjának, ne eredménynek.

Első lépések

A beágyazott kliens szervert indít a folyamatban, és a program leállásakor mindent elveszít, ami teszthez pontosan jó, termeléshez pontosan rossz. Egy minimális lekérdezéshez kliens, kollekció, upsert és query kell — szerver, konténer és indexhangolás nélkül.

import chromadb

client = chromadb.Client()
collection = client.get_or_create_collection("docs")

collection.upsert(
    ids=["d1", "d2"],
    documents=[
        "Refunds are issued within five business days.",
        "Support answers within one working day.",
    ],
    metadatas=[{"topic": "billing"}, {"topic": "support"}],
)

hits = collection.query(
    query_texts=["how fast is a refund?"],
    where={"topic": "billing"},
    n_results=1,
)

# Results are column-major: one list per query, one entry per result.
print(hits["documents"][0][0])

Ebben a részletben három dolog okozza később a legtöbb súrlódást. Az eredmények oszlopos formában érkeznek, így minden fogyasztónak párhuzamos tömböket kell összevégeznie a rekordok helyett. Az n_results alapértelmezetten 10, ami egy kis tesztkollekción csendben nem ad használható eredményt. A szűrő pedig a where argumentumba megy a metaadaton, míg a szöveges illesztés a tárolt dokumentumon a where_documentban fut, $contains vagy regex formájában.

Hibrid keresés és a felhő vonala

A Search API az query és get helyébe összeállítható kifejezést tesz: a Search építi a szűrőt és a limitet, a Knn adja a rangsorolást, az Rrf pedig több rangsort von össze. A reciprok rank fúzió minden jelöltet úgy értékel, mint a súly és a simítási állandó plusz a rangsor összegének negatív hányadosát, ahol k alapértelmezetten 60 — ezért működik a sűrű és a ritka eredmények között anélkül, hogy két különböző skálát normálni kellene.

from chromadb import Search, K, Knn, Rrf

dense = Knn(
    query="how fast is a refund?",
    key="#embedding",
    return_rank=True,
    limit=200,
)
sparse = Knn(
    query="how fast is a refund?",
    key="sparse_embedding",
    return_rank=True,
    limit=200,
)

search = (
    Search()
    .where(K("topic") == "billing")
    .rank(Rrf(ranks=[dense, sparse], weights=[0.7, 0.3], k=60))
    .limit(10)
    .select(K.DOCUMENT, K.SCORE)
)

rows = collection.search(search).rows()[0]
for row in rows:
    print(row["score"], row["document"][:60])

Árak és az egy lekérdezésre jutó költség

A Chroma Cloud négy külön számlálót vezet, és az érdekes nem a vektortár. Az írás 2,50 $ GiB-onként, a tárolás 0,33 $ GiB-onként havonta, a lekérdezések 0,0075 $ TiB-onként, a kimenő forgalom pedig 0,09 $ GiB-onként a visszaküldött adatra számol. A Starter csomag nulla havi díjat kér és 5 $ kreditet, tíz adatbázist és tíz csapattagot tartalmaz; a Team havi 250 $ mellett 100 $ kreditet, száz adatbázist, harminc tagot és SOC II-t ad.

A gyártó saját kalkulátora tanulságos. 1536 dimenzióval, 8 KiB-os dokumentumokkal és 500 kollekcióval egymillió dokumentum kb. 34 $ba kerül beírásra, hatmillió tárolt dokumentum havonta kb. 27 $, tízmillió lekérdezés kb. 19 $ — nagyjából 79 $ havonta egy hatmilliós darabos korpuszra. Figyeld az ekonomia irányát: 1 GiB szövegből körülbelül 15 GiB vektor lesz, tehát a tárolást a leggyorsabban növekvő számra számlázzák, és a rövid darabok helyett teljes dokumentumok visszaküldése az, ami felhajtja a kimenő forgalmi számlálót.

Saját üzemeltetés: mi fut valójában

A saját üzemeltetés nem egyetlen dolgot jelent. Az architektúra-dokumentáció három módot különböztet meg eltérő felső korlátokkal, és a köztük lévő különbség nagyobb, mint a márkanevek sugallják.

• Beágyazott: a chromadb.Client() a folyamatban fut, memóriában vagy helyi útvonalon tartja az adatot, és meghal a programmal. Teszthez jó, szolgáltatáshoz nem.
• Egy csomópont: chroma run --path egy HttpClient mögött, dokumentálva kevesebb mint 10 millió rekordra, néhány kollekcióra. Tartós, egyszerű, egyetlen hibaforrás.
• Elosztott: az a telepítés, amelyet a Chroma Cloud üzemeltet, objektumtárolós perzisztenciával és SSD gyorsítótárakkal, adatbázisonként egy régióhoz kötve.
• Adatelhelyzet: a Chroma Cloud az AWS us-east-1 mellett 2026 áprilisától a GCP europe-west1 régióban is fut. A régió létrehozáskor fix, a költözés új adatbázist és újraindexelést jelent.
• Megfelelés: a Chroma Cloud SOC 2 Type II tanúsított; az ügyfél által kezelt titkosító kulcsok 2025 decemberében, a privát hálózat 2026 januárjában érkezett.

Hol gyengül

A gyengeségek jönnek elsőként, mert ők döntik el a választást. A hibrid rangsorolás csak a felhőben van. A metaadat-szűrés kényelmes, nem hangolható, és egy lassú szűrőhöz nincs index, amit állítanál. Az eredményforma oszlopos, ami minden fogyasztótól kis, de állandó adót szed. Az árlista pedig pontos azt a mintát bünteti, amit a retrieval-augmented generation ösztönöz: nagy kontextusablakot adni vissza lekérdezésenként.

Az összehasonlítás, ami számít, a pgvectoré. Ha a korpusz már egy Postgres táblában van, és a vektoroknak ugyanabban a tranzakcióban kell lenniük, egy külön vektortár egy további szolgáltatás, amit menteni, biztonságoskodni és felügyelni kell olyan képességért, amit a Postgres már tud adni — a standard vector típus 2 000 dimenziós kemény korlátjával és 4 000-rel fél pontosságnál. A Chroma akkor érdemli meg a helyét, ha a visszakeresés a termék: multimodális kollekciók, regex a tárolt dokumentumokon, kollekció-forking kísérletekhez, és egy embedding funkció, amely kivesz egy modellhívást az alkalmazáskódból.

Ítélethoz

A Chroma egy jól mérlegelt alapértelmezés egy meghatározott vakfolttal. A kezelhetőség valódi: három kliens, egy API, egy séma nélküli szűrőnyelv, és tíz sor az import chromadbtól a rangsorolt eredményig. A vakfolt ugyanilyen valós: az a lekérdezési funkcionalitás, ami a demót megkülönbözteti a visszakeresési rendszertől, pontosan az, amit ma nem tudsz magad üzemeltetni. Az első réteghez észszerű csere, egy hosszú életű rendszerhez rossz.

1. Válaszd, ha a visszakeresési réteg még tervezés alatt áll, és a mérhető alaphoz vezető leggyorsabb út a legfontosabb.
2. Válaszd, ha az embeddingeknek, a dokumentumoknak és a metaadatnak egy kollekcióban kell élniük, és a csapat eleve többbérlős.
3. Válaszd olyan prototípushoz, amit később lecserélnek; a collection API elég kicsi ahhoz, hogy az újraírás egy nap, nem egy negyedév.
4. Kerüld el, ha a hibrid keresésnek ma a saját hálózatodon belül kell maradnia — a Search API ott nem elérhető.
5. Kerüld el, ha a korpusz már Postgresben van, és a pgvector dimenziókorlátja nem szúr.
6. Gondolj újra róla, amikor a korpusz átlép néhány millió darabot és a single node korlátai érvénybe lépnek, vagy amikor a visszaküldött GiB-onkénti forgalom uralja a számlát.

Források

1. Chroma dokumentáció: bevezetés
2. Chroma: architektúraáttekintés
3. Chroma: első lépések az SDK-val
4. Chroma: query és get
5. Chroma: metaadat-szűrés
6. Chroma Cloud: Search API áttekintés
7. Chroma Cloud: hibrid keresés RRF-fel
8. Chroma Cloud: árak
9. Chroma changelog