A vektoradatbázis egy speciális adattár, amit nem szöveg-egyezésre, hanem jelentés-egyezésre tervezte. A klasszikus adatbázis (MySQL, PostgreSQL) így keres: „add ide mindazokat a rekordokat, ahol a ‘név’ mező pontosan ‘Kovács János'”. A vektoradatbázis viszont így keres: „add ide a 10 legközelebb-jelentésű rekordot ehhez a kérdéshez”. Ez teszi lehetővé, hogy egy AI-chatbot felfogja, ha valaki „Kovács úr”-ról ír, miközben az adatbázisban „Kovács János” szerepel — ugyanaz a jelentés, más szavakkal.
Így is ismerheted
Magyarul vektor-adatbázis, vektor alapú adatbázis, ritkábban jelentésalapú adattár. Angolul vector database, vector store, néha embeddings database. A „vektor” itt egy számokból álló sorozat (általában 384-3072 dimenziós), ami egy szöveg vagy kép jelentésének matematikai reprezentációja. A vektorok hasonlóságát egy egyszerű matematikai módszerrel (cosine similarity) tudjuk mérni — két közeli vektor jelentésben is hasonló dokumentum.
Mire jó ez egy üzleti rendszer számára?
A vektoradatbázis ott jön elő, ahol szöveges, képes vagy kevert tartalom között kell keresni, és a klasszikus kulcsszó-egyezés kevés. Az ilyen szituációk egyre gyakoribbak az AI-világban:
Egy AI tudásbázis-ban, ahol a felhasználó természetes nyelven kérdez (pl. „mi a szabadságkiadás folyamata?”) — a vektoradatbázis megtalálja a releváns szabályzat-szelet, akkor is, ha a dokumentumban „szabadság-igénylés”-ként szerepel.
Egy termék-ajánló rendszer-ben, ahol egy vásárlót hasonló termékek érdekelnek — a vektoradatbázis a termékleírások jelentés-alapú hasonlóságát keresi, nem csak a kategória-egyezést.
Egy kép-keresőben, ahol egy beadott képhez hasonló képeket keresel — a vektoradatbázis a vizuális jellemzők alapján találja meg őket.
Egy spam-detekcióban, ahol új e-mailt nézel, és a vektor-keresés alapján mondod meg, hasonlít-e korábbi spam-üzenetekre.
Hogyan működik egy vektoradatbázis?
Három lépéses folyamat. Először minden tartalomdarabot (mondat, bekezdés, kép, hangfájl) átalakítasz egy vektorrá egy embedding-modell segítségével (OpenAI text-embedding, BERT, Sentence Transformers, CLIP képekhez). Másodszor ezeket a vektorokat eltárolod egy vektoradatbázisban, ami speciálisan a magas dimenziós keresésre van optimalizálva (HNSW, IVF, vagy más indexálási algoritmussal). Harmadszor, ha valaki kérdez, a kérdést is vektorba alakítod, és az adatbázis adja vissza a legközelebbi N elemet — tipikusan milliszekundumok alatt akár több millió rekordon.
Praktikusan a fejlesztő egy SDK-n vagy REST API-n keresztül kommunikál a vektoradatbázissal:
// Beillesztés
db.upsert({ id: 'doc1', vector: [0.12, -0.43, ...], metadata: {...} });
// Keresés
const results = db.query({
vector: queryVector,
topK: 10,
filter: { kategoria: 'HR' }
});Milyen vektoradatbázist válassz?
A piac négy nagyobb opciót kínál:
- Pinecone — felhős, fully managed, gyors, sok integráció. Free csomag indító projektre elég. Drágább nagy mennyiségnél.
- Qdrant — Rust-ban írt, önhostolható, open-source, gyors. GDPR-barát, mert lokálisan futtatható.
- Weaviate — open-source, Go-ban, sok beépített modell-integráció.
- pgvector — egy PostgreSQL-bővítmény, ha már van Postgres-ed. Egyszerűbb integráció, kis-közepes adatmennyiségig.
Választás-szempontok: mekkora a forgalom (másodperc/lekérdezés), mennyi adat (10 ezer vagy 10 millió vektor), és kell-e európai régió (GDPR). A 90%-os esetre Qdrant (önhostolva) vagy Pinecone tökéletes; nagyon kis projektre a pgvector elegáns megoldás.
Hol illeszkedik egy AI-architektúrába?
A leggyakoribb használati eset a RAG (Retrieval Augmented Generation) architektúra. Itt a folyamat: a céges dokumentumokat embedding-be alakítjuk → tároljuk a vektoradatbázisban → felhasználói kérdést is embedding-be alakítjuk → kikeressük a 5-10 legközelebbi dokumentum-szeletet → ezeket odaadjuk a nyelvi modellnek (GPT-4, Claude) → ő ezekből és a kérdésből összerakja a választ.
A vektoradatbázis tehát NEM az AI-rendszer, csak a kereső réteg. A nyelvi modell adja a választ; a vektoradatbázis biztosítja, hogy a megfelelő, releváns kontextust megtalálja hozzá.
Mire figyelj a használatánál?
A legfontosabb buktató a chunk-méretválasztás. Ha túl rövid darabokra (50-100 szó) bontod a dokumentumokat, a vektor sok kontextust elveszít. Ha túl hosszúra (2000+ szó), a kérdéshez kevésbé pontosan illeszkedő darabokat ad vissza. A 300-500 szavas chunk-méret a klasszikus ajánlás, némi átfedéssel (overlap) a darabok között.
A második a metaadat-szűrés. A vektoradatbázis nemcsak vektorokat tárol, hanem metaadatokat is (pl. „kategória: HR”, „létrehozó: marketing csapat”, „nyelv: magyar”). Egy jól megírt lekérdezés a vektor-keresés mellett metaadat-szűrést is alkalmaz: „kérlek, csak a HR-kategória dokumentumaiból keress”. Enélkül a rendszer 10 ezer rekord között szétszedi a relevanciát.
A harmadik a frissítés. A vektorok generálása költséges (OpenAI API-hívás minden chunk-ra), és minden dokumentum-frissítésnél új embedding-et kell generálni. Tervezz be egy incremental update mechanizmust, ami csak a változott darabokra fut le.
A negyedik a biztonság. A vektoradatbázis sokszor érzékeny adatot tárol — szerződéseket, ügyfél-információkat. Ha cloud-szolgáltatót (Pinecone) használsz, gondold át a GDPR-szempontokat. Európai régió, titkosított kapcsolat, audit-naplók — ezek kritikusak.
Ha vektoradatbázist tartalmazó AI-megoldást szeretnél építeni — tudásbázis, ajánlórendszer, AI-chatbot —, az AI és automatizáció szolgáltatásunk pont erre épül: a teljes stack felépítése a dokumentum-betöltéstől a felhasználói felületig. Egy weboldali AI-megjelenéshez (chatbot, kereső) a chatbot fejlesztés a relevánsabb. Részletesebben a vektor-alapú keresésről: pinecone.io/learn/vector-database.
