Tükeldamine, ümberreastamine ja hübriidotsing: pane RAG päriselt tööle

Enamik RAG-rakendusi töötab halvasti. Mudel võib olla täiesti sobiv — Claude või GPT-5 suudavad leitud dokumentide põhjal vastata. Tavaliselt veab alt otsing: süsteem tagastab küsimuse peale valed tekstiosad ning mudel koostab nende põhjal enesekindla, kuid eksliku vastuse.

Halba otsingut parandavad kolm võtet: tükeldamisstrateegia, ümberreastamine ja hübriidotsing. Kui need õigesti teha, kaob suur osa kaebustest, et RAG ei sobi konkreetse kasutusjuhuga.

Jätame vahele sügava tehnilise matemaatika ja keskendume sellele, mida tegelikult teha.

Miks otsing ebaõnnestub

RAG-i vaikimisi töötlusahel:

1. Jaga dokumendid tükkideks.
2. Loo iga tekstiosa embedding.
3. Küsimuse saabudes loo ka selle embedding ning leia kõige sarnasemad tekstiosad (koosinussarnasuse alusel).
4. Anna need tükid LLM-ile.

Igal sammul on oma läbikukkumismustrid:

Halb tükeldamine toodab tükke, mis on kasulikkuseks liiga lühikesed või sidususeks liiga pikad. Või tükke, mis murduvad keset loogilist mõtet, nii et kumbki pool ei otsi end hästi välja.

Naiivne sarnasus leiab tükke, mis jagavad päringuga sõnavara, kuid pole tegelikult asjakohased. Päring “kuidas tellimust tühistada” võib leida iga tüki, mis mainib “tellimust”, sealhulgas asjasse mittepuutuvat turunduskoopiat.

Ümberreastamise puudumisel näeb LLM täpselt neid tulemusi, mille sarnasusotsing tagastab. Kõige sarnasem tekstiosa ei ole alati kõige asjakohasem.

Puhas semantiline otsing jätab vahele täpsed märksõna-vasted, mis loevad. Päring “veakood 503” võib jätta vahele tüki, kus on täpselt tekst “veakood 503”, sest päringu semantiline vektor ei sobi kokku tüki üldteemaga.

Kolm parandust — parem tükeldamine, ümberreastamine ja hübriidotsing — lahendavad neid probleeme.

Parandus 1: Parem tükeldamine

Tükeldamine on RAG-i töötlusahela kõige mõjukam üksik otsus ja just see, millele enamik inimesi enne kehvade tulemuste ilmnemist ei mõtle.

Enamiku koodita tööriistade lihtne vaikevalik on jagada tekst kindla tokeniarvu järgi, näiteks 500 tokeni pikkusteks osadeks 50 tokeni suuruse ülekattega. See võib töötada, kuid ebaõnnestub sageli.

Paremad strateegiad:

Semantiline tükeldamine

Jaga dokumente semantiliste piiride peal — kohtades, kus teema muutub —, mitte suvaliste tokeni-arvude peal. Enamikul kaasaegsetel raamistikel (LangChain, LlamaIndex) on semantilised tükeldajad, mis tuvastavad teemamuutusi ja jagavad seal.

Võit: tükid sisaldavad täielikke mõtteid. Mudel saab sidusa konteksti, mitte pool-argumente.

Struktuuriteadlik tükeldamine

Kui sinu dokumentidel on loomulik struktuur (Markdowni pealkirjad, HTML-i sektsioonid, PDF-i peatükid, koodifunktsioonide piirid), kasuta seda. Tükelda sektsiooni järgi, mitte tokeni järgi.

Markdowni jaoks:

• Iga H2-sektsioon on tükk (kus H1-kontekst on ette pandud).
• Pikad H2-sektsioonid on alam-tükeldatud, kus H2-pealkiri on kontekstina korratud.

Koodi jaoks:

• Iga funktsioon või klass on tükk.
• Tükk sisaldab failiteed ja kõiki importe.

See on pimedast fikseeritud-suurusega tükeldamisest dramaatiliselt parem mistahes struktureeritud sisule.

Hierarhiline tükeldamine

Hiljutise RAG-uuringu muster. Loo tükid mitmel tasemel:

• Väikesed tükid (200-500 tokenit) täpseks otsinguks.
• Keskmised tükid (1000-2000 tokenit) konteksti jaoks.
• Dokumendikokkuvõtted (50-100 tokenit) kõrgetasemeliseks sobitamiseks.

Otsides sobita väikeste tükkide vastu, aga tagasta ümbritsev keskmine tükk. LLM saab täpse asjakohasuse pluss piisavalt konteksti, et selles aru saada.

Tüki suuruse valimine

Umbkaudne reegel sisutüübi järgi:

Kui kasutad koodita tööriista, mis peidab tükeldamise, tee katse: küsi kümme küsimust, mille vastused on kindlasti korpuses. Kui otsing jätab õige tekstiosa korduvalt leidmata, on probleem tükeldamises.

Muster, mis töötab hästi: “lehekülg-või-sektsioon, siis küsimusepõhine”

Enamiku isikliku RAG-i kasutusjuhtumite jaoks töötab muster:

1. Tükelda dokumendi sektsiooni järgi (Markdowni H2, PDF-i peatükk jne).
2. Üle ~2000 tokeni tükkide jaoks alam-tükelda lõigu järgi.
3. Pane iga tüki ette dokumendi pealkiri ja sektsiooni pealkiri kontekstina.
4. Lisa iga tüki lõppu lühike kirjeldus, milliseid küsimusi see tükk vastab (kiire LLM genereerib indekseerimise ajal automaatselt).

Automaatselt genereeritud “milliseid küsimusi see tükk vastab” trikk on üllatavalt alakasutatud ja üllatavalt võimas. See töötab, sest kasutajate päringud on sageli sõnastatud küsimustena ja nende sobitamine küsimusvormis metaandmete vastu on täpsem kui sobitamine toore dokumenditeksti vastu.

Parandus 2: ümberreastamine

Pärast esmast otsingut, mis tagastab vektorisarnasuse põhjal tavaliselt 20–50 tekstiosa, kasuta ümberreastajat, et seada tulemused päringu tegeliku asjakohasuse järgi uude järjekorda.

Ümberreastaja on eraldi, tavaliselt väiksem ja spetsialiseeritud mudel, mis hindab päringu ja tekstiosa paari asjakohasust. Rakenda seda 20–50 parimale esialgsele tulemusele, sorteeri tulemused uue hinnangu järgi ning anna LLM-ile 3–5 parimat.

Tulemuseks on märksa täpsem otsing. Vektorisarnasus on kiire, kuid mitte alati piisavalt täpne; ümberreastajad on aeglasemad, kuid hindavad asjakohasust paremini. Nende ühendamisel saad kiire otsingu ja täpsema järjestuse.

Ümberreastajate valikud 2026. aastal:

• Cohere Rerank — väljakujunenud API-põhine ümberreastaja. 2,00 dollarit 1000 otsingu kohta (hinnakirja järgi, kontrollitud 2026-07-10).
• Voyage AI rerank-2 — tugev kommertsvalik, mis võib kitsastes valdkondades Cohere’ist parem olla.
• bge-reranker-v2-m3 — avatud lähtekoodiga mudel, mida saab käitada kohapeal või soodsas majutuskeskkonnas.
• Jina Reranker — veel üks tugev avatud lähtekoodiga valik.

Tüüpilises töötlusahelas:

1. Vektorisotsing tagastab 50 parimat tekstiosa (odav ja kiire).
2. Ümberreastaja hindab kõigi 50 tulemuse asjakohasust päringu suhtes (kallim ja aeglasem).
3. LLM-ile antakse ümberreastaja hinnangu järgi viis parimat tulemust.

Lisanduv kogulatentsus on ligikaudu 200–500 ms. Otsingu täpsus võib oluliselt paraneda, kuid mõju tuleb mõõta oma hindamiskomplektil, mitte tuletada üldisest protsendist.

Koodita tööriistades, mis ümberreastamist vaikimisi ei paku — näiteks NotebookLM-is ja lihtsamates n8n-i seadistustes — on see sageli kõige mõjusam üksik täiendus. n8n-is on Cohere Rerank-sõlm; LangChain ja LlamaIndex sisaldavad ümberreastajate integratsioone.

Parandus 3: Hübriidotsing

Vektorisarnasus püüab semantilisi vasteid. Märksõnaotsing (BM25 või sarnane) püüab täpseid vasteid. Mõlemad jätavad vahele asju, mida teine püüab.

Päring „kuidas parandada meie API-värava HTTP 503 vigu?”:

• Vektorisotsing leiab tekstiosi HTTP vigade, API-värava probleemide ja tõrkeotsingu kohta.
• Märksõnaotsing leiab tükid, mis konkreetselt mainivad “503” — mis võib olla tegelik vastus.

Hübriidotsing käitab mõlemat otsingut ja ühendab tulemused. Selleks kasutatakse meetodit Reciprocal Rank Fusion (RRF): mõlema meetodi järjestuste põhjal luuakse koondjärjestus, mis arvestab mõlemat signaali.

Rakendus enamikus tööriistades on lihtne:

• Jooksuta vektorisotsing → saa järjestatud nimekiri A.
• Jooksuta BM25 / märksõnaotsing → saa järjestatud nimekiri B.
• Iga tüki jaoks arvuta RRF-skoor = 1/(k + rank_in_A) + 1/(k + rank_in_B) (kus k tüüpiliselt 60).
• Sorteeri koondhinnangu järgi ja tagasta parimad tulemused.

2026. aastal on hübriidotsing natiivselt toetatud:

• Weaviate (vektorisalvestus) — kohe kasutatav hübriidotsing.
• Qdrant — hübriidotsing filtreerimise kaudu.
• Pinecone — hübriidotsing hõredate vektorite kaudu.
• Elastic / OpenSearch — kombineeritud märksõna + vektor.
• Enamik n8n RAG-malle — hübriid on kaasaegsetes mallides vaikevalik.

Võit: dramaatiliselt parem kaetus päringutel, mis sisaldavad konkreetseid identifikaatoreid, koode, nimesid või kõnepruuke. Tehnilise sisu jaoks (kood, veakoodid, tootenimed, regulatiivsed viited) on hübriidotsing sisuliselt kohustuslik.

Sinu kasutusjuhtumi jaoks: kui sinu päringud sisaldavad sageli konkreetseid termineid, mis peaksid täpselt sobima (numbrid, nimed, koodid, täpsed fraasid), lülita hübriidotsing sisse. Kulu on madal ja võit on suur.

Pannes kokku

Tipptasemel RAG-i töötlusahel 2026. aastal:

Päring
  ↓
Päringu ümberkirjutaja (valikuline — korrasta päring, ava lühendid)
  ↓
Hübriidotsing: vektor- + märksõnaotsing
  ↓
Top 30-50 tulemust
  ↓
Ümberreastaja
  ↓
Viis parimat ümberreastaja hinnangu järgi
  ↓
LLM koos leitud tükkide + päringuga
  ↓
Viidatud vastus

Iga samm on individuaalselt odav. Kombineerituna toodavad nad otsingu kvaliteeti, mis on kvalitatiivselt erinev “vektorisarnasus → top 5 → LLM”-ist.

Paar vähem levinud, kuid võimast lisandust:

Päringu laiendamine. Kirjuta kasutaja päring ümber mitmeks variandiks ja otsi igaühte. Püüab erinevaid sõnastusi.

Mitmeastmeline otsing. Keerukate küsimuste jaoks tee mitu otsingut. Esimene otsing tuvastab alamküsimused; teine otsing toob iga alamküsimuse vastuse.

Vestluspõhine otsing. Mitmekäigulises vestluses kasuta vestluse ajalugu otsingu mõjutamiseks (“nad küsisid varem X kohta, niisiis selle küsimuse jaoks eelista X-iga seotud sisu”).

Allika filtreerimine. Kasuta metaandmete filtreid otsingu piiritlemiseks. “Otsi ainult dokumentidest, mis on märgistatud ‘EL-i regulatsioonid’ ja pärast 2023-t”.

Neid võimalusi leidub üha rohkemates koodita RAG-tööriistades. Enne keerukamate võtete lisamist kontrolli siiski, kas põhilised kolm — hea tükeldamine, ümberreastaja ja hübriidotsing — on olemas.

Kuidas mõõta RAG-i kvaliteeti

Sa ei saa parandada seda, mida sa ei mõõda. Mõned praktilised hindamisstrateegiad:

“Kuldsete küsimuste” test. Vali 20 küsimust, mille õigeid vastuseid sa tead. Jooksuta need oma RAG-ist läbi. Skoor: kas õiged tükid said välja otsitud? Kas mudel tootis õige vastuse? Tee seda kord kuus.

Otsingu kaetus K juures. Iga kuldse küsimuse jaoks tuvasta, millised tükid sisaldavad vastust. Siis kontrolli: kas otsingusüsteem tagastas mõne neist oma top K-s (5, 10, 20)? Mõõda osakaal.

LLM-kohtuniku hindamine. Edasijõudnum versioon: lase tugeval mudelil (Claude Opus, GPT-5) hinnata, kas vastus on õige, viitetäpne, täielik ja hästi tõenduspõhine. Jooksuta esinduslike küsimuste partii peal. Meil on terve artikkel evalide kohta.

Kasutaja-tajutud kvaliteet. Meeskonna või tootmis-RAG-i jaoks lisa pöial-üles / pöial-alla iga vastuse juurde. Vaata pöial-alla mustreid. Need koonduvad teatud küsimusetüüpide ümber — paranda need.

Suurim viga on mõõtmise üldse vahele jätta. “Tundub okei” pole mõõtmine. Sa ei saa teada, kas sinu parandused töötavad, ilma selleta.

Läbitöötatud näide: lonkava RAG-i parandamine

Oletame, et oled ehitanud isikliku RAG-i oma firma sisedokumentatsiooni jaoks. Kvaliteet on keskpärane — umbes 60% küsimustest saab kasuliku vastuse. Parandused, mida sa rakendaksid, järjekorras:

Auditi kõigepealt otsingut. Kümne halva kvaliteediga vastuse jaoks vaata, millised tükid said välja otsitud. Kas õige tükk sai välja otsitud? Kui jah, on probleem mudelis või promptis. Kui ei, on probleem otsingus.

Kui otsing on probleem:

1. Kontrolli tükeldamist. Kas tükid on sidusad? Kas su tükeldaja jagab keset olulist mõtet? Lülitu üle semantilisele või struktuuriteadlikule tükeldamisele.

2. Lisa ümberreastaja. Kui kasutad lihtsat vektorisotsingut ja viit parimat tulemust, lisa Cohere Rerank või bge-reranker-v2-m3 otsingu ja LLM-i vahele. Paranemine on sageli kohe märgatav, kuid mõõda seda oma hindamiskomplektil, selle asemel et usaldada üldist protsenti.

3. Lisa hübriidotsing. Eriti kui sinu päringud sisaldavad konkreetseid termineid (tootenimed, veakoodid, kõnepruuk).

4. Vaata oma indekseerimist. Kas tükid on metaandmetega märgistatud (dokumenditüüp, sektsioon, kuupäev)? Kasuta otsingus metaandmete filtreid.

Kui mudel on probleem (õiged tükid välja otsitud, vale vastus):

1. Täpsusta prompti. Ütle mudelile selgelt: „Vasta ainult antud konteksti põhjal. Kui kontekst küsimust ei kata, ütle seda.”

2. Lisa viited. Nõua, et mudel viitaks kasutatud konkreetsele tükile. See nii aitab silumisel kui ka vähendab hallutsineerimist.

3. Kasuta tugevamat mudelit. Kui kasutad väikest kiiret mudelit, proovi Claude Sonnet 4.5 või GPT-5.

Pärast kaht-kolme sellist uurimis- ja parandusringi võib kasulike vastuste osakaal isiklikus või väikese meeskonna korpuses meie ligikaudse kogemuse põhjal jõuda 85–89%-ni, kus kasutajad hakkavad süsteemi omaks võtma. Mõõda tulemust oma kontrollküsimustel; see vahemik ei ole lubadus.

Levinud vead

Paar konkreetset asja, mille otsa inimesed järjekindlalt satuvad:

Vale sisu indekseerimine. Turunduslehed, aegunud dokumendid, madala kvaliteediga blogisisu. Mudel ei oska eristada; kõike indeksis koheldakse kui kaanonit. Kureeri halastamatult.

Indeksi uuendamise unustamine, kui dokumendid muutuvad. Aegunud sisuga RAG annab enesekindlalt valesid vastuseid. Kas indekseeri regulaarselt uuesti või kasuta süsteemi, mis automaatselt sünkroonib.

Hindamise ignoreerimine. Enamik RAG-e juurutatakse ilma mõõtmiseta ja siis ei parandata kunagi. “Tundub okei” faas kestab igavesti. Ehita hindamine sisse esimesest päevast peale.

Otsingu kui musta kasti kohtlemine. “See lihtsalt ei tööta” pole diagnoos. Ava otsing ja vaata, mis tagasi tuleb. Peaaegu alati saab probleem ilmseks, kui sa seda näed.

Liiga keerukas algus. Sa ei pea alustama tipptasemel töötlusahelaga. Alusta NotebookLM-i või lihtsa vektorisotsinguga. Lisa keerukust ainult siis, kui oled tuvastanud konkreetse kitsaskoha.

Millal see loeb

Kolm parandust — parem tükeldamine, ümberreastamine ja hübriidotsing — on kõige olulisemad siis, kui:

• Korpus on tehniline, konkreetse terminoloogiaga.
• Päringud sisaldavad täpset vastet nõudvaid elemente (koodid, nimed, ID-d).
• Kasutajad hoolivad täpsusest (juriidiline, vastavus, klienditugi).
• Süsteemi kasutatakse skaalal (väike kvaliteedikasv loeb palju, kui seda tabatakse 10 000 korda päevas).

Need loevad vähem, kui:

• Korpus on väike (alla 100 dokumendi) ja hästi organiseeritud.
• Päringud on avatud küsimused (“mis on meie seisukoht X kohta”).
• Kasutajad on andestavad ja itereerivad, et vastust leida.
• Kasutusjuhtum on uurimuslik, mitte täpne.

Enamiku isiklike ja väikese meeskonna RAG-lahenduste puhul annab suurima mõju üleminek lihtsast vektorisarnasusest vektorisarnasuse ja ümberreastaja kombinatsioonile. Järgmine täiendus on hübriidotsing. Tükeldamine on oluline igas mõõtkavas.

Kokkuvõte

Halva RAG-i põhjus on peaaegu alati halb otsing ning selle taga on tavaliselt tükeldamine, ümberreastamine või otsingumeetod. Paranda need kolm ja suur osa RAG-i kvaliteediprobleemidest kaob.

Sa ei pea olema otsinguinsener, et neid rakendada. Tööriistad — Weaviate, Pinecone, Qdrant, n8n mallid, LangChaini integratsioonid — on tehnikad kättesaadavaks teinud. Kitsaskoht on nüüd peamiselt teadmine, et need eksisteerivad, ja nende rakendamisega kaalutletult tegelemine.

Kui sinu RAG ei tööta, ära süüdista mudelit. Vaata, millised tükid tagasi tulevad, paranda otsing ja siis hinda uuesti.