Compartilhar via


Construindo sistemas avançados de Geração Aumentada de Recuperação

O artigo anterior discutiu duas opções para criar um aplicativo de "bate-papo sobre seus dados", um dos principais casos de uso para IA generativa nas empresas:

  • Geração aumentada de recuperação (RAG) que complementa o treinamento de um Large Language Model (LLM) com um banco de dados de artigos pesquisáveis que podem ser recuperados com base na semelhança com as consultas dos usuários e passados para o LLM para conclusão.
  • Ajuste fino, que expande o treinamento do LLM para entender mais sobre o domínio do problema.

O artigo anterior também discutiu quando usar cada abordagem, prós e contras de cada abordagem e várias outras considerações.

Este artigo explora o RAG com mais profundidade, especificamente, todo o trabalho necessário para criar uma solução pronta para produção.

O artigo anterior descreveu as etapas ou fases do RAG usando o diagrama a seguir.

Diagrama representando um fluxo RAG simples, com caixas representando etapas ou processos e setas conectando cada caixa. O fluxo começa com a consulta do usuário. Em seguida, a consulta é enviada para a API de incorporação, que resulta em uma consulta vetorizada, que é usada para localizar as correspondências mais próximas no banco de dados vetorial, que recupera partes de artigo, e as partes de consulta e artigo são enviadas para a API de conclusão e os resultados são enviados ao usuário.

Essa representação tem sido chamada de "RAG ingênua" e é uma maneira útil de primeiro entender os mecanismos, funções e responsabilidades necessárias para implementar um sistema de bate-papo baseado em RAG.

No entanto, uma implementação mais real tem muito mais etapas de pré e pós-processamento para preparar os artigos, as consultas e as respostas para uso. O diagrama a seguir é uma representação mais realista de um RAG, às vezes referido como "RAG avançado".

Diagrama exibindo o fluxo avançado RAG da lógica como uma série de caixas com setas entre elas. Há 10 caixas que começam com a consulta do usuário. Em seguida, as etapas de processamento de consulta, uma chamada para a API de incorporação, a consulta resultante como um vetor, em seguida, o vetor é usado para consultar o banco de dados vetorial para encontrar a correspondência mais próxima, em seguida, recuperado como blocos de artigo, em seguida, etapas de processamento pós-recuperação, em seguida, consulta processada e partes de artigo processadas são enviadas para a API de conclusão e, em seguida, etapas de processamento pós-conclusão,  e, finalmente, uma resposta entregue ao usuário.

Este artigo fornece uma estrutura conceitual para entender os tipos de preocupações de pré e pós-processamento em um sistema de bate-papo baseado em RAG do mundo real, organizado da seguinte maneira:

  • Fase de ingestão
  • Fase do pipeline de inferência
  • Fase de avaliação

Como uma visão geral conceitual, as palavras-chave e ideias são fornecidas como contexto e um ponto de partida para futuras explorações e pesquisas.

Ingestão

O Ingestion se preocupa principalmente em armazenar os documentos da sua organização de forma que eles possam ser facilmente recuperados para responder à pergunta de um usuário. O desafio é garantir que as partes dos documentos que melhor correspondem à consulta do usuário sejam localizadas e utilizadas durante a inferência. A correspondência é realizada principalmente por meio de incorporações vetorizadas e uma pesquisa de similaridade cosseno. No entanto, é facilitado pela compreensão da natureza do conteúdo (padrões, forma, etc.) e da estratégia de organização de dados (a estrutura dos dados quando armazenados no banco de dados vetorial).

Para esse fim, os desenvolvedores precisam considerar o seguinte:

  • Pré-processamento e extração de conteúdo
  • Estratégia de fragmentação
  • Organização de fragmentação
  • Estratégia de atualização

Pré-processamento e extração de conteúdo

Conteúdo limpo e preciso é uma das melhores maneiras de melhorar a qualidade geral de um sistema de bate-papo baseado em RAG. Para conseguir isso, os desenvolvedores precisam começar analisando a forma e a forma dos documentos a serem indexados. Os documentos estão em conformidade com padrões de conteúdo especificados, como documentação? Em caso negativo, que tipos de perguntas os documentos podem responder?

No mínimo, os desenvolvedores devem criar etapas no pipeline de ingestão para:

  • Padronizar formatos de texto
  • Manipular caracteres especiais
  • Remover conteúdo não relacionado e desatualizado
  • Conta para conteúdo versionado
  • Conta para a experiência de conteúdo (guias, imagens, tabelas)
  • Extrair metadados

Algumas dessas informações (como metadados, por exemplo) podem ser úteis para serem mantidas com o documento no banco de dados vetorial para uso durante o processo de recuperação e avaliação no pipeline de inferência ou combinadas com o bloco de texto para persuadir a incorporação vetorial do bloco.

Estratégia de fragmentação

Os desenvolvedores devem decidir como dividir um documento mais longo em partes menores. Isso pode melhorar a relevância do conteúdo suplementar enviado ao LLM para responder à consulta do usuário com precisão. Além disso, os desenvolvedores precisam considerar como utilizar as partes após a recuperação. Esta é uma área onde os projetistas de sistemas devem fazer algumas pesquisas sobre técnicas usadas na indústria, e fazer alguma experimentação, mesmo testando-a em uma capacidade limitada em sua organização.

Os desenvolvedores devem considerar:

  • Otimização do tamanho do bloco - Determine qual é o tamanho ideal do bloco e como designar um bloco. Por seção? Por parágrafo? Por sentença?
  • Blocos de janela sobrepostos e deslizantes - Determine como dividir o conteúdo em blocos discretos. Ou os pedaços se sobreporão? Ou os dois (janela de correr)?
  • Small2Big - Ao fragmentar em um nível granular como uma única frase, o conteúdo será organizado de tal forma que seja fácil encontrar as frases vizinhas ou que contenham parágrafo? (Consulte "Organização de fragmentação".) Recuperar essas informações adicionais e fornecê-las ao LLM poderia fornecer mais contexto ao responder à consulta do usuário.

Organização de fragmentação

Em um sistema RAG, a organização dos dados no banco de dados vetoriais é crucial para a recuperação eficiente de informações relevantes para aumentar o processo de geração. Aqui estão os tipos de estratégias de indexação e recuperação que os desenvolvedores podem considerar:

  • Índices hierárquicos - Essa abordagem envolve a criação de várias camadas de índices, em que um índice de nível superior (índice de resumo) reduz rapidamente o espaço de pesquisa para um subconjunto de blocos potencialmente relevantes e um índice de segundo nível (índice de blocos) fornece ponteiros mais detalhados para os dados reais. Esse método pode acelerar significativamente o processo de recuperação, pois reduz o número de entradas a serem examinadas no índice detalhado filtrando o índice de resumo primeiro.
  • Índices especializados - Índices especializados, como bancos de dados baseados em gráficos ou relacionais, podem ser usados dependendo da natureza dos dados e das relações entre os blocos. Por exemplo:
    • Os índices baseados em gráficos são úteis quando os blocos têm informações ou relacionamentos interconectados que podem melhorar a recuperação, como redes de citação ou gráficos de conhecimento.
    • Os bancos de dados relacionais podem ser eficazes se os blocos forem estruturados em um formato tabular em que consultas SQL possam ser usadas para filtrar e recuperar dados com base em atributos ou relacionamentos específicos.
  • Índices híbridos - Uma abordagem híbrida combina várias estratégias de indexação para alavancar os pontos fortes de cada uma. Por exemplo, os desenvolvedores podem usar um índice hierárquico para filtragem inicial e um índice baseado em gráfico para explorar relações entre partes dinamicamente durante a recuperação.

Otimização do alinhamento

Para melhorar a relevância e a precisão das partes recuperadas, pode ser benéfico alinhá-las mais de perto com os tipos de perguntas ou consultas que devem responder. Uma estratégia para conseguir isso é gerar e inserir uma pergunta hipotética para cada pedaço que represente qual pergunta o bloco é mais adequado para responder. Isso ajuda de várias maneiras:

  • Correspondência aprimorada: Durante a recuperação, o sistema pode comparar a consulta recebida com essas perguntas hipotéticas para encontrar a melhor correspondência, melhorando a relevância dos blocos obtidos.
  • Dados de treinamento para modelos de aprendizado de máquina: esses pares de perguntas e blocos podem servir como dados de treinamento para melhorar os modelos de aprendizado de máquina subjacentes ao sistema RAG, ajudando-o a aprender quais tipos de perguntas são melhor respondidas por quais partes.
  • Tratamento direto de consultas: se uma consulta de usuário real corresponder a uma pergunta hipotética, o sistema poderá recuperar e usar rapidamente a parte correspondente, acelerando o tempo de resposta.

A pergunta hipotética de cada pedaço funciona como uma espécie de "rótulo" que orienta o algoritmo de recuperação, tornando-o mais focado e contextualmente consciente. Isso é útil em cenários em que os blocos cobrem uma ampla gama de tópicos ou tipos de informações.

Estratégias de atualização

Se sua organização precisar indexar documentos que são atualizados com frequência, é essencial manter um corpus atualizado para garantir que o componente retriever (a lógica no sistema responsável por executar a consulta no banco de dados vetorial e retornar os resultados) possa acessar as informações mais atuais. Aqui estão algumas estratégias para atualizar o banco de dados vetoriais em tais sistemas:

  • Atualizações incrementais:
    • Intervalos regulares: agende atualizações em intervalos regulares (por exemplo, diariamente, semanalmente), dependendo da frequência de alterações no documento. Esse método garante que o banco de dados seja atualizado periodicamente.
    • Atualizações baseadas em gatilho: implemente um sistema em que as atualizações acionem a reindexação. Por exemplo, qualquer modificação ou adição de um documento poderia iniciar automaticamente uma reindexação das seções afetadas.
  • Atualizações parciais:
    • Reindexação seletiva: em vez de reindexar todo o banco de dados, atualize seletivamente apenas as partes do corpus que foram alteradas. Isso pode ser mais eficiente do que a reindexação completa, especialmente para grandes conjuntos de dados.
    • Codificação delta: armazene apenas as diferenças entre os documentos existentes e suas versões atualizadas. Essa abordagem reduz a carga de processamento de dados, evitando a necessidade de processar dados inalterados.
  • Controle de versão:
    • Snapshotting: mantenha versões do corpus do documento em diferentes pontos no tempo. Isso permite que o sistema reverta ou faça referência a versões anteriores, se necessário, e fornece um mecanismo de backup.
    • Controle de versão de documentos: use um sistema de controle de versão para rastrear alterações em documentos sistematicamente. Isso ajuda a manter o histórico de alterações e pode simplificar o processo de atualização.
  • Atualizações em tempo real:
    • Processamento de fluxo: Utilize tecnologias de processamento de fluxo para atualizar o banco de dados vetorial em tempo real à medida que as alterações são feitas nos documentos. Isso pode ser crítico para aplicativos em que a pontualidade das informações é fundamental.
    • Consulta em tempo real: em vez de depender apenas de vetores pré-indexados, implemente um mecanismo para consultar dados dinâmicos para obter as respostas mais atualizadas, possivelmente combinando isso com resultados armazenados em cache para eficiência.
  • Técnicas de otimização:
    • Processamento em lote: acumule alterações e processe-as em lotes para otimizar o uso de recursos e reduzir a sobrecarga causada por atualizações frequentes.
    • Abordagens híbridas: combine várias estratégias, como o uso de atualizações incrementais para pequenas alterações e a reindexação completa para atualizações importantes ou alterações estruturais no corpus do documento.

A escolha da estratégia de atualização correta ou da combinação de estratégias depende de requisitos específicos, como o tamanho do corpus do documento, a frequência das atualizações, a necessidade de dados em tempo real e a disponibilidade de recursos. Cada abordagem tem suas compensações em termos de complexidade, custo e latência de atualização, por isso é essencial avaliar esses fatores com base nas necessidades específicas do aplicativo.

Pipeline de inferência

Agora que os artigos foram fragmentados, vetorizados e armazenados em um banco de dados vetorial, o foco se volta para os desafios na conclusão.

  • A consulta do usuário é escrita de forma a obter os resultados do sistema que o usuário está procurando?
  • A consulta do usuário viola alguma de nossas políticas?
  • Como reescrever a consulta do usuário para melhorar suas chances de encontrar correspondências mais próximas no banco de dados vetorial?
  • Como avaliamos os resultados da consulta para garantir que os blocos de artigo estejam alinhados à consulta?
  • Como avaliamos e modificamos os resultados da consulta antes de passá-los para o LLM para garantir que os detalhes mais relevantes sejam incluídos na conclusão do LLM?
  • Como avaliamos a resposta do LLM para garantir que a conclusão do LLM responda à consulta original do usuário?
  • Como garantir que a resposta do LLM esteja em conformidade com nossas políticas?

Como você pode ver, existem muitas tarefas que os desenvolvedores devem levar em conta, principalmente na forma de:

  • Pré-processamento de insumos para otimizar a probabilidade de obter os resultados desejados
  • Saídas de pós-processamento para garantir os resultados desejados

Lembre-se de que todo o pipeline de inferência está sendo executado em tempo real. Embora não haja uma maneira certa de projetar a lógica que executa as etapas de pré e pós-processamento, é provável que seja uma combinação de lógica de programação e chamadas adicionais para um LLM. Uma das considerações mais importantes, então, é o trade-off entre a construção do pipeline mais preciso e compatível possível e o custo e a latência necessários para que isso aconteça.

Vamos analisar cada etapa para identificar estratégias específicas.

Etapas de pré-processamento da consulta

O pré-processamento da consulta ocorre imediatamente após o usuário enviar a consulta, conforme descrito neste diagrama:

Diagrama repetindo as etapas avançadas do RAG com ênfase nas etapas de processamento de consulta rotuladas na caixa.

O objetivo dessas etapas é garantir que o usuário esteja fazendo perguntas dentro do escopo do nosso sistema (e não tentando "jailbreak" o sistema para fazê-lo fazer algo não intencional) e preparar a consulta do usuário para aumentar a probabilidade de que ele localize os melhores pedaços de artigo possíveis usando a pesquisa de semelhança cosseno / "vizinho mais próximo".

Verificação de política - Esta etapa pode envolver lógica que identifica, remove, sinaliza ou rejeita determinado conteúdo. Alguns exemplos podem incluir a remoção de informações de identificação pessoal, a remoção de palavrões e a identificação de tentativas de "jailbreak". Jailbreak refere-se aos métodos que os usuários podem empregar para contornar ou manipular as diretrizes internas de segurança, éticas ou operacionais do modelo.

Reescrita de consultas - Isso pode ser qualquer coisa, desde expandir siglas e remover gírias até reformular a pergunta para fazê-la de forma mais abstrata para extrair conceitos e princípios de alto nível ("step-back prompting").

Uma variação no prompt de step-back é a incorporação hipotética de documentos (HyDE) que usa o LLM para responder à pergunta do usuário, cria uma incorporação para essa resposta (a incorporação hipotética de documentos) e usa essa incorporação para executar uma pesquisa no banco de dados vetorial.

Subconsultas

Esta etapa de processamento diz respeito à consulta original. Se a consulta original for longa e complexa, pode ser útil dividi-la programaticamente em várias consultas menores e, em seguida, combinar todas as respostas.

Por exemplo, considere uma questão relacionada a descobertas científicas, particularmente no campo da física. A pergunta do usuário pode ser: "Quem fez contribuições mais significativas para a física moderna, Albert Einstein ou Niels Bohr?"

Essa consulta pode ser complexa de lidar diretamente porque "contribuições significativas" podem ser subjetivas e multifacetadas. Dividi-lo em subconsultas pode torná-lo mais gerenciável:

  1. Subconsulta 1: "Quais são as principais contribuições de Albert Einstein para a física moderna?"
  2. Subconsulta 2: "Quais são as principais contribuições de Niels Bohr para a física moderna?"

Os resultados dessas subconsultas detalhariam as principais teorias e descobertas de cada físico. Por exemplo:

  • Para Einstein, as contribuições podem incluir a teoria da relatividade, o efeito fotoelétrico e E=mc^2.
  • Para Bohr, as contribuições podem incluir seu modelo do átomo de hidrogênio, seu trabalho sobre mecânica quântica e seu princípio de complementaridade.

Uma vez delineadas essas contribuições, elas podem ser avaliadas para determinar:

  1. Subconsulta 3: "Como as teorias de Einstein impactaram o desenvolvimento da física moderna?"
  2. Subconsulta 4: "Como as teorias de Bohr impactaram o desenvolvimento da física moderna?"

Essas subperguntas explorariam a influência do trabalho de cada cientista no campo, como como as teorias de Einstein levaram a avanços na cosmologia e na teoria quântica, e como o trabalho de Bohr contribuiu para a compreensão da estrutura atômica e da mecânica quântica.

A combinação dos resultados dessas subconsultas pode ajudar o modelo de linguagem a formar uma resposta mais abrangente sobre quem fez contribuições mais significativas para a física moderna, com base na extensão e no impacto de seus avanços teóricos. Esse método simplifica a consulta complexa original, lidando com componentes mais específicos e respondíveis e, em seguida, sintetizando esses achados em uma resposta coerente.

Roteador de consulta

É possível que sua organização decida dividir seu corpus de conteúdo em vários repositórios vetoriais ou sistemas de recuperação inteiros. Nesse caso, os desenvolvedores podem empregar um roteador de consulta, que é um mecanismo que determina de forma inteligente quais índices ou mecanismos de recuperação usar com base na consulta fornecida. A função principal de um roteador de consulta é otimizar a recuperação de informações selecionando o banco de dados ou índice mais apropriado que pode fornecer as melhores respostas para uma consulta específica.

O roteador de consulta normalmente funciona em um ponto após a consulta ter sido formulada pelo usuário, mas antes de ser enviada para qualquer sistema de recuperação. Aqui está um fluxo de trabalho simplificado:

  1. Análise de consulta: o LLM ou outro componente analisa a consulta de entrada para entender seu conteúdo, contexto e o tipo de informação provavelmente necessária.
  2. Seleção de índice: com base na análise, o roteador de consulta seleciona um ou mais de potencialmente vários índices disponíveis. Cada índice pode ser otimizado para diferentes tipos de dados ou consultas — por exemplo, alguns podem ser mais adequados para consultas factuais, enquanto outros podem se destacar no fornecimento de opiniões ou conteúdo subjetivo.
  3. Despacho de Consulta: A consulta é então despachada para o índice selecionado.
  4. Agregação de resultados: As respostas dos índices selecionados são recuperadas e possivelmente agregadas ou processadas para formar uma resposta abrangente.
  5. Geração de respostas: A etapa final envolve a geração de uma resposta coerente com base nas informações recuperadas, possivelmente integrando ou sintetizando conteúdo de múltiplas fontes.

Sua organização pode usar vários mecanismos ou índices de recuperação para os seguintes casos de uso:

  • Especialização em Tipo de Dados: Alguns índices podem se especializar em artigos de notícias, outros em artigos acadêmicos e ainda outros em conteúdo geral da web ou bancos de dados específicos, como aqueles para informações médicas ou legais.
  • Otimização de tipo de consulta: certos índices podem ser otimizados para pesquisas factuais rápidas (por exemplo, datas, eventos), enquanto outros podem ser melhores para tarefas complexas de raciocínio ou consultas que exigem conhecimento profundo do domínio.
  • Diferenças algorítmicas: Diferentes algoritmos de recuperação podem ser usados em diferentes mecanismos, como pesquisas de similaridade baseadas em vetor, pesquisas tradicionais baseadas em palavras-chave ou modelos de compreensão semântica mais avançados.

Imagine um sistema baseado em RAG usado em um contexto de aconselhamento médico. O sistema tem acesso a vários índices:

  • Um índice de artigos de pesquisa médica otimizado para explicações detalhadas e técnicas.
  • Um índice de estudo de caso clínico que fornece exemplos reais de sintomas e tratamentos.
  • Um índice geral de informações de saúde para consultas básicas e informações de saúde pública.

Se um usuário fizer uma pergunta técnica sobre os efeitos bioquímicos de um novo medicamento, o roteador de consulta pode priorizar o índice de papel de pesquisa médica devido à sua profundidade e foco técnico. Para uma pergunta sobre sintomas típicos de uma doença comum, no entanto, o índice de saúde geral pode ser escolhido por seu conteúdo amplo e de fácil compreensão.

Etapas de processamento pós-recuperação

O processamento pós-recuperação ocorre depois que o componente retriever recupera partes de conteúdo relevantes do banco de dados vetorial, conforme descrito no diagrama:

Diagrama repetindo as etapas avançadas do RAG com ênfase na caixa rotulada etapas de processamento pós-recuperação.

Com os blocos de conteúdo candidatos recuperados, as próximas etapas são validar se os blocos de artigo serão úteis ao aumentar o prompt do LLM e, em seguida, começar a preparar o prompt a ser apresentado ao LLM.

Os desenvolvedores devem considerar vários aspectos do prompt. Um prompt que inclui muitas informações de suplemento e algumas (possivelmente as informações mais importantes) poderia ser ignorado. Da mesma forma, um prompt que inclua informações irrelevantes pode afetar indevidamente a resposta.

Outra consideração é o problema da agulha em um palheiro , um termo que se refere a uma peculiaridade conhecida de alguns LLMs onde o conteúdo no início e no final de um prompt têm maior peso para o LLM do que o conteúdo no meio.

Finalmente, o comprimento máximo da janela de contexto do LLM e o número de tokens necessários para concluir prompts extraordinariamente longos (especialmente ao lidar com consultas em escala) devem ser considerados.

Para lidar com esses problemas, um pipeline de processamento pós-recuperação pode incluir as seguintes etapas:

  • Filtrando resultados - Nesta etapa, os desenvolvedores garantem que os blocos de artigo retornados pelo banco de dados vetorial sejam relevantes para a consulta. Caso contrário, o resultado será ignorado ao compor o prompt para o LLM.
  • Reclassificação - Classifique os blocos de artigo recuperados do repositório vetorial para garantir que os detalhes relevantes fiquem perto das bordas (início e fim) do prompt.
  • Compactação de prompt - Usando um modelo pequeno e barato projetado para combinar e resumir vários blocos de artigo em um único prompt compactado antes de enviá-lo ao LLM.

Etapas de processamento pós-conclusão

O processamento pós-conclusão ocorre após a consulta do usuário e todos os blocos de conteúdo terem sido enviados para o LLM, conforme descrito no diagrama a seguir:

Diagrama repetindo as etapas avançadas do RAG com ênfase na caixa rotulada etapas de processamento pós-conclusão.

Depois que o prompt for concluído pelo LLM, é hora de validar o preenchimento para garantir que a resposta seja precisa. Um pipeline de processamento pós-conclusão pode incluir as seguintes etapas:

  • Verificação de fatos - Isso pode assumir muitas formas, mas a intenção é identificar alegações específicas feitas no artigo que são apresentadas como fatos e, em seguida, verificar esses fatos para precisão. Se a etapa de verificação de fatos falhar, talvez seja apropriado consultar novamente o LLM na esperança de uma resposta melhor ou retornar uma mensagem de erro ao usuário.
  • Verificação de política - Esta é a última linha de defesa para garantir que as respostas não contenham conteúdo prejudicial, seja para o usuário ou para a organização.

Avaliação

Avaliar os resultados de um sistema não determinístico não é tão simples quanto, digamos, testes de unidade ou integração com os quais a maioria dos desenvolvedores está familiarizada. Existem vários fatores a serem considerados:

  • Os usuários estão satisfeitos com os resultados que estão obtendo?
  • Os usuários estão obtendo respostas precisas para suas perguntas?
  • Como capturamos o feedback dos usuários? Temos alguma política em vigor que limite os dados que podemos coletar sobre os dados do usuário?
  • Para o diagnóstico de respostas insatisfatórias, temos visibilidade de todo o trabalho que foi feito para responder à pergunta? Mantemos um log de cada estágio no pipeline de inferência de entradas e saídas para que possamos realizar a análise de causa raiz?
  • Como fazer mudanças no sistema sem regressão ou degradação dos resultados?

Capturando e agindo sobre o feedback dos usuários

Como mencionado anteriormente, os desenvolvedores podem precisar trabalhar com a equipe de privacidade de sua organização para projetar mecanismos de captura de feedback e telemetria, registro em log etc. para habilitar a análise forense e de causa raiz em uma determinada sessão de consulta.

O próximo passo é desenvolver um pipeline de avaliação. A necessidade de um pipeline de avaliação surge da complexidade e da natureza demorada de analisar o feedback integral e as causas raiz das respostas fornecidas por um sistema de IA. Essa análise é crucial, pois envolve investigar cada resposta para entender como a consulta de IA produziu os resultados, verificar a adequação dos pedaços de conteúdo usados da documentação e as estratégias empregadas na divisão desses documentos.

Além disso, envolve considerar quaisquer etapas extras de pré ou pós-processamento que possam melhorar os resultados. Esse exame detalhado geralmente descobre lacunas de conteúdo, especialmente quando não existe documentação adequada em resposta à consulta de um usuário.

A construção de um pipeline de avaliação, portanto, torna-se essencial para gerenciar a escala dessas tarefas de forma eficaz. Um pipeline eficiente utilizaria ferramentas personalizadas para avaliar métricas que se aproximam da qualidade das respostas fornecidas pela IA. Esse sistema agilizaria o processo de determinar por que uma resposta específica foi dada à pergunta de um usuário, quais documentos foram usados para gerar essa resposta e a eficácia do pipeline de inferência que processa as consultas.

Conjunto de dados dourado

Uma estratégia para avaliar os resultados de um sistema não-determinístico como um sistema de bate-papo RAG é implementar um "conjunto de dados dourado". Um conjunto de dados dourado é um conjunto curado de perguntas com respostas aprovadas, metadados (como tópico e tipo de pergunta), referências a documentos de origem que podem servir como verdade fundamental para respostas e até variações (frases diferentes para capturar a diversidade de como os usuários podem fazer as mesmas perguntas).

O "conjunto de dados dourado" representa o "melhor cenário" e permite que os desenvolvedores avaliem o sistema para ver o desempenho dele e realizem testes de regressão ao implementar novos recursos ou atualizações.

Avaliação de danos

A modelagem de danos é uma metodologia que visa prever danos potenciais, identificar deficiências em um produto que possam representar riscos aos indivíduos e desenvolver estratégias proativas para mitigar tais riscos.

A ferramenta projetada para avaliar o impacto da tecnologia, particularmente os sistemas de IA, apresentaria vários componentes-chave com base nos princípios da modelagem de danos, conforme descrito nos recursos fornecidos.

Os principais recursos de uma ferramenta de avaliação de danos podem incluir:

  1. Identificação das partes interessadas: A ferramenta ajudaria os usuários a identificar e categorizar várias partes interessadas afetadas pela tecnologia, incluindo usuários diretos, partes afetadas indiretamente e outras entidades, como gerações futuras ou fatores não humanos, como preocupações ambientais (.

  2. Categorias e descrições de danos: incluiria uma lista abrangente de danos potenciais, como perda de privacidade, sofrimento emocional ou exploração econômica. A ferramenta pode guiar o usuário por vários cenários ilustrando como a tecnologia pode causar esses danos, ajudando a avaliar consequências intencionais e não intencionais.

  3. Avaliações de gravidade e probabilidade: A ferramenta permitiria que os usuários avaliassem a gravidade e a probabilidade de cada dano identificado, permitindo que eles priorizassem quais questões abordar primeiro. Isso pode incluir avaliações qualitativas e pode ser apoiado por dados, quando disponíveis.

  4. Estratégias de mitigação: Ao identificar e avaliar danos, a ferramenta sugeriria potenciais estratégias de mitigação. Isso pode incluir mudanças no design do sistema, mais salvaguardas ou soluções tecnológicas alternativas que minimizem os riscos identificados.

  5. Mecanismos de feedback: A ferramenta deve incorporar mecanismos de coleta de feedback das partes interessadas, garantindo que o processo de avaliação de danos seja dinâmico e responsivo a novas informações e perspectivas.

  6. Documentação e relatórios: Para ajudar na transparência e prestação de contas, a ferramenta facilitaria a criação de relatórios detalhados que documentam o processo de avaliação de danos, descobertas e ações tomadas para mitigar riscos potenciais.

Esses recursos não apenas ajudariam a identificar e mitigar riscos, mas também ajudariam a projetar sistemas de IA mais éticos e responsáveis, considerando um amplo espectro de impactos desde o início.

Para saber mais, veja:

Testando e verificando as salvaguardas

Este artigo descreveu vários processos destinados a mitigar a possibilidade de que o sistema de bate-papo baseado em RAG possa ser explorado ou comprometido. O red-teaming desempenha um papel crucial para garantir que as mitigações sejam eficazes. Red-teaming envolve simular as ações de um adversário destinadas ao aplicativo para descobrir possíveis fraquezas ou vulnerabilidades. Essa abordagem é especialmente vital para lidar com o risco significativo de jailbreaking.

Para testar e verificar efetivamente as salvaguardas de um sistema de bate-papo baseado em RAG, os desenvolvedores precisam avaliar rigorosamente esses sistemas em vários cenários em que essas diretrizes possam ser testadas. Isso não apenas garante robustez, mas também ajuda a ajustar as respostas do sistema para aderir estritamente aos padrões éticos e procedimentos operacionais definidos.

Considerações finais que podem influenciar suas decisões de design de aplicativo

Aqui está uma pequena lista de coisas a serem consideradas e outras conclusões deste artigo que afetam suas decisões de design de aplicativo:

  • Reconheça a natureza não determinista da IA generativa em seu projeto, planejando a variabilidade nos resultados e configurando mecanismos para garantir consistência e relevância nas respostas.
  • Avalie os benefícios do pré-processamento de prompts do usuário em relação ao potencial aumento na latência e nos custos. Simplificar ou modificar prompts antes do envio pode melhorar a qualidade da resposta, mas pode adicionar complexidade e tempo ao ciclo de resposta.
  • Investigue estratégias para paralelizar solicitações de LLM para melhorar o desempenho. Essa abordagem pode reduzir a latência, mas requer gerenciamento cuidadoso para evitar maior complexidade e possíveis implicações de custo.

Se você quiser começar a experimentar a criação de uma solução de IA generativa imediatamente, recomendamos dar uma olhada em Introdução ao bate-papo usando sua própria amostra de dados para Python. Há versões do tutorial também disponíveis em .NET, Java e JavaScript.