Un agente salta i suoi strumenti quando risponde dalla memoria parametrica invece di chiamare lo strumento di ricerca o la base di conoscenza che gli hai dato. La chiamata saltata e piu veloce, non restituisce errori e appare verde sulla tua dashboard di latenza. E anche sbagliata, perche il modello ha tirato a indovinare invece di ancorarsi. La soluzione e deterministica: registra ogni traccia di chiamata a strumento, verifica che lo strumento sia stato davvero chiamato per le query che richiedono dati freschi, e fai fallire la valutazione quando non c'e stata nessuna chiamata.
Perche le dashboard di latenza nascondono le chiamate saltate
Una chiamata a strumento aggiunge tempo di andata e ritorno. Chiamare POST /api/v1/google, aspettare i risultati e poi rimandarli al modello costa qualche centinaio di millisecondi e un credito. Quando l'agente salta questo e risponde direttamente dai suoi pesi, la richiesta e piu veloce ed economica. Il tuo p50 scende. Il tasso di errore resta a zero, perche indovinare non e un errore che il runtime puo vedere.
Quindi la dashboard premia proprio il fallimento che ti interessa. Una query di fatto che avrebbe dovuto attivare una ricerca ma non l'ha fatto sembra identica a un turno di chiacchiere che legittimamente non richiedeva nessuno strumento. Latenza, tasso di errore e conteggio token non le distinguono. Il segnale che ti serve e se lo strumento si e attivato, e questo vive nella traccia, non nelle metriche.
Valida l'uso degli strumenti in modo deterministico, non con un giudice LLM
Per la domanda "l'agente ha chiamato lo strumento", un controllo deterministico batte un giudice LLM. Il giudice e un altro modello che puo allucinare, costa token ed e lento. Ma hai gia la verita: la traccia della chiamata. O c'e una chiamata al tuo strumento di ricerca nella traccia oppure no. Controlla quello.
Il controllo piu forte ha due parti. Primo, verifica che lo strumento sia stato chiamato. Secondo, verifica che la risposta finale referenzi davvero qualcosa che lo strumento ha restituito, cosi l'agente non puo chiamare lo strumento e poi ignorarlo. Con l'endpoint Google di Scavio ricevi risultati organic con URL reali, quindi puoi controllare che la risposta ne citi uno.
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: lo strumento di ricerca e stato davvero chiamato
assert any(c["name"] == "search" for c in tool_calls), \
f"agent skipped search for fact query: {query!r}"
# 2) deterministico: la risposta cita un URL che lo strumento ha restituito
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 di valutazione di esempio
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"}}],
)Nessun modello nel ciclo. Il controllo passa o fallisce su fatti che puoi vedere.
Forza l'ancoraggio per le query di fatto
Rilevare una chiamata saltata a posteriori va bene per le valutazioni. Prevenirla in produzione e meglio. Per le query che sai richiedono dati freschi, forza la chiamata di ricerca invece di lasciarla al giudizio del modello.
La maggior parte dei framework per agenti espone tool_choice. Impostalo su required (o nomina esplicitamente il tuo strumento di ricerca) per il percorso delle query di fatto, cosi il modello deve chiamare POST /api/v1/google e rispondere da risultati organici reali prima di poter rispondere. Non chiedi all'agente di decidere se l'ancoraggio conta. Decidi tu per lui nei casi in cui sai gia che la risposta non puo venire dai dati di addestramento.
Questo scambia un po' di latenza e un credito per chiamata con una risposta davvero aggiornata. Su un percorso di fatto, e lo scambio che vuoi ogni volta.
Il limite onesto
La validazione deterministica delle chiamate a strumenti batte un giudice LLM per "l'ha chiamato", ma non ti dice quali query richiedevano uno strumento all'inizio. Qualcuno deve etichettarlo. Il tuo set di valutazione ha bisogno di casi marcati come che richiedono uno strumento, cosi l'asserzione sa quando una chiamata mancante e un bug e quando nessuno strumento era correttamente necessario.
Quell'etichettatura e il vero lavoro. Costruisci un set di query di fatto dove la risposta giusta dipende da dati attuali, marca ognuna come strumento-richiesto, ed esegui l'asserzione in due parti contro ognuna. Il controllo deterministico e economico ed esatto una volta che hai le etichette. Ottenere le etichette e la parte che nessuna automazione fa per te.