Um agente pula suas ferramentas quando responde a partir da memoria parametrica em vez de chamar a ferramenta de busca ou base de conhecimento que voce deu a ele. A chamada pulada e mais rapida, nao retorna erro e aparece em verde no seu painel de latencia. Tambem esta errada, porque o modelo chutou em vez de se ancorar. A solucao e deterministica: registre cada traco de chamada de ferramenta, verifique que a ferramenta foi realmente chamada nas consultas que precisam de dados frescos e faca a avaliacao falhar quando nao houve chamada.
Por que os paineis de latencia escondem chamadas puladas
Uma chamada de ferramenta adiciona tempo de ida e volta. Chamar POST /api/v1/google, esperar os resultados e devolve-los ao modelo custa algumas centenas de milissegundos e um credito. Quando o agente pula isso e responde direto dos seus pesos, a requisicao e mais rapida e barata. Seu p50 cai. A taxa de erro fica em zero, porque chutar nao e um erro que o runtime consiga ver.
Entao o painel premia exatamente a falha que importa. Uma consulta de fato que deveria ter disparado uma busca mas nao disparou parece identica a um turno de conversa que legitimamente nao precisava de ferramenta. Latencia, taxa de erro e contagem de tokens nao as distinguem. O sinal que voce precisa e se a ferramenta disparou, e isso vive no traco, nao nas metricas.
Valide o uso de ferramentas de forma deterministica, nao com um juiz LLM
Para a pergunta "o agente chamou a ferramenta", uma verificacao deterministica vence um juiz LLM. O juiz e outro modelo que pode alucinar, custa tokens e e lento. Mas voce ja tem a verdade: o traco da chamada. Ou existe uma chamada a sua ferramenta de busca no traco ou nao existe. Verifique isso.
A verificacao mais forte tem duas partes. Primeiro, verifique que a ferramenta foi chamada. Segundo, verifique que a resposta final referencia algo que a ferramenta retornou, para que o agente nao possa chamar a ferramenta e depois ignora-la. Com o endpoint do Google da Scavio voce recebe resultados organic com URLs reais, entao pode checar que a resposta cita uma delas.
import requests
API_KEY = "sk-your-key"
def search(query):
r = requests.post(
"https://api.scavio.dev/api/v1/google",
headers={"Authorization": f"Bearer {API_KEY}"},
json={"query": query, "light_request": False},
)
r.raise_for_status()
return r.json()
def assert_grounded(query, agent_answer, tool_calls):
# 1) deterministico: a ferramenta de busca foi realmente chamada
assert any(c["name"] == "search" for c in tool_calls), \
f"agent skipped search for fact query: {query!r}"
# 2) deterministico: a resposta cita uma URL que a ferramenta retornou
results = search(query)
returned_urls = [item["link"] for item in results.get("organic", [])]
assert any(url in agent_answer for url in returned_urls), \
"answer does not reference any retrieved source"
# caso de avaliacao de exemplo
assert_grounded(
query="latest stable python release",
agent_answer="Python 3.13 is current. Source: https://www.python.org/downloads/",
tool_calls=[{"name": "search", "args": {"query": "latest stable python release"}}],
)Nenhum modelo no loop. A verificacao passa ou falha sobre fatos que voce pode ver.
Force a ancoragem para consultas de fato
Detectar uma chamada pulada depois e bom para avaliacoes. Preveni-la em producao e melhor. Para as consultas que voce sabe que precisam de dados frescos, force a chamada de busca em vez de deixa-la ao criterio do modelo.
A maioria dos frameworks de agente expoe tool_choice. Coloque em required (ou nomeie sua ferramenta de busca explicitamente) para o caminho das consultas de fato, de modo que o modelo precise chamar POST /api/v1/google e responder a partir de resultados organicos reais antes de poder responder. Voce nao pede ao agente que decida se a ancoragem importa. Voce decide por ele nos casos em que ja sabe que a resposta nao pode vir dos dados de treino.
Isso troca um pouco de latencia e um credito por chamada por uma resposta de fato atualizada. Num caminho de fato, essa e a troca que voce quer sempre.
A limitacao honesta
A validacao deterministica de chamadas de ferramenta vence um juiz LLM para "ele chamou", mas nao diz quais consultas precisavam de uma ferramenta de inicio. Alguem tem que rotular isso. Seu conjunto de avaliacao precisa de casos marcados como exigindo ferramenta, para que a assercao saiba quando uma chamada ausente e um bug e quando nenhuma ferramenta era corretamente necessaria.
Esse rotulo e o trabalho de verdade. Construa um conjunto de consultas de fato onde a resposta certa dependa de dados atuais, marque cada uma como ferramenta-requerida e rode a assercao de duas partes contra todas. A verificacao deterministica e barata e exata uma vez que voce tem os rotulos. Conseguir os rotulos e a parte que nenhuma automacao faz por voce.