Vissza a blogra
Szemantikus keresésEmbeddingpgvectorRAGKnowledge GraphAI architektúra

Szemantikus Keresés és Embedding — Miért nem elég a kulcsszó-keresés az AI korszakában?

ÁZ&A
Ádám Zsolt & AIMY
||5 perc

Amikor a keresés nem érti, amit keresünk

Képzeld el: egy AI asszisztenst megkérdeznek — „Mikor volt utoljára Kiss Anna?"

A hagyományos kulcsszó-keresés nem talál semmit. Az „utoljára" szó nem szerepel egyetlen naptárbejegyzésben sem. A szemantikus keresés viszont megérti a jelentést: megtalálja Kiss Anna legutóbbi naptárbejegyzését, mert felismeri, hogy az „utoljára" = legutóbbi időpont.

Ez a különbség a szó-egyezés és a jelentés-egyezés között — és ez az alapja minden modern AI-alapú keresési architektúrának.


Mi az embedding?

Az embedding egy szöveg átalakítása numerikus vektorrá — jellemzően 256-3072 dimenziós térben. A lényeg: a szemantikailag hasonló szövegek vektorai közel kerülnek egymáshoz, a különbözőek távol.

Gyakorlatilag a gép így „érti meg" a szöveg jelentését — nem a betűket hasonlítja össze, hanem a fogalmakat.

„Mikor volt utoljára Kiss Anna?"   →   [0.23, -0.41, 0.87, ...]   ←─┐
                                                                       │ közel!
„Kiss Anna legutóbbi időpontja"     →   [0.25, -0.39, 0.85, ...]   ←─┘

„Marketing költségvetés 2026"       →   [0.71, 0.12, -0.33, ...]   ← távol

A két hasonló kérdés vektorai szinte megegyeznek, a teljesen más témájú szöveg vektora viszont távol van. A hasonlóságot cosine similarity-vel mérjük: 1 = tökéletesen hasonló, 0 = nincs kapcsolat.


Miért nem elég önmagában a vektor-keresés?

A szemantikus keresés megtalálja a hasonló tartalmakat — de az üzleti kérdések gyakran kapcsolatokat kérnek:

  • „Mikor volt utoljára Kiss Anna, és mit csináltunk?" → Kell a naptáresemény + a kliensadatok + a jegyzet
  • „Mennyit költött márciusban?" → Kell a kliens + a számlák + a foglalások

Ezeket egy knowledge graph (tudásgráf) oldja meg: az üzleti entitások (email, naptár, kliens, számla) csomópontokként, a köztük lévő kapcsolatok élekként épülnek fel — és a keresés mindkettőt használja.

Keresési megközelítés Mit talál? Üzleti kérdésre válaszol?
Kulcsszó (LIKE, tsvector) Pontos szó-egyezés Ritkán
Vektor (embedding) Szemantikailag hasonló Részben
Vektor + Knowledge Graph Hasonló + kapcsolódó entitások Igen, kontextussal

pgvector — vektor-keresés a meglévő PostgreSQL-ben

Nem kell külön vektor-adatbázis (Pinecone, Qdrant). Ha már van PostgreSQL-ed, a pgvector extension ingyen, egyetlen CREATE INDEX paranccsal bekapcsolható — és a vektorok ugyanabban az adatbázisban élnek, mint az üzleti adatok.

Ez azt jelenti: egy egyetlen SQL lekérdezéssel végezhető vektor-keresés + gráf-bejárás + tenant-szűrés, hálózati latencia nélkül.

Szempont pgvector Dedikált vektor DB
Költség $0 (extension) $25-70+/hó
SQL integráció Natív (JOIN, WHERE) Nincs
Multi-tenant szűrés WHERE provider_id = Namespace / payload
Knowledge graph Ugyanaz az adatbázis Külön rendszer kell
Skálázhatóság ~5M vektorig kiváló 100M+

Nagyvállalati (100M+ vektor) méretben a dedikált megoldások nyernek — de a legtöbb KKV és mid-market SaaS számára a pgvector bőven elég, és jelentősen egyszerűbb az üzemeltetés.


A RAG pipeline röviden — 5 lépésben

A Retrieval-Augmented Generation (RAG) pipeline az, ami összeköti a keresést az LLM-mel:

  1. Input validáció — A rövid üzenetek (1-2 karakter) nem hordoznak szemantikus tartalmat, kiszűrjük
  2. Vektor-keresés — A kérdés embedding-jét összehasonlítjuk az adatbázis vektoraival (cosine similarity > 0.60, top-8)
  3. Gráf-gazdagítás — A top-3 találat szomszédait is betöltjük (1-hop neighbors, 0.8 decay factor)
  4. Deduplikáció + token budget — Egyedi csomópontok, relevancia szerinti sorrendben, 3000 token limiten belül
  5. Formázás + injektálás — Markdown kontextus, típus szerinti csoportosítva, az LLM system message-be

Az eredmény: az LLM nem hallucinál, hanem a valós üzleti adatokra építve válaszol — forrásmegjelöléssel.


3 gyakorlati tanulság

1. Kezdj egyszerűen

pgvector + OpenAI text-embedding-3-small + cosine search — ez 30 perc alatt működik, és a legtöbb KKV use case-re elegendő. Ne tervezz túl!

2. Ne darabolj, amit nem kell

Az emailek, naptáresemények, ügyfélprofilok természetes egységek — nem kell 500 tokenes darabokra vágni őket. Az entitás-alapú megközelítés (1 üzleti objektum = 1 node + 1 embedding) szimplább és jobb eredményt ad.

3. A gráf-gazdagítás a valódi differenciátor

A „Ki?" „Mikor?" „Mennyit?" típusú kérdésekre a vektor-keresés önmagában gyenge — a szomszédok betöltése drámai minőségjavulást hoz, minimális többletköltséggel.


Mélyebben érdekel a téma?

Ez a cikk a Szemantikus Keresés és Embedding Stratégiák — Whitepaper rövidített változata. A teljes whitepaper 15 fejezeten keresztül végigvezeti a részleteket: embedding-modell összehasonlítás, pgvector indexelés (IVFFlat vs. HNSW), BullMQ async pipeline, hybrid keresés (RRF), re-ranking, RAGAS kiértékelés, GraphRAG, produkciós monitoring és embedding drift kezelés.


Szeretnéd bevezetni a szemantikus keresést a saját rendszeredben? Az Atlosz Interactive csapatának produkciós tapasztalata van pgvector, knowledge graph és RAG pipeline architektúrával. Vedd fel velünk a kapcsolatot egy ingyenes technikai konzultációért!

Megosztás:
Vissza a blogra