ToolGen: recuperação e invocação unificadas de ferramentas por meio de geração

O ToolGen é uma estrutura para integrar o conhecimento de ferramentas diretamente em modelos de linguagem grandes (LLMs), permitindo a invocação de ferramentas e a geração de linguagem perfeitas ao representar cada ferramenta como um token exclusivo. Ele foi desenvolvido por Renxi Wang et al. para melhorar o desempenho da recuperação de ferramentas e da conclusão de tarefas.

• Tokenização de ferramentas: conversão de ferramentas em tokens exclusivos para facilitar a invocação de modelos.
• Geração de chamadas de ferramentas: o modelo é capaz de gerar chamadas de ferramentas e parâmetros.
• Conclusão de tarefas: automação de tarefas complexas por meio de chamadas de ferramentas.
• Suporte a conjuntos de dados: fornece conjuntos de dados avançados para apoiar o treinamento e a avaliação de modelos.

resumos

À medida que os modelos de linguagem grande (LLMs) evoluem, as limitações de sua incapacidade de executar tarefas de forma autônoma, interagindo diretamente com ferramentas externas, tornam-se particularmente aparentes. As abordagens tradicionais dependem do uso de descrições de ferramentas como entrada de contexto, o que é limitado pelo comprimento do contexto e exige um mecanismo de recuperação separado que, muitas vezes, é ineficiente. Propomos o ToolGen, um método para recuperar descrições de ferramentas, representando cada ferramenta como um único Token O paradigma do conhecimento da ferramenta integra-se diretamente aos parâmetros do LLM. Isso permite que os LLMs usem chamadas e parâmetros de ferramentas como parte dos recursos preditivos de seu próximo token, integrando, assim, perfeitamente as chamadas de ferramentas à geração de linguagem. Nossa estrutura permite que os LLMs acessem e usem um grande número de ferramentas sem etapas adicionais de recuperação, melhorando significativamente o desempenho e a escalabilidade. Resultados experimentais baseados em mais de 47.000 ferramentas mostram que o ToolGen não só obtém resultados superiores na recuperação de ferramentas e na conclusão autônoma de tarefas, mas também estabelece a base para uma nova geração de agentes de IA que podem se adaptar a uma ampla gama de ferramentas de domínio. Ao transformar fundamentalmente a recuperação de ferramentas em um processo generativo, o ToolGen abre caminho para sistemas de IA mais flexíveis, eficientes e autônomos. O ToolGen amplia a utilidade do LLM ao oferecer suporte ao aprendizado de ferramentas de ponta a ponta e oportunidades de integração com outras tecnologias avançadas, como Chain Thinking e Reinforcement Learning.

1 Introdução

Os modelos de linguagem grande (LLMs) demonstraram capacidades impressionantes no processamento de entradas externas, na realização de operações e na conclusão autônoma de tarefas (Gravitas, 2023; Qin et al. 2023; Yao et al. 2023; Shinn et al. 2023; Wu et al. 2024a; Liu et al. 2024). Entre as várias abordagens para permitir que os LLMs interajam com o mundo externo, as chamadas de ferramentas por meio de APIs se tornaram uma das mais comuns e eficazes. Entretanto, à medida que o número de ferramentas aumenta para dezenas de milhares, os métodos existentes de recuperação e execução de ferramentas são difíceis de dimensionar de forma eficiente.

Em cenários do mundo real, uma abordagem comum é combinar a recuperação de ferramentas com a execução de ferramentas, em que o modelo de recuperação primeiro filtra as ferramentas relevantes antes de entregá-las ao LLM para seleção e execução final (Qin et al., 2023; Patil et al., 2023). Embora essa abordagem combinada seja útil quando se lida com um grande número de ferramentas, há limitações óbvias: os modelos de recuperação geralmente dependem de codificadores pequenos que dificultam a captura abrangente da semântica de ferramentas e consultas complexas, enquanto a separação entre recuperação e execução pode levar a ineficiências e a distorções de estágio no processo de conclusão da tarefa.

Além disso, os LLMs e seus desambiguadores são pré-treinados principalmente em dados de linguagem natural (Brown et al., 2020; Touvron et al., 2023) e têm conhecimento intrínseco limitado da funcionalidade relacionada à ferramenta. Essa lacuna de conhecimento leva a um desempenho ruim, especialmente quando os LLMs precisam confiar nas descrições de ferramentas recuperadas para a tomada de decisões.

Neste estudo, apresentamos o ToolGen, uma nova estrutura que integra o conhecimento de ferramentas do mundo real diretamente aos parâmetros do LLM e transforma a recuperação e a execução de ferramentas em uma tarefa de geração unificada. Especificamente, o ToolGen faz uso mais eficaz do conhecimento preexistente do LLM para recuperação e invocação de ferramentas, ampliando o vocabulário do LLM para representar ferramentas como tokens virtuais específicos e treinando o modelo para gerar esses tokens no contexto do diálogo.

Especificamente, cada ferramenta é representada como um token virtual exclusivo no vocabulário do LLM. Com base no LLM pré-treinado, o processo de treinamento do ToolGen consiste em três fases: memória da ferramenta, treinamento de recuperação e treinamento do agente. Durante a fase de memória da ferramenta, o modelo associa cada token de ferramenta virtual ao respectivo documento. Durante o treinamento de recuperação, o modelo aprende a gerar ToolTokens relevantes com base nas consultas do usuário. Por fim, no ajuste de agente de ponta a ponta, o modelo é treinado para atuar como um agente autônomo, gerando planos e ferramentas e determinando os parâmetros adequados para concluir a tarefa. Ao invocar ferramentas e obter feedback do ambiente externo, o modelo pode processar de forma eficiente e integrada as consultas do usuário. A Figura 1 mostra como o ToolGen se compara ao paradigma tradicional.

Validamos a superioridade do ToolGen em dois cenários: uma tarefa de recuperação de ferramentas em que o modelo recupera a ferramenta correta para uma determinada consulta e uma tarefa de agente baseada em LLM em que o modelo conclui tarefas complexas envolvendo chamadas reais de API. Usando um conjunto de dados de 47.000 ferramentas do mundo real, o ToolGen tem um desempenho tão bom quanto os principais métodos de recuperação de ferramentas, mas a um custo significativamente menor e com maior eficiência. Além disso, ele vai além do paradigma tradicional de aprendizado de ferramentas, destacando seu potencial para o avanço de sistemas de uso de ferramentas mais eficazes.

Figura 1: Comparação do ToolGen com abordagens anteriores baseadas em recuperação. As abordagens anteriores usam recuperadores para recuperar ferramentas relevantes por meio de correspondência de similaridade e, em seguida, colocam essas ferramentas nos prompts do LLM para seleção. O ToolGen permite a recuperação de ferramentas gerando diretamente um token de ferramenta e pode realizar a tarefa sem depender de recuperadores externos.

O ToolGen representa um novo paradigma para a interação com ferramentas, fundindo a recuperação e a geração em um modelo unificado. Essa inovação estabelece a base para uma nova geração de agentes de IA que podem se adaptar a uma ampla variedade de ferramentas de domínio. Além disso, o ToolGen cria novas oportunidades para a combinação de técnicas avançadas, como raciocínio de pensamento encadeado e aprendizagem por reforço, com uma abordagem geradora unificada para o uso de ferramentas, ampliando os recursos de grandes modelos de linguagem em aplicativos do mundo real.

Em resumo, nossas contribuições incluem:

• Propõe-se uma nova estrutura, a ToolGen, que integra a recuperação e a execução de ferramentas ao processo de geração de grandes modelos de linguagem por meio de tokens virtuais.
• Um processo de treinamento em três fases foi projetado para tornar o ToolGen eficiente e dimensionável para recuperação de ferramentas e chamadas de API.
• A validação experimental mostra que o ToolGen apresenta desempenho comparável ao dos melhores métodos de recuperação de ferramentas disponíveis em repositórios de ferramentas em grande escala, mas a um custo menor, de forma mais eficiente e além do paradigma tradicional de aprendizado de ferramentas.

2 Trabalhos relacionados

2.1 Recuperação de ferramentas

A recuperação de ferramentas é fundamental na execução de tarefas práticas de grandes agentes de modelos de linguagem, em que as ferramentas geralmente são descritas por seus documentos. As abordagens tradicionais, como a recuperação esparsa (por exemplo BM25 (Robertson et al., 2009)) e a recuperação intensiva (por exemplo, DPR (Karpukhin et al., 2020), ANCE (Xiong et al., 2021)) dependem de grandes índices de documentos e módulos externos, o que leva a ineficiências e dificuldades de otimização em uma estrutura de agente de ponta a ponta. Vários estudos exploraram abordagens alternativas. Por exemplo, Chen et al. (2024b) reescrevem a consulta e extraem sua intenção para uma configuração de recuperação não supervisionada, embora os resultados não sejam tão bons quanto os das abordagens supervisionadas. xu et al. (2024) propõem uma abordagem que melhora a precisão da recuperação, mas aumenta a latência, otimizando iterativamente a consulta com base no feedback da ferramenta.

Recentemente, a recuperação generativa surgiu como um novo paradigma promissor em que os modelos geram diretamente identificadores de documentos relevantes em vez de depender de mecanismos de recuperação tradicionais (Wang et al., 2022; Sun et al., 2023; Kishore et al., 2023; Mehta et al., 2023; Chen et al., 2023b). Inspirado nisso, o ToolGen representa cada ferramenta como um token exclusivo, de modo que a recuperação e a invocação de ferramentas possam ser tratadas como tarefas generativas. Além de simplificar a recuperação, esse design pode ser usado em conjunto com outros modelos de Big Language e funções de agente baseadas em modelos de Big Language, como Chained Thought Reasoning (Wei et al., 2023) e ReAct (Yao et al., 2023)) é integrado sem problemas. Ao integrar a recuperação e a execução de tarefas em um único agente de modelo de linguagem grande, ele reduz a latência e as despesas gerais de computação e melhora a eficiência e a eficácia da conclusão da tarefa.

2.2 Agentes de modelo de linguagem grande com chamadas de ferramenta

Modelos de linguagem grandes apresentam grande potencial para dominar as ferramentas necessárias para várias tarefas. No entanto, a maioria das pesquisas existentes concentrou-se em um conjunto limitado de ações (Chen et al., 2023a; Zeng et al., 2023; Yin et al., 2024; Wang et al., 2024). Por exemplo, o Toolformer (Schick et al., 2023) faz o ajuste fino do GPT-J para lidar com apenas cinco ferramentas (por exemplo, calculadoras). Embora essa abordagem funcione bem em tarefas restritas, ela tem dificuldades em cenários realistas que contêm grandes quantidades de espaço de ação. O ToolBench (Qin et al., 2023) amplia o estudo introduzindo mais de 16.000 ferramentas, destacando os desafios da seleção de ferramentas em ambientes complexos.

Para realizar a seleção de ferramentas, as abordagens atuais normalmente empregam um pipeline de geração de recuperação, em que o modelo de linguagem grande primeiro recupera a ferramenta relevante e depois a explora (Patil et al., 2023; Qin et al., 2023). No entanto, a abordagem de pipeline enfrenta dois problemas principais: a passagem incorreta da etapa de recuperação e a dificuldade de os modelos de linguagem de grande porte entenderem e utilizarem totalmente as ferramentas por meio de avisos simples.

Para aliviar esses problemas, os pesquisadores tentaram representar as ações como Token e transformar a previsão de ações em tarefas generativas. Por exemplo, o RT2 (Brohan et al., 2023) gera tokens que representam ações de robôs, e o Self-RAG (Asai et al., 2023) usa tokens especiais para decidir quando recuperar um documento. O conceito é o mais próximo de nossa abordagem.

Nossa abordagem difere significativamente da do ToolkenGPT. Primeiro, nos concentramos em ferramentas reais que exigem parâmetros flexíveis para tarefas complexas (por exemplo, pesquisa de canais do YouTube), enquanto o ToolkenGPT se limita a ferramentas mais simples com menos entradas (por exemplo, funções matemáticas com dois números). Além disso, o ToolkenGPT depende de menos dicas de amostra, enquanto o ToolGen integra o conhecimento da ferramenta diretamente no modelo de linguagem maior por meio do ajuste fino completo dos parâmetros, permitindo que ele recupere e execute tarefas de forma autônoma. Por fim, nossos experimentos envolvem um conjunto muito maior de ferramentas - 47.000 ferramentas, em comparação com as 13-300 do ToolkenGPT.

Outros estudos, como o ToolPlanner (Wu et al., 2024b) e o AutoACT (Qiao et al., 2024), usaram o aprendizado por reforço ou sistemas multiagentes para aprimorar o aprendizado de ferramentas ou a conclusão de tarefas (Qiao et al., 2024; Liu et al., 2023; Shen et al., 2024; Chen et al., 2024a). Não comparamos essas abordagens com nosso modelo por dois motivos: (1) a maioria desses esforços depende de mecanismos de feedback como o Reflection (Shinn et al., 2023) ou modelos de recompensa, que são semelhantes ao design de avaliação do ToolBench, em que o modelo de linguagem grande serve como avaliador e não tem acesso às respostas reais. No entanto, esse não é o foco do nosso estudo, e nossos experimentos de ponta a ponta não dependem de tais mecanismos de feedback. (2) Nossa abordagem não entra em conflito com esses métodos, mas pode ser integrada. A exploração dessa integração é deixada para pesquisas futuras.

3 ToolGen

Nesta seção, primeiro apresentamos a representação simbólica usada no documento. Em seguida, descrevemos em detalhes a abordagem específica do ToolGen, incluindo virtualização de ferramentas, memória de ferramentas, treinamento de recuperação e ajuste de agentes de ponta a ponta, conforme mostrado na Figura 2. Por fim, apresentamos nossa metodologia de inferência.

Figura 2: Diagrama esquemático da estrutura do ToolGen. Na fase de virtualização de ferramentas, as ferramentas são mapeadas para tokens virtuais e, nas próximas três fases de treinamento, o ToolGen primeiro lembra as ferramentas prevendo os tokens de ferramentas a partir de documentos de ferramentas. Em seguida, o ToolGen aprende a recuperar ferramentas prevendo tokens de ferramentas a partir de consultas. Por fim, os dados do pipeline (ou seja, trajetórias) são usados para ajustar o modelo de recuperação no último estágio, gerando o modelo do agente ToolGen.

3.1 Conhecimento preparatório

Para uma determinada consulta de usuário q, o objetivo do aprendizado de ferramentas é resolver q usando ferramentas de um grande conjunto de ferramentas D={d1,d2,...,dN}, em que |D|=N é um número grande, o que torna impraticável incluir todas as ferramentas em D em um grande ambiente de modelagem de linguagem. Portanto, a pesquisa atual normalmente usa um recuperador R para recuperar k ferramentas relevantes de D, denotado como Dk,R={dr1,dr2,...,drk}=R(q,k,D), em que |Dk,R|≪N. O prompter final é uma concatenação de q e Dk,R, denotado como Prompt=[q,Dk,R]. Para concluir uma tarefa (consulta), os agentes baseados em grandes modelos de linguagem normalmente usam uma iteração de quatro estágios (Qu et al., 2024): geração de um plano pi , seleção de uma ferramenta dsi , determinação dos parâmetros da ferramenta ci e coleta de informações do feedback da ferramenta fi . Denotamos essas etapas como pi,dsi,ci,fi para a i-ésima iteração. O modelo continua a iterar por essas etapas até que a tarefa seja concluída, momento em que a resposta final a é gerada. A trajetória inteira pode ser representada como Traj=[Prompt,(p1,ds1,c1,f1),...,(pt,dst,ct,ft),a]=[q,R (q,D),(p1,ds1,c1,f1),...,(pt,dst,ct,ft),a]. Essa abordagem iterativa permite que o modelo ajuste e refine dinamicamente suas operações em cada etapa com base no feedback recebido, melhorando assim seu desempenho na realização de tarefas complexas.

3.2 Virtualização de ferramentas

No ToolGen, implementamos a virtualização de ferramentas mapeando cada ferramenta para um novo Token exclusivo por meio de uma abordagem chamada indexação atômica. Nessa abordagem, um token exclusivo é atribuído a cada ferramenta estendendo o vocabulário de um modelo de linguagem grande. A incorporação de cada token de ferramenta é inicializada com a incorporação média do nome da ferramenta correspondente, fornecendo assim um ponto de partida semanticamente significativo para cada ferramenta.

Formalmente, um conjunto de tokens é definido como T = Index(d)|∀d ∈ D, em que Index é uma função que mapeia ferramentas para tokens. Mostramos que a indexação atômica é mais eficiente e reduz os fenômenos fantasmas em comparação com outros métodos de indexação (por exemplo, mapeamentos semânticos e numéricos; veja 4.3 e 5.4 para discussão).

3.3 Memória da ferramenta

Depois de atribuir o token a uma ferramenta, o Big Language Model ainda não tem conhecimento sobre a ferramenta. Para resolver esse problema, ajustamos a descrição da ferramenta usando-a como entrada e o token correspondente como saída, referindo-nos a esse processo como memória da ferramenta. Usamos a seguinte função de perda:

em que θ denota os parâmetros do modelo de linguagem grande e ddoc denota a descrição da ferramenta. Esta etapa fornece os conceitos básicos da ferramenta e as operações relacionadas ao modelo de linguagem grande.

3.4 Treinamento de busca

Em seguida, treinamos o modelo de linguagem grande para associar o espaço oculto da ferramenta virtual Token (e seus documentos) com o espaço das consultas do usuário, de modo que o modelo possa gerar a ferramenta correta com base na consulta do usuário. Para isso, ajustamos o modelo de linguagem grande tomando as consultas do usuário como entrada e a ferramenta correspondente Token como saída:

onde θ′ denota os parâmetros do modelo de linguagem grande após a memória da ferramenta, Q é o conjunto de consultas do usuário e Dq é o conjunto de ferramentas associadas a cada consulta. Esse processo gera o recuperador ToolGen, permitindo que ele gere o Tool Token apropriado para uma determinada consulta do usuário.

3.5 Ajuste do agente de ponta a ponta

Após o treinamento de recuperação, o modelo do Big Language é capaz de gerar o Token de Ferramenta a partir da consulta. No estágio final, usamos tarefas do Agent-Flan para concluir o modelo de ajuste fino da trajetória. Adotamos uma estratégia de inferência semelhante à do Agent-Flan (Chen et al., 2024c), em que nosso pipeline usa um processo iterativo, em que o modelo primeiro gera o pensamento e, em seguida, gera o token de ação correspondente, que é usado para buscar o documento da ferramenta, que é então usado pelo modelo de Big Language para gerar os parâmetros necessários. O processo é iterado até que o modelo gere um token "done" ou atinja o número máximo de rodadas. A trajetória gerada é representada como Traj=[q,(p1,Index(ds1),c1,f1),...,(pt,Index(dst),ct,ft),a]. Nessa estrutura, a ferramenta de associação não é mais necessária.

3.6 Raciocínio

Durante o processo de raciocínio, um modelo de linguagem grande pode gerar tokens de ação além do conjunto predefinido de tokens de ferramentas. Para evitar isso, desenvolvemos um método de geração de pesquisa de pacote de restrições para limitar o token de saída ao conjunto de tokens de ferramentas. Aplicamos essa pesquisa de pacote restrito à recuperação de ferramentas (em que o modelo se baseia em uma ferramenta de seleção de consulta) e a sistemas de agentes de ponta a ponta, reduzindo efetivamente as ilusões na etapa de geração de ações. Consulte 5.4 para obter uma análise detalhada. Consulte o Apêndice C para obter detalhes da implementação.

4 Avaliação da recuperação de ferramentas

4.1 Configuração experimental

Usamos o modelo Llama-3-8B pré-treinado (Dubey et al., 2024) como modelo de base com um vocabulário de 128.256. 46.985 tokens foram adicionados durante a virtualização da ferramenta por meio do método de indexação atômica, resultando em um vocabulário final de 175.241. Fizemos o ajuste fino do modelo usando o modelo de bate-papo Llama-3 com um agendador de taxa de aprendizagem cosine e aplicando uma etapa de aquecimento de 3%. A taxa máxima de aprendizado foi de 4 × 10-5. Todos os modelos passaram pelo Deepspeed ZeRO 3 em 4 × GPUs A100 (Rajbhandari et al.2020) foram treinados. Foram realizadas oito rodadas de treinamento de memória de ferramentas e uma rodada de treinamento de recuperação.

conjunto de dados

Nossos experimentos são baseados no ToolBench, um benchmark de ferramentas do mundo real que contém mais de 16.000 coleções de ferramentas, cada uma contendo várias APIs, totalizando cerca de 47.000 APIs exclusivas. Cada API é documentada usando um dicionário que contém o nome da API, a descrição e os parâmetros de chamada. Consulte o Apêndice para ver um exemplo do mundo real ATratamos cada API como uma operação e a mapeamos para um token. Tratamos cada API como uma operação e a mapeamos para um token. Nossos dados de recuperação e ajuste de agente de ponta a ponta são convertidos dos dados brutos do ToolBench. Consulte o Apêndice para obter mais informações G. Embora cada ferramenta possa conter várias APIs, para simplificar, este documento se refere a cada API coletivamente como uma ferramenta.

Seguimos a metodologia de particionamento de dados de Qin et al. (2023) e classificamos os 200.000 pares (consultas, APIs associadas) em três categorias: I1 (consultas com uma única ferramenta), I2 (consultas com várias ferramentas em classes) e I3 (comandos com várias ferramentas em coleções), contendo 87.413, 84.815 e 25.251 instâncias, respectivamente.

Metodologia de linha de base

Comparamos o ToolGen com os seguintes benchmarks:

• BM25: um método clássico de recuperação não supervisionada baseado em TF-IDF com base na similaridade de palavras entre a consulta e o documento.
• Similaridade de incorporação (EmbSim): incorporação de frases geradas usando o modelo de incorporação de frases da OpenAI; especificamente text-embedding-3-large usado em nossos experimentos.
• Re-Invoke (Chen et al., 2024b): um método de recuperação não supervisionado que incorpora a reescrita de consultas e a expansão de documentos.
• IterFeedback (Xu et al., 2024): um recuperador baseado em BERT que usa o gpt-3.5-turbo-0125 como um modelo de feedback para até 10 rodadas de feedback iterativo.
• ToolRetriever (Qin et al., 2023): um recuperador baseado em BERT treinado por aprendizado por contraste.

configurar

Realizamos experimentos em duas configurações. Na primeira configuração, o In-Domain Retrieval restringe a recuperação de ferramentas cujo espaço de pesquisa está dentro do mesmo domínio. Por exemplo, ao avaliar as consultas no domínio I1, ela se limita às ferramentas em I1. Essa configuração é consistente com a configuração do ToolBench. A segunda configuração, Multi-Domain Retrieval (Recuperação em vários domínios), é mais complexa, em que o espaço de pesquisa é ampliado para ferramentas em todos os três tipos de domínios. Nesse caso, o modelo é treinado em dados mesclados, aumentando o espaço de pesquisa e a complexidade da tarefa. Ao contrário do ToolBench, a configuração de vários domínios reflete cenários realistas em que as tarefas de recuperação podem envolver domínios sobrepostos ou mistos. Essa configuração avalia a capacidade do modelo de generalizar entre domínios e lidar com tarefas de recuperação mais complexas e diversas.

norma

Avaliamos o desempenho da recuperação usando o ganho cumulativo com desconto normalizado (NDCG) (Järvelin & Kekäläinen, 2002), uma métrica amplamente usada em tarefas de classificação, incluindo a recuperação de ferramentas.

Tabela 1: Avaliação da recuperação de ferramentas em duas configurações: (1) recuperação intra-domínio, em que os modelos são treinados e avaliados nos mesmos domínios, e (2) recuperação multi-domínio, em que os modelos são treinados em todos os domínios e avaliados no conjunto completo de ferramentas de todos os domínios. é um sistema de recuperação com vários modelos e mecanismos de feedback. O ToolRetriever é treinado usando o aprendizado por contraste, enquanto o ToolGen é treinado usando a previsão do próximo token. Os itens com * nos resultados indicam modelos que não foram implementados por nós, e os dados são provenientes do documento original e, portanto, estão listados apenas na configuração no domínio. Para o ToolGen na configuração no domínio, permitimos que o espaço de geração inclua todos os tokens, o que é um cenário mais desafiador em comparação com outros modelos. Os melhores resultados em cada categoria estão marcados em negrito.

4.2 Resultados

A Tabela 1 mostra os resultados da recuperação de ferramentas. Como esperado, todos os modelos treinados superam significativamente a linha de base não treinada (BM25, EmbSim e Re-Invoke) em todas as métricas, mostrando as vantagens do treinamento em dados de recuperação de ferramentas.

Nosso modelo proposto ToolGen tem o melhor desempenho consistente em ambas as configurações. Na configuração no domínio, o ToolGen fornece resultados altamente competitivos, com desempenho comparável ao do sistema IterFeedback usando vários modelos e mecanismos de feedback. Como um único modelo, o ToolGen supera significativamente o ToolRetriever em todas as métricas e supera até mesmo o IterFeedback em vários cenários (por exemplo, NDCG@5 para o domínio I1 e NDCG@1, @3, @5 para I2).

Na configuração multidomínio, o ToolGen permanece robusto, superando o ToolRetriever e ficando à frente dos modelos de linha de base, apesar do espaço de busca maior e da queda usual no desempenho geral. Isso mostra que o ToolGen, apesar de ser um modelo único, ainda pode competir com sistemas de recuperação complexos como o IterFeedback, demonstrando sua capacidade de lidar com tarefas de recuperação complexas do mundo real com limites de domínio pouco claros.

4.3 Comparação de métodos de indexação

Embora o ToolGen use índices atômicos para virtualização de ferramentas, também exploramos vários métodos alternativos de recuperação generativa. Nesta seção, comparamos esses métodos com as três abordagens a seguir:

• Digital: mapeia cada ferramenta para um número exclusivo. O token gerado é puramente digital, não fornecendo nenhuma informação semântica intrínseca, mas um identificador exclusivo para cada ferramenta.
• Hierárquico: esse método agrupa as ferramentas em grupos não sobrepostos e divide recursivamente esses agrupamentos para formar uma estrutura hierárquica. Um índice do nó raiz para os nós folha nessa estrutura representa cada ferramenta, semelhante à técnica de agrupamento de Brown.
• Semântica: nessa abordagem, cada ferramenta é mapeada para seu nome, o que orienta o Modelo de Linguagem Ampla (LLM) por meio do conteúdo semântico do nome da ferramenta. O nome da ferramenta fornece diretamente uma representação significativa relacionada à sua função.

Figura 3: A distribuição do número de sub-Tokens por ferramenta é diferente em cada método de indexação. A indexação atômica garante que cada ferramenta seja um único token, enquanto a indexação numérica codifica as ferramentas em N tokens, ou seja, o número da ferramenta está no intervalo (10N-1,10N]. Por outro lado, a indexação semântica e a indexação hierárquica produzem números variáveis de sub-Tokens, sendo que a indexação semântica tem uma sequência mais longa de sub-Tokens e mais outliers.

Os detalhes específicos da implementação estão descritos no Apêndice B.

Primeiro, analisamos o número de sub-Tokens exigidos por cada método para representar cada ferramenta, conforme mostrado na Figura 3. O gráfico destaca a superioridade da indexação atômica, em que cada ferramenta é representada por um único token, enquanto os outros métodos exigem vários tokens. Essa eficiência permite que o ToolGen reduza o número de geração de tokens e diminua o tempo de raciocínio em cenários de recuperação e agente.

Em seguida, examinamos a eficácia dos diferentes métodos de indexação. Conforme mostrado na Tabela 2, a indexação semântica apresenta o melhor desempenho de recuperação em várias métricas e cenários, enquanto a indexação atômica fica em segundo lugar em muitos casos. Atribuímos isso ao fato de que a indexação semântica corresponde melhor aos dados pré-treinados do modelo de linguagem grande. No entanto, essa vantagem diminui à medida que os dados e os tipos de treinamento aumentam. Por exemplo, na Seção 5.3, mostramos que os índices atômicos têm melhor desempenho nos resultados de ponta a ponta. Levando em conta esses fatores, escolhemos índices atômicos para a virtualização de ferramentas do ToolGen.

Tabela 2: Avaliações de recuperação de diferentes métodos de indexação na configuração de vários domínios. Os melhores resultados estão em negrito e os próximos melhores resultados estão sublinhados.

Tabela 3: Estudos de ablação para recuperação de ferramentas. Os efeitos da remoção do treinamento de recuperação, da memória de ferramentas e da pesquisa de feixe restrito no desempenho do ToolGen são avaliados separadamente.

4.4 Experimentos de ablação

Realizamos experimentos de ablação para avaliar os efeitos de diferentes fases de treinamento do ToolGen, conforme mostrado na Tabela 3 Mostrado. Os resultados mostram que o treinamento de recuperação é um fator importante que afeta o desempenho da recuperação de ferramentas, pois alinha diretamente a tarefa de recuperação em que a entrada é uma consulta e a saída é um token de ferramenta. A remoção das memórias de ferramentas resulta em uma ligeira queda no desempenho, embora seja útil para melhorar o desempenho da generalização, como mostraremos no Apêndice F discutido mais adiante. Da mesma forma, a pesquisa restrita de pacotes, embora contribua pouco para a tarefa de recuperação, ajuda a evitar a geração de alucinações e, portanto, tem algum valor em tarefas de agente de ponta a ponta, consulte a Seção 5.4.

5 Avaliação de ponta a ponta

5.1 Configuração experimental

Fizemos várias alterações nos dados de rastreamento do ToolBench para adaptá-los à estrutura do ToolGen. Por exemplo, como o ToolGen não exige a seleção explícita de ferramentas relevantes como entrada, removemos essas informações dos prompts do sistema. Para obter mais detalhes, consulte o Apêndice G. Com base nisso, ajustamos o modelo de recuperação usando os dados reformatados para gerar um agente ToolGen de ponta a ponta.

modelo de linha de base

• GPT-3.5: usamos o gpt-3.5-turbo-0613 como um dos modelos de linha de base. A implementação é a mesma do StableToolBench (Guo et al., 2024), em que a funcionalidade de chamada de ferramentas do GPT-3.5 é usada para formar agentes de ferramentas.
• ToolLlama-2: Qin et al. (2023) introduziram o ToolLlama-2 por meio do ajuste fino do modelo Llama-2 (Touvron et al., 2023) nos dados do ToolBench.
• ToolLlama-3: para garantir uma comparação justa, criamos o modelo de linha de base ToolLlama-3 ajustando o mesmo modelo de base Llama-3 do ToolGen no conjunto de dados ToolBench. No restante deste documento, o ToolLlama-3 é chamado de ToolLlama para diferenciá-lo do ToolLlama-2.

configurar

• Uso de Ferramentas Genuínas (G.T.): com base em Qin et al. (2023), definimos as Ferramentas Genuínas para consultas como ChatGPT Ferramenta selecionada. Para o ToolLlama, inserimos a ferramenta real diretamente no prompt, no mesmo formato dos dados de treinamento. Para o ToolGen, como ele não foi treinado com os dados da ferramenta pré-selecionada, adicionamos o prefixo: I am using the following tool: [tool tokens] in the planning phase, onde [tool tokens] é um token virtual correspondente à ferramenta real.
• Uso de recuperadores: nos experimentos de ponta a ponta, usamos uma configuração baseada em recuperação. Para o modelo de linha de base, usamos ferramentas recuperadas pelo ToolRetriever como ferramentas associadas. O ToolGen, por outro lado, gera tokens de ferramentas diretamente e, portanto, não usa um recuperador.

Todos os modelos foram ajustados usando um agendador de cosseno com a taxa máxima de aprendizado definida como 4 × 10-5. O comprimento do contexto foi truncado para 6.144 e o tamanho total do lote para 512. Usamos ainda o Flash-Attention (Dao et al., 2022; Dao, 2024) e o Deepspeed ZeRO 3 ( Rajbhandari et al., 2020) para economizar memória.

O ToolGen e o ToolLlama seguem paradigmas diferentes para concluir a tarefa; o ToolLlama gera ideias, ações e parâmetros em uma única rodada, enquanto o ToolGen separa essas etapas. Para o ToolGen, definimos um limite de até 16 rodadas, permitindo 5 rodadas de ações e 1 rodada de respostas finais. Comparamos isso com o limite de 6 rodadas do ToolLlama.

Além disso, introduzimos um mecanismo de repetição para todos os modelos a fim de evitar o término prematuro, cujos detalhes estão descritos no Apêndice D. Especificamente, se um modelo gerar uma resposta que contenha "desista" ou "desculpe", solicitamos que o modelo gere novamente a resposta em uma temperatura mais alta.

Avaliação de indicadores

Para avaliação de ponta a ponta, usamos o benchmark de avaliação de ferramenta estável StableToolBench (Guo et al., 2024), que seleciona consultas solucionáveis do ToolBench e simula a saída de ferramentas com falha usando GPT-4 (OpenAI, 2024). Avaliamos o desempenho usando duas métricas: a taxa de aprovação solucionável (SoPR), que é a porcentagem de consultas resolvidas com sucesso, e a taxa de vitória solucionável (SoWR), que indica a porcentagem de respostas que superam o modelo de referência (GPT-3.5 neste estudo). Além disso, fornecemos as pontuações micro-médias para cada categoria.

Tabela 4: Desempenho da avaliação de ponta a ponta de comandos não vistos em duas configurações. Para a configuração R., o GPT-3.5 e o ToolLlama usam o ToolRetriever, enquanto o ToolGen não usa um recuperador externo. Todas as avaliações SoPR e SoWR resultantes são realizadas três vezes e relatadas como valores médios.

5.2 Resultados

A Tabela 4 mostra o desempenho da avaliação de ponta a ponta de cada modelo em dois ambientes: usando a ferramenta real (G.T.) e o retriever (R.). No ambiente G.T., o ToolGen atinge uma pontuação média de SoPR de 54,19, superando o GPT-3.5 e o ToolLlama, e o ToolGen atinge a maior pontuação de SoWR de 49,70. O ToolGen ainda mantém a liderança no ambiente Retriever, com uma média de SoPR de 53,28 e SoWR de 51,51. O ToolLlama demonstrou competitividade, superando o ToolGen em algumas instâncias individuais. Um estudo de ablação de ponta a ponta do ToolGen é apresentado no Apêndice G.

Tabela 5: Avaliação de ponta a ponta de diferentes métodos de indexação.

5.3 Comparação de métodos de indexação

Da mesma forma que a comparação dos métodos de indexação para a tarefa de recuperação (Seção 4.3), a Tabela 5 mostra uma comparação dos diferentes métodos de indexação na tarefa de agente de ponta a ponta. Nessa configuração, a decodificação restrita é removida, permitindo que o agente gere livremente Pensamento, Ação e Parâmetros. A partir dos resultados, o método de indexação atômica tem o melhor desempenho entre os quatro métodos de indexação. Atribuímos isso às taxas fantasmas mais altas dos outros métodos, conforme discutido na Seção 5.4.

Figura 4: Mostra a taxa fantasma de diferentes modelos ao gerar ferramentas inexistentes. O ToolGen não gera ferramentas inexistentes ao usar a decodificação restrita. No entanto, sem essa restrição, o ToolGen gera 7% de tokens sem ferramentas na fase de geração de ações ao usar a indexação atômica, e a taxa de ilusão é maior ao usar a indexação semântica. Para o ToolLlama e o GPT-3.5, a ilusão ocorre mesmo que cinco ferramentas reais sejam fornecidas na dica. Se nenhuma ferramenta for especificada na dica, o ToolLlama gera nomes de ferramentas inexistentes em um número superior a 50%.

5.4 Alucinações

Avaliamos a situação fantasma do modelo na geração de ferramentas em um cenário de agente de ponta a ponta. Para isso, inserimos consultas que são formatadas de forma consistente com o treinamento do modelo. Especificamente, para o ToolGen, inserimos diretamente a consulta e solicitamos ao modelo que gere a resposta de acordo com o paradigma do agente ToolGen (ou seja, Pensamento, Ferramenta e Parâmetros em ordem). Testamos a decodificação de ações sem as restrições de pesquisa de pacotes descritas na Seção 3.6. Para o ToolLlama e o GPT-3.5, inserimos consultas e incluímos 5 ferramentas reais. Em todas as configurações, relatamos a proporção de ferramentas não presentes no conjunto de dados entre as geradas em todas as ações de geração de ferramentas. A Figura 4 ilustra a taxa fantasma de ferramentas inexistentes geradas por diferentes modelos. Como pode ser visto na figura, o ToolLlama e o GPT-3.5 ainda têm a probabilidade de gerar nomes de ferramentas inexistentes, apesar do fato de que apenas cinco ferramentas reais são fornecidas. Em contrapartida, o ToolGen evita completamente as alucinações por meio de seu projeto de decodificação restrito.

6 Conclusão

Neste artigo, apresentamos o ToolGen, uma estrutura de modelagem de linguagem ampla (LLM) que unifica a recuperação e a execução de ferramentas ao incorporar tokens virtuais específicos da ferramenta em um vocabulário de modelo, transformando assim a interação da ferramenta em uma tarefa generativa. Ao incluir um processo de treinamento em três estágios, o ToolGen capacita os LLMs a recuperar e executar ferramentas com eficiência em cenários reais. Essa abordagem unificada estabelece uma nova referência para agentes de IA dimensionáveis e eficientes, capazes de lidar com grandes bibliotecas de ferramentas. No futuro, o ToolGen abre as portas para a integração de tecnologias avançadas, como raciocínio de cadeia de pensamento, aprendizado por reforço e ReAct, aumentando ainda mais a autonomia e a versatilidade do LLM em aplicativos do mundo real.

Referências

• Asai et al. (2023) ↑Akari Asai, Zeqiu Wu, Yizhong Wang, Avirup Sil e Hannaneh Hajishirzi.Self-rag: Learning to retrieve, generate, and critique por meio da autorreflexão, 2023.URL https://arxiv.org/abs/2310.11511.
• Brohan et al. (2023)↑ Anthony Brohan, Noah Brown, Justice Carbajal, Yevgen Chebotar, Xi Chen, Krzysztof Choromanski, Tianli Ding, Danny Driess, Avinava Dubey, Chelsea Finn, Pete Florence, Chuyuan Fu, Montse Gonzalez Arenas, Keerthana Gopalakrishnan, Kehang Han, Karol Avinava Dubey, Chelsea Finn, Pete Florence, Chuyuan Fu, Montse Gonzalez Arenas, Keerthana Gopalakrishnan, Kehang Han, Karol Hausman, Alexander Herzog, Jasmine Hsu, Brian Ichter, Alex Irpan, Nikhil Joshi, Ryan Julian, Dmitry Kalashnikov, Yuheng Kuang, Isabel Leal, Lisa Lee, Tsang-Wei Edward Lee Sergey Levine, Yao Lu, Henryk Michalewski, Igor Mordatch, Karl Pertsch, Kanishka Rao, Krista Reymann, Michael Ryoo, Grecia Salazar, Pannag Sanketi, Pierre Sermanet, Jaspil Joshi, Ryan Julian, Dmitry Kalashnikov, Yuheng Kuang, Isabel Leal, Lisa Lee, Tsang-Wei Edward Lee Pierre Sermanet, Jaspiar Singh, Anikait Singh, Radu Soricut, Huong Tran, Vincent Vanhoucke, Quan Vuong, Ayzaan Wahid, Stefan Welker, Paul Wohlhart. Jialin Wu, Fei Xia, Ted Xiao, Peng Xu, Sichun Xu, Tianhe Yu e Brianna Zitkovich.Rt-2: Modelos de visão-linguagem-ação transferem conhecimento da Web para controle robótico, 2023.URL https://arxiv.org/abs/2307.15818.
• Brown et al. (2020) ↑Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam. Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler. Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gray, Benjamin Chess, Jack Clark, Christopher Berner, Sam McCandlish, Alec Radford, Ilya Sutskever e Dario Amodei.Language models are few-shot learners.In Hugo Larochelle, Marc'Aurelio Ranzato, Raia Hadsell, Maria-Florina Balcan e Hsuan-Tien Lin (eds.). Avanços em sistemas de processamento de informações neurais 33: Conferência anual sobre sistemas de processamento de informações neurais 2020, NeurIPS 2020, de 6 a 12 de dezembro, 2020, virtual, 2020.URL https://proceedings.neurips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html.
• Chen et al. (2023a) ↑Baian Chen, Chang Shu, Ehsan Shareghi, Nigel Collier, Karthik Narasimhan e Shunyu Yao.Fireact: Toward language agent fine- de linguagem.arXiv preprint arXiv:2310.05915, 2023a.
• Chen et al. (2023b)↑Jiangui Chen, Ruqing Zhang, Jiafeng Guo, Maarten de Rijke, Wei Chen, Yixing Fan e Xueqi Cheng.Continual Learning for Generative Retrieval over Dynamic Corpora. Retrieval over Dynamic Corpora.In Anais da 32ª Conferência Internacional da ACM sobre Gestão da Informação e do ConhecimentoCIKM '23, pp. 306-315, Nova York, NY, EUA, 2023b. Association for Computing Machinery. isbn 9798400701245. doi: 10.1145/ 3583780.3614821.URL https://dl.acm.org/doi/10.1145/3583780.3614821.
• Chen et al. (2024a)↑Junzhi Chen, Juhao Liang e Benyou Wang.Smurfs: Aproveitamento de vários agentes de proficiência com eficiência de contexto para planejamento de ferramentas planejamento de ferramentas, 2024a.URL https://arxiv.org/abs/2405.05955.
• Chen et al. (2024b)↑Yanfei Chen, Jinsung Yoon, Devendra Singh Sachan, Qingze Wang, Vincent Cohen-Addad, Mohammadhossein Bateni, Chen-Yu Lee e Tomas Pfister. Tomas Pfister.Re-invoke: reescrita de invocação de ferramenta para recuperação de ferramenta zero-shot.arXiv preprint arXiv:2408.01875, 2024b.
• Chen et al. (2024c)↑Zehui Chen, Kuikun Liu, Qiuchen Wang, Wenwei Zhang, Jiangning Liu, Dahua Lin, Kai Chen e Feng Zhao.Agent-flan: projetando dados e métodos de ajuste eficaz de agentes para grandes modelos de linguagem, 2024c.URL https://arxiv.org/abs/2403.12881.
• Dao (2024)↑Tri Dao.FlashAttention-2: atenção mais rápida com melhor paralelismo e particionamento de trabalho.In Conferência Internacional sobre Representações de Aprendizagem (ICLR), 2024.
• Dao et al. (2022)↑Tri Dao, Daniel Y. Fu, Stefano Ermon, Atri Rudra e Christopher Ré. FlashAttention: atenção exata rápida e eficiente em termos de memória com reconhecimento de IO. IO-awareness.In Avanços em sistemas de processamento de informações neurais (NeurIPS), 2022.
• Dubey et al. (2024)↑Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, Angela Fan, et al. The llama 3 herd of models.arXiv preprint arXiv:2407.21783, 2024.
• Gravitas (2023)↑Gravitas.AutoGPT, 2023.URL https://github.com/Significant-Gravitas/AutoGPT.
• Guo et al. (2024)↑Zhicheng Guo, Sijie Cheng, Hao Wang, Shihao Liang, Yujia Qin, Peng Li, Zhiyuan Liu, Maosong Sun e Yang Liu.StableToolBench: Towards StableToolBench: Towards Stable Large-Scale Benchmarking on Tool Learning of Large Language Models, 2024.URL https://arxiv.org/abs/2403.07714.
• Hao et al. (2023)↑Shibo Hao, Tianyang Liu, Zhen Wang e Zhiting Hu.Toolkengpt: Augmenting frozen language models with massive tools via tool embeddings. Em Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt e Sergey Levine (eds.) Avanços nos sistemas de processamento de informações neurais 36: Conferência anual sobre sistemas de processamento de informações neurais 2023, NeurIPS 2023, Nova Orleans, LA, EUA, 10 a 16 de dezembro de 2023 EUA, 10 a 16 de dezembro de 2023, 2023.URL http://papers.nips.cc/paper_files/paper/2023/hash/8fd1a81c882cd45f64958da6284f4a3f-Abstract-Conference.html.
• Järvelin & Kekäläinen (2002)↑Kalervo Järvelin e Jaana Kekäläinen.Cumulated gain-based evaluation of ir techniques.Transações ACM sobre sistemas de informação (TOIS), 20(4):422-446, 2002.
• Karpukhin et al. (2020)↑Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen e Wen-tau Yih.Dense passage Dense passage retrieval for open-domain question answering.In Bonnie Webber, Trevor Cohn, Yulan He e Yang Liu (eds.) Anais da Conferência de 2020 sobre métodos empíricos em processamento de linguagem natural (EMNLP), pp. 6769-6781, Online, 2020. association for Computational Linguistics. doi: 10.18653/v1/2020.emnlp-main.550.URL https://aclanthology.org/2020.emnlp-main.550.
• Kishore et al. (2023)↑Varsha Kishore, Chao Wan, Justin Lovelace, Yoav Artzi e Kilian Q. Weinberger.Incdsi: Incrementally updatable document retrieval. Em Andreas Krause, Emma Brunskill, Kyunghyun Cho, Barbara Engelhardt, Sivan Sabato e Jonathan Scarlett (eds.). Conferência Internacional sobre Aprendizado de Máquina, ICML 2023, 23-29 de julho de 2023, Honolulu, Havaí, EUA, volume 202 de Anais da Pesquisa de Aprendizado de MáquinaPMLR, 2023.URL https://proceedings.mlr.press/v202/kishore23a.html.
• Liu et al. (2024)↑Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, et al. Agentbench. Avaliação de llms como agentes. Décima segunda Conferência Internacional sobre Representações de Aprendizagem, 2024.
• Liu et al. (2023)↑ Zhiwei Liu, Weiran Yao, Jianguo Zhang, Le Xue, Shelby Heinecke, Rithesh Murthy, Yihao Feng, Zeyuan Chen, Juan Carlos Niebles, Devansh Arpit, et al. Bolaa: Benchmarking and orchestrating llm-augmented autonomous agents.arXiv preprint arXiv:2308.05960, 2023.
• Mehta et al. (2023)↑Sanket Vaibhav Mehta, Jai Gupta, Yi Tay, Mostafa Dehghani, Vinh Q. Tran, Jinfeng Rao, Marc Najork, Emma Strubell e Donald Metzler. DSI++: atualização da memória do transformador com novos documentos. Anais da Conferência 2023 sobre Métodos Empíricos em Processamento de Linguagem NaturalAssociação para Linguística Computacional. doi: 10.18653/v1/2023.emnlp-main.510.URL https://aclanthology.org/2023.emnlp-main.510.
• OpenAI (2024)↑Relatório técnico OpenAI.Gpt-4, 2024.URL https://arxiv.org/abs/2303.08774.
• Patil et al. (2023) ↑Shishir G. Patil, Tianjun Zhang, Xin Wang e Joseph E. Gonzalez.Gorilla: modelo de linguagem grande conectado com apis maciços, 2023. URL https://arxiv.org/abs/2305.15334.
• Qiao et al. (2024)↑Shuofei Qiao, Ningyu Zhang, Runnan Fang, Yujie Luo, Wangchunshu Zhou, Yuchen Eleanor Jiang, Chengfei Lv e Huajun Chen.Autoact. Aprendizagem automática de agentes do zero para qa por meio de planejamento automático, 2024.URL https://arxiv.org/abs/2401.05268.
• Qin et al. (2023)↑Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, Sihan Zhao, Lauren Hong, Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu e Maosong Sun. Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu e Maosong Sun. ToolLLM: Facilitando modelos de linguagem grandes para dominar mais de 16.000 APIs do mundo real, 2023 APIs do mundo real, 2023.URL https://arxiv.org/abs/2307.16789.
• Qu et al. (2024)↑Changle Qu, Sunhao Dai, Xiaochi Wei, Hengyi Cai, Shuaiqiang Wang, Dawei Yin, Jun Xu e Ji-Rong Wen. Aprendizado de ferramentas com modelos de linguagem grandes: uma pesquisa.arXiv preprint arXiv:2405.17935, 2024.
• Rajbhandari et al. (2020)↑Samyam Rajbhandari, Jeff Rasley, Olatunji Ruwase e Yuxiong He.Zero: Otimizações de memória para treinamento de trilhões de modelos de parâmetros, 2020.URL https://arxiv.org/abs/1910.02054.
• Robertson et al. (2009) ↑Stephen Robertson, Hugo Zaragoza, et al. The probabilistic relevance framework: bm25 and beyond.Foundations and Trends® in Information Retrieval (Fundamentos e Tendências® em Recuperação de Informações), 3(4):333-389, 2009.
• Schick et al. (2023)↑Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda e Thomas Scialom. Scialom.Toolformer: modelos de linguagem podem ensinar a si mesmos a usar ferramentas, 2023.URL https://arxiv.org/abs/2302.04761.
• Shen et al. (2024)↑Weizhou Shen, Chenliang Li, Hongzhan Chen, Ming Yan, Xiaojun Quan, Hehong Chen, Ji Zhang e Fei Huang.Small llms are weak tool aprendizes: um agente multi-llm, 2024.URL https://arxiv.org/abs/2401.07324.
• Shinn et al. (2023)↑Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan e Shunyu Yao.Reflexion: agentes de linguagem com aprendizado por reforço verbal. aprendizagem por reforço verbal.In Anais da 37ª Conferência Internacional sobre Sistemas de Processamento de Informações Neurais, pp. 8634-8652, 2023.
• Sun et al. (2023)↑Weiwei Sun, Lingyong Yan, Zheng Chen, Shuaiqiang Wang, Haichao Zhu, Pengjie Ren, Zhumin Chen, Dawei Yin, Maarten de Rijke e Zhaochun Ren. Ren.Learning to tokenize for generative retrieval.In Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt e Sergey Levine (eds.) Avanços nos sistemas de processamento de informações neurais 36: Conferência anual sobre sistemas de processamento de informações neurais 2023, NeurIPS 2023, Nova Orleans, LA, EUA, 10 a 16 de dezembro de 2023 EUA, 10 a 16 de dezembro de 2023, 2023.URL http://papers.nips.cc/paper_files/paper/2023/hash/91228b942a4528cdae031c1b68b127e8-Abstract-Conference.html.
• Touvron et al. (2023)↑Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie-Anne Lachaux, Timothée Lacroix, Baptiste Rozière, Naman Goyal, Eric Hambro, Faisal Azhar, Aurelien Rodriguez, Armand Joulin, Edouard Grave e Guillaume Lample.Llama: open and efficient foundation modelos de linguagem, 2023.URL https://arxiv.org/abs/2302.13971.
• Wang et al. (2024)↑Renxi Wang, Haonan Li, Xudong Han, Yixuan Zhang e Timothy Baldwin.Learning from failure: integrating negative examples when fine -ao ajustar grandes modelos de linguagem como agentes.arXiv preprint arXiv:2402.11651, 2024.
• Wang et al. (2022)↑Yujing Wang, Yingyan Hou, Haonan Wang, Ziming Miao, Shibin Wu, Qi Chen, Yuqing Xia, Chengmin Chi, Guoshuai Zhao, Zheng Liu, Xing Xie, Hao Sun, Weiwei Deng, Qi Zhang e Mao Yang. Hao Sun, Weiwei Deng, Qi Zhang e Mao Yang.A neural corpus indexer for document retrieval. Em Sanmi Koyejo, S. Mohamed, A. Agarwal, Danielle Belgrave, K. Cho e A. Oh (2008), um indexador de corpus neural para recuperação de documentos. Cho e A. Oh (eds.). Avanços em sistemas de processamento de informações neurais 35: Conferência anual sobre sistemas de processamento de informações neurais 2022, NeurIPS 2022, Nova Orleans, LA, EUA, 28 de novembro a 9 de dezembro de 2022 Nova Orleans, LA, EUA, 28 de novembro a 9 de dezembro de 2022, 2022.URL http://papers.nips.cc/paper_files/paper/2022/hash/a46156bd3579c3b268108ea6aca71d13-Abstract-Conference.html.
• Wei et al. (2023)↑Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le e Denny Zhou.Chain-of-thought elicits elicits reasoning in large language models, 2023.URL https://arxiv.org/abs/2201.11903.
• Wu et al. (2024a)↑Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W White, Doug Burger e Chi Wang. Awadallah, Ryen W White, Doug Burger e Chi Wang.Autogen: habilitando aplicativos de última geração de llm por meio de uma estrutura de conversação com vários agentes.In COLM, 2024a.
• Wu et al. (2024b)↑Qinzhuo Wu, Wei Liu, Jian Luan e Bin Wang.ToolPlanner: uma ferramenta LLM aumentada para instruções de granularidade múltipla com planejamento de caminho e feedback, 2024b.URL https://arxiv.org/abs/2409.14826.
• Xiong et al. (2021)↑Lee Xiong, Chenyan Xiong, Ye Li, Kwok-Fung Tang, Jialin Liu, Paul N. Bennett, Junaid Ahmed e Arnold Overwijk.Approximate nearest neighbour negative contrastive learning for dense text retrieval. aprendizado contrastivo negativo do vizinho mais próximo para recuperação de textos densos. 9ª Conferência Internacional sobre Representações de Aprendizagem, ICLR 2021, Evento Virtual, Áustria, 3 a 7 de maio de 2021. OpenReview.net, 2021.URL https://openreview.net/forum?id=zeFrfgyZln.
• Xu et al. (2024)↑Qiancheng Xu, Yongqi Li, Heming Xia e Wenjie Li.Aprimorando a recuperação de ferramentas com feedback iterativo de grandes modelos de linguagem.arXiv preprint arXiv:2406.17465, 2024.
• Yao et al. (2023)↑Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan e Yuan Cao.ReAct: sinergia entre raciocínio e ação em modelos de linguagem. modelos de linguagem.In Conferência Internacional sobre Representações de Aprendizagem (ICLR), 2023.
• Yin et al. (2024)↑Da Yin, Faeze Brahman, Abhilasha Ravichander, Khyathi Chandu, Kai-Wei Chang, Yejin Choi e Bill Yuchen Lin.Agent lumos: Unified and modular training for open-source language agents. Lun-Wei Ku, André Martins e Vivek Srikumar (eds.). Anais da 62ª Reunião Anual da Association for Computational Linguistics (Volume 1: Long Papers)Associação para Linguística Computacional. doi: 10.18653/v1/2024.acl-long.670. URL https://aclanthology.org/2024.acl-long.670.
• Zeng et al. (2023) ↑Aohan Zeng, Mingdao Liu, Rui Lu, Bowen Wang, Xiao Liu, Yuxiao Dong e Jie Tang.Agenttuning: enabling generalised agent abilities para llms, 2023.

Um exemplo de uma ferramenta real

mapa 5 É mostrado um exemplo de uma ferramenta real. Cada ferramenta contém várias APIs. Os seguintes campos são usados em nossos experimentos: "tool_name" é o nome da ferramenta. "tool_description" descreve informações sobre a ferramenta, como o que ela faz. Em cada API, "name" é o nome da API. "description" descreve informações sobre a API. "method" é o método http que chama a API. "required_parameters" são os parâmetros que devem ser preenchidos ao chamar a API. "optional_parameters" pode ser usado para definir parâmetros adicionais (opcionais).

{
"nome_da_ferramenta": "YouTube Hub",.
"tool_description": "Obtenha detalhes sobre o número de curtidas, visualizações, título, miniatura etc. de um único vídeo." ,
"home_url": "https://rapidapi.com/itsrohitofficial-XBPdXttOUQ/api/youtube-hub/",
"host": "youtube-hub.p.rapidapi.com",
"api_list":[
{
"name": "Get Video Details" (Obter detalhes do vídeo),
"url": "https://youtube-hub.p.rapidapi.com/",
"description": "Obter todas as informações básicas sobre um vídeo",

"required_parameters":[
{
"name": "id",
"type": "STRING",
"description":"",
"default": "fD6SzYIRr4c"
}
], "optional_parameters".
"optional_parameters":[], .
}
]
}

Figura 5: Um exemplo de uma ferramenta real. A ferramenta contém uma API e os campos desnecessários foram removidos para simplificar.

B Implementação da virtualização de ferramentas

O ToolGen usa um único token exclusivo para representar uma ferramenta, o que demonstra sua força na recuperação e invocação de ferramentas. Também introduzimos outros métodos de indexação de ferramentas, incluindo semântico, numérico e hierárquico. Abaixo está uma descrição detalhada de como implementamos cada tipo de indexação.

atômico

A indexação é o método que usamos no ToolGen. Em contraste com outros métodos, ele usa um único Token como ferramenta e não falsifica uma ferramenta que não existe. Usamos <> para combinar o nome da ferramenta e o nome da API em um único token. A O exemplo nesta seção resulta em um token de <>.

significado das palavras

O índice mapeia cada ferramenta para um nome usado no ToolBench, que também é uma combinação do nome da ferramenta e do nome da API. No entanto, o nome pode ser dividido em vários tokens para que o modelo possa perceber seu significado semântico. No exemplo do Apêndice A, o mapeamento resultante é get_video_details_for_youtube_hub.

numérico

O índice mapeia cada ferramenta em um número exclusivo. Começamos obtendo uma lista de todas as ferramentas, que tem cerca de 47.000 caracteres, e para todas as ferramentas usamos um número de cinco dígitos, separado por espaços, para representar a ferramenta. Se o exemplo no Apêndice A for o 128º elemento da lista, usaremos 0 0 0 0 0 1 2 8 para representar a ferramenta. Como o lexer Llama-3 codifica cada dígito

camadas

também mapeia cada ferramenta em um número. Diferentemente do índice numérico, injetamos informações estruturais na representação da ferramenta por meio de agrupamento iterativo. Em cada iteração, agrupamos as ferramentas em dez grupos, cada um com um número de 0 a 9. Para cada cluster, repetimos esse processo de agrupamento até que haja apenas uma ferramenta nesse cluster. Essas etapas formam uma árvore de agrupamento. Vamos da raiz para os números das folhas como uma representação das ferramentas naquela folha. Os exemplos no Apêndice A podem receber um número maior que cinco dígitos, como 0 1 2 2 3 3 3.

C Detalhes da pesquisa de restrições

Ao recuperar e concluir tarefas de agente de ponta a ponta, usamos a pesquisa de pacote restrita para restringir as operações geradas a tokens de ferramentas válidos. As etapas detalhadas estão descritas no Algoritmo 1. Para isso, primeiro construímos uma árvore de dicionário disjunta, em que cada nó representa uma ID de token de ferramenta e os filhos desse nó são todas as IDs viáveis que seguem a ID atual. inviáveis, forçando as possíveis IDs a serem amostradas ou pesquisadas.

Para a recuperação, isso pode ser aplicado diretamente durante a geração. Para a tarefa de agente de ponta a ponta, como decompomos a etapa de raciocínio em três rodadas de diálogo, podemos detectar facilmente quando o ToolGen precisa gerar uma ação e, portanto, aplicar a restrição. A Figura 6 mostra um exemplo de raciocínio de ponta a ponta para o ToolGen, onde não há nenhuma ferramenta associada para o ToolGen escolher. Ele pode simplesmente gerar o ToolToken e concluir a tarefa.

Tabela 6: Estatísticas do conjunto de dados para os três estágios de treinamento. Para a memória da ferramenta, há algumas duplicatas, resultando em um tamanho de amostra ligeiramente maior do que o número de ferramentas que usamos.

SISTEMA: você é um AutoGPT com a capacidade de utilizar várias ferramentas e recursos para concluir uma determinada tarefa.
1. Primeiro, fornecerei a você uma descrição da tarefa que iniciará sua missão. 2.
2. Em cada etapa, você determinará a próxima ação gerando um token de ação. 3.
3. Após o token, você receberá o documento de ação que corresponde ao token. Você precisará gerar uma entrada para essa ação que o transferirá para um novo estado. Em seguida, você determinará a próxima etapa e repetirá o processo.
4) Após várias iterações de geração de várias ações e entradas, você finalizará a tarefa e fornecerá sua resposta final.
... ...
: Visitei recentemente o Viva City e fiquei impressionado com o cardápio. Gostaria de saber mais sobre os itens do cardápio do local 5a76c927bb5d660001e09731. Você pode fornecer categorias de cardápio, preços, disponibilidade, regras, itens do cardápio fixo e outros detalhes relevantes? Por favor, use o idioma "zh-hans" para fornecer os detalhes do menu.
Descrição: Preciso chamar a função "<>" para recuperar os detalhes do menu do local 5a76c927bb5d660001e09731. O motivo para chamar essa função é fornecer ao usuário as categorias de menu, os preços, a disponibilidade, as regras, os itens do pacote e outros detalhes relevantes. Essa função é chamada com os parâmetros "lang" definido como "zh-hans" e "is_id" definido como "5a76c927bb5d660001e09731" para garantir que os detalhes do menu fornecidos estejam no idioma necessário e sejam específicos do local.
Gerar ação.
<>
: Forneça a entrada. Aqui está a documentação: {'name': '<>', 'description': 'Use o KV para obter detalhes do local (é necessário sincronizar novamente para obter os dados mais recentes) e filtrar os dados dinâmicos em vários idiomas com base nos parâmetros de consulta. , 'required': [{'name': 'id', 'type': 'STRING', 'description': '', 'default': '56c467cb7b0d464811a42017'}, {'name': 'lang', 'type': 'STRING', ' description': '', 'default': 'zh-hans'}], 'optional': []}
::{\n "is_id": "5a76c927bb5d660001e09731",\n "lang": "zh-hans"\n}
: {'error': '', 'response': {'menu_id': '5a76c927bb5d660001e09731', 'language': 'zh-hans', 'menu_details': {'sections': [{'section_name': ' Appetisers', 'items': [{'item_name': 'Spring Rolls', 'description': 'Rolinhos primavera crocantes com molho especial', 'price': 12.99}, {'item_name': 'Chicken Skewers', 'description': 'Spicy chicken kebabs, crocantes por fora e macios por dentro', 'price'. 15,99}]}, {'section_name': 'Mains', 'items': [{'item_name': 'Kung Pao Chicken', 'description': 'Cozinha clássica de Szechuan, picante e saborosa', 'price': 18,99}, {'item_name': 'Steamed Seabass', ' description': 'Fresco e leve, nutritivo e saudável', 'price': 22.99}]}], 'special_notes': 'Opções vegetarianas estão disponíveis neste cardápio, por favor, informe ao seu garçom.'}}
: Venue 5a76c927bb5d660001e09731 Os detalhes do menu são os seguintes:\n- Categoria do menu: Comida chinesa\nPreço: \n - Item 1: 12,99 RMB\n - Item 2: 15,99 RMB\n - Item 3: 18,99 RMB\n - Item 4: 22,99 RMB\nDisponibilidade: \n - Item 1: Disponível\n - Item Item 2: Disponível\n - Item 3: Disponível\n - Item 4: Disponível\n- Regras: \n - Item 1: Regras específicas não mencionadas\n - Item 2: Regras específicas não mencionadas\n - Item 3: Regras específicas não mencionadas\n - Item 4: Regras específicas não mencionadas\n- Itens do pacote: \n - Item 1: 2 pacotes\n - Item 2: 2 pacotes\n - Item 3: 2 pacotes\n - Item 4 : 2 conjuntos de refeições\n- Outros detalhes relevantes:\n - Observação especial: Os cardápios estão sujeitos a alterações e os preços estão sujeitos a alterações. Por favor, verifique com o local para obter as informações mais recentes. \n\nPor favor, me avise se houver mais alguma coisa em que eu possa ajudá-lo!
: Gerar ação.
<<Finish
: Por favor, dê sua opinião. Aqui está a documentação: {'required': [], 'optional': [{'name': 'give_answer', 'description': 'Output answer', 'type': 'string'}, {'name': 'give_up_and_restart', ' description': 'Não foi possível processar a tarefa dessa etapa', 'type': 'string'}]}
: {"return_type": "give_answer", "final_answer": "Os detalhes do menu do Venue 5a76c927bb5d660001e09731 são os seguintes:\n- Categoria do menu: Culinária chinesa\n- Preço: \n - Item 1: 12,99 CNY\n - Item 2: 15,99 CNY\n- Item 3: 18,99 CNY\n - Item 4: 22,99 CNY\n- Disponibilidade: \n - Item 1: Disponibilidade \n - Item 2: Disponibilidade \n - Item 3: Disponibilidade \n - Item 4: Disponibilidade \n- Regras: \n - Item 1: Regra específica não mencionada \n - Item 2: Regra específica não mencionada \n - Item 3: Regra específica não mencionada \n - Item 4: Regra específica não mencionada Regras\n- Itens do cardápio fixo: \n - Item 1: 2 cardápios fixos\n - Item 2: 2 cardápios fixos\n - Item 3: 2 cardápios fixos\n - Item 4: 2 cardápios fixos\n- Outros detalhes relevantes: \n - Observação especial: Os cardápios estão sujeitos a alterações e os preços estão sujeitos a alterações. Consulte o local do evento para obter as informações mais recentes."}

Figura 6: Exemplo de raciocínio com o ToolGen. Primeiramente, é fornecido um prompt do sistema, sem nenhuma ferramenta associada. Em seguida, o usuário fornece uma consulta de tarefa, o ToolGen gera um pensamento e, então, usamos o modelo de prompt de função do usuário para gerar uma ação. Depois de gerar a ação, usamos novamente o usuário para fornecer um documento de ferramenta. O modelo gerará entradas de ferramentas com base nessa documentação.

E Teste de ablação

A Tabela 7 mostra os resultados de ablação para a avaliação de ponta a ponta. Para instruções não vistas, o ToolGen Agent tem um desempenho ligeiramente melhor sem o treinamento de memória ou recuperação de ferramentas. No entanto, para ferramentas não vistas, tanto o SoPR quanto o SoWR diminuem sem os dois primeiros estágios de treinamento. Isso sugere que os dois primeiros estágios do treinamento desempenham um papel na capacidade de generalização do ToolGen, enquanto o treinamento de recuperação é mais importante do que a memória de ferramentas.

Tabela 7: Resultados de ablação da avaliação de ponta a ponta do ToolGen. Aqui, Inst. representa consultas não vistas (comandos) e Tool. e Cat. representam ferramentas não vistas durante o treinamento.

F Capacidade de generalização

Para o ToolGen Agent, medimos o desempenho do modelo em consultas de ferramentas não treinadas. A Tabela 8 mostra a avaliação de ponta a ponta do modelo em ferramentas não vistas. O desempenho do ToolGen Agent é inferior ao do ToolLlama, o que também indica uma generalização ruim ao concluir a tarefa completa. O problema da generalização é predominante na recuperação generativa e está além do escopo deste documento. Portanto, deixamos esse assunto para pesquisas futuras.

Tabela 8: Resultados de generalização do ToolGen. Testamos e comparamos o desempenho do ToolGen com outros modelos em consultas que exigiam ferramentas não vistas durante o treinamento.

Adaptação dos dados do ToolBench ao ToolGen

Nossos dados do ToolGen são adaptados e transformados a partir dos dados do ToolBench. Especificamente, usamos os documentos da ferramenta como dados para o treinamento da memória da ferramenta, em que as entradas são documentos da ferramenta e as saídas são o token correspondente.

Para o treinamento de recuperação, usamos dados anotados para recuperação de ferramentas no ToolBench, onde uma consulta é anotada com várias ferramentas relacionadas. Tomamos a consulta como entrada e convertemos as ferramentas relevantes em tokens virtuais, que são usados como saída do treinamento de recuperação.

Para o ajuste de ponta a ponta do smartbody, usamos trajetórias de interação como fonte com as seguintes transformações:(1) Cada trajetória contém ferramentas disponíveis nas dicas do sistema que podem ser usadas para resolver consultas. Ao concluir uma tarefa, o ToolLlama conta com as ferramentas recuperadas nas dicas do sistema para resolver a tarefa, enquanto o ToolGen pode gerar ferramentas diretamente. Portanto, removemos as ferramentas das dicas do sistema. (2) Substituímos todos os nomes de ferramentas na trajetória pelo token de ferramenta virtual correspondente.(3) Na trajetória original, o modelo de corpo inteligente gera pensamento, ação e entrada de ação (também chamado de ReAct) sequencialmente. Decompomos todo o ReAct em três rodadas de diálogo. Na primeira rodada, o modelo de corpo inteligente gera um pensamento e usamos o usuário para solicitar que o modelo gere uma ação. Na segunda rodada, o modelo gera ações, ou seja, tokens de ferramentas virtuais, e, em seguida, obtemos documentos correspondentes a esses tokens para que o modelo saiba quais parâmetros especificar. Na terceira rodada, o modelo gera parâmetros para a ferramenta.

O número de amostras em cada conjunto de dados é mostrado na Tabela 6. As amostras para treinamento de memória e recuperação de ferramentas são mostradas na Fig. 7. As amostras para ajuste de inteligências de ponta a ponta são mostradas na Fig. 8.

Memória da ferramenta #
Usuário: Nome da ferramenta: Ferramenta de OCR da carteira de motorista tailandesa Descrição: Extrai informações da carteira de motorista tailandesa e retorna resultados de texto, como o número da carteira de motorista e informações pessoais Nome da API: API da carteira de motorista Descrição: Extrai informações da carteira de motorista tailandesa e retorna resultados de texto, como o número da carteira de motorista e informações pessoais.
Ajudante: <>
Treinamento de recuperação #
Usuário: Meu amigo e eu estamos organizando uma hackathon sobre "Desenvolvimento Web" e "Desenvolvimento de aplicativos móveis". Precisamos de inspiração e orientação. Você pode obter histórias populares sobre esses tópicos no Medium.com?
Ajuda: <>

Fig. 7: Exemplo de conjunto de dados para treinamento de memória e recuperação de ferramentas. Usamos funções de usuário para representar entradas e funções de assistente para representar saídas.

Ajuste de agente de ponta a ponta do #
Sistema:
Você é um AutoGPT e é capaz de utilizar várias ferramentas e recursos para concluir a tarefa dada.
1. Primeiro, fornecerei a você uma descrição da tarefa, e sua tarefa começará. 2.
2 Em cada etapa, você determina a próxima ação gerando um Action Token. 3.
3 Depois do Token, você receberá a documentação da ação que corresponde ao Token. Você precisa gerar entradas para a ação que o ajudará a passar para o novo estado. Em seguida, você tomará uma decisão sobre a próxima etapa e repetirá o processo. 4.
4. após várias iterações de geração de várias ações e entradas, você concluirá a tarefa e fornecerá a resposta final.
Lembre-se:
1. As alterações de estado são irreversíveis e você não pode retornar a um estado anterior.
2. mantenha suas operações simples e limitadas ao que melhor se adequa à consulta atual.
3. você pode fazer várias tentativas. Se você planeja continuar tentando condições diferentes, tente uma condição de cada vez. 4.
4. Se você achar que reuniu informações suficientes, gere a ação "<> com o argumento give_answer" para fornecer sua resposta à tarefa.
5. Se você achar que não pode processar a tarefa nesta etapa, gere a ação "<> with argument give_up_and_restart".
Vamos começar!
DESCRIÇÃO DA TAREFA: você deve usar a operação para processar consultas de usuários em tempo real. Lembre-se:
1. Sempre gere um "<>" no final da tarefa. A resposta final deve conter informações suficientes para ser apresentada ao usuário. Se você não conseguir processar a tarefa ou achar que a operação sempre falha (esse recurso não está funcionando no momento), use a operação <> com give_up_and_restart.
2. Gere somente a operação e a entrada.
Usuário:
Você pode obter o endereço do código postal "PL11DN"? Gostaria de saber o número de itens encontrados, o distrito, o subdistrito, o condado, o país e os detalhes do geocódigo (direção leste, direção norte, latitude e longitude).
Iniciar!
Helper:
Com base na consulta do usuário, ele deseja obter o endereço do código postal "PL11DN" e recuperar detalhes específicos, como número de itens encontrados, distrito, subdistrito, condado, país e detalhes de geocodificação. A chamada atual da API é para a função "find_by_postcode" com o parâmetro "postcode" definido como "PL11DN". Essa API é útil porque pode fornecer endereços com base em um determinado código postal do Reino Unido. Ao usar essa API, poderei recuperar as informações necessárias para uma consulta de um usuário.
Usuário:
Gera a operação.
Ajudante:
<>
Usuário:
Fornece a entrada. Esta é a documentação: {'name': '<>', 'description': ' A API "Find By PostCode" obtém um endereço com base em um determinado código postal do Reino Unido. Essa API fornece uma interface JSON para pesquisar endereços em códigos postais do Reino Unido. , 'required': [{'name': 'postcode', 'type': 'string', 'description': '', 'default': 'PL11DN'}], 'optional': []}
Auxiliar:
{
"postcode": "PL11DN"
}
Tools (Ferramentas):
{ "error": "", "response": "{'status': 200, 'message': 'Success', 'noOfItems': 37, 'result': {'postcode': 'PL1 1DN', 'district': 'Plymouth', 'district': 'St Peter's and Seafront ', 'county': 'Devon', 'country': 'England', 'geocode': {'eastings': '248025', 'northings': '0054420', 'lattitude': '50.370001', 'longitude': '- 4.138397'}, 'addresses': [{'po_box': '', 'line_2': '', 'postcode_type': 'S', 'line_3': '', 'su_organisation_indicator': ' ' ', 'building_number'. '5', 'udprn': '18911184', 'thoroughfare': 'St Andrew's Cross', 'line_1': '5 St Andrew's Cross', 'postcode_outcode': 'PL1', 'postcode_compact': 'PL11DN', 'dependant_ thoroughfare': '', 'premise': '5', 'post_town': 'Plymouth', 'building_name': '', 'organization_name': '', 'postcode': 'PL1 1DN', 'department_name'. '', 'postcode_incode': '1DN', 'address': '5 St Andrew's Cross, Plymouth, PL1 1DN', 'double_dependant_locality': '', 'sub_building_name': '', 'dependent_ locality': '', 'delivery_point_suffix': '4T'}, {'po_box': '', 'line_2': '2 St Andrew's Cross', 'p...
Usuário:
Gerar a operação.
Ajudante:
<<Finish
Usuário:
Por favor, dê sua contribuição. Esta é a documentação: {'required': [], 'optional': [{'name': 'give_answer', 'description': 'output answer', 'type': 'string'}, {'name': 'give_up_and_restart', ' description': 'Unable to process tasks for this step', 'type': 'string'}]}
Auxiliar:
{
"return_type":'give_answer', 'return_type'.
"final_answer": "Número de itens encontrados: 37\nDistrict: Plymouth\nSubdivision: St Peter's and the Seafront\nCounty: Devon\nCountry: England\nGeocode details: \n- Eastbound: 248025\n Northbound: 0054420\n- Latitude: 50.370001\nLongitude: -4.138397"
}

! [[Imagem colada 20241027190429.png]]

Figura 8: Exemplo de ajuste de agente de ponta a ponta.

O guia do leigo para começar a usar a IA

Ajuda você a aprender a utilizar as ferramentas de IA com baixo custo e a partir de uma base zero.A IA, assim como o software de escritório, é uma habilidade essencial para todos. Dominar a IA lhe dará uma vantagem em sua busca de emprego e metade do esforço em seu trabalho e estudos futuros.

Ver detalhes>