Geração aumentada de recuperação

Como o RAG funciona

RAG melhora a saída de um modelo de linguagem, injetando nele informações contextuais e em tempo real obtidas de uma fonte de dados externa. Quando um usuário submete uma consulta, o sistema primeiramente aciona o modelo de recuperação, que utiliza uma base de dados vetorizada para identificar e "recuperar" documentos semanticamente similares, bancos de dados ou outras fontes de informações relevantes. Uma vez identificados, ele combina esses resultados com o prompt de entrada original e os envia para um modelo de IA gerativo, que sintetiza as novas informações em seu próprio modelo.

Isso permite que o LLM produza respostas mais precisas e conscientes do contexto, baseadas em dados específicos da empresa ou atualizados, em vez de simplesmente confiar no modelo no qual foi treinado.

Os pipelines RAG geralmente envolvem quatro etapas: preparação e divisão do documento, indexação de vetores, recuperação e aumento de prompt. Este fluxo de processo ajuda desenvolvedores a atualizar fontes de dados sem precisar treinar novamente o modelo e torna o RAG uma solução escalável e custo-efetiva para construir aplicações de LLM em domínios como suporte ao cliente, bases de conhecimento e busca interna.

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.

   Por exemplo, a Experian, uma empresa multinacional de corretagem de dados e relatórios de crédito ao consumidor, queria construir um chatbot para atender às necessidades internas e voltadas para o cliente. Eles perceberam rapidamente que suas atuais tecnologias de chatbot tinham dificuldades para se expandir para atender à demanda. Ao criar seu chatbot GenAI — Latte — na Plataforma de Inteligência de Dados Databricks, a Experian conseguiu melhorar o manuseio de prompts e a precisão do modelo, o que deu às suas equipes maior flexibilidade para experimentar com diferentes prompts, refinar as saídas e se adaptar rapidamente às evoluções na tecnologia GenAI.

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.

   Uma maneira pela qual isso está sendo implantado é na Cycle & Carriage, um importante grupo automobilístico do Sudeste Asiático. Eles recorreram ao Databricks Mosaic AI para desenvolver um chatbot RAG que melhora a produtividade e o engajamento do cliente, acessando suas bases de conhecimento proprietárias, como manuais técnicos, transcrições de suporte ao cliente e documentos de processos de negócios. Isso facilitou para os funcionários a busca por informações por meio de consultas em linguagem natural que fornecem respostas contextuais e em tempo real.

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.

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.

Desafios comuns na implementação do RAG

Implementar o RAG em larga escala introduz vários desafios técnicos e operacionais.

1. Qualidade de recuperação. Mesmo os LLMs mais poderosos podem gerar respostas ruins se recuperarem documentos irrelevantes ou de baixa qualidade. Portanto, é crucial desenvolver um pipeline de recuperação eficaz que inclua uma seleção cuidadosa de modelos de incorporação, métricas de similaridade e estratégias de classificação.
2. Limitações da janela de contexto. Com a totalidade da documentação mundial ao seu alcance, os riscos podem ser a injeção de conteúdo excessivo no modelo, levando a fontes truncadas ou respostas diluídas. Estratégias de "chunking" devem equilibrar a coerência semântica com a eficiência de tokens.
3. Atualização dos dados O benefício do RAG é sua capacidade de reunir informações atualizadas. No entanto, índices de documentos podem se tornar rapidamente obsoletos sem trabalhos de ingestão agendados ou atualizações automatizadas. Ao garantir que seus dados estão atualizados, você pode evitar alucinações ou respostas desatualizadas.
4. Latência. Ao lidar com grandes conjuntos de dados ou APIs externas, a latência pode interferir na recuperação, classificação e geração.
5. Avaliação RAG. Devido à natureza híbrida do RAG, os modelos tradicionais de avaliação de IA ficam aquém. Avaliar a precisão das saídas requer uma combinação de julgamento humano, pontuação de relevância e verificações de fundamentação para avaliar a qualidade da resposta.
    

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.

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

• Publicações no blog da Databricks
  • Usar MLflow AI Gateway e Llama 2 para construir aplicativos de IA generativa
  • Práticas recomendadas para avaliação de LLM de aplicativos RAG
• Demonstração da Databricks
• eBook da Databricks — The Big Book of MLOps

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

• Criando aplicativos RAG de alta qualidade com a Databricks
• Pré-lançamento público do Vector Search da Databricks
• Melhore a qualidade de resposta do aplicativo RAG com dados estruturados em tempo real
• Crie aplicativos de IA generativa mais rapidamente com novos recursos de modelo básico
• Práticas recomendadas para avaliação de LLM de aplicativos RAG
• Usar o gateway de IA do MLflow e o Llama 2 para construir aplicativos de IA generativa (obter maior precisão usando geração aumentada de recuperação (RAG) com seus próprios dados)

eBooks

• The Big Book of GenAI
• O guia compacto para a RAG
• e-book: The Big Book of MLOps

Demos

• Implemente seu chatbot de LLM com a geração aumentada de recuperação (RAG), Llama2-70B (Inferências de MosaicML) e Vector Search

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)

Futuro da tecnologia RAG

RAG está evoluindo rapidamente de uma solução improvisada para um componente fundamental da arquitetura de IA empresarial. À medida que os LLMs se tornam mais capazes, o papel do RAG está mudando. Está passando de simplesmente preencher lacunas no conhecimento para sistemas que são estruturados, modulares e mais inteligentes.

Uma das formas que o RAG está se desenvolvendo é através de arquiteturas híbridas, onde o RAG é combinado com ferramentas, bancos de dados estruturados e agentes de chamada de função. Nesses sistemas, o RAG fornece fundamentação não estruturada enquanto dados estruturados ou APIs lidam com tarefas mais precisas. Essas arquiteturas multimodais oferecem às organizações uma automação de ponta a ponta mais confiável.

Outro grande desenvolvimento é o co-treinamento de retriever e gerador. Este é um modelo em que o recuperador RAG e o gerador são treinados conjuntamente para otimizar a qualidade da resposta um do outro. Isso pode reduzir a necessidade de engenharia de prompt manual ou ajustes finos e leva a coisas como aprendizado adaptativo, redução de alucinações e melhor desempenho geral de recuperadores e geradores.

À medida que as arquiteturas LLM amadurecem, é provável que o RAG se torne mais perfeito e contextual. Ultrapassando os armazenamentos finitos de memória e informação, esses novos sistemas serão capazes de lidar com fluxos de dados em tempo real, raciocínio multi-documento e memória persistente, tornando-os assistentes conhecedores e confiáveis.

Perguntas frequentes (FAQ)

O que é a geração aumentada de recuperação (RAG)? RAG é uma arquitetura de IA que fortalece os LLMs ao recuperar documentos relevantes e inseri-los no prompt. Isso permite respostas mais precisas, atuais e específicas do domínio sem levar tempo para re-treinar o modelo.

Quando devo usar RAG em vez de ajuste fino?
Use o RAG quando você deseja incorporar dados dinâmicos sem o custo ou a complexidade do ajuste fino. É ideal para casos de uso onde informações precisas e oportunas são necessárias.

O RAG reduz alucinações em LLMs?
Sim. Ao fundamentar a resposta do modelo em conteúdo recuperado e atualizado, o RAG reduz a probabilidade de alucinações. Isso é especialmente verdadeiro em domínios que exigem alta precisão, como saúde, trabalho jurídico ou suporte empresarial.

Que tipo de dados o RAG precisa?
O RAG usa dados de texto não estruturado - pense em fontes como PDFs, emails e documentos internos - armazenados em um formato recuperável. Esses geralmente são armazenados em um banco de dados vetorial, e os dados devem ser indexados e atualizados regularmente para manter a relevância.

Como você avalia um sistema RAG?
Sistemas RAG são avaliados usando uma combinação de pontuação de relevância, verificações de fundamentação, avaliações humanas e métricas de desempenho específicas da tarefa. Mas, como vimos, as possibilidades de co-treinamento retriever-generator podem facilitar a avaliação regular à medida que os modelos aprendem e treinam um ao outro.