Avaliação da relevância de busca - parte 1: o benchmark BEIR

Conecte-se perfeitamente com as principais plataformas de IA e machine learning. Inicie um teste gratuito na nuvem para explorar os recursos de IA generativa da Elastic ou experimente agora mesmo em sua máquina.

Este é o primeiro de uma série de posts que discutem como pensar a avaliação dos seus próprios sistemas de busca a partir de uma compreensão mais aprofundada do benchmark BEIR. Vamos apresentar dicas e técnicas específicas para melhorar os processos de avaliação de busca nesse contexto. Também destacaremos armadilhas comuns que tornam a avaliação menos confiável. Por fim, observamos que os LLMs oferecem uma nova e poderosa ferramenta no arsenal de engenheiros de busca e mostraremos, com exemplos, como usá-los para auxiliar na avaliação de busca.

Entendendo o benchmark BEIR na avaliação de relevância de busca

Para melhorar qualquer sistema, é preciso conseguir medir o quão bem ele está funcionando. No contexto de busca, o BEIR (ou, de forma equivalente, a seção de recuperação da tabela de classificação do MTEB) é considerado o “santo graal” pela comunidade de recuperação de informação, e isso não é por acaso. Trata-se de um benchmark muito bem estruturado, com conjuntos de dados variados que abrangem diferentes tarefas. Mais especificamente, as seguintes áreas são contempladas:

• Recuperação de argumentos (ArguAna, Touche2020)
• QA de domínio aberto (HotpotQA, Natural Questions, FiQA)
• Recuperação de passagens (MSMARCO)
• Recuperação de perguntas duplicadas (Quora, CQADupstack)
• Verificação de fatos (FEVER, Climate-FEVER, Scifact)
• Recuperação de informações biomédicas (TREC-COVID, NFCorpus, BioASQ)
• Recuperação de entidades (DBPedia)
• Previsão de citações (SCIDOCS)

O benchmark fornece uma única métrica, nDCG@10, relacionada a quão bem um sistema corresponde aos documentos mais relevantes para cada exemplo de tarefa entre os principais resultados retornados. Para um sistema de busca com o qual pessoas interagem, a relevância dos primeiros resultados é fundamental. No entanto, existem muitas nuances na avaliação de busca que uma única métrica resumida não consegue capturar.

Estrutura de um conjunto de dados BEIR

Cada benchmark é composto por três artefatos:

• o corpus, ou seja, os documentos a serem recuperados
• as consultas
• Os julgamentos de relevância para as consultas (também conhecidos como qrels).

Os julgamentos de relevância são fornecidos como uma pontuação igual ou maior que zero. Pontuações diferentes de zero indicam que o documento tem alguma relação com a consulta.

Tabela 1: Estatísticas dos conjuntos de dados. Os números foram calculados com base na porção de teste dos conjuntos de dados (dev para MSMARCO).

A Tabela 1 apresenta algumas estatísticas dos conjuntos de dados que compõem o benchmark BEIR, como o número de documentos no corpus, o número de consultas no conjunto de teste e o número de pares positivos/negativos (consulta, documento) no arquivo qrels. Com uma análise rápida dos dados, é possível inferir imediatamente o seguinte:

• maioria dos conjuntos de dados não contém relações negativas no arquivo qrels, ou seja, pontuações zero que indicariam explicitamente que um documento é irrelevante para determinada consulta.
• O número médio de relações entre documentos por consulta (#qrels / #queries) varia de 1,0 no caso de ArguAna até 493,5 (TREC-COVID), mas fica em torno de <5 na maioria dos casos.
• Alguns conjuntos de dados apresentam documentos duplicados no corpus, o que em certos casos pode levar a avaliações incorretas, por exemplo quando um documento é considerado relevante para uma consulta, mas seu duplicado não é. Como exemplo, em ArguAna, identificamos 96 casos de pares de documentos duplicados em que apenas um documento do par foi marcado como relevante para uma consulta. Ao “expandir” a lista inicial de qrels para incluir também os duplicados, observamos um aumento relativo médio de aproximadamente 1% na pontuação nDCG@10.

Exemplo de pares duplicados no ArguAna. No arquivo qrels, apenas o primeiro aparece como relevante (como contra-argumento) para a consulta (“test-economy-epiasghbf-pro02a”).

Ao comparar modelos na tabela de classificação do MTEB, é tentador focar na qualidade média de recuperação. Essa é uma boa aproximação da qualidade geral do modelo, mas não necessariamente indica como ele vai se comportar no seu caso de uso específico. Como os resultados são reportados por conjunto de dados, vale a pena entender o quanto cada conjunto se relaciona com a sua tarefa de busca e reavaliar os modelos usando apenas os mais relevantes. Se quiser se aprofundar ainda mais, também é possível verificar a sobreposição de tópicos entre os diferentes corpora dos conjuntos de dados. Estratificar as métricas de qualidade por tópico fornece uma avaliação muito mais detalhada de pontos fortes e limitações específicas.

Um ponto importante a destacar é que, quando um documento não está marcado no arquivo qrels , ele é considerado irrelevante para a consulta por padrão. Aprofundamos um pouco mais essa análise e reunimos evidências para esclarecer melhor a seguinte pergunta: “Com que frequência um avaliador se depara com pares (consulta, documento) para os quais não existe informação de comprovação?” Isso é importante porque, quando apenas anotações superficiais estão disponíveis (ou seja, nem todos os documentos relevantes são rotulados como tal), um sistema de recuperação de informação pode ser avaliado como pior do que outro simplesmente porque ele “escolhe” destacar documentos relevantes diferentes, porém não marcados. Essa é uma armadilha comum na criação de conjuntos de avaliação de alta qualidade, especialmente em conjuntos de dados grandes. Para que a rotulagem manual seja viável, ela normalmente se concentra nos principais resultados retornados pelo sistema atual, o que pode deixar de fora documentos relevantes que estão fora do seu campo de visão. Por isso, em geral é preferível concentrar mais recursos em uma anotação mais completa de um número menor de consultas, em vez de realizar uma anotação ampla porém superficial.

Usando o benchmark BEIR para avaliação de relevância de busca

Para iniciar nossa análise, implementamos o seguinte cenário (ver o notebook):

1. Primeiro, carregamos o corpus de cada conjunto de dados em um índice do Elasticsearch.
2. Para cada consulta no conjunto de teste, recuperamos os top 100 documentos usando BM25.
3. Em seguida, fazemos a reclassificação dos documentos recuperados usando uma variedade de modelos de reclassificação de última geração.
4. Por fim, reportamos a “taxa de julgamento” para os top 10 documentos provenientes das etapas 2 (após a recuperação) e 3 (após a reclassificação). Em outras palavras, calculamos a porcentagem média dos top 10 documentos que possuem uma pontuação no arquivo qrels.

A lista de modelos de reclassificação que usamos é a seguinte:

• Cohere rerank-english-v2.0 e rerank-english-v3.0
• BGE-base
• mxbai-rerank-xsmall-v1
• MiniLM-L-6-v2

Tabela 2: Taxa de julgamento por pares (conjunto de dados, reclassificador), calculada sobre os top 10 documentos recuperados/reclassificados

A partir da Tabela 2, com exceção de TREC-COVID (cobertura de >90%), DBPedia (~65%), Touche2020 e nfcorpus (~35%), observamos que a maioria dos conjuntos de dados apresenta uma taxa de rotulagem entre 5% e pouco mais de 10% após a recuperação ou a reclassificação. Isso não significa que todos esses documentos não marcados sejam relevantes, mas pode haver um subconjunto deles — especialmente aqueles posicionados no topo — que seja positivo.

Com a chegada de modelos de linguagem de propósito geral ajustados por instruções, passamos a contar com uma nova e poderosa ferramenta que pode, potencialmente, automatizar a avaliação de relevância. Esses métodos normalmente são computacionalmente caros demais para uso online em sistemas de busca, mas aqui estamos tratando de avaliação offline. A seguir, usamos esses modelos para explorar evidências de que alguns conjuntos de dados do BEIR sofrem com anotações superficiais.

Para investigar melhor essa hipótese, decidimos focar no MSMARCO e selecionar um subconjunto de 100 consultas, juntamente com os top 5 documentos reclassificados (com Cohere v2) que atualmente não estão marcados como relevantes. Primeiro, usamos um prompt cuidadosamente ajustado (falaremos mais sobre isso em um post futuro) para preparar o modelo Phi-3-mini-4k, lançado recentemente, a prever se um documento é ou não relevante para a consulta. Em paralelo, esses mesmos casos também foram rotulados manualmente, de modo a avaliar a taxa de concordância entre a saída do LLM e o julgamento humano. De forma geral, podemos tirar as duas conclusões a seguir$\dag$:

• A taxa de concordância entre as respostas dos LLMs e os julgamentos humanos ficou próxima de 80%, o que parece um ponto de partida razoável nessa direção.
• Em 57,6% dos casos (com base em julgamento humano), os documentos retornados foram considerados realmente relevantes para a consulta. Colocando isso de outra forma: para 100 consultas, temos 107 documentos julgados como relevantes, mas pelo menos 0,576 × 5 × 100 = 288 documentos adicionais que também são, de fato, relevantes.

Aqui estão alguns exemplos extraídos do conjunto de dados MSMARCO/dev que incluem a consulta, o documento positivo anotado (de qrels) e um documento falso negativo devido a anotações incompletas:

Exemplo 1:

Exemplo 2:

Avaliar manualmente consultas específicas dessa forma é uma técnica geralmente útil para entender a qualidade da busca e complementa métricas quantitativas como o nDCG@10. Se você tiver um conjunto representativo de consultas que sempre executa ao fazer alterações no sistema de busca, isso fornece informações qualitativas importantes sobre como a performance muda, algo que não aparece nas estatísticas. Por exemplo, essa abordagem oferece muito mais visibilidade sobre resultados incorretos retornados pela busca: ajuda a identificar erros evidentes nos documentos recuperados, classes de falhas recorrentes, como interpretações equivocadas de terminologia específica de um domínio, entre outros.

Nossos resultados estão alinhados com pesquisas relevantes sobre avaliação em MSMARCO. Por exemplo, Arabzadeh et al. seguem um procedimento semelhante ao empregar trabalhadores de crowdsourcing para realizar julgamentos de preferência. Entre outros achados, eles mostram que, em muitos casos, os documentos retornados pelos módulos de reclassificação são preferidos em relação aos documentos presentes no arquivo qrels do MSMARCO. Outra evidência vem dos autores do reclassificador RocketQA, que relatam que mais de 70% dos documentos reclassificados foram considerados relevantes após inspeção manual.

$\dag$ Atualização – 9 de setembro: após uma reavaliação cuidadosa do conjunto de dados, identificamos mais 15 casos de documentos relevantes, aumentando o total de 273 para 288.

Principais conclusões e próximos passos

• A busca por uma comprovação melhor é contínua e extremamente importante para benchmarking e comparação de modelos. Os LLMs podem auxiliar em algumas áreas da avaliação, desde que usados com cautela e ajustados com instruções adequadas.
• De forma mais geral, considerando que benchmarks nunca serão perfeitos, pode ser preferível migrar de uma comparação puramente baseada em pontuações para técnicas mais robustas, capazes de capturar diferenças estatisticamente significativas. O trabalho de Arabzadeh et al. oferece um bom exemplo disso: com base em seus resultados, os autores constroem intervalos de confiança de 95% para indicar se as diferenças entre diferentes execuções são estatisticamente significativas ou não. No notebook que acompanha este conteúdo, fornecemos uma implementação de intervalos de confiança usando bootstrapping.
• Do ponto de vista do usuário final, é útil pensar em alinhamento com a tarefa ao interpretar resultados de benchmarks. Por exemplo, para um engenheiro de IA que constrói um pipeline de RAG e sabe que o caso de uso mais comum envolve reunir múltiplas informações de diferentes fontes, faz mais sentido avaliar o desempenho do modelo de recuperação em conjuntos de dados de QA multi-hop, como o HotpotQA, em vez de considerar apenas a média global de todo o benchmark BEIR.

No próximo post do blog, vamos nos aprofundar no uso do Phi-3 como avaliador baseado em LLM e no processo de ajuste do modelo para prever relevância.

Perguntas frequentes