Vektoradatbázis üzemeltetés: Qdrant, ChromaDB

Amit egy jól működő RAG-hoz építünk

Egy chatbot, amely a cég saját dokumentumaiból válaszol, többre van szüksége, mint egy vektoradatbázisra. Felépítjük a teljes láncot: kinyerés PDF-ekből, szerződésekből vagy belső oldalakról, kontrollált átfedéssel darabolás, embeddingek generálása, indexelés Qdrantban, valamint hibrid keresés, amely a szemantikai közelséget a pontos kulcsszó-egyezéssel kombinálja. Ehhez metaadat alapú szűrést is hozzáadunk, hogy a felhasználó ne kapjon részletet olyan dokumentumból, amelyhez nincs jogosultsága. A pipeline minden lépését újrafuttathatóra tervezzük, hogy egy hibás forrásdokumentum javítása után az újraindexelés ne igényeljen kézi beavatkozást.

• Ismételhető betöltési folyamat, újraindexeléssel a dokumentumok frissítésekor
• Hibrid keresés: vektoros közelség plusz lexikális egyezés a pontos kifejezésekhez
• Metaadat szerinti szűrés: részleg, ügyfél, bizalmassági szint
• A válaszminőség kiértékelése valós kérdésekből álló halmazon

Bevált gyakorlatok, amelyeket alkalmazunk

A RAG-projektek ritkán a modell miatt buknak el; az adatok és a hozzáférés miatt buknak el. Az alábbi listát minden átadásnál alkalmazzuk, és beírjuk a dokumentációdba, a válaszminőséget mérő kérdéshalmazzal együtt. Egy kezdetben rögzített mérés nélkül minden modell-, darabolási vagy keresési paraméterváltoztatás javulásnak tűnik, de a csapatból senki sem tudja bizonyítani, hogy valóban az. Ezért minden bevezetés része a kiértékelő kérdéshalmaz elkészítése, még a részletek finomhangolása előtt.

• Hozzáférés csak privát hálózaton vagy VPN-en, plusz API-kulcs minden fogyasztónak
• Rendszeres pillanatképek a kollekciókról, tesztelt visszaállítással
• Vektorkvantálás ott, ahol memóriát takarít meg relevanciavesztés nélkül
• Kötelező metaadat-szűrés, hogy a válaszok tiszteletben tartsák a hozzáférési jogokat
• Személyes adatok anonimizálása indexelés előtt, ha a cél nem igényli azokat

Adatok az EU-ban, AI Act és GDPR

A magyarországi csapatok fő oka, hogy saját infrastruktúrára hozzák a RAG-jukat, az adatok feletti kontroll. A dokumentumok Frankfurtban maradnak, az embeddingek igény szerint helyben, GPU szerveren generálhatók, és ha mégis külső modellt használsz, pontosan megmutatjuk, milyen szövegrészletek hagyják el a rendszert. Az adatfeldolgozási szerződést és a nemzetközi transzferhez szükséges klauzulákat megkapod, az üzemeltetés pedig az ISO 27001-hez igazodó gyakorlat szerint történik. Az EU AI Act kapcsán az számít, hogy dokumentálni tudod az adatok útját.

A beleértett órák és a GPU szerverek

A telepítés, a kezdeti indexelés és a finomhangolás a havi keretbe tartozik: 1–8 óra a VPS-terveken, csomagtól függően 5–10 óra a dedikált és 10 óra a GPU szervereken. Az ügyfélpanel DevOps szolgáltatások menüpontjából kéred, a te javasolt határidőddel. Helyben futó embedding-modellekhez GPU szervert javaslunk, ahol a 10 órás keret rendszerint a beállítást és az újraindexeléseket fedezi. Az órák nem gördülnek át; ami meghaladja a keretet, azt külön számlázzuk.

Hogyan dolgozunk

1. Igényled a panelből

   Elmondod, milyen dokumentumokat szeretnél lekérdezhetővé tenni, milyen mennyiségben és ki férhet hozzájuk, majd javasolsz egy határidőt az ügyfélpanelből.

2. Egyeztetjük a kereteket

   Kiválasztjuk a te adatmennyiségedhez illő vektoradatbázist és embedding-modellt, meghatározzuk a kiértékelő kérdéshalmazt, és megbecsüljük a szükséges órákat.

3. Megvalósítjuk és mérjük a relevanciát

   Indexeljük a dokumentumokat, beállítjuk a hibrid keresést és a metaadat-szűrést, majd lefuttatjuk a kiértékelést, és stabil eredményig finomítjuk a darabolást.

4. Dokumentálva átadjuk

   Megkapod a folyamatot a saját tárolódban, a kollekciók sémáját, a hozzáférési szabályokat, az újraindexelési eljárást és a kiértékelési riportot.

Felhasználási esetek

Technológiák

• Qdrant
• ChromaDB
• pgvector
• PostgreSQL
• Ollama
• vLLM
• LiteLLM
• Prometheus
• Grafana

Gyakori kérdések

• Qdrant vagy ChromaDB: melyik jobb RAG-hoz?

  A ChromaDB kényelmes prototípusokhoz és kisebb adatmennyiséghez, néhány perc alatt telepíthető. A Qdrant jobban bírja az éles terhelést: hatékony metaadat-szűrés, kvantálás, pillanatképek, replikáció. Ha a projekt túljut a bemutató szakaszon, egyből Qdrantra építünk.

• Mi az a vektoradatbázis?

  Olyan adatbázis, amely vektorokat, vagyis szövegek vagy képek numerikus reprezentációit tárolja, és gyorsan megtalálja a lekérdezéshez legközelebb álló elemeket. Ez teszi lehetővé a jelentés szerinti keresést, nem csak a szó szerinti egyezést, és ez az alap, amire minden RAG-rendszer épül.

• Az EU-ban tarthatom a RAG adatait, külső szolgáltató nélkül?

  Igen. A vektoradatbázis és a dokumentumok a frankfurti szervereden maradnak, az embedding-modell pedig helyben, GPU szerveren futhat. Ha a válaszgeneráláshoz mégis külső modellt választasz, pontosan dokumentáljuk, milyen szövegrészletek kerülnek elküldésre.

• pgvector vagy Qdrant?

  A pgvector jó választás, ha már van PostgreSQL-ed, és néhány tízezer szövegrészleted: egyetlen rendszert kell üzemeltetni, közös mentéssel. A Qdrant nagyobb adatmennyiségnél, összetett metaadat-szűrésnél és állandó keresési forgalomnál lesz jobb, mert erre tervezték.

• Miért kell GPU szerver az embeddinghez?

  Nem mindig kell. Ritka újraindexeléshez elegendő egy VPS. A GPU akkor indokolt, ha gyakran indexelsz újra, nagy dokumentummennyiséggel dolgozol, vagy szeretnéd helyben futtatni a választ generáló modellt is, hogy semmi ne kerüljön ki az infrastruktúrádból.

• Honnan tudom, hogy a válaszok helyesek?

  Az elején rögzítünk egy elvárt válaszokkal ellátott kérdéshalmazt, és minden darabolási, modell- vagy keresési paraméterváltoztatás előtt és után ezen mérünk. Mérés nélkül minden módosítás javulásnak tűnhet, de senki sem tudja bizonyítani az ellenkezőjét.