Compartilhar via


Etapas de descrição e processamento do pipeline de dados RAG

Neste artigo, você aprenderá a preparar dados não estruturados para uso em aplicativos RAG. Dados não estruturados referem-se a dados sem uma estrutura ou organização específica, como documentos PDF que podem incluir texto e imagens ou conteúdo multimídia, como áudio ou vídeos.

Dados não estruturados não têm um modelo ou esquema de dados predefinido, impossibilitar a consulta apenas com base na estrutura e nos metadados. Como resultado, dados não estruturados exigem técnicas que podem entender e extrair significado semântico de texto bruto, imagens, áudio ou outro conteúdo.

Durante a preparação de dados, o pipeline de dados do aplicativo RAG usa dados não estruturados brutos e os transforma em partes discretas que podem ser consultadas com base em sua relevância para a consulta de um usuário. As principais etapas no pré-processamento de dados são descritas abaixo. Cada etapa tem uma variedade de botões que podem ser ajustados. Para obter uma explicação mais profunda sobre esses botões, consulte Qualidade dos aplicativos RAG.

Diagrama dos componentes básicos do pipeline de dados RAG.

Preparar dados não estruturados para recuperação

No restante desta seção, descrevemos o processo de preparação de dados não estruturados para recuperação usando a pesquisa semântica. A pesquisa semântica entende o significado contextual e a intenção de uma consulta de usuário para fornecer resultados de pesquisa mais relevantes.

A pesquisa semântica é uma das várias abordagens que podem ser tomadas ao implementar o componente de recuperação de um aplicativo RAG em dados não estruturados. Esses documentos abordam estratégias de recuperação alternativas na seção botões de recuperação.

Etapas de um pipeline de dados de aplicativo RAG

Veja a seguir as etapas típicas de um pipeline de dados em um aplicativo RAG usando dados não estruturados:

  1. Analisar os documentos brutos: a etapa inicial envolve a transformação de dados brutos em um formato utilizável. Isso pode incluir a extração de texto, tabelas e imagens de uma coleção de PDFs ou a utilização de técnicas de OCR (reconhecimento óptico de caracteres) para extrair texto de imagens.
  2. Extrair metadados do documento (opcional): em alguns casos, extrair e usar metadados de documento, como títulos de documento, números de página, URLs ou outras informações, pode ajudar a etapa de recuperação com mais precisão a consultar os dados corretos.
  3. Documentos em partes: para garantir que os documentos analisados possam se encaixar no modelo de inserção e na janela de contexto da LLM, dividimos os documentos analisados em partes menores e discretas. Recuperar essas partes focadas, em vez de documentos inteiros, fornece ao LLM um contexto mais direcionado do qual gerar suas respostas.
  4. Incorporando partes: em um aplicativo RAG que usa pesquisa semântica, um tipo especial de modelo de linguagem chamado modelo de inserção transforma cada um dos blocos da etapa anterior em vetores numéricos ou listas de números, que encapsulam o significado de cada parte do conteúdo. Crucialmente, esses vetores representam o significado semântico do texto, não apenas palavras-chave no nível da superfície. Isso permite a pesquisa com base no significado em vez de correspondências de texto literal.
  5. Partes de índice em um banco de dados vetor: a etapa final é carregar as representações de vetor das partes, juntamente com o texto da parte, em um banco de dados vetor. Um banco de dados vetor é um tipo especializado de banco de dados projetado para armazenar e pesquisar dados de vetor com eficiência, como inserções. Para manter o desempenho com um grande número de partes, os bancos de dados vetoriais geralmente incluem um índice de vetor que usa vários algoritmos para organizar e mapear as inserções de vetor de uma maneira que otimiza a eficiência da pesquisa. No momento da consulta, a solicitação de um usuário é inserida em um vetor e o banco de dados aproveita o índice de vetor para localizar os vetores de partes mais semelhantes, retornando as partes de texto originais correspondentes.

O processo de similaridade de computação pode ser computacionalmente caro. Índices vetoriais, como a Busca em Vetores do Databricks, aceleram esse processo fornecendo um mecanismo para organizar e navegar com eficiência inserções, muitas vezes por meio de métodos sofisticados de aproximação. Isso permite a classificação rápida dos resultados mais relevantes sem comparar cada inserção com a consulta do usuário individualmente.

Cada etapa no pipeline de dados envolve decisões de engenharia que afetam a qualidade do aplicativo RAG. Por exemplo, escolher o tamanho da parte certa na etapa 3 garante que a LLM receba informações específicas, mas contextualizadas, enquanto selecionar um modelo de inserção apropriado na etapa 4 determina a precisão das partes retornadas durante a recuperação.

Esse processo de preparação de dados é chamado de preparação de dados offline, pois ocorre antes que o sistema responda às consultas, ao contrário das etapas online disparadas quando um usuário envia uma consulta.