RAG Chunking Strategieën: 7 Methoden, Gerangschikt op Retrievaldata (2026)

RAG Chunking Strategieën: 7 Methoden, Gerangschikt op Retrievaldata (2026)

RAG chunking strategieën bepalen wat je retriever kan vinden voordat er ook maar één query draait. Chroma's studie van juli 2024 draaide 472 queries over vijf corpora op text-embedding-3-large, en de splitter die je kiest verschilt recall met zo'n vijf punten: 86,7% voor een kale token-splitter, 91,7% voor die van GPT-4o, met vijf chunks per query. Precision schommelt veel harder. Over het hele rapport loopt hij van 1,5% naar 8,0%, wat je chunkgrootte-keuze een kostenbeslissing in een kwaliteitskostuum maakt, en elke gids op pagina één somt dezelfde zeven methoden op zonder te laten zien welke beter retrievet.

Belangrijkste Punten

• Chunking splitst documenten vóór het embedden; de splitpunten bepalen wat je retriever wel en niet kan vinden.
• In Chroma's studie van juli 2024 met 472 queries liep recall van 86,7% tot 91,7% over de gemeten splitters.
• Precision varieert meerdere keren meer dan recall, dus chunkgrootte is vooral een tokenkostenbeslissing.
• Begin op 512 tokens met 10% overlap en stem daarna af op je eigen eval-set.

Welke RAG Chunking Strategie Moet Je Gebruiken? (Gerangschikt)

Voor de meeste teams die op platte tekst bouwen, is recursieve karakter-chunking op 512 tokens met 10% overlap de juiste standaard. Hij respecteert paragraaf- en zinsgrenzen, kost niets extra, en eindigde in Chroma's 472-query benchmark 3,2 punten recall achter de LLM-gebaseerde splitter. Stap alleen over als je documenten een sterke structuur hebben of je eval-set het tegendeel bewijst.

Onze lezing: begin met recursieve karakter. In Chroma's data loopt hij qua recall alleen achter de cluster- en LLM-splitters, en de 3,9% precision van de LLM-splitter betekent dat je de generator ruwweg twee keer zoveel ruis per relevante token voert. De meeste teams hebben geen chunking-probleem; ze hebben een chunkgrootte-probleem dat ze nooit gemeten hebben.

Wat Zegt de Data Echt over Chunkgrootte?

De enige openbare head-to-head vergelijking van RAG chunking strategieën is Chroma's technische rapport "Evaluating Chunking Strategies for Retrieval" (Brandon Smith en Anton Troynikov, gepubliceerd 3 juli 2024). Ze draaiden 472 queries over 5 corpora (328.208 tokens), embedden alles met OpenAI text-embedding-3-large, en retrievden 5 chunks per query. De rijen hieronder komen uit de appendix-tabel van het rapport voor alle corpora op text-embedding-3-large met 5 opgehaalde chunks, dus ze zijn direct onderling vergelijkbaar:

Chroma's hoofdresultatentabel, die een andere retrieval-instelling rapporteert, zet de beste precision van de cluster-chunker op 8,0% bij 87,3% recall, en rekt het precision-bereik over al zijn splitters van 1,5% (KamradtSemanticChunker) naar 8,0%. Bron: Chroma Research, Evaluating Chunking Strategies

Anthropic's "Introducing Contextual Retrieval" (gepubliceerd 19 september 2024) valt het probleem vanuit een andere hoek aan. Hun baseline top-20 retrieval-faalpercentage was 5,7%; contextuele embeddings alleen brachten het naar 3,7% (35% reductie), contextuele BM25 erbovenop naar 2,9% (49%), en reranking drukte het naar 1,9% (67%). Anthropic publiceert de exacte chunkgrootte of overlap niet, dus behandel die als bewijs op methodeniveau, niet op grootteniveau. Bron: Anthropic, Contextual Retrieval.

Onze lezing: drie conclusies uit de rekenkunde. Ten eerste is de splitterkeuze echte recall waard, en Chroma zegt het vlakaf: sommige strategieën presteren tot 9% beter in recall. Over de hoofdresultatentabel loopt recall van 83,6% (KamradtSemanticChunker) naar 91,9% (LLMSemanticChunker), en binnen de retrieve-5-rijen hierboven nog steeds van 86,7% naar 91,7%. Precision beweegt meerdere keren verder op dezelfde data: 1,5% naar 8,0%, een spreiding van 5,3x tegen 1,1x voor recall. Dus recall is waar je een paar punten pakt, en precision en tokenkosten zijn waar de keuze echt bijt. Ten tweede koopt de LLM-gebaseerde splitter top-recall tegen de slechtste precision: je betaalt een LLM-call per document en voert de generator meer ruis. Ten derde laten Anthropic's cijfers zien dat chunks verrijken met context (5,7% naar 3,7%) het faalpercentage verder bewoog dan welke splitterkeuze in Chroma's tabel dan ook. Verrijk chunks voordat je de splitter opnieuw afstelt. Reranking herstelt chunks die je splitter verminkte, en hybride zoeken combineert BM25 met vector-retrieval om dezelfde reden.

Eerlijke grenzen: beide studies gebruiken één embeddingmodel, uitsluitend Engelstalige corpora, en geen van beide is een gecontroleerde test van jouw corpus. Over 472 queries was het gat tussen de beste en slechtste splitter zo'n 5 punten recall bij 5 opgehaalde chunks, en een proportioneel veel groter gat in precision.

Waarom Bepaalt Chunkgrootte de Retrievalkwaliteit?

Chunkgrootte zet de granulariteit van je retrieval-sleutel. Een chunk van 400 tokens produceert een gefocuste embedding die bij specifieke queries past; een chunk van 4.000 tokens middelt over veel onderwerpen en matcht nergens precies. Kleine chunks retrieven de exacte passage maar fragmenteren een antwoord mogelijk over meerdere resultaten. Grote chunks houden context bij elkaar maar verzwakken het embedding-signaal.

Het context-plafond van het embeddingmodel doet er ook toe. Als je model op 512 input-tokens afkapt en je voert er 800 in, dan wordt de staart stilzaam afgekapt. Je embedding representeert twee derde van de chunk. Geen fout gelogd.

Dan de generatorkant. Liu et al. lieten in "Lost in the Middle" (arXiv 2307.03172, 2023) zien dat LLM-accuratesse meer dan 20% zakt wanneer het relevante document midden in een lange context staat. Vijf chunks van 1.000 tokens retrieven dumpt 5.000 tokens in de prompt, en het antwoord dat je nodig hebt belandt mogelijk op de positie waar het model het slechtst leest. Kleinere chunks houden de relevante passage dichter bij een positie die het model goed verwerkt.

Zie het als een bibliotheekindex. Een kaartje dat zegt "Sectie 4.2, paragraaf 3: retourbeleid" brengt je bij de pagina. Een kaartje dat zegt "alles over handel in de 20e eeuw" brengt je bij het gebouw. Je embedding is het kaartje. Bouw een RAG-applicatie van begin tot eind om te zien waar chunking in de pipeline zit, en lees onze context engineering-gids voor hoe opgehaalde chunks prompt-tokens worden. Pinecone's chunking-gids kadert dezelfde afweging vanuit de vectordatabase-kant.

Fixed-Size en Recursieve Chunking (Begin Hier)

Fixed-size is de baseline waartegen je alles meet; recursief is wat je daadwerkelijk scheept.

Fixed-size token chunking

Split elke N tokens ongeacht de inhoud.

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

Het juiste antwoord voor: platte tekst zonder kopjesstructuur, snelle prototypes, en elke baseline-vergelijking. Het is niet dom. Het is de controlegroep.

Recursieve karakter-chunking

LangChain's RecursiveCharacterTextSplitter splitst op een hiërarchie van scheidingstekens: eerst \n\n (paragrafen), dan \n (regels), dan . (zinnen), dan (woorden). Elke chunk blijft onder chunk_size terwijl hij de grootste natuurlijke grens respecteert die past.

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)

De lijst met scheidingstekens is het deel dat elke concurrent weglaat. De splitter probeert eerst \n\n en valt pas terug op . wanneer een paragraaf chunk_size overschrijdt. Als je Markdown koppen heeft, voeg dan "## " toe vóór "\n\n" zodat secties intact blijven.

Chunk-overlap rekenkunde: bij 512 tokens met 50-token overlap is de stap 462. Een document van 10.000 tokens produceert ceil(10000 / 462) = 22 chunks. Totaal geëmbde tokens: 22 x 512 = 11.264, wat betekent dat je ruwweg 12,6% van het corpus opnieuw embedt als overlap. Dat zijn de opslag- en API-kosten om grenszinnen niet te laten geïsoleerd raken.

Hoe Werkt Semantische Chunking, en Is het de Kosten Waard?

Semantische chunking embedt elke zin, meet de cosinusafstand tussen aangrenzende zin-embeddings, en splitst waar die afstand een percentieldrempel overschrijdt (meestal de 95e). Chunks breken op onderwerpverschuivingen in plaats van willekeurige tokenaantallen. Greg Kamradt's "5 Levels of Text Splitting" notebook begon deze percentiel-breakpoint aanpak, en de Chroma-studie benchmarkt zijn chunkers bij naam.

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)

De kostenrekensom is het deel dat niemand vooraf vertelt. Semantische chunking embedt je corpus twee keer: één keer om zinsafstanden te berekenen en breakpoints te vinden, één keer om de resulterende chunks te embedden voor indexering. Bij OpenAI's text-embedding-3-large prijs van $0,13 per 1M tokens kost een corpus van 10M tokens $1,30 om normaal te indexeren en $2,60 met semantische chunking. Je betaalt dubbel voordat er één query draait.

Wat koop je daarvan? In Chroma's retrieve-5-rijen haalde de cluster-gebaseerde semantische chunker 89,0% recall en 6,7% precision versus 88,5% en 7,0% voor recursief bij dezelfde 200-token grootte. In de hoofdresultatentabel post dezelfde chunker de beste precision van de studie, 8,0%, bij 87,3% recall. Een half punt recall de ene of de andere kant op, en een precision-resultaat dat van teken wisselt afhankelijk van welke retrieval-instelling je leest, voor het dubbele van de embedding-rekening. Ons oordeel: semantische chunking loont op corpora met uiteenlopende onderwerpen (nieuwsarchieven, paper-verzamelingen) waar vaste grenzen routinematig midden in een onderwerp snijden. Voor homogene corpora (productdocs, één knowledge base) haalt recursief 95% van de kwaliteit tegen de helft van de kosten. Als je embeddingmodellen lokaal draait met Ollama, worden de dubbele-embedding-kosten puur rekentijd.

Documentbewuste Chunking: Markdown, HTML en Code

Structuurbewust splitsen gebruikt de eigen grenzen van het document (koppen, lijstitems, functiedefinities) in plaats van karaktertellingen. Een Markdown H2 is een semantische grens die een mens met opzet plaatste; een karakter-splitter versnippert hem.

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": "..."}

Voor code zijn de grenzen AST-nodes. LlamaIndex's NodeParsers leveren taalbewuste splitters die breken op functie- en klassedefinities. Het cruciale detail: houd het importblok en de omvattende klassehandtekening aan elke functie-chunk vast. Een functiebody zonder zijn imports is onembedbare ruis, dus zet beide vóór elke chunk en de embedding vangt wat de functie doet en waarvan hij afhangt.

Specifiek voor code-RAG: splitsen op AST-grenzen, imports vooraf, 256-512 tokens per functie, nul overlap.

Hoe Zit het met Late, Hiërarchische en Agentische Chunking?

Dit zijn de geavanceerde RAG chunking strategieën achter de "RAG 2.0"-hype, en alle drie zitten ze op 1/10 SERP-dekking.

Late chunking

Late chunking, geïntroduceerd door Günther et al. in "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, september 2024), embedt eerst het volledige document met een long-context model en poolt dan token-level embeddings tot chunkvectoren, zodat elke chunk documentbrede context draagt en "het kost $40/maand" weet waar "het" naar verwijst. De abstract claimt superieure retrieval over taken heen maar publiceert geen kopcijfer dat we konden verifiëren. Weaviate's artikel legt de mechaniek uit en komt evenmin tot een gecontroleerde vergelijking. Status van het bewijs: veelbelovend, niet gekwantificeerd.

Hiërarchische (parent-child) chunking

Indexeer kleine chunks (256 tokens) voor retrieval; geef de parent (1.024 tokens) terug aan de generator. De retriever vindt de naald; de generator krijgt de omringende hooiberg. Je onderhoudt twee indexniveaus en een parent-child mapping. Geen openbare benchmark isoleert het effect.

LLM-gebaseerde / agentische chunking

De LLMSemanticChunker uit de Chroma-studie gebruikt GPT-4o om splitpunten per document te bepalen: 91,7% recall (hoogste) en 3,9% precision (laagste). Je betaalt een LLM-call per document bij indexeertijd (zo'n $100 voor een corpus van 10.000 documenten) en voert de generator meer ruis. Reserveer hem voor echt onregelmatige corpora: juridische stukken, gescande PDF's zonder extraheerbare koppen.

Welke Chunkgrootte Past bij Je Embeddingmodel?

De max input tokens van je embeddingmodel is een afkap-plafond, geen aanbeveling. Een model dat 8.192 tokens accepteert, embedt niet beter op 8.192 dan op 512. Kwaliteit degradeert door verdunning ruim vóór het plafond: het model middelt betekenis over meer tokens en de vector drijft richting het corpus-zwaartepunt. De aanbevelingskolom hieronder is Techsy's interpretatie, niet het advies van de vendors.

Bronnen: OpenAI embeddings-gids, Cohere embed-docs, Voyage embeddings-docs, BGE modelkaart.

Het patroon: modellen met een hard 512-token plafond (Cohere v3, BGE) vragen chunks ruim onder 512, want afkappen is stil. Voer je er één 600 in, dan verdwijnen de laatste 88 uit de embedding zonder gelogde fout. Modellen met grote plafonds (OpenAI, Voyage, Cohere v4) verdragen grotere chunks maar belonen ze niet. De max input-lengte van een model is een afkapgrens, geen aanbeveling.

Koppel dit aan onze beste embeddingmodellen voor RAG-roundup, wat een MTEB-score eigenlijk meet, en Voyage, OpenAI en Cohere embeddings naast elkaar voordat je een model vastzet.

Hoe Chunk Je Niet-Engelse Documenten?

Tokenizers zijn niet taal-neutraal. Petrov et al. lieten in "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023) zien dat dezelfde tekst vertaald over talen tot 15x kan verschillen in getokeniseerde lengte. Zelfs karakter-level en byte-level modellen tonen meer dan 4x verschil voor sommige taalparen. Een chunk van 512 tokens bevat veel minder betekenis in het Turks, Arabisch of Japans dan in het Engels.

Hier is dezelfde zin getokenized met tiktoken's cl100k_base encoding (GPT-4's tokenizer):

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

Tellingen gegenereerd met tiktoken cl100k_base, 30 juli 2026.

Praktische richtlijn: bij een vaste chunkgrootte van 512 tokens bevatten je Turkse en Japanse chunks ruwweg 37% van de betekenis die je Engelse chunks bevatten, en je Arabische chunks zo'n 26%. Chunk op karakteraantal of aantal zinnen per taal, of verhoog het tokenbudget proportioneel (zo'n 1.400 voor Turks, 2.000 voor Arabisch). CJK-talen hebben geen woordgrenzen met witruimte, dus karakter-splitters gedragen zich anders. Arabische morfologie stopt meerdere grammaticale markeringen in één token, wat tellingen verder opblaast.

Een Beslisboom voor het Kiezen van je Chunkingstrategie

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

Drie snelle recepten. Docs-chatbot: MarkdownHeaderTextSplitter op 512 tokens, nul overlap, kopjespad in metadata. Code-zoekassistent: splitsen op AST-grenzen op 256-512 tokens per functie, imports vooraf. Gemengd enterprise corpus: routeer op documenttype bij binnenkomst en sla op in de vectordatabase waarin je de chunks opslaat met type-metadata voor latere afstemming per type. Die routering per document is alles wat adaptieve chunking voor RAG-applicaties inhoudt.

Tools: LangChain vs LlamaIndex vs Chonkie

We verkopen geen van deze; de drie hoogst rankende pagina's voor dit zoekwoord zijn vendor-blogs met product-CTA's.

Bronnen: LangChain-docs, LlamaIndex NodeParsers, Chonkie-docs.

Alle drie implementeren ze dezelfde kernalgoritmen, dus kies op basis van wat je pipeline al gebruikt. Voor de bredere RAG-toolingstack voorbij splitters en Qdrant, Chroma en pgvector vergeleken voor opslag, zie onze clustergidsen.

Hoe Techsy Chunking Aanpakt

Bij klant-RAG-builds begint het Techsy-team op 512 tokens met 10% overlap en raken we de splitter niet aan totdat we een eval-set van 20-50 vragen hebben gebouwd uit de echte support-tickets van de klant. De eval-set komt eerst; dan veranderen we één variabele tegelijk: grootte, overlap, strategie. Geen splitter-wissel zonder een voor- en na-meting op dezelfde vragen. Plan een gratis adviesgesprek voor een tweede paar ogen op je retrieval-pipeline.

Veelgestelde Vragen

Wat is chunking in RAG?

Chunking is de voorverwerkingsstap die documenten in kleinere segmenten splitst vóór het embedden, zodat de retriever queries kan matchen tegen gefocuste passages in plaats van hele bestanden. De splitpunten bepalen wat je systeem wel en niet kan vinden op query-tijd.

Wat is de beste chunkingstrategie voor RAG?

Voor de meeste productiesystemen op algemene documenten is recursieve karakter-chunking op 512 tokens met 10% overlap de sterkste standaard. In Chroma's 472-query studie (juli 2024) scoorde hij 88,5% recall, binnen 3,2 punten van de duurste LLM-gebaseerde methode, tegen nul extra kosten.

Wat is de optimale chunkgrootte voor RAG?

Begin op 512 tokens. Zak naar 256 als je embeddingmodel op 512 input-tokens afkapt (Cohere v3, BGE) of als je queries antwoorden van één zin verwachten. Ga alleen naar 1.024 als je eval-set laat zien dat antwoorden van meerdere alinea's gefragmenteerd worden. Meet altijd tegen je eigen vragen.

Hoeveel chunk-overlap moet ik gebruiken?

10-20% van de chunkgrootte (50-100 tokens bij 512). Overlap voorkomt dat grenszinnen geïsoleerd raken: een feit gesplitst over twee chunks verschijnt compleet in minstens één. Voorbij 20% embed je te veel van het corpus opnieuw voor afnemende opbrengst. De meeste teams landen op 10% en kijken er nooit meer naar.

Is semantische chunking beter dan fixed-size chunking?

Marginaal, en tegen dubbele embedding-kosten. Chroma's benchmark van juli 2024 toonde de cluster-gebaseerde semantische chunker op 89,0% recall en 6,7% precision versus 88,5% recall en 7,0% precision voor recursief bij dezelfde tokengrootte, met zijn 8,0% beste-precision resultaat uit een andere retrieval-instelling. De moeite waard voor corpora met uiteenlopende onderwerpen; moeilijk te rechtvaardigen voor homogene documentsets.

Hangt chunkgrootte af van het embeddingmodel?

Ja. Modellen met een 512-token input-plafond (BGE, Cohere v3) vereisen chunks ruim onder 512 omdat afkappen stil is. Modellen met 8.192+ plafonds verdragen grotere chunks maar belonen ze niet; embedding-kwaliteit degradeert door verdunning vóór het plafond. Zie de koppelingstabel hierboven voor startpunten per model.

Hoe chunk ik code voor een RAG-systeem?

Split op AST-grenzen (functie- en klassedefinities) in plaats van tokenaantallen. Houd elke chunk op 256-512 tokens per functie, zet het importblok van het bestand en de omvattende klassehandtekening vooraf, en gebruik nul overlap omdat functies zelfstandige eenheden zijn. LlamaIndex's CodeSplitter en LangChain's taalbewuste splitters kunnen beide dit aan.

Wat is late chunking?

Late chunking embedt eerst het volledige document met een long-context model en poolt dan token-level embeddings tot chunkvectoren. Elke chunk-embedding draagt documentbrede context, wat het "waar verwijst het naar?"-probleem oplost. Geïntroduceerd door Günther et al. (arXiv 2409.04701, september 2024). Geen openbare head-to-head benchmark kwantificeert de winst nog.

Hoe chunk ik documenten in andere talen dan Engels?

Tokentellingen zijn niet taal-neutraal. Dezelfde zin kostte 2,7x meer tokens in het Turks en Japans dan in het Engels, en 3,9x in het Arabisch (tiktoken cl100k_base). Een vast 512-token budget geeft niet-Engelse chunks stilzwijgend minder betekenis. Chunk op karakteraantal of aantal zinnen per taal, of verhoog het budget proportioneel.

Hoe weet ik of mijn chunking echt werkt?

Bouw een eval-set van 20-50 vragen uit echte gebruikersqueries voordat je de splitter aanraakt. Scoor hit@5 en MRR tegen je huidige chunks. Verander één variabele (grootte, overlap, strategie), draai opnieuw, vergelijk. Zonder eval-set stem je af op gevoel. Twintig vragen is genoeg om te beginnen.

De Kern

• Begin met recursieve karakter-chunking op 512 tokens, 10% overlap. Juiste standaard voor platte tekst.
• Over de vier splitterfamilies die iemand gemeten heeft, bewegen Chroma's 472 queries recall zo'n 5 punten en precision meerdere malen meer. Stem eerst af op precision en kosten.
• Match chunkgrootte aan het input-plafond van je embeddingmodel. Een model met een 512-token plafond vraagt chunks onder 512.
• Verrijk chunks met context (Anthropic's faalpercentage-daling van 5,7% naar 3,7%) voordat je de splitter opnieuw afstelt.
• Bouw eerst de eval-set. Elke splitter-beslissing zonder een voor- en na-meting is een gok.

Voor de volledige pipeline rond je chunking-keuze, zie een RAG-applicatie van begin tot eind bouwen. Twijfel je nog tussen retrieval en fine-tuning? RAG of fine-tuning legt uit wanneer welke wint.