Ir para o conteúdo principal

Geração aumentada de recuperação

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

A geração aumentada de recuperação (RAG) é uma abordagem de arquitetura que pode melhorar a eficácia das aplicações de grandes modelo de linguagem (LLM) usando dados personalizados. Isso é feito recuperando dados/documentos relevantes para uma pergunta ou tarefa e fornecendo-os como contexto para o LLM. A RAG está tendo sucesso no suporte a chatbots e sistemas de perguntas e respostas que precisam manter informações atualizadas ou acessar conhecimento específico do domínio.

Continue explorando

Big-Book-of-MLOps

e-book: The Big Book of MLOps

Leitura obrigatória para engenheiros de ML e data scientists que desejam otimizar sua prática de MLOps

Obter o e-Book
A compact guide to large language models thumbnail

Aproveite o potencial dos LLMs

Como aumentar a eficiência e reduzir os custos com IA.

Baixar
Gen AI

Revolucione seu setor com IA generativa

Aprenda a otimizar LLMs com RAG e muito mais.

Assista agora

Quais desafios a abordagem de geração aumentada de recuperação resolve?

Problema 1: os modelos de LLM não conhecem seus dados

Os LLMs usam modelos de aprendizagem profunda e treinam em datasets enormes para entender, resumir e gerar conteúdo novo. A maioria dos LLMs é treinada em uma ampla gama de dados públicos, de modo que um modelo pode responder a muitos tipos de tarefas ou perguntas. Depois de treinados, muitos LLMs não têm a capacidade de acessar dados além do ponto de corte dos dados de treinamento. Isso torna os LLMs estáticos e pode fazer com que eles respondam incorretamente, forneçam respostas desatualizadas ou tenham alucinações quando recebem perguntas sobre dados com os quais não foram treinados.

Problema 2: os aplicativos de IA devem aproveitar dados personalizados para serem eficazes

Para que os LLMs forneçam respostas relevantes e específicas, as organizações precisam do modelo para entender seu domínio e fornecer respostas a partir de seus dados, em vez de dar respostas amplas e generalizadas. Por exemplo, as organizações criam bots de suporte ao cliente com LLMs, e essas soluções devem fornecer respostas específicas à empresa para as perguntas do cliente. Outras estão criando bots internos de perguntas e respostas que devem responder às perguntas dos colaboradores sobre dados internos de RH. Como as empresas constroem essas soluções sem retreinar esses modelos?

Solução: o aumento de recuperação virou o padrão do setor

Uma maneira fácil e popular de usar seus próprios dados é fornecê-los como parte do prompt com o qual você consulta o modelo de LLM. Isso é chamado de geração aumentada de recuperação (RAG), pois você recupera os dados relevantes e os utiliza como contexto aumentado para o LLM. Em vez de confiar exclusivamente no conhecimento derivado dos dados de treinamento, um fluxo de trabalho RAG obtém informações relevantes e conecta LLMs estáticos com a recuperação de dados em tempo real.

Com a arquitetura RAG, as organizações podem implantar qualquer modelo de LLM e aumentá-lo para retornar resultados relevantes, fornecendo uma pequena quantidade dos dados sem os custos e o tempo de ajuste ou pré-treinamento do modelo.

Quais são os casos de uso da RAG?

Existem muitos casos de uso diferentes para a RAG. Os mais comuns são:

  1. Chat de perguntas e respostas: a incorporação de LLMs com chatbots permite que eles obtenham automaticamente respostas mais precisas de documentos da empresa e bases de conhecimento. Os chatbots são usados para automatizar o suporte ao cliente e o acompanhamento do lead do site para responder a perguntas e resolver problemas rapidamente.
  2. Aumento de pesquisa: a incorporação de LLMs com mecanismos de pesquisa que aumentam os resultados de pesquisa com respostas geradas por LLM pode responder melhor a queries informativas e tornar mais fácil para os usuários encontrarem as informações de que precisam para fazer seu trabalho.
  3. Mecanismo de conhecimento — faça perguntas sobre seus dados (por exemplo, RH, documentos de compliance): os dados da empresa podem ser usados como contexto para LLMs e permitir que os funcionários obtenham facilmente respostas às suas perguntas, incluindo perguntas de RH relacionadas a benefícios e políticas e questões de segurança e compliance.

Quais são os benefícios da RAG?

A abordagem RAG tem vários benefícios importantes, incluindo:

  1. Fornecer respostas atualizadas e precisas: a RAG garante que a resposta de um LLM não se baseie exclusivamente em dados de treinamento estáticos e obsoletos. Em vez disso, o modelo usa fontes de dados externas atualizadas para fornecer respostas.
  2. Reduzir respostas imprecisas ou alucinações: ao analisar o resultado do modelo de LLM sobre conhecimento externo relevante, a RAG tenta mitigar o risco de resposta com informações incorretas ou fabricadas (também conhecidas como alucinações). Os resultados podem incluir citações de fontes originais, permitindo a verificação humana.
  3. Fornecer respostas relevantes e específicas do domínio: ao usar a RAG, o LLM poderá fornecer respostas contextualmente relevantes adaptadas aos dados proprietários ou específicos do domínio de uma organização.
  4. Ser eficiente e econômica: em comparação com outras abordagens para personalizar LLMs com dados específicos de domínio, a RAG é simples e econômica. As organizações podem implantar a RAG sem precisar personalizar o modelo. Isso é especialmente útil quando os modelos precisam ser atualizados com novos dados com frequência.

Quando devo usar a RAG e quando devo ajustar o modelo?

A RAG é o lugar certo para começar, sendo fácil e até suficiente para alguns casos de uso. O ajuste fino é mais apropriado em uma situação diferente, quando se deseja que o comportamento do LLM mude ou que ele aprenda uma "linguagem" diferente. Eles não são mutuamente exclusivos. Como próximo passo, é possível considerar o ajuste fino de um modelo para entender melhor a linguagem do domínio e a forma de saída desejada, além de usar a RAG para melhorar a qualidade e a relevância da resposta.

Quando eu quiser personalizar meu LLM com dados, quais são as opções e qual método é o melhor (engenharia de prompt, RAG, ajuste fino ou pré-treino)?

Existem quatro padrões de arquitetura a considerar ao personalizar uma aplicação de LLM com os dados da sua organização. Essas técnicas são descritas abaixo e não são mutuamente exclusivas. Em vez disso, elas podem (e devem) ser combinadas para aproveitar os pontos fortes de cada uma.

MétodoDefiniçãoCaso de uso principalRequisitos de dadosVantagensConsiderações

Engenharia de prompt

Engenharia de prompt

Elaboração de prompts especializados para orientar o comportamento do LLMOrientação rápida e instantânea do modeloNenhumaRápida, econômica, sem necessidade de treinamentoMenos controle do que o ajuste fino

Geração aumentada de recuperação (RAG)

Geração aumentada de recuperação (RAG)

Combinar um LLM com recuperação de conhecimento externo Datasets dinâmicos e conhecimento externoBase de conhecimento externa ou base de dados (por exemplo, base de dados vetorial) Contexto atualizado dinamicamente, maior precisãoAumenta o comprimento do prompt e o cálculo da inferência

Ajuste fino

Ajuste fino

Adaptar um LLM pré-treinado a datasets ou domínios específicosEspecialização de domínio ou tarefaMilhares de exemplos específicos de domínio ou instruçõesControle granular, alta especializaçãoExige dados rotulados, custo computacional

Pré-treinamento

Pré-treinamento

Treinar um LLM do zeroTarefas exclusivas ou corpora específicos do domínioGrandes datasets (bilhões a trilhões de tokens)Controle máximo, personalizado para necessidades específicasExtremamente intensivo em recursos

Independentemente da técnica selecionada, a criação de uma solução de maneira bem estruturada e modularizada garante que as organizações estejam preparadas para iterar e se adaptar. Saiba mais sobre essa abordagem e muito mais em The Big Book of MLOps.

Geração aumentada de recuperação

O que é uma arquitetura de referência para aplicativos RAG?

Há muitas maneiras de implementar um sistema de geração aumentada de recuperação, dependendo de necessidades específicas e nuances dos dados. Confira abaixo um fluxo de trabalho comumente adotado para oferecer uma compreensão básica do processo.

Arquitetura de referência para aplicações RAG

  1. Preparar dados: os dados do documento são reunidos juntamente com os metadados e submetidos ao pré-processamento inicial — por exemplo, gestão de PII (detecção, filtragem, supressão, substituição). Para ser usado em aplicativos RAG, os documentos precisam ser agrupados em comprimentos apropriados com base na escolha do modelo de incorporação e da aplicação de LLM downstream que usa esses documentos como contexto.
  2. Indexar dados relevantes: produza incorporações de documentos e hidrate um índice de Vector Search com esses dados.
  3. Recuperar dados relevantes: recuperar partes dos seus dados relevantes para a query de um usuário. Esses dados de texto são fornecidos como parte do prompt usado para o LLM.
  4. Criar aplicações de LLM: envolva os componentes de aumento de prompt e consulte o LLM em um endpoint. Esse endpoint pode ser exposto a aplicativos como chatbots de perguntas e respostas por meio de uma API REST simples.

A Databricks também recomenda alguns elementos importantes de uma arquitetura RAG:

  • Base de dados vetorial: algumas (mas não todas) aplicações de LLM usam bases de dados vetoriais para pesquisas rápidas de similaridade, mais frequentemente para fornecer contexto ou conhecimento de domínio em queries de LLM. Para garantir que o modelo de idioma implantado tenha acesso a informações atualizadas, as atualizações regulares da base de dados vetorial podem ser agendadas como um job. Observe que a lógica para recuperar da base de dados vetorial e injetar informações no contexto de LLM pode ser empacotada no artefato do modelo registrado no MLflow usando as variantes de modelo LangChain ou PyFunc.
  • Implantações de LLM do MLflow ou Model Serving: em aplicativos baseados em LLM em que uma API LLM de terceiros é usada, as implantações de LLM do MLflow ou o suporte ao Model Serving para modelos externos podem ser usados como uma interface padronizada para encaminhar solicitações de fornecedores como OpenAI e Anthropic. Além de fornecer um API gateway de nível empresarial, o MLflow LLM Deployments ou Model Serving centraliza a gestão de chaves API e oferece a capacidade de aplicar controles de custo.
  • Model Serving: no caso da RAG que usa uma API de terceiros, uma mudança de arquitetura importante é que o pipeline de LLM fará chamadas de API externas, do endpoint do Model Serving para APIs de LLM internas ou de terceiros. Deve-se observar que isso adiciona complexidade, latência potencial e outra camada de gerenciamento de credenciais. Por outro lado, no exemplo do modelo com ajuste fino, o modelo e seu ambiente de modelo serão implantados.

Recursos

Clientes da Databricks que usam RAG

JetBlue

A JetBlue implementou o "BlueBot", um chatbot que usa modelos de IA generativa de código aberto complementados por dados corporativos, com tecnologia da Databricks. Esse chatbot pode ser usado por todas as equipes da JetBlue para obter acesso a dados que são governados por função. Por exemplo, a equipe de finanças pode ver os dados da SAP e os registros regulatórios, mas a equipe de operações só verá as informações de manutenção.

Leia também este artigo.

Chevron Phillips

A Chevron Phillips Chemical usa a Databricks para apoiar suas iniciativas de IA generativa, incluindo a automação de processos de documentos.

Thrivent Financial

A Thrivent Financial está usando a IA generativa para melhorar as pesquisas, produzir insights mais resumidos e acessíveis e aumentar a produtividade da engenharia.

Onde posso encontrar mais informações sobre geração aumentada de recuperação?

Há muitos recursos disponíveis com mais informações sobre a RAG, incluindo:

Blogs

eBooks

Demos

Entre em contato com a Databricks para agendar uma demonstração e conversar com alguém sobre seus projetos de LLM e geração aumentada de recuperação (RAG)

    Voltar ao glossário