RAG rendszerek: Hogyan építs intelligens vállalati tudásbázist?

Miért nem elég az LLM önmagában?

Az LLM-ek (GPT-5.2, Claude Sonnet 5, Gemini 3 Pro) hatalmas tudással rendelkeznek - de két alapvető korlátjuk van:

1. Tudás határidő (knowledge cutoff): A modell csak a tanítási adatokig “tud”. Ami utána történt, arról nem tud.
2. Hallucináció: Ha nem tudja a választ, gyakran kitalál egyet - magabiztosan és meggyőzően, de hamisan.

A vállalati környezetben ez katasztrofális. Ha az AI chatbotod hamis információt ad egy ügyfélnek, vagy elavult belső dokumentumra hivatkozik, az üzleti kockázat.

A RAG (Retrieval Augmented Generation) pont ezt a problémát oldja meg: ahelyett, hogy az LLM a saját “fejéből” válaszolna, előbb visszakeresi a releváns dokumentumokat, majd azok alapján generálja a választ. Nem kitalál - hanem hivatkozik.

A RAG pipeline lépésről lépésre

Egy RAG rendszer két fő fázisból áll: indexelés (egyszeri) és lekérdezés (minden kérdésnél).

1. fázis: Indexelés

Dokumentumok → Chunking → Embedding → Vektor adatbázis

Dokumentum betöltés (Document Ingestion)

Az első lépés: összegyűjteni a tudásbázis alapját képező dokumentumokat. Ezek lehetnek:

• PDF-ek (szabályzatok, szerződések, dokumentációk)
• Weboldalak (help center, FAQ)
• Confluence/Notion oldalak
• Email archívumok
• Adatbázis rekordok

Minden forráshoz más-más loader kell. A LangChain és a LlamaIndex is rengeteg beépített loader-t kínál.

Chunking (darabolás)

Az LLM kontextusablaka korlátozott, és a visszakeresés pontossága drasztikusan romlik, ha hatalmas szövegblokkokat tárolunk. A megoldás: a dokumentumokat kisebb darabokra (chunk) vágjuk.

A chunking stratégia kritikusan fontos - a kutatások szerint a chunk méret és az átfedés mértéke legalább akkora hatással van a visszakeresés minőségére, mint maga az embedding modell.

Főbb stratégiák:

Stratégia	Leírás	Mikor használd
Fix méretű	512 token, 10-20% átfedéssel	Általános célú, jó kiindulópont
Szemantikus	Mondatok csoportosítása hasonlóság alapján	Vegyes tartalmú dokumentumok
Rekurzív	Fejezet → bekezdés → mondat szinten bontja	Strukturált dokumentumok
Agentic	LLM dönt a vágási pontokról	Komplex, változatos dokumentumok
Late chunking	Előbb az egész dokumentum embedding, utána vágás	Kontextus-érzékeny tartalom

Gyakorlati javaslat: Kezdj 512 tokenes fix méretű chunk-okkal, 10-20% átfedéssel. Ez a legtöbb use case-re jól működik. Ha a minőség nem kielégítő, próbálj szemantikus chunking-ot.

Embedding generálás

Minden chunk-ot egy embedding modell alakít vektorrá - egy sűrű, numerikus reprezentáció, ami megragadja a szöveg jelentését. A hasonló jelentésű szövegek vektorai közel kerülnek egymáshoz a vektortérben.

Népszerű embedding modellek (2026):

• OpenAI text-embedding-3-large: 3072 dimenzió, kiváló minőség, fizetős API
• OpenAI text-embedding-3-small: 1536 dimenzió, jó ár-érték arány
• Cohere Embed v4: Multimodális (szöveg + kép), 128K kontextus, 100+ nyelv támogatás
• Voyage AI voyage-3-large: SOTA teljesítmény 100 dataseten, Matryoshka dimenziók (256-2048), kvantizálás támogatás
• Open-source: nomic-embed-text-v2-moe (MoE architektúra, többnyelvű), BGE-M3 (dense + sparse + multi-vector keresés, 100+ nyelv)

Fontos: Az embedding modell választása végleges - ha később váltasz, az összes dokumentumot újra kell embedding-elned.

Vektor adatbázis

Az embedding-eket egy vektor adatbázisba töltöd, ami gyors hasonlóság-keresést tesz lehetővé (cosine similarity, dot product, euclidean distance).

Vektor adatbázisok összehasonlítása (2026):

Adatbázis	Típus	Erősség	Mikor válaszd
Pinecone	Managed SaaS	Skálázás, egyszerűség	Ha nem akarsz infrastruktúrát kezelni
Qdrant	Open-source	Teljesítmény, szűrés	Ha fontos a sebesség és a self-hosting
Weaviate	Open-source	Hibrid keresés, moduláris	Ha keyword + vektor keresés kell
ChromaDB	Open-source	Egyszerűség, fejlesztőbarát	Prototípus, kis-közepes méret
Milvus	Open-source	Enterprise skála, 35K+ GitHub star	Nagy adatmennyiség, enterprise
pgvector	PostgreSQL ext.	Meglévő PG infrastruktúra	Ha már van PostgreSQL-ed

Benchmark adatok (2026): A Pinecone ~50 000 insertion/s és ~5 000 query/s teljesítményt mutat, a Qdrant hasonló kategória (~45 000 / ~4 500), míg a ChromaDB fejlesztői kényelemben erős, de nagyobb adatoknál lassabb (~25 000 / ~2 000).

2. fázis: Lekérdezés

Kérdés → Embedding → Vektor keresés → Top-K dokumentumok → LLM válaszgenerálás

1. A felhasználó kérdését embedding-eled (ugyanazzal a modellel, mint az indexelésnél)
2. Vektor keresés: megkeresed a leginkább hasonló chunk-okat (tipikusan top 3-10)
3. A talált chunk-okat kontextusként beilleszted az LLM promptjába
4. Az LLM a kontextus alapján generálja a választ

# Egyszerű RAG lekérdezés (pszeudokód)
question = "Mi a visszaküldési szabályzatunk?"

# 1. Kérdés embedding
question_embedding = embed(question)

# 2. Vektor keresés
relevant_chunks = vector_db.search(question_embedding, top_k=5)

# 3. Prompt összeállítás
prompt = f"""Az alábbi dokumentumok alapján válaszolj a kérdésre.
Ha a dokumentumok nem tartalmazzák a választ, mondd el, hogy nem tudod.

Dokumentumok:
{relevant_chunks}

Kérdés: {question}"""

# 4. LLM válaszgenerálás
answer = llm.generate(prompt)

Hibrid keresés: vektor + keyword

A tiszta vektor keresés nem mindig elég. Ha a felhasználó pontos kifejezést keres (pl. “GDPR 17. cikk”), a szemantikus keresés nem biztos, hogy megtalálja - mert a vektor keresés a jelentésre optimalizál, nem a pontos szóegyezésre.

A hibrid keresés kombinálja:

• Vektor keresés: Szemantikus hasonlóság (a jelentés alapján)
• Keyword keresés (BM25): Pontos szóegyezés (a szavak alapján)

A két eredményt reciprocal rank fusion (RRF) vagy súlyozott átlag segítségével kombinálod. A Weaviate és a Qdrant natívan támogatja a hibrid keresést.

Reranking: a második szűrő

A vektor keresés gyors, de nem mindig pontos. A reranking egy második, pontosabb modell, ami a visszakeresett dokumentumokat újra rangsorolja a kérdés tükrében.

Népszerű reranker modellek:

• Cohere Rerank v3.5: SaaS, egyszerű API, kiváló minőség, reasoning képességek
• BGE Reranker v2: Open-source, jó ár-érték arány
• Cross-encoder modellek: Lassabb, de pontosabb, mint a bi-encoder embedding

A reranking tipikusan 20-30%-os javulást hoz a válaszok relevanciájában - kis befektetés, nagy hatás.

Advanced RAG minták

Multi-step RAG

A felhasználó kérdése nem mindig egyértelmű. A multi-step RAG előbb tisztázza a kérdést (query rewriting, query expansion), majd több körben keres.

Eredeti kérdés: "Mi a helyzet a projekttel?"
  → Átírt kérdés 1: "Mi az Alpha projekt jelenlegi státusza?"
  → Átírt kérdés 2: "Mik az Alpha projekt nyitott feladatai?"
  → Egyesített válasz a két keresés alapján

Self-RAG

Az LLM kiértékeli a saját válaszát: ellenőrzi, hogy a visszakeresett dokumentumok valóban relevánsak-e, és hogy a válasz hűen tükrözi-e a forrásokat. Ha nem, újra keres vagy korrigál.

Agentic RAG

Az agent önállóan dönt a keresési stratégiáról: melyik forrásban keressen, milyen szűrőket alkalmazzon, szükséges-e többkörös keresés. Ez a ReAct pattern és a RAG kombinációja.

Graph RAG

A dokumentumok közötti kapcsolatokat is modelezi (knowledge graph). Különösen hasznos, ha az entitások közötti összefüggések fontosak - pl. “Ki dolgozik az Alpha projekten?” típusú kérdéseknél, ahol a válasz több dokumentumban szétszórva található.

Kiértékelés: honnan tudod, hogy jól működik?

A RAG rendszer kiértékelése nem triviális. A legfontosabb metrikák:

Faithfulness (hűség)

A generált válasz megfelel-e a forrás dokumentumoknak? Nem hallucinálja-e az LLM az információt?

Answer Relevancy (válasz relevancia)

A válasz tényleg a kérdésre válaszol-e? Nem tér-e el a lényegtől?

Context Precision (kontextus pontosság)

A visszakeresett dokumentumok valóban relevánsak-e a kérdéshez?

Context Recall (kontextus teljesség)

A rendszer megtalálta-e az összes releváns dokumentumot?

Kiértékelő keretrendszerek: A RAGAS és a LangSmith automatizált kiértékelést biztosít ezekre a metrikákra.

Gyakorlati példa: vállalati tudásbázis

Tegyük fel, hogy egy 200 fős cég belső tudásbázisát építed RAG-gal. Így néz ki a projekt:

1. Adatforrások

• 500+ belső dokumentum (PDF, Word)
• Confluence wiki (300+ oldal)
• Korábbi support ticket-ek (5000+)
• Email archívum (válogatott)

2. Technológiai stack

• Embedding: OpenAI text-embedding-3-small (költséghatékony)
• Vektor DB: Qdrant (self-hosted, Docker)
• LLM: Claude Sonnet 5 (kiváló reasoning, magyar támogatás)
• Framework: LangChain v0.3 + FastAPI
• Frontend: Egyedi chat interface

3. Pipeline

Confluence API + PDF-ek + Support ticketek
    ↓
Chunking (512 token, 10% overlap)
    ↓
Embedding generálás (text-embedding-3-small)
    ↓
Qdrant vektor DB
    ↓
Hibrid keresés (vektor + BM25)
    ↓
Reranking (Cohere Rerank v3.5)
    ↓
LLM válaszgenerálás (Claude Sonnet 5)
    ↓
Válasz + forráshivatkozások

4. Költségbecslés (havi)

• Qdrant hosting (VPS): ~$30-50/hó
• OpenAI embedding API: ~$10-30/hó (500 dokumentum esetén)
• Claude API: ~$50-200/hó (napi 100-500 kérdés esetén)
• Összesen: ~$90-280/hó

Ez töredéke annak, mint amennyibe egy dedikált support csapattag kerülne.

Mikor NE használj RAG-ot?

A RAG nem mindenre jó. Ne használd, ha:

• A kérdések egyszerűek és statikusak: Ha egy FAQ oldal megoldja a problémát, ne építs RAG-ot
• Nincs elég adat: 10-20 dokumentumból nem érdemes RAG-ot építeni - tedd be a teljes szöveget a promptba
• Valós idejű adat kell: A RAG a dokumentumokat tárolja, nem a valós idejű adatokat. Ehhez API integráció + agent kell
• 100%-os pontosság kell: A RAG csökkenti a hallucinációt, de nem szünteti meg. Kritikus döntéseknél emberi jóváhagyás kell
• Az adatok strukturáltak: Ha SQL-ből lekérdezhető az adat, ne vektorizáld - használj Text-to-SQL megoldást

Költségek és skálázás

Embedding költségek

Az embedding egyszeri költség (hacsak nem frissíted gyakran a dokumentumokat):

• OpenAI text-embedding-3-small: ~$0.02 / 1M token
• OpenAI text-embedding-3-large: ~$0.13 / 1M token
• Open-source (self-hosted): infrastruktúra költség, de token díj nélkül

LLM költségek (válaszgenerálás)

Ez a fő futó költség, mert minden kérdésnél LLM hívás kell:

• Claude Sonnet 5: ~$3 / 1M input token, $15 / 1M output token
• GPT-5.2: ~$1.75 / 1M input token, $14 / 1M output token
• GPT-5 mini: ~$0.25 / 1M input token, $2 / 1M output token
• Open-source (Llama 4, Mistral Large 2): infrastruktúra költség, de API díj nélkül

Skálázási tippek

• Cache: Gyakori kérdésekre cache-eld a válaszokat
• Kisebb modell: A válaszgeneráláshoz nem mindig kell a legerősebb modell
• Batch indexelés: Ne real-time-ban embedding-elj, hanem ütemezetten
• Chunk méret optimalizálás: Kisebb chunk = több vektor = drágább keresés, de pontosabb

Összefoglalás

A RAG nem varázslat - de a legjobb módszer arra, hogy az LLM-eket a saját adataiddal gazdagítsd. A kulcs a helyes architektúra: jó chunking, megfelelő embedding modell, gyors vektor adatbázis, és a hibrid keresés + reranking kombináció.

2026-ban a RAG már nem kísérleti technológia, hanem production-ready megoldás, amit a világ legnagyobb vállalatai is használnak. A kérdés nem az, hogy “működik-e”, hanem az, hogy “hogyan illeszd be a te rendszeredbe”.

Ha RAG-alapú tudásbázist vagy chatbotot tervezel, az AppForge csapata segít a teljes implementációban - az adatfeldolgozástól a vektor adatbázis kiválasztásán át a production deployment-ig.