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.

Esta representação é 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".

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 as seguintes etapas:

• 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 aplicar 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, alinhe-as de perto com a pergunta ou os tipos de consulta 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 age como um "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 reindexação de todo o banco de dados, atualize seletivamente apenas as partes alteradas do corpus. 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:
  • Snapshotting: Mantenha versões do corpus de documentos em diferentes momentos no tempo. Esta 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 controlar 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 de documentos são feitas.
  • Consulta em tempo real: em vez de depender apenas de vetores pré-indexados, implemente um mecanismo de consulta de dados em tempo real para respostas atualizadas, possivelmente combinando com resultados armazenados em cache para eficiência.
• Técnicas de otimização:

  • Processamento em lote: Alterações acumuladas no processo em lote para otimização de recursos e redução de despesas gerais em vez de atualizações frequentes.

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

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

A escolha da estratégia de atualização certa ou de uma combinação depende de requisitos específicos, tais 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 complexidade, custo e compromissos de 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 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

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, 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 identificar estratégias específicas em cada etapa.

Etapas de pré-processamento de consultas

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

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 localize os melhores pedaços de artigo possíveis usando a pesquisa cosseno similaridade / "vizinho mais próximo".

Verificação de política - Esta etapa envolve a 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". 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 - Esta etapa 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, uma pergunta sobre descobertas científicas na física pode ser: "Quem fez contribuições mais significativas para a física moderna, Albert Einstein ou Niels Bohr?"

A divisão de consultas complexas em subconsultas as torna mais gerenciáveis:

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:

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

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

Estas subconsultas exploram a influência de cada cientista na física, tais 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 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 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 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:

Com os blocos de conteúdo candidato recuperados, as próximas etapas são validar a utilidade do bloco de artigo ao aumentar o prompt do LLM antes de preparar o prompt a ser apresentado ao LLM.

Os desenvolvedores devem considerar vários aspetos imediatos:

• Incluir demasiada informação complementar pode resultar em ignorar a informação mais importante.
• a inclusão de informações irrelevantes pode influenciar negativamente 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.
• Compressão rápida - Use um modelo pequeno e barato para compactar e resumir vários blocos de artigo 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 todos os blocos de conteúdo são enviados para o LLM, conforme descrito no diagrama a seguir:

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 factos - A intenção é identificar alegaçõ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 - 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 como, digamos, testes de unidade ou 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. Os exemplos incluem avaliações qualitativas apoiadas por dados, quando disponíveis.

4. Estratégias de mitigação: A ferramenta sugere potenciais estratégias de mitigação após identificar e avaliar danos. Os exemplos incluem 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 transparência e prestação de contas, 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 riscos tomadas.

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:

• Fundamentos da avaliação de danos
• Tipos de danos

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.

Os desenvolvedores precisam avaliar rigorosamente as proteções do sistema de chat baseado em RAG sob vários cenários de diretriz para testá-las e verificá-las de forma eficaz. 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.