De acertar uma resposta a concluir uma tarefa: como evoluiu a avaliação da IA

A pergunta histórica: o que significa avaliar uma capacidade de IA?

Avaliar uma capacidade de inteligência artificial significa converter uma pergunta ampla — por exemplo, se um sistema compreende instruções ou consegue ajudar a resolver problemas — num teste com tarefas, condições e uma regra para julgar os resultados. A pontuação obtida não mede a capacidade em abstrato: resume o desempenho nessas condições específicas.

Uma resposta correta a uma pergunta, uma solução que passa nos testes de software e uma operação que deixa uma aplicação no estado solicitado são evidências diferentes. Não podem ser tratadas como unidades intercambiáveis. Cada uma torna certos êxitos e falhas visíveis e deixa outros de fora. Por isso, a história da avaliação pode ser lida, em parte, como uma mudança naquilo que conta como unidade avaliada: primeiro, respostas a exemplos delimitados; depois, conjuntos mais variados de tarefas; e, em alguns benchmarks recentes, sequências de ações executadas em ambientes.

Esta sequência serve de enquadramento interpretativo, não de cronologia exaustiva nem de escada inevitável rumo a uma medida melhor. Os trabalhos selecionados representam abordagens distintas. Um benchmark de respostas pode ser adequado a uma pergunta específica; um benchmark interativo pode fornecer evidências mais diretas sobre a execução, mas também acrescenta dependências do ambiente e do protocolo.

Primeira etapa: tarefas delimitadas e respostas que podem ser pontuadas

Numa avaliação baseada em conjuntos de dados, cada exemplo apresenta uma entrada e estabelece qual saída é considerada correta ou que critério deve ser aplicado. Na compreensão da linguagem, a entrada pode ser uma frase ou um par de frases; a saída, uma etiqueta, uma avaliação ou uma resposta. O resultado agregado permite comparar sistemas que participaram na mesma tarefa e segundo um protocolo comum.

Este desenho tem vantagens práticas. Os exemplos podem ser repetidos, os resultados podem ser calculados de forma consistente e os investigadores podem comparar métodos sem lhes pedir que operem uma aplicação completa. Se a pergunta é se um modelo distingue uma relação semântica específica, uma tarefa de classificação bem definida pode fornecer evidências úteis.

Mas a unidade avaliada é restrita. Obter uma etiqueta correta não demonstra que o sistema consiga planear uma série de passos, utilizar ferramentas, reagir a uma mudança inesperada ou concluir uma tarefa numa interface. Uma pontuação agregada também não explica, por si só, onde se concentram os erros. A cobertura dos dados, a forma como as perguntas são formuladas e a métrica escolhida delimitam aquilo que se pode inferir.

A inferência prudente é condicional: o sistema obteve determinado resultado nessas tarefas, com esses dados e essa regra de pontuação. Para sustentar afirmações mais amplas sobre competência geral, robustez ou utilidade numa situação real, são necessários testes adicionais.

Alargar o campo de teste: GLUE e BIG-bench

Apresentado em 2018, o GLUE reúne várias tarefas de compreensão da linguagem natural num benchmark multitarefa e numa plataforma de análise. O seu desenho desloca o foco de um único teste para um conjunto de problemas relacionados: permite observar se um sistema obtém resultados em diferentes tarefas e oferece uma forma de resumir parte desse desempenho. A diversidade de tarefas torna mais difícil reduzir a avaliação a uma só capacidade, embora não elimine as limitações de cada tarefa nem transforme o resultado agregado numa medida universal.

O BIG-bench alargou ainda mais a variedade de testes reunidos. Em vez de se centrar numa família relativamente delimitada de problemas linguísticos, propôs uma ampla coleção de tarefas contribuídas por diferentes colaboradores, com objetivos e formas de avaliação diversos. O trabalho analisa o desempenho de modelos de linguagem nessa coleção e a forma como os resultados mudam quando se altera a escala dos modelos.

A mudança importante não consiste apenas em acrescentar exemplos. Uma coleção heterogénea pode testar capacidades e comportamentos diferentes e revelar que um sistema forte numa tarefa não é necessariamente forte noutra. Ao mesmo tempo, essa variedade torna a comparação mais complexa: as tarefas podem ter formatos, métricas e níveis de dificuldade distintos. Um valor agregado facilita uma leitura panorâmica, mas pode ocultar diferenças importantes entre componentes.

Em ambos os casos, a avaliação continua a ser, sobretudo, um teste de respostas a tarefas definidas antecipadamente. Ter muitas tarefas não equivale a observar um agente a trabalhar num ambiente aberto. A amplitude melhora a cobertura dentro da coleção; não garante que esta represente todos os usos possíveis nem que meça uma execução prolongada.

Mudar a unidade: resolver uma questão num repositório

O SWE-bench desloca a unidade de avaliação para uma tarefa de engenharia de software: resolver questões de repositórios reais do GitHub. Em vez de avaliar apenas uma resposta textual a uma pergunta, o sistema tem de trabalhar com o contexto de um projeto e produzir alterações no código que respondam ao problema apresentado.

A avaliação pode verificar o patch através dos testes do projeto, incluindo testes relacionados com o erro descrito e outros que deveriam continuar a passar. Assim, obtém-se evidência sobre algo mais concreto do que uma explicação convincente: se a alteração proposta funciona segundo as verificações disponíveis no ambiente do benchmark. O avaliador pode determinar se o resultado passa nesses testes; isso não equivale a certificar que o patch é a única solução correta, que está bem concebido em todos os aspetos ou que é seguro em qualquer implementação.

O sistema avaliado também não é necessariamente apenas o modelo isolado. Consoante a configuração, o resultado pode depender da forma como o repositório lhe é apresentado, das ferramentas disponíveis para inspecionar ou editar ficheiros, do número de tentativas permitido e do procedimento para executar os testes. Para comparar pontuações, é importante saber que componentes estão incluídos e se o protocolo se manteve constante.

A avaliação continua a ser uma coleção definida de questões e condições de execução. Por conseguinte, resolver uma questão comprova o sucesso naquele caso e segundo as respetivas verificações, não a capacidade de resolver qualquer problema de software. Um teste de repositório aproxima a tarefa de uma atividade profissional concreta, mas não abrange automaticamente requisitos de produto, colaboração, manutenção a longo prazo ou consequências de uma alteração em produção.

Incluir interação e estado: tarefas em ambientes informáticos

O OSWorld avalia agentes multimodais em tarefas abertas dentro de ambientes informáticos reais simulados. Em vez de se limitar a produzir uma resposta sobre uma aplicação, um agente pode ter de observar a interface e agir com controlos como o teclado ou o rato para alcançar um estado solicitado. A avaliação centra-se em tarefas realizadas no ambiente, e não apenas na qualidade linguística de uma descrição.

Esta mudança permite observar dimensões que um teste de respostas não regista diretamente: se as ações são executadas, se uma sequência alcança o resultado previsto e se o estado final satisfaz uma condição de avaliação. Também torna mais visível a relação entre perceção, decisão e ação. Um sistema pode descrever corretamente o que deveria fazer e, ainda assim, não conseguir fazê-lo; num ambiente interativo, essa diferença pode fazer parte do resultado.

A execução fornece um sinal mais próximo da tarefa operacional, mas não elimina a necessidade de decidir o que conta como sucesso. O ambiente, as aplicações, o estado inicial, as instruções, as ferramentas e o verificador fazem parte das condições do teste. Se a avaliação compara estados através de regras automatizadas, essas regras podem verificar aspetos específicos do resultado; não avaliam necessariamente todos os pormenores de qualidade, segurança ou conveniência do percurso seguido.

Também é necessário distinguir o agente do ambiente. Uma pontuação obtida com determinadas ferramentas e controlos não descreve automaticamente o que o modelo faria sem eles, com uma interface diferente ou perante condições não contempladas. O resultado corresponde ao sistema e ao protocolo avaliados, não a uma capacidade isolada de todos esses componentes.

O que muda com um ambiente executável — e o que permanece

A passagem de respostas pontuadas para tarefas executáveis amplia as evidências observáveis. Pode mostrar se o sistema produz uma alteração num repositório ou numa aplicação, em vez de apenas redigir uma solução plausível. Esta é uma diferença relevante para afirmações sobre capacidade de ação. No entanto, não transforma automaticamente um benchmark numa medida completa de utilidade, autonomia ou fiabilidade.

Convém separar quatro elementos. A tarefa define o que é pedido; o ambiente determina onde e em que condições isso acontece; o verificador estabelece que resultados considera satisfatórios; e o sistema avaliado inclui os componentes que recebem a tarefa e produzem ações. Uma alteração em qualquer um destes elementos pode mudar a dificuldade ou o significado da pontuação. Se forem comparados resultados de protocolos diferentes sem reconhecer essas alterações, pode atribuir-se ao modelo algo que, em parte, resulta de outras condições.

A validade do verificador merece atenção especial. Um teste automatizado pode ser reproduzível e útil, mas só avalia aquilo que verifica. Um conjunto de testes incompleto pode não detetar um defeito que não esteja coberto; uma verificação do estado final pode não penalizar um percurso ineficiente se a eficiência não fizer parte do critério. Estas são possibilidades gerais que devem ser investigadas em cada benchmark, não defeitos que devam ser atribuídos a uma avaliação específica sem evidências.

A reprodutibilidade também depende de pormenores operacionais: versões de software, estado inicial, acesso a ferramentas, orçamento de tempo ou número de tentativas. Descrever estes limites permite interpretar melhor o resultado. Quando faltam pormenores, a comparação pode ser menos informativa; nesse caso, é preferível assinalar a incerteza em vez de preencher as lacunas com suposições.

Como interpretar uma pontuação histórica

Uma pontuação histórica precisa de contexto. O primeiro passo é identificar que versão do benchmark e que protocolo foram utilizados. A mesma designação pode referir-se a conjuntos de tarefas, métricas ou configurações diferentes. Antes de comparar dois valores, é necessário confirmar que descrevem testes suficientemente comparáveis.

O segundo passo é identificar a unidade de avaliação. Foi pontuada uma resposta, uma coleção de respostas, um patch submetido a testes ou uma tarefa numa interface? Essa diferença determina que tipo de evidência o resultado fornece. Uma percentagem de respostas corretas e uma taxa de tarefas concluídas não são escalas equivalentes, mesmo que ambas sejam expressas em percentagem.

Em seguida, convém separar o resultado agregado da sua desagregação. Num conjunto multitarefa, analisar o desempenho por tarefa pode revelar pontos fortes e fracos que desaparecem na média. Nas avaliações interativas, importa saber que condições de execução foram mantidas e que estados o verificador considerou satisfatórios. Sempre que existam relatórios disponíveis, os resultados desagregados ajudam a evitar que um valor-resumo se transforme numa afirmação mais ampla do que as evidências permitem.

Por fim, uma melhoria entre avaliações não demonstra, por si só, quanto progrediu uma capacidade geral. Se o modelo, a coleção de tarefas, as ferramentas ou as regras de pontuação mudarem em simultâneo, não é possível atribuir toda a alteração a uma única causa sem análise adicional. A comparação é mais sólida quando as condições se mantêm ou quando as diferenças são descritas com precisão.

Conclusão: escolher as evidências de acordo com a afirmação

GLUE e BIG-bench mostram duas formas de alargar avaliações centradas em respostas: reunir tarefas relacionadas ou abranger uma coleção mais diversificada. SWE-bench e OSWorld ilustram abordagens que deslocam o teste para resultados executados em repositórios e ambientes informáticos. Não são degraus intercambiáveis de uma classificação; respondem a perguntas diferentes e deixam tipos distintos de evidência.

Quando a afirmação diz respeito a respostas a tarefas linguísticas, um conjunto de dados pertinente pode ser um teste útil. Se se pretende saber como o desempenho se distribui por várias tarefas, importa analisar uma avaliação multitarefa e os seus resultados desagregados. Se a afirmação se refere a alterar um projeto ou a realizar ações numa aplicação, uma avaliação executável pode fornecer evidências mais diretas sobre esses resultados operacionais.

A regra final é simples: interpretar a pontuação ao nível do teste que a produziu. Uma avaliação mais próxima da utilização pode revelar mais sobre ações e estados, mas não mede, por si só, todos os aspetos de um sistema útil, seguro ou fiável. Para sustentar essas conclusões, são necessários protocolos transparentes e evidências complementares adequadas a cada afirmação.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.