Pular para o conteúdo principal

Melhorar a qualidade da cadeia RAG

Diagrama dos componentes da cadeia RAG que contribuem para a qualidade.

Este artigo aborda como você pode melhorar a qualidade do aplicativo RAG usando componentes da cadeia RAG.

A cadeia RAG recebe uma consulta do usuário como entrada, recupera informações relevantes para essa consulta e gera uma resposta apropriada com base nos dados recuperados. Embora os passos exatos em uma cadeia RAG possam variar amplamente dependendo do caso de uso e dos requisitos, os seguintes são os componentes key a serem considerados ao construir sua cadeia RAG:

  1. Compreensão de consultas: Análise e transformação de consultas de usuários para melhor representar a intenção e extrair informações relevantes, como filtros ou palavras-chave, para melhorar o processo de recuperação.
  2. **Recuperação:** Encontrar os trechos de informação mais relevantes dada uma consulta de recuperação. No caso de dados não estruturados, isso geralmente envolve uma ou uma combinação de busca semântica ou baseada em palavras-chave.
  3. Aumento do prompt: Combinando uma consulta de usuário com informação recuperada e instruções para guia do LLM na geração de respostas de alta qualidade.
  4. LLM: Selecionar o modelo mais apropriado (e parâmetros do modelo) para seu aplicativo para otimizar/equilibrar desempenho, latência e custo.
  5. Pós-processamento e guardrails: Aplicação de os passos de processamento adicionais e medidas de segurança para garantir que as respostas geradas por LLM sejam relevantes, factualmente consistentes e estejam em conformidade com diretrizes ou restrições específicas.

Saiba mais sobre como avaliar e melhorar seu aplicativo iterativamente em 3. Iterar na Qualidade do Agente de AI.

Compreensão de query

Usar a consulta do usuário diretamente como uma consulta de recuperação pode funcionar para algumas consultas. No entanto, geralmente é benéfico reformular a consulta antes do passo de recuperação. A compreensão de consultas compreende o passo (ou série de os passos) no início de uma cadeia para analisar e transformar consultas de usuário para representar melhor a intenção, extrair informação relevante e, em última instância, ajudar o processo de recuperação subsequente. As abordagens para transformar uma query do usuário para melhorar a recuperação incluem:

  1. Reescrita de consulta: A reescrita de consulta envolve traduzir uma consulta do usuário em uma ou mais consultas que melhor representam a intenção original. O objetivo é reformular a consulta de uma forma que aumente a probabilidade de o passo de recuperação encontrar os documentos mais relevantes. Isso pode ser particularmente útil ao lidar com consultas complexas ou ambíguas que podem não corresponder diretamente à terminologia usada nos documentos de recuperação.

    Exemplos:

    • Parafraseando a história de conversas em um chat com várias interações
    • Correção de erros de ortografia na query do usuário
    • Substituindo palavras ou frases na consulta do usuário por sinônimos para capturar uma gama mais ampla de documentos relevantes
importante

A reescrita de consulta deve ser feita em conjunto com as alterações no componente de recuperação

  1. Extração de filtros: Em alguns casos, as query dos usuários podem conter filtros ou critérios específicos que podem ser usados para refinar os resultados da pesquisa. A extração de filtros envolve identificar e extrair esses filtros da query e passá-los para o passo de recuperação como parâmetros adicionais. Isso pode ajudar a melhorar a relevância dos documentos recuperados, concentrando-se em subconjuntos específicos dos dados disponíveis.

    Exemplos:

    • Extraindo períodos de tempo específicos mencionados na consulta, como "artigos dos últimos 6 meses" ou "relatórios de 2023".
    • Identificando menções de produtos, serviços ou categorias específicas na consulta, como "Databricks Professional Services" ou "laptops".
    • Extraindo entidades geográficas da consulta, como nomes de cidades ou códigos de países.
nota

A extração de filtro deve ser feita em conjunto com alterações nos componentes de pipeline de dados de extração de metadados e de cadeia de retriever. O passo de extração de metadados deve garantir que os campos de metadados relevantes estejam disponíveis para cada documento/trecho, e o passo de recuperação deve ser implementado para aceitar e aplicar os filtros extraídos.

Além da reescrita de consulta e extração de filtro, outra consideração importante na compreensão de consulta é se deve usar uma única chamada de LLM ou várias chamadas. Embora usar uma única chamada com um prompt cuidadosamente elaborado possa ser eficiente, há casos em que dividir o processo de compreensão de consulta em várias chamadas de LLM pode levar a melhores resultados. Esta, aliás, é uma regra geral aplicável quando você está tentando implementar uma série de etapas lógicas complexas em um único prompt.

Por exemplo, pode-se usar uma chamada de LLM para classificar a intenção da consulta, outra para extrair entidades relevantes e uma terceira para reescrever a consulta com base nas informações extraídas. Embora esta abordagem possa adicionar alguma latência ao processo geral, ela pode permitir um controle mais granular e potencialmente melhorar a qualidade dos documentos recuperados.

Compreensão de query multiestágios para um bot de suporte

Veja como um componente de compreensão de consulta de várias etapas pode parecer para um bot de suporte ao cliente:

  1. Classificação de intenções: Use um LLM para classificar a consulta do usuário em categorias predefinidas, como “informação do produto”, “solução de problemas” ou “gerenciamento de account”.
  2. Extração de entidades: Com base na intenção identificada, use outra chamada de LLM para extrair entidades relevantes da consulta, como nomes de produtos, erros relatados ou números de account.
  3. Reescrita de consulta: use a intenção e as entidades extraídas para reescrever a consulta original em um formato mais específico e direcionado, por exemplo, “Minha cadeia RAG está falhando ao ser implantado no Model Serving, estou vendo o seguinte erro…”.

Recuperação

O componente de recuperação da cadeia RAG é responsável por encontrar as partes mais relevantes de informações, dada uma consulta de recuperação. No contexto de dados não estruturados, a recuperação geralmente envolve uma ou uma combinação de pesquisa semântica, pesquisa baseada em palavras-chave e filtragem de metadados. A escolha da estratégia de recuperação depende dos requisitos específicos do seu aplicativo, da natureza dos dados e dos tipos de consultas que você espera manipular. Vamos comparar estas opções:

  1. Pesquisa semântica: a pesquisa semântica usa um modelo de embedding para converter cada parte de texto em uma representação vetorial que captura seu significado semântico. Ao comparar a representação vetorial da consulta de recuperação com as representações vetoriais dos chunks, a pesquisa semântica pode recuperar documentos conceitualmente semelhantes, mesmo que não contenham as palavras-chave exatas da consulta.
  2. Pesquisa baseada em palavras-chave: A pesquisa baseada em palavras-chave determina a relevância dos documentos analisando a frequência e a distribuição de palavras compartilhadas entre a consulta de recuperação e os documentos indexados. Quanto mais frequentemente as mesmas palavras aparecem tanto na consulta quanto em um documento, maior será a pontuação de relevância atribuída a esse documento.
  3. Pesquisa híbrida: a pesquisa híbrida combina os pontos fortes da pesquisa semântica e baseada em palavras-chave ao empregar um processo de recuperação em duas etapas. Primeiro, ele realiza uma pesquisa semântica para recuperar um conjunto de documentos conceitualmente relevantes. Em seguida, ele aplica a pesquisa baseada em palavras-chave neste conjunto reduzido para refinar ainda mais os resultados com base em correspondências exatas de palavras-chave. Por fim, ele combina as pontuações de ambos os passos para classificar os documentos.

Comparar estratégias de recuperação

A tabela a seguir compara cada uma dessas estratégias de recuperação entre si:

Busca semântica

Busca por palavra-chave

Pesquisa híbrida

Explicação simples

Se os mesmos **conceitos** aparecerem na query e em um documento potencial, eles são relevantes.

Se as mesmas palavras aparecerem na consulta e em um documento em potencial, elas são relevantes. Quanto mais palavras da consulta no documento, mais relevante esse documento é.

Executa tanto uma pesquisa semântica quanto uma pesquisa por palavra-chave, e então combina os resultados.

Exemplo de caso de uso

Suporte ao cliente onde as consultas dos usuários são diferentes das palavras nos manuais do produto. Exemplo: "como eu ligo meu telefone?" e a seção do manual se chama "ligar/desligar a energia".

Suporte ao cliente onde as consultas contêm termos técnicos específicos e não descritivos. Exemplo: "o que o modelo HD7-8D faz?"

Consultas de suporte ao cliente que combinavam termos semânticos e técnicos. Exemplo: “como ligo meu HD7-8D?”

Abordagens técnicas

Usa incorporações para representar texto em um espaço vetorial contínuo, habilitando a busca semântica.

Baseia-se em métodos discretos baseados em tokens como bag-of-words, TF-IDF, BM25 para correspondência de palavras-chave.

Use uma abordagem de reclassificação para combinar os resultados, como fusão de classificação recíproca ou um modelo de reclassificação.

Pontos fortes

Recuperando informação contextualmente similar a uma consulta, mesmo que as palavras exatas não sejam usadas.

Cenários que exigem correspondências exatas de palavras-chave, ideais para querys focadas em termos específicos, como nomes de produtos.

Combina o melhor de ambas as abordagens.

Maneiras de aprimorar o processo de recuperação

Além dessas principais estratégias de recuperação, há várias técnicas que você pode aplicar para aprimorar ainda mais o processo de recuperação:

  • Expansão de consulta: a expansão de consulta pode ajudar a capturar uma gama mais ampla de documentos relevantes usando múltiplas variações da consulta de recuperação. Isso pode ser alcançado realizando buscas individuais para cada consulta expandida ou usando uma concatenação de todas as consultas de busca expandidas em uma única consulta de recuperação.
nota

A expansão de consulta deve ser feita em conjunto com alterações no componente de compreensão de consulta (cadeia RAG). As várias variações de uma consulta de recuperação são tipicamente geradas neste o passo.

  • Reclassificação: Depois de recuperar um conjunto inicial de blocos, aplique critérios de classificação adicionais (por exemplo, classificar por tempo) ou um modelo de reclassificador para reordenar os resultados. A reclassificação pode ajudar a priorizar os blocos mais relevantes, dada uma consulta de recuperação específica. A reclassificação com modelos de codificador cruzado, como mxbai-rerank e ColBERTv2, pode aumentar o desempenho da recuperação.
  • Filtragem de metadados: use filtros de metadados extraídos de o passo de compreensão da consulta para restringir o espaço de busca com base em critérios específicos. Filtros de metadados podem incluir atributos como tipo de documento, data de criação, autor ou tags específicas do domínio. Ao combinar filtros de metadados com busca semântica ou baseada em palavras-chave, você pode criar uma recuperação mais direcionada e eficiente.
nota

A filtragem de metadados deve ser feita em conjunto com as alterações na compreensão de consulta (cadeia RAG) e nos componentes de extração de metadados (pipeline de dados).

Aumento do prompt

Aumento de prompt é o passo onde a consulta do usuário é combinada com a informação e instruções recuperadas em um padrão de prompt para o guia do modelo de linguagem a gerar respostas de alta qualidade. A iteração sobre este padrão para otimizar o prompt fornecido ao LLM (também conhecida como engenharia de prompt ) é necessária para garantir que o modelo seja guiado a produzir respostas precisas, fundamentadas e coerentes.

Há guias completas de engenharia de prompt, mas aqui estão algumas considerações para ter em mente ao iterar no padrão de prompt:

  1. Forneça exemplos

    • Inclua exemplos de consultas bem formuladas e suas respectivas respostas ideais no próprio padrão de prompt (few-shot learning). Isso ajuda o modelo a entender o formato, o estilo e o conteúdo desejados das respostas.
    • Uma maneira útil de encontrar bons exemplos é identificar os tipos de consultas com os quais sua cadeia tem dificuldades. Crie respostas padrão-ouro para essas consultas e inclua-as como exemplos no prompt.
    • Certifique-se de que os exemplos que você fornece sejam representativos das consultas de usuário que você antecipa no momento da inferência. Procure cobrir uma gama diversificada de consultas esperadas para ajudar o modelo a generalizar melhor.
  2. Parametrize seu modelo de padrão

    • Projete seu padrão de prompt para ser flexível, parametrizando-o para incorporar informações adicionais além dos dados recuperados e da query do usuário. Isso pode ser variáveis como data atual, contexto do usuário ou outros metadados relevantes.
    • Injetar essas variáveis no prompt no momento da inferência pode permitir respostas mais personalizadas ou sensíveis ao contexto.
  3. Considere o encadeamento de pensamento

    • Para consultas complexas em que respostas diretas não são facilmente aparentes, considere o prompting de Cadeia de Pensamento (CoT). Esta estratégia de engenharia de prompt divide perguntas complexas em os passos mais simples e sequenciais, guiando o LLM através de um processo de raciocínio lógico.
    • Ao instruir o modelo a “pensar no problema passo a passo”, este é encorajado a fornecer respostas mais detalhadas e bem fundamentadas, o que pode ser particularmente eficaz para lidar com consultas de várias etapas ou abertas.
  4. As instruções podem não ser transferidas entre modelos.

    • Reconheça que os prompts frequentemente não são transferidos perfeitamente entre diferentes modelos de linguagem. Cada modelo possui suas próprias características únicas, onde um prompt que funciona bem para um modelo pode não ser tão eficaz para outro.
    • Experimente diferentes formatos e comprimentos de prompt, consulte guias online (como OpenAI Cookbook ou Anthropic cookbook) e esteja preparado para adaptar e refinar seus prompts ao alternar entre modelos.

LLM

O componente de geração da cadeia RAG pega o padrão de prompt aumentado do passo anterior e o passa para um LLM. Ao selecionar e otimizar um LLM para o componente de geração de uma cadeia RAG, considere os seguintes fatores, que são igualmente aplicáveis a quaisquer outros os passos que envolvam chamadas de LLM:

  1. Experimente diferentes modelos prontos.

    • Cada modelo tem suas próprias propriedades, pontos fortes e fracos exclusivos. Alguns modelos podem ter uma melhor compreensão de certos domínios ou ter um melhor desempenho em tarefas específicas.
    • Conforme mencionado anteriormente, é importante considerar que a escolha do modelo também pode influenciar o processo de engenharia de prompt, pois diferentes modelos podem responder de maneiras distintas aos mesmos prompts.
    • Se houver vários os passos em sua cadeia que exigem um LLM, como chamadas para compreensão de query, além do o passo de geração, considere usar modelos diferentes para passos diferentes. Modelos mais caros e de propósito geral podem ser um exagero para tarefas como determinar a intenção de uma query do usuário.
  2. Comece pequeno e aumente a escala conforme necessário.

    • Embora seja tentador buscar imediatamente os modelos mais poderosos e capazes disponíveis (por exemplo, GPT-4, Claude), é geralmente mais eficiente começar com modelos menores e mais leves.
    • Em muitos casos, alternativas de código aberto menores, como Llama 3, podem fornecer resultados satisfatórios a um custo mais baixo e com tempos de inferência mais rápidos. Esses modelos podem ser particularmente eficazes para tarefas que não exigem raciocínio altamente complexo ou conhecimento de mundo extenso.
    • Ao desenvolver e refinar sua cadeia RAG, avalie continuamente o desempenho e as limitações do modelo escolhido. Se você perceber que o modelo tem dificuldade com certos tipos de consultas ou falha em fornecer respostas suficientemente detalhadas ou precisas, considere escalar para um modelo mais capaz.
    • Monitore o impacto da alteração de modelos nas key métricas, como qualidade de resposta, latência e custo, para garantir o equilíbrio certo para os requisitos do seu caso de uso específico.
  3. Otimizar parâmetros de modelo

    • Experimente diferentes configurações de parâmetros para encontrar o equilíbrio ideal entre qualidade da resposta, diversidade e coerência. Por exemplo, ajustar a temperatura pode controlar a aleatoriedade do texto gerado, enquanto max_tokens pode limitar o comprimento da resposta.
    • Esteja ciente de que as configurações de parâmetro ideais podem variar dependendo da tarefa específica, do prompt e do estilo de saída desejado. Teste e refine iterativamente estas configurações com base na avaliação das respostas geradas.
  4. Ajuste fino específico da tarefa

    • À medida que você aprimora o desempenho, considere o ajuste fino de modelos menores para subtarefas específicas em sua cadeia RAG, como a compreensão de consultas.
    • Ao realizar o treinamento de modelos especializados para tarefas individuais com a cadeia RAG, você pode melhorar o desempenho geral, reduzir a latência e diminuir os custos de inferência em comparação com o uso de um único modelo grande para todas as tarefas.
  5. Pré-treinamento contínuo

    • Se seu aplicativo RAG lida com um domínio especializado ou requer conhecimento que não está bem representado no LLM pré-treinado, considere realizar o pré-treinamento continuado (CPT) em dados específicos do domínio.
    • O pré-treinamento contínuo pode melhorar a compreensão de um modelo sobre terminologia ou conceitos específicos exclusivos do seu domínio. Por sua vez, isso pode reduzir a necessidade de engenharia de prompt extensiva ou exemplos de poucos disparos.

Pós-processamento e barreiras de segurança

Depois que o LLM gera uma resposta, geralmente é necessário aplicar técnicas de pós-processamento ou barreiras de segurança para garantir que a saída atenda aos requisitos de formato, estilo e conteúdo desejados. Este o passo final (ou múltiplos os passos) na cadeia pode ajudar a manter a consistência e a qualidade nas respostas geradas. Se você estiver implementando pós-processamento e barreiras de segurança, considere o seguinte:

  1. Impondo o formato de saída

    • Dependendo do seu caso de uso, pode ser necessário que as respostas geradas sigam um formato específico, como um padrão estruturado ou um tipo de arquivo específico (como JSON, HTML, Markdown e assim por diante).
    • Se a saída estruturada for necessária, bibliotecas como Instructor ou Outlines fornecem bons pontos de partida para implementar esse tipo de o passo de validação.
    • Ao desenvolver, dedique tempo para garantir que o passo de pós-processamento seja flexível o suficiente para lidar com variações nas respostas geradas, mantendo o formato exigido.
  2. Manter a consistência do estilo

    • Se seu aplicativo RAG tiver diretrizes de estilo específicas ou requisitos de tom (por exemplo, formal vs. casual, conciso vs. detalhado), o passo de pós-processamento pode verificar e aplicar esses atributos de estilo em todas as respostas geradas.
  3. Filtros de conteúdo e proteções de segurança

  4. Lidando com alucinações

    • A defesa contra alucinações também pode ser implementada como o passo de pós-processamento. Isso pode envolver a referência cruzada da saída gerada com documentos recuperados, ou o uso de LLMs adicionais para validar a precisão factual da resposta.
    • Desenvolva mecanismos de fallback para lidar com casos em que a resposta gerada não atende aos requisitos de precisão factual, como gerar respostas alternativas ou fornecer isenções de responsabilidade ao usuário.
  5. Tratamento de erros

    • Com os passos de pós-processamento, implemente mecanismos para lidar de forma elegante com os casos em que o passo encontra um problema ou não consegue gerar uma resposta satisfatória. Isso pode envolver a geração de uma resposta default ou o encaminhamento do problema para um operador humano para revisão manual.