Desvantagens do RAG
Perda de informação, aumento do custo, e outras limitações
Me siga no X | Me siga no LinkedIn | Apoie a Newsletter | Solicite uma consultoria
RAG, que significa "Retrieval-Augmented Generation" (Geração com Enriquecimento por Recuperação), é um método que ajuda a fornecer a um modelo um contexto adicional ao qual ele não foi exposto durante o treinamento.
Imagine que você criou um sistema de perguntas e respostas que utiliza como base o GPT-4, que foi treinado com dados públicos de até abril de 2023. Aliado a estes dados, você também mantém uma base de documentos com informações úteis que o modelo desconhece (por exemplo, dados privados da sua organização), mas que poderia ser utilizado para responder as perguntas de maneira apropriada.
À medida que as perguntas dos usuários chegam, é possível procurar na base de dados privados alguns trechos de documentos relevantes relacionados a pergunta, e injetar trechos desses documentos na solicitação que é enviada ao GPT-4.
Isso permite que o GPT-4 processe a solicitação com um contexto enriquecido, oferecendo respostas que são não apenas baseadas em seu treinamento original, mas também em informações atualizadas e específicas, tornando-o mais eficaz e versátil.
Embora seja uma abordagem comumente utilizada para sistemas baseados em LLMs, o RAG tem algumas limitações. Vamos abordar algumas destas neste texto de blog.
RAG em poucas palavras
O objetivo principal do RAG é enriquecer a capacidade de resposta de um modelo linguístico, ao fornecer-lhe informações adicionais que não estavam disponíveis durante seu processo de treinamento. Isso é especialmente útil em situações em que os modelos precisam de informações atualizadas ou específicas de um domínio que não estava incluído em seus dados de treinamento originais.
Para se implementar um mecanismo de RAG, é necessário criar de base de dados composta por documentos relevantes, porém desconhecidos ao modelo. Exemplos desses documentos incluem: planilhas com dados financeiros de uma empresa, requisitos de sistema de um cliente, ou até mesmo uma base de código.
Ao utilizar os dados desta base de dados, o modelo pode oferecer respostas mais precisas, detalhadas e contextualmente relevantes, aumentando significativamente sua utilidade e precisão.
Na prática, quando um usuário faz uma pergunta, o RAG busca na base de dados os documentos mais pertinentes à solicitação. Em seguida, extrai alguns trechos relevantes desses documentos (ou melhor, chunks de documentos) e os integra à solicitação inicial.
Isso permite que o modelo processe a solicitação com um contexto enriquecido, oferecendo respostas que são não apenas baseadas em seu treinamento original, mas também em informações atualizadas e específicas.
Para saber mais sobre RAG, leia esse outro texto.
Desvantagens do RAG
Embora os benefícios do uso do RAG sejam claros, como a utilização de dados novos e do enriquecimento da consulta ao LLM, essa abordagem conta com algumas limitações.
Perda de informação
O método RAG é implementado em uma cadeia de etapas:
Fragmentação do texto e geração de embeddings para os fragmentos
Recuperação dos fragmentos por busca de similaridade
Geração de resposta com base no texto dos top_k fragmentos
Todas as etapas do processo são passíveis de perda de informação. Logo, não há garantia de que todas as informações serão preservadas no resultado fornecido ao usuário.
Em particular, o processo de fragmentação e de criação de embeddings são passíveis de perda por causa do tamanho do fragmento e da capacidade e qualidade dos modelos de embedding.
Por sua vez, o processo de recuperação é limitado aos top_k resultados e à função de similaridade utilizada.
Por fim, o processo de geração de resposta é imperfeito devido ao limite de tokens do conteúdo e da qualidade dos LLMs.
Necessária curadoria dos dados
A qualidade das respostas de um LLM está diretamente relacionado a qualidade do prompt fornecido.
Por exemplo, quando o modelo é sobrecarregado com dados desnecessários, há uma maior probabilidade de que as respostas geradas sejam menos precisas, menos relevantes ou até mesmo desviem do tópico original da consulta.
Isso ocorre pois o modelo pode se confundir com a presença de dados que não têm relação com a solicitação feita pelo usuário, prejudicando assim a eficiência do processo de geração de resposta.
Logo, é contraproducente fornecer conteúdo irrelevante ao LLM, uma vez que isto tende a exigir que o modelo filtre informações desnecessárias. Essa filtragem de informações irrelevantes impõe ao modelo um esforço adicional que não contribui para a melhoria da qualidade das respostas geradas.
Além disso, o processamento de informações irrelevantes pode aumentar a latência e os custos operacionais.
Busca por similaridade não são bala de prata
A busca por similaridade semântica não é um processo mágico, assim como muitas outras tecnologias de aprendizado de máquina.
Primeiro, é importante notar que o modelo de embeddings e o modelo generativo são diferentes.
Modelo de embeddings: Os modelos de embeddings foram projetados para prever segmentos mascarados no texto de entrada. Dessa forma, eles aprendem a intenção do texto fornecido como entrada. Esse tipo de LLM é conhecido como autoencoder.
Modelo generativos: Já os LLMs generativos foram projetados para prever o próximo token com base na sequência de entrada anterior. Esses modelos são chamados de autoregressores. Exemplos de autoregressores incluem ChatGPT, Google Palm e Llama.
Esses vetores de embeddings captam informações do texto de entrada, e a similaridade entre vetores pode ser usada para comparar a proximidade entre textos.
No entanto, não sabemos quais informações foram extraídas nem como essas informações estão organizadas nos vetores, muito menos como tornar esse processo mais eficiente ou desenvolver uma função de similaridade mais precisa.
Como consequência, as buscas por similaridade semântica podem falhar ocasionalmente.
Chunks quebram o contexto
Após o processo de fragmentação (ou criação de chunks), as relações entre os fragmentos dos documentos são quebradas. Na fase de recuperação, apenas os principais fragmentos selecionados (top-k) são enviados ao LLM. Isso significa que apenas uma parte dos documentos e suas relações são encaminhadas ao LLM.
Em particular, textos em linguagem natural frequentemente utilizam ligações linguísticas para conectar os tópicos. Por exemplo, uma história pode começar com "no início", continuar com "então", "portanto", "depois disso", até terminar com "eventualmente", "finalmente", etc. Com a estratégia de fragmentação, as conexões do texto são perdidas, embaralhando a sequência lógica da ordem sequencial do texto.
Como consequência, aplicações baseadas em RAG tem desempenho comprometido em tarefas que envolvam entender relacionamento entre dois pontos (por exemplo, sumarizar os livros mais populares de um determinado autor). Isso acontece pois apenas alguns poucos fragmentos dos documentos podem ser buscados e enviados ao LLM; e esses fragmentos estão dispersos nos dados.
Além disso, se desenvolvedores codificarem um trecho longo com vários tópicos em um único vetor de embeddings, nuances importantes podem se perder. Em um estudo realizado pela Microsoft, foi observado que o uso de grandes chunks reduz o desempenho do processo de recuperação.
Escolha embeddings especializados
A escolha do modelo para a criação dos embeddings é um aspecto importante. Os embeddings são representações numéricas de alta dimensão dos dados, e o modelo escolhido deve ser capaz de capturar a essência dos dados de forma eficaz.
Existem vários modelos disponíveis, cada um com suas próprias forças e fraquezas, e a escolha dependerá do tipo de dados específico do sistema. Por exemplo, você deseje fazer buscas de código, talvez seja interessante utilizar um modelo de embeddings treinado com bases de código.
A decisão sobre qual modelo de embeddings influencia diretamente a qualidade e a eficácia das buscas realizadas pelo sistema RAG.
Aumento do custo
A utilização do RAG acarreta um aumento na quantidade de dados (ou tokens) que precisam ser enviados ao modelo. Isso é uma consequência direta da natureza do RAG, que busca enriquecer as respostas do modelo com dados relevantes recuperados de uma base de dados externa, o que naturalmente leva a um aumento no volume de dados processados.
Esse aumento no volume de dados tem implicações na gestão de recursos. Em particular, se você estiver utilizando um serviço de terceiros que cobra com base no número de tokens, isso pode resultar em um aumento nos custos.
Ao implementar o RAG, é importante considerar o equilíbrio entre a melhoria na qualidade das respostas geradas e o impacto nos custos operacionais.
Conclusão
Em conclusão, o RAG apresenta uma abordagem inovadora para enriquecer as respostas de modelos linguísticos, como o GPT-4, com informações adicionais e específicas que não estavam disponíveis durante o treinamento do modelo.
Por meio da curadoria de bases de dados e da integração de trechos relevantes em solicitações ao LLM, o RAG potencializa a capacidade de resposta do modelo, proporcionando respostas mais precisas e detalhadas.
No entanto, é importante estar ciente das limitações inerentes ao RAG, como a perda de informação no processo de fragmentação, os desafios na busca por similaridade semântica, e o potencial aumento dos custos operacionais devido à maior quantidade de dados processados.
Esses fatores sublinham a necessidade de uma seleção cuidadosa de modelos de embeddings e uma gestão eficiente dos recursos, garantindo assim que o RAG seja utilizado de maneira otimizada, ao mesmo tempo em que maximiza os benefícios que oferece.