Un agente se salta sus herramientas cuando responde desde la memoria parametrica en vez de llamar a la herramienta de busqueda o base de conocimiento que le diste. La llamada omitida es mas rapida, no devuelve error y aparece en verde en tu panel de latencia. Tambien esta mal, porque el modelo adivino en lugar de fundamentarse. La solucion es determinista: registra cada traza de llamada a herramienta, comprueba que la herramienta se llamo de verdad en las consultas que necesitan datos frescos y haz fallar la evaluacion cuando no hubo llamada.
Por que los paneles de latencia ocultan las llamadas omitidas
Una llamada a herramienta anade tiempo de ida y vuelta. Llamar a POST /api/v1/google, esperar los resultados y devolverlos al modelo cuesta unos cientos de milisegundos y un credito. Cuando el agente se salta eso y responde directo desde sus pesos, la peticion es mas rapida y barata. Tu p50 baja. La tasa de error queda en cero, porque adivinar no es un error que el runtime pueda ver.
Asi que el panel premia justo el fallo que te importa. Una consulta de hecho que deberia haber disparado una busqueda pero no lo hizo se ve identica a un turno de charla que legitimamente no necesitaba herramienta. La latencia, la tasa de error y el conteo de tokens no las distinguen. La senal que necesitas es si la herramienta se disparo, y eso vive en la traza, no en las metricas.
Valida el uso de herramientas de forma determinista, no con un juez LLM
Para la pregunta "llamo el agente a la herramienta", una comprobacion determinista gana a un juez LLM. El juez es otro modelo que puede alucinar, cuesta tokens y es lento. Pero ya tienes la verdad: la traza de la llamada. O hay una llamada a tu herramienta de busqueda en la traza o no la hay. Comprueba eso.
La comprobacion mas fuerte tiene dos partes. Primero, comprueba que la herramienta se llamo. Segundo, comprueba que la respuesta final referencia algo que la herramienta devolvio, para que el agente no pueda llamar a la herramienta y luego ignorarla. Con el endpoint de Google de Scavio recibes resultados organic con URLs reales, asi que puedes verificar que la respuesta cita una de ellas.
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) determinista: la herramienta de busqueda se llamo de verdad
assert any(c["name"] == "search" for c in tool_calls), \
f"agent skipped search for fact query: {query!r}"
# 2) determinista: la respuesta cita una URL que la herramienta devolvio
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 evaluacion de ejemplo
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"}}],
)Ningun modelo en el bucle. La comprobacion pasa o falla sobre hechos que puedes ver.
Fuerza la fundamentacion en las consultas de hecho
Detectar una llamada omitida despues es bueno para las evaluaciones. Prevenirla en produccion es mejor. Para las consultas que sabes que necesitan datos frescos, fuerza la llamada de busqueda en lugar de dejarla al criterio del modelo.
La mayoria de los frameworks de agentes exponen tool_choice. Ponlo en required (o nombra tu herramienta de busqueda explicitamente) para la ruta de consultas de hecho, de modo que el modelo deba llamar a POST /api/v1/google y responder desde resultados organicos reales antes de poder contestar. No le pides al agente que decida si la fundamentacion importa. Decides por el en los casos donde ya sabes que la respuesta no puede salir de los datos de entrenamiento.
Esto cambia un poco de latencia y un credito por llamada por una respuesta que de verdad esta actualizada. En una ruta de hecho, ese es el intercambio que quieres siempre.
La limitacion honesta
La validacion determinista de llamadas a herramientas gana a un juez LLM para "la llamo", pero no te dice que consultas necesitaban una herramienta de entrada. Alguien tiene que etiquetar eso. Tu conjunto de evaluacion necesita casos marcados como que requieren herramienta, para que la asercion sepa cuando una llamada ausente es un fallo y cuando no se necesitaba ninguna herramienta.
Ese etiquetado es el trabajo de verdad. Construye un conjunto de consultas de hecho donde la respuesta correcta dependa de datos actuales, marca cada una como herramienta-requerida y corre la asercion de dos partes contra todas. La comprobacion determinista es barata y exacta una vez que tienes las etiquetas. Conseguir las etiquetas es la parte que ninguna automatizacion hace por ti.