Cómo evaluar una solicitud de LLM antes de su lanzamiento

Lo que dice la guía

La guía de enero de 2026 de Anthropic divide las pruebas de agentes en tareas, ejecuciones repetidas, reglas de puntuación y el entorno de prueba. También separa lo que dice un agente de lo que realmente hace. Por ejemplo, un agente puede decir que guardó un registro cuando el registro nunca cambió. Califica el resultado y la conversación. Este es un consejo de un proveedor modelo, no una prueba de que un método funcione para todos los sistemas.

Evidencia: Evaluaciones desmitificadoras para agentes de IA [1]

Elija la decisión que debe respaldar su prueba

Escriba la pregunta de liberación en una oración. Por ejemplo: ¿puede nuestro asistente de soporte explicar la política de la cuenta sin prometer un reembolso que no puede aprobar? Esto le da a la prueba un usuario, una tarea y un riesgo claros. Un objetivo vago como “ser más útil” puede recompensar una respuesta suave e incorrecta.

Decida qué parte del flujo de trabajo probará. Una respuesta puede ser suficiente para una herramienta de resumen. Un asistente de chat puede necesitar una conversación completa. Si un agente edita un registro, verifique también el registro guardado. Guarde la versión del modelo, el mensaje, la configuración de búsqueda y los permisos de la herramienta. Un cambio en cualquiera de estos puede cambiar el resultado.

Cree un pequeño conjunto de pruebas que pueda revisar

Rubrex recomienda tres grupos de casos: tareas comunes, casos extremos y fallas conocidas. Para cada caso, escriba el comportamiento esperado y por qué el caso pertenece a la prueba. Retenga algunos casos mientras ajusta el sistema. Utilice la primera ejecución de prueba para encontrar requisitos poco claros antes de utilizar puntuaciones para respaldar un lanzamiento.

Utilice el código para verificar reglas exactas, como campos obligatorios o ID de registros permitidos. Utilice una guía de puntuación para determinar el significado, los detalles faltantes y la incertidumbre honesta. Pida a los revisores que califiquen ellos mismos un pequeño conjunto compartido. Discuta en qué no están de acuerdo antes de confiar más casos a un juez automatizado. Mantenga los casos que no se pueden calificar en el informe y explique por qué.

• Guarde la versión original y todas las respuestas, incluidas las solicitudes fallidas.
• Ejecute la versión modificada en las mismas entradas y límites.
• Inspeccionar los casos que mejoraron y los casos que empeoraron.
• Asigne a cada falla que bloquea la liberación un propietario designado.

Ejemplo: un asistente que explica la política.

Supongamos que un asistente debe citar la política actual, explicar las excepciones y evitar prometer aprobación. Puede cumplir las dos primeras reglas pero aun así no prometer un reembolso. Califica cada regla para que el equipo pueda encontrar el problema. También registre si la respuesta pasó todas las reglas requeridas.

Ahora supongamos que un nuevo mensaje corrige las citas pero hace más promesas no respaldadas. Ese es un resultado mixto. Pruebe un cambio dirigido a las promesas y luego vuelva a ejecutar los casos anteriores para comprobar si hay nuevos fallos. Este es un plan de prueba de ejemplo, no el resultado de un cliente de Rubrex.

Déle al siguiente ingeniero lo suficiente para volver a ejecutar la prueba.

Comparta los casos, reglas de puntuación, versiones del sistema y respuestas originales. Agrupa los fallos por causa y explica lo que aún se desconoce. Incluya pasos para volver a ejecutar la prueba y agregar una falla encontrada después del lanzamiento. Otro ingeniero debería poder comprobar la decisión sin necesidad de las diapositivas del autor. Cuando la evidencia sea demasiado débil para decidir, nombre los datos que faltan y la siguiente prueba.

Registre lo que significa cada puntuación.

Elija medidas que respondan a la pregunta de liberación. Para un asistente de soporte, Rubrex recomienda realizar un seguimiento de las respuestas incorrectas, los reclamos no respaldados, las tareas completadas y el costo de una respuesta útil. Indique qué cubre cada conteo. Diez respuestas fallidas de 100 respuestas significan algo diferente a diez sesiones fallidas de 100 sesiones. Incluya solicitudes que no produjeron respuesta.

Una prueba verifica un requisito. Un conjunto de pruebas comprueba varios requisitos y formas en que el sistema puede fallar. Mantenga los resultados de su aplicación separados de las puntuaciones de referencia de los modelos públicos. Escriba un breve registro de decisiones con las versiones antiguas y nuevas, los casos probados, las definiciones de puntuación y las fallas que bloquean la publicación. Nombra a la persona propietaria de la próxima prueba.

Preguntas comunes