RAG:n paloittelustrategiat: 7 menetelmää, hakudatan perusteella järjestettynä (2026)

RAG:n paloittelustrategiat: 7 menetelmää, hakudatan perusteella järjestettynä (2026)

RAG:n paloittelustrategiat määräävät, mitä hakumoduuli voi löytää, ennen kuin ensimmäistäkään kyselyä on ajettu. Chroman heinäkuun 2024 tutkimus ajoi 472 kyselyä viiden korpuksen yli text-embedding-3-large-mallilla, ja valittu pilkkoja siirtää recall-lukemaa noin viisi prosenttiyksikköä: 86,7 % tavallisella token-pilkkojalla ja 91,7 % GPT-4o-pilkkojalla, kun kyselyä kohden haetaan viisi lohkoa. Precision heilahtelee paljon rajummin. Koko raportissa se liikkuu 1,5 prosentista 8,0 prosenttiin, joten lohkon koon valinta on kustannuspäätös laadun valepuvussa. Silti jokainen etusivun opas listaa samat seitsemän menetelmää näyttämättä, mikä niistä hakee paremmin.

Keskeiset opit

• Paloittelu pilkkoo dokumentit ennen upotusta; pilkkomiskohdat määräävät, mitä hakumoduuli löytää ja mitä ei.
• Chroman heinäkuun 2024 tutkimuksessa, jossa oli 472 kyselyä, recall vaihteli 86,7 prosentin ja 91,7 prosentin välillä mitatuilla pilkkojilla.
• Precision vaihtelee moninkertaisesti recalliin nähden, joten lohkon koko on ennen kaikkea token-kustannuspäätös.
• Aloita 512 tokenilla ja 10 %:n päällekkäisyydellä, ja säädä sitten oman eval-aineistosi perusteella.

Mikä RAG:n paloittelustrategia kannattaa valita? (järjestettynä)

Useimmille tasaisen proosan varaan rakentaville tiimeille rekursiivinen merkkipaloittelu 512 tokenilla ja 10 %:n päällekkäisyydellä on oikea oletus. Se kunnioittaa kappale- ja lauserajoja, ei maksa mitään ylimääräistä ja jäi Chroman 472 kyselyn benchmarkissa vain 3,2 recall-pistettä LLM-pohjaisesta pilkkojasta. Poikkea siitä vain, jos dokumenteissasi on vahva rakenne tai oma eval-aineistosi todistaa toisin.

Tulkintamme: aloita rekursiivisella merkkipaloittelulla. Chroman datassa se jää recallissa vain klusteri- ja LLM-pilkojille, ja LLM-pilkkojan 3,9 %:n precision tarkoittaa, että syötät generaattorille suunnilleen kaksinkertaisen määrän kohinaa jokaista relevanttia tokenia kohden. Useimmilla tiimeillä ei ole paloitteluongelmaa; heillä on lohkon koko-ongelma, jota he eivät ole koskaan mitanneet.

Mitä data oikeasti sanoo lohkon koosta?

Ainoa julkinen suora vertailu RAG:n paloittelustrategioiden välillä on Chroman tekninen raportti "Evaluating Chunking Strategies for Retrieval" (Brandon Smith ja Anton Troynikov, julkaistu 3. heinäkuuta 2024). He ajoivat 472 kyselyä viidellä korpuksella (328 208 tokenia), upottivat kaiken OpenAI:n text-embedding-3-large-mallilla ja hakivat 5 lohkoa kyselyä kohden. Alla olevat rivit ovat raportin liitetaulukosta: kaikki korpuskset, text-embedding-3-large, 5 haettua lohkoa, joten ne ovat suoraan keskenään vertailukelpoisia:

Chroman päätulostaulukko, joka raportoi eri hakuasetuksella, antaa klusteripilkkojan parhaaksi precisioniksi 8,0 % recallin ollessa 87,3 %, ja precisionin vaihteluväli kaikilla pilkkojilla on 1,5 %:sta (KamradtSemanticChunker) 8,0 %:iin. Lähde: Chroma Research, Evaluating Chunking Strategies

Anthropicin "Introducing Contextual Retrieval" (julkaistu 19. syyskuuta 2024) lähestyy ongelmaa toisesta kulmasta. Heidän lähtötasonaan top-20-haun epäonnistumisprosentti oli 5,7 %; pelkkä kontekstuaalinen upotus laski sen 3,7 %:iin (35 %:n vähennys), kontekstuaalinen BM25 sen päälle toi sen 2,9 %:iin (49 %) ja uudelleenjärjestely painoi sen 1,9 %:iin (67 %). Anthropic ei julkaise tarkkaa käytettyä lohkon kokoa tai päällekkäisyyttä, joten käsittele niitä menetelmätason näyttönä, eivät kokotason näyttönä. Lähde: Anthropic, Contextual Retrieval.

Tulkintamme: aritmetiikasta seuraa kolme johtopäätöstä. Ensinnäkin pilkkojan valinta tuottaa oikeaa recall-hyötyä, ja Chroma sanoo sen suoraan: jotkin strategiat ovat muita parempia jopa 9 %:lla recallissa. Päätulostaulukossa recall liikkuu 83,6 %:sta (KamradtSemanticChunker) 91,9 %:iin (LLMSemanticChunker), ja yllä olevilla viiden haun riveillä vaihteluväli on yhä 86,7-91,7 %. Precision liikkuu samalla datalla moninkertaisesti enemmän: 1,5 %:sta 8,0 %:iin, eli 5,3-kertainen hajonta recallin 1,1-kertaista vastaan. Recall on siis se, mistä keräät muutaman pisteen, kun taas precision ja token-kustannus ovat paikkoja, joissa valinta todella puraisee. Toiseksi LLM-pohjainen pilkkoja ostaa huippurecallin huonoimmalla precisionilla: maksat LLM-kutsun dokumentilta ja syötät generaattorille enemmän kohinaa. Kolmanneksi Anthropicin luvut osoittavat, että lohkojen rikastaminen kontekstilla (5,7 %:sta 3,7 %:iin) siirsi epäonnistumisprosenttia enemmän kuin mikään pilkkojavalinta Chroman taulukossa. Rikasta lohkot, ennen kuin säädät pilkkojaa uudelleen. Reranking pelastaa lohkot, joita pilkkojasi runnoi, ja hybridihaku yhdistää BM25:n ja vektorihaun samasta syystä.

Rehelliset rajat: molemmat tutkimukset käyttävät yhtä upotusmallia ja vain englanninkielisiä korpuksia, eikä kumpikaan ole kontrolloitu testi juuri sinun korpuksellasi. 472 kyselyn aineistossa parhaan ja huonoimman pilkkojan ero oli noin 5 recall-pistettä viidellä haetulla lohkolla, ja precisionissa ero oli suhteessa paljon suurempi.

Miksi lohkon koko ratkaisee haun laadun?

Lohkon koko asettaa hakuavaimesi granulariteetin. 400 tokenin lohko tuottaa keskittyneen upotuksen, joka vastaa tiettyihin kyselyihin; 4 000 tokenin lohko keskiarvoistaa monta aihetta eikä vastaa mihinkään tarkasti. Pienet lohkot hakevat tarkan kohdan, mutta voivat pirstoa vastauksen moneen tulokseen. Suuret lohkot pitävät kontekstin koossa, mutta heikentävät upotuksen signaalia.

Upotusmallin kontekstikatto merkitsee myös. Jos mallisi katto on 512 input-tokenia ja syötät 800, häntä katkeaa äänettömästi. Upotuksesi edustaa kahta kolmasosaa lohkosta. Virhettä ei kirjata mihinkään.

Sitten generaattorin puoli. Liu ym. osoittivat tutkimuksessa "Lost in the Middle" (arXiv 2307.03172, 2023), että LLM:n tarkkuus laskee yli 20 %, kun relevantti dokumentti on pitkän kontekstin keskellä. Viiden 1 000 tokenin lohkon hakeminen kaataa 5 000 tokenia promptiin, ja tarvitsemasi vastaus voi osua kohtaan, jossa malli lukee heikoiten. Pienemmät lohkot pitävät relevantin kohdan lähempänä mallille suotuisaa paikkaa.

Ajattele sitä kirjaston kortistona. Kortti, jossa lukee "kohta 4.2, kolmas kappale: palautusehdot", vie sinut oikealle sivulle. Kortti, jossa lukee "kaikki 1900-luvun kaupankäynnistä", vie sinut rakennukseen. Upotuksesi on se kortti. Rakenna RAG-sovellus alusta loppuun, niin näet, missä kohtaa putkessa paloittelu on, ja lue konteksti-insinöörityön oppaamme siitä, miten haetut lohkot muuttuvat promptin tokeneiksi. Pineconen paloitteluopas kuvaa saman kompromissin vektoritietokannan puolelta.

Kiinteä koko ja rekursiivinen paloittelu (aloita tästä)

Kiinteä koko on vertailukohta, johon mittaat kaiken; rekursiivinen on se, mitä oikeasti laitat tuotantoon.

Kiinteän koon token-paloittelu

Pilko joka N. token sisällöstä riippumatta.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

Oikea vastaus näihin: tasainen proosa ilman otsikkorakennetta, nopeat prototyypit ja mikä tahansa vertailukohta. Se ei ole tyhmä. Se on kontrolliryhmä.

Rekursiivinen merkkipaloittelu

LangChainin RecursiveCharacterTextSplitter pilkkoo erotinhierarkian mukaan: ensin \n\n (kappaleet), sitten \n (rivit), sitten . (lauseet) ja sitten (sanat). Jokainen lohko pysyy alle chunk_size-rajan ja kunnioittaa samalla suurinta mahdollista luonnollista rajaa.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

Erotinlista on se osa, jonka jokainen kilpailija jättää pois. Pilkkoja yrittää ensin \n\n ja turvautuu . -erottimeen vasta, kun kappale ylittää chunk_size-rajan. Jos Markdownissasi on otsikoita, lisää "## " ennen "\n\n", jotta osiot pysyvät ehjinä.

Päällekkäisyyden laskuoppi: 512 tokenilla ja 50 tokenin päällekkäisyydellä askel on 462. 10 000 tokenin dokumentti tuottaa ceil(10000 / 462) = 22 lohkoa. Upotettuja tokeneita yhteensä: 22 x 512 = 11 264, eli upotat uudelleen noin 12,6 % korpusksesta päällekkäisyytenä. Se on rajalauseiden irrallisiksi jäämisen estämisen tallennus- ja API-kustannus.

Miten semanttinen paloittelu toimii, ja onko se kustannuksen arvoinen?

Semanttinen paloittelu upottaa jokaisen lauseen, mittaa kosinietäisyyden vierekkäisten lauseupotusten välillä ja pilkkoo kohdasta, jossa etäisyys ylittää prosenttipisterajan (yleensä 95.). Lohkot katkeavat aiheenvaihtoon eivätkä mielivaltaisiin tokenmääriin. Greg Kamradtin "5 Levels of Text Splitting" -muistikirja loi tämän prosenttipistemurroskohtien lähestymistavan, ja Chroman tutkimus benchmarkkaa hänen pilkkojiaan nimeltä.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

Kustannuslaskelma on se osa, jonka kukaan ei kerro heti alkuun. Semanttinen paloittelu upottaa korpuksesi kahdesti: kerran lause-etäisyyksien ja murroskohtien laskemiseksi ja kerran syntyvien lohkojen upottamiseksi indeksointia varten. OpenAI:n text-embedding-3-large-hinnalla 0,13 dollaria per 1 M tokenia 10 miljoonan tokenin korpus maksaa normaalisti 1,30 dollaria ja semanttisella paloittelulla 2,60 dollaria. Maksat kaksinkertaisesti ennen kuin yhtäkään kyselyä ajetaan.

Mitä sillä saa? Chroman viiden haun riveillä klusteripohjainen semanttinen pilkkoja saavutti 89,0 %:n recallin ja 6,7 %:n precisionin, kun rekursiivinen pääsi samalla 200 tokenin koolla 88,5 %:iin ja 7,0 %:iin. Päätulostaulukossa sama pilkkoja tekee tutkimuksen parhaan precisionin, 8,0 %, recallin ollessa 87,3 %. Puoli prosenttiyksikköä recallia suuntaan tai toiseen, ja precision-tulos, joka vaihtaa merkkiä sen mukaan mitä hakuasetusta lukee, kaksinkertaisella upotuslaskulla. Tuomiomme: semanttinen paloittelu kannattaa aiheiltaan vaihtelevissa korpuksissa (uutisarkistot, tutkimuspapereiden kokoelmat), joissa kiinteät rajat pilkkovat säännöllisesti aiheen keskeltä. Homogeenisissa korpuksissa (tuotedokumentaatio, yksi tietokanta) rekursiivinen antaa 95 % laadusta puoleen hintaan. Jos ajat upotusmalleja paikallisesti Ollamalla, kaksinkertainen upotuskustannus muuttuu laskenta-ajaksi.

Dokumenttitietoinen paloittelu: Markdown, HTML ja koodi

Rakennetietoinen pilkkominen käyttää dokumentin omia rajoja (otsikot, listan kohdat, funktiomäärittelyt) merkkimäärien sijaan. Markdownin H2 on ihmisen tarkoituksella asettama semanttinen raja; merkkipilkkoja silppuaa sen.

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

Koodissa rajat ovat AST-solmuja. LlamaIndexin NodeParserit tarjoavat kielitietoisia pilkkojia, jotka katkeavat funktio- ja luokkamäärittelyihin. Ratkaiseva yksityiskohta: pidä import-lohko ja ympäröivän luokan allekirjoitus kiinni jokaisessa funktiolohkossa. Funktiorunko ilman importteja on upotuskelvotonta kohinaa, joten lisää molemmat jokaisen lohkon alkuun, jolloin upotus vangitsee sekä sen, mitä funktio tekee, että sen, mistä se on riippuvainen.

Erityisesti koodi-RAGia varten: AST-rajojen mukainen pilkkominen, importit alkuun, 256-512 tokenia per funktio, nolla päällekkäisyyttä.

Entä myöhäinen, hierarkkinen ja agenttipohjainen paloittelu?

Nämä ovat "RAG 2.0" -puheen takana olevat edistyneet RAG:n paloittelustrategiat, ja kaikki kolme ovat SERP-kattavuudeltaan 1/10.

Myöhäinen paloittelu

Myöhäisen paloittelun, jonka esittelivät Günther ym. tutkimuksessa "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, syyskuu 2024), upottaa ensin koko dokumentin pitkän kontekstin mallilla ja kokoaa sitten token-tason upotukset lohkovektoreiksi, jolloin jokainen lohko kantaa koko dokumentin kontekstia ja "se maksaa 40 dollaria kuussa" tietää, mihin "se" viittaa. Abstrakti väittää parempaa hakua eri tehtävissä, mutta ei julkaise yhtään vahvistettavaa avainlukua. Weaviaten kirjoitus selittää mekaniikan, mutta pysähtyy myös ennen kontrolloitua vertailua. Näytön tila: lupaava, kvantifioimaton.

Hierarkkinen (vanhempi/lapsi) paloittelu

Indeksoi pienet lohkot (256 tokenia) hakua varten; palauta vanhempi (1 024 tokenia) generaattorille. Hakumoduuli löytää neulan; generaattori saa ympäröivän heinäsuovan. Ylläpidät kahta indeksitasoa ja vanhempi-lapsi-kytkeytymää. Mikään julkinen benchmark ei eristele vaikutusta.

LLM-pohjainen / agenttipohjainen paloittelu

Chroman tutkimuksen LLMSemanticChunker käyttää GPT-4o:ta päättämään pilkkomiskohdat dokumenteittain: 91,7 % recall (korkein) ja 3,9 % precision (matalin). Maksat LLM-kutsun dokumentilta indeksointivaiheessa (noin 100 dollaria 10 000 dokumentin korpuksella) ja syötät generaattorille enemmän kohinaa. Varaa se aidosti epäsäännöllisille korpuksille: juridiikan asiakirjat, skannatut PDF:t, joista ei voi irrottaa otsikoita.

Mikä lohkon koko sopii upotusmallillesi?

Upotusmallisi input-tokenien enimmäismäärä on katkaisukatto, ei suositus. Malli, joka hyväksyy 8 192 tokenia, ei upota paremmin 8 192:lla kuin 512:lla. Laatu heikkenee laimenemisen myötä paljon ennen kattoa: malli keskiarvoistaa merkitystä useamman tokenin yli ja vektori ajautuu kohti korpuksen painopistettä. Alla oleva suositussarake on Techsyn tulkinta, ei toimittajien ohje.

Lähteet: OpenAI embeddings guide, Cohere embed docs, Voyage embeddings docs, BGE model card.

Kuvio: mallit, joilla on kova 512 tokenin katto (Cohere v3, BGE), vaativat selvästi alle 512 tokenin lohkoja, koska katkaisu on äänetön. Syötä yhdelle 600 tokenia, ja viimeiset 88 katoavat upotuksesta ilman virheilmoitusta. Mallit, joilla on suuri katto (OpenAI, Voyage, Cohere v4), sietävät isompia lohkoja, mutta eivät palkitse niistä. Mallin syötteen enimmäispituus on katkaisuraja, ei suositus.

Kytke tähän parhaat RAG-upotusmallit -katsauksemme, mitä MTEB-lukema oikeasti mittaa ja Voyage, OpenAI ja Cohere upotukset rinnakkain, ennen kuin sitoudut malliin.

Miten paloittelet muita kuin englanninkielisiä dokumentteja?

Tokenoijat eivät ole kieleltään neutraaleja. Petrov ym. osoittivat tutkimuksessa "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023), että sama teksti käännettynä eri kielille voi erota tokenoidulta pituudeltaan jopa 15-kertaisesti. Jopa merkki- ja tavutason mallit näyttävät yli 4-kertaista eroa joillakin kielipareilla. 512 tokenin lohko sisältää paljon vähemmän merkitystä turkiksi, arabiaksi tai japaniksi kuin englanniksi.

Tässä sama lause tokenoituna tiktokenin cl100k_base-koodauksella (GPT-4:n tokenoija):

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

Luvut tuotettu tiktoken cl100k_base -koodauksella 30. heinäkuuta 2026.

Käytännön ohje: kiinteällä 512 tokenin lohkokoolla turkin- ja japaninkieliset lohkosi sisältävät suunnilleen 37 % siitä merkityksestä, jonka englanninkieliset lohkosi sisältävät, ja arabiankieliset lohkosi noin 26 %. Pilko kielikohtaisesti merkki- tai lausemäärän mukaan tai nosta tokenbudjettia suhteessa (noin 1 400 turkille, 2 000 arabialle). CJK-kielissä ei ole välilyöntirajoja sanojen välillä, joten merkkipilkkojat käyttäytyvät eri tavalla. Arabian morfologia pakkaa useita kieliopillisia merkintöjä yksittäisiin tokeneihin, mikä paisuttaa lukemia entisestään.

Päätöspuu paloittelustrategian valintaan

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

Kolme nopeaa reseptiä. Dokumentti-chatbotti: MarkdownHeaderTextSplitter 512 tokenilla, nolla päällekkäisyyttä, otsikkopolku metadatassa. Koodihakuvusturi: AST-rajojen mukainen pilkkominen 256-512 tokenia per funktio, importit alkuun. Sekalainen yrityskorpus: ohjaa dokumenttityypin mukaan sisäänotossa ja tallenna siihen vektoritietokantaan, johon lohkot tallennat tyyppimetadatan kanssa myöhempää tyyppikohtaista säätöä varten. Tämä dokumenttikohtainen reititys on koko adaptiivinen paloittelu RAG-sovelluksille.

Työkalut: LangChain vs LlamaIndex vs Chonkie

Emme myy mitään näistä; tämän avainsanan kolme parhaiten sijoittuvaa sivua ovat toimittajien blogeja, joissa on tuote-CTA.

Lähteet: LangChain docs, LlamaIndex NodeParsers, Chonkie docs.

Kaikki kolme toteuttavat samat ydinalgoritmit, joten valitse sen mukaan, mitä putkesi jo käyttää. Laajempaan RAG-työkalupinoon pilkkojien ulkopuolella ja Qdrant, Chroma ja pgvector vertailtuna tallennukseen, katso klusterioppaamme.

Miten Techsy lähestyy paloittelua

Asiakkaiden RAG-projekteissa Techsyn tiimi aloittaa 512 tokenilla ja 10 %:n päällekkäisyydellä eikä koske pilkkojaan ennen kuin olemme rakentaneet 20-50 kysymyksen eval-aineiston asiakkaan oikeista tukitiketeistä. Eval-aineisto tulee ensin; sitten muutamme yhtä muuttujaa kerrallaan: koko, päällekkäisyys, strategia. Ei pilkkojan vaihtoa ilman ennen-jälkeen-lukua samoilla kysymyksillä. Ota maksuton konsultaatio, niin saat toisen silmäparin hakuputkellesi.

Kirjoittajasta

Mert Batur on Techsy.io:n perustajaosakas, ja tiimi toimittaa AI-agentteja, automaatiojärjestelmiä sekä ääni-/SDR-putkia B2B-asiakkaille. Hän kirjoittaa LLM-työkalupinosta, jota Techsyn tiimi oikeasti käyttää tuotannossa, mukaan lukien asiakkaiden tietokantaprojektien RAG- ja hakutyö. Yhteys LinkedInissä.

Usein kysytyt kysymykset

Mitä on RAG:n paloittelu?

Paloittelu on esikäsittelyvaihe, joka pilkkoo dokumentit pienempiin osiin ennen upotusta, jotta hakumoduuli voi sovittaa kyselyitä keskittyneisiin kohtiin eikä kokonaisiin tiedostoihin. Pilkkomiskohdat määräävät, mitä järjestelmäsi voi ja ei voi löytää kyselyhetkellä.

Mikä on paras paloittelustrategia RAGille?

Useimmissa tuotantojärjestelmissä yleisdokumenteilla rekursiivinen merkkipaloittelu 512 tokenilla ja 10 %:n päällekkäisyydellä on vahvin oletus. Chroman 472 kyselyn tutkimuksessa (heinäkuu 2024) se saavutti 88,5 %:n recallin, 3,2 pisteen päähän kalleimmasta LLM-pohjaisesta menetelmästä, ilman lisäkustannuksia.

Mikä on optimaalinen lohkon koko RAGissa?

Aloita 512 tokenista. Laske 256:een, jos upotusmallisi katto on 512 input-tokenia (Cohere v3, BGE) tai jos kyselysi odottavat yhden lauseen vastauksia. Nosta 1 024:ään vain, jos eval-aineistosi osoittaa monikappaleisten vastausten pirstoutuvan. Mittaa aina omilla kysymyksilläsi.

Kuinka paljon lohkojen päällekkäisyyttä kannattaa käyttää?

10-20 % lohkon koosta (50-100 tokenia 512:lla). Päällekkäisyys estää rajalauseita jäämästä irrallisiksi: kahden lohkon rajalle jakautuva fakta on kokonaisena ainakin yhdessä. Yli 20 %:ssa upotat liikaa korpuskuesta uudelleen laskevin tuotoin. Useimmat tiimit päätyvät 10 prosenttiin eivätkä palaa siihen koskaan.

Onko semanttinen paloittelu parempaa kuin kiinteän koon paloittelu?

Hieman, ja kaksinkertaisella upotuskustannuksella. Chroman heinäkuun 2024 benchmarkissa klusteripohjainen semanttinen pilkkoja sai 89,0 %:n recallin ja 6,7 %:n precisionin, kun rekursiivinen sai samalla tokenkoolla 88,5 % recallin ja 7,0 %:n precisionin, ja sen 8,0 %:n paras precision-tulos tuli eri hakuasetuksella. Kannattaa aiheiltaan vaihtelevissa korpuksissa; vaikea perustella homogeenisilla dokumenttiaineistoilla.

Riippuuko lohkon koko upotusmallista?

Kyllä. Mallit, joilla on 512 tokenin input-katto (BGE, Cohere v3), vaativat selvästi alle 512 tokenin lohkoja, koska katkaisu on äänetön. Mallit, joilla on 8 192+ katto, sietävät isompia lohkoja, mutta eivät palkitse niistä; upotuksen laatu heikkenee laimenemisen myötä ennen kattoa. Katso yllä olevasta taulukosta mallikohtaiset aloituspisteet.

Miten paloittelen koodia RAG-järjestelmälle?

Pilko AST-rajojen (funktio- ja luokkamäärittelyt) mukaan äläkä tokenmäärien. Pidä jokainen lohko 256-512 tokenissa per funktio, lisää tiedoston import-lohko ja ympäröivän luokan allekirjoitus alkuun ja käytä nollaa päällekkäisyyttä, koska funktiot ovat itsenäisiä yksiköitä. LlamaIndexin CodeSplitter ja LangChainin kielitietoiset pilkkojat hoitavat molemmat tämän.

Mitä on myöhäinen paloittelu?

Myöhäinen paloittelu upottaa ensin koko dokumentin pitkän kontekstin mallilla ja kokoaa sitten token-tason upotukset lohkovektoreiksi. Jokainen lohkon upotus kantaa koko dokumentin kontekstia, mikä ratkaisee "mihin 'se' viittaa?" -ongelman. Esittelijät Günther ym. (arXiv 2409.04701, syyskuu 2024). Mikään julkinen suora vertailubenchmark ei vielä kvantifioi hyötyä.

Miten paloittelen muita kuin englanninkielisiä dokumentteja?

Tokenmäärät eivät ole kieleltään neutraaleja. Sama lause vei 2,7-kertaisesti enemmän tokeneita turkiksi ja japaniksi kuin englanniksi ja 3,9-kertaisesti arabiaksi (tiktoken cl100k_base). Kiinteä 512 tokenin budjetti antaa muille kuin englanninkielisille lohkoille äänettömästi vähemmän merkitystä. Pilko kielikohtaisesti merkki- tai lausemäärän mukaan tai nosta budjettia suhteessa.

Mistä tiedän, toimiiko paloitteluni oikeasti?

Rakenna 20-50 kysymyksen eval-aineisto oikeista käyttäjien kyselyistä ennen kuin kosket pilkkojaan. Pisteytä hit@5 ja MRR nykyisillä lohkoillasi. Muuta yhtä muuttujaa (koko, päällekkäisyys, strategia), aja uudelleen, vertaa. Ilman eval-aineistoa säädät tuntumalta. Kaksikymmentä kysymystä riittää alkuun.

Yhteenveto

• Aloita rekursiivisella merkkipaloittelulla: 512 tokenia, 10 %:n päällekkäisyys. Oikea oletus tasaiselle proosalle.
• Neljällä mitatulla pilkkojaperheellä Chroman 472 kyselyä siirtävät recallia noin 5 pistettä ja precisionia moninkertaisesti enemmän. Säädä ensin precisionia ja kustannusta.
• Sovita lohkon koko upotusmallisi input-kattoon. 512 tokenin katon malli vaatii alle 512 tokenin lohkoja.
• Rikasta lohkot kontekstilla (Anthropicin 5,7 %:sta 3,7 %:iin pudonnut epäonnistumisprosentti) ennen pilkkojan uudelleensäätöä.
• Rakenna eval-aineisto ensin. Jokainen pilkkojapäätös ilman ennen-jälkeen-lukua on arvaus.

Koko putkeen paloitteluvalintasi ympärillä, katso RAG-sovelluksen rakentaminen alusta loppuun. Vieläkö punnitset hakua ja hienosäätöä? RAG vai fine-tuning erittelee, milloin kumpikin voittaa.