Construção de 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 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 a 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 encontrar 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 para o usuário.

Esta representação tem sido referida como "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 RAG avançado 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, em seguida, uma chamada para a API de incorporação, em seguida, 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 blocos de artigo processados são enviados 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 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 um 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 tal 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 através de incorporações vetorizadas e uma pesquisa de semelhança de 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 vetoriais).

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, a que tipo de perguntas poderão os documentos 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 para o LLM para responder à consulta do usuário com precisão. Além disso, os desenvolvedores precisam considerar como utilizar os blocos 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 secção? Por parágrafo? Por sentença?
  • Blocos de janela sobrepostos e deslizantes - Determine como dividir o conteúdo em partes discretas. Ou os pedaços se sobreporão? Ou ambos (janela deslizante)?
  • 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 contendo 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 - Esta abordagem envolve a criação de várias camadas de índices, onde um índice de nível superior (índice de resumo) reduz rapidamente o espaço de pesquisa a um subconjunto de partes 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 verificadas no índice detalhado, filtrando primeiro pelo í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 partes. Por exemplo:
    • Os índices baseados em gráficos são úteis quando os blocos têm informações interconectadas ou relações 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 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 alavancar os pontos fortes de cada um. 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 aumentar 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 parte que representa qual pergunta a parte é mais adequada para responder. Isso ajuda de várias maneiras:

  • Correspondência melhorada: 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 obtidas.
  • 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 respondidos por quais partes.
  • Tratamento direto de consultas: Se uma consulta de usuário real corresponder a uma pergunta hipotética, o sistema pode recuperar e usar rapidamente a parte correspondente, acelerando o tempo de resposta.

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

Estratégias de atualização

Se sua organização precisa 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 realizar 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 acionem a reindexação. Por exemplo, qualquer modificação ou adição de um documento pode iniciar automaticamente uma reindexação das secçõ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 de documentos em diferentes momentos. 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 em tempo real 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 de documentos.

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 de documentos, 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 utilizador viola alguma das 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 vetoriais?
  • Como avaliamos os resultados da consulta para garantir que os blocos do 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 garantimos que a resposta do LLM está em conformidade com as nossas políticas?

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

  • Pré-processamento de entradas para otimizar a probabilidade de obter os resultados desejados
  • Saídas 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 compromisso 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 na caixa rotulada como etapas de processamento de consulta.

O objetivo dessas etapas é certificar-se de que o usuário está 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 irá localizar os melhores pedaços de artigo possíveis usando a semelhança cosseno / pesquisa "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 pessoalmente identificáveis, 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 de segurança, éticas ou operacionais internas do modelo.

Reescrita de consultas - 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 na solicitação de passo atrás é 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 realizar 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 com 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?"

Esta consulta pode ser complexa de tratar diretamente porque as "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, estas contribuições 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 subconsultas explorariam a influência do trabalho de cada cientista no campo, 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 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 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 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 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 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 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. 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 posteriormente para formar uma resposta abrangente.
  5. Geração de respostas: A etapa final envolve gerar 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 por Tipo de Dados: Alguns índices podem especializar-se em artigos noticiosos, outros em artigos académicos e ainda outros em conteúdos web gerais ou bases de dados específicas, como as de informação médica ou jurídica.
  • Otimização do tipo de consulta: certos í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 conhecimento profundo do domínio.
  • Diferenças algorítmicas: Diferentes algoritmos de recuperação podem ser usados em diferentes mecanismos, como pesquisas de semelhança 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 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 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 descrito no diagrama:

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

Com os blocos de conteúdo candidato 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 aspetos do prompt. Um prompt que inclui muitas informações de suplemento e algumas (possivelmente as informações mais importantes) podem ser ignoradas. Da mesma forma, um aviso que inclua informações irrelevantes pode afetar indevidamente a resposta.

Outra consideração é a agulha em um problema de 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 tem 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 artigos recuperados do repositório de vetores para garantir que os detalhes relevantes vivam perto das bordas (início e fim) do prompt.
  • Compactação rápida - 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 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 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 como etapas de processamento pós-conclusão.

Uma vez que o prompt tenha sido 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 factos - Pode assumir muitas formas, mas a intenção é identificar afirmações específicas feitas no artigo que são apresentadas como factos e, em seguida, verificar a exatidão desses factos. Se a etapa de verificação de fatos falhar, pode ser apropriado consultar novamente o LLM na esperança de uma resposta melhor ou retornar uma mensagem de erro para o usuário.
  • Verificação de políticas - Esta é a última linha de defesa para garantir que as respostas não contenham conteúdo nocivo, 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 de integração com os quais a maioria dos desenvolvedores está familiarizada. Existem vários fatores a considerar:

  • Os utilizadores estão satisfeitos com os resultados que estão a obter?
  • Os usuários estão recebendo respostas precisas às suas perguntas?
  • Como captamos o feedback dos utilizadores? 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 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?

Captar e agir com base no feedback dos utilizadores

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, 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 do feedback literal e das causas profundas 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 blocos de conteúdo usados a partir da documentação e as estratégias empregadas na divisão desses documentos.

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

Por conseguinte, a criação de uma reserva de avaliação torna-se essencial para gerir eficazmente a escala destas tarefas. 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 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 de base para as respostas e até variações (diferentes fraseados 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 seu desempenho 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, detetar deficiências em um produto que possam representar riscos para os 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 de modelagem de danos, conforme descrito nos recursos fornecidos.

As principais características 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 através de vários cenários ilustrando 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 aos usuários avaliar a gravidade e a probabilidade de cada dano identificado, permitindo que eles priorizassem quais questões abordar primeiro. Tal poderá incluir avaliações qualitativas e poderá 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. Tal poderá incluir alterações na conceção 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 recolha de feedback das partes interessadas, garantindo que o processo de avaliação de danos é dinâmico e reativo a novas informações e perspetivas.

  6. Documentação e relatórios: Para ajudar na transparência e responsabilização, 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 só 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 obter mais informações, consulte:

Testar e verificar as salvaguardas

Este artigo descreveu vários processos destinados a mitigar a possibilidade de que o sistema de chat baseado em RAG pudesse 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 potenciais fraquezas ou vulnerabilidades. Esta abordagem é especialmente vital para lidar com o risco significativo de jailbreaking.

Para testar e verificar efetivamente as salvaguardas de um sistema de chat baseado em RAG, os desenvolvedores precisam avaliar rigorosamente esses sistemas em vários cenários onde essas diretrizes podem ser testadas. Isso não só 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 as decisões de design do aplicativo

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

  • Reconheça a natureza não determinística 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 da latência e dos 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 LLM para melhorar o desempenho. Esta abordagem pode reduzir a latência, mas requer uma gestão cuidadosa para evitar o aumento da complexidade e potenciais implicações em termos de custos.

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.