El error de un modelo sobre los datos con los que se entrenó es una estimación optimista, a veces desesperadamente optimista, de su desempeño futuro (Witten et al., 2017, p. 163). Por eso se reservan datos. La práctica estándar usa tres conjuntos (Witten et al., 2017, p. 164; Chollet, 2021, sec. 5.2.1):
- Entrenamiento: los ejemplos con los que se ajustan los parámetros.
- Validación: datos aparte para comparar configuraciones y elegir hiperparámetros (cuántas capas, cuántas épocas).
- Prueba: datos que no intervienen en ninguna decisión y se usan al final, para estimar la generalización.
¿Por qué no alcanza con dos? Porque ajustar la configuración mirando el desempeño en validación también es una forma de aprendizaje: cada decisión filtra información sobre esos datos, y tras muchas iteraciones el modelo queda sobreajustado a la validación sin haberla visto nunca durante el entrenamiento (Chollet, 2021, sec. 5.2.1). Con pocos datos se usa la validación cruzada: se divide el conjunto en k partes y se rota cuál sirve de prueba (Witten et al., 2017, p. 168).
La regla de oro, «no entrenar con los datos de prueba», se rompe de maneras sutiles. M. Mitchell (2019) relata que en 2015 un equipo de Baidu usó al menos treinta cuentas para enviar resultados de ImageNet al servidor de prueba más de doscientas veces, cuando el límite era de dos por semana; esa retroalimentación pudo darle la fracción de punto porcentual que decidía el récord, y fue descalificado (2019, ch. 5). Con los modelos de lenguaje el problema cambia de forma: los benchmarks públicos terminan en la web y, por lo tanto, en los datos de entrenamiento (contaminación de datos).
El filósofo de la ciencia reconocerá la distinción entre predicción y acomodación: una teoría que acierta un dato que no se usó para construirla merece más crédito que una ajustada para acomodarlo. El conjunto de prueba institucionaliza esa intuición.