LLMs são cada vez mais populares para tarefas de raciocínio, como controle de qualidade multivoltas , conclusão de tarefas , geração de código ou matemática . 

No entanto, tal como as pessoas, nem sempre resolvem os problemas corretamente à primeira tentativa, especialmente em tarefas para as quais não foram treinados. Portanto, para que tais sistemas sejam mais úteis, devem ser capazes de 1) identificar onde o seu raciocínio falhou e 2) recuar para encontrar outra solução.

Isto levou a um aumento nos métodos relacionados à autocorreção , onde um LLM é usado para identificar problemas em seus próprios resultados e, em seguida, produzir melhores resultados com base no feedback. A autocorreção geralmente é considerada um processo único, mas decidimos dividi-la em dois componentes: detecção de erros e correção de saída .

Em “ LLMs não conseguem encontrar erros de raciocínio, mas podem corrigi-los! ”, testamos LLMs de última geração em localização de erros e correção de saída separadamente. Apresentamos o BIG-Bench Mistake , um conjunto de dados de referência de avaliação para identificação de erros, que usamos para responder às seguintes questões:

• Os LLMs podem encontrar erros lógicos no raciocínio do estilo Chain-of-Thought (CoT)?
• A descoberta de erros pode ser usada como um substituto para a correção?
• Sabendo onde está o erro, os LLMs podem ser solicitados a voltar atrás e chegar à resposta correta?
• A descoberta de erros como uma habilidade pode ser generalizada para tarefas que os LLMs nunca viram?

Sobre nosso conjunto de dados

A descoberta de erros é um problema pouco explorado no processamento de linguagem natural, com uma particular falta de tarefas de avaliação neste domínio. Para melhor avaliar a capacidade dos LLMs de encontrar erros, as tarefas de avaliação devem apresentar erros que não sejam ambíguos. Até onde sabemos, a maioria dos conjuntos de dados atuais de detecção de erros não vão além do domínio da matemática por esse motivo.

Para avaliar a capacidade dos LLMs de raciocinar sobre erros fora do domínio matemático, produzimos um novo conjunto de dados para uso pela comunidade de pesquisa, chamado BIG-Bench Mistake . Este conjunto de dados consiste em rastreamentos de cadeia de pensamento gerados usando PaLM 2 em cinco tarefas no BIG-Bench . Cada traço é anotado com a localização do primeiro erro lógico.

Para maximizar o número de erros em nosso conjunto de dados, amostramos 255 traços onde a resposta está incorreta (para sabermos que definitivamente há um erro) e 45 traços onde a resposta está correta (portanto, pode haver ou não um erro). Em seguida, pedimos aos rotuladores humanos que analisem cada traço e identifiquem a primeira etapa do erro. Cada traço foi anotado por pelo menos três rotuladores, cujas respostas tiveram níveis de confiabilidade interavaliadores >0,98 (usando α de Krippendorff ). A rotulagem foi feita para todas as tarefas, exceto a tarefa Dyck Languages , que envolve prever a sequência de parênteses de fechamento para uma determinada sequência de entrada. Esta tarefa foi rotulada algoritmicamente.

Os erros lógicos cometidos neste conjunto de dados são simples e inequívocos, fornecendo uma boa referência para testar a capacidade de um LLM de encontrar os seus próprios erros antes de os utilizar em tarefas mais difíceis e ambíguas.

 

Perguntas essenciais sobre identificação de erros

1. Os LLMs podem encontrar erros lógicos no raciocínio do estilo Cadeia de Pensamento?

Primeiro, queremos descobrir se os LLMs conseguem identificar erros independentemente da sua capacidade de os corrigir. Tentamos vários métodos de prompt para testar os modelos da série GPT quanto à sua capacidade de localizar erros (solicitações aqui ) sob a suposição de que eles são geralmente representativos do desempenho moderno do LLM.

Geralmente, descobrimos que esses modelos de última geração apresentam desempenho insatisfatório, com o melhor modelo alcançando 52,9% de precisão geral. Portanto, há necessidade de melhorar a capacidade dos LLMs nesta área de raciocínio.

Em nossos experimentos, tentamos três métodos diferentes de solicitação: direto (traço), direto (passo) e CoT (passo). No direto (rastreamento), fornecemos o rastreio ao LLM e solicitamos a etapa de localização do erro ou não . Em direto (passo), solicitamos ao LLM que se faça esta pergunta para cada passo que dá. No CoT (passo), solicitamos ao LLM que justifique se cada passo é um erro ou não.

Um diagrama mostrando os três métodos de solicitação direto (traço), direto (etapa) e CoT (etapa).

Nossa descoberta está alinhada e se baseia em resultados anteriores , mas vai além ao mostrar que os LLMs lutam até mesmo com erros simples e inequívocos (para comparação, nossos avaliadores humanos sem experiência prévia resolvem o problema com um alto grau de concordância). Nossa hipótese é que esta é uma grande razão pela qual os LLMs são incapazes de autocorrigir erros de raciocínio. Veja o artigo para os resultados completos.

2. A descoberta de erros pode ser usada como proxy para a correção da resposta?

Quando as pessoas são confrontadas com um problema para o qual não temos certeza da resposta, podemos trabalhar nas nossas soluções passo a passo. Se nenhum erro for encontrado, podemos presumir que fizemos a coisa certa.

Embora tenhamos levantado a hipótese de que isto funcionaria de forma semelhante para os LLMs, descobrimos que esta é uma estratégia fraca. Em nosso conjunto de dados com 85% de traços incorretos e 15% de traços corretos, usar esse método não é muito melhor do que a estratégia ingênua de sempre rotular os traços como incorretos, o que dá uma média ponderada F1 de 78.

Um diagrama que mostra quão bem a detecção de erros com LLMs pode ser usada como um proxy para a correção da resposta em cada conjunto de dados.

3. Os LLMs podem voltar atrás sabendo onde está o erro?

Como mostramos que os LLMs apresentam baixo desempenho na localização de erros de raciocínio em traços de CoT, queremos saber se os LLMs conseguem corrigir os erros , mesmo que saibam onde está o erro.

Observe que saber a localização do erro é diferente de saber a resposta certa : os traços do CoT podem conter erros lógicos mesmo que a resposta final esteja correta, ou vice-versa. Na maioria das situações do mundo real, não saberemos qual é a resposta certa, mas poderemos identificar erros lógicos em etapas intermediárias.

Propomos o seguinte método de retrocesso:

1. Gere traços CoT normalmente, à temperatura = 0. (A temperatura é um parâmetro que controla a aleatoriedade das respostas geradas, com valores mais altos produzindo resultados mais diversos e criativos, geralmente em detrimento da qualidade.)
2. Identifique a localização do primeiro erro lógico (por exemplo, com um classificador, ou aqui apenas usamos rótulos do nosso conjunto de dados).
3. Gere novamente a etapa errada na temperatura = 1 e produza um conjunto de oito saídas. Como se sabe que o resultado original leva a resultados incorretos, o objetivo é encontrar uma geração alternativa nesta etapa que seja significativamente diferente da original.
4. Destas oito saídas, selecione uma que seja diferente da etapa do erro original. (Usamos apenas correspondência exata aqui, mas no futuro isso poderá ser algo mais sofisticado.)
5. Usando a nova etapa, gere o restante do traço normalmente na temperatura = 0.

É um método muito simples que não requer nenhuma elaboração adicional de prompt e evita a necessidade de gerar novamente todo o rastreamento. Nós o testamos usando os dados de localização de erros do BIG-Bench Mistake e descobrimos que ele pode corrigir erros de CoT.

Trabalhos recentes mostraram que métodos de autocorreção, como Reflexão e RCI , causam deterioração nas pontuações de precisão porque há mais respostas corretas que se tornam incorretas do que vice-versa. Nosso método, por outro lado, produz mais ganhos (ao corrigir respostas erradas) do que perdas (ao transformar respostas certas em respostas erradas).

Também comparamos nosso método com uma linha de base aleatória, onde assumimos aleatoriamente que uma etapa é um erro. Nossos resultados mostram que essa linha de base aleatória produz alguns ganhos, mas não tanto quanto retroceder com a localização correta do erro e com mais perdas.

Um diagrama que mostra os ganhos e perdas de precisão do nosso método, bem como uma linha de base aleatória em cada conjunto de dados.

4. A descoberta de erros pode ser generalizada para tarefas que os LLMs nunca viram?

Para responder a essa pergunta, ajustamos um modelo pequeno em quatro das tarefas do BIG-Bench e o testamos na quinta tarefa prolongada. Fazemos isso para cada tarefa, produzindo um total de cinco modelos ajustados. Em seguida, comparamos os resultados com apenas o prompt zero-shot PaLM 2-L-Unicorn , um modelo muito maior.

Gráfico de barras mostrando a melhoria da precisão do modelo pequeno ajustado em comparação com a solicitação de tiro zero com PaLM 2-L-Unicorn.

Nossos resultados mostram que o modelo de recompensa bem menor e ajustado geralmente tem melhor desempenho do que o disparo zero que solicita um modelo grande, mesmo que o modelo de recompensa nunca tenha visto dados da tarefa no conjunto de teste. A única exceção é a dedução lógica, onde funciona no mesmo nível da solicitação de disparo zero.

Este é um resultado muito promissor, pois podemos usar apenas um pequeno modelo de recompensa ajustado para realizar retrocessos e melhorar a precisão em qualquer tarefa, mesmo que não tenhamos os dados para isso. Este modelo de recompensa menor é completamente independente do gerador LLM e pode ser atualizado e ajustado para casos de uso individuais.

Uma ilustração que mostra como funciona nosso método de retrocesso.

 

Conclusão

Neste trabalho, criamos um conjunto de dados de referência de avaliação que a comunidade acadêmica mais ampla pode usar para avaliar futuros LLMs. Mostramos ainda que os LLMs atualmente lutam para encontrar erros lógicos. Porém, se pudessem, mostramos a eficácia do retrocesso como estratégia que pode proporcionar ganhos nas tarefas. Finalmente, um modelo de recompensa menor pode ser treinado em tarefas gerais de detecção de erros e usado para melhorar a detecção de erros fora do domínio, mostrando que a detecção de erros pode ser generalizada.

Artigo publicado no Onetoday.news