O que é uso de ferramentas em LLMs?

Você também pode ver esse mecanismo ser chamado de chamada de ferramentas ou chamada de funções. Os nomes geralmente se referem ao mesmo mecanismo. No entanto, algumas plataformas usam ferramentas como uma categoria mais ampla, que inclui pesquisa hospedada, execução de código, recuperação de arquivos ou controle de computador, além de funções definidas pelo desenvolvedor.

O modelo mental útil

Pense no modelo como quem faz a chamada, não como a máquina que executa o trabalho.

O modelo pode produzir uma solicitação estruturada como “chame get_order_status com o ID do pedido 4821”. Essa saída ainda é uma resposta do modelo. Ela não consulta um banco de dados por conta própria.

Uma aplicação ao redor recebe a solicitação e controla o que acontece em seguida. Ela pode rejeitar a chamada, pedir ao usuário que a confirme, verificar permissões, executar código ou retornar um erro. Se executar a ferramenta, ela devolve o resultado ao modelo como um novo contexto. O modelo pode então explicar o resultado ou solicitar outra ferramenta.

Essa separação é o fato central do uso de ferramentas:

User request
    ↓
Model selects a tool and proposes inputs
    ↓
Application validates, authorizes, and executes
    ↓
Tool result returns to the model
    ↓
Model answers or requests another tool

Alguns provedores também oferecem ferramentas hospedadas, que são executadas em seus próprios servidores. A API pode ocultar parte do ciclo, mas as etapas lógicas permanecem: o modelo solicita uma operação, um sistema de execução a executa e o resultado entra na conversa.

Como funciona o uso de ferramentas

1. A aplicação descreve cada ferramenta

Uma definição de ferramenta normalmente inclui:

• um nome, como get_order_status
• uma descrição em linguagem simples de quando usá-la
• as entradas que ela aceita
• regras para o formato e o tipo de cada entrada

Essas regras de entrada geralmente são expressas como um esquema JSON. O esquema pode indicar que order_id é uma string obrigatória. A descrição informa ao modelo o significado da ferramenta; o esquema informa como formatar uma chamada.

2. O modelo recebe a solicitação e as definições das ferramentas

O modelo considera a mensagem do usuário junto com as descrições das ferramentas disponíveis. Ele pode responder normalmente, solicitar uma ferramenta ou solicitar várias ferramentas quando a API e a aplicação permitirem.

A seleção de ferramentas é uma previsão, não um plano garantido. O modelo pode escolher a ferramenta errada, omitir uma chamada necessária ou propor um argumento bem-formado, mas inadequado.

3. O modelo retorna uma chamada de ferramenta estruturada

Em vez de — ou junto com — uma prosa comum, a resposta contém uma chamada legível por máquina. Uma versão simplificada poderia ser assim:

{
  "name": "get_order_status",
  "arguments": {
    "order_id": "4821"
  }
}

As APIs dos provedores codificam isso em diferentes tipos de mensagem e associam um identificador para que o resultado posterior possa ser relacionado à chamada correta. O envelope exato muda, mas a ideia de nome e entradas é consistente entre as principais APIs.

4. A aplicação decide se deve executá-la

É nesse ponto que uma ação proposta se torna real — ou não.

A aplicação analisa os argumentos e os verifica além do esquema. Ela pode confirmar a identidade do usuário conectado, aplicar regras de acesso, limitar valores, exigir aprovação para um efeito colateral ou recusar uma ferramenta que esteja indisponível. Somente então um executor de ferramentas chama o banco de dados, a API, a calculadora, o sistema de arquivos ou outro sistema.

Um esquema rigoroso pode melhorar a confiabilidade estrutural, mas não é um sistema de autorização. "order_id": "4821" pode ser um JSON válido e ainda assim se referir ao pedido de outra pessoa.

5. O resultado da ferramenta retorna ao modelo

A aplicação envia a saída em uma mensagem de resultado associada à chamada original. A saída pode conter dados, um erro ou uma declaração de que a permissão foi negada.

O modelo usa esse resultado como contexto adicional. Ele pode produzir uma resposta final, corrigir uma suposição anterior ou fazer outra chamada de ferramenta. Um agente de IA que executa várias etapas pode repetir esse ciclo até atingir uma condição de parada.

Exemplo prático: consultar um pedido

Suponha que uma loja disponibilize uma ferramenta somente de leitura:

Name: get_order_status
Purpose: Return shipping information for an order the current user owns
Input: order_id (required string)

O usuário pergunta:

Onde está o pedido 4821?

O modelo solicita:

{
  "name": "get_order_status",
  "arguments": {
    "order_id": "4821"
  }
}

Antes de consultar qualquer informação, a aplicação verifica a sessão atual. Se o usuário for o proprietário do pedido 4821, ela executa a consulta e retorna:

{
  "status": "shipped",
  "estimated_delivery": "Friday"
}

Agora o modelo pode responder: “O pedido 4821 foi enviado e a previsão de entrega é sexta-feira.”

Se a verificação de propriedade falhar, a aplicação não deve executar a consulta nem revelar o status. Ela pode retornar um erro de permissão, que o modelo pode explicar sem expor dados privados.

Nada na chamada do modelo comprovou a propriedade. O esquema da ferramenta descreveu uma solicitação válida; a aplicação aplicou a regra real.

Por que o uso de ferramentas é importante

O uso de ferramentas dá a um modelo de linguagem acesso controlado a recursos que a geração de texto, sozinha, não oferece.

• Dados atuais ou privados: Uma ferramenta pode recuperar informações atuais ou dados que nunca fizeram parte do material de treinamento do modelo.
• Operações exatas: Uma calculadora, consulta a banco de dados ou programa pode executar tarefas que não devem depender de uma estimativa plausível.
• Ações reais: As ferramentas podem criar registros, enviar mensagens, agendar eventos ou operar outros softwares.
• Sistemas existentes: Uma ferramenta pode transformar uma solicitação em linguagem natural em uma chamada para uma API empresarial já estabelecida.
• Trabalho em várias etapas: O resultado de uma chamada pode orientar a próxima chamada.

O uso de ferramentas não elimina as limitações do modelo. Ele transfere algumas tarefas para sistemas mais adequados a elas e cria uma interface entre decisões probabilísticas e software determinístico.

A confiabilidade e a segurança dependem do sistema ao redor

O modelo não é uma fonte confiável de comandos apenas porque sua saída corresponde a um esquema. O uso de ferramentas em produção requer controles ao redor do modelo.

Valide o significado, não apenas o formato. Verifique identificadores, intervalos, estados obrigatórios e regras de negócio. A validação estrutural não consegue dizer se uma transação proposta corresponde à solicitação do usuário.

Autorize no momento da execução. Use a identidade e as permissões mantidas pela aplicação. Não permita que o modelo conceda acesso a si mesmo ao inserir um ID de usuário ou uma função em um argumento da ferramenta.

Limite o poder de cada ferramenta. Uma ferramenta get_order_status com escopo restrito é mais fácil de controlar do que uma ferramenta de banco de dados genérica. Ferramentas somente de leitura e de escrita devem ser distintas quando seus riscos forem diferentes.

Trate a saída da ferramenta como dados não confiáveis. Conteúdo externo pode estar errado ou conter texto criado para redirecionar o modelo. Um documento retornado é uma informação a ser examinada, não uma nova autoridade capaz de substituir a solicitação do usuário ou as regras do sistema.

Trate os efeitos colaterais de forma deliberada. Enviar uma mensagem ou emitir um reembolso é diferente de consultar um status. Ações sensíveis podem exigir confirmação, proteção de idempotência contra execução duplicada e um registro de auditoria.

Retorne as falhas de forma clara. Tempos limite, serviços indisponíveis, permissões rejeitadas e argumentos inválidos devem se tornar resultados explícitos da ferramenta. Caso contrário, o modelo pode preencher a lacuna com um sucesso inventado.

Equívocos comuns

“O LLM chamou minha API”

Normalmente, o LLM gerou uma solicitação e uma aplicação chamou a API. Dizer que o modelo “chamou” a ferramenta é uma abreviação conveniente, mas oculta a fronteira de execução e segurança.

“Chamada de funções e chamada de ferramentas são sempre diferentes”

Para funções definidas pelo desenvolvedor, provedores e frameworks geralmente usam os termos de forma intercambiável. A diferença aparece quando uma plataforma usa ferramenta como um termo abrangente para funções e recursos integrados, como pesquisa ou execução de código. Consulte a taxonomia da plataforma em vez de presumir uma distinção universal.

“Um esquema válido significa uma chamada correta”

Um esquema pode exigir uma string, um número, uma lista ou um objeto e rejeitar uma saída malformada. Ele não pode garantir que o modelo selecionou a ferramenta certa, inferiu o valor correto ou respeitou uma regra de negócio.

“Adicionar uma ferramenta cria um agente”

O uso de ferramentas é uma capacidade. Um agente é um sistema maior, capaz de decidir, agir, observar resultados, preservar o estado relevante, repetir o ciclo e parar. Uma chamada estruturada pontual pode usar o mesmo mecanismo sem se tornar um fluxo de trabalho autônomo.

“O resultado da ferramenta deve ser verdadeiro”

O modelo pode resumir fielmente um resultado incorreto. A confiabilidade da ferramenta, a atualidade dos dados, o controle de acesso e a resistência a conteúdo malicioso são propriedades do sistema como um todo, não apenas do modelo de linguagem.

Como o uso de ferramentas se encaixa em um sistema de IA

O uso de ferramentas fica na fronteira entre um modelo de linguagem e os sistemas ao seu redor.

O modelo interpreta a linguagem e propõe uma próxima etapa estruturada. A aplicação fornece as definições das ferramentas, mantém o estado da conversa, valida as chamadas, gerencia permissões, executa operações e retorna observações. As ferramentas fornecem capacidades específicas. Um agente pode usar essa estrutura repetidamente para realizar uma tarefa maior.

Por isso, a qualidade do uso de ferramentas não é apenas uma propriedade do modelo. Descrições claras das ferramentas, esquemas distintos, controles de execução, mensagens de erro úteis e regras de parada adequadas influenciam o funcionamento do sistema.

Próximos passos

Leia O que é um agente de IA? para ver como as chamadas de ferramentas se tornam parte de um ciclo repetido de planejar-agir-observar, com estado e regras de parada. Leia O que é um harness de IA? para conhecer o software que valida e executa essas chamadas; depois, use Modelo de IA vs. chatbot vs. harness vs. agente para situar o uso de ferramentas no sistema mais amplo.