Un agente de Snowflake Cortex fallaba al buscar y su evaluación medía otra cosa

Cuando un agente de IA saca una nota mala en producción, lo primero que uno mira es el prompt. Un desarrollador que trabaja con un agente de Snowflake Cortex ha contado que ese reflejo le llevó por mal camino más de una vez. Su conclusión: antes de tocar nada hay que separar tres preguntas. ¿Acertó la respuesta? ¿Siguió un camino razonable? ¿La prueba estaba midiendo lo que yo quería medir?

El caso más claro fue el de un objeto que el agente juraba que no existía. Los metadatos sí lo contenían, pero como fuente consumida por otras vistas, no como la vista que el agente andaba buscando. Añadió una instrucción de respaldo al prompt. Volvió a fallar. La siguiente hipótesis fue que la herramienta semántica no sabía buscar por fuente; inspeccionar su definición desmintió esa explicación, porque la dimensión de fuente ya estaba ahí. Lo que pasaba es que su guía de generación de SQL insistía en buscar por nombre de vista.

La corrección tocó las dos capas a la vez. El agente recibió un respaldo que le dice cuándo preguntar qué vistas consumen esa fuente, y la vista semántica recibió instrucciones para explicar esa búsqueda a Cortex Analyst. Al repetir la prueba, el objeto y sus consumidores aparecieron. El propio autor pone un límite a ese éxito: encontrar los consumidores aguas abajo no demuestra cómo se carga cada objeto aguas arriba, y una consulta de linaje no debería convertirse en una explicación de la arquitectura de ingesta que nadie ha verificado.

El contador que mentía

Al comparar su propia telemetría con las trazas nativas de Snowflake, apareció una discrepancia incómoda. El contador de llamadas a herramientas de su aplicación convertía la ausencia de metadatos en un cero, mientras las trazas mostraban actividad que se había perdido por el camino. Una medida que faltaba, disfrazada de cero medido.

Ese episodio es el que le llevó a revisar cómo se puntúa un agente. Snowflake desglosa varias comprobaciones: corrección de la respuesta, con un LLM juzgándola contra el contenido esperado; precisión en la selección de herramientas, que compara de forma determinista los nombres y el número de llamadas esperadas contra las reales y no mira el orden; precisión en la ejecución, que cruza entradas y salidas con las invocaciones que coinciden; y consistencia lógica, donde otro LLM revisa la coherencia entre instrucciones, planificación y acciones sin respuestas de referencia. La selección de herramientas penaliza llamadas extra aunque mejoren la respuesta, así que una nota baja ahí no equivale a un porcentaje de acierto.

De ahí saca una regla que conviene repetirse: no se ablanda una prueba solo porque el agente la haya suspendido. Cada cambio en el comportamiento esperado necesita una razón independiente, sea una ruta alternativa verificada, un prerrequisito documentado o una corrección del propio caso.

Preguntas reales, respuestas que no valen como verdad

Las conversaciones reales dan buenas entradas para pruebas, mejores que las que uno se inventa para una demo. Pero arrastran trampas. Un seguimiento del tipo «genera la consulta para este modelo» pierde sentido cuando se separa de la conversación anterior. Una respuesta antigua que funcionó puede contener un error. Un dato sensible al tiempo caduca. Para que un caso de regresión sirva hace falta el contexto de la pregunta, expectativas verificadas aparte, incertidumbre aceptable y el comportamiento concreto que no debe repetirse. También conviene conservar los ejemplos que ya funcionaban, para que un ajuste puntual no rompa un flujo que iba bien. Y hay que tener presente que cambiar preguntas o respuestas esperadas crea una base nueva: comparar su media con la anterior como si solo hubiera cambiado el agente infla la mejora.

Queda un último detalle sobre lo que una prueba cubre de verdad. Después de habilitar un sandbox de Python, ni los casos centrados en XML mostraban su uso en la inspección grabada. Configurado, mencionado en el plan e invocado son tres estados distintos, y una respuesta correcta por otra ruta puede pasar el test dejando el sandbox sin ejercitar.

Todo esto viene de un entorno concreto y de repeticiones puntuales, no de un banco de pruebas controlado, así que no hay cifras que extrapolar. Lo que sí se lleva uno es la distinción, que es portable a cualquier agente con herramientas: «los datos no están», «la herramienta no puede» y «el agente no preguntó bien» se arreglan en sitios distintos. Antes de reescribir el prompt, merece la pena comprobar si el mal medido es el test.