Pare de fazer chunking como se estivéssemos em 2022 — Yuval Belfer, AI21 Labs

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Stop Chunking Like It’s 2022 — Yuval Belfer, AI21 Labs · Canal: AI Engineer · 17:35 · Assistir no YouTube

Tópicos: Agentes de IA, RAG, busca e recuperação de informação

Resumo

Yuval Belfer argumenta que chunking continua sendo uma parte importante de sistemas RAG, mesmo com o avanço de agentic search. Como o tamanho ideal dos chunks depende da consulta, não há um único tamanho fixo que funcione melhor para todas as perguntas. Experimentos em vários conjuntos de dados indicam que uma abordagem oracle, que escolhe o melhor tamanho para cada consulta, tem potencial para elevar o recall em 20% a 40%. A proposta apresentada, chamada multi-scale indexing, indexa os dados em vários tamanhos e combina os resultados com RRF, em troca de maior uso de memória.

Pontos-chave

Chunking é uma etapa de pré-processamento que afeta o que os sistemas conseguem recuperar; não existe um tamanho de chunk ideal para todas as consultas.
Chunks grandes preservam mais contexto, mas podem reduzir a precisão das representações; chunks pequenos podem perder o contexto necessário para responder a perguntas amplas.
Nos experimentos, diferentes consultas tiveram melhor desempenho com diferentes tamanhos de chunk, e nenhum tamanho fixo dominou em todos os conjuntos de dados.
Um experimento oracle, que seleciona o melhor tamanho de chunk para cada consulta, revelou uma diferença potencial de recall de 20% a 40% em relação a tamanhos fixos.
A proposta de multi-scale indexing cria versões do índice com vários tamanhos de janela e consulta todas elas.
Para combinar os resultados, o método recupera documentos em vez de comparar diretamente rankings de chunks de tamanhos diferentes e usa RRF.
A abordagem superou os melhores tamanhos fixos nos conjuntos de dados testados, com melhorias relatadas de aproximadamente 20% a 40% em vários casos.
O custo principal é o uso adicional de memória para manter várias cópias do índice; as consultas podem ser executadas em paralelo.
Trabalhos futuros incluem determinar quantos tamanhos de chunk usar e explorar métodos de combinação além de RRF.

Capítulos

Início	Capítulo	Resumo
00:01	Por que chunking ainda importa	Yuval apresenta a discussão e questiona a ideia de que agentic search tornou chunking obsoleto.
03:11	O problema dos tamanhos fixos	Um exemplo sobre dados da Copa do Mundo ilustra as limitações da recuperação, e a palestra descreve chunking como uma forma de compressão com perdas.
05:46	Experimentos com tamanhos de chunk	Os testes em QMSum, NarrativeQA e Seinfeld mostram que consultas diferentes podem se beneficiar de tamanhos diferentes.
10:00	A proposta de multi-scale indexing	A palestra apresenta a indexação em várias escalas e a combinação de rankings de documentos com RRF.
13:48	Resultados e custos	A abordagem supera tamanhos fixos nos conjuntos testados, com maior uso de memória e pouca influência relatada na latência.
15:55	Limitações e próximos passos	Yuval aponta questões em aberto, como escolher os tamanhos de chunk e testar alternativas a RRF, e conclui que retrieval continua sendo infraestrutura necessária.

Citações

Chunking é essencialmente uma compressão com perdas. — 04:43

Não existe um tamanho de chunk correto. — 05:15

Por que se comprometer com um, se podemos nos comprometer com vários? — 11:06

Agentes não mataram retrieval. Nada morreu. — 16:29

Conceitos e entidades

Yuval Belfer (pessoa): Pesquisador da AI21 Labs que apresenta a palestra sobre chunking e recuperação.
AI21 Labs (empresa): Empresa descrita na palestra como um laboratório de pesquisa em IA.
chunking (conceito): Processo de dividir dados em partes para armazená-los e recuperá-los em um sistema RAG.
agentic search (conceito): Abordagem de busca com agentes que, segundo a palestra, não elimina a necessidade de preparar os dados.
multi-scale indexing (conceito): Método que indexa os mesmos dados com vários tamanhos de chunk e combina os resultados das consultas.
RRF (reciprocal rank fusion) (conceito): Método usado para combinar rankings de documentos obtidos por diferentes índices.
QMSum (conceito): Conjunto de dados de transcrições de reuniões usado nos experimentos apresentados.
NarrativeQA (conceito): Conjunto de dados de perguntas e respostas sobre romances usado nos experimentos.
Seinfeld dataset (conceito): Conjunto de perguntas triviais sobre transcrições de Seinfeld, criado pela equipe e mencionado na palestra como publicado.
FinanceBench (conceito): Conjunto de dados financeiro incluído na avaliação do método.

Tradução completa (pt-BR)

00:01 [música] >> Oi, pessoal. Obrigado por virem hoje. Bem-vindos a uma palestra sobre nada. Quer dizer, uma palestra sobre retrieval. Meu nome é Yuval. Trabalho na AI21, que é essencialmente um laboratório de pesquisa em IA. E hoje quero falar com vocês sobre algo de que a maioria das pessoas não quer

00:34 falar, que é chunking. Espero convencê-los, até o fim, de que chunking não morreu e de que há algo a fazer a respeito. E, de verdade, se vocês estão no X, no LinkedIn ou em qualquer outro lugar, provavelmente já viram alguém dizer que RAG morreu. Certo? Acho que ultimamente também mataram o MCP. E RAG morreu de novo. Vida longa à IA agêntica, ao retrieval, à busca agêntica. E chega uma hora em que você precisa

01:04 se perguntar: quantas vezes RAG pode morrer? Certo? E mesmo quando alguém diz “bem, RAG não morreu”, como Jerry, o CEO da LlamaIndex, ainda precisa matar alguma coisa, e aparentemente essa coisa é chunking. Tipo: não invista nisso. Não faça isso. E a razão pela qual as pessoas disseram que chunking morreu é que todo mundo está usando busca agêntica agora, certo? Você tem grep, ls, find.

01:35 Tudo isso é ótimo, mas ainda não basta quando você tem muitos dados e uma grande variedade de consultas. Só um segundo. E acho que a principal razão para muita gente não gostar de falar sobre chunking é que essa não é a parte divertida, certo? Em todo sistema de RAG ou de arquivos, temos duas etapas. A primeira é a mais entediante, como vocês podem imaginar. É a que fazemos no começo.

02:07 Você tem muitos dados. Precisa pré-processá-los. Precisa decidir o tamanho dos chunks. E depois precisa armazenar tudo em um banco de dados vetorial. A outra parte é o retrieval. Essencialmente, é a que acontece a cada consulta. Isso é muito mais fácil de fazer, certo? É muito mais fácil de otimizar. Você pode usar todas as suas consultas e brincar com o K máximo — quer dizer, o top K, desculpem. Pode experimentar a busca híbrida, talvez. Esse tipo de coisa. É muito mais divertido ajustar o retrieval, certo?

02:40 Então, vou defender que, se precisamos matar alguma coisa, se alguma coisa precisa morrer, provavelmente é o ajuste do retrieval. E sim, a busca agêntica provavelmente o matou. Mas, ainda assim, mesmo que aceitemos que a busca agêntica matou o ajuste do retrieval, ela continua não sendo boa o suficiente quando você tem uma escala realmente grande, muitos dados. Custa muito dinheiro. Acho que nem preciso mais mencionar isso. Maximizar tokens é algo de que todo mundo está falando.

03:11 E o problema por baixo disso é que, se os próprios dados não estiverem organizados da maneira certa nas pastas e nos diretórios, você ainda vai obter algo ineficiente. Então, vamos pensar em um exemplo atual, certo? A Copa do Mundo da FIFA está acontecendo agora. Vamos imaginar que temos um conjunto de dados que contém todas as Copas do Mundo da FIFA. Cada diretório corresponde, digamos, à edição de 98, à de 2002

03:42 e assim por diante. Mas, se a sua consulta perguntar qual time venceu mais Copas do Mundo, você não pode simplesmente ir a uma pasta e perguntar isso. Precisa ir a todas as pastas, ver quem venceu e depois agregar os resultados, o que é muito ineficiente. A resposta, aliás, é o Brasil, espero — pelo menos de acordo com o Woo! É, de acordo com o momento em que esta conversa está acontecendo. Então, retrieval não morre de fato,

04:12 certo? Não vamos matar nada nesta palestra. Ele foi rebaixado a encanamento. E acho que todo mundo que já trabalhou em algum sistema de RAG conhece essa sensação. No primeiro dia, na primeira semana ou talvez até no primeiro mês, se você for muito meticuloso, escolhe algum tamanho de chunk. Digamos, 512. Talvez você também coloque uma sobreposição, certo? De 10%, 20% e assim por diante, indexa tudo e esquece o assunto. E pode fazer isso, certo? Falamos muito

04:43 sobre estratégias de chunking fixo: se o chunk for grande demais, você obtém o quadro geral, o que é bom, mas perde muitas nuances, e os embeddings de todos os chunks não serão significativos. Já se escolher chunks pequenos demais, perde o quadro geral. E, na prática, isso não será tão eficiente. Isso nos mostra que chunking é, essencialmente, uma compressão com perda. Não importa o que façamos, perdemos alguma coisa.

05:15 E vou defender que não existe um tamanho de chunk certo. Muitos de vocês que trabalharam com dados vão dizer: “Não, mas temos este corpus, temos este conjunto de dados, usamos de verdade e otimizamos nosso sistema para funcionar muito, muito bem com esses dados”. Nós também pensávamos assim. Tínhamos muita experiência com isso, com muitos tipos diferentes de agents, sistemas e workflows. Dá mesmo para pensar nisso, certo? Pensem em benchmarks. Como é fácil ajustar demais seu modelo a um

05:46 benchmark. Mas não com RAG. Isso não acontece nesse caso. E você não consegue realmente otimizá-lo por conjunto de dados. Vou defender que isso depende da consulta. E como posso ter tanta certeza? Como posso afirmar algo assim? Porque fizemos experimentos e testamos, e agora vou apresentar os resultados a vocês. Então, em vez de perguntar qual é o melhor tamanho de chunk para cada conjunto de dados, decidimos descobrir. Vamos, vamos pegar um conjunto de dados e duplicá-lo várias vezes. Neste caso, seis vezes.

06:22 Em cada duplicata, em cada instância, o tamanho do chunk é diferente. Assim, temos um banco de dados com chunks de 2.000, outro com chunks de 1.000, e assim por diante. Fizemos isso com vários conjuntos de dados. QMSum, que é um conjunto de dados de transcrições de reuniões; NarrativeQA, que é de perguntas e respostas sobre romances; e o conjunto de dados Seinfeld, que é de curiosidades sobre nada. Na verdade, não. São perguntas de curiosidades sobre as transcrições de Seinfeld. É um conjunto de dados meio provocativo que nós

06:54 criamos internamente. Também o publicamos; se alguém quiser o link, posso passar no final. E testamos todos eles para ver o que acontece. Primeiro, queríamos simplesmente ver qual tamanho de chunk era melhor para cada conjunto de dados. O que vemos aqui é um exemplo do conjunto de dados Seinfeld, em que, essencialmente, duas consultas de naturezas diferentes têm resultados diferentes dependendo do tamanho do chunk. A primeira pergunta é: qual é o nome da camisa favorita do Jerry? Dá para dizer que é uma pergunta

07:26 bem focada, bem específica. A resposta provavelmente está bem delimitada, e um tamanho de chunk menor funciona melhor nesse caso. Dá para ver a posição 1 em comparação com uma posição abaixo de 50, ao passar de um tamanho fixo de chunk de 100 tokens para 100. Já uma pergunta como “Quem Jerry descreve como seu inimigo mortal e o puro mal?”, e eu nem sou tão fã de Seinfeld, mas sei que é o Newman. Se você olhar para

07:56 a transcrição, não é algo que se encontre com tanta facilidade. E dá para ver que isso muda bastante, certo? Se usar chunks pequenos, não vai obter a resposta. Então, depois de executar tudo isso e percebermos esse padrão, nos perguntamos: “E se tivéssemos um oráculo, ou um gênio, se preferirem, capaz de nos dizer qual é o melhor tamanho de chunk para fazer retrieval para cada consulta?” Esse é, essencialmente, o experimento do oráculo.

08:26 Era isso que queríamos descobrir, para ver o potencial. Isso não é uma situação real, porque já temos as respostas. Portanto, não estamos construindo um sistema de verdade aqui. Só queremos ver qual é o potencial que temos. E o que vocês podem ver aqui — bem, neste gráfico — é que todas as linhas azuis… Primeiro, o eixo Y é o recall. Quanto maior, melhor. O eixo X é o número de chunks recuperados. Então, é recall em K em função de K. Dá para ver todas as linhas azuis, provavelmente indistinguíveis, mas cada uma delas representa o desempenho de um

08:57 tamanho fixo de bloco. Já a linha laranja é a linha do oráculo. Isso vale para cada consulta: pegamos o melhor resultado entre esses. E dá para ver que isso acontece em vários conjuntos de dados. Em muitos deles, dá para ver que as linhas azuis se cruzam, o que significa que, de fato, para muitos conjuntos de dados, nenhum tamanho de bloco é realmente superior aos outros. E o que é mais interessante é que há muito potencial. A diferença, que você pode ver

09:28 entre a linha laranja e todas as linhas azuis, é grande. E, quando digo grande, estou falando de algo entre 20% e 40%. Só com uma estratégia de segmentação em blocos — e uma estratégia bem simples, vale acrescentar. Essa diferença é o custo da escolha de 512, 1.000 ou qualquer outro número, certo? Esse número é arbitrário. É isso que essa escolha custa. E acho que o problema aqui é que

10:00 é um pouco complicado, porque é como um problema de informação: não temos as informações de que precisamos em cada etapa. O que quero dizer com isso? Se estou olhando para a etapa de indexação, em que posso controlar o tamanho dos blocos, não sei quais serão as consultas. Posso adivinhar. Talvez consiga estimar. Posso tentar, mas não sei quais serão as consultas, então não posso ajustar o tamanho dos blocos de acordo com elas. E, na etapa de recuperação, quando tenho as consultas, não posso controlar o tamanho dos blocos,

10:34 certo? Ele já está definido. E, obviamente, não vou executar todo o processo desde o início para cada consulta. Então, analisamos trabalhos anteriores, como, notavelmente, o da Anthropic sobre recuperação contextual, em que enriquecem cada bloco, e outros que tentam melhorar o espaço latente de cada bloco. Mas não seguimos nessa direção. Todos eles permaneceram no modelo de trabalhar com um tamanho fixo de bloco, enquanto nós adotamos uma abordagem diferente.

11:06 E dissemos: “Por que se comprometer com apenas um, quando podemos nos comprometer com vários?” Chamamos isso de indexação em múltiplas escalas. Essencialmente, estamos fazendo o que vimos antes. Verificamos o banco de dados, duplicamos e o dividimos em blocos de vários tamanhos, ou tamanhos de janela. E então — desculpe — isso acontece durante a indexação. Depois, no momento da recuperação, fazemos consultas em todos eles. Então,

11:36 se tivéssemos n cópias do banco de dados, com n tamanhos de janela, agora teríamos que executar seis chamadas de recuperação diferentes por consulta. Desculpe, seis é n. E como combinamos os resultados? Obviamente, não podemos usar o oráculo, certo? O oráculo serve apenas para mostrar o potencial. Na vida real, não sabemos a resposta. Mas o que podemos fazer é encontrar algum tipo de algoritmo de combinação. Agora, você poderia dizer, olhando para isso,

12:08 qual pode ser o problema? O fato de termos n rankings, mas os rankings são de blocos. E blocos de tamanhos diferentes não são realmente comparáveis, certo? Então, em vez disso, optamos por fazer algo bastante popular atualmente, que muitos sistemas RAG realmente fazem: em vez de recuperar apenas o bloco, quando encontramos um bloco, recuperamos o documento inteiro, certo? À medida que a context window cresce, queremos fornecer cada vez mais contexto. E agora, nesse caso, temos n rankings dos mesmos documentos, porque

12:44 eles já não são blocos. E podemos compará-los. Nesse caso, você pode pensar na recuperação como uma votação, certo? Então, não se trata puramente de ranking. Não temos rankings de execução para depois fazer um reranking. Temos n rankings diferentes dos documentos relevantes e queremos agregá-los em um só. Por isso, usamos algo chamado RRF, fusão recíproca de posições, certo? É basicamente uma fórmula simples. Testamos várias coisas. Essa funcionou melhor.

13:15 E, como você pode ver, não é um modelo. Não é algo que você precise fazer de maneira específica, especialmente. É apenas um script simples que praticamente não leva tempo. E é assim que o sistema completo se parece. Fazemos a indexação n vezes, depois consultamos cada banco de dados com cada consulta e usamos RRF para combinar tudo. Você pode imaginar que os resultados são bons; caso contrário, eu não estaria aqui sendo tão confiante. Certo,

13:48 mas você pode ver que testamos em vários conjuntos de dados: QMSum, NarrativeQA, SciFact e também FinanceBench. Usamos todos eles, e o método iguala os melhores resultados obtidos com tamanhos fixos. Vamos ver isso em um gráfico. É um pouco difícil de enxergar aqui, então vou explicar devagar. Cada linha corresponde a um tamanho de bloco, como você pode ver: 50, 100 e assim por diante. A linha de baixo é o nosso método, este aqui: o

14:21 que você obtém usando todos eles e depois combinando os resultados. E cada coluna é o recall em determinado ponto. Então, recall em 1, 2, 3, até 10. O que dá para ver aqui são duas coisas, certo? Primeiro, que nosso método ainda vence em diferentes valores de recall, o que pode parecer muito fácil, mas combinar tudo isso não é algo tão trivial.

14:51 E também dá para ver que a qualidade realmente aumenta. O mapa de calor fica muito mais verde. E, novamente, eu só queria mostrar isso em tamanho grande. Aqui você pode ver todos os quatro conjuntos de dados, nos quais conseguimos resultados melhores — melhorias de 20%, 30%, até 40% em muitos casos. Também há resultados que não mostrei aqui, no MTEB. Você pode vê-los no nosso blog; vou colocar o link mais tarde. Também estamos conseguindo muitas melhorias, entre

15:25 10% e 40%, dependendo do conjunto de dados. Agora, não sou ingênuo. Não vou afirmar aqui que isso não tem custo. Obviamente, há um custo, certo? Não existe almoço grátis. Tudo tem um preço. E sim, isso custa memória extra. O custo fica entre duas e cinco vezes, ou O de um, certo? Um aumento constante de memória, pois é preciso manter todas essas cópias do banco de dados.

15:55 No entanto, se você pensar bem, isso não afeta muito a latência, porque é possível executar toda a etapa de recuperação em paralelo. Além disso, a etapa de RRF não leva muito tempo. Eu diria que este foi um ótimo projeto de pesquisa e que obtivemos resultados muito legais. Ainda há coisas a fazer, certo? Há pontos a melhorar. Há trabalho futuro a realizar. Mais especificamente, queremos entender de quantos tamanhos de bloco precisamos e quais devem ser.

16:29 Certo, o fato de termos trabalhado com 50, 100, 200 e assim por diante foi bastante arbitrário, para ser sincero. Então, precisamos descobrir como calcular isso e como saber exatamente de quantas cópias precisamos. Também queremos ir além do RRF, certo? Usamos RRF porque foi o que funcionou melhor entre os métodos que testamos, mas isso não significa que não exista um método melhor. E, se eu tiver que deixar uma mensagem para vocês, diria que os agents não acabaram com a recuperação. Nada morreu. Vamos lá. É apenas

17:03 infraestrutura. E a parte ruim é que é uma infraestrutura de 2022. Com métodos bem simples, você pode melhorar seu sistema RAG, ou qualquer coisa que envolva armazenar dados e depois recuperá-los, em 20% a 40%, mais uma vez, sem nada sofisticado demais. Então, se quiser ouvir mais ou ler mais sobre isso, você pode ler o blog. Também há um exemplo de código lá e o

17:35 conjunto de dados Sign. E é isso. Sou Yuval. Muito obrigado por estarem aqui. >> Uhu! >> [aplausos] [música]

Transcrição original

[00:01] [music] >> Hi everybody. Uh, thank you for coming today. Uh, welcome to a talk about nothing. Sorry, a talk about retrieval. My name is Yuval. 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 want to

[00:34] talk about, which is chunking. And I hope to convince you by the end that chunking isn’t dead and there is something to do with that. And really, if you are at X, LinkedIn, wherever, you’ve probably seen that RAG is dead. Right? I think people also killed MCP lately. And RAG is dead again. Long live agentic AI, retrieval, agentic search. And there is come the come a time where you have

[01:04] to ask yourself, how many times can RAG die? Right? And even when someone says, well, RAG isn’t dead, like 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 is using agentic search now, right? You have grabs, you have LS, you have finds.

[01:35] All of these are great, but these are still not enough if you have a lot of data and you have various amount of queries. Just a second. 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 rug or 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.

[02:07] 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 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 the hybrid search, maybe. Those kind of things. Much more fun to do retrieval tuning, right?

[02:40] Uh so, I will claim that if we have to kill something, if something has to be dead, then it’s probably retrieval tuning. And yes, identic search probably kill that. And but still identic search, even if we can accept the fact that it killed the 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 don’t think I have to mention that anymore. Token maxing is like

[03:11] something that everybody’s talking about. And the thing underneath, which is 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 like a timely example, right? The FIFA World Cup is now. And let’s imagine that we have a data set that contains of all the FIFA World Cup. So, every directory is the let’s say the ’98 one, the 2002

[03:42] one, and so on, and so on. But if your query asks whi- 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 Woo! Yeah, uh according to the time that this uh conversation is happening. So, retrieval doesn’t actually die,

[04:12] okay? We’re not killing anything in this uh lecture. It 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 talked a lot

[04:43] about the fixed chunking strategies, where if your chunk 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.

[05: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 corpus, we have this data set, and we really used it, 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 right? You think about benchmarks. How easy it is to overfit your model to a

[05:46] benchmark. But not with uh rag. It doesn’t happen there. And you cannot really optimize it per data set. 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 run experiments and we tested and now I’m going to 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 data set and duplicate this data set several times. In this case, six times.

[06:22] In every duplication, in every instance, the chunk size is different. So we have a database with a chunk size of 2,000, a database with a chunk size of 1,000 and so on and so on. And we did it with several data sets. So QMSum, which is a meeting transcript data set, NarrativeQA, which is question answering on novels, and Seinfeld data set, which is trivia about nothing. Not really. It’s a trivia trivia questions about the transcripts of the Seinfeld. It’s a kind of a trolling data set that we

[06:54] built 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 data set which chunk size is the best. And what we’re seeing here is an example from the Seinfeld data set where essentially two queries, which are different by nature, get different results based on the chunk size. So the first question, what is the name for Jerry’s favorite shirt? You can say this is a

[07:26] 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 rank one versus rank below 50. Between 100 tokens fixed uh uh size chunk size to 100. Whereas a question like where 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

[07:56] 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 noticed that, we said, “What if we had an 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

[08:26] 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, okay, in this graph, all the blue First of all, the Y axis is the recall. Higher is 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 the performance for a

[08:57] 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 data sets. In a lot of them, you can actually see that the blue lines inter intersect with each other, meaning that indeed for a lot of the data sets, no chunk size actually dominates. And what’s more interesting is that there’s a lot of potential. The gap, which you can see

[09:28] between the orange line and all the blue lines, is big. And when I say big, it’s something like 20 to 40%. Just from doing strategy on chunking and very simple strategy, may I add. And this is like that this gap, this is what the choice of 512 or 1,000 or whatever, right? This number is just arbitrary. This is what it costs you. And I think that the the problem here is like

[10:00] it’s a bit tricky because it’s kind of like a 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 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 chunk size accordingly. And the retrieval part where I do have my queries, I cannot control the chunk size,

[10:34] right? It’s already fixed. And I obviously will not do the entire process per query from the beginning. So, we looked at prior works such as notably Entropic, contextual retrieval, where they enrich every chunk, and others that fancy try to improve the latent space of every chunk. But this is not the direction that we went. All of them just stayed in the model of let’s work with a fixed chunk size, whereas we took a different

[11:06] approach. And we said, “Why commit to one where we can commit to several?” And we call it the multi-scale indexing. Essentially, we’re just doing what we’ve seen before. So, we’re checking the database, we duplicate it, and chunk it with several chunk chunk sizes or window sizes. And then, sorry, um, and then this is happens at the indexing. And then at retrieval time, we are querying all of them. So,

[11:36] if we had n uh duplicates of database n window sizes, we now have to run six different retrieval calls per query. Uh sorry, uh six is n. And how do we combine them? 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,

[12:08] what can be the issue? The fact that we have n ranking, but the rankings are for 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? And uh rankings of the same documents, because

[12:44] they’re not 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 run 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’re using something called RRF, reciprocal rank fusion, okay, which is pretty much a simple uh formula. We tried several things. This worked the

[13:15] best. And as you can see, it’s not a model. It’s not something 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 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 they’re good, otherwise I would not uh standing here in uh

[13:48] being way too much uh uh confident. All right, but you can see we tested across several data sets, a QM sum, narrative QA, SciFeL, and also a finance bench. Uh we took all of them, and it matches the best uh bits that 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 size, so you can see 50, 100, and so on. The bottom row is our method, this one, the

[14:21] one that you do from all of them and then combine, and the every column is uh recall at something. So, recall at 1, 2, 3, up until 10. What you can see here is that two things, right? First of all, that across like recall at whatever, uh our method still wins, which you can think 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.

[14:51] 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 data sets, where we do achieve better results uh really quite like 20, 30, 40% even in a lot of the things. Uh also, there are results that I did not show you here, uh which uh are on MTAB. Uh you can see in our blog, I will put the link later. We’re getting there also a lot of improvements, somewhere between

[15:25] 10 to 40% depending on the data set. Now, I’m I’m I’m not naive. I’m not going to 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 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.

[15:55] 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. Uh I will say that this was a very nice research project that we did and we 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.

[16:29] All right, that the fact that we worked with 50, 100, 200, and so on was pretty arbitrary uh to be honest. So, we do need to figure out how to compute this 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. Nothing died. Come on. Uh it’s just

[17:03] infrastructure. And the part the bad bad part is that it’s infrastructure from 2022. 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 20 to 40% again, without any something too sophisticated. So, if you want to hear more about or read more about it, you can read the blog. There is also an example code there and the

[17:35] sign for data set. And that’s it. I’m Yuval. Thank you so much being here. >> Woo! >> [applause] [music]