AI Engineer World's Fair 2026
Stop Chunking Like It's 2022 — Yuval Belfer, AI21 Labs
Read the talk
Stop Chunking Like It's 2022
A small chunk can find a precise fact and miss a relationship spread across a scene. Yuval Belfer explains how searching several chunk sizes and combining whole-document rankings improves recall—and what that flexibility costs.
From a talk by Yuval Belfer
At a glance
Ideas worth remembering
The useful chunk size depends on the question: narrow windows can find contained facts while losing relationships that need surrounding context.
The oracle's reported 20%–40% recall gap measures headroom using known answers. It cannot choose a scale for an unanswered query.
Multiscale indexing searches N window sizes, maps chunk matches to whole documents, and combines comparable document rankings with Reciprocal Rank Fusion.
Belfer reports matching or beating the best fixed size across four datasets at roughly two to five times the memory. Parallel searches limit added latency; scale selection and better fusion remain open questions.
Agentic search still depends on how data is organized
Yuval Belfer of AI21 Labs opens with the recurring declarations that RAG—retrieval-augmented generation—is dead, followed by similar claims about chunking. Agents can explore files with tools such as grep, ls, and find. His objection concerns scale and variety: these tools alone do not make searching a large corpus efficient for many different kinds of questions. The work of dividing and indexing data still matters.
Indexing sets the units; retrieval searches them
- Indexing: Before questions arrive, preprocess the corpus, choose how much text each chunk contains, and store the resulting representations in a vector database. This determines the units the system can search.
- Retrieval: For each question, search those units. Developers can adjust top K, the number of results returned, or experiment with hybrid search. Because they already have the questions, they can inspect how these changes affect the results.
Belfer finds retrieval tuning easier to engage with: the questions are concrete and the effects are visible. The earlier decision about what each searchable unit contains receives less attention.
Agentic search does not remove the cost of a poor organization. Belfer imagines World Cup records arranged into a separate folder for each tournament, including 1998 and 2002. To answer which team won the most tournaments, an agent must visit the folders, find each winner, and aggregate the results. No individual tournament folder answers that question. An organization that suits a local lookup can make a cross-cutting question expensive, even when the agent navigates it correctly.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A fixed chunk size trades detail against context
Retrieval has become plumbing, Belfer says, and chunking often becomes a decision made once and forgotten. The familiar setup is to choose a size such as 512, add 10% or 20% overlap, index everything, and move on. Overlap lets neighboring chunks share some text, but the system still commits to a particular window. That window determines which information receives a searchable representation together.
- Large chunks preserve surrounding context. They keep more of a passage together, but their embeddings can blur a specific detail among other material. The whole picture survives while a small fact becomes harder to retrieve.
- Small chunks concentrate local detail. A focused passage can represent a contained fact more clearly, but it can separate that fact from the broader context needed to understand a relationship.
Belfer calls chunking lossy compression. The loss concerns the searchable representation: choosing a window favors some information and weakens other information. His claim is that the useful size depends on the query, even within one corpus. A fixed size that performs well on familiar questions can hide failures on questions that need a different amount of context. The experiments that follow test how much this difference matters.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Two Seinfeld questions need different windows
The team created six differently chunked instances of each dataset. Belfer names windows of 2,000 and 1,000 alongside smaller sizes. The initial datasets were QMSum, containing meeting transcripts; NarrativeQA, involving questions about novels; and an in-house Seinfeld trivia dataset built around episode transcripts. Holding the underlying material constant let the team compare what each scale could retrieve.
A contained fact and a contextual relationship
- Focused lookup: A question asking for the name of something associated with Jerry returns the relevant result at rank one with 100-token chunks, while larger windows place it beyond the first 50 results. Belfer's explanation is that a contained answer benefits from a narrow representation.
- Contextual lookup: A question asks whom Jerry describes as his nemesis and pure evil. Belfer identifies the answer as Newman, but reports that small chunks fail to retrieve it. Finding the relationship needs more surrounding transcript context than the focused lookup.
These questions make corpus-wide tuning an awkward compromise. A narrow window works for one question and fails for the other. The team therefore moves from asking which size wins on a dataset to asking how much performance is available when each query gets its favorable size.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The oracle measures the cost of committing too early
The oracle experiment uses the known answers to choose the best-performing chunk size for each query. It measures headroom: how well could the tested collection of sizes perform if the system always made the favorable choice? A real retrieval system cannot use this selector because it does not know the answer before searching.
Belfer describes plots with recall on the vertical axis and the number of retrieved chunks, K, on the horizontal axis. Each fixed-size curve shows recall at K for one window size. The oracle curve uses the best per-query outcomes across the tested sizes. Some fixed-size curves intersect, showing that a size's advantage changes with the retrieval cutoff. The oracle also captures differences between individual questions that disappear into dataset-level averages.
He reports a roughly 20%–40% recall gap between the oracle and fixed-size retrieval in the tested settings. That range describes an opportunity within those experiments. It does not establish that every system using 512 loses that amount, and the recording does not distinguish relative improvements from percentage-point differences.
The question arrives after the window is frozen
The information problem has two ends. At indexing time, the system controls chunk size but does not know the incoming questions. At retrieval time, it has the question but the indexed windows are already fixed. Changing them would repeat the indexing work. The system can estimate future questions, but it cannot adjust a single preselected size to every query as it arrives.
Belfer contrasts the team's direction with Anthropic's contextual retrieval, which he describes as enriching chunks to improve their representations. His team instead keeps several window sizes available. Rather than making one chunk representation carry every kind of question, multiscale indexing supplies several searchable views of the same material.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Search every scale, then combine rankings of whole documents
Multiscale indexing turns the experiment's duplicated corpus into a retrieval strategy. Index the material at N window sizes, then send each incoming query to all N indexes. The six instances used in the experiment are one choice of N. The system searches every available scale instead of predicting a winning size and searching only that index.
Searching several indexes produces several rankings, but their entries initially refer to different objects. A short passage and a larger passage containing it are distinct chunks. Their lists do not rank a shared set of candidates. The team changes the unit of comparison: a chunk match retrieves its entire source document. Each scale can now rank the same document identities, even though it found them through differently sized passages.
Document rankings become votes
Belfer describes the remaining step as voting. Each scale supplies a ranking of relevant documents; Reciprocal Rank Fusion, or RRF, combines those rankings into one list. This replaces the oracle's answer-aware choice with an aggregation of the available retrieval results. RRF worked best among the merging methods the team tried. Belfer describes its implementation as a simple script, without an additional learned reranking model.
Whole-document retrieval also separates the passage used to find information from the text supplied afterward. A narrow chunk can locate a document while the full document supplies surrounding context. Belfer connects this choice to growing model context windows. The recording does not quantify the downstream token cost or explain how documents that exceed a model's context window would be handled.
The same material is indexed at several window sizes.
Two example scales show the flow; the system searches all N scales. Chunk matches lead to whole documents, giving RRF shared candidates to combine.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Better recall costs memory—and leaves two choices open
The final evaluation covers QMSum, NarrativeQA, Seinfeld, and FinanceBench. Belfer reports that multiscale fusion matches or beats the best fixed size across those datasets. He walks through a heat map whose rows represent fixed chunk sizes and the combined method, while columns represent recall cutoffs from one through ten. Combining scales has to place useful documents high in the final ranking; merely finding them somewhere among N searches would not be enough.
Belfer reports improvements reaching roughly 20%, 30%, or 40% in many tested settings. These are retrieval results, so they do not establish equivalent gains in generated-answer accuracy. He also mentions MTEB improvements between 10% and 40%, depending on the dataset, but does not walk through those results in the recording. The practical fusion results remain separate from the oracle: they combine rankings without knowing which scale will find the answer.
Memory increases; searches can overlap in time
- Memory: Belfer gives a roughly two-to-five-times memory cost for keeping the additional indexed copies. With a fixed number of scales, this is a multiplier on the corpus's storage requirements; memory still grows with the corpus.
- Retrieval latency: He reports little added latency because the searches can run in parallel and RRF adds little computation. Parallelism lets searches overlap rather than run one after another. The system still performs N retrieval calls for each question.
The recording provides no timing measurements or accounting of indexing cost and concurrent serving capacity. Overlapping the searches explains how extra work can add little elapsed time, but does not eliminate that work.
Which scales, and which merger?
- Scale selection remains unfinished. Belfer says the tested choices, including 50, 100, and 200, were fairly arbitrary. The team still wants to determine which window sizes to use and how many indexed copies are necessary. Each additional scale spends memory and retrieval work, so their number matters alongside recall.
- RRF remains a tested choice. It performed best among the merging methods the team tried. Belfer explicitly leaves room for a better aggregation method; the experiments do not establish that RRF is the best possible merger.
Belfer's closing judgment returns to the infrastructure that agents inherit. Retrieval still matters, and a chunk size selected early should remain open to scrutiny. Multiscale indexing offers a simple experiment: keep several searchable views of the material, retrieve whole documents through each view, and combine their rankings. The reported recall gains give a reason to try it; the memory multiplier and unfinished scale selection determine what a team must weigh for its workload. He closes by pointing readers to the research blog, example code, and published Seinfeld dataset.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
- Yuval Belfer on XReference
Speaker profile supplied with the recording, including discussion of query-dependent chunk sizes.
Related talks
- RAG Evaluation Is Broken! Here's Why (And How to Fix It)
Belfer and Niv Granot examine aggregation questions that individual chunks cannot answer, extending the World Cup example into structured retrieval and evaluation.
Read the complete timestamped transcript
- 0:13
Hi, everybody. Uh, thank you for, uh, coming today. Uh, welcome to a talk about nothing... Sorry, a talk about retrieval. Uh, my name is Yuval. Uh, I work at AI21, which is essentially an AI research lab. And today, I want to talk to you about something that most people don't wanna talk about, which is chunking. And I hope to convince you by the end that chunking isn't dead, and there
- 0:43
is something to do with that. And really, if you are at X, LinkedIn, wherever, you've probably have seen that RAG is dead, right? I think people also killed MCP lately. And RAG is dead again. Long live agentic, uh, retrieval, agentic search. And there is co- there come a time where you have to ask yourself, "How many times can RAG die?" Right? And even when someone says, "Well, RAG isn't dead," like,
- 1:13
uh, Jerry, the CEO of LlamaIndex, they still have to kill something, and apparently this something is chunking. Like, don't invest in it, don't do it. And this is the reason that people said that chunking is dead because everybody's using agentic search now, right? You have greps, you have ls, you have finds. All of these are great, but these are still not enough if you have a lot of data and you have
- 1:42
various amount of queries.
- 1:46
Just a second. Okay. And I think that the main reason that a lot of people don't like to talk about chunking, it's because it's not the fun part, right? In every RAG or, uh, files, uh, system, we have two stages. The first stage is the, like, the boring one, as you may. The one you do in the beginning. You have a lot of data. You have to pre-process it, you have to decide on the chunk size, and then you have to store everything in a vector DB. The
- 2:16
other part is the retrieval part, essentially the, the one that happens per query. This is something which is much easier to do, right? It's much easier to optimize. You can use all your queries, and then you can play with the max K, uh, top K, sorry. You can, uh, play with a hybrid search maybe, those kind of things. Much more fun to do retrieval tuning, right? Uh, so I will claim that if we have to kill something, if something has to be dead,
- 2:46
then it's probably retrieval tuning. And yes, agentic search probably killed that. And but still agentic search, even if we can accept the fact that it killed agen- uh, retrieval tuning, it's still not good enough when you have a lot of, right, scale, a lot of data. It costs a lot of money. I, I don't think I have to mention that anymore. Token maxing is, like, something that everybody's talking about. And the thing underneath, which is
- 3:16
if the data itself is not ordered in a right way, in your folders, in your directories, you still get something which is inefficient. So let's try to think of a, like, a timely example, right? The FIFA World Cup, uh, is now, and let's imagine that we have a dataset that contains of all the FIFA World Cup. So every directory is the, let's say, the '98 one, the 2002 one, and so on and so on. But if your query
- 3:46
asks whi- how, which team won the most World Cups, you can't just go to a folder and ask that. You have to go to every folder, see who won, and then aggregate this together, which is very inefficient. The answer, by the way, is Brazil, I hope, at least according to- Whoo. Yeah, uh, according to the time that this, uh, conversation's happening. So retrieval didn't actually die, okay? We're not killing anything in this, uh, lecture. It
- 4:15
is... got demoted into plumbing. And I think that everybody who worked on any RAG system know the feeling. Day one or week one or maybe even month one if you're very thorough, you're picking some sort of a chunk size. Let's say 512. Uh, maybe you're probably putting some overlap, right? 10, 20%, so on, indexing everything and forget all about it. And you can... Right? We talk a lot about the fixed, uh, chunking
- 4:46
strategies where if you chunk, uh, something which is too big, right? So you get the whole picture, which is nice, but you're losing a lot of the nuance and all the chunks will not get meaningful embeddings. Where if you will choose your chunks to be too small, you're getting the big picture lost and really it won't be as efficient. So what this tells us is that chunking is essentially a lossy compression. No matter what we're doing, we're losing something.
- 5:15
And I will, I will claim that there is no right chunk size. And a lot of you who worked on data will say, "No, but we have this, uh, corpus, we have this dataset, and we really used and we optimized our system to work very, very well on this data." And we thought so too. We had a lot of experience with it, with a lot of different types of agents and systems and workflows that you can really... and, hmm, right? You think about benchmarks, how easy it is to overfit
- 5:45
your model to a benchmark. But not with, uh, RAG. It doesn't happen there. And you cannot really optimize it per dataset, and I will claim that it is query-dependent. And how can I be so sure? How can I claim such a thing? Because we ran experiments and we tested, and now I'm gonna present it to you. So what we did, instead of saying what is the best chunk size per data, let's find out. Let's, let's actually take a dataset
- 6:15
and dupl-duplicate this dataset several times, in this case, six times. In every duplication, in every instance, the chunk size is different. So we have a database with a chunk size of two thousand, a database with a chunk size of one thousand, and so on and so on. And we did it with several datasets, so QMSum, which is a meeting transcript dataset, NarrativeQA, which is question answering on, uh, novels, and Seinfeld dataset, which is trivia
- 6:45
about, uh, nothing. Uh, not really. It's, uh, trivia, qu-trivia questions about the transcripts of, uh, Seinfeld. It's, uh, kind of a trolling dataset that we built, uh, in-house. We also published it if anybody wants the, the link at the end. And we tested on all of them to see what happens. And first of all, we just wanted to see, for every dataset, which chunk size is the best. And what we're seeing here is an example from the Seinfeld dataset, where essentially two
- 7:15
queries which are different by nature get different results, uh, based on the chunk size. So the first question, what is the name for Jerry's favorite shirt? You can see this is a very focused question, very specific question. The answer to it is probably very contained, and this is something that a smaller chunk size will do best in. And you can see, uh, rank one versus rank below fifty, uh, between one hundred tokens, uh, fixed at chunk size to one hundred.
- 7:45
Whereas a question like wh-who does Jerry describe as his nemesis and pure evil, which I'm not even that big of a Seinfeld fan, and I know it's Newman, uh, but if you look at the transcript, it's not something you can find that easily. And you can see that it really changes, right? If you use small chunk size, you will not get the answer. And what we did to really... After we ran all of these things and we've noticed that, we said, "What if we had an
- 8:14
oracle or a genie, if you want, that can tell us for every query what is the best chunk size to do retrieval for?" This essentially is the oracle experiment. This is what we wanted to know to see the potential. This is not... Right? We already have the answers, so we're not actually building a system here. We just want to see what is the potential that we have here. And what you can see here, 'kay, uh, in this, uh, graph, all the blue... First of all, the Y-axis is the recall. Higher is
- 8:44
better. Uh, the X-axis is the number of retrieved chunks, so it's recall at K versus K. You can see all the blue lines, probably indistinguishable, but each of them is a performance for a fixed chunk size, whereas the orange one is the oracle line. This is for every query, we took the best one out of these. And you can see it happens across several datasets. In a lot of them, you can actually see that the blue lines
- 9:14
inter, uh, intersect with each other, meaning that indeed for a lot of the datasets, no chunk size actually dominates. And what's more interesting is that there's a lot of potential. The gap which you can see between the orange line and all the blue lines is big. And when I say big, it's something like twenty to forty percent just from doing strategy on chunking, and very simple strategy, may I add. And
- 9:44
this is, like, the, this gap, this is what the choice of five hundred and twelve or a thousand or whatever, right? This number is just arbitrary. This is what it costs you. And I think that the, the problem here is... Like, it's a bit tricky because it's kind of like a p- uh, an information problem, that we don't have the information that we need at every stage. And what do I mean by that? If I'm looking at the indexing part where I do have control over the chunk
- 10:14
size, I don't know what the queries will be. I can guess. I can maybe estimate. I, I can try, but I don't know what the queries will be, so I cannot adjust my, uh, chunk size accordingly. And the retrieval part where I do have my queries, I cannot control the chunk size, right? It's already fixed, and I obviously will not do the entire process per query from the beginning. So, uh, we looked at, uh, prior works
- 10:44
such as notably Anthropic, uh, contextual retrieval, where they intru- enrich every chunk, and others that essentially try to improve the latent space, uh, of every chunk, uh, but this is not the direction that we went. All of them just stayed in the model of let's work with a fixed, uh, chunk size, whereas we took a different approach and we said, "Why commit to one when we can commit to several?" And we call it the multi-scale indexing.
- 11:15
Es-essentially, we're just doing what we've seen before. So we're checking the database. We duplicate it and chunk it, uh, with several chu-chunk sizes or window sizes. And then... Sorry, um... And then this is what happens at the indexing, and then at retrieval time, we are querying all of them. So if we had N, uh, duplicates of the database and window sizes, we now have to run six different
- 11:45
retrieval calls per query. Uh, sorry, six is N. And how do we combine them? We, we obviously cannot use the oracle, right? The oracle is something that we have just for potential. In real life, we don't know the answer. Uh, but what we can do is to find some sort of merging algorithm. Now you would say when we look at it like this- What can be the issue? The fact that we have s- N ranking, but the rankings are for
- 12:14
chunks, and chunks with different sizes are not really comparable, right? So instead, we opted to do something which is pretty popular these days, and a lot of the RAG systems actually work like this, that instead of just retrieving the chunk, when we're getting a chunk, we're retrieving the entire document. Right? When context window grows, we want to give more and more context. And now, in this case, we have N, right, N, uh, rankings of the same documents because they're not
- 12:44
chunks anymore, and this we can compare. And in this case, you can think of retrieval as essentially just voting. Right? So it's not purely ranking. We don't have round ranking and then we're doing a re-rank. We're having N different ranks of the relevant documents, and we want to aggregate them all into one. That's why we are using something called RRF, Reciprocal Rank Fusion, okay, which is pretty much a simple, uh, formula. We tried several things.
- 13:15
This worked the best, and as you can see, it's not a model. It's not something, uh, that you have to do specifically, like, especially, this is just a simple script that takes really no time. And this is how the full, uh, how the full system looks like. So we have the indexing N times, then, uh, we query each query from every database, and we're using RRF to combine them all. And the results, you can guess that
- 13:44
they're good, otherwise I would not, uh, standing here and, uh- ... being way too much, uh, uh, confident. Right? But you can see we tested across several datasets, uh, QMSum, NarrativeQA, Seinfeld, and also, uh, FinanceBench. Uh, we took all of them, and it matches the be- or beats the best fixed, uh, size. Let's see it in a graph. Uh, it's a bit hard to see here, so I'll walk it slowly. Every row here is a chunk
- 14:15
size, so you can see fifty, one hundred, and so on. The bottom row is our method, this one, the one that you t- do from all of them and then combine. And the... every column is a recall at something, so recall at one, two, three, up until ten. What you can see here is that two things, right? First of all, that across, m- like, recall at whatever, uh, our method still wins, which you can think
- 14:45
is very easy, but the fact that you have to combine all of them is not very... it's not something which is very trivial. And also, you can see that the quality actually increases. The heat map where you can see it's become much greener. And again, this was just something that I wanted to show in large. Here you can see, uh, all four of the datasets where we do achieve better results, uh, really quite, like, twenty, thirty, forty percent even in a lot of the things. Uh, also there are results that I
- 15:15
did not show you here, uh, which, uh, are on MTEB. Um, you can see in our blog, I will put the link later. We're getting there also a lot of improvements, somewhere between ten to forty percent depending on the dataset. Now, I'm, I'm, I'm not naive. I'm not gonna claim here that this costs nothing. Obviously, there is a cost, right? No free lunches. Everything has to come with something. And yes, this costs with extra memory. It costs something
- 15:44
between two to five to... O of one, right? A constant of additional memory where you have to keep all of those, uh, all those, uh, copies of the database. However, if you think about it latency-wise, it doesn't really affect that because you can do all the retrieval part parallelly, and also the RRF part doesn't really take a lot of time.
- 16:10
Uh, I will say that this was a very nice research project that we did, and we've got really, really cool results. There are things to do, right? There are places to improve. There are future work, uh, to do. More precisely, we want to understand how many chunk sizes do we want and, and which, right? The, the fact that we worked with fifty, one hundred, two hundred and so on was pretty arbitrary, uh, to be honest. So we do need to figure out how to compute this
- 16:40
and how to know how many copies exactly do you need. Uh, also go beyond RRF, right? The fact that we're using RRF is because it worked the best from the methods that we used, but it doesn't mean that there is no better method. And if I need to leave you with something, I would say that agents didn't kill retrieval. N- nothing died. Come on. Uh, just infrastructure. And the part, the ba- bad part is that it's infrastructure from 2022,
- 17:10
and with really simple, simple methods, you can take your RAG system or anything that has to do with storing data and then retrieve it with twenty to forty percent, again, without any, you know, something too sophisticated. So if you, uh, want to hear more about or read more about it, uh, you can read the, the blog. There is also an example code there and the Seinfeld dataset. Um, that's it. I'm Yuval. Thank you so much, uh, being
- 17:40
here.