RAG és tudásbázis-építés
Ez a modul azoknak szól, akik saját dokumentumaikból akarnak AI-t 'oktatni'. A RAG ma az egyik leggyakoribb vállalati AI architektúra: mélyebb kontextus, kevesebb hallucináció és pontosabb válaszok.
RAG alapok
A RAG (Retrieval-Augmented Generation) egy architektúra, amely kombinálja a keresést és a szöveggenerálást. Ahelyett, hogy az AI csak a training adatából válaszolna, először megkeresi a releváns dokumentumokat a te adatbázisodból, majd azok alapján generálja a választ.
A RAG 4 lépése
Indexelés
Dokumentumaid chunk-okra darabolódnak (méret kontextusfüggő: rövid tények ~256 token, hosszabb érvelés ~512–1024 token) és embedding vektorokká alakulnak — hibrid pipeline esetén BM25 indexbe is
Keresés
Kérdésedre a rendszer megkeresi a leginkább releváns chunk-okat a vektortárból
Kontextus-injektálás
A talált chunk-ok bekerülnek az LLM promptjába mint kontextus
Generálás
Az LLM a kontextus alapján generálja a választ — forrásmegjelöléssel
Eszközök és frameworkök
Kezdőknek és nem technikai felhasználóknak az alábbi megoldások egyszerű belépési pontot adnak a RAG-alapú tudásbázis-építéshez.
| Eszköz | Mire jó |
|---|---|
| NotebookLM | Dokumentum feltöltés, kérdezés, podcast — teljesen ingyenes |
| Claude Projects | Dokumentumok + instrukciók = perszonalizált asszisztens |
| ChatGPT GPTs | Custom GPT saját tudásbázissal, megosztható |
| Dify | AI app platform — RAG + agentek + workflow, ingyenes tier |
Három tipikus RAG-minta
Személyes kutatási asszisztens
A legegyszerűbb RAG-minta: a cél nem egy teljes vállalati kereső, hanem az, hogy néhány forrásból megbízhatóbban tudj kérdezni és visszakeresni.
Csapaton belüli belső tudásréteg
Itt már nem elég a dokumentumfeltöltés. Jogosultság, verziózás, forráskezelés és naplózhatóság is kell, különben a tudásbázis gyorsan bizalomvesztetté válik.
Üzemi ügyfélszolgálati tudásbázis
A support RAG ott működik jól, ahol a keresési minőség, a visszaidézhetőség és az eszkaláció együtt áll össze. Egy feltöltött PDF-halmaz még nem ügyfélszolgálati rendszer.
Praktikus tippek
A chunk mérete és stratégiája kritikus döntés — nincs egyetlen optimális méret. A dokumentum típusa, a kérdések jellege és a retrieval logika együtt határozza meg, mi működik.
Fix méret (fixed-size)
Rögzített token-határon vágás (pl. 512 token, 20% átfedés). Egyszerű, kiszámítható — de mondatokat kettévághat.
Mondathatár (sentence-boundary)
Mondathatáron vágás, majd token-korlát figyelembevétele. Jobb koherencia, kicsit több overhead.
Hierarchikus (hierarchical)
Nagy chunk-ok kis chunk-okba ágyazva. A keresés kis chunk-on fut, de a generálás a nagyobb kontextust kapja.
Praktikus irányelvek
- →20–30% overlap a chunk-ok között — így nem vágod ketté a mondatokat
- →Adj hozzá metaadatokat (forrás, dátum, kategória) — így szűrhetsz kereséskor
- →Teszteld különböző méretekkel — nem minden dokumentumtípusra ugyanaz az optimális
Konkrét use case-ek
Szakmai dokumentumokból kérdezhető asszisztens
- 1.Tisztítsd le a forrásokat: ne minden régi verzió kerüljön bele egyszerre.
- 2.Kérdezz rá ugyanarra több megfogalmazással, és nézd meg, stabilan ugyanarra a forrásra mutat-e.
- 3.A rossz találatokat külön gyűjtsd, mert ezekből derül ki, hol kell javítani a chunkinget vagy a keresést.
Belső policy-bot csapatoknak
- 1.Különítsd el a hivatalos, jóváhagyott policy-forrásokat a háttéranyagoktól.
- 2.A válaszhoz mindig kérj forrásidézetet vagy dokumentumlinket.
- 3.A policy-botot ne kreatív asszisztensként kezeld, hanem visszakereső rétegként.
Support tudásbázis ticket-előkészítéshez
- 1.A leggyakoribb ticketkategóriákból indíts, ne az összes edge case-ből.
- 2.A keresést és a generálást külön mérd: lehet, hogy nem a modell rossz, hanem a visszakeresés.
- 3.Ahol sok a félrement válasz, tegyél be emberi ellenőrzési pontot és célzott evalt.