RAG-chunking AI-chatbotokhoz: A tartalmak célszerű felosztása

Egy weboldal-chatbot csak akkor tud megbízhatóan válaszolni, ha a megfelelő pillanatban megtalálja a hozzáillő tartalmat. Pontosan itt dönt a RAG-chunking: A hosszú oldalakat, kézikönyveket és súgószövegeket kisebb egységekre bontja, amelyeket a keresőkomponens célzottan le tud kérdezni. A túl nagy blokkok sok mellékes információt tartalmaznak. A túl kicsi blokkok elveszítik az összefüggést. A jó felosztás ezért nem vakon egy számot követ, hanem a tartalom szerkezetét, jelentését és későbbi felhasználását.

Ez az útmutató a webes, támogatási és tartalomkezelő csapatoknak szól. Elmagyarázza, hogyan oszthatók fel a tartalmak szemantikailag, hogyan őrizhetők meg a metaadatok, hogyan csökkenthetők a duplikációk, és hogyan ellenőrizhető valósághű keresési kérdésekkel, hogy a választott stratégia működik-e. A megközelítés szolgáltatófüggetlen, és mind a klasszikus vektorkeresésre, mind a hibrid lekérdezési eljárásokra átültethető.

Miért határozza meg a RAG-chunking a válaszminőséget

Retrieval-Augmented Generation esetén a rendszer először megkeresi a releváns tudáselemeket, majd átadja azokat a nyelvi modellnek. A chunk-határok így azt határozzák meg, hogy egyáltalán mi található meg együtt és mi használható kontextusként. Ha egy árazási feltételt elválasztanak a kivételétől, egy formálisan helyes keresés mégis hiányos alapot szolgáltathat. Ha viszont egy chunk egy teljes termékoldalt tartalmaz navigációval, változatokkal és lábléccel, a döntő szakasz sok zajjal verseng.

A chunking egyszerre több minőségi dimenziót is befolyásol:

• Megtalálhatóság: Egyértelműen beleillik a keresett állítás egy kompakt egységbe?
• Összefüggés: Együtt marad a címsor, a magyarázat, a korlátozás és a példa?
• Pontosság: A találat a lehető legkevesebb témaidegen sallangot tartalmazza?
• Nyomonkövethetőség: Hozzárendelhető a részlet egy érvényes forráshoz, nyelvhez és verzióhoz?

A Microsoft leír rögzített, változó és szemantikus eljárásokat, és hangsúlyozza, hogy a címsorok, valamint más elrendezési jelek használhatók a célszerű határok kijelölésére. Az AWS is megkülönböztet rögzített, hierarchikus és szemantikus stratégiákat. A közös gyakorlati tanulság: A technikai felosztásnak a tartalmi tagolást kell követnie, ahol ez megbízhatóan rendelkezésre áll.

Kezdje szemantikus szakaszokkal az önkényes vágások helyett

Jó kiindulópont a meglévő oldalszerkezet. A H2 és H3 címsorok, bekezdések, listák, GYIK-kérdések, táblázatok és világosan elhatárolt megjegyzések már hordoznak jelentést. A visszaküldési határidőkről szóló szakasz nem végződhet a mondat közepén vagy a szabály és a kivétel között. Egy GYIK-kérdésnek a válaszával együtt ugyanabban a chunkban a helye. Egy útmutatónál a cselekvési lépés, az előfeltétel és a figyelmeztetés lehetőség szerint együtt marad.

Gyakorlati határlogika

1. Először a dokumentum-, oldal- és főcímsoroknál ossza fel a tartalmat.
2. Ellenőrizze, hogy egy szakasz pontosan egy érthető főtémát tárgyal-e.
3. Csak azokat a szakaszokat bontsa tovább, amelyek túl nagyok a lekérdezéshez vagy a modellkontextushoz.
4. A nagyon rövid töredékeket vonja össze egy hozzáillő szomszédos szakasszal.
5. Csatolja a címsort és a struktúraútvonalat kontextusként minden részhez.

Tiszta HTML vagy Markdown esetén ez a módszer jól automatizálható. A strukturálatlan PDF-ek, a nem egységes exportok és a beszkennelt dokumentumok gyakran előzetes elrendezés- vagy szövegfelismerést igényelnek. Ennek során különösen ellenőrizze a táblázatokat, oszlopokat, fejléceket és oldalhatárokat: Ami optikailag egymás mellett áll, az az kiolvasáskor rossz sorrendbe kerülhet.

Kezelje a chunk-méretet tesztértékként, ne dogmaként

Nincs univerzálisan ideális chunk-méret. A Microsoft 512 tokent 25 százalékos átfedéssel említ lehetséges kiindulópontként bizonyos forgatókönyvekhez, de rámutat, hogy az optimális beállítás a tartalomtól és a modelltől függ. Az AWS szintén dokumentál konfigurálható méreteket és átfedéseket. Az ilyen értékek hasznos kiindulási hipotézisek – nem minőségi bizonyítékok.

A rövid GYIK-válaszok gyakran önálló egységként működnek. A részletes eljárási utasításoknak több kontextusra van szükségük. A jogi vagy szerződéses szövegek nem szakíthatják szét a szabályt, az hatályt és a kivételt. A termékösszehasonlítások viszont soronként vagy szakaszonként lehetnek célszerűek, ha az oszlopfejléceket és a termékhivatkozást is átadjuk.

Miről ismerhetők fel a túl nagy vagy túl kicsi chunkok

Egy chunk jellemzően túl nagy, ha több keresési szándék keveredik benne, a releváns mondat eltűnik a navigáció és a mellékes információk között, vagy sok találat ugyanazot a terjedelmes blokkot adja vissza. Túl kicsi, ha a névmásoknak már nincs hivatkozásuk, hiányoznak a címsorok, a feltételek elválnak az állításoktól, vagy több töredékre van szükség egy egyszerű kérdés megértéséhez.

Ezért hasonlítson össze legalább két vagy három változatot ugyanazzal a kérdéssorral. Alkalmanként csak egy paramétert változtasson meg, például a célméretet vagy a határlogikát. Így látható marad, hogy valójában mi javítja a találati minőséget és a válaszbizonyítékokat.

Az átfedés védi a kontextust – és egyben duplikációkat hoz létre

Egy kis átfedés megakadályozhatja, hogy egy döntő mondat közvetlenül egy chunk-határon vesszen el. Különösen hasznos, ha a hossz szerinti technikai felosztás elkerülhetetlen. A túl sok átfedésnek azonban mellékhatásai vannak: A szinte azonos találatok több helyet foglalnak el az eredmények között, növelik a kontextus terjedelmét, és mesterségesen dominálhatnak egy állítást.

Ezért használja az átfedést célzottan. A struktúraalapú szakaszoknál gyakran elég a címsort, a struktúraútvonalat és egy rövid átmenetet átvinni. Hosszabb folyószövegeknél hasznos lehet az előző szakasz egy kis része. Ezt követően mérje meg, hogy a különböző releváns források a legjobb találatok között maradnak-e, vagy kiszorítják őket a duplikátumok.

A metaadatok üzembiztossá teszik a chunkot

A puszta szöveg ritkán elég egy produktív tudásbázishoz. Minden chunknak meg kell őriznie a származását és a hatályát. Az AWS a metaadatokat a lekérdezés során használt szűrők alapjaként írja le. Egy weboldal-tudásbázisban különösen a következő mezők hasznosak:

• kanonikus forrás URL és oldal címe,
• címsorútvonal az oldalon belül,
• nyelv vagy locale,
• tartalomtípus, mint például GYIK, útmutató, irányelv vagy termékrészlet,
• közzétételi, illetve módosítási dátum,
• termék, régió vagy célcsoport, amennyiben szakmailag releváns,
• hozzáférési és engedélyezési státusz nem nyilvános tartalmak esetén.

Ezzel például elérhető, hogy csak a magyar nyelvű, jelenleg engedélyezett támogatási tartalmakban lehessen keresni. A forrás emellett belinkelhető a válaszban, és egy későbbi frissítés során célzottan újra feldolgozható. A naprakészség szisztematikus biztosítását a KI-Chatbot-Wissensbasis aktuell halten (Az AI-chatbot tudásbázis naprakészen tartása) című útmutató mutatja be.

Távolítsa el a sablonszövegeket (boilerplate) és duplikátumokat az indexelés előtt

A navigáció, a süti-értesítések, az ismétlődő kapcsolati blokkok és a globális láblécek nem valók minden chunkba. Ellenkező esetben több száz majdnem azonos bejegyzés keletkezik, amelyek kiszoríthatják a tényleges tartalmakat. A felosztás előtt távolítsa el az ismétlődő oldalelemeket, és normalizálja a felesleges szóközöket, dekoratív karaktereket, valamint a technikai töredékeket.

A szakmai duplikátumok is figyelmet igényelnek. Ha ugyanaz a visszaküldési szabály a súgó-, termék- és szállítási oldalakon eltérően van megfogalmazva, meg kell határozni egy felelős elsődleges forrást. A elavult másolatokat el kell távolítani, át kell irányítani vagy egyértelműen alacsonyabb prioritással kell ellátni. A chunking eljárás nem tudja a ellentmondásos forrásokat megbízható tudássá alakítani.

A különleges esetek tudatos kezelése

GYIK-tartalmak

Tárolja a kérdést és a választ együtt. Nagyon rövid válaszok esetén egészítse ki a fölérendelt témakörrel. Ugyanazon kérdés változatai hasznosak lehetnek a kereséshez, de nem szabad őket többszörös válaszszerkezetként indexelni.

Táblázatok és listák

Egy táblázatsor oszlopfejlécek nélkül többnyire érthetetlen. Ezért ismételje meg vagy hivatkozza be a releváns fejléc-kifejezéseket a chunkban. Hosszú listáknál minden résznek meg kell őriznie a lista címét és a közös bevezetőt. A kinyerés után ellenőrizze, hogy az értékek továbbra is a megfelelő tulajdonsághoz vannak-e rendelve.

Többnyelvű oldalak

Különítse el a tartalmakat locale szerint, és tárolja a nyelvet metaadatként. Egy magyar nyelvű lekérdezés nem kaphat véletlenül egy elavult angol szakaszt csak azért, mert hasonló kifejezések szerepelnek benne. A közös fordítási vagy oldalazonosítók segítenek a változatok összekapcsolásában anélkül, hogy ugyanabban a szövegblokkban keverednének.

Végezzen lekérdezési teszteket a választeszt előtt

Először azt értékelje, hogy a keresés a megfelelő szakaszt adja-e vissza. Csak ezután bírálja el a nyelvi modell megfogalmazását. A valós felhasználói kérdésekből álló kis Golden Setnek tartalmaznia kell egyértelmű kérdéseket, szinonimákat, többoldalú kéréseket, határeseteket és válasz nélküli kérdéseket. Minden kérdésnél előre határozza meg, hogy melyik forrás vagy szakasz várható.

Többek között ellenőrizze:

• hogy a várható szakasz megjelenik-e az első találatok között,
• hogy az irrelevantis vagy duplikált találatok kiszorítanak-e fontos forrásokat,
• hogy minden szükséges feltétel és kivétel szerepel-e a kapott kontextusban,
• hogy a forrás és annak naprakészségi állapota nyomon követhető marad-e,
• hogy a rendszer hiányzó tudás esetén biztosan nem talál-e ki választ.

A KI-Chatbot-Antwortqualität mit Golden Set und RAG-Tests messen (AI-chatbot válaszminőségének mérése Golden Set és RAG tesztekkel) című cikk leírja a megfelelő ellenőrzési folyamatot. A látható bizonyítékokhoz a Chatbot-Antworten mit Quellen belegen (Chatbot-válaszok alátámasztása forrásokkal) című útmutató egészíti ki a linkellenőrzésre és a bizonytalanságra vonatkozó perspektívát.

Ellenőrzőlista a bevezetéshez

1. Tartalmak leltározása: Oldaltípusok, nyelvek, formátumok és felelős források rögzítése.
2. Kinyerés ellenőrzése: Címsorok, táblázatok és olvasási sorrend ellenőrzése reprezentatív példákon.
3. Határok meghatározása: Szemantikus szakaszok előnyben részesítése, és rögzített méretek használata csak tartalék logikaként.
4. Kontextus megőrzése: Oldalcím, címsorútvonal és szükséges átmenetek átadása.
5. Metaadatok tervezése: URL, locale, naprakészség, tartalomtípus és engedélyezés strukturált tárolása.
6. Duplikátumok eltávolítása: Sablonszövegek (boilerplate) és ellentmondásos másolatok tisztítása az indexelés előtt.
7. Változatok tesztelése: Méretek és átfedések összehasonlítása ugyanazzal a Golden Set-tel.
8. Működés felügyelete: Hiányzó találatok, elavult források és felhasználói visszajelzések rendszeres értékelése.

Összegzés: A jó chunkok érthető tudásegységek

A RAG-chunking nem egy egyszeri technikai beállítás, hanem tartalomarchitektúra a gépi lekérdezéshez. A jó chunkok egy világosan körülhatárolt részterületre válaszolnak, megőrzik a szükséges kontextusukat, és érvényes forráshoz rendelhetők. A címsorok, metaadatok és a kontrollált átfedés ugyanolyan fontosak, mint a puszta hossz.

Kezdje néhány reprezentatív tartalomtípussal, mérje a lekérdezést a válaszolási stílus előtt, és dokumentáljon minden változtatást. Ha ezt követően weboldal-chatbotot szeretne építeni egy strukturált tudásbázisra, a ChatReact funkcióinak áttekintésénél megtalálja a megfelelő belépési pontot.

Források

• Microsoft Learn: Chunk large documents for vector search solutions in Azure AI Search
• Microsoft Learn: Chunk and vectorize by document layout
• AWS Bedrock: How content chunking works for knowledge bases
• AWS Bedrock: Include metadata in a data source