Compartilhar via


Desenvolvendo sistemas avançados de geração aumentada por 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 em 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 que descreve 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 inserção, 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 é chamada de "RAG ingênuo" e é uma maneira útil de entender primeiro os mecanismos, funções e responsabilidades necessários 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 chamado de "RAG avançado".

Diagrama exibindo o fluxo avançado de lógica RAG como uma série de caixas com setas entre elas. Existem 10 caixas que começam com a consulta do usuário. Em seguida, as etapas de processamento de consulta, depois uma chamada para a API de incorporação, depois a consulta resultante como um vetor, então o vetor é usado para consultar o banco de dados vetorial para encontrar a correspondência mais próxima, depois recuperado como partes de artigo, depois etapas de processamento pós-recuperação, então a consulta processada e as partes de artigo processadas são enviadas para a API de conclusão e, em seguida, as 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 forma:

  • 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 ponto de partida para exploração e pesquisa adicionais.

Ingestão

A ingestão 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 de cosseno. No entanto, isso é 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 isso, os desenvolvedores precisam considerar as seguintes etapas:

  • Pré-processamento e extração de conteúdo
  • Estratégia de agrupamento
  • Organização em partes
  • 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 fazer 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? Se não, 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
  • Lidar com caracteres especiais
  • Remover conteúdo não relacionado e desatualizado
  • Conta para conteúdo versionado
  • Considere 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 agrupamento

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 os pedaços após a recuperação. Esta é uma área em que os projetistas de sistemas devem fazer algumas pesquisas sobre as técnicas usadas na indústria e fazer algumas experimentações, até mesmo testando-as em uma capacidade limitada em sua organização.

Os desenvolvedores devem considerar:

  • Otimização do tamanho da parte - Determine qual é o tamanho ideal da parte e como designar uma parte. Por seção? Por parágrafo? Por frase?
  • Partes de janela sobrepostas e deslizantes - Determine como dividir o conteúdo em partes discretas. Ou os pedaços se sobreporão? Ou ambos (janela deslizante)?
  • Small2Big - Ao agrupar em um nível granular como uma única frase, o conteúdo será organizado de forma que seja fácil encontrar as frases vizinhas ou o parágrafo contido? (Consulte "Organização em partes".) Recuperar essas informações adicionais e fornecê-las ao LLM pode fornecer mais contexto ao responder à consulta do usuário.

Organização em partes

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) restringe rapidamente o espaço de pesquisa a um subconjunto de partes potencialmente relevantes, e um índice de segundo nível (índice de partes) 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 verificadas no índice detalhado, filtrando primeiro o índice de resumo.
  • Í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 grafos são úteis quando os chunks têm informações ou relacionamentos interconectados que podem aprimorar 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 as 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 aplicar 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 as relações entre partes dinamicamente durante a recuperação.

Otimização de alinhamento

Para aumentar a relevância e a precisão das partes recuperadas, alinhe-as estreitamente com os tipos de pergunta ou consulta que elas devem responder. Uma estratégia para conseguir isso é gerar e inserir uma pergunta hipotética para cada parte que represente qual pergunta a parte é mais adequada 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 das partes buscadas.
  • Dados de treinamento para modelos de aprendizado de máquina: esses pares de perguntas e partes 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 de consulta direta: Se uma consulta de usuário real corresponder a uma pergunta hipotética, o sistema poderá recuperar e usar rapidamente o bloco correspondente, acelerando o tempo de resposta.

A pergunta hipotética de cada parte atua como um "rótulo" que orienta o algoritmo de recuperação, tornando-o mais focado e contextualmente consciente. Isso é útil em cenários em que as partes abrangem uma ampla variedade 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 vetorial em tais sistemas:

  • Atualizações incrementais:
    • Intervalos regulares: agende atualizações em intervalos regulares (por exemplo, diariamente, semanalmente), dependendo da frequência das alterações de documentos. 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 disparam a reindexação. Por exemplo, qualquer modificação ou adição de um documento pode 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 alteradas. Essa abordagem 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:
    • Instantâneo: mantenha as versões do corpus de documentos em diferentes momentos. Essa técnica fornece um mecanismo de backup e permite que o sistema reverta ou faça referência a versões anteriores.
    • Controle de versão do documento: use um sistema de controle de versão para rastrear sistematicamente as alterações do documento para manter o histórico de alterações e simplificar o processo de atualização.
  • Atualizações em tempo real:
    • Processamento de fluxo: Quando a pontualidade das informações for crítica, utilize tecnologias de processamento de fluxo para atualizações de banco de dados vetoriais em tempo real à medida que as alterações no documento são feitas.
    • Consulta dinâmica: em vez de depender apenas de vetores pré-indexados, implemente um mecanismo de consulta de dados em tempo real para obter respostas atualizadas, possivelmente combinando com resultados armazenados em cache para eficiência.
  • Técnicas de otimização:
    • Processamento em lotes: o processo em lotes acumulou alterações para otimização de recursos e redução de sobrecarga em vez de atualizações frequentes.

    • Abordagens híbridas: Combine várias estratégias, como:

      • Usar atualizações incrementais para pequenas alterações.
      • Reindexação completa para atualizações importantes.
      • Documente as mudanças estruturais do corpus.

A escolha da estratégia de atualização correta ou de uma combinação depende de requisitos específicos, como:

  • Tamanho do corpus do documento.

  • Frequência de atualização.

  • Necessidades de dados em tempo real.

  • Disponibilidade de recursos.

  • Avalie esses fatores com base nas necessidades específicas do aplicativo, pois cada abordagem tem compensações de complexidade, custo e latência de atualização.

Pipeline de inferência

Agora que os artigos são fragmentados, vetorizados e armazenados em um banco de dados vetorial, o foco se volta para os desafios de 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 reescrevemos 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 as partes do artigo estejam alinhadas à 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 garantimos 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 consideração, principalmente na forma de:

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

Todo o pipeline de inferência está sendo executado em tempo real. Embora não haja uma maneira certa para o design da etapa de pré e pós-processamento, é provável que seja uma combinação de lógica de programação e outras chamadas LLM. Uma das considerações mais importantes é 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 identificar estratégias específicas em cada etapa.

Etapas de pré-processamento de consulta

O pré-processamento de consulta ocorre imediatamente após o usuário enviar sua consulta, conforme ilustrado neste diagrama:

Diagrama que repete as etapas avançadas do RAG com ênfase na caixa rotulada etapas de processamento de consulta.

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

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

Reescrita de consulta - Esta etapa pode ser qualquer coisa, desde expandir acrônimos 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 ("solicitação de retrocesso").

Uma variação da solicitação de retrocesso são as incorporações de documentos hipotéticos (HyDE) que usam o LLM para responder à pergunta do usuário, criam uma incorporação para essa resposta (a incorporação de documentos hipotéticos) e usam essa incorporação para realizar uma pesquisa no banco de dados vetorial.

Subconsultas

Essa 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, uma pergunta sobre descobertas científicas em física pode ser: "Quem fez contribuições mais significativas para a física moderna, Albert Einstein ou Niels Bohr?"

Dividir consultas complexas em subconsultas as torna mais gerenciáveis:

  1. Subpergunta 1: "Quais são as principais contribuições de Albert Einstein para a física moderna?"
  2. Subpergunta 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 em mecânica quântica e seu princípio de complementaridade.

Uma vez que essas contribuições são descritas, elas podem ser avaliadas para determinar:

  1. Subpergunta 3: "Como as teorias de Einstein impactaram o desenvolvimento da física moderna?"

  2. Subpergunta 4: "Como as teorias de Bohr impactaram o desenvolvimento da física moderna?"

Essas subconsultas exploram a influência de cada cientista na física, como:

  • Como as teorias de Einstein levaram a avanços na cosmologia e na teoria quântica
  • 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 em 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 essas descobertas 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 de vetores 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 principal função 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 a uma consulta específica.

O roteador de consulta normalmente funciona em um ponto depois que o usuário formula a consulta, mas antes de enviar para sistemas de recuperação. Aqui está um fluxo de trabalho simplificado:

  1. Análise de consulta: o LLM ou outro componente analisa a consulta recebida 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 vários índices potencialmente 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. Expedição de consulta: a consulta é então expedida para o índice selecionado.
  4. Agregação de resultados: as respostas dos índices selecionados são recuperadas e possivelmente agregadas ou processadas posteriormente 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 várias fontes.

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

  • Especialização do tipo de dados: Alguns índices podem se especializar em artigos de notícias, outros em trabalhos 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 jurídicas.
  • Otimização do tipo de consulta: determinados índices podem ser otimizados para pesquisas factuais rápidas (por exemplo, datas, eventos), enquanto outros podem ser melhores para tarefas de raciocínio complexas ou consultas que exigem profundo conhecimento do domínio.
  • Diferenças algorítmicas: Diferentes algoritmos de recuperação podem ser usados em diferentes mecanismos, como pesquisas de similaridade baseadas em vetores, 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 consultoria médica. 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 poderá priorizar o índice de artigos 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 geral de saúde pode ser escolhido por seu conteúdo amplo e facilmente compreensível.

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 ilustrado no diagrama:

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

Com as partes de conteúdo candidatas recuperadas, as próximas etapas são validar a utilidade da parte do artigo ao aumentar o prompt do LLM antes de preparar o prompt a ser apresentado ao LLM.

Os desenvolvedores devem considerar vários aspectos imediatos:

  • Incluir muitas informações suplementares pode resultar em ignorar as informações mais importantes.
  • A inclusão de informações irrelevantes pode influenciar negativamente a resposta.

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

Por fim, 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 as partes do artigo retornadas 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 artigos recuperados do repositório de vetores para garantir que os detalhes relevantes estejam próximos às bordas (início e fim) do prompt.
  • Compactação de prompt - Use um modelo pequeno e barato para compactar e resumir vários blocos de artigos em um único prompt compactado antes de enviar para o LLM.

Etapas de processamento pós-conclusão

O processamento pós-conclusão ocorre após a consulta do usuário e todas as partes de conteúdo são enviadas para o LLM, conforme ilustrado no diagrama a seguir:

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

A validação da precisão ocorre após a conclusão imediata pelo LLM. Um pipeline de processamento pós-conclusão pode incluir as seguintes etapas:

  • Verificação de fatos - A intenção é identificar alegações específicas feitas no artigo que são apresentadas como fatos e, em seguida, verificar a precisão desses fatos. Se a etapa de verificação de fatos falhar, pode ser apropriado repetir a consulta do LLM na esperança de uma resposta melhor ou retornar uma mensagem de erro ao usuário.
  • Verificação de política – 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. Há 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 às suas perguntas?
  • Como capturamos o feedback do usuário? Temos alguma política em vigor que limita 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 necessário para responder à pergunta? Mantemos um registro 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 podemos fazer alterações no sistema sem regressão ou degradação dos resultados?

Capturando e agindo de acordo com o feedback dos usuários

Conforme mencionado anteriormente, os desenvolvedores podem precisar trabalhar com a equipe de privacidade de sua organização para projetar mecanismos de captura de comentários 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 da análise literal do feedback literal e das causas raiz das respostas fornecidas por um sistema de IA. Essa análise é crucial, pois envolve investigar todas as respostas para entender como a consulta de IA produziu os resultados, verificando a adequação dos blocos de conteúdo usados na 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 revela lacunas de conteúdo, principalmente 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 simplificaria 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 RAG-chat é implementar um "conjunto de dados dourado". Um conjunto de dados dourado é um conjunto selecionado de perguntas com respostas aprovadas, metadados (como tópico e tipo de pergunta), referências a documentos de origem que podem servir como verdade 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 dos danos

A modelagem de danos é uma metodologia que visa prever danos potenciais, detectar deficiências em um produto que possam representar riscos para os indivíduos e desenvolver estratégias proativas para mitigar esses 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 de 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 indiretamente afetadas 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 que ilustram como a tecnologia pode causar esses danos, ajudando a avaliar as 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 problemas abordar primeiro. Os exemplos incluem avaliações qualitativas apoiadas por dados, quando disponíveis.

  4. Estratégias de mitigação: A ferramenta sugere possíveis estratégias de mitigação após identificar e avaliar os danos. Os exemplos incluem mudanças no design do sistema, mais salvaguardas ou soluções tecnológicas alternativas que minimizam os riscos identificados.

  5. Mecanismos de feedback: A ferramenta deve incorporar mecanismos para coletar 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 transparência e responsabilidade, a ferramenta pode facilitar relatórios detalhados que documentam o processo de avaliação de danos, descobertas e possíveis ações de mitigação de risco tomadas.

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:

Testar e verificar 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. A equipe vermelha desempenha um papel crucial para garantir que as mitigações sejam eficazes. A equipe vermelha envolve a simulação das ações de um adversário voltadas para o aplicativo para descobrir possíveis pontos fracos ou vulnerabilidades. Essa abordagem é especialmente vital para lidar com o risco significativo de jailbreak.

Os desenvolvedores precisam avaliar rigorosamente as proteções do sistema de bate-papo baseado em RAG em vários cenários de diretrizes para testá-las e verificá-las com eficácia. 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 aplicativos

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

  • Reconheça a natureza não determinística da IA generativa em seu design, 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 possível 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 um gerenciamento cuidadoso para evitar o aumento da 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 chat usando seu próprio exemplo de dados para Python. Existem versões do tutorial também disponíveis em .NET, Java e JavaScript.