Goatify IA

Noticias, guías y análisis

NVIDIA propone evaluar agentes por el estado final del entorno y no por la apariencia correcta de cada llamada a herramientas

NVIDIA publicó un marco para evaluar agentes con entornos ejecutables y estado persistente, distinguiendo puntuación por paso de verificación end-to-end del resultado; recomienda success rate, consistencia, precisión de

NVIDIA propone evaluar agentes por el estado final del entorno y no por la apariencia correcta de cada llamada a herramientas

Un tool call correcto puede terminar en una tarea fallida. NVIDIA publicó el 21 de septiembre una guía que argumenta que evaluar agentes exige mirar más allá de la selección de funciones y sus argumentos. Un agente puede llamar correctamente a issuerefund y aun omitir una validación, duplicar un efecto o dejar el sistema en un estado inconsistente. Por eso la evaluación necesita ejecutar las herramientas contra un entorno que conserva estado y después inspeccionar el mundo resultante. Esta idea cambia el objeto de medición: ya no calificamos solamente mensajes o llamadas individuales, sino una trayectoria que debe producir una consecuencia verificable.

Process scoring y outcome scoring responden preguntas distintas. NVIDIA separa la puntuación de cada paso, útil para saber dónde se rompe la cadena, de la verificación end-to-end que pregunta si el estado final cumple el objetivo. Un proceso puede tener pasos redundantes y aun terminar bien; otro puede parecer elegante y fallar al último momento. Para desarrollo necesitamos ambos. El process score ayuda a mejorar prompts, herramientas y fine-tuning. El outcome score debe funcionar como release gate porque representa lo que el usuario experimenta. Mezclarlos en una sola nota borra información causal y puede premiar agentes que hablan bien pero no completan el trabajo.

La consistencia importa porque los agentes son sistemas estocásticos. La guía recomienda repetir trials y reportar rangos, no solo un promedio. Un modelo que logra noventa por ciento en una corrida y setenta y cuatro en otra no ofrece la misma confianza que uno que se mantiene en un rango estrecho. También propone medir tool-call precision, argument accuracy, steps per success y cost per success. Esta última métrica es especialmente práctica: gastar pocos tokens no sirve si la tarea falla. La economía debe dividirse por outcomes válidos, incorporando reintentos y trayectorias largas que una métrica de precio unitario puede ocultar.

Los verificadores ejecutables son el patrón más fuerte. NVIDIA considera que comprobar una fila de base de datos, una prueba que pasa o un ticket cerrado es preferible a comparar una respuesta con un texto esperado. Los jueces LLM siguen siendo útiles cuando la calidad es lingüística o no existe un check determinista, pero sus puntuaciones deberían validarse contra personas. Para una plataforma agentic, esto sugiere diseñar el verificador al mismo tiempo que la habilidad. Si no sabemos cómo demostrar que una acción terminó correctamente, tampoco sabemos qué significa éxito y estaremos obligados a confiar en la narración del propio agente.

La contaminación también llega a los agentes con acceso web. La publicación señala que un agente puede recuperar respuestas o material del propio benchmark durante una evaluación, y que datasets públicos pueden terminar incorporados a entrenamiento posterior. Los evals privados de dominio reducen ese riesgo porque nacen de tickets, APIs y estados internos que no están disponibles públicamente. Esto no significa esconder todas las pruebas; significa separar benchmarking público, útil para comparabilidad, de release gates privados, útiles para nuestra distribución real. Una empresa debería mantener casos frescos y rotarlos para evitar que optimización repetida convierta el examen en entrenamiento indirecto.

Lectura Goatify. Esta guía se alinea con cómo deberíamos certificar nuestras habilidades: cada una necesita un outcomeverifier que observe el sistema después del trabajo. Un agente de marketing no “terminó” porque dijo que publicó; terminó cuando la pieza existe en la cuenta correcta, con la fecha y configuración esperadas. Un agente de CRM no “actualizó” porque emitió una llamada válida; terminó cuando el registro cambió una vez y el historial coincide. Podemos vender esa diferencia como producto. La autonomía confiable no se mide por cuántas herramientas puede llamar, sino por cuántos outcomes puede demostrar sin pedir fe.

Abrir artículo en Goatify

Abriendo Goatify...