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

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

Az LLM-eknek (GPT-5.2, Claude Sonnet 5, Gemini 3 Pro) hatalmas tudása van — két alapvető korlát mellett:

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, meggyőzően, hamisan.

Vállalati környezetben ez katasztrofális. Ha az AI chatbotod hamis információt ad egy ügyfélnek, az üzleti kockázat.

A RAG (Retrieval-Augmented Generation) ezt oldja meg: az LLM ahelyett, hogy 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 — hivatkozik.

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

Két fázis: 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

Tudásbázis-források: PDF (szabályzatok, szerződések), weboldalak (help center, FAQ), Confluence/Notion oldalak, email archívum, adatbázis rekordok. Minden forráshoz más loader kell — a LangChain és a LlamaIndex sokat kínál beépítve.

Chunking (darabolás)

Az LLM kontextusablaka korlátozott, és a visszakeresés pontossága drasztikusan romlik nagy szövegblokkokon. A chunking kritikus — a kutatások szerint a chunk méret legalább akkora hatással van a visszakeresés minőségére, mint az embedding modell.

Embedding generálás

Minden chunkot egy embedding modell alakít vektorrá — sűrű numerikus reprezentáció, ami a szöveg jelentését ragadja meg. A hasonló jelentésű szövegek vektorai közel kerülnek egymáshoz.

Népszerű embedding modellek (2026):

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

Vektor adatbázis

Benchmark (2026): a Pinecone ~50 000 insertion/s és ~5 000 query/s, a Qdrant hasonló kategória (~45 000 / ~4 500), 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álasz

1. A felhasználó kérdését embedding-eled (ugyanazzal a modellel)
2. Vektor keresés: top 3-10 leginkább hasonló chunk
3. A talált chunkokat kontextusként a promptba illeszted
4. Az LLM a kontextus alapján válaszol

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

question_embedding = embed(question)
relevant_chunks = vector_db.search(question_embedding, top_k=5)

prompt = f"""Az alábbi dokumentumok alapján válaszolj.
Ha nincs benne a válasz, mondd el, hogy nem tudod.

Dokumentumok:
{relevant_chunks}

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

answer = llm.generate(prompt)

Hibrid keresés — vektor + keyword

A tiszta vektor keresés nem mindig elég. Pontos kifejezésnél (pl. „GDPR 17. cikk”) a szemantikus keresés nem mindig találja meg — az embedding a jelentésre optimalizál, nem a pontos szóegyezésre.

A hibrid keresés kombinálja:

• Vektor keresés: szemantikus hasonlóság
• Keyword keresés (BM25): pontos szóegyezés

A két eredményt reciprocal rank fusion (RRF) vagy súlyozott átlaggal kombinálod. A Weaviate és a Qdrant natívan támogatja.

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.

• 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
• Cross-encoder modellek: lassabb, pontosabb, mint a bi-encoder embedding

A reranking tipikusan 20-30% javulást ad 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 (query rewriting, query expansion), majd több körben keres.

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

Self-RAG

Az LLM kiértékeli a saját válaszát: relevánsak-e a dokumentumok, 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, milyen szűrőkkel, kell-e többkörös keresés. Ez a ReAct pattern + RAG kombináció.

Graph RAG

A dokumentumok közötti kapcsolatokat is modelezi (knowledge graph). Hasznos, ha az entitások közötti összefüggések fontosak — pl. „ki dolgozik az Alpha projekten?”.

Kiértékelés — honnan tudod, hogy működik?

• Faithfulness (hűség): a generált válasz megfelel-e a forrásnak? Nem hallucinál-e?
• Answer Relevancy: tényleg a kérdésre válaszol?
• Context Precision: a visszakeresett dokumentumok valóban relevánsak?
• Context Recall: minden releváns dokumentumot megtalált?

Kiértékelő keretrendszerek: RAGAS és a LangSmith automatizált kiértékelést biztosít. Részletek a LangFuse vs LangSmith összehasonlításban.

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

200 fős cég belső tudásbázisa RAG-gal:

1. Adatforrások

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

2. 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 + Support ticketek
    ↓
Chunking (512 token, 10% overlap)
    ↓
Embedding (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ás

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

Töredéke egy dedikált support csapattag költségének. Lásd még az esettanulmányokat — ott a magyar SaaS-nál +180% új ügyfél fogadása lett az eredmény változatlan support csapattal.

Mikor NE használj RAG-ot?

• Egyszerű, statikus FAQ: ha egy oldal megoldja, ne építs RAG-ot
• 10-20 dokumentum: nem érdemes RAG, tedd a teljes szöveget a promptba
• Valós idejű adat kell: a RAG dokumentumokat tárol, nem live adatot — ide API integráció + agent kell
• 100% pontosság kell: a RAG csökkenti, de nem szünteti meg a hallucinációt — kritikus döntéseknél emberi jóváhagyás
• Strukturált adat: ha SQL-ből lekérdezhető, ne vektorizáld — Text-to-SQL

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

Embedding költségek (egyszeri)

• 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, token díj nélkül

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

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

Skálázási tippek

• Cache: gyakori kérdésekre cache-eld a választ
• Kisebb modell: nem mindig kell a legerősebb
• Batch indexelés: ne real-time embedding, hanem ütemezett
• Chunk méret optimalizálás: kisebb chunk = több vektor = drágább keresés, de pontosabb

Összefoglalás

2026-ban a RAG már nem kísérleti technológia, hanem production-ready megoldás. A kérdés nem az, hogy „működik-e”, hanem az, hogy „hogyan illeszd be a saját rendszeredbe”. Ha RAG-alapú tudásbázist vagy chatbotot tervezel, az AppForge csapata segít a teljes implementációban — kérj 30 perces ingyenes konzultációt.