Utoljára frissítve:
Vállalati Tudásportál · Spoke
Vállalati wiki vagy RAG rendszer? — döntési mátrix 2026
A Confluence és Notion wiki erős — de csak bizonyos kérdéstípusokra. Mikor elég a wiki, mikor kell RAG, és mikor a hibrid? Konkrét döntési mátrix, nem elvont elmélet.
A wiki navigáló lekérdezésekre optimális. A RAG informatív és generatív kérdésekre. A legtöbb vállalatnál a hibrid megközelítés a helyes — a wiki marad forrásnak, a RAG kereső réteget kap fölé. A döntést a query típus elemzése alapozza meg, nem a technológiai divat.
A kérdés, amellyel kezdeni kell: milyen típusú lekérdezések dominálnak?
A wiki vs. RAG döntés alapvető hibája, ha technológiai kérdésként kezelik — valójában query típus kérdése. A három lekérdezési típus teljesen eltérő eszközt igényel.
Navigáló lekérdezés (navigational query): "Hol találom az onboarding anyagot?" — a felhasználó tudja, mit keres, csak a helyet nem tudja. Erre a wiki kiválóan alkalmas: a struktúra navigálható, a linkek egyértelműek.
Informatív lekérdezés (informational query): "Mi a különbség az X és Y folyamat között?" — a felhasználó tudást akar, amelyet valószínűleg több dokumentumból kellene összeszedni. A wiki-keresés ezt nem tudja jól kiszolgálni; a RAG szemantikus visszakeresés és szintézis erre optimális.
Generatív lekérdezés (generative query): "Hogyan kell kezelni ezt a szituációt a mi folyamataink szerint?" — a felhasználó kontextusspecifikus választ vár, amelyet az AI a belső dokumentumok alapján generál. Ez kizárólag RAG-alapon lehetséges.
Mielőtt döntést hozol, válaszolj erre: az elmúlt hónapban a csapatod lekérdezéseinek hány százaléka volt navigáló (hol van?), informatív (mit jelent?) és generatív (hogyan csináljuk mi?)? Ha a navigáló kérdések dominálnak, a wiki elegendő. Ha az informatív és generatív kérdések súlya nő, a RAG réteg indokolt.
Döntési mátrix: wiki vs. RAG 8 dimenzióban
Mikor elég a wiki — és mikor nem?
A wiki-elégségesség feltételei egyszerre kell teljesüljenek. Ha bármelyik sérül, a RAG réteg hozzáadása értéket teremt.
A wiki elegendő, ha mind a négy feltétel teljesül:
- A csapat tagjai tudják, milyen típusú dokumentumok léteznek — navigálni tudnak
- A tartalom volumene kezelhető (200–300 oldal alatt)
- A kérdések döntően navigáló jellegűek ("hol van?", "ki felelős?", "mi a folyamat?")
- A tartalom viszonylag stabil — ritkán változik, nincs gyors frissítési igény
A RAG réteg indokolt, ha bármelyik feltétel sérül:
- A keresés frusztrációs pont — az emberek nem találják meg, amit tudnak, hogy létezik
- A tartalom volumene meghaladja a böngészhető méretet (500+ oldal)
- Informatív és generatív kérdések aránya nő ("hogyan csinálják ezt mások a szervezetben?", "mi a belső best practice X témában?")
- Kereszt-dokumentum szintézis igény jelenik meg — a válasz nem egy, hanem több dokumentumból rakható össze
A leggyakoribb hiba: a RAG-ot a wiki helyett bevezetni. A hibrid megközelítés — wiki forrásként, RAG kereső rétegként — a legtöbb vállalatnál a helyes út. A meglévő szerkesztési kultúra megmarad, a keresési képesség bővül.
A hibrid megközelítés: wiki forrásként, RAG kereső rétegként
A hibrid architektúra azt jelenti, hogy a Confluence vagy Notion megmarad forrásként — a tartalom ott él, ott szerkesztik, a meglévő szerkesztési munkafolyamat nem változik. Fölé épül egy RAG réteg, amely automatikusan indexeli a tartalmat, és szemantikus keresési felületet nyújt.
A szinkronizálás kétféleképpen oldható meg:
- Webhook-alapú valós idejű szinkron: minden Confluence-módosítás automatikusan kiváltja az érintett oldal újraindexelését. Kis latenciájú, de erőforrásigényes pipeline szükséges.
- Napi batch indexelés: éjjeli job exportálja a módosított oldalakat és újraindexeli. A leggyakoribb és leggazdaságosabb megközelítés — a másnap reggeli keresések friss adatot látnak.
A hibrid modell előnye: nem kell migrálni. A meglévő tartalom, a meglévő jogosultság-struktúra és a meglévő szerkesztési kultúra marad. A RAG réteg addíció, nem csere.
Hibrid implementáció 4 lépése
- Forrás-audit: Confluence/Notion tartalom minőségének és frissességének értékelése. Elavult tartalom ne kerüljön az indexbe.
- Chunking stratégia: Oldalak darabolása szemantikus egységekre (300–800 token), metaadatokkal kiegészítve (szerző, dátum, kategória, jogosultság).
- Index felépítése: Vektorizálás (embedding modellel) és feltöltés vektoradatbázisba (Qdrant self-hosted, Pinecone managed, Weaviate open-source).
- Szinkronizálási pipeline: Webhook vagy napi batch job a Confluence API-on keresztül, amely az új és módosított oldalakat automatikusan újraindexeli.
A hibrid modell legnagyobb kockázata: ha a forrás (Confluence) nem frissül, az index sem frissül. A RAG réteg bevezetése nem oldja meg a governance problémát — egy elavult wiki elavult RAG indexet eredményez. A frissítési fegyelem a tartalom szintjén marad a szerkesztőknél.
Fenntartási teher összehasonlítása
A döntéshozók egyik leggyakoribb tévedése: azt feltételezik, hogy a RAG átveszi a wiki karbantartási terhét. Ez téves — a RAG egy plusz réteget ad hozzá, nem a meglévő réteget váltja ki.
| Fenntartási terület | Wiki (Confluence/Notion) | RAG réteg hozzáadva |
|---|---|---|
| Tartalomkarbantartás | Emberi szerkesztői idő — oldalak frissítése, elavult tartalom törlése | Változatlan — a tartalom továbbra is emberi karbantartást igényel |
| Struktúrakarbantartás | Navigációs struktúra, space-ek, kategóriák karbantartása | Csökken — a RAG struktúra nélkül is keres, de a forrás struktúrája marad |
| Technikai karbantartás | SaaS tool frissítések (Atlassian/Notion kezeli) | Plusz: embedding pipeline, vektoradatbázis, LLM API, szinkronizálási job |
| Minőségbiztosítás | Periodikus tartalom-audit — mi elavult, mi redundáns? | Plusz: retrieval minőség monitorozás — mi kerül elő helytelen kontextusban? |
Az összesített fenntartási cost a RAG réteg hozzáadásával tipikusan 30–50 százalékkal nő — de ez nem lineáris többlet: a keresési hatékonyság növekedése és a böngészési idő csökkentése ezt a többletet jellemzően kompenzálja 50 főnél nagyobb szervezetekben.
Kérdések és válaszok
Mik a wiki és RAG rendszer legfőbb különbségei?
A wiki (Confluence, Notion) struktúrált, ember által karbantartott dokumentumtár: a tartalom megtalálásához tudni kell, hol keresni. A RAG (Retrieval-Augmented Generation) szemantikus keresőrendszer: természetes nyelvű kérdésre releváns dokumentumrészleteket keres elő, majd azok alapján szintetizál választ. A wiki navigációs logikára épül (hol van?), a RAG informatív és generatív lekérdezésekre (mit jelent ez, hogyan csináljuk?).
Mikor éri meg RAG-ra váltani?
Három jelzés alapján: (1) A keresés frusztrációs pont — az emberek nem találnak meg dokumentumokat, holott azok léteznek; (2) A tartalom volumene meghaladja a böngészhető méretet — 500+ oldal felett a wiki-navigáció elveszti hatékonyságát; (3) A kérdések generatív jellegűek — 'hogyan kell csinálni X-et a mi kontextusunkban?' típusú lekérdezések nem válaszolhatók egyszerű linkkel. E három feltétel nélkül a wiki karbantartási komplexitása alacsonyabb és elegendő.
Hogyan migrálható a Confluence tartalma RAG-ba?
4 lépés: (1) Export — Confluence API-val exportáld a tartalmakat (Markdown vagy plain text formátumban); (2) Tisztítás — távolítsd el az elavult, ismétlődő vagy alacsony minőségű oldalakat (tipikusan a tartalom 30–50%-a); (3) Chunking — darabolás szemantikus egységekre (300–800 token), metadatokkal (oldal, szerző, dátum, kategória); (4) Indexelés — vektorizálás és feltöltés Qdrant/Pinecone vektoradatbázisba. A Confluence mint adatforrás maradhat — a RAG az index fölé épül.
Melyik esetben elég a wiki?
A wiki elegendő, ha: (1) a csapat tagjai tudják, milyen dokumentumok léteznek — navigálni tudnak; (2) a kérdések főleg navigáló jellegűek ('hol van az onboarding anyag?'); (3) a csapat mérete 15–20 fő alatt van, és a dokumentumszám kezelhető; (4) a tartalom viszonylag stabil és ritkán változik. Ezek teljesülése esetén a RAG implementáció komplexitása nem térül meg — a wiki a helyes eszköz.
Mi a hibrid megközelítés és mikor ajánlott?
A hibrid azt jelenti: a wiki megmarad forrásként (Confluence vagy Notion tartja a tartalmat, ott szerkeszthető), de fölé épül egy RAG réteg, amely szemantikusan indexeli és kereshetővé teszi. Az emberek továbbra is Confluence-ban szerkesztik a dokumentumokat — az AI réteg automatikusan újraindexeli a változásokat. Ez a megközelítés akkor ajánlott, ha erős szerkesztési kultúra már kialakult, és nem akarunk migrálni — csak intelligens keresést hozzáadni.
Milyen query típusokra jobb a RAG és mire a wiki?
Wiki erős: navigáló lekérdezések ('hol találom az X szabályzatot?'), struktúrált tartalom böngészése, dokumentumszerkesztés, verziókövetés. RAG erős: informatív lekérdezések ('mi a különbség X és Y között a mi kontextusunkban?'), generatív kérdések ('hogyan kell kezelni ezt a szituációt?'), kereszt-dokumentum szintézis ('mit tudunk az X témáról a belső anyagainkból?'). A query típus elemzése az egyik legfontosabb döntési szempont.
Mekkora a RAG implementáció fenntartási terhe wikivel összehasonlítva?
A wiki fenntartási terhe: emberi szerkesztési idő (tartalom aktualizálása, struktúra karbantartása). A RAG fenntartási terhe: indexelési pipeline fenntartása, embedding modell kezelése, vektoradatbázis karbantartása, és mindemellett az eredeti tartalom frissítése is szükséges. A RAG tehát nem csökkenti a tartalomkarbantartási terhet — a technikai réteg felülkerül, nem alatta van. Az összesített fenntartási cost tipikusan magasabb, de a keresési érték is magasabb.
Milyen frissítési ciklusra van szükség RAG-alapú rendszernél?
Az index frissítési ciklusa a forrás változási rátájához igazítandó. Három modell: (1) Valós idejű szinkron — minden Confluence-módosítás automatikusan kiváltja az újraindexelést (webhookkal megvalósítható, de erőforrásigényes); (2) Napi batch — éjjeli indexelési job, a másnap reggeli keresések friss adatot látnak; (3) Heti manuális — kisebb szervezeteknél, ahol a tartalom változása lassú. A napi batch a legtöbb vállalatnál optimális egyensúly.
Hogyan kezeljük a jogosultságokat RAG-alapú vállalati keresőnél?
Metaadat-alapú szűrés: az indexeléskor minden dokumentumhoz hozzárendeljük az engedélyezett szerepköröket (pl. 'HR', 'management', 'all'). A lekérdezéskor a retrieval engine csak a felhasználó szerepköréhez tartozó dokumentumokból keres. Confluence esetén a meglévő jogosultság-struktúra leolvasható az API-on keresztül és átvihető a vektoradatbázis metaadataiba. Ez Qdrant filtering, Weaviate RBAC és Pinecone namespace-ek segítségével implementálható.
Mi a RAG-alapú keresés pontossága a wiki-kereséshez képest?
A közvetlen összehasonlítás nehéz, mert más kérdéstípusokra optimalizáltak. Kulcsszavas wiki-keresés navigáló kérdésekre: 80–90% pontosság, ha a felhasználó tudja, mit keres. RAG szemantikus keresés informatív kérdésekre: 70–85% relevanciaarány (rerankerrel 85–92%), de a 'pontosság' itt nem ugyanaz — a RAG szintetizál, nem csak linket ad. A 4×-es keresési idő-megtakarítás nem a pontosságból, hanem a böngészési idő eliminálásából fakad.
