Cambias las instrucciones del asistente que recibe consultas de clientes. Ahora responde mejor a las preguntas habituales, pero deja una interrupción de servicio en la cola ordinaria. La respuesta suena correcta; la persona que debía intervenir no recibe el aviso.
Esta es una situación ilustrativa, no un caso de cliente de NorteIA. El problema aparece al actualizar un sistema que ya trabaja: hay que comprobar que conserva los comportamientos que la empresa necesita. Una demostración con preguntas fáciles no basta para decidirlo.
Definir qué debe seguir funcionando
Antes de cambiar el modelo, las instrucciones o las conexiones, anota qué pretendes mejorar y qué resultados deben mantenerse. Para un asistente de atención, podrían ser orientar una consulta habitual, pedir un dato imprescindible y derivar una incidencia al responsable adecuado.
Anthropic distingue las pruebas de nuevas capacidades de las evaluaciones de regresión: estas últimas comprueban si el sistema conserva tareas que ya resolvía. También diferencia el mensaje del asistente del resultado real de su acción. Si afirma que ha abierto una incidencia, la comprobación debe buscar ese registro.
Proponemos guardar una colección de casos con entrada, resultado esperado y evidencia observable. Incluye solicitudes ordinarias y excepciones que importen al negocio. Si utilizas conversaciones reales para prepararla, elimina los datos identificativos y la información confidencial innecesaria. Las pruebas deben ejecutarse en un entorno aislado, sin enviar mensajes a clientes ni modificar registros de producción.
Una ficha para comparar las dos versiones
Esta tabla es una propuesta de NorteIA para un asistente de soporte. Adapta los criterios con la persona responsable del servicio. «Bloquea» significa que el cambio no se publica hasta resolver ese fallo; no es una clasificación universal.
| Caso de prueba | Resultado esperado | Evidencia y decisión |
|---|---|---|
| Pregunta por el horario de atención. | Responde con el horario vigente de la documentación de prueba. | Comparar dato y fuente. Una diferencia de estilo se registra aparte de un horario incorrecto. |
| Solicita ayuda sin identificar el servicio afectado. | Pide el dato necesario antes de decidir el recorrido. | Revisar la conversación. Bloquea si inventa el dato y actúa a partir de él. |
| Describe una interrupción que el procedimiento clasifica como crítica. | La deriva al responsable establecido, con los datos disponibles. | Comprobar destinatario y registro en el sistema de prueba. Bloquea si queda como consulta ordinaria o no llega. |
| Describe un problema menor que permite continuar trabajando. | Aplica el recorrido ordinario previsto. | Comprobar la clasificación. Registrar falsas urgencias para evitar que «derivar todo» parezca una mejora. |
| El registro de incidencias devuelve un error. | Explica que no pudo completar la acción y ofrece la alternativa acordada. | Comparar respuesta y registro. Bloquea si confirma una incidencia inexistente. |
Añade a cada ejecución la versión del modelo, las instrucciones, los documentos utilizados y el resultado observado. Conserva la misma configuración de prueba para la versión actual y la candidata, cambiando únicamente lo que quieres evaluar. Restablece los datos entre intentos para que una incidencia creada antes no falsee el siguiente resultado.
Por qué un promedio mejor puede ocultar un problema
Supongamos 20 consultas ficticias, cada una evaluada una vez con ambas versiones y los mismos criterios. Para simplificar el ejemplo, cada consulta cuenta como correcta o incorrecta. Las cantidades siguientes son inventadas para explicar la decisión; no describen resultados de NorteIA.
| Grupo de consultas | Versión actual | Versión candidata |
|---|---|---|
| 16 consultas ordinarias. | 13 correctas de 16. | 16 correctas de 16. |
| 4 incidencias críticas. | 4 derivadas correctamente de 4. | 2 derivadas correctamente de 4. |
| Total de consultas resueltas correctamente. | 17 de 20: 85 %. | 18 de 20: 90 %. |
El cálculo global es 17 ÷ 20 = 85 % frente a 18 ÷ 20 = 90 %: una mejora de cinco puntos porcentuales. Sin embargo, la candidata falla en dos incidencias críticas que la versión actual sí deriva. Con el criterio de bloqueo definido arriba, esta actualización no pasa.
Google explica que la exactitud global de un clasificador puede ser poco informativa cuando las clases están desequilibradas o los errores tienen consecuencias distintas. Aquí usamos esa idea para separar el total de aciertos de los fallos del recorrido crítico.
Esta muestra pequeña y artificial no estima la fiabilidad del asistente en una empresa. Tampoco demuestra que la versión actual sea segura para todos los casos: solo permite comparar estas ejecuciones concretas.
Comprobar también al comprobador
Antes de confiar en una tabla llena de aprobados, introduce una respuesta deliberadamente incorrecta: por ejemplo, «incidencia registrada» sin que exista el registro. El método de evaluación debe rechazarla. Conserva además una respuesta válida para comprobar que también puede reconocer un acierto.
Cuando la valoración dependa del significado de una conversación, deja criterios escritos y ejemplos de aceptación para la persona que revise. Si otra IA ayuda a puntuar, contrasta sus decisiones con revisión humana, especialmente en los casos críticos. Que dos modelos coincidan no acredita por sí solo que el resultado sea correcto.
Las respuestas pueden variar entre ejecuciones. Repite los casos importantes y registra todos los intentos, incluidos los fallidos. Reserva también casos que no hayas usado para ajustar las instrucciones. No borres una prueba porque la nueva versión no la supera: revisa si el requisito sigue vigente y documenta cualquier cambio.
Tomar la decisión y vigilar el cambio
Deja por escrito qué mejoró, qué empeoró y quién acepta la actualización. Si queda un fallo crítico o el equipo no consigue acordar qué respuesta sería válida, mantén el cambio en pruebas. Primero hay que resolver esa duda.
Tras una publicación aprobada, revisa incidencias y una muestra de conversaciones con un responsable asignado. Conserva la configuración anterior y un procedimiento para detener el sistema. Volver a una versión previa no deshace mensajes enviados ni acciones ya ejecutadas: esas consecuencias necesitan revisión propia.
Si tu empresa ya utiliza asistentes y cada actualización exige probar «a ojo», podemos ayudarte a definir los criterios y conectarlos con tus sistemas. NorteIA desarrolla integraciones y agentes de IA con comprobaciones operativas, desde A Coruña para empresas de Galicia.