Por qué la demo funciona y en producción falla

Introducción

La escena se repite con una regularidad casi cómica. Una demostración impecable: se le enseñan cinco documentos al sistema, los procesa sin un fallo, la sala se convence y el proyecto se aprueba. Tres semanas después de conectarlo al flujo real, la sensación general es que aquello no funciona tan bien como parecía.

Nadie ha mentido. La demostración era real y los cinco documentos también. Lo que ha ocurrido es que la prueba y la realidad miden cosas distintas, y hay varias razones bien estudiadas por las que un sistema que rinde en la primera se degrada en la segunda.

Conviene conocerlas por dos motivos. Uno, para no aprobar proyectos basándose en pruebas que no predicen nada. Y dos, para diseñar pruebas que sí lo hagan, que es más fácil de lo que parece.

La demostración está sesgada por construcción

Empecemos por lo evidente, que suele ser lo que más pesa.

Los ejemplos de una demostración los elige alguien. Aunque no haya intención de engañar, la selección se produce igualmente: se toman documentos que estaban a mano, que se entienden bien, que no tienen anotaciones raras a lápiz en el margen, que no vienen escaneados torcidos ni con el sello de caja tapando el importe. Se eligen, en definitiva, casos representativos de lo que uno cree que es el trabajo.

Y el trabajo real no está hecho de casos representativos. Está hecho de una mayoría de casos fáciles y una minoría persistente de casos que no encajan, que son justo los que consumen el tiempo de las personas y los que motivaron el proyecto.

Hay una prueba sencilla para detectar este sesgo, y consiste en invertir quién elige. Si la demostración la prepara el proveedor, que la empresa aporte diez documentos escogidos por quien hace ese trabajo a diario, con el encargo explícito de incluir los tres peores del último mes. La diferencia entre ambas demostraciones es, aproximadamente, la diferencia que habrá entre la expectativa y la realidad.

Los casos raros no son raros cuando se suman

Este es el punto que más cuesta interiorizar, porque la intuición engaña con los porcentajes.

Cada excepción concreta es infrecuente. El proveedor que factura en otro formato es el 2 % de los casos. El cliente con dos razones sociales, el 1 %. Los documentos que llegan escaneados de través, otro 3 %. Ninguna merece por separado que se detenga un proyecto.

El problema es que estas excepciones no compiten entre sí, se acumulan. Un proceso real puede tener veinte o treinta rarezas distintas, cada una pequeña, que juntas suponen un tercio del volumen. Y como cada una necesita su propio tratamiento, el esfuerzo de cubrirlas no crece con el volumen sino con la variedad, que es una magnitud que nadie mide antes de empezar.

De ahí viene la sensación de que el proyecto va bien hasta que de pronto se atasca. No se ha atascado: se ha terminado la parte fácil, que era el 70 % de los casos y el 20 % del trabajo.

Esto tiene una consecuencia práctica al presupuestar. Cuando alguien pregunta cuánto cuesta automatizar un proceso, la respuesta honesta depende de cuántas variantes tenga, y eso no se sabe hasta haber mirado una muestra grande. Un presupuesto cerrado emitido tras ver cinco documentos es una estimación sobre la parte fácil.

Dos sistemas que puntúan igual pueden comportarse muy distinto

Aquí entra un fenómeno menos intuitivo y bastante bien documentado.

Cuando se construye un sistema de este tipo, se toman muchas decisiones que parecen intrascendentes: cómo se parte el texto, en qué orden se presenta la información, qué ejemplos se incluyen en las instrucciones, qué semilla se usa. Dos versiones que difieran en esos detalles pueden obtener exactamente la misma puntuación en el conjunto de prueba y, sin embargo, comportarse de manera muy diferente en cuanto cambian ligeramente las condiciones.

Un equipo de investigación amplio dio nombre a esto y lo documentó en visión artificial, imagen médica y procesamiento de lenguaje: llamaron subespecificación a la situación en que un proceso de construcción puede producir muchas soluciones con rendimiento equivalente en la prueba, y encontraron que esas soluciones aparentemente intercambiables se comportan de forma muy distinta al desplegarlas (D'Amour et al., 2022).

La lectura práctica para quien compra es la siguiente: una buena puntuación en una prueba no garantiza un buen comportamiento en producción, porque la prueba no distingue entre soluciones que resultan ser muy diferentes fuera de ella. Y la lectura para quien construye es que hay que evaluar en condiciones variadas, no solo en un conjunto fijo, y desconfiar de las mejoras pequeñas que solo se ven en una métrica.

Conviene añadir un matiz honesto: ese trabajo se hizo sobre modelos entrenados a medida y no sobre los sistemas basados en modelos preentrenados que hoy usa una empresa pequeña. El mecanismo concreto no se traslada punto por punto. La conclusión general, que es que la puntuación en un conjunto de prueba mide menos de lo que sugiere, sí se sostiene.

El mundo no se queda quieto

Una demostración es una fotografía. Un sistema en producción vive en un mundo que cambia, y ese cambio lo degrada de tres formas distintas.

Cambia lo que entra. Un proveedor rediseña sus facturas, entra un cliente de un sector nuevo, se empieza a recibir documentación en otro idioma. El sistema sigue haciendo lo mismo, pero ya no sobre lo mismo.

Cambia lo que se considera correcto. Se modifica un criterio interno, entra en vigor una obligación nueva, la empresa decide tratar de otra manera un tipo de incidencia. Lo que ayer era la respuesta buena hoy es la mala, y el sistema no se ha enterado.

Cambian los componentes. El proveedor del modelo actualiza su versión, una interfaz cambia, una biblioteca se comporta distinto. Esto ocurre sin aviso y sin que nadie de la empresa haya tocado nada.

Ninguna de las tres es un fallo del sistema, y las tres producen el mismo síntoma: algo que funcionaba deja de funcionar sin causa aparente. Por eso la evaluación no puede ser un acto único de aceptación, sino algo que se repite periódicamente sobre el mismo conjunto de casos.

El sistema no es el modelo

Queda la razón más estructural de todas, y es la que explica por qué la distancia entre demostración y producción es tan grande en estos proyectos y no tanto en otros tipos de software.

Un trabajo ya clásico de ingenieros de Google puso el dedo en la llaga: en un sistema real de aprendizaje automático, el código propiamente dedicado al modelo es una fracción pequeña del conjunto, y todo lo demás (recogida de datos, verificación, infraestructura, gestión de configuración, monitorización, herramientas de análisis) constituye la mayor parte de lo que hay que construir y mantener. Sus autores advertían de que es peligroso tratar las victorias rápidas de estos sistemas como si salieran gratis, porque es habitual incurrir en enormes costes de mantenimiento continuado (Sculley et al., 2015).

Una demostración enseña exactamente esa fracción pequeña, que además es la que mejor funciona y la que más impresiona. Todo lo que falta por construir es invisible en la sala y es la mayor parte del proyecto.

Por eso una demostración impresionante y un presupuesto bajo son, juntos, una combinación sospechosa: o el proveedor ha resuelto ya el resto (y entonces puede enseñarlo) o no lo ha contado.

Cómo hacer una prueba que sí prediga algo

Todo lo anterior se traduce en unos cuantos criterios que convierten una demostración decorativa en una prueba informativa.

Que los casos los elija quien hace el trabajo. No el proveedor y no la dirección. La persona que procesa esos documentos a diario sabe cuáles son los que duelen.

Que incluya deliberadamente lo peor. Los tres casos más difíciles del último mes, los que generaron una consulta interna, los que salieron mal. Si el sistema los resuelve, la noticia es excelente. Si no, se ha averiguado antes de firmar.

Que el volumen sea suficiente para ver variedad. Cinco casos no dicen nada sobre la cola de excepciones. Cincuenta empiezan a decir algo. Doscientos son ya una base seria.

Que la respuesta correcta esté anotada de antemano. Antes de ver lo que produce el sistema, no después. Si se anota después, el criterio se contamina sin que nadie lo pretenda.

Que se mida qué pasa cuando falla. Interesa tanto la tasa de acierto como la forma del error: si el sistema avisa de que duda o si se equivoca con aplomo, que es bastante peor y bastante más frecuente.

Que se repita semanas después. La misma prueba, el mismo conjunto, para ver si algo se ha movido. Es la única forma de detectar las tres clases de cambio descritas arriba.

Errores frecuentes

Aprobar por impresión. La demostración produce una sensación, y la sensación no es un dato. Merece la pena escribir el criterio de aceptación antes de ver nada, precisamente para no juzgarlo en caliente.

Tratar el conjunto de prueba como un trámite. Es el activo más valioso del proyecto y el que sobrevive a todo lo demás, incluidos el proveedor y el modelo. Conviene construirlo con cuidado y conservarlo.

Ajustar el sistema contra el conjunto de evaluación hasta que apruebe. Si se usan los mismos casos para mejorar y para juzgar, la nota deja de significar nada. Conviene reservar una parte que no se toca.

Interpretar la primera degradación como un fracaso. Que un sistema empeore al cabo de unos meses es lo esperable, no una señal de que estaba mal construido. Lo que indica un problema es que nadie se dé cuenta.

Pedir un presupuesto cerrado sobre una muestra pequeña. Se está pidiendo un precio sobre la parte fácil, y la conversación difícil se traslada al peor momento posible, que es a mitad del proyecto.

Conclusión

La distancia entre la demostración y la producción no es un problema de honestidad comercial, aunque a veces también lo sea. Es una consecuencia de que ambas cosas miden fenómenos distintos: una enseña el comportamiento en casos escogidos y estáticos, la otra ocurre sobre una distribución completa de casos, en un mundo que cambia y con un sistema del que el modelo es solo una parte pequeña.

La forma de reducir esa distancia no es desconfiar de las demostraciones, sino sustituirlas por pruebas mejores. Casos elegidos por quien sufre el proceso, incluyendo deliberadamente los peores, en cantidad suficiente para que aparezcan las excepciones, con la respuesta correcta anotada antes y repitiendo la medición semanas después.

Hacer eso cuesta unas horas de la persona adecuada. Es, con bastante diferencia, la inversión más rentable de todo el proyecto, porque es la única que convierte una decisión basada en impresiones en una decisión basada en pruebas.

Y tiene un efecto secundario muy útil: pedirlo revela enseguida qué clase de proveedor se tiene delante.

Referencias

D'Amour, A., Heller, K., Moldovan, D., Adlam, B., Alipanahi, B., Beutel, A., Chen, C., Deaton, J., Eisenstein, J., Hoffman, M. D., Hormozdiari, F., Houlsby, N., Hou, S., Jerfel, G., Karthikesalingam, A., Lucic, M., Ma, Y., McLean, C., Mincu, D., … Sculley, D. (2022). Underspecification presents challenges for credibility in modern machine learning. Journal of Machine Learning Research, 23(226), 1-61. https://www.jmlr.org/papers/v23/20-1335.html

Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. (2015). Hidden technical debt in machine learning systems. En Advances in Neural Information Processing Systems 28 (pp. 2503-2511). https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems