A Geração Aumentada por Recuperação (RAG) Será Morta por LLMs de Contexto Longo?
A busca por inovação e supremacia em IA não mostra sinais de desaceleração. Recentemente, o Google revelou o Gemini 1.5, apenas dois meses após a estreia do Gemini, seu mais recente modelo de linguagem grande (LLM) capaz de lidar com contextos que chegam a impressionantes 10 milhões de tokens. Simultaneamente, a OpenAI entrou em cena com o Sora, um robusto modelo de texto para vídeo celebrado por seus efeitos visuais cativantes. O confronto entre essas duas tecnologias de ponta gerou discussões sobre o futuro da IA, especialmente o papel e o possível desaparecimento da Geração Aumentada por Recuperação (RAG).
Neste blog, exploraremos os detalhes das capacidades de contexto longo do Gemini, suas limitações e seu impacto na evolução das técnicas de Geração Aumentada por Recuperação. Mais importante, discutiremos se a RAG está à beira do desaparecimento e como otimizar sistemas RAG.
Entendendo a capacidade de contexto longo do Gemini
Embora o apelo dos efeitos visuais do Sora atraia mais atenção, estou mais interessado no Gemini e em seu relatório técnico complementar, com mais de 50 páginas e que explora os testes das capacidades de contexto longo e multimodais do Gemini. De acordo com esse relatório, o Gemini 1.5 Pro oferece suporte a contextos ultralongos de até 10 milhões de tokens e ao processamento de dados multimodais, permitindo que o Gemini interaja perfeitamente com dados diversos, desde um livro inteiro e enormes coleções de documentos até extensas bibliotecas de código e um filme de uma hora.
O Gemini 1.5 Pro oferece suporte a contextos ultralongos de até 10M tokens. Fonte da imagem: https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/
Estabilidade e precisão da recuperação
Este relatório apresenta um método de avaliação "agulha no palheiro" para testar e comparar a capacidade de recuperação do Gemini 1.5 Pro e do GPT-4. Nesse teste, o Google insere segmentos de texto (as "agulhas") em diferentes posições de um documento extenso (o "palheiro"), e o Gemini e o GPT precisam encontrar e nomear documentos relevantes para recuperá-los.
Os resultados dos testes mostram que o Gemini 1.5 Pro alcança 100% de recall com até 530.000 tokens e mantém mais de 99,7% de recall com até 1M de tokens. Mesmo com um documento superlongo de 10M de tokens, o modelo mantém uma impressionante taxa de recall de 99,2%. Enquanto o GPT-4 lida de forma excelente com menos de 128.000 tokens, o Gemini é mais proficiente em lidar com contextos mais extensos. Esses resultados ressaltam a excelente recuperação de informações, estabilidade e precisão do Gemini em contextos excepcionalmente longos de até 10M de tokens.
Fonte da imagem: https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
Resposta a perguntas
Além de testar a capacidade de recuperação do Gemini, o Google avalia sua capacidade de responder a perguntas fornecer contexto. Nesse teste, o Google usa o livro Les Misérables (710.000 tokens) como contexto e pede ao Gemini 1.5 Pro, ao Gemini 1.0 Pro e ao Claude 2.1 da Anthropic que respondam a perguntas sobre o livro.
Como o Gemini 1.0 Pro e o Claude 2.1 suportam um comprimento de contexto menor do que 710.000 tokens, eles devem aproveitar a técnica de geração aumentada por recuperação (RAG) para acessar as passagens mais relevantes Top-K (até 4.000 tokens) do livro como seu contexto. O Gemini tem uma janela de contexto maior, então ele se refere ao livro inteiro como seu contexto. Este teste também compara o desempenho dos três modelos na configuração 0-shot sem nada fornecido como contextos.
Os resultados dos testes mostram que o Gemini 1.5 Pro supera outros LLMs com RAG ao responder perguntas, demonstrando seu domínio na compreensão e no processamento de coleções de texto gigantescas. Este teste também revela que a técnica de geração aumentada por recuperação frequentemente tem dificuldade em resolver expressões referenciais e raciocínio entre fontes de dados com dependências de longa distância.
Fonte da imagem: https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
LLMs de contexto longo vão matar o RAG?
O framework de geração aumentada por recuperação, incorporando um banco de dados vetorial, um LLM e prompt-as-code, é uma tecnologia de ponta que integra perfeitamente fontes externas de conhecimento para enriquecer a base de conhecimento de um LLM para documentos e respostas precisos e relevantes. É uma solução comprovada que aborda efetivamente desafios fundamentais dos LLMs, como alucinações e falta de conhecimento específico de domínio.
Ao testemunhar o desempenho impressionante do Gemini ao lidar com contextos longos, algumas vozes rapidamente preveem o fim do RAG. Por exemplo, em uma análise do Gemini 1.5 Pro no Twitter, o Dr. Yao Fu afirmou ousadamente: "O contexto de 10M mata o RAG."
Essa afirmação é verdadeira? Da minha perspectiva, a resposta é “NÃO.” O desenvolvimento da tecnologia RAG apenas começou e continuará a evoluir. Embora o Gemini se destaque no gerenciamento de contextos extensos, ele enfrenta desafios persistentes encapsulados como os 4Vs: Velocidade, Valor, Volume e Variedade.
Os desafios dos 4Vs dos LLMs
Velocidade: O Gemini enfrenta obstáculos para alcançar tempos de resposta inferiores a um segundo para contextos extensos, evidenciado por um atraso de 30 segundos ao responder a 360.000 contextos. Apesar do otimismo sobre os avanços computacionais dos LLMs, respostas rápidas em nível inferior a um segundo ao recuperar contextos longos continuam sendo desafiadoras para grandes modelos baseados em transformers.
Valor: A proposta de valor dos LLMs é prejudicada pelos consideráveis custos de inferência associados à geração de respostas de alta qualidade em contextos longos. Por exemplo, recuperar 1 milhão de tokens de conjuntos de dados a uma taxa de 1.50 por uma única solicitação. Esse fator de custo torna tais gastos elevados impraticáveis para uso cotidiano, representando uma barreira significativa para a adoção generalizada.
Volume: Apesar de sua capacidade de lidar com uma grande janela de contexto de até dez milhões de tokens, a capacidade de volume do Gemini é insignificante quando comparada à vastidão de dados não estruturados. Por exemplo, nenhum LLM, incluindo o Gemini, consegue acomodar adequadamente a escala colossal de dados encontrada no índice de busca do Google. Além disso, dados corporativos privados terão que permanecer dentro dos limites de seus proprietários, que podem optar por usar RAG, treinar seus próprios modelos ou usar um LLM privado.
Variedade: Casos de uso do mundo real envolvem não apenas dados não estruturados, como textos longos, imagens e vídeos, mas também uma variedade diversa de dados estruturados que podem não ser facilmente capturados por um LLM para fins de treinamento, como dados de séries temporais, dados de grafos e alterações de código. Estruturas de dados e algoritmos de recuperação otimizados são essenciais para processar esses dados variados de forma eficiente.Todos esses desafios destacam a importância de uma abordagem equilibrada no desenvolvimento de aplicações de IA, tornando o RAG cada vez mais crucial no cenário em evolução da inteligência artificial.
Estratégias para Otimizar a Eficácia do RAG
Embora a geração aumentada por recuperação tenha se mostrado benéfica na redução de alucinações de LLM, ela tem limitações. Nesta seção, exploraremos estratégias para otimizar a eficácia da geração aumentada por recuperação, a fim de encontrar um equilíbrio entre precisão e desempenho para tornar os sistemas RAG mais adaptáveis em uma gama mais ampla de aplicações.
Aprimorando a Compreensão de Contextos Longos
Técnicas convencionais de geração aumentada por recuperação frequentemente dependem de chunking para vetorizar dados não estruturados, principalmente devido às limitações de tamanho dos modelos de embedding e de suas janelas de contexto. No entanto, essa abordagem de chunking apresenta duas desvantagens notáveis.
- Em primeiro lugar, ela divide a sequência de entrada em chunks isolados, interrompendo a continuidade do contexto e impactando negativamente a qualidade do embedding.
- Em segundo lugar, há o risco de separar informações consecutivas em chunks distintos, potencialmente resultando na recuperação incompleta de informações essenciais.
Em resposta a esses desafios, estratégias emergentes de embedding baseadas em LLMs ganharam força como soluções eficientes. Elas apresentam melhor capacidade de embedding e oferecem suporte a janelas de contexto expandidas. Por exemplo, SRF-Embedding-Mistral e GritLM7B, dois dos modelos de linguagem de embedding com melhor desempenho no Huggingface MTEB LeaderBoard, suportam contextos de 32 mil tokens, demonstrando uma melhoria substancial nas capacidades de embedding. Esse aprimoramento no embedding de dados não estruturados também eleva a compreensão do RAG sobre contextos longos.
Outra abordagem eficaz para enfrentar os desafios acima é a estratégia BGE Landmark Embedding, lançada recentemente. Essa abordagem adota uma arquitetura sem chunking, na qual embeddings para as unidades de entrada de granularidade fina, por exemplo, frases, podem ser gerados com base em um contexto longo coerente. Ela também utiliza uma função sensível à posição para facilitar a recuperação completa de informações úteis que compreendem múltiplas frases consecutivas dentro do contexto longo. Portanto, o landmark embedding é benéfico para aprimorar a capacidade dos sistemas RAG de compreender e processar contextos longos.
A arquitetura para landmark embedding. Tokens Landmark (LMK) são anexados ao final de cada frase. Uma janela deslizante é empregada para lidar com textos de entrada mais longos que a janela de contexto do LLM. Fonte da imagem: https://arxiv.org/pdf/2402.11573.pdf
Este diagrama compara os métodos Sentence Embedding e Landmark Embedding para ajudar aplicativos RAG a responder perguntas. O primeiro trabalha com o contexto fragmentado, que tende a selecionar a frase saliente. O segundo mantém um contexto coerente, o que permite selecionar a frase correta. As frases destacadas em azul e roxo são respostas recuperadas pelos dois métodos de embedding, respectivamente. O sistema RAG que utilizou Sentence embedding deu a resposta errada, enquanto o RAG baseado em Landmark embedding deu a resposta correta. Esta imagem é adaptada de: https://arxiv.org/abs/2402.11573
Utilizando Hybrid Search para Melhorar a Qualidade da Busca
A qualidade das respostas de geração aumentada por recuperação depende de sua capacidade de recuperar informações relevantes de alta qualidade. Limpeza de dados, extração de informações estruturadas e hybrid search são formas eficazes de melhorar a qualidade da recuperação. Pesquisas recentes sugerem que modelos de sparse vector como Splade superam modelos de dense vector na recuperação de conhecimento fora do domínio, percepção de palavras-chave, busca semântica e muitas outras áreas.
O recém-disponibilizado como open source BGE_M3 embedding model pode gerar vetores de tokens esparsos, densos e semelhantes ao Colbert dentro do mesmo modelo. Essa inovação melhora significativamente a qualidade da recuperação do banco de dados vetorial ao conduzir recuperações híbridas em diferentes tipos de vetores. Notavelmente, essa abordagem está alinhada ao conceito amplamente aceito de hybrid search entre fornecedores de vector database como Zilliz. Por exemplo, o próximo lançamento do Milvus 2.4 promete uma busca híbrida mais abrangente de vetores densos e esparsos.
Utilizando Tecnologias Avançadas para Aprimorar o Desempenho do RAG
Neste diagrama, Wenqi Glantz listou 12 pontos problemáticos no desenvolvimento de um pipeline RAG e propôs 12 soluções correspondentes para enfrentar esses desafios. Fonte da imagem:https://towardsdatascience.com/12-rag-pain-points-and-proposed-solutions-43709939a28c
Maximizar as capacidades do RAG envolve enfrentar inúmeros desafios algorítmicos e aproveitar capacidades e tecnologias sofisticadas de engenharia. Como destacado por Wenqi Glantz em seu blog, desenvolver um pipeline RAG apresenta pelo menos 12 desafios complexos de engenharia. Enfrentar esses desafios exige uma compreensão profunda de algoritmos de ML e a utilização de técnicas complicadas como reescrita de consultas, dados de treinamento para reconhecimento de intenção, e detecção de entidades.
Mesmo modelos avançados como Gemini 1.5 enfrentam obstáculos substanciais. Eles exigem 32 chamadas para alcançar uma taxa de precisão de 90,0% nos testes de benchmark MMLU do Google. Isso ressalta a natureza de maximizar o desempenho em sistemas RAG.
Bancos de dados vetoriais, uma das tecnologias de IA de ponta, são um componente essencial no pipeline de RAG. Optar por um banco de dados vetorial mais maduro e avançado, como o Milvus, amplia as capacidades do seu pipeline de RAG, passando da geração de respostas para tarefas como classificação, extração de dados estruturados e processamento de documentos PDF complexos. Esses aprimoramentos multifacetados dos bancos de dados vetoriais contribuem para a adaptabilidade dos sistemas RAG em um espectro mais amplo de casos de uso de aplicações.
Conclusão: RAG continua sendo um pilar para o sucesso sustentado das aplicações de IA.
Grandes modelos de linguagem estão remodelando o mundo, mas não podem mudar os princípios fundamentais do nosso mundo. A separação entre computação, memória e armazenamento de dados externo existe desde o surgimento da arquitetura de von Neumann em 1945. No entanto, mesmo com a memória de uma única máquina atingindo hoje o nível de terabytes, discos SATA e flash ainda desempenham papéis cruciais em diferentes casos de uso de aplicações. Isso demonstra a resiliência de paradigmas estabelecidos diante da evolução tecnológica.
O framework RAG ainda é um pilar para o sucesso sustentado das aplicações de IA. Sua provisão de memória de longo prazo para grandes modelos de linguagem mostra-se indispensável para desenvolvedores que buscam um equilíbrio ideal entre qualidade das consultas e custo-benefício. Na implantação de IA generativa por grandes empresas, RAG é uma ferramenta crítica para controle de custos sem comprometer a qualidade das respostas.
Assim como os avanços em grandes memórias não conseguem eliminar os discos rígidos, o papel do RAG, aliado a suas tecnologias de suporte, como o banco de dados vetorial, permanece integral e adaptável. Ele está preparado para perdurar e coexistir dentro do novo cenário de dados em constante evolução das aplicações de IA e da recuperação de informações.
Continue lendo
Zilliz Cloud BYOC Now Available Across AWS, GCP, and Azure
Zilliz Cloud BYOC is now generally available on all three major clouds. Deploy fully managed vector search in your own AWS, GCP, or Azure account — your data never leaves your VPC.
Zilliz Cloud Now Available in Azure North Europe: Bringing AI-Powered Vector Search Closer to European Customers
The addition of the Azure North Europe (Ireland) region further expands our global footprint to better serve our European customers.
AI Integration in Video Surveillance Tools: Transforming the Industry with Vector Databases
Discover how AI and vector databases are revolutionizing video surveillance with real-time analysis, faster threat detection, and intelligent search capabilities for enhanced security.