A probléma — Miért „buta" a legtöbb AI integráció?
A legtöbb vállalati AI integráció ma így működik: az LLM (nagy nyelvi modell) megkapja a felhasználó kérdését, lefuttat egy SQL lekérdezést, és visszaadja az eredményt. Ez egy jobb keresőmotor — de nem intelligencia.
A valódi probléma: az adatok önmagukban nem tudás. A tudás az adatok közötti kapcsolatokban rejlik.
Példa: Kovács Anna egy kontakt a CRM-ben. De mit tudunk valójában róla?
- A múlt héten kapott egy ajánlatot (deal)
- Erre válaszolt emailben, pozitívan (Gmail szál)
- Holnap van vele konzultáció (naptáresemény)
- A konzultáción részt vesz a főnöke is (résztvevő)
- Tavaly 3 projektben dolgoztunk együtt (előzmény)
Egy hagyományos CRM lekérdezés ezekből talán 1-2 adatot ad vissza. Egy Knowledge Graph-ra épült RAG rendszer mindet — mert érti a kapcsolatokat.
Knowledge Graph — Az üzleti kapcsolatok térképe
Mi ez konkrétan?
Egy Knowledge Graph (tudásgráf) két építőelemből áll:
- Csomópontok (nodes): entitások — kontaktok, emailek, naptáresemények, ügyletek, számlák, feladatok
- Élek (edges): kapcsolatok — KI küldött emailt KINEK, KI vett részt az ESEMÉNYEN, melyik DEAL tartozik melyik KONTAKTHOZ
┌────────────┐ KÜLDÖTT ┌────────────┐
│ Kovács Anna│───────────────▶│ Email │
│ (kontakt) │ │ "Ajánlat │
│ │◀───────────────│ OK!" │
└─────┬──────┘ CÍMZETT_VOLT └────────────┘
│
│ RÉSZTVEVŐ
▼
┌────────────┐ TARTOZIK ┌────────────┐
│ Konzultáció│ │ WebShop Pro │
│ (esemény) │───────────────▶│ (deal) │
│ 2025.11.04 │ │ 500.000 Ft │
└────────────┘ └────────────┘
Az adatmodell
Egy production-ready Knowledge Graph node az alábbi mezőkkel rendelkezik:
Az élek típusa jelzi a kapcsolat természetét: EMAILED, BOOKED, PAID, MENTIONS, ASSIGNED, ATTENDED_BY. Minden él súlyozott (weight), ami lehetővé teszi a releváns kapcsolatok priorizálását.
Miért nem Neo4j?
Jogos kérdés. A dedikált gráf-adatbázisok (Neo4j, Amazon Neptune) természetes választásnak tűnnek. A gyakorlatban azonban a PostgreSQL + pgvector kombináció meglepően jól működik, ha:
- Már van PostgreSQL a stack-ben (nem kell új infra)
- A gráf mérete entitásonként néhány 10.000 csomópont (nem milliók)
- Szükség van vektoros keresésre is (pgvector natívan támogatja)
- Egy adatbázisban szeretnénk tartani mindent (ops egyszerűség)
A trükk: rekurzív CTE-k (Common Table Expressions) PostgreSQL-ben képesek a többlépéses gráf-bejárásra, legrövidebb út keresésre, és ciklus-megelőzésre — lényegében ugyanazt nyújtják, amit a Neo4j Cypher nyelve BFS szinten.
A kulcs az absztrakciós réteg: ha a graph-service API jól van tervezve, a PostgreSQL → Neo4j váltás nulla kódváltozást igényel a hívó oldalon. Érdemes ezzel a tervezési elvvel indulni.
RAG — Hogyan kapja meg az AI a releváns kontextust?
A RAG lényege 30 másodpercben
A RAG (Retrieval-Augmented Generation) megoldja az LLM-ek legnagyobb korlátját: nem tudnak mindent, és ami a training data-ban nem volt, azt hallucinate-elhetik (kitalálják).
A RAG ezt úgy oldja meg, hogy a kérdés megválaszolása előtt kikeresi a releváns információt az adatbázisból, és ezt kontextusként adja az LLM-nek. Az LLM nem az „emlékezetéből" válaszol, hanem a kapott tények alapján.
Miért nem elég a sima keresés?
Két okból:
-
Szemantikus keresés > kulcsszavas keresés: Ha a felhasználó azt kérdezi „mit beszéltünk az ajánlatról?", a kulcsszavas keresés az „ajánlat" szót keresi. A szemantikus keresés megérti, hogy a „proposal", „árajánlat", „díjszabás" és akár a „küldöm a részleteket" is releváns lehet.
-
Kontextus-összefűzés: A vektor-keresés megtalálja a releváns emailt. De a Knowledge Graph hozzá tudja adni, hogy ki küldte, melyik deal-hez tartozik, és milyen naptáresemény kapcsolódik hozzá. Ez a kombináció teszi a választ igazán használhatóvá.
Az 5 lépéses RAG pipeline a gyakorlatban
Lépés 1 — Vektorizálás és szemantikus keresés
A felhasználó kérdése embedding-gé alakul (OpenAI text-embedding-3-small, 1536 dimenzió), majd a pgvector cosine similarity kereséssel megtalálja a legközelebb álló tartalmakat.
Paraméterek (production-ban tesztelve):
- Top-K: 8 eredmény
- Küszöbérték: 0.60 cosine similarity (ez alatt túl sok a zaj)
Lépés 2 — Gráf-bővítés (Graph Enrichment)
A top 3 vektor-találat szomszédjait is behúzzuk — 1 lépés mélységig, max 5 szomszéd csomópontonként.
A szomszédok öröklött relevancia-pontszámot kapnak: szülő_hasonlóság × 0.8. Ha egy email 92%-os relevanciával jött be, a hozzá kapcsolódó kontakt 73.6%-ot kap. Ez biztosítja, hogy a gráfból jövő kontextus nem nyomja el a közvetlen találatokat.
Lépés 3 — Deduplikáció és rangsorolás
A vektor- és gráf-eredmények összefésülése (vektoros találat prioritást élvez), csökkenő relevancia szerinti rendezés.
Kritikus elem: token-büdzsé kezelés. Az LLM kontextus-ablaka véges (és drága). A pipeline egy egyszerű, de hatékony becslést alkalmaz: (tartalom_hossz + cím_hossz + 50) / 4 token per csomópont (magyar szöveg ≈ 4 karakter/token). Ha a kumulatív token-szám eléri a 3000-es limitet, megáll — nincs overflow, nincs felesleges költség.
Lépés 4 — Kontextus-szöveg összeállítás
A kiválasztott csomópontokból strukturált Markdown kontextus készül az LLM számára:
## Releváns kontextus
### Email
**"RE: Ajánlat részletek"** [forrás: Gmail, relevancia: 92%]
> Szia, átnéztem az ajánlatot, számunkra elfogadható...
*Feladó: kovacs.anna@ceg.hu | Dátum: 2025-10-28*
Kapcsolatok: → KÜLDÖTT_EMAILT → Kovács Anna (ügyfél)
### Naptár
**"Konzultáció — Kovács Anna"** [forrás: Google Naptár, relevancia: 74%]
*2025-11-04 10:00–11:00 | Résztvevők: Kovács Anna, Dr. Szabó*
Lépés 5 — Forrás-attribúció
A frontend számára részletes forrás-objektumok készülnek: ikon, szín, kivonat, relevancia-százalék, és a bejutási útvonal (vector vagy graph). A felhasználó pontosan látja, honnan jött az információ — ez nem csak UX, hanem compliance-szempontból is kritikus.
Konkrét use case-ek
„Mit tudunk erről az ügyfélről?"
Hagyományos megoldás: CRM megnyitás → kontakt keresés → deal-ek áttekintés → email kliens váltás → keresés → naptár megnyitás → keresés. ~5-10 perc.
Knowledge Graph + RAG: Az AI egyetlen kérdésre összefoglalja a kontaktot, az utolsó emaileket, a nyitott deal-eket és a közelgő eseményeket — forrás-hivatkozásokkal. ~5 másodperc.
„Mi történt a múlt héten a WebShop Pro projekttel?"
A szemantikus keresés megtalálja a releváns emaileket és naptáreseményeket. A gráf-bővítés behúzza a kapcsolódó kontaktokat és a deal státuszát. Az AI kronológiai összefoglalót ad, hivatkozásokkal.
Proaktív figyelmeztetések
A gráf-statisztikák alapján az AI felismeri: „Kovács Anna-hoz 5 befejezetlen deal tartozik és 2 hete nem volt kommunikáció — érdemes felvenni a kapcsolatot." Ehhez nem kérdés kell — a rendszer időzítetten elemzi a gráfot.
Döntési pontok CTO-knak és IT vezetőknek
Embedding modell választás
Javaslat: Induljon text-embedding-3-small modellel — ez a legjobb kompromisszum költség, minőség és magyar nyelvi pontosság között. Később bármikor migrálható.
Vektor-adatbázis választás
Javaslat: 100.000 csomópont alatt a pgvector tökéletesen elegendő és drámaian egyszerűsíti az infrastruktúrát. Felette érdemes Qdrant-ot vagy Pinecone-t mérlegelni.
Aszinkron vs. szinkron embedding generálás
Az embedding generálás költséges (API hívás) és lassú (100-500 ms/darab). Két megközelítés:
- Szinkron: Az entitás létrehozásakor azonnal embedding-et generálunk. Egyszerű, de lassítja a write-okat.
- Aszinkron (ajánlott): Az entitás létrejön, az embedding egy queue-ba kerül (BullMQ, RabbitMQ, SQS), és háttérben generálódik. Rate limiting-gel, párhuzamos feldolgozással, retry logikával.
A production konfigurációnk: 3 párhuzamos worker, max 50 job/perc rate limit, Redis-alapú BullMQ queue. Ez biztosítja, hogy az OpenAI API rate limit-ek soha ne okozzanak hibát, miközben a legtöbb embedding 1 percen belül elkészül.
Biztonság és adatvédelem
Tenant izoláció
Minden Knowledge Graph lekérdezés providerId-vel szűrt. Egy multi-tenant rendszerben ez nem opcionális — ez az alap. A gráf-bejárás, a vektor-keresés és a RAG kontextus is csak az adott szolgáltató adatait éri el.
Adatminimalizálás a RAG-ban
A RAG pipeline nem az egész Knowledge Graph-ot küldi el az LLM-nek — csak a releváns, rangsorolt kontextust, token-limittel. Ez GDPR-szempontból adatminimalizálás, költség-szempontból pedig hatékonyság.
Embedding-ek és személyes adatok
Fontos tudni: az embedding nem visszafejthető szöveggé, de az eredeti tartalom mellette tárolódik. A GDPR törlési jog betartásához az entitás törlésekor a node-ot, a tartalmát és az embedding-et is törölni kell. A cascade delete (az élekre is) ezt automatikusan kezeli.
On-premise opció
A legérzékenyebb adatok esetén:
- Embedding: Ollama +
nomic-embed-textlokálisan, nulla adatkiáramlás - Vektor-keresés: pgvector a saját PostgreSQL-en
- Trade-off: gyengébb embedding-minőség, de teljes adatkontroll
Összegzés — Mikor érdemes belevágni?
A Knowledge Graph + RAG megéri, ha:
- Több adatforrás van (CRM + email + naptár + számlázó)
- A felhasználók kérdései kontextus-függők („mit tudunk róla?" típusú)
- Az adat-szilók egyértelmű fájdalompontot jelentenek
- Fontos a forrás-átláthatóság és auditálhatóság
Még korai, ha:
- Egyetlen, jól strukturált adatforrás van — itt elég egy sima SQL keresés
- Nincs 500+ entitás — a gráf nem hoz értéket kis adatmennyiségnél
- Nem fontos a szemantikus keresés — kulcsszavas keresés is elegendő
A legfontosabb tervezési elvek
- Absztrakciós réteg a gráf-adatbázis fölé — ma PostgreSQL, holnap Neo4j, nulla kódváltozás
- Aszinkron embedding pipeline — queue + rate limiting + retry
- Token-büdzsé kezelés a RAG-ban — ne az LLM döntse el, mit olvas, mi döntjük el, mit kap
- Relevancia-öröklődés a gráf-bejárásban — decay factor a 2. szintű találatokra
- Forrás-attribúció a felületen — a felhasználó mindig tudja, honnan jött az adat
A cikk az AIMY projekt Knowledge Graph implementációjának tapasztalatain alapul — PostgreSQL + pgvector, OpenAI embeddings, BullMQ pipeline.
Ha hasonló megoldáson gondolkodtok, vegyétek fel velünk a kapcsolatot!