RAG (Retrieval Augmented Generation) no Azure Databricks

Importante

Esta funcionalidade está em Pré-visualização Pública.

O Agent Framework compreende um conjunto de ferramentas no Databricks projetadas para ajudar os desenvolvedores a criar, implantar e avaliar agentes de IA com qualidade de produção, como aplicativos de Geração Aumentada de Recuperação (RAG).

Este artigo aborda o que é RAG e os benefícios do desenvolvimento de aplicativos RAG no Azure Databricks.

O Agent Framework permite que os desenvolvedores iterem rapidamente em todos os aspetos do desenvolvimento do RAG usando um fluxo de trabalho LLMOps de ponta a ponta.

Requisitos

• Os recursos de assistência de IA alimentados por IA do Azure devem ser habilitados para seu espaço de trabalho.
• Todos os componentes de um aplicativo agentic devem estar em um único espaço de trabalho. Por exemplo, no caso de um aplicativo RAG, o modelo de serviço e a instância de pesquisa vetorial precisam estar no mesmo espaço de trabalho.

O que é RAG?

RAG é uma técnica de design de IA generativa que aprimora grandes modelos de linguagem (LLM) com conhecimento externo. Esta técnica melhora os LLMs das seguintes maneiras:

• Conhecimento proprietário: o RAG pode incluir informações proprietárias não usadas inicialmente para treinar o LLM, como memorandos, e-mails e documentos para responder a perguntas específicas do domínio.
• Informações atualizadas: Um aplicativo RAG pode fornecer ao LLM informações de fontes de dados atualizadas.
• Citando fontes: o RAG permite que LLMs citem fontes específicas, permitindo que os usuários verifiquem a precisão factual das respostas.
• Segurança de dados e listas de controle de acesso (ACL): A etapa de recuperação pode ser projetada para recuperar seletivamente informações pessoais ou proprietárias com base nas credenciais do usuário.

Sistemas compostos de IA

Uma aplicação RAG é um exemplo de um sistema de IA composto: expande as capacidades linguísticas do LLM combinando-o com outras ferramentas e procedimentos.

Na forma mais simples, um aplicativo RAG faz o seguinte:

1. Recuperação: a solicitação do usuário é usada para consultar um armazenamento de dados externo, como um repositório vetorial, uma pesquisa de palavra-chave de texto ou um banco de dados SQL. O objetivo é obter dados de suporte para a resposta do LLM.
2. Aumento: Os dados recuperados são combinados com a solicitação do usuário, geralmente usando um modelo com formatação e instruções adicionais, para criar um prompt.
3. Geração: O prompt é passado para o LLM, que gera uma resposta à consulta.

Dados RAG não estruturados vs. estruturados

A arquitetura RAG pode trabalhar com dados de suporte não estruturados ou estruturados. Os dados que você usa com a RAG dependem do seu caso de uso.

Dados não estruturados: dados sem uma estrutura ou organização específica. Documentos que incluem texto e imagens ou conteúdo multimédia, como áudio ou vídeos.

• PDFs
• Documentos do Google/Office
• Wikis
• Imagens
• Vídeos

Dados estruturados: dados tabulares organizados em linhas e colunas com um esquema específico, como tabelas em um banco de dados.

• Registos de clientes num sistema de BI ou Data Warehouse
• Dados de transação de um banco de dados SQL
• Dados de APIs de aplicativos (por exemplo, SAP, Salesforce, etc.)

As seções a seguir descrevem um aplicativo RAG para dados não estruturados.

Pipeline de dados RAG

O pipeline de dados RAG pré-processa e indexa documentos para recuperação rápida e precisa.

O diagrama abaixo mostra um pipeline de dados de exemplo para um conjunto de dados não estruturado usando um algoritmo de pesquisa semântica. O Databricks Jobs orquestra cada etapa.

1. Ingestão de dados - Ingerir dados de sua fonte proprietária. Armazene esses dados em uma tabela Delta ou em um Volume de Catálogo Unity.
2. Processamento de documentos: você pode executar essas tarefas usando Databricks Jobs, Databricks Notebooks e Delta Live Tables.
   • Analisar documentos brutos: transforme os dados brutos em um formato utilizável. Por exemplo, extrair o texto, tabelas e imagens de uma coleção de PDFs ou usar técnicas de reconhecimento ótico de caracteres para extrair texto de imagens.
   • Extrair metadados: extraia metadados de documentos, como títulos de documentos, números de página e URLs, para ajudar a consulta da etapa de recuperação com mais precisão.
   • Fragmentar documentos: divida os dados em partes que se ajustam à janela de contexto LLM. A recuperação dessas partes focadas, em vez de documentos inteiros, dá ao LLM um conteúdo mais direcionado para gerar respostas.
3. Incorporação de blocos - Um modelo de incorporação consome os blocos para criar representações numéricas das informações chamadas incorporações vetoriais. Os vetores representam o significado semântico do texto, não apenas palavras-chave de nível de superfície. Nesse cenário, você calcula as incorporações e usa o Model Serving para servir o modelo de incorporação.
4. Armazenamento de incorporação - Armazene as incorporações vetoriais e o texto do bloco em uma tabela Delta sincronizada com a Pesquisa Vetorial.
5. Banco de dados vetorial - Como parte da Pesquisa Vetorial, incorporações e metadados são indexados e armazenados em um banco de dados vetorial para facilitar a consulta pelo agente RAG. Quando um usuário faz uma consulta, sua solicitação é incorporada em um vetor. Em seguida, o banco de dados usa o índice vetorial para localizar e retornar os blocos mais semelhantes.

Cada etapa envolve decisões de engenharia que afetam a qualidade da aplicação RAG. Por exemplo, escolher o tamanho de bloco certo na etapa (3) garante que o LLM receba informações específicas, mas contextualizadas, enquanto selecionar um modelo de incorporação apropriado na etapa (4) determina a precisão das partes retornadas durante a recuperação.

Pesquisa vetorial Databricks

A semelhança computacional é muitas vezes computacionalmente cara, mas índices vetoriais como o Databricks Vetor Search otimizam isso organizando incorporações de forma eficiente. As pesquisas vetoriais classificam rapidamente os resultados mais relevantes sem comparar cada incorporação à consulta do usuário individualmente.

A Pesquisa Vetorial sincroniza automaticamente as novas incorporações adicionadas à sua tabela Delta e atualiza o índice da Pesquisa Vetorial.

O que é um agente RAG?

Um agente de Geração Aumentada de Recuperação (RAG) é uma parte fundamental de um aplicativo RAG que aprimora os recursos de grandes modelos de linguagem (LLMs) integrando a recuperação de dados externos. O agente RAG processa consultas do usuário, recupera dados relevantes de um banco de dados vetorial e passa esses dados para um LLM para gerar uma resposta.

Ferramentas como LangChain ou Pyfunc ligam essas etapas conectando suas entradas e saídas.

O diagrama abaixo mostra um agente RAG para um chatbot e os recursos do Databricks usados para criar cada agente.

1. Pré-processamento de consulta - Um usuário envia uma consulta, que é então pré-processada para torná-la adequada para consultar o banco de dados vetorial. Isso pode envolver colocar a solicitação em um modelo ou extrair palavras-chave.
2. Vetorização de consulta - Use o Model Serving para incorporar a solicitação usando o mesmo modelo de incorporação usado para incorporar as partes no pipeline de dados. Essas incorporações permitem a comparação da semelhança semântica entre a solicitação e as partes pré-processadas.
3. Fase de recuperação - O retriever, um aplicativo responsável por buscar informações relevantes, pega a consulta vetorizada e executa uma pesquisa de semelhança vetorial usando a Pesquisa Vetorial. Os blocos de dados mais relevantes são classificados e recuperados com base em sua semelhança com a consulta.
4. Aumento de prompt - O recuperador combina os blocos de dados recuperados com a consulta original para fornecer contexto adicional ao LLM. O prompt é cuidadosamente estruturado para garantir que o LLM compreenda o contexto da consulta. Muitas vezes, o LLM tem um modelo para formatar a resposta. Esse processo de ajuste do prompt é conhecido como engenharia de prompt.
5. Fase de geração do LLM - O LLM gera uma resposta usando a consulta aumentada enriquecida pelos resultados da recuperação. O LLM pode ser um modelo personalizado ou um modelo de fundação.
6. Pós-processamento - A resposta do LLM pode ser processada para aplicar lógica de negócios adicional, adicionar citações ou refinar o texto gerado com base em regras ou restrições predefinidas

Vários guardrails podem ser aplicados ao longo deste processo para garantir a conformidade com as políticas empresariais. Isso pode envolver a filtragem de solicitações apropriadas, a verificação das permissões do usuário antes de acessar fontes de dados e o uso de técnicas de moderação de conteúdo nas respostas geradas.

Desenvolvimento de agentes RAG no nível de produção

Itere rapidamente no desenvolvimento de agentes usando os seguintes recursos:

Crie e registre agentes usando qualquer biblioteca e MLflow. Parametrize seus agentes para experimentar e iterar no desenvolvimento de agentes rapidamente.

Implante agentes na produção com suporte nativo para streaming de token e registro de solicitação/resposta, além de um aplicativo de revisão integrado para obter feedback do usuário para seu agente.

O rastreamento de agentes permite registrar, analisar e comparar rastreamentos no código do agente para depurar e entender como o agente responde às solicitações.

Avaliação e monitorização

A avaliação e o monitoramento ajudam a determinar se seu aplicativo RAG atende aos seus requisitos de qualidade, custo e latência. A avaliação ocorre durante o desenvolvimento, enquanto o monitoramento acontece quando o aplicativo é implantado na produção.

O RAG sobre dados não estruturados tem muitos componentes que afetam a qualidade. Por exemplo, alterações na formatação de dados podem influenciar as partes recuperadas e a capacidade do LLM de gerar respostas relevantes. Portanto, é importante avaliar componentes individuais, além da aplicação geral.

Para obter mais informações, consulte O que é Mosaic AI Agent Evaluation?.

Disponibilidade da região

Para obter informações sobre a disponibilidade regional do Agent Framework, consulte Recursos com disponibilidade regional limitada