HybridRAG: Uma Nova Abordagem para Geração de Texto em Tempo Real

Modelos de recuperação aumentada mostram que podem melhorar modelos de linguagem tradicionais. Eles ajudam esses modelos a entender melhor o contexto, usar dados privados e reduzir erros na geração de informações. Porém, o tempo que esses modelos levam para recuperar informações pode ser um problema, especialmente para tarefas que precisam de respostas rápidas, tipo ajudar a escrever.

Pra resolver esse problema, apresentamos o Hybrid Retrieval-Augmented Generation (HybridRAG). Essa estrutura usa uma mistura de modelos de cliente e de Nuvem. O HybridRAG usa uma memória que é criada na nuvem e enviada pro modelo cliente sem demora. Isso permite que o modelo cliente gere respostas eficazes aproveitando as habilidades do modelo de nuvem. A abordagem assíncrona significa que o modelo cliente pode dar respostas rápidas sem esperar a sincronização da memória da nuvem. Nossos testes usando os conjuntos de dados Wikitext e Pile mostram que o HybridRAG é mais rápido que modelos que dependem só da nuvem, enquanto ainda oferece melhor utilidade que modelos que funcionam apenas do lado do cliente.

Métodos de recuperação aumentada surgiram como ferramentas úteis pra melhorar o desempenho de modelos de linguagem grandes (LLM), já que eles podem usar documentos externos. Essa capacidade permite que modelos como o GPT3 reúnam contexto extra, levando a uma melhor compreensão, manuseio mais fácil de dados privados e menos erros no conteúdo gerado.

Apesar disso, esses modelos de recuperação aumentada podem ser lentos por causa do seu tamanho e do passo extra necessário pra recuperar informações. Isso pode atrasar tarefas que pedem resultados instantâneos, como assistência na escrita.

Ferramentas pra composição em tempo real devem sugerir rapidamente as próximas palavras ou frases, geralmente dentro de um limite de tempo rígido (normalmente cerca de 100 milissegundos ou menos). Pra evitar atrasos, esses modelos normalmente rodam nos dispositivos dos usuários ao invés de na nuvem. Contudo, isso pode limitar seu tamanho e habilidades, tornando-os menos eficazes pra ajudar na composição. Enquanto alguns avanços recentes permitiram que modelos como o LLAMA produzam alguns tokens por segundo, eles ainda têm dificuldades pra completar uma frase em algumas centenas de milissegundos.

Além disso, adicionar um módulo de recuperação ao modelo cliente pode não ser prático, especialmente porque documentos relevantes geralmente ficam na nuvem. Isso pode adicionar mais atrasos durante a recuperação.

Pra lidar com essas questões, apresentamos o Hybrid Retrieval-Augmented Generation (HybridRAG). Essa estrutura permite que pequenos modelos de linguagem em dispositivos dos usuários usem memória criada na nuvem de forma assíncrona. O HybridRAG inclui um modelo de recuperação e um gerador de memória em um servidor na nuvem. O coordenador de aumento e o modelo cliente com memória aumentada estão nos dispositivos dos usuários. O modelo da nuvem cria a memória e a envia pro modelo cliente sem atraso. Assim, o cliente pode responder a solicitações em tempo real sem esperar atualizações de memória da nuvem.

Em resumo, nossas contribuições incluem:

1. Aumento de recuperação híbrida pra geração em tempo real: Propomos uma nova estrutura que facilita a geração rápida de texto em dispositivos cliente, usando aumento de recuperação da nuvem. Nosso método utiliza comunicação assíncrona pra fornecer respostas rápidas enquanto reduz o impacto de atrasos na rede.

2. Desempenho competitivo: Introduzimos um método pra melhorar a utilidade do modelo cliente através de memória gerada por LLM. Usando rótulos gerados pelo GPT3 pra treinamento, nosso modelo melhora significativamente o desempenho do modelo cliente.

3. Redução da necessidade de comunicação cliente-nuvem: Nosso coordenador de aumento minimiza solicitações por memória aumentada, buscando atualizações apenas quando a memória antiga está desatualizada. Usar pontos de bala do GPT3 também reduz a quantidade de dados transferidos.

Nós avaliamos nossa abordagem usando cinco conjuntos de dados de referência cobrindo vários tópicos. Os resultados mostram que nosso modelo teve desempenho melhor que a melhor base híbrida, com uma melhora média de 48,6% na pontuação GLEU através da memória gerada por LLM e um ganho adicional de 9,5% após o ajuste de instruções no modelo cliente. Além disso, o design Assíncrono da nossa estrutura proporcionou um aumento notável de 138 vezes na velocidade em comparação com um modelo síncrono nos mesmos testes.

#Pesquisa Relacionada

A ideia de computação híbrida entre dispositivos de borda e nuvem não é nova. A computação híbrida de borda-nuvem é sobre compartilhar tarefas entre dispositivos de borda e nuvem pra fazer o melhor uso de suas forças. Esse método geralmente divide tarefas de processamento pra melhorar eficiência e velocidade. Entretanto, não há muita pesquisa focada especificamente em computação híbrida para modelos de aprendizado de máquina.

Um conceito relacionado é a computação dividida, onde diferentes partes de modelos de aprendizado de máquina são divididas entre ambientes de borda e nuvem. Por exemplo, uma parte de um modelo pode funcionar em um dispositivo de borda pra extrair características, enquanto outra parte classifica dados na nuvem. Essa configuração não só equilibra custos, mas também proporciona benefícios de privacidade. Na computação dividida, tanto a borda quanto a nuvem trabalham juntas pra finalizar uma execução de inferência.

Outra abordagem é o aprendizado federado, que usa vários dispositivos pra ajudar a treinar modelos. Esse método é mais voltado pra treinamento e menos pra rodar modelos. Alguns serviços de nuvem têm padrões pra gerenciar tarefas de aprendizado de máquina entre dispositivos locais e na nuvem, mas muitas vezes envolvem dividir componentes de um modelo completo, mantendo partes principais hospedadas na nuvem.

Além disso, há trabalhos focados em melhorar como os modelos funcionam em dispositivos de borda e métodos pra reduzir modelos grandes para dispositivos menores. No entanto, esses não são diretamente comparáveis à nossa estrutura.

#Visão Geral da Estrutura HybridRAG

O HybridRAG se beneficia da memória gerada na nuvem pra melhorar o modelo de linguagem cliente. Primeiro, esboçamos nossa abordagem, seguidos de detalhes sobre a geração de memória na nuvem e descrições do modelo cliente.

#Estrutura Geral

A estrutura HybridRAG é composta por quatro partes principais: um coordenador de aumento (cliente), um modelo cliente com memória aumentada (cliente), um modelo de recuperação (nuvem) e um gerador de memória (nuvem). O coordenador de aumento observa o contexto de escrita pra decidir quando buscar memória aumentada da nuvem. O modelo de recuperação do servidor da nuvem escaneia documentos relevantes, enquanto o gerador de memória usa o GPT3 pra criar memória útil a partir dos documentos. A memória aumentada é enviada pro cliente onde melhora o desempenho.

#Papel do Coordenador de Aumento

O coordenador de aumento gerencia a memória aumentada com base nas mudanças de contexto na escrita. Ele verifica se uma atualização é necessária com base nos contextos atuais e anteriores. Se a diferença ultrapassar um limite estabelecido, o coordenador solicita memória atualizada da nuvem. Pra evitar solicitações desnecessárias, ele usa um método de atualização incremental, onde apenas novas informações de contexto são usadas pra gerar memória atualizada.

Quando a memória atinge seu limite máximo, a memória mais antiga é substituída pela nova.

#Gerador de Memória pra Memória Aumentada por Recuperação

Quando o coordenador de aumento pede memória atualizada, o gerador de memória da nuvem a prepara em duas etapas: encontrar documentos relevantes e criar memória a partir deles.

#Encontrando Documentos Relevantes

Com base no contexto de entrada, o objetivo do recuperador é escolher os documentos mais relevantes de um grande banco de dados. Usamos o método de Recuperação de Passagens Densas (DPR), que funciona com codificadores duplos treinados para tarefas de pergunta-resposta. O recuperador codifica tanto o documento quanto a consulta, avaliando sua similaridade pra selecionar os melhores documentos.

#Criando Memória

Depois de encontrar os melhores documentos, ao invés de usá-los diretamente, nós usamos um modelo de linguagem grande como o GPT3 pra resumir os pontos-chave dos documentos recuperados. Esses pontos de bala criam a memória aumentada, que é muito menor e mais fácil de lidar do que documentos completos. Isso reduz o tempo de transferência pro cliente e diminui a carga no modelo cliente.

Pra resumir informações de um documento, primeiro o dividimos em parágrafos. Escolhemos um tamanho que mantenha as frases completas. Cada parágrafo é processado pelo GPT3 pra extrair pontos-chave, que são então combinados pra formar uma memória completa pra solicitação atual. Essa nova memória é adicionada à memória existente.

#Modelo Cliente com Memória Aumentada

Diferente de modelos anteriores com memória aumentada que focavam apenas no desempenho, nosso modelo cliente visa aproveitar ao máximo a memória criada por LLM. Acreditamos que até um modelo de linguagem menor pode ter um bom desempenho o suficiente pra usar memória aumentada em tarefas mais simples como parafrasear conteúdo.

Porém, treinar esse modelo cliente pode ser difícil devido à falta de dados de treinamento. Especificamente, ele precisa de dados onde haja um prompt, a memória aumentada e o texto real pra completar. Conseguir as duas últimas partes pode ser complicado. Pra lidar com isso, sugerimos um novo método que usa um modelo de linguagem grande pra gerar os dados de treinamento necessários.

Começando com um documento, selecionamos aleatoriamente uma parte pra ser o prompt de entrada. Em seguida, geramos a memória aumentada conforme planejado. Pra completar o texto, podemos usar o resto do documento ou fazer o GPT3 criar os rótulos de conclusão. Usar o GPT3 proporciona melhores resultados, já que pode produzir rótulos de alta qualidade que nosso modelo pode então aprender.

Depois de preparar os dados de treinamento, ajustamos nosso modelo cliente com o prompt baseado em instruções e os rótulos completos gerados pelo GPT3. Isso ajuda o modelo cliente a utilizar melhor a memória aumentada.

#Experimentos

Apresentamos os resultados de avaliação da nossa abordagem HybridRAG em diversos conjuntos de dados de referência. Vamos introduzir a configuração experimental e detalhar como nosso modelo se comporta em comparação a vários modelos de baseline em relação à utilidade e velocidade de inferência.

#Configuração Experimental

Utilizamos o conjunto de dados WikiText-103 e quatro conjuntos de dados do benchmark Pile pra treinar e testar nosso modelo. Para ajuste de instruções, aproveitamos o conjunto de treinamento do WikiText-103, que compreende 15.220 páginas wiki.

Nas nossas avaliações, usamos o conjunto de teste do WikiText-103 junto com os subconjuntos de Emails da Enron, HackerNews, NIH ExPorter e Legendas do Youtube do Pile. Esses conjuntos de dados cobrem várias áreas como artigos de notícias, emails, registros médicos e legendas de vídeos. Comparamos as previsões de nossos modelos com as de um modelo maior, o GPT3.

#Detalhes da Implementação

Para o nosso modelo cliente, usamos dois modelos OPT menores, um com 125 milhões de parâmetros (OPT-125M) e outro com 350 milhões (OPT-350M). Esses modelos são treinados pra prever texto enquanto ainda são pequenos o suficiente pra rodar eficientemente pra ajudar na escrita em tempo real. Usamos um método chamado decodificação gulosa pra geração de texto.

Durante a fase de treinamento, usamos máquinas com GPUs Tesla V100. Para testes de latência, nosso modelo cliente roda em duas configurações: uma máquina com GPU e um laptop sem GPU dedicada. A geração de pontos de bala utiliza o poderoso modelo GPT3 na API da OpenAI.

#Métricas de Avaliação

Pra avaliar o desempenho, usamos várias métricas automatizadas. Primeiro, medimos a Perplexidade, que reflete a confiança do modelo em processar texto. Menor Perplexidade indica melhor compreensão e entendimento. Também avaliamos comparando o conteúdo gerado com os rótulos fornecidos usando métricas como GLEU, BLEU, ROUGE, METEOR e BERTScore.

Pra analisar a latência de inferência, medimos o tempo levado pra recuperação de documentos, geração de memória e previsão de texto. Isso nos dá uma visão sobre a eficiência do nosso sistema.

#Métodos de Baseline

Comparamos nossa abordagem HybridRAG a vários métodos de baseline:

1. Vanilla OPT: Um modelo cliente OPT padrão usado pra completar texto sem memória adicional.

2. RAG: A abordagem de Geração Aumentada por Recuperação adaptada à nossa estrutura, utilizando o modelo DPR pra recuperar dados relevantes da nuvem.

3. HybridRAG sem ajuste fino: Examinando a eficácia do nosso modelo cliente ajustado por instruções em comparação a um que não foi ajustado.

4. GPT3 zero-shot: Usando o modelo GPT3 em um contexto zero-shot pra completar texto. Note que esse modelo não roda em dispositivos cliente.

Garantimos comparações justas regenerando rótulos de referência com o GPT3, ajustados pra memória usada em cada caso de baseline.

#Resultados Experimentais

Os resultados destacam como nossos modelos se comportam em comparação aos baselines no conjunto de dados WikiText-103, usando os modelos OPT-125M e OPT-350M. Mostra que nossa abordagem supera outros modelos por margens significativas. Por exemplo, nosso método mostra melhorias na Perplexidade e nas pontuações GLEU por percentagens notáveis em comparação aos modelos cliente padrão.

A mesma tendência é observada no desempenho do modelo OPT-350M nos conjuntos de dados Pile. Vemos um desempenho consistente superior a modelos de baseline, mostrando a capacidade do nosso modelo de generalizar bem mesmo sem ajuste específico nos conjuntos de dados do Pile.

#Latência de Inferência

Avalíamos a latência dos modelos OPT-125M e OPT-350M em diferentes configurações de hardware. Nossos testes revelam que o modelo OPT-125M é mais rápido que o modelo OPT-350M, indicando que o tamanho do modelo influencia significativamente a velocidade de inferência.

Nossa abordagem assíncrona mostra melhorias impressionantes na velocidade, superando métodos síncronos por uma grande margem. Além disso, nossa estrutura opera de forma eficiente até em dispositivos sem GPUs dedicadas.

#Atualizações de Memória Assíncronas

A eficácia das atualizações de memória assíncronas também foi avaliada. Descobrimos que, à medida que o contexto envelhece, ele tende a se tornar menos relevante, o que impacta negativamente a utilidade. No entanto, quando o limite de atualização aumentou, a queda no desempenho foi mínima, mostrando resiliência no nosso método.

#Estudos de Caso

Pra uma visão mais profunda de como o HybridRAG funciona, examinamos as saídas de vários modelos sob diferentes condições. Notavelmente, tanto os modelos HybridRAG OPT-125M quanto OPT-350M produziram respostas fluentes e factuais em alguns casos. Contudo, também houve instâncias em que ambos os modelos geraram saídas incorretas ou repetitivas.

Ao analisar essas conclusões, identificamos maneiras de melhorar nosso design HybridRAG. Melhorar o gerador de memória e refinar as habilidades de raciocínio do modelo cliente são áreas potenciais pra futuras melhorias.

#Conclusão

Neste trabalho, apresentamos o HybridRAG, uma abordagem inovadora pra assistência na composição em tempo real. Combinando memória aprimorada pela nuvem com um modelo cliente ajustado por instruções operando de forma assíncrona, demonstramos melhorias significativas em utilidade e velocidade. Nossos experimentos em vários conjuntos de dados confirmam que esse método efetivamente une as forças dos modelos de nuvem e cliente para aplicações em tempo real.

O desempenho do nosso sistema depende fortemente de quão bem a memória gerada na nuvem suporta o modelo cliente. Em pesquisas futuras, pretendemos examinar maneiras ainda melhores de representar e aumentar essa memória com base em tarefas específicas. Explorar métodos alternativos de aprimoramento de memória também permanece uma prioridade pra refinar ainda mais as capacidades do nosso modelo.