notícias

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

• Crecy vem do Templo Aofei
  Qubits | Conta pública QbitAI

A equipe da Apple lançou uma nova conquista de código aberto - um conjunto de benchmarks sobre a capacidade de chamar ferramentas de grandes modelos.

Este Benchmark usa de forma inovadoraMétodo de avaliação baseado em cenário, que pode refletir melhor o nível do modelo no ambiente real.

Também introduz cenários importantes que não são considerados nos padrões tradicionais, como a interação de diálogo e a dependência do Estado.

Este conjunto de benchmarks de teste é denominado ToolSandbox, e Pang Ruoming, chefe da equipe de modelos básicos da Apple, também participou do trabalho de pesquisa.

O ToolSandbox compensa a falta de avaliação baseada em cenários dos padrões de teste existentes e reduz a lacuna entre as condições de teste e as aplicações reais.

E em termos de interação, o autor permite que o GPT-4o atue como usuário e converse com o modelo em teste, simulando assim cenários do mundo real.

Por exemplo, diga ao GPT-4o que você não é mais um assistente, mas deseja interpretar o usuário A que está conversando com o usuário B e, em seguida, faça uma série de solicitações específicas.

Além disso, o autor também usou o ToolSandbox para testar alguns modelos convencionais, e os resultados geraisOs modelos de código fechado pontuam mais que os modelos de código aberto, o mais forte deles é o GPT-4o.

O desenvolvedor de aplicativos iOS, Nick Dobos, disse que o conjunto de padrões da Apple é conciso e claro.

Ao mesmo tempo, ele destacou que o ChatGPT já está um pouco sobrecarregado quando se depara com três ferramentas. Se a Siri quiser gerenciar dezenas ou centenas de aplicativos em telefones celulares, ela também precisará melhorar os recursos de chamada de ferramentas.

A implicação é que a pesquisa da ToolSandbox pode esclarecer a direção da pesquisa e desenvolvimento futuro da Siri.

Teste o modelo em um cenário

Conforme mencionado acima, o ToolSandbox adota um método de teste interativo e baseado em cenários.

Especificamente, o ToolSandbox inclui um total de quase 2.000 cenários em sete tipos, incluindo invocação de ferramenta única/múltipla, rodadas únicas/múltiplas de diálogo, dependência do estado, padronização e informações insuficientes.

Os primeiros são relativamente fáceis de entender. Aqui estão algumas explicações para os três tipos de cena a seguir:

• Dependência de estado: A execução de uma ferramenta depende de certos estados globais, e esse estado precisa ser modificado primeiro por outras ferramentas;
• Padronização: Converter expressões de linguagem natural no formato padrão exigido pela ferramenta, o que pode exigir o auxílio de outras ferramentas;
• Informações insuficientes: As principais ferramentas necessárias para concluir a tarefa estão faltando intencionalmente. Verifique se o modelo pode identificar situações em que ela não pode ser concluída.

Nestes cenários, o ToolSandbox se concentrará em três indicadores do modelo:

• Desempenho geral, ou seja, a semelhança média com as respostas predefinidas em vários cenários
• Robustez, utilizar diversos métodos para modificar e interferir na ferramenta, e observar o desempenho do modelo neste ambiente
• Eficiência, ou seja, o número médio de rodadas de conclusão de tarefas

Em termos de ferramentas, o autor selecionou 34 funções Python combináveis ​​como ferramentas, que são comparáveis ​​à complexidade de cenários reais.

Inclui ferramentas Python nativas e algumas ferramentas RapidAPI integradas, com funções que cobrem muitas áreas comuns, como pesquisa, diálogo, navegação, clima e processamento de imagens.

Em termos de processo, o primeiro passo é preparar o cenário de teste. Os pesquisadores definirão e armazenarão o estado mundial inicial e, ao mesmo tempo, utilizarão o modelo GPT-4o calibrado para gerar a mensagem inicial do usuário.

Entrando então no estágio de execução interativa, o sistema primeiro inicializa o Message Bus como um canal de comunicação entre funções e configura o modelo que interpreta o usuário e o modelo em teste.

Quando o loop de conversação começa, o modelo que simula o usuário envia uma mensagem inicial, e o modelo em teste recebe a mensagem e decide a próxima ação – seja respondendo diretamente ao usuário ou chamando uma ferramenta para interagir com o ambiente.

Se o modelo optar por chamar a ferramenta, ele fornecerá os parâmetros necessários no formato JSON, e o ambiente de execução interpretará e executará essa chamada, possivelmente atualizando o estado mundial e manipulando possíveis condições de chamada paralela.

Após os resultados da execução serem retornados ao modelo em teste, o modelo em teste determina novamente a próxima ação. Este processo continua até que o simulador do usuário acredite que a tarefa foi concluída (ou não pode ser concluída), momento em que chamará end_conversation. ferramenta para encerrar a conversa.

Durante todo o processo de interação, o sistema registra todas as mensagens e alterações de status para formar uma “trilha de diálogo” completa, que então entra na fase de avaliação.

A avaliação utiliza “marcos” e “campos minados” predefinidos para medir o desempenho do modelo de agente.

marcoOs principais eventos para completar a tarefa são definidos, formando um gráfico acíclico direcionado para refletir as dependências de tempo.

O sistema procura a melhor correspondência entre eventos e marcos na trajetória, mantendo a ordem topológica dos marcos.

campo minadoEle define eventos proibidos e é usado principalmente para detectar se o modelo está tendo alucinações por falta de informação.

Por exemplo, a figura abaixo mostra um exemplo de avaliação de um campo minado no cenário de “informação insuficiente”.

Nesta tarefa, como o carimbo de data/hora atual não está disponível, o modelo não deve chamar a ferramenta timestamp_diff, mas o modelo adivinha incorretamente o carimbo de data/hora atual e chama a ferramenta, resultando em uma pontuação 0 para esta rodada.

Em última análise, o sistema calcula uma pontuação composta que é o produto da pontuação média da partida do marco e da penalidade do campo minado.

Além disso, o sistema também contará o número médio de rodadas necessárias para completar a tarefa como indicador complementar para avaliar a eficiência do modelo.

Cenários complexos de interação ainda são um desafio

No geral,Os modelos de código fechado têm melhor desempenho do que os modelos de código aberto em termos de chamadas de ferramentas。

Aquele com maior pontuação média é o GPT-4o, com pontuação de 73,0. É o único que ultrapassa 70 e obteve a maior pontuação em quatro dos sete cenários definidos pelo autor.

Além disso, o GPT-4o também é extremamente robusto. O autor utilizou 8 métodos para modificar a ferramenta, e o GPT-4o obteve a maior pontuação de robustez entre eles.

É seguido de perto por Claude 3-Opus, com pontuação média de 69,2, que supera GPT-4o em cenas com informações insuficientes, e depois algumas outras versões de GPT e Claude.

O Gemini do Google está relativamente atrasado. A pontuação do 1.5 Pro é 60,4, o que é apenas passageiro e não tão bom quanto o GPT-3.5. No entanto, ele tem um bom desempenho no único item de informação insuficiente.

A pontuação média mais alta do modelo de código aberto é de apenas 31,4. Entre eles, a famosa pontuação do Mistral-7B é de 29,8, mas alcançou a melhor pontuação de 76,8 no único item de informação insuficiente.

Mesmo alguns dos modelos de código aberto, como Gorilla e Command-R, não conseguem lidar com as respostas da ferramenta ou mal conseguem completar uma única rodada de chamadas de ferramenta.

Uma análise mais aprofundada mostrou queOs modelos de código aberto são ruins para identificar quando é hora de recorrer às ferramentas, preferindo tratar o problema como uma tarefa de geração de texto puro.

Da dimensão da tarefa, o modelo grande tem um bom desempenho em chamadas de ferramentas únicas/múltiplas e em solicitações de usuário de rodada única, masA vantagem enfraquece em conversas multivoltas e tarefas dependentes de estado。

Na GPT, Claude, Gemini e outras famílias,Modelos maiores têm vantagens mais óbvias em invocação de múltiplas ferramentas e tarefas de diálogo multivoltas.;masEm tarefas dependentes do estado, modelos de pequeno e médio porte（如GPT-3.5、Claude-3-Sonnet）Pelo contrário, é melhor que o modelo grande（GPT-4, Claude-3-Opus）ter melhor desempenho。

Além disso, a normalização é um grande desafio para todos os modelos, especialmente cenários que requerem ferramentas para normalização, e a normalização de parâmetros relacionados ao tempo também é muito difícil.

Pesquisas sobre robustez mostram que a sensibilidade do modelo a mudanças na descrição da ferramenta, informações de parâmetros, etc. varia muito e nenhuma regra óbvia é encontrada.

Em termos de eficiência, os modelos mais fortes são geralmente mais eficientes, mas há exceções. Por exemplo, a eficiência dos modelos da série Claude é geralmente melhor que o GPT.

Em suma, grandes modelos ainda enfrentam muitos desafios ao utilizar ferramentas para lidar com cenários complexos de interação no mundo real.

Sobre o autor

Os membros da equipe do ToolSandbox vêm das equipes de aprendizado de máquina, ciência de dados, modelo básico grande e outras equipes da Apple.

O primeiro autor é um engenheiro chinês de aprendizado de máquinaJiarui Lu, formou-se na Universidade de Tsinghua com bacharelado. Durante seus estudos, também atuou como assistente de pesquisa no laboratório do professor Zhu Jun.

Posteriormente, Lu obteve um mestrado em aprendizado de máquina pela Carnegie Mellon University e ingressou na Apple em 2020 após se formar.

Incluindo Lu, assinado10 dos 12 autores são chineses, e todos têm formação em escolas de prestígio.

Isso também inclui o chefe da equipe básica de modelos grandesPang Ruoming(Dor de Ruoming)

Além disso, um diretor de engenharia que trabalha na Apple há 8 anosBernhard Aumayertambém participou deste projeto.

Endereço do papel:
https://arxiv.org/abs/2408.04682