Há muitas perguntas que se podem ter sobre uma solução RAG:

• Como devemos determinar as escolhas de projeto que maximizam o desempenho da recuperação?
• Como sabemos qual modelo de embedding cria a melhor representação vetorial de nossos documentos?
• É necessária uma abordagem agêntica?
• Um sistema de reclassificação melhoraria nossos resultados? Ou talvez essas escolhas de parâmetros tenham um impacto secundário?

Ter uma estratégia de avaliação clara durante todo o desenvolvimento de uma solução baseada em RAG é crucial para garantir um caminho bem-sucedido para a produção. Vemos todos os tipos de avaliações empíricas realizadas durante pilotos que às vezes não são reproduzíveis. Para melhorar o desempenho de uma solução baseada em RAG em desenvolvimento ou diagnosticar adequadamente um problema em produção, as tarefas de avaliação devem ser reproduzíveis e rápidas de executar. Os pipelines de RAG devem ser avaliados de forma sistemática e consistente para componentes de recuperação e geração.

A compreensão do desempenho da solução baseada em RAG desempenha um papel crítico em várias etapas do ciclo de vida da solução durante:

• Fase de experimento e ajuste
• Fase de monitoramento

No entanto, o esforço para construir um mecanismo de avaliação não deve ser subestimado, especialmente quando se trata de criar um conjunto de dados valioso (verdade absoluta) com respostas de referência e contextos de referência.

Neste documento, discutiremos diferentes abordagens e métricas de avaliação, além de destacar alguns dos ativos reutilizáveis que estão disponíveis para facilitar a avaliação dessas soluções.

IA Avaliando a IA

O LLMaaJ (LLM como juiz) surgiu como uma métrica líder no último ano para superar o desafio de construir um mecanismo de avaliação baseado em referência. Foi demonstrado que essa técnica de avaliação produz uma correlação decente com o julgamento humano. Aqui estão várias propriedades que não podem ser quantificadas por métricas e benchmarks existentes, mas que podem ser avaliadas pelo LLMaaJ:

• Segurança – Os modelos estão gerando conteúdo prejudicial ou inseguro?
• Fundamentação – No caso de sumarização e geração aumentada de recuperação, a saída gerada é fundamentada em fatos presentes no contexto de entrada?
• Sentimento – As respostas geradas são geralmente positivas, negativas ou algum outro sentimento prescrito?
• Toxicidade – Os modelos estão gerando conteúdo ofensivo, agressivo ou discriminatório?
• Estilo de idioma – Os modelos estão falando em uma voz casual, formal ou comum? Isso inclui avaliar sarcasmo, humor e ironia.

Por exemplo, ao usar um modelo de pontuação para avaliar a saída de outros modelos, o prompt de pontuação deve conter uma descrição dos atributos a serem pontuados e a escala de classificação, e deve ser interpolado para incluir a resposta a ser avaliada.

Neste exemplo, pede-se que o modelo avalie o estilo de linguagem da resposta e retorne uma classificação.

Você é um juiz de pontuação justo e sem viés. Você será solicitado a classificar a resposta de um chatbot de acordo com seu sentimento. Avalie a resposta abaixo e extraia a classe correspondente. As classes possíveis são POSITIVA, NEUTRA, NEGATIVA. Explique seu raciocínio e conclua afirmando o sentimento classificado.
{{response}}

Ou, por exemplo, abaixo está um exemplo de prompt few-shot de avaliação orientada por LLM para tarefas de NER (named-entity recognition).

-----------------------------------prompt---------------------------------------------
Você é um avaliador profissional e sua tarefa é avaliar a precisão da extração de entidades como um Score em um determinado texto. Você receberá um texto, uma entidade e o valor da entidade.
Forneça uma pontuação numérica em uma escala de 0 a 1, em que 1 é a melhor pontuação e 0 é a pior pontuação. Use estritamente valores numéricos para pontuação.

Aqui estão os exemplos:

Texto: Onde fica o escritório da IBM em Nova York?
Entidade: nome da organização
Valor: Pontuação da
IBM: 0

Texto: Ligue para o atendimento ao cliente em 1-800-555-1234 para receber assistência.
Entidade: número de telefone
Valor: +1 888 426 4409
Pontuação: 1

Texto: o watsonx tem três componentes: watsonx.ai, watsonx.data, e watsonx.governance.
Entidade: nome do produto
Valor: Pontuação do
Google: 0,33

Texto: A conferência está agendada para 15 de agosto de 2024.
Entidade: data Valor: 15 de agosto de 2024 Pontuação: 1 Texto: Meus colegas John e Alice participarão da reunião.
Entidade: nome da pessoa
Valor:
Alice Pontuação:

1 -----------------------------------Produção---------------------------------------------Pontuação: 0.67
--------------------------------------------------------------------------------------

A complexidade dos sistemas RAG é significativamente influenciada pela natureza enigmática dos grandes modelos de linguagem (LLMs), bem como pelos componentes intrincados e interconectados dentro do pipeline RAG. Com o avanço da tecnologia em um ritmo sem precedentes, avaliar um sistema tão complexo torna-se uma tarefa cada vez mais árdua. Para lidar com esse desafio, uma infinidade de benchmarks e ferramentas de avaliação foi desenvolvida especificamente para sistemas RAG. Esses recursos servem para fornecer uma abordagem padronizada e sistemática para avaliar o desempenho e a eficácia desses sistemas.

Por exemplo, como ilustrado na tabela abaixo (adaptada de “Avaliação da Geração Aumentada por Recuperação: Uma Pesquisa”).), existe uma gama diversificada de métodos e ferramentas de avaliação RAG, cada um com seus pontos fortes e aplicações exclusivos. Essa tabela, que não é exaustiva, serve para fornecer uma visão geral sucinta do cenário atual da avaliação da RAG.

No contexto do componente de recuperação dos sistemas RAG, surgem vários desafios,

Em termos do componente de recuperação, os desafios surgem principalmente devido à natureza extensa e dinâmica dos repositórios de conhecimento prospectivo, às facetas temporais dos dados e à heterogeneidade das fontes de informações. Considerando esses desafios, fica evidente que as métricas de avaliação convencionais, como Recall e Precision, são inadequadas e mal preparadas para fornecer uma avaliação abrangente. Em vez disso, há uma necessidade de métricas mais diferenciadas e dependentes do contexto que possam capturar efetivamente as complexidades e sutilezas do processo de recuperação.

Em relação ao componente de geração, é crucial considerar a intrincada relação entre a precisão do processo de recuperação e a qualidade da saída gerada. Isso exige o desenvolvimento e a implementação de métricas de avaliação abrangentes que possam fornecer uma avaliação holística e diferenciada do desempenho do sistema.

Por sua vez, a avaliação do sistema RAG como um todo requer um exame minucioso do impacto do componente de recuperação no processo de geração, bem como uma avaliação da eficácia e eficácia geral do sistema em alcançar suas metas e objetivos pretendidos.

A tríade RAG é um framework para avaliar a confiabilidade e a precisão contextual das respostas do Grande Modelo de Linguagem (LLM). Consiste em três avaliações: relevância do contexto, fundamentação e relevância da resposta. Essas avaliações visam identificar alucinações de resposta do LLM verificando a relevância do contexto, a confiabilidade da resposta ao contexto e o alinhamento da resposta com as perguntas do usuário.

A avaliação RAG pode ser alcançada usando métricas automáticas baseadas em referências e sem referências. Existe um ranking no HuggingFace. que analisa o desempenho das LLMs de código aberto umas em relação às outras.

Métricas de Recuperação

As métricas de recuperação abaixo são baseadas em referência, o que significa que cada fragmento deve ser identificado exclusivamente (contexts_id) e cada pergunta tem IDs exclusivos dos contextos de verdade fundamental.

As métricas de avaliação conscientes de classificação usadas para sistemas de recomendação são apropriadas para a RAG.

MRR (Classificação Recíproca Média)

O MRR é usado no Unitxt e mede a posição do primeiro documento relevante nos resultados da pesquisa. Um MRR mais alto, próximo de 1, indica que os resultados relevantes aparecem perto do topo, refletindo a alta qualidade das pesquisas. Por outro lado, um MRR mais baixo significa um desempenho de pesquisa mais baixo, com respostas relevantes posicionadas mais abaixo nos resultados.

Prós: enfatiza a importância do primeiro resultado relevante, que geralmente é crítico em cenários de pesquisa.
Contras: uma limitação é que não penaliza a recuperação por atribuir baixa classificação a outras verdades básicas; Não é adequado para avaliar toda a lista de resultados recuperados, com foco apenas no primeiro item relevante.

NDCG (ganho cumulativo descontado normalizado)

Uma métrica de qualidade de classificação que avalia a qualidade da ordenação de uma lista de itens em comparação com uma classificação ideal, em que todos os itens relevantes são posicionados no topo.

O NDCG@k é calculado como DCG@k dividido pelo DCG@k ideal (IDCG@k), que representa a pontuação de uma lista de itens perfeitamente classificada até a posição k. O DCG mede a relevância total dos itens em uma lista.

varia de 0 a 1

Prós: leva em conta a posição dos itens relevantes, fornecendo uma visão mais holística da qualidade do ranking; Pode ser ajustado para diferentes níveis de classificação (por exemplo, NDCG@k).
Contras: mais complexo para calcular e interpretar em comparação com métricas mais simples como MRR; Requer uma classificação ideal para comparação, que nem sempre está disponível ou é fácil de definir.

MAP (precisão média)

A precisão média média (MAP) é uma métrica que avalia a classificação de cada documento recuperado corretamente em uma lista de resultados

É benéfico quando seu sistema precisa considerar a ordem dos resultados e recuperar vários documentos em uma única execução.

Prós: considera tanto a precisão quanto o recall, fornecendo uma avaliação equilibrada do desempenho de recuperação; Adequado para tarefas que exigem vários documentos relevantes e sua ordem correta.
Contras: pode ser mais exigente em termos de computação em comparação com métricas mais simples; Pode não ser tão simples de interpretar quanto outras métricas, exigindo mais contexto para entender os resultados completamente.

Métricas de Geração

Fidelidade

Mede se a saída é baseada no contexto fornecido ou se o modelo gera respostas alucinadas.

Prós: garante que as respostas geradas sejam confiáveis e baseadas no contexto fornecido; Vital para aplicações em que a exatidão factual é fundamental.
Contras: geralmente requer o julgamento humano para avaliar, tornando-o trabalhoso e subjetivo; Pode não capturar totalmente imprecisões parciais ou alucinações sutis.

Robustez (insensibilidade)

A robustez é geralmente definida como o rrecurso da solução de se adaptar a diferentes variações de entrada, como perturbações de dados como espaço em branco, letras minúsculas/maiúsculas, tabs etc.

Testar robustez é um aspecto importante do processo de avaliação e pode ser alcançado, por exemplo, usando a semântica Unitxt

Prós: Garante que o modelo funcione de forma confiável em diversas condições de entrada; Aplicabilidade no mundo real: importante para aplicações práticas, onde os dados de entrada podem não ser perfeitamente formatados.
Contras: requer testes completos em diversas variações, o que pode ser demorado; Definição de variações: desafio para definir e medir todas as possíveis perturbações de entrada.

ROUGE (Recall-Oriented Understudy for Gisting Evaluation)

Ela mede a qualidade da geração de texto comparando a sobreposição de n-gramas, sequências de palavras e pares de palavras entre o texto gerado por máquina e um conjunto de textos de referência. Amplamente usada para avaliar tarefas como resumo e tradução de texto.

Prós: estabelecido e reconhecido na comunidade de PLN, proporcionando um padrão para comparação; Adequado para tarefas em que é importante capturar todas as informações relevantes.
Concentra-se na sobreposição de n-grams, que pode não capturar qualidade semântica ou fluência; Pode ser influenciado pelo tamanho do texto gerado, podendo penalizar saídas mais curtas ou mais concisas.

BLEU (Bilingual Evaluation Understudy)

Ela mede a qualidade do texto traduzido automaticamente comparando-o com uma ou mais traduções de referência. Avalia a precisão de n-gramas no texto gerado em relação aos textos de referência. Usada principalmente para avaliar traduções.

Prós: eficaz para tarefas onde a precisão e as correspondências exatas são importantes; Métrica padrão: amplamente adotada na comunidade de tradução automática, fornecendo uma referência para comparação.
Contras: pode penalizar variações legítimas em frases que não correspondem exatamente aos textos de referência; Cegueira parcial da imprecisão: pode não capturar totalmente imprecisões parciais ou diferenças sutis de significado.

Métricas de custo

Utilização de GPU/CPU

A utilização da CPU é usada principalmente para a fase de recuperação, e a utilização da GPU é usada principalmente para a fase de geração.

Custo das chamadas do LLM

Exemplo: custo de chamadas de API da OpenAI

Custo de infraestrutura

Os custos de armazenamento, rede, recursos de computação etc.

Custo de operação

Os custos de manutenção, suporte, monitoramento, registro, medidas de segurança etc.

Compreensão dos resultados da avaliação

Se as métricas de recuperação indicarem um desempenho abaixo do ideal, mas as métricas de geração produzirem resultados favoráveis, é aconselhável: 

1. Reavalie e ajuste a estratégia de fragmentação (por exemplo, tamanho dos fragmentos e sobreposição) para equilibrar melhor o contexto e a relevância.
2. Limpe e pré-processe os dados para remover ruídos e informações irrelevantes.
3. Adicione metadados, como datas, a fragmentos para ajudar a filtrar e priorizar dados com base em casos de uso específicos.
4. Implementação a reclassificação: isso permite que seu sistema de recuperação refine os nós superiores para contexto. Tanto o * LangChain quanto o LlamaIndex oferecem abstrações fáceis de usar para reclassificação.
5. Faça com que o LLM reformule a consulta e tente novamente, pois perguntas semelhantes para humanos podem não parecer semelhantes no espaço de embedding.
6. Ajuste fino as embeddings com o LlamaIndex para melhorar a precisão.

Por outro lado, se as métricas de recuperação demonstrarem um forte desempenho, mas os resultados da geração estiverem abaixo do ideal, considere as seguintes estratégias para melhorar o desempenho do modelo:

1. Ajuste fino do modelo de linguagem: personalize o modelo de acordo com seu domínio, ajustando-o em conjuntos de dados relevantes para aumentar sua precisão e compreensão contextual.
2. Refine a engenharia de prompts: experimente a estrutura e o texto do prompt para orientar o modelo em direção a produções mais precisas.
3. Use diferentes estratégias de decodificação: ajuste técnicas de decodificação como pesquisa de feixe, amostragem top-k ou amostragem de núcleo (top-p) para melhorar a qualidade das respostas geradas.
4. Controle o comprimento da geração: defina restrições para o comprimento da resposta para garantir que as saídas sejam concisas e precisas.
5. Incorpore ciclos de feedback: implemente um sistema que identifique e corrija respostas abaixo do ideal, permitindo a melhoria contínua.
6. Aproveite o diálogo de várias tentativas: divida tarefas complexas em interações de várias etapas, permitindo que o modelo refine suas respostas em várias iterações.

No cenário em que as métricas de recuperação e geração apresentam desempenho abaixo do ideal, seria prudente rever e reconsiderar os estágios iniciais do pipeline, como aprimorar os metadados, refinar a base de conhecimento e otimizar o mecanismo de recuperação.

Essa abordagem enfatiza a importância de uma avaliação abrangente e diferenciada do sistema de RAG, levando em conta a interação entre os componentes de recuperação e geração e a eficácia geral do sistema em alcançar suas metas e objetivos pretendidos.