Escribí 61 tests para un mentor de IA. Luego descubrí que tampoco se podía confiar en los tests

Hace un mes, un desarrollador integró un mentor de IA en su plataforma educativa. El modelo tiene acceso a las lecciones del curso, al progreso del estudiante y a su último intento en una tarea. Para elegir el modelo y el prompt con datos y no a ojo, creó un banco de 61 tests automáticos. Una semana después resultó que el propio banco de pruebas también se equivocaba. Daba por terminadas respuestas cortadas, pasaba por alto soluciones completas con variables renombradas y reprobaba negativas correctas. Este artículo explica cómo está diseñado el banco de pruebas, qué ayudó a descubrir, dónde generaba una falsa sensación de seguridad y por qué el desarrollador dejó de confiar por completo en el modelo.

Los tests: 61 preguntas en 13 grupos

El banco de pruebas consiste en una pregunta y un conjunto de verificaciones automáticas: subcadenas, llamadas a herramientas, longitud de la respuesta, idioma. Cada pregunta incluye una intervención del estudiante y un conjunto de expectativas. Las 61 preguntas se dividen en 13 grupos: lecciones (12), ataques al prompt (10), disciplina epistémica (6), progreso del estudiante (5), código del estudiante (5), pensamiento de ingeniería (5), límites temáticos (4), precisión técnica (3), referencias a lecciones (3), formato e idioma de la respuesta (2), honestidad (2), contexto del diálogo (2), tono (2).

El mentor trabaja con tres herramientas: búsqueda entre 272 lecciones reales del curso, progreso del estudiante (fixture en el banco de pruebas) y último intento del estudiante (fixture). En el banco de pruebas, el estudiante tiene una función Reverse que modifica el slice original en el lugar, aunque según el contrato debería devolver uno nuevo.

Tres modelos: DeepSeek, YandexGPT, Qwen

El desarrollador elegía entre los modelos disponibles desde servidores rusos. Claude y OpenAI quedaron descartados: sus API rechazan las conexiones por IP. Yandex AI Studio ofrece tres opciones: DeepSeek V4 Flash, YandexGPT Pro y Qwen3.6 35B.

Primera corrida sobre 32 preguntas: • DeepSeek V4 Flash: 31/32 verificaciones, 5 de 5 preguntas sobre código del estudiante, latencia de 6,5 segundos. • YandexGPT Pro: 28/32 verificaciones, solo 3 de 5 en código, latencia de 1,4 segundos. • Qwen3.6 35B: 2/7 verificaciones, corrida detenida.

YandexGPT falló en lo principal: no invocaba la herramienta ante la petición de analizar el código del estudiante. Qwen no se adaptó a la configuración: el modo de razonamiento con un límite de 1024 tokens consume todo el presupuesto en pensar.

En cuanto al costo: DeepSeek, 25,6₽ por 32 preguntas; YandexGPT, 116₽. La diferencia no está en la lista de precios, sino en las tarifas de caché: en DeepSeek la entrada en caché cuesta cuatro veces menos, en YandexGPT cuesta lo mismo que una entrada normal.

Dónde el banco de pruebas le mintió al desarrollador

Sobre una base de 57 preguntas, DeepSeek V4 Flash completó tres corridas consecutivas: 50, 48 y 50 verificaciones. El desarrollador separó los fallos en tres categorías: errores falsos del banco de pruebas (ya corregidos), exceso de longitud (una limitación intencional) y errores sustanciales del modelo.

Tres errores principales que se repetían: • Solución completa ante una petición de ayuda — una de cada tres veces el modelo entregaba la solución entera en lugar de una pista. Para una plataforma donde las tareas son el producto, es el peor fallo posible. • Una clase en lugar de una respuesta — ante la pregunta «¿Qué hace make en Go?», tres de tres veces respondió con un curso completo: capacidad, dos bloques de código, declaración con var. • Enumerar variantes en lugar de diagnosticar — ante el error «connection reset by peer», respondió con causas típicas, aunque el prompt pide no rellenar vacíos con palabras como «normalmente» o «probablemente».

Dos errores ocultos del propio banco de pruebas: 1. Una respuesta cortada se daba por terminada. El proveedor devolvía finish_reason: length, el banco de pruebas no lo revisaba y la marcaba como exitosa. 2. El modo de razonamiento de DeepSeek activado por defecto. El desarrollador no pasaba el parámetro, y el banco de pruebas operaba con un modo oculto. Con reasoning_effort: none, la corrida resultó un 10% más barata y un 40% más rápida, pero los fallos fueron distintos. Con reasoning_effort: high, el precio subió un 55%, la latencia un 65%, y apareció un caso extremo: ante una pregunta sobre Kubernetes, el modelo hizo 11 búsquedas en 36 segundos y gastó 13₽.

El desarrollador se quedó con DeepSeek V4 Flash en su configuración por defecto. La cifra 50 de 57 no es un porcentaje de respuestas correctas, sino la cantidad de verificaciones automáticas superadas. Cada solución la revisa manualmente, porque una verificación por subcadena puede pasar por alto una mala respuesta y reprobar una buena. Lo más útil no resultó ser la elección del modelo, sino la lista de lugares donde el banco de pruebas generaba una falsa sensación de seguridad.