Geração Aumentada de Recuperação (RAG) em Databricks

Este artigo fornece uma visão geral da geração aumentada de recuperação (RAG) e descreve o suporte ao aplicativo RAG no Databricks.

O que é geração aumentada de recuperação?

RAG é um padrão de design generativo de IA que envolve a combinação de um grande modelo de linguagem (LLM) com recuperação de conhecimento externo. O RAG é necessário para conectar dados tempo-real às suas aplicações generativas de IA. Isso melhora a precisão e a qualidade da aplicação, fornecendo seus dados como contexto para o LLM no momento da inferência.

A plataforma Databricks fornece um conjunto integrado de ferramentas que suporta os seguintes cenários RAG.

Tipo de RAG	Descrição	Exemplo de caso de uso
Dados não estruturados	Uso de documentos – PDFs, wikis, conteúdos de sites, documentos do Google ou Microsoft Office e assim por diante.	Chatbot sobre documentação do produto
Dados estruturados	Uso de dados tabulares - Tabelas Delta, dados de APIs de aplicativos existentes.	Chatbot para verificar o status do pedido
Ferramentas e chamadas de funções	Chame APIs internas ou de terceiros para realizar tarefas específicas ou atualizar status. Por exemplo, realizar cálculos ou acionar um fluxo de trabalho comercial.	Chatbot para fazer um pedido
Agentes	Decida dinamicamente como responder à query de um usuário usando um LLM para escolher uma sequência de ações.	Chatbot que substitui um agente de atendimento ao cliente

Arquitetura de aplicativo RAG

A seguir ilustramos os componentes que compõem um aplicativo RAG.

Os aplicativos RAG requerem um pipeline e um componente de cadeia para executar o seguinte:

Indexação Um pipeline que ingere dados de uma origem e os indexa. Esses dados podem ser estruturados ou não estruturados.
Recuperação e geração Esta é a cadeia RAG real. Ele pega a query do usuário e recupera dados semelhantes do índice e, em seguida, passa os dados, junto com a query, para o modelo LLM.

O diagrama abaixo demonstra esses componentes principais:

Arquitetura de aplicativo RAG apenas para o pipeline de indexação e recuperação e geração, a cadeia RAG, pedaços de RAG. A seção superior mostra a cadeia RAG consumindo a query e os passos subsequentes de processamento query , expansão query , recuperação e reclassificação, engenharia de prompt, geração de resposta inicial e pós-processamento, tudo antes de gerar uma resposta à query. A parte inferior mostra a cadeia RAG conectada a um pipeline de dados separado para 1. dados não estruturados, que inclui análise, fragmentação e incorporação de dados e armazenamento desses dados em um banco de dados ou índice de pesquisa vetorial. Pipeline de dados não estruturado requer interação com modelos de incorporação e fundamentais para alimentar a cadeia RAG e 2. pipeline de dados estruturado, que inclui o consumo de blocos de dados já incorporados e a execução de tarefas ETL e engenharia de recursos antes de servir esses dados à cadeia RAG

Exemplo de RAG de dados não estruturados

As seções a seguir descrevem os detalhes do pipeline de indexação e da cadeia RAG no contexto de um exemplo de RAG de dados não estruturados.

Pipeline de indexação em um aplicativo RAG

As etapas a seguir descrevem o pipeline de indexação:

Ingira dados de sua fonte de dados proprietária.
Divida os dados em partes que possam caber na janela de contexto do LLM fundamental. Este passo também inclui a análise dos dados e a extração de metadados. Esses dados são comumente chamados de base de conhecimento na qual o LLM básico é treinado.
Use um modelo de incorporação para criar incorporações vetoriais para os blocos de dados.
Armazene os embeddings e metadados em um banco de dados vetorial para torná-los acessíveis para consulta pela cadeia RAG.

Recuperação usando a cadeia RAG

Após a preparação do índice, a cadeia RAG da aplicação pode ser atendida para responder às dúvidas. Os passos e o diagrama a seguir descrevem como o aplicativo RAG responde a uma solicitação recebida.

Incorpore a solicitação usando o mesmo modelo de incorporação usado para incorporar os dados na base de conhecimento.
query o banco de dados vetorial para fazer uma pesquisa de similaridade entre a solicitação incorporada e os blocos de dados incorporados no banco de dados vetorial.
Recupere os blocos de dados mais relevantes para a solicitação.
Alimente os blocos de dados relevantes e a solicitação para um LLM personalizado. Os blocos de dados fornecem contexto que ajuda o LLM a gerar uma resposta apropriada. Muitas vezes, o LLM possui um padrão de como formatar a resposta.
Gere uma resposta.

O diagrama a seguir ilustra esse processo:

RAG fluxo de trabalho após uma solicitação

Desenvolva aplicativos RAG com Databricks

Databricks fornece os seguintes recursos para ajudá-lo a desenvolver aplicativos RAG.

Unity Catalog para governança, descoberta, controle de versão e controle de acesso para dados, recursos, modelos e funções.
Notebook e fluxo de trabalho para criação e orquestração de pipeline de dados.
TabelasDelta para armazenar dados estruturados e blocos e incorporações de dados não estruturados.
A pesquisa vetorial fornece um banco de dados de vetores consultável que armazena vetores incorporados e pode ser configurado para sincronizar automaticamente com sua base de conhecimento.
Modelo instalado de Databricks para implantação de LLMs e hospedagem de sua cadeia RAG. Você pode configurar um endpoint de modelo de atividade dedicado especificamente para acessar LLMs abertos de última geração com APIs do Foundation Model ou modelos de terceiros com modelos externos.
MLflow para acompanhamento de desenvolvimento da cadeia RAG e avaliação LLM.
recurso engenharia e atendimento. Isso normalmente se aplica a cenários RAG de dados estruturados.
Tabelas on-line. Você pode servir tabelas online como uma API de baixa latência para incluir os dados em aplicativos RAG.
Lakehouse Monitoring para monitoramento de dados e qualidade de previsão do modelo de acompanhamento e desvio usando registro automático de carga útil com tabelas de inferência.
AI Playground. Uma interface de usuário baseada em bate-papo para testar e comparar LLMs.

Arquitetura RAG com Databricks

Os diagramas de arquitetura a seguir demonstram onde cada recurso do Databricks se encaixa no fluxo de trabalho do RAG. Para obter um exemplo, veja a demonstração Implantando seu Chatbot LLM com Geração Aumentada de Recuperação.

Processar dados não estruturados e embeddings gerenciados pelo Databricks

Para processamento de dados não estruturados e embeddings gerenciados por Databricks, o seguinte diagrama de passos e diagrama mostram:

ingestão de dados de sua fonte de dados proprietária. Você pode armazenar esses dados em uma tabela Delta ou em um volume Unity Catalog .
Os dados são então divididos em partes que podem caber na janela de contexto do LLM fundamental. Este passo também inclui a análise dos dados e a extração de metadados. Você pode usar Databricks Workflows, Databricks Notebook e Delta Live Tables para realizar essas tarefas. Esses dados são comumente chamados de base de conhecimento na qual o LLM básico é treinado.
Os dados analisados e fragmentados são então consumidos por um modelo de incorporação para criar incorporações de vetores. Neste cenário, o Databricks compute os embeddings para você como parte da funcionalidade Vector Search que usa modelo específico para fornecer um modelo de incorporação.
Após os embeddings compute do Vector Search, o Databricks os armazena em uma tabela Delta.
Também como parte do Vector Search, os embeddings e metadados são indexados e armazenados em um banco de dados vetorial para torná-los acessíveis para consulta pela cadeia RAG. Vector Search compute automaticamente incorporações para novos dados que são adicionados à tabela de dados de origem e atualiza o índice de pesquisa vetorial.

pipeline de indexação RAG processando dados não estruturados e Databricks gerenciando embeddings. Este diagrama mostra a arquitetura do aplicativo RAG apenas para o pipeline de indexação.

Processar dados não estruturados e incorporações gerenciadas pelo cliente

Para processamento de dados não estruturados e embeddings cliente-gerenciar, seguem os passos e diagrama a seguir:

ingestão de dados de sua fonte de dados proprietária. Você pode armazenar esses dados em uma tabela Delta ou em um volume Unity Catalog .
Você pode então dividir os dados em partes que cabem na janela de contexto do LLM fundamental. Este passo também inclui a análise dos dados e a extração de metadados. Você pode usar Databricks Workflows, Databricks Notebook e Delta Live Tables para realizar essas tarefas. Esses dados são comumente chamados de base de conhecimento na qual o LLM básico é treinado.
Em seguida, os dados analisados e fragmentados podem ser consumidos por um modelo de incorporação para criar incorporações vetoriais. Neste cenário, você mesmo compute os embeddings e pode usar o modelo autônomo para servir um modelo de embedding.
Depois de compute os embeddings, você pode armazená-los em uma tabela Delta, que pode ser sincronizada com o Vector Search.
Como parte do Vector Search, os embeddings e metadados são indexados e armazenados em um banco de dados vetorial para torná-los acessíveis para consulta pela cadeia RAG. Vector Search sincroniza automaticamente novos embeddings adicionados à sua tabela Delta e atualiza o índice de pesquisa vetorial.

RAG com dados não estruturados do Databricks e embeddings autogerenciados

Processar dados estruturados

Para o processamento de dados estruturados, os seguintes passos e diagrama mostram:

ingestão de dados de sua fonte de dados proprietária. Você pode armazenar esses dados em uma tabela Delta ou em um volume Unity Catalog .
Para engenharia de recursos você pode usar Databricks Notebook, Databricks fluxo de trabalho e Delta Live Tables.
Crie uma tabela de recursos. Uma tabela de recursos é uma tabela Delta no Unity Catalog que possui uma key primária.
Crie uma tabela online e hospede-a em um endpoint de atendimento de recurso. O endpoint permanece automaticamente sincronizado com a tabela de recursos.

Para obter um exemplo Notebook que ilustra o uso de tabelas online e recurso servindo para aplicativos RAG, consulte as tabelas online do Databricks e endpoint de serviço de recurso para exemplo de RAG Notebook.

RAG com dados estruturados do Databricks

Corrente RAG

Após a preparação do índice, a cadeia RAG da aplicação pode ser atendida para responder às dúvidas. Os passos e o diagrama a seguir descrevem como a cadeia RAG opera em resposta a uma pergunta recebida.

A pergunta recebida é incorporada usando o mesmo modelo de incorporação usado para incorporar os dados na base de conhecimento. modelo específico é usado para servir o modelo de incorporação.
Depois que a pergunta for incorporada, você poderá usar Vector Search para fazer uma pesquisa de similaridade entre a pergunta incorporada e os blocos de dados incorporados no banco de dados vetorial.
Depois que o Vector Search recupera os blocos de dados que são mais relevantes para a solicitação, esses blocos de dados juntamente com o recurso relevante do recurso Serving e a pergunta incorporada são consumidos em um LLM customizado para pós-processamento antes de uma resposta ser gerada.
Os blocos de dados e o recurso fornecem contexto que ajuda o LLM a gerar uma resposta apropriada. Muitas vezes, o LLM possui um padrão de como formatar a resposta. Mais uma vez, o modelo de atividade é utilizado para atender o LLM. Você também pode usar o Unity Catalog e o Lakehouse Monitoring para armazenar logs e monitorar o fluxo de trabalho da cadeia, respectivamente.
Gere uma resposta.

Disponibilidade da região

Os recursos que suportam o desenvolvimento de aplicações RAG no Databricks estão disponíveis nas mesmas regiões do modelo instalado.

Se você planeja usar APIs do Foundation Model como parte do desenvolvimento de seu aplicativo RAG, estará limitado às regiões suportadas para APIs do Foundation Model.