Agentes de IA devem chamar modelos

O artigo sobre MLAT descreve um piloto em produção no qual um agente chama um modelo de precificação XGBoost como ferramenta, alcança R^2 = 0,807 em dados reservados para teste, informa erro absoluto médio de 3.688 USD e reduz a geração de propostas de horas para menos de 10 minutos.¹

A ideia útil não é o modelo de precificação específico. A ideia útil é a fronteira: quando uma tarefa precisa de uma pontuação, previsão, preço, estimativa de risco, ranqueamento, classificador ou detector, o agente deve chamar o modelo treinado para aquela função. Ele não deve improvisar uma resposta estatística em prosa fluente.

Um modelo treinado pertence ao registro de ferramentas do agente. O LLM pode decidir quando chamá-lo, explicar o resultado, pedir entradas ausentes e encaminhar exceções. O modelo ajustado deve produzir a estimativa numérica, o sinal de confiança, a saída versionada e o rastro de evidências.

Resumo

Agentes LLM são bons em orquestração. Modelos estatísticos e de machine learning muitas vezes são melhores em previsões delimitadas. O padrão Machine Learning as a Tool trata um modelo de ML ajustado como uma ferramenta chamável dentro de um fluxo de trabalho de agente, junto com busca, bancos de dados, APIs e outras ferramentas.¹

Esse padrão dá às equipes uma regra operacional clara: deixe o agente coordenar o trabalho, mas faça modelos especializados executarem inferências especializadas. O resultado deve incluir versão do modelo, esquema de entrada, esquema de saída, notas de calibração e um registro rastreável da chamada. Sem essa fronteira, o LLM pode soar seguro enquanto substitui silenciosamente um modelo por um palpite.

Principais pontos

• Para quem constrói agentes: exponha modelos treinados como ferramentas tipadas, com esquemas, versões e modos de falha.
• Para equipes de ML: trate o agente como chamador, não como substituto para avaliação, persistência ou disciplina de registro de modelos.
• Para equipes de produto: mostre se um número veio de uma chamada de modelo, de uma regra, de um banco de dados ou de uma explicação do LLM.
• Para equipes de segurança: aplique às ferramentas de modelo a mesma lógica de autoridade delimitada de chaves de agente precisam de orçamentos de risco.
• Para revisores: exija a chamada do modelo, a versão do modelo, as entradas, a saída e os limites de confiança antes de confiar na resposta.

Por que agentes devem chamar modelos em vez de imitá-los?

Um LLM pode falar sobre um preço. Um modelo de precificação pode estimar um preço a partir dos atributos que aprendeu. Um LLM pode resumir risco. Um modelo de risco pode pontuar risco a partir de um conjunto de atributos testado. Um LLM pode descrever churn. Um modelo de churn pode retornar uma probabilidade ligada a um processo de treinamento.

Esses são trabalhos diferentes.

As ferramentas de agente já tornam essa separação possível. A documentação do OpenAI Agents SDK descreve ferramentas de função com parâmetros de JSON Schema, manipuladores de invocação de ferramentas e saída estruturada de ferramentas.² A documentação de uso de ferramentas da Anthropic descreve o Claude chamando ferramentas do lado do cliente e funções externas com entradas definidas por JSON Schema.³ O agente pode pedir uma previsão de modelo pelo mesmo padrão de ferramenta que usa para busca, atualizações de calendário, comandos de shell ou consultas a banco de dados.

O principal modo de falha aparece quando as equipes ignoram essa separação. Elas pedem uma estimativa ao LLM porque o LLM consegue produzir uma. A resposta chega rápido. A prosa parece razoável. A interface não dá nenhum indício visível de que o número veio de completar padrões, não de um estimador ajustado.

Esse contrato é fraco. O usuário não sabe o que produziu o resultado. O revisor não consegue inspecionar a versão do modelo nem os atributos de entrada. O operador não consegue reproduzir a chamada. O produto não consegue explicar por que a resposta mudou.

A barreira de evidências se aplica aqui: confiança não é evidência. Uma chamada de modelo pode produzir evidência. Um palpite em prosa geralmente não.

O que o padrão MLAT acrescenta?

MLAT significa Machine Learning as a Tool. O artigo enquadra um modelo de ML treinado como uma ferramenta de primeira classe que um agente LLM pode invocar quando a conversa precisa de estimativa quantitativa.¹

O sistema piloto do artigo, PitchCraft, usa dois agentes. Um agente de pesquisa reúne contexto sobre o prospect por meio de chamadas paralelas a ferramentas. Um agente de rascunho chama um modelo de precificação XGBoost e depois escreve uma proposta por meio de saídas estruturadas.¹ O modelo de ML cuida da precificação. O LLM cuida do contexto, da montagem e da explicação.

Essa separação importa porque evita dois desenhos ruins:

O agente continua importante. Ele pode decidir quando a entrada de precificação está incompleta. Pode pedir ao usuário campos ausentes. Pode chamar busca ou ferramentas de CRM antes de invocar o modelo. Pode explicar que a estimativa veio de um modelo, não de sua própria autoridade.

Essa é a divisão correta do trabalho: o LLM orquestra; o modelo ajustado prevê.

O que uma ferramenta de modelo deve retornar?

Uma ferramenta de modelo não deve retornar um número solto. Uma ferramenta de modelo séria deve retornar um objeto de evidência.

Esse formato de saída torna ferramentas de modelo compatíveis com rastreamentos de execução de agentes são o contrato do ambiente de execução. Se um agente chama um modelo de precificação, o rastreamento deve mostrar a chamada do modelo. Se um agente pula o modelo e escreve um número mesmo assim, o rastreamento deve deixar essa ausência óbvia.

A mesma lógica sustenta pacotes de revisão são a nova resposta final. Uma resposta final com um preço é fraca. Uma resposta final com registro da chamada de modelo, versão do modelo, retrato dos atributos e nota de confiança dá ao revisor algo para inspecionar.

Onde entram os registros de modelos?

Envolver o modelo como ferramenta não substitui MLOps. Isso expõe MLOps ao ambiente de execução do agente.

A documentação de registro de modelos do MLflow descreve linhagem, versionamento, aliases, tags de metadados e informações de ciclo de vida para modelos.⁴ Essa camada de registro importa porque um fluxo de trabalho de agente só consegue citar uma versão de modelo se a plataforma rastrear versões desde o início.

A documentação de persistência de modelos do scikit-learn faz um ponto relacionado pelo lado da disponibilização: escolhas de persistência envolvem compromissos de segurança e portabilidade, e ONNX pode servir modelos sem um ambiente Python, enquanto caminhos baseados em pickle exigem confiança na fonte.⁵ Uma ferramenta de modelo não deve contrabandear um artefato de modelo inseguro para dentro de um agente só porque o agente pediu uma previsão.

A pilha operacional mínima é esta:

Equipes muitas vezes comprimem essas camadas em um endpoint chamado predict. Esse atalho funciona para demonstrações. Ele falha quando o agente começa a encadear previsões em emails para clientes, propostas comerciais, notas de subscrição, planos de infraestrutura ou rascunhos de triagem médica.

O produto precisa de um contrato de modelo, não de um endpoint mágico.

Como produtos devem mostrar a saída de modelos?

A UI deve informar ao usuário quando uma resposta veio de uma ferramenta de modelo.

Textos ruins de interface escondem a procedência:

Textos melhores nomeiam o caminho de produção:

Essa distinção protege a dignidade do usuário. Usuários não deveriam ter que adivinhar se um número veio de um modelo testado, um cartão de modelo, uma regra de negócio ou uma conclusão de modelo de linguagem. Design agêntico é design de superfície de controle argumenta que produtos com agentes precisam de superfícies para supervisão e controle. A procedência do modelo é uma dessas superfícies.

Cartões de modelo ajudam com o mesmo problema na camada de documentação. O artigo Model Cards propõe relatórios estruturados para características do modelo, uso pretendido, métricas e contexto de avaliação.⁶ Interfaces de agentes podem tomar essa ideia emprestada no ambiente de execução: toda resposta de modelo deve carregar contexto suficiente para que um usuário ou revisor entenda que tipo de afirmação o modelo fez.

O que os agentes devem recusar?

Um agente consciente de modelos deve recusar vários atalhos tentadores.

Ele deve recusar inventar uma saída de modelo quando a ferramenta de modelo estiver indisponível. Pode dizer que o modelo de precificação falhou. Pode perguntar se o usuário quer uma estimativa aproximada rotulada como humana. Não deve substituir o modelo silenciosamente.

Ele deve recusar ampliar o domínio do modelo sem evidência. Um modelo de churn treinado com dados de SaaS para empresas de médio porte não deve virar um oráculo universal de saúde do negócio porque o prompt pediu com educação.

Ele deve recusar esconder incerteza. Se um modelo retorna um intervalo, a resposta não deve reduzi-lo a um único número confiante, a menos que o produto tenha uma regra clara de exibição.

Ele deve recusar chamar uma ferramenta de modelo com atributos ausentes ou fabricados. O agente pode coletar entradas, fazer perguntas de acompanhamento ou marcar campos como desconhecidos. Não deve preencher o vetor de atributos com ficção conveniente.

Ele deve recusar tratar autoridade do modelo como autoridade de ação. Um modelo pode estimar risco de fraude. Isso não significa que o agente pode congelar uma conta. A ação ainda precisa da disciplina de chaves com escopo de chaves de agente precisam de orçamentos de risco.

A regra de decisão

Use esta regra ao criar um fluxo de trabalho de agente:

Essa regra dá ao LLM um trabalho valioso sem permitir que ele se passe por todos os outros sistemas. Ele pode coordenar o fluxo de trabalho, explicar saídas, rascunhar a mensagem e fazer perguntas melhores. Ele não pode virar modelo de precificação, modelo de risco, modelo de fraude, modelo de ranqueamento ou motor de políticas só porque soa fluente.

Os melhores produtos com agentes não pedirão que um único modelo finja ser a empresa inteira. Eles construirão uma superfície de ferramentas em que cada sistema faz o trabalho que consegue comprovar.

FAQ

Isso vale apenas para modelos tradicionais de machine learning?

Não. O mesmo padrão se aplica a qualquer estimador ou pontuador especializado: modelos de gradient boosting, classificadores, sistemas de ranqueamento, modelos de previsão, motores de regras, pontuadores de recuperação e detectores específicos de domínio. O ponto não é o algoritmo. O ponto é o contrato em torno da saída.

Por que não deixar o LLM estimar diretamente?

Às vezes, uma estimativa qualitativa aproximada basta. O produto deve dizer isso com clareza. Quando o usuário precisa de preço, pontuação de risco, previsão ou decisão de elegibilidade, a resposta deve vir de um caminho de modelo ou regra testado, com entradas e limites rastreáveis.

Uma ferramenta de modelo torna a resposta automaticamente correta?

Não. Uma ferramenta de modelo ainda pode estar desatualizada, enviesada, mal calibrada, mal utilizada ou fora de seu domínio válido. A ferramenta de modelo melhora a capacidade de inspeção. Ela não elimina a necessidade de avaliação, monitoramento e revisão humana.

Qual é o contrato mínimo viável para uma ferramenta de modelo?

Comece com esquema de entrada, esquema de saída, versão do modelo, previsão, confiança ou ressalva, formato de erro, timeout e ID de rastreamento. Acrescente nomes de atributos, link do registro, referência ao cartão de modelo e notas de calibração quando o modelo afetar dinheiro, acesso, segurança ou decisões voltadas ao cliente.

Como isso muda a UX de agentes?

A interface deve rotular a fonte das saídas importantes. Usuários devem ver se uma resposta veio de uma chamada de modelo, de um documento recuperado, de uma regra de negócio, de uma aprovação humana ou de síntese do LLM. Essa procedência muda o nível de confiança que a resposta merece.

Referências