O que é geração aumentada por recuperação (RAG)?

O RAG fornece dados contextuais e atualizados para tornar os LLMs úteis.

A geração aumentada por recuperação é uma técnica que aborda as limitações dos LLMs, fornecendo-lhes acesso a dados contextuais e atualizados. As implementações RAG, às vezes chamadas de modelos ou padrões RAG, funcionam combinando um LLM pré-treinado com um sistema de recuperação de informações prontamente acessíveis. O sistema de recuperação é responsável por encontrar informações relevantes em uma biblioteca de conhecimento, como um banco de dados. Os modelos RAG permitem que o LLM, ou modelo de fundação, gere uma resposta mais precisa com contexto atualizado e relevante para a tarefa em questão.

Os modelos RAG demonstraram ser eficazes para uma variedade de tarefas de conhecimento intensivo, incluindo:

• Tarefas de geração de linguagem, como responder a perguntas de forma abrangente e informativa ou gerar diferentes formatos criativos de conteúdo de texto, como poemas, roteiros, peças musicais, e-mails, cartas, etc.
• Tarefas de PNL, como fornecer resumos de conversas, gravações de áudio e chamadas de vídeo.
• Tarefas que exigem classificação, como segurança cibernética e conformidade, ou raciocínio para coisas como planejamento de negócios

O RAG também pode ser usado para permitir que uma aplicação alimentada por IA generativa observe algum estado de background e adapte suas gerações de acordo. Um exemplo seria a capacidade de escrever código com base no código que um usuário está escrevendo. Outros exemplos incluem:

• Contexto de aplicação. Digamos que você esteja criando um assistente de Excel com IA - seria útil se ele soubesse os nomes das suas planilhas, o nome do arquivo, os intervalos de células selecionados, etc. O RAG alimentará o prompt com essas "informações de atividade no background" para que o LLM possa adaptar a ajuda à sua planilha.
• Dados pessoais (por exemplo, agente auxiliar do chatbot). Digamos que você esteja criando um bot de suporte ao cliente. O bot pode obter o histórico de conversas anteriores e de CRM desse cliente específico para ajudar a personalizar a conversa (não apenas cumprimentar, mas personalizar as opções etc.). Sem esse histórico, o LLM não poderá realizar a personalização de forma eficaz nem ajudar com os problemas existentes.
• Números brutos, métricas, dados tabulares (por exemplo CSV, Parquet, JSON etc.). O RAG não se limita a trabalhar com contexto textual, mas também com informações quantitativas. Um chatbot de business intelligence (BI) certamente estaria fazendo RAG em dados tabulares brutos.
• Outros tipos de dados multimodais, como imagens, vídeo e áudio. Muitos modelos, como o DALL-E 2, podem aproveitar o texto para criar ou aumentar as imagens. Por outro lado, eles podem sintetizar imagens ou vídeos em linguagem natural. Por ter contexto para determinadas imagens ou fatores de forma de design, o RAG pode tornar as aplicações de IA generativa mais avançadas quando se trata de criar ativos de marketing ou gerar resumos e traduções de vídeos que contenham informações muito específicas e com muito contexto.

O RAG também é útil para dados que não podem ser incorporados como dados de treinamento

• Dados altamente voláteis/sensíveis ao tempo: dados como notícias do mercado de ações tornam-se obsoletos rapidamente. Portanto, faz mais sentido aprimorar o LLM apenas com as informações mais recentes e atualizadas, de preferência a cada solicitação durante o tempo de inferência, em vez de tentar treinar novamente os LLMs com esse corpus.
• Dados confidenciais: muitos dos LLMs de melhor desempenho (como o GPT da OpenAI ou o Claude da Anthropic) são pagos por uso e pertencem a essas empresas. O uso de informações pessoais e confidenciais em dados de treinamento para ajustar esses LLMS pode levar ao vazamento de dados privados e é potencialmente perigoso. Portanto, às vezes o RAG é a única opção segura.

Principais casos de uso do RAG.

Com base no exposto, os casos de uso mais adequados do RAG incluem:

• Resposta a perguntas sobre qualquer conhecimento de domínio extrínseco, como documentação e bases de conhecimento específicas da empresa, sistemas operacionais ativos, sistemas de back office, etc.: por definição, o uso de LLMs com quaisquer dados fora do limite de conhecimento do LLM requer RAG. Além disso, perguntas e respostas sobre contextos altamente sensíveis ao tempo e que mudam rapidamente - dados que ficam desatualizados rapidamente - são impossíveis de serem integrados aos LLMs por meio de ajustes finos.
• Para reduzir alucinações e aumentar a precisão factual: de modo geral, o RAG pode melhorar a precisão factual até mesmo para responder a perguntas sobre informações contidas no corpus de treinamento do LLM. Isso ocorre porque o RAG transforma a tarefa de resposta a perguntas em uma tarefa de "questionário de livro aberto", que é mais fácil do que uma tarefa de resposta a perguntas ilimitadas.
• A personalização é um caso de uso canônico para o RAG. Nesse caso, o prompt é aumentado com dados do usuário. Opcionalmente, todos os dados de PII podem ser limpos antes de serem inseridos no prompt.
• Fornecimento de respostas contextuais (dentro dos Co-Pilotos). Como demonstra o copiloto do Github, as gerações LLM podem ser mais relevantes quando baseadas no estado da aplicação (o documento atual, os metadados gerais do projeto, qual URL ou página está sendo visitada no momento, etc.)
• Qualquer aplicação de IA generativa que trabalhe com contextos altamente específicos de domínio. Os exemplos incluem saúde, serviços financeiros, descoberta legal, ciência e engenharia. Nesses tipos de domínios, os dados de treinamento geralmente são escassos e, portanto, o RAG é essencial para criar aplicações de IA generativa úteisl.

Por que o RAG? Quais são as alternativas ao RAG na criação de aplicações de IA generativa.

Há uma série de alternativas ao RAG para criar aplicações de IA generativa. Algumas das alternativas mais populares incluem:

• Treinar seu próprio LLM: embora possa haver justificativa para treinar seu próprio LLM, provavelmente será muito caro e demorado criar algo competitivo com os muitos modelos comerciais (OpenAI GPTs) e de código aberto (LLaMa do Meta) disponíveis.
• Ajuste fino de um LLM existente: uma técnica em que um LLM pré-treinado é treinado novamente em um conjunto de dados menor de dados específicos da tarefa. O ajuste fino pode ser eficaz para melhorar o desempenho de um LLM em uma tarefa específica, mas também pode ser demorado e caro. O ajuste fino nunca termina – à medida que novos dados são disponibilizados, o modelo precisa ser ajustado novamente. Quando seu aplicativo GenAI exige acesso a dados operacionais em tempo real, o ajuste fino não funcionará para você.

Por queo RAG em vez do ajuste fino de um LLM?

• O ajuste fino é outra maneira de usar LLMs com "dados personalizados", mas, ao contrário do RAG, que é como dar a um LLM um teste com livro aberto, o ajuste fino é como dar a ele memórias totalmente novas ou uma lobotomia. O ajuste fino adapta o modelo para que você possa alterar seu desempenho, comportamento, perfil de custo, etc. Isso exige muito tempo e recursos e, em geral, não é viável para fundamentar os LLMs em um contexto específico, além de ser especialmente inadequado para dados operacionais em tempo real de sua empresa.

Os principais blocos de construção de uma arquitetura RAG básica.

Uma arquitetura RAG básica consiste em três componentes principais:

• Um LLM pré-treinado: o LLM é responsável por gerar texto, imagens, áudio e vídeo.
• Pesquisa vetorial (ou semantic search): o sistema de recuperação é responsável por encontrar informações relevantes em uma base de conhecimento externa ao LLM. Há uma variedade de bancos de dados de uso geral ou bancos de dados vetoriais de uso único para escolher, que podem armazenar embeddings vetoriais e executar queries de pesquisa de vizinho mais próximo aproximado em relação a eles. A pesquisa vetorial é fundamental para poder aumentar com precisão o conhecimento proprietário fornecido a um LLM de uso geral.
• Embeddings vetoriais: às vezes chamados simplesmente de "vetores" ou "embeddings", os embeddings vetoriais são essencialmente representações numéricas que capturam o significado semântico ou subjacente de um dado. Em geral, eles são uma array de floats, em que cada float representa uma única dimensão das representações numéricas.
• Orquestração: o mecanismo de fusão é responsável por combinar a saída do LLM com as informações do sistema de recuperação para gerar a saída final.

O diagrama a seguir mostra uma arquitetura RAG básica com o mesmo exemplo de varejo anterior:

Como uma solução alternativa para essa falta de contexto específico do domínio, a geração aumentada por recuperação é realizada da seguinte forma:

• Buscamos as descrições de produtos mais relevantes em um banco de dados (geralmente um banco de dados com pesquisa vetorial) que contém o catálogo de produtos mais recente
• Em seguida, inserimos (aumentamos) essas descrições no prompt do LLM
• Por fim, instruímos o LLM a "referenciar" essas informações atualizadas sobre o produto ao responder à pergunta

Três coisas a serem consideradas a partir do exposto acima:

• O RAG é uma técnica puramente de tempo de inferência (sem necessidade de retreinamento). Todas as etapas 1 a 3 acima ocorrem em tempo de inferência. Não são necessárias alterações no modelo (por exemplo modificar os pesos do modelo).
• O RAG é adequado para personalizações em tempo real das gerações LLM. Como não há retreinamento envolvido e tudo é feito por meio do aprendizado no contexto, a inferência baseada em RAG é rápida (latência inferior a 100 ms) e adequada para ser usada em aplicações operacionais em tempo real.
• O RAG torna as gerações LLM mais precisas e úteis. Sempre que o contexto mudar, o LLM gerará uma resposta diferente. Assim, o RAG faz com que as gerações de LLM dependam de qualquer contexto que tenha sido recuperado.

Manter o RAG simples com complexidade mínima, mas sofisticado para ter um desempenho confiável em escala.

Para obter uma arquitetura RAG de alto desempenho, porém minimamente complexa, é necessário escolher os sistemas certos. Ao escolher os sistemas ou as tecnologias para uma implementação de RAG, é importante escolher sistemas ou um sistema que possa atingir os seguintes objetivos:

• Oferecer suporte a novos requisitos de dados vetoriais sem aumentar muito a expansão, o custo e a complexidade de suas operações de TI.
• Garantir que as experiências de IA generativa criadas tenham acesso a dados em tempo real com latência mínima.
• Ter flexibilidade para acomodar novos requisitos de dados e aplicativos e permitir que as equipes de desenvolvimento permaneçam ágeis ao fazer isso.
• Equipar melhor as equipes de desenvolvimento para trazer todo o ecossistema de IA para seus dados, e não o contrário.

As opções variam de bancos de dados vetoriais de finalidade única a documentos e relational database com recursos vetoriais nativos, além de data warehouses e lakehouses. No entanto, os bancos de dados vetoriais de finalidade única aumentarão imediatamente a expansão e a complexidade. Os data warehouses e lakehouses são inerentemente projetados para consultas do tipo analítico de longa duração em dados históricos, em oposição aos requisitos de alto volume, baixa latência e dados novos do aplicativo GenAI que o RAG alimenta. Além disso, os relational databases trazem esquemas rígidos que limitam a flexibilidade de adicionar novos dados e requisitos de aplicativos com facilidade. Isso deixa os bancos de dados de documentos com recursos vetoriais nativos ou incorporados. Em particular, o MongoDB foi desenvolvido com base no modelo de documento flexível e tem pesquisa vetorial nativa, o que o torna um banco de dados vetorial para o RAG, além de ser o banco de dados líder do setor para qualquer aplicação moderno.

Levando o poder dos LLMs para o próximo nível com recursos adicionais em sua implementação de RAG.

Além dos componentes principais, há uma série de recursos adicionais que podem ser adicionados a uma implementação do RAG para elevar o poder dos LLMs a um novo patamar. Alguns desses recursos adicionais incluem:

• Multimodalidade: os modelos RAG multimodais podem gerar texto com base em dados textuais e não textuais, como imagens, vídeos e áudio. O fato de ter esses dados multimodais armazenados lado a lado com os dados operacionais em tempo real torna a implementação do RAG mais fácil de projetar e gerenciar.
• Definição de filtros adicionais na consulta de pesquisa vetorial: a capacidade de adicionar pesquisa por palavra-chave, pesquisa geoespacial e filtros de ponto e intervalo na mesma consulta vetorial pode aumentar a precisão e a velocidade do contexto fornecido ao LLM.
• Especificidade de domínio: os modelos RAG específicos do domínio podem ser treinados em dados de um domínio específico, como saúde ou finanças. Isso permite que o modelo RAG gere um texto mais preciso e relevante para esse domínio.

Garantir que sua aplicação alimentada por IA generativa seja segura, eficiente, confiável e escalável quando se tornar global.

Há várias coisas que podem ser feitas para garantir que uma aplicação com tecnologia GenAI criada com um RAG seja segura, eficiente, confiável e escalável quando se tornar global. Algumas dessas coisas incluem:

• Usar uma plataforma que seja segura e tenha os recursos adequados de governança de dados: governança de dados é um termo amplo que engloba tudo o que você faz para garantir que os dados sejam seguros, privados, precisos, disponíveis e utilizáveis. Inclui os processos, as políticas, as medidas, a tecnologia, as ferramentas e os controles do ciclo de vida dos dados. Portanto, a plataforma deve ser segura por padrão, ter criptografia de ponta a ponta e ter alcançado conformidade nos níveis mais altos.
• Use uma plataforma baseada em cloud: além dos recursos de segurança e escalabilidade que as plataformas baseadas em cloud oferecem, os principais provedores de cloud são alguns dos principais inovadores da infraestrutura de IA. A escolha de uma plataforma que seja agnóstica em relação à cloud permite que as equipes aproveitem as inovações de IA onde quer que elas estejam.
• Use uma plataforma que possa isolar a infraestrutura de carga de trabalho vetorial de outra infraestrutura de banco de dados: é importante que as cargas de trabalho OLTP regulares e as cargas de trabalho vetoriais não compartilhem a infraestrutura, para que as duas cargas de trabalho possam ser executadas em hardware otimizado para cada uma delas e para que não concorram por recursos e, ao mesmo tempo, possam aproveitar os mesmos dados.
• Use uma plataforma que tenha sido comprovada em escala: uma coisa é um provedor dizer que pode escalonar, mas será que ele tem um histórico e um histórico com clientes corporativos globais? Ele tem tolerância a falhas de missão crítica e capacidade de escalonar horizontalmente, e pode comprovar isso com exemplos de clientes?

Seguindo essas dicas, é possível criar aplicações com a tecnologia GenAI com arquiteturas RAG que sejam seguras, eficientes, confiáveis e escalonáveis.

Com a introdução do Atlas Vector Search, A plataforma líder de dados para desenvolvedores do MongoDB fornece às equipes um banco de dados vetorial que permite a criação de arquiteturas RAG sofisticadas e de alto desempenho que podem funcionar em escala. Tudo isso mantendo os mais altos níveis de segurança e agnosticismo na cloud e, o mais importante, sem adicionar complexidade e custos desnecessários.