Pare de Fazer Chunking Como se Estivéssemos em 2022 — Yuval Belfer, AI21 Labs
AAI Engineer
컴퓨터/소프트웨어AI/미래기술
스크립트
00:00:00Olá a todos. Obrigado por virem hoje. Bem-vindos a uma palestra sobre nada. Desculpem, uma palestra sobre
00:00:21recuperação. Meu nome é Yuval. Trabalho na AI21, que é essencialmente um laboratório de pesquisa em IA. E hoje,
00:00:29quero falar com vocês sobre algo de que a maioria das pessoas não quer falar, que é a segmentação (chunking).
00:00:37E espero convencê-los no final de que a segmentação não morreu e de que ainda há muito o que fazer com isso.
00:00:45E na verdade, se você está no X, no LinkedIn, onde quer que seja, provavelmente já viu que o RAG morreu, certo?
00:00:53Acho que as pessoas também mataram o MCP ultimamente. E o RAG morreu de novo. Vida longa à recuperação orgânica,
00:01:00à busca orgânica. E chega um momento em que você tem que se perguntar: quantas vezes o RAG pode morrer?
00:01:07Não é? E mesmo quando alguém diz, bem, o RAG não morreu, como o Jerry, o CEO da Llama Index,
00:01:14eles ainda precisam matar alguma coisa. E aparentemente, essa coisa é a segmentação. Tipo, não investe nisso.
00:01:23Não faça isso. E essa é a razão pela qual as pessoas dizem que a segmentação está morta, porque todo mundo está usando
00:01:30busca agêntica agora, certo? Você tem greps, tem ls, tem finds. Tudo isso é ótimo,
00:01:36mas ainda não é suficiente se você tem muitos dados e uma enorme variedade de consultas.
00:01:46Só um segundo. Ok. E eu acho que a principal razão pela qual muita gente não gosta de falar
00:01:51sobre segmentação é porque não é a parte divertida, certo? Em qualquer sistema RAG ou de arquivos,
00:02:00temos duas etapas. A primeira etapa é a chata, por assim dizer. Aquela que você faz no início,
00:02:07você tem muitos dados. Precisa pré-processá-los. Tem que decidir o tamanho do segmento. E então
00:02:13você precisa armazenar tudo em um banco de dados vetorial. A outra parte é a parte de recuperação, essencialmente a que
00:02:20acontece por consulta. Isso é algo muito mais fácil de fazer, certo? É bem mais simples de
00:02:25otimizar. Você pode usar todas as suas consultas e depois brincar com o max K, o top K, desculpe, você pode brincar
00:02:32com a busca híbrida, quem sabe, esse tipo de coisa. É muito mais divertido fazer ajustes de recuperação, certo?
00:02:40Então, eu afirmo que, se tivermos que matar algo, se algo tem que morrer, então provavelmente é
00:02:47o ajuste de recuperação. E sim, a busca agêntica provavelmente matou isso. Mas ainda assim, a busca agêntica, mesmo se
00:02:55aceitarmos o fato de que ela matou o ajuste de recuperação, ainda não é boa o suficiente quando você tem muitos
00:03:02dados. Custa muito dinheiro. Acho que não preciso mais mencionar isso. O consumo máximo de tokens
00:03:09é algo de que todo mundo está falando. E a questão subjacente é que, se os próprios dados
00:03:17não estiverem organizados da maneira certa em suas pastas, em seus diretórios, você ainda terá algo que é
00:03:25ineficiente. Então vamos tentar pensar em um exemplo oportuno, certo? A Copa do Mundo da FIFA está acontecendo agora. E vamos
00:03:33imaginar que temos um conjunto de dados que contém toda a Copa do Mundo da FIFA. Então cada diretório é, digamos,
00:03:40o de 98, o de 2002 e assim por diante. Mas se a sua consulta perguntar qual seleção ganhou mais Copas
00:03:50do Mundo, você não pode simplesmente ir a uma pasta e acessar isso. Você tem que ir a cada pasta, ver quem ganhou e
00:03:57depois agregar tudo isso, o que é muito ineficiente. A resposta imediata é o Brasil, espero eu, pelo menos
00:04:03de acordo com a época em que esta conversa está acontecendo. Portanto, a recuperação não morreu de fato. Não estamos
00:04:13matando nada nesta palestra. Ela foi rebaixada a encanação. E acho que todos que trabalharam em
00:04:21qualquer sistema RAG conhecem esse sentimento. No dia um, ou na semana um, ou talvez até no mês um, se você for muito minucioso,
00:04:29você escolhe algum tipo de tamanho de segmento. Digamos 512. E talvez coloque alguma sobreposição,
00:04:36certo, 10%, 20%, e assim por diante, indexa tudo e esquece o assunto. E você pode, certo,
00:04:43falamos muito sobre as estratégias de segmentação fixa, onde se o seu segmento for grande demais,
00:04:49certo, você obtém o panorama geral, o que é legal, mas perde muitas das nuances. E todos os
00:04:54segmentos não terão incorporações (embeddings) significativas. Por outro lado, se você escolher tamanhos de segmento pequenos demais,
00:05:00você perde o panorama geral. E realmente, não será tão eficiente. Então o que isso nos diz é
00:05:07que a segmentação é essencialmente uma compressão com perdas. Não importa o que façamos, estamos perdendo algo.
00:05:15E eu afirmo que não existe um tamanho de segmento correto. E muitos de vocês que trabalharam com dados dirão:
00:05:23não, mas nós temos este corpus, nós temos este conjunto de dados, e nós realmente usamos e otimizamos nosso sistema para
00:05:29funcionar muito, muito bem com esses dados. E nós também pensávamos assim. Nós tivemos muita experiência com isso,
00:05:35com muitos tipos diferentes de agentes, sistemas e fluxos de trabalho em que você realmente pode,
00:05:40e, certo, você pensa em benchmarks, como é fácil ajustar excessivamente (overfit) o seu modelo a um benchmark.
00:05:48Mas não com o RAG. Isso não acontece lá. E você não pode realmente otimizá-lo por conjunto de dados. E eu vou
00:05:54mostrar como garantir que ele seja dependente da consulta. E como posso ter tanta certeza? Como posso afirmar
00:06:00uma coisa dessas? Porque nós rodamos experimentos, testamos e agora vou apresentar isso a vocês. Então o que fizemos,
00:06:06em vez de dizer qual é o melhor tamanho de segmento por dado, vamos descobrir. Vamos pegar
00:06:14um conjunto de dados e duplicá-lo várias vezes. Nesse caso, seis vezes. Em cada duplicação,
00:06:23em cada instância, o tamanho do segmento é diferente. Então temos um banco de dados com tamanho de segmento de 2.000,
00:06:28um banco de dados com tamanho de segmento de 1.000, e assim por diante. E fizemos isso com vários conjuntos de dados,
00:06:36como QMSUM, que é um conjunto de dados de transcrições de reuniões. Narrative QA, que é perguntas e respostas sobre
00:06:41romances. E o conjunto de dados Seinfeld, que são curiosidades sobre o nada. Na verdade, não. São perguntas de trivia
00:06:49sobre as transcrições de Seinfeld. É meio que um conjunto de dados de provocação que construímos internamente. Também
00:06:56o publicamos caso alguém queira o link no final. E testamos em todos eles para ver o que acontece.
00:07:03E primeiro de tudo, queríamos apenas ver, para cada conjunto de dados, qual tamanho de segmento é o melhor. E o que
00:07:10estamos vendo aqui é um exemplo do conjunto de dados Seinfeld, onde essencialmente duas consultas, que são
00:07:16diferentes por natureza, obtêm resultados distintos com base no tamanho do segmento. Então a primeira pergunta: qual é o
00:07:24nome da camisa favorita do Jerry? Vocês podem ver que esta é uma pergunta muito focada, muito específica.
00:07:28A resposta para ela provavelmente é bem contida. E isto é algo em que um tamanho de segmento menor
00:07:33vai se sair melhor. E vocês podem ver a classificação 1 versus abaixo de 50. Entre 100 tokens de tamanho
00:07:43de segmento fixo para 100. Enquanto uma pergunta como: quem Jerry descreve como seu nêmesis e pura maldade,
00:07:50o que, eu nem sou tão fã de Seinfeld assim, e sei que é o Newman. Mas se você olhar para a
00:07:56transcrição, não é algo que você encontre tão facilmente. E dá para ver que isso realmente muda, certo? Se você usar
00:08:02um segmento pequeno, você não conseguirá a resposta. E o que fizemos para realmente -- depois de executarmos
00:08:10tudo isso e todas essas coisas, percebemos, dissemos: e se tivéssemos um oráculo, ou um gênio, se
00:08:19preferirem, que pudesse nos dizer, para cada consulta, qual é o melhor tamanho de segmento para fazer a recuperação? Essencialmente,
00:08:25este é o experimento do oráculo. É isso que queríamos saber para ver o potencial. Isso não é -- nós já temos
00:08:33a capacidade de construir um sistema aqui. Nós só queremos ver qual é o potencial que temos aqui. E o que você pode
00:08:38ver aqui, ok, neste gráfico, todo o azul -- primeiro de tudo, o eixo y é o recall. Quanto maior, melhor. O
00:08:46eixo x é o número de segmentos recuperados. Portanto, é o recall em k versus k. Você pode ver todas as linhas azuis, provavelmente
00:08:52indistinguíveis, mas cada uma delas é o desempenho para um tamanho de segmento fixo. Enquanto a linha laranja é a
00:09:01linha do oráculo. Esta é -- para cada consulta, pegamos a melhor entre elas. E você pode ver que isso acontece
00:09:09em vários conjuntos de dados. Em muitos deles, você realmente pode ver que as linhas azuis se cruzam
00:09:16entre si, o que significa que, de fato, para muitos conjuntos de dados, nenhum tamanho de segmento domina de fato. E o que
00:09:24é mais interessante é que há muito potencial. A lacuna que você pode ver entre a linha laranja
00:09:30e todas as linhas azuis é grande. E quando digo grande, é algo em torno de 20 a 40 por cento apenas por
00:09:38fazer estratégia na segmentação. E uma estratégia muito simples, devo acrescentar. E esta -- essa lacuna é o que a
00:09:47escolha de 512 ou 1.000 ou o que quer que seja, certo? Esse número é apenas arbitrário. É isso que custa a você. E eu
00:09:56acho que o problema aqui é -- é um pouco complicado porque é como se fosse um problema de informação em que não temos
00:10:07a informação de que precisamos em cada estágio. E o que quero dizer com isso? Se eu estiver olhando para a parte de indexação,
00:10:12onde eu tenho controle sobre o tamanho do segmento, eu não sei quais serão as consultas.
00:10:18Eu posso adivinhar. Posso talvez estimar. Posso tentar. Mas não sei quais serão as consultas, portanto não consigo
00:10:25ajustar o tamanho do meu segmento de acordo. E na parte de recuperação, onde eu tenho minhas consultas,
00:10:31eu não consigo controlar o tamanho do segmento, certo? Ele já está fixo. E obviamente não vou refazer o processo inteiro
00:10:37por consulta desde o início. Então olhamos para trabalhos anteriores, notoriamente a recuperação
00:10:47contextual entrópica, onde eles enriquecem cada segmento, e outros que essencialmente tentam melhorar o espaço
00:10:54latente de cada segmento. Mas esta não foi a direção que seguimos. Todos eles continuaram no modelo
00:11:01de vamos trabalhar com um tamanho de segmento fixo, enquanto nós adotamos uma abordagem diferente. E dissemos: por que nos comprometer com
00:11:08um quando podemos nos comprometer com vários? E chamamos isso de indexação multiescala. Basicamente, estamos apenas
00:11:16fazendo o que vimos antes. Então verificamos o banco de dados. Nós o duplicamos e o segmentamos com vários
00:11:26tamanhos de segmentos ou de janelas. E então, isso é o que acontece na indexação. E depois, no momento da recuperação,
00:11:34fazemos consultas em todos eles. Portanto, se tínhamos n duplicatas do banco de dados e tamanhos de janela, agora precisamos executar
00:11:43seis chamadas de recuperação diferentes por consulta. Desculpem, seis como n. E como os combinamos? Obviamente não podemos
00:11:52usar o oráculo, certo? O oráculo é algo que temos apenas para o potencial. Na vida real,
00:11:57não sabemos a resposta. Mas o que podemos fazer é encontrar algum tipo de algoritmo de mesclagem. Agora, vocês diriam,
00:12:06quando olhamos para isso assim, qual pode ser o problema? O fato de termos n classificações,
00:12:13mas as classificações são para segmentos. E segmentos com tamanhos diferentes não são realmente comparáveis,
00:12:19certo? Então, em vez disso, optamos por fazer algo que é bastante popular hoje em dia. E muitos dos
00:12:25Os sistemas RAG funcionam assim: em vez de recuperar apenas o trecho, quando recebemos um
00:12:30trecho, recuperamos o documento inteiro, certo? Com o crescimento da janela de contexto, queremos dar cada vez mais
00:12:35contexto. E agora, neste caso, temos n classificações dos mesmos documentos, porque eles não são
00:12:44mais trechos. E isso podemos comparar. E aqui, você pode pensar na recuperação essencialmente
00:12:50como uma votação, tudo bem? Então não é puramente uma classificação. Não temos uma classificação única para depois
00:12:56reclassificar. Temos n classificações diferentes dos documentos relevantes e queremos agregá-las
00:13:03todas em uma só. É por isso que usamos algo chamado RRF, Reciprocal Rank Fusion, que é basicamente
00:13:11uma fórmula simples. Tentamos várias coisas e esta funcionou melhor. Como podem ver, não é um
00:13:17modelo. Não é algo que você precise fazer de forma específica. É apenas um
00:13:23script simples que não leva praticamente nenhum tempo. E é assim que o sistema completo se parece. Temos a
00:13:32indexação n vezes, depois consultamos cada consulta em cada base de dados e usamos o RRF para combiná-las
00:13:40todas. E os resultados, podem imaginar que são bons, caso contrário eu não estaria aqui
00:13:48sendo tão confiante, certo? Mas podem ver que testamos em vários conjuntos de dados: QMSum,
00:13:56Narrative QA, Seinfeld e também Finance Bench. Pegamos todos e superam o nosso tamanho fixo
00:14:05da melhor forma. Vamos ver num gráfico. É um pouco difícil de ver aqui, então vou explicar com calma. Cada linha
00:14:12aqui é o tamanho do bloco. Então você vê 50, 100 e assim por diante. A linha inferior é o nosso método. Este aqui, aquele
00:14:21aquele em que você faz a busca em todos e depois combina. E cada coluna é o recall em algum ponto. Recall em um,
00:14:31dois, três, até 10. O que podem ver aqui são duas coisas, certo? Primeiro, que em relação
00:14:39ao recall em qualquer ponto, o nosso método ainda ganha, o que pode parecer muito fácil, mas o fato de
00:14:46ter que combinar todos eles não é algo muito trivial. E também podem ver que a qualidade
00:14:53na verdade aumenta. O mapa de calor fica muito mais verde. E repito, isto era apenas
00:14:58algo que eu queria mostrar em maior escala. Aqui podem ver todos os quatro conjuntos de dados onde alcançamos
00:15:06resultados melhores. Realmente cerca de 20, 30, 40 por cento em muitos casos. Além disso, há resultados
00:15:14que não mostrei aqui que estão no MTab. Como podem ver no nosso blog, cujo link colocarei depois, estamos obtendo
00:15:22também muitas melhorias por lá, entre 10 e 40 por cento, dependendo do conjunto de dados.
00:15:30Agora, eu não sou ingênuo. Não vou afirmar aqui que isto não custa nada. Obviamente há um custo,
00:15:36certo? Não há almoços grátis. Tudo tem um preço. E sim, isto custa mais memória.
00:15:43Custa algo entre 2 a 5 O(1), certo? Uma constante de memória adicional em que você precisa manter
00:15:51todas essas cópias da base de dados. No entanto, se pensar bem, em termos de latência, isso não afeta
00:15:59tanto porque você pode fazer toda a parte de recuperação em paralelo. E também a parte do RRF não demora muito tempo.
00:16:10Diria que este foi um projeto de investigação muito interessante que fizemos e obtivemos resultados muito, muito fixes.
00:16:16Há coisas a fazer, certo? Há aspetos a melhorar. Há trabalho futuro a realizar. Mais precisamente,
00:16:23queremos entender quantos tamanhos de trecho queremos e quais, certo? O facto de termos trabalhado com 50, 100,
00:16:32200, etc., foi bastante arbitrário, para ser honesto. Por isso, precisamos de descobrir como calcular isto e
00:16:40como saber exatamente quantas cópias são necessárias. Além disso, ir além do RRF, certo? O facto de
00:16:46estarmos a usar o RRF é porque funcionou melhor entre os métodos que usá-amos, mas isso não significa que não
00:16:52exista um método melhor. E se eu tiver de vos deixar com uma mensagem, diria que os agentes não mataram
00:16:59a recuperação. Nada morreu. Ora essa. É apenas infraestrutura. E a parte má é que se trata
00:17:07de infraestrutura de 2022. E com métodos realmente simples, você pode melhorar o seu sistema RAG ou qualquer coisa relacionada
00:17:17ao armazenamento de dados e à sua recuperação em 20 a 40 por cento, mais uma vez, sem recorrer a nada
00:17:26muito sofisticado. Portanto, se quiser ler mais sobre isso, pode ler o blog. Também há código de exemplo
00:17:34lá e o conjunto de dados de Seinfeld. E é tudo. Sou o Yuval. Muito obrigado por estarem aqui.
00:17:47Vejo-vos na próxima.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기