A mérés, ami eldönti, mennyire sürgős ez
A benchmark módszertana adja a súlyát: Wikipédia-pillanatképeket hasonlítottak össze havonta fél éven át, és a tényváltozásokat automatikusan nyerték ki — 96,8%-os kinyerési pontossággal. Ebből lett 96 124 kérdés-válasz pár és 219 463 dokumentum.
Az eredmény elavult dokumentumok jelenlétében:
| Modell | Összesített pontosság |
|---|---|
| Nagy modell (70 milliárd paraméter) | 51,7% |
| Közepes (8 milliárd) | 40,0% |
| Kicsi (7 milliárd) | 29,9% |
A vizsgálat legalább 20%-os esésről számol be — a táblázat az elavult dokumentumok jelenlétében mért abszolút értékeket mutatja —, és a mezőny alján a véletlen szintje alatti teljesítményt.
A kulcsmondat viszont ez: a modellek megfelelően bizonytalanok maradnak, ha semmit nem találnak, de „magabiztos, de helytelen válaszokra hajlamossá válnak, amikor elavult információval találkoznak."
Ez fordítja meg a szokásos gondolkodást. A hiányos tudásbázis kellemetlen: a bot azt mondja, nem tudja. Az elavult tudásbázis veszélyes: a bot magabiztosan rosszat mond, és a felhasználónak nincs jele arról, hogy baj van.
Miért nem veszi észre a modell?
Mert nem is feladata. A RAG alapelve az, hogy higgy a kontextusnak — pontosan azért építed, hogy a modell a te dokumentumaidból válaszoljon, ne a saját emlékezetéből.
Erre van egy 2026-os mérés, ami számszerűsíti, mennyibe kerül ez. A vizsgálat 4 500 rekordon nézte, mi történik, ha a bekérdezett szöveg ellentmond annak, amit a modell egyébként tud:
| Beállítás | Pontosság ellentmondó adaton |
|---|---|
| Hagyományos RAG | 63,0% |
| Ütközésfigyelő eljárással | 78,1% |
És a legdrámaibb részlet ugyaninnen: amikor egy elterjedt tévhitet tartalmazó dokumentumot tettek a tudásbázisba, a hagyományos RAG pontossága 15%-ra esett.
Magyarul: ha van egy régi, visszavont dokumentumod a tudásbázisban, a rendszer az esetek nagy részében azt fogja visszaadni — nem azért, mert rossz a modell, hanem mert pont erre kérted.
(A vizsgálat szerzői maguk figyelmeztetnek: a javulás mechanizmusa modellcsaládonként eltér, tehát nincs egyetlen bevált megoldás az ütközésre.)
Ebből egyenesen következik, hol kell megoldani: nem a modellnél, hanem az indexelésnél. Ha a rossz dokumentum bekerül a találatok közé, már késő.
A négy művelet, ami nem magától megy
A frissen tartás négy dologból áll, és ezek közül kettő rendszerint magától nem működik.
| Művelet | Mi történik alapból |
|---|---|
| Új dokumentum | Ez az egyetlen, ami mindenhol jól működik. |
| Módosított dokumentum | Általában működik, de a változásészlelés a forrásrendszertől függ. |
| Törölt dokumentum | Ez a csapda. Több platformon a törlés nem propagálódik magától. |
| Jogosultságváltozás | Késleltetve érvényesül, és az örökölt jogokhoz külön frissítés kell. |
A törlés a legveszélyesebb, mert néma. A dokumentumot kiveszed a mappából, a rendszer működik tovább, és a chatbot hónapokig visszaadja azt, ami már nem létezik.
A gyártói dokumentációk szerint ez platformonként másképp áll: van, ahol automatikusan működik; van, ahol csak akkor, ha az első indexelésnél beállítottad; van, ahol csak teljes összehangoló módban; és van, ahol külön takarítási beállítást kell bekapcsolni.
A gyakorlati teendő egyetlen mondat: keresd meg a rendszered dokumentációjában a törlés szót, mielőtt élesbe teszed.
Az újraindexelés olcsóbb, mint hinnéd
[Saját számítás] Ez általában meglepetés:
| Tudásbázis mérete | Teljes újraszámolás beágyazási költsége | Hányszor fér bele 100 dollárba |
|---|---|---|
| 1 000 dokumentum | ~0,50 USD | 200× |
| 10 000 dokumentum | ~5 USD | 20× |
| 100 000 dokumentum | ~50 USD | 2× |
Havi teljes újraindexelés tízezer dokumentumnál évi hatvan dollár. Ez nem költségkérdés — ez üzemeltetési kérdés.
A valódi költség máshol van: az index újraépítésénél. A gyártói dokumentáció pontosan felsorolja, mit lehet menet közben módosítani, és mihez kell az egészet eldobni és újraépíteni:
MENET KÖZBEN MEGY
- új mező hozzáadása
- pontozási profil, szinonimalista, szemantikus
beállítás módosítása
- meglévő mező visszaadhatóságának állítása
TELJES ÚJRAÉPÍTÉST IGÉNYEL
- mező törlése
- MEZŐDEFINÍCIÓ MÓDOSÍTÁSA (típus, kereshetőség,
szűrhetőség, rendezhetőség)
- analizátor hozzárendelése vagy módosítása
- szolgáltatásváltás vagy csomagváltás
A második lista második sora az, ami mindenkit meglep: a beágyazó modell cseréje meződefiníció-változás. Ha átállsz másik modellre, vagy a dimenziószám változik, akkor teljes index-újraépítés kell. Nem az ötven dollár a költség, hanem a leállás és a kockázat.
Erre van egy technikai megoldás, ami különbséget tesz „karbantartási leállás" és „a felhasználó nem vesz észre semmit" között: az index alias. Az alkalmazásod egy álnévre hivatkozik, nem a konkrét indexre; az új indexet melléépíted, teszteled, és amikor kész, az álnevet átirányítod.
A sorrend a dokumentáció szerint:
1. Mentsd el a jelenlegi indexdefiníciót
2. Ha van szabad kapacitás, tartsd meg a régit,
amíg az újat építed és teszteled
3. Építsd fel az újat a módosított mezőkkel
4. Töltsd fel külső forrásból
5. Fordítsd át az aliast
(Az újraindexelés időigényére nem találtam publikált számot — API-korlátoktól, darabmérettől és a tároló írási sebességétől függ. Mérd meg egyszer ezer dokumentumon a saját adatodon, és szorozd fel.)
Ellentmondó dokumentumok
Ez a legnehezebb rész, mert nem technikai probléma. Két dokumentum ugyanarról mást mond — a régi szabályzat és az új, a magyar és az angol változat, a szerződéssablon és a konkrét szerződés.
A modell nem fogja megoldani helyetted. A fenti mérés szerint az ütközés kezelése modellcsaládonként eltérő eredményt ad, és nincs bevált egységes megoldás.
Az egyetlen működő megközelítés indexelési oldali, három lépésben:
- Kötelező érvényességi metaadat minden dokumentumon. Érvényes-tól, érvényes-ig, verzió, státusz. Ha ez nincs, semmilyen szűrés nem lehetséges.
- A visszavont dokumentumot vedd ki az indexből, ne szűrd. A szűrés elfelejthető, kikapcsolható, és a darabolt indexeknél nem mindig terjed ki a darabokra. Ami nincs bent, azt nem lehet visszaadni.
- Ha a rendszer mégis ellentmondást talál, ne válasszon. A helyes viselkedés az, hogy jelzi az ütközést és megmutatja mindkét forrást — nem az, hogy az egyiket kiválasztja.
A harmadik pont azért fontos, mert ez a különbség egy hasznos és egy veszélyes rendszer között. Egy chatbot, ami azt mondja „erről két, egymásnak ellentmondó forrásom van, nézd meg őket", hasznosabb, mint az, amelyik magabiztosan az egyiket idézi.
Ki a gazdája?
Erre őszintén: célzott iparági felmérést arról, hogy ki a tudásbázis gazdája egy AI-bevezetés után, nem találtam. A tapasztalatunk viszont az, hogy ez a szerep a legtöbb szervezetben nincs kiosztva — és pont ezért avul el a tudásbázis.
Amit felelősen javasolni lehet: a gazda az legyen, aki a forrásdokumentumokért is felel, ne az, aki a rendszert üzemelteti. A HR-szabályzat gazdája a HR, nem az informatika. Ha ez elválik, akkor a frissítés mindig a másik osztály feladata lesz.
A rutin
1. ÉRVÉNYESSÉGI MEZŐ MINDEN DOKUMENTUMON
Érvényes-tól, érvényes-ig, verzió, státusz.
Ez az egyetlen, ami nélkül semmi más nem megy.
2. A TÖRLÉST ELLENŐRIZD ELŐSZÖR
Tegyél be egy tesztdokumentumot, töröld ki,
és kérdezz rá. Ha visszajön, van dolgod.
3. HETI INKREMENTÁLIS, HAVI TELJES
Az inkrementális gyors és olcsó. A havi teljes
újraszámolás kifogja azt, amit az elrontott.
4. INDEX ALIAS AZ ELSŐ NAPTÓL
Az alkalmazás álnévre hivatkozzon. Enélkül
minden szerkezeti változás leállás.
5. AZ ELLENTMONDÁST JELEZD, NE OLDD FEL
Két forrás, két dátum, a felhasználó dönt.
Ez hasznosabb, mint egy magabiztos tévedés.
6. HAVONTA HÚSZ KÉRDÉS ÚJRAFUTTATÁSA
Ugyanaz a húsz kérdés, minden hónapban.
Ha romlik, tudni fogod, mielőtt panasz jön.
7. NEVEZD MEG A GAZDÁT DOKUMENTUMTÍPUSONKÉNT
Aki a forrásért felel, nem aki a rendszert
üzemelteti.
8. ÉVENTE NÉZD ÁT, MI NEM KELL
A növekvő tudásbázis nem cél. A pontos az.
A második pont öt perc, és a leggyakoribb néma hibát fogja meg. Érdemes még az élesítés előtt megcsinálni.
Tipikus félreértések
- „A hiányos tudásbázis a nagyobb baj." Fordítva. A mérés szerint üres találatnál a modell bizonytalan marad; elavult találatnál magabiztosan téved.
- „Ha törlöm a fájlt, kikerül a rendszerből." Több platformon nem. A törlés propagálása külön beállítás, és van, ahol csak az első indexeléskor kapcsolható be.
- „A modell majd észreveszi, hogy régi az adat." Nem. A RAG alapelve az, hogy higgy a kontextusnak — pont ezért építetted.
- „Drága az újraindexelés." Tízezer dokumentum teljes újraszámolása öt dollár. A drága rész az index szerkezeti újraépítése és a leállás.
- „A beágyazó modell cseréje csak konfiguráció." Meződefiníció-változás, tehát teljes index-újraépítés.
- „Az ellentmondást a rendszernek kell feloldania." Nincs rá bevált megoldás. A helyes viselkedés a jelzés, nem a választás.
Amit érdemes elvinni
A tudásbázis nem attól romlik el, hogy hiányos, hanem attól, hogy régi — és ez a különbség a mérésben legalább húsz százalék.
Három dolog, ami ezt megelőzi, és mindhárom az első héten beállítható: érvényességi metaadat minden dokumentumon, a törlés propagálásának ellenőrzése egy tesztfájllal, és index alias, hogy a szerkezeti változás ne jelentsen leállást.
És egy havi rutin, ami öt percbe kerül: futtasd le ugyanazt a húsz kérdést. Nem azért, hogy jó számot kapj, hanem hogy észrevedd, mikor kezd romlani — mert a felhasználók nem fogják jelezni. Csak abbahagyják a használatát. A bevezetés tervezéséről a céges tudásbázis-chatbot című írás szól, a mérésről pedig a RAG-rendszer ellenőrzése témájú poszt.