Miért kell egyáltalán feldarabolni?
Mert egyetlen vektor nem tud egy hetvenoldalas szerződést jelenteni. A beágyazás egy fix hosszú számsorba sűríti a szöveget: ha rövid a szöveg, ez pontos; ha hosszú, akkor a lényeg elveszik az átlagban. Erről a mechanizmusról az embedding és a vektoros keresés című írás szól bővebben.
A mért különbség egy nagy szolgáltató saját vizsgálatából, négy ügyfél-adathalmazon:
| Megközelítés | Recall@50 |
|---|---|
| Egy vektor a teljes dokumentumra | 28,2 |
| Feldarabolva (512 token, 25% átfedés) | 45,7 |
(Ez a mérés külön részkísérlete; a lentebbi méret- és átfedés-táblák másik részkísérletből valók, ezért az abszolút értékeik nem vethetők össze ezzel.)
Ez a legerősebb és legegyszerűbb érv: 17,5 pont pusztán a darabolástól.
Mekkora legyen egy darab?
Ugyanaz a mérés a méretet is végigpróbálta:
| Darabméret | Recall@50 |
|---|---|
| 512 token | 42,4 |
| 1 024 token | 37,5 |
| 4 096 token | 36,4 |
| 8 191 token | 34,9 |
Monoton romlás. 512-től 8 191-ig 7,5 pont esés. Az ok egyszerű: a releváns mondat felhígul a darabban. Ha egy 8 000 tokenes blokkban egyetlen bekezdés válaszol a kérdésre, a blokk vektora nagyrészt a másik 7 800 tokenről szól.
De itt jön a fenntartás, ami nélkül ez a szám félrevezető. Egy 2025-ös vizsgálat több adathalmazon azt találta, hogy nincs univerzális optimum:
| Darabméret | Mikor a legjobb |
|---|---|
| 64–128 token | tömör, tényalapú kérdések („mennyi a felmondási idő?") |
| 512–1 024 token | ahol szélesebb összefüggés kell („miért módosították a szerződést?") |
És a beágyazó modell is beleszól: a vizsgálatban az egyik modell nagyobb darabokból profitált hosszú dokumentumoknál, a másik kisebbekkel volt jobb névre és azonosítóra keresésnél.
A felelős megfogalmazás tehát: 512 token jó kiindulás, de nem válasz. A válasz az, amit a saját kérdéseiden mérsz.
Kicsi darab, jobb precizitás
Van egy második mérés, ami egy másik szemszögből nézi ugyanezt — és fontos, mert nem ugyanazt méri.
| Stratégia | Méret / átfedés | Recall | Precizitás |
|---|---|---|---|
| Rekurzív | 800 / 400 | 85,4% | 1,5% |
| Rekurzív | 400 / 0 | 89,5% | 3,6% |
| Rekurzív | 200 / 0 | 88,1% | 7,0% |
| Klaszteres szemantikus | 200 / 0 | 87,3% | 8,0% |
| LLM-alapú darabolás | — | 91,9% | 3,9% |
A recall azt méri, megtaláltad-e a választ. A precizitás azt, hogy mennyi felesleges szöveget hoztál mellé.
A 800/400-as és a 200/0-s beállítás recallja között alig három pont a különbség — a precizitás viszont négy és félszeres. Vagyis a nagy darabokkal ugyanolyan gyakran találod meg a választ, csak közben négyszer annyi zajt teszel a modell elé. És a zaj nem semleges: rontja a választ, és fizetsz érte tokenben.
Két fenntartás, amit ki kell mondani. Az egyik: a szórás ebben a mérésben óriási, ±25 és ±37 pont között — vagyis az átlagok közti néhány pontos különbség önmagában nem sokat mond. A másik: a mérést egy vektoradatbázist árusító cég végezte, igaz, nyílt módszertannal és nyílt kóddal.
Az átfedésről három forrás hármat mond
Ez az a pont, ahol a legtöbb útmutató magabiztosabb, mint amennyire a bizonyíték indokolja. Íme, mit mondanak:
- Egy nagy szolgáltató mérése: a 25%-os átfedés +3 pont recallt hozott a nyers vágáshoz képest.
- A fenti darabolási vizsgálat: az átfedés rontotta a precizitást — több a redundáns token.
- Egy 2026-os preprint: az átfedés növeli az indexelés költségét mérhető minőségjavulás nélkül.
A becsületes összegzés: az átfedés keveset ad, és biztosan kerül valamibe. Ha a dokumentumaid rövid, önálló bekezdésekből állnak, valószínűleg elhagyható. Ha összefüggő szöveg, ahol egy gondolat átnyúlhat a határon, tartsd meg — de 10-25% bőven elég.
A határ, ahol vágsz
Ugyanabból a mérésből, és ez a legolcsóbb javítás az egészben:
| Stratégia | Recall@50 |
|---|---|
| Token-határon vág | 40,9 |
| Mondathatárt megőriz | 42,4 |
| 10% átfedés | 43,1 |
| 25% átfedés | 43,9 |
A mondathatár megőrzése másfél pont, ingyen. Egy félbevágott mondat két értelmetlen töredéket ad, és mindkettő rossz vektort kap.
A gyári alapbeállítás nem jó
Ez a cikk legpraktikusabb megállapítása, mert a legtöbb RAG-rendszer gyári beállítással megy.
| Eszköz | Gyári darabméret / átfedés |
|---|---|
| Az egyik elterjedt keretrendszer | 4 000 karakter / 200 |
| Egy másik | 1 024 token / 20 |
| Egy nagy szolgáltató asszisztens-funkciója | 800 token / 400 |
Az utolsóról a független mérés szó szerint azt írja, hogy „átlag alatti recall és a legrosszabb pontszám az összes többi mértéken".
Egyik gyári beállítás sem esik közel ahhoz, amit a mérések javasolnak. Ez az a fél óra munka, ami a legtöbbet hozza egy RAG-projektben.
Táblázat, lista, kód, PDF
Itt van a valódi munka, és itt térül meg a legjobban.
A legjobb mérés erre 80 nehéz pénzügyi jelentésen készült — 4-től 549 oldalig, átlagosan 147 oldal, összesen 11 787 oldal. Az összehasonlítás a fix méretű darabolás és a dokumentumszerkezet szerinti darabolás között zajlott, ahol a rendszer felismeri a címeket, bekezdéseket, listaelemeket és táblázatokat:
| Stratégia | Oldalszintű pontosság |
|---|---|
| Fix 128 token | 72,3% |
| Fix 256 token | 73,1% |
| Fix 512 token | 68,1% |
| Szerkezet szerinti | 84,4% |
Plusz tizenegy-tizenkét pont a legjobb fix mérethez képest is — és a válaszadás pontossága 48,2%-ról 51,8–53,2%-ra nőtt.
És a legfontosabb mellékszám: mindezt közel fele annyi darabbal érte el — 62 529 a 112 155-tel szemben. Vagyis közel fele annyi tárolás, közel fele annyi beágyazási költség, kevesebb zaj. Ez az a hely, ahol a darabolásba fektetett munka mérhetően megtérül.
Négy konkrét szabály a részletekre, elsődleges dokumentációból:
1. TÁBLÁZAT: A FEJLÉCET MINDEN DARABBAN ISMÉTELD
Ha egy 200 soros táblázatot négy darabra vágsz,
és a fejléc csak az elsőben van, a 2-4. darab
számoszlopok halmaza jelentés nélkül.
A jó eszközökben ez alapból be van kapcsolva.
2. TÁBLÁZATOT NE FŰZZ ÖSSZE MÁS SZÖVEGGEL
Önálló egység. Ha nem fér el, táblázatként
darabold tovább, ne szövegként.
3. LISTA: DÖNTSD EL, EGY EGYSÉG-E
Az eszközök alapértelmezése ELLENTÉTES:
az egyik összefűzi a listát, a másik átvágja.
Nézd meg, melyikkel dolgozol.
4. KÓD: SORBAN VÁGJ, NE KARAKTERBEN
A kód sora értelmes egység, a 400. karakter nem.
Van erre kifejezetten szintaxis-tudatos vágó.
Az első pont a leggyakoribb néma hiba. A fejléc nélküli táblázatdarab beágyazása gyakorlatilag zajt kódol, és a keresés soha nem fogja megtalálni.
Ha a darab elveszíti a kontextusát
Van egy technika, ami pont ezt a problémát oldja meg: minden darab elé egy rövid, generált mondat kerül arról, hol helyezkedik el a dokumentumban — mielőtt beágyazod. „Ez a részlet a 2024-es éves jelentés harmadik negyedévi bevételekről szóló fejezetéből való."
A gyártói mérés eredménye (a visszakeresés hibaaránya, a legjobb 20 találatra):
| Beállítás | Hibaarány | Javulás |
|---|---|---|
| Alap | 5,7% | — |
| + kontextusmondat a darab elé | 3,7% | −35% |
| + kulcsszavas keresés is | 2,9% | −49% |
| + újrarangsorolás | 1,9% | −67% |
A költsége, a gyártó saját közlése szerint: millió dokumentum-tokenenként 1,02 dollár, egyszeri tétel, gyorsítótárazással.
(Gyártói mérés, saját modellel. A módszer viszont bármelyik modellel reprodukálható, és a logikája ellenőrizhető.)
Vedd észre viszont, hogy a legnagyobb egyetlen lépés itt a kontextusmondat volt — 5,7-ről 3,7-re —, az újrarangsorolás pedig a maradék hibák harmadát vitte el. Erről szól bővebben a hybrid search című írás.
A how-to
1. NÉZD MEG A GYÁRI BEÁLLÍTÁST
Ez az első lépés, és a legtöbbet hozza.
Ha 800 vagy 1024 vagy 4000, állítsd át.
2. KEZDD 512 TOKENNEL, MONDATHATÁRON
Jó kiindulás. Nem válasz - kiindulás.
3. ÁTFEDÉS 10-25%, VAGY SEMMI
Összefüggő szövegnél tartsd meg, önálló
bekezdéseknél elhagyható. Többet ne.
4. A SZERKEZETET HASZNÁLD, NE A KARAKTERSZÁMOT
Cím, bekezdés, listaelem, táblázat. Mérésben
+12 pont, KÖZEL FELE annyi darabbal.
5. TÁBLÁZATNÁL ISMÉTELD A FEJLÉCET
Minden darabban. Ez nem opcionális.
6. TEDD BELE A DOKUMENTUM CÍMÉT MINDEN DARABBA
A legolcsóbb kontextus, amit adhatsz.
7. MÉRJ KÉT DOLGOT KÜLÖN
Megtalálta-e (recall) ÉS mennyi zajt hozott
mellé (precizitás). Nem ugyanaz a kérdés.
8. TESZTELD A SAJÁT KÉRDÉSEIDEN
Nincs univerzális optimum. Húsz valódi kérdés
többet mond, mint bármelyik blogbejegyzés.
A hetedik pont az, amit a legtöbben kihagynak. Ha csak azt méred, megtalálta-e, akkor a nagy darabok jónak fognak látszani — miközben négyszer annyi zajt tesznek a modell elé.
Tipikus félreértések
- „Van egy optimális darabméret." Nincs. A mérés szerint tényalapú kérdéseknél 64–128 token, összefüggést igénylőknél 512–1 024 — és a beágyazó modell is beleszól.
- „A nagyobb darab több kontextust ad, tehát jobb." A recall monoton romlik a mérettel: 512-nél 42,4, 8 191-nél 34,9. A releváns rész felhígul.
- „Több átfedés, biztosabb találat." Három mérés hármat mond. A becsületes összegzés: keveset ad, és biztosan kerül valamibe.
- „A szemantikus darabolás mindig jobb." Valódi adaton a fix méretű darabolás gyakran ugyanolyan jó vagy jobb — sokkal olcsóbban.
- „Majd egy jobb beágyazó modell kijavítja." Egy 2026-os mérés szerint a nagyobb modellek magasabb pontszámot érnek el, de ugyanúgy érzékenyek a rossz darabolásra.
- „A darabolás egyszeri feladat." Ha új dokumentumtípus jön (más PDF-szerkezet, más táblázatforma), az egészet újra kell nézni.
Amit érdemes elvinni
A darabolás a RAGlegalulértékeltebb része: nem látszik, nincs róla demó, és mégis itt dől el a rendszer minősége. A hibák fele — hogy a válasz nem kerül be a találatok közé, vagy hogy hiányosan kerül be — a daraboláshoz vezethető vissza.
Három szám, amit érdemes megjegyezni: +17,5 pont pusztán attól, hogy darabolsz; +12 pont közel fele annyi darabból, ha a dokumentum szerkezetét használod; és négy és félszeres precizitáskülönbség kis és nagy darabok között, gyakorlatilag azonos recall mellett.
És a leggyorsabb nyereség, amit ma megszerezhetsz: nézd meg, mi a gyári darabméret a rendszeredben. Ha 800 vagy több, akkor egyetlen beállítással többet javítasz, mint egy modellváltással. Hogy a kész rendszert honnan tudod, hogy jól válaszol, azt a RAG-rendszer ellenőrzése témájú poszt veszi végig, a tároló oldalról pedig a vector database című bevezető.