El autor de un mentor de IA revisó sus 61 tests y descubrió que el banco de pruebas mentía

Hace un mes, el desarrollador de una plataforma educativa integró en ella un mentor de IA y montó un banco de pruebas con 61 tests automáticos para tomar decisiones con cifras y no por intuición. Una semana después resultó que el que fallaba era el propio banco: daba por buenas las respuestas cortadas, dejaba pasar soluciones completas con otros nombres de variables y suspendía rechazos correctos. Una semana más tarde, en el banco de pruebas el modelo funcionaba de forma impecable, pero en producción, con el mismo tipo de preguntas, no. El autor contó esta historia en Habr.

Qué se evaluaba y para qué

El mentor de la plataforma no es un chatbot abstracto. Ve las lecciones, el progreso del estudiante y su último intento en la tarea. De ahí el criterio de calidad: a un tutor no se le evalúa por saber la respuesta, sino por dónde decide parar. Si señala la línea con el error o reescribe el ejercicio por el alumno. Si dice «no lo sé, vamos a comprobarlo» o se inventa el resto con aplomo.

El banco de pruebas debía medir precisamente ese comportamiento. Servía para elegir el modelo y ajustar el prompt sin tener que adivinar qué versión era mejor. Mientras se pueda confiar en las cifras, el esquema funciona. Los problemas empezaron cuando se revisaron las propias comprobaciones.

Dónde mentía el banco de pruebas

El autor señala tres errores, y cada uno empuja en una dirección distinta. El anuncio no detalla la implementación, así que lo que sigue es nuestra interpretación.

• Se aprobaba una respuesta cortada. Al parecer, la comprobación buscaba ciertos rasgos en el texto, pero no exigía que la respuesta estuviera terminada. Un modelo cuya salida se truncaba por el límite de tokens obtenía el aprobado.
• Pasaba una solución completa con otro nombre de variable. Lo más probable es que la prohibición de dar la solución se basara en comparar texto. Si se renombra la variable, la coincidencia desaparece y el estudiante recibe el código completo.
• Se suspendía un rechazo correcto. La comprobación esperaba una forma concreta de rechazo y no reconocía como válida una respuesta correcta con otra formulación.

Los errores primero y segundo producen falsos aprobados; el tercero, falsos suspensos. Por eso el porcentaje global de aciertos dice casi nada: los errores se compensan en parte entre sí y la cifra final parece verosímil.

El banco de pruebas, limpio; producción, no

Lo más desagradable ocurrió después. Tras corregir las comprobaciones, el modelo se comportaba de forma impecable en el banco de pruebas, pero en producción, con el mismo tipo de preguntas, no. Es la brecha clásica entre un conjunto sintético y el tráfico real. Los estudiantes de verdad escriben peor, envían código a medias, presionan al mentor y formulan sus peticiones de otra manera que el autor del test. Un conjunto de 61 casos no cubre esa variedad.

La conclusión del autor es dura: dejó de confiar en el modelo por completo. Del título se desprende que tampoco se puede confiar en los tests. En la práctica, esto implica cambiar la arquitectura de la confianza: el comportamiento del mentor hay que limitarlo y verificarlo a nivel de sistema, en lugar de esperar que un buen prompt y un banco de pruebas en verde garanticen el resultado.

Qué se puede llevar a la práctica

• Verifique al evaluador. Pase el banco de pruebas por respuestas deliberadamente malas: cortadas, con la solución completa, con variables renombradas. Si el banco las deja pasar, no se puede confiar en las cifras.
• Compare por significado. En el caso del código, eso supone normalizar identificadores, analizar la estructura o ejecutar la solución, y no buscar una subcadena.
• Cuente por separado los falsos aprobados y los falsos suspensos. Un único porcentaje de aciertos oculta errores de ambos signos.
• Devuelva producción al conjunto de tests. Cada fallo real debe convertirse en un test nuevo.
• No se apoye en el modelo en los puntos críticos. Es más fiable implantar la prohibición de dar la solución completa como una comprobación sobre la salida que como una petición en el prompt.

Esta historia sirve a cualquiera que construya agentes y asistentes LLM con métricas de calidad. El evaluador es un componente de software igual que el propio modelo, y se equivoca con la misma frecuencia. El autor publica el análisis completo con ejemplos en el artículo original; aquí solo hemos resumido lo que se declara en el anuncio.