La evaluación en producción

La evaluación en producción es la medición de un sistema de inteligencia artificial con el tráfico real de sus usuarios, sin respuestas correctas anotadas y sin poder repetir el experimento. Es lo contrario de la evaluación fuera de línea en todo: allí las entradas son fijas y se pueden volver a pasar cuantas veces haga falta, aquí las entradas son las que llegan y no vuelven; allí hay etiqueta y aquí hay, como mucho, indicios. Y es, pese a eso, la única que mide el sistema que existe, porque el corpus lo escribió alguien del equipo y el tráfico no.

La primera regla es tan barata que cuesta explicar por qué se incumple siempre: las dimensiones de fuera de línea y las de producción tienen que llamarse igual. Si el corpus mide «fundamentación» y el panel de producción mide «calidad percibida», no hay ninguna operación aritmética que relacione las dos cifras, y la pregunta interesante —¿acierta mi evaluación al predecir lo que ocurre con usuarios reales?— queda fuera de alcance para siempre. Con el mismo nombre y la misma definición en los dos sitios, la comparación es una resta y el sistema de evaluación se vuelve, él mismo, comprobable. Esta decisión hay que tomarla al empezar, porque renombrar puntuaciones a posteriori rompe la serie histórica que justificaba tenerlas.

La señal más valiosa de producción es gratuita y consiste en mirar qué hace el usuario con la respuesta: si la acepta tal cual, si la edita y cuánto, si la descarta, si la vuelve a pedir, si abandona. Es el equivalente de lo que en recuperación de información se llama realimentación implícita, y arrastra la misma advertencia que Joachims y sus coautores documentaron en 2005 para los clics: la señal está condicionada por lo que el sistema mostró y por la posición en que lo mostró, de modo que mide una mezcla de calidad y presentación. Con eso se puede trabajar, siempre que se sepa.

Lo que hunde a la mayoría de los paneles de calidad no es ese sesgo sino otro, más simple y más grave, que conviene analizar despacio porque casi nunca aparece en la documentación de los productos: la señal falta, y falta de forma no aleatoria.

Todo sistema real acumula exclusiones razonables, cada una defendible por separado. La puntuación de aceptación se emite al publicar, así que el borrador que nunca se publica no puntúa. La estimación solo se evalúa cuando hay datos suficientes para calcularla, así que los casos pobres en contexto no puntúan. Una respuesta servida desde la caché no puntúa, porque no hubo generación. Una revisión que no encuentra nada que decir no produce una tasa de hallazgos. Una petición interrumpida por el usuario no puntúa, a propósito. Enumeradas en una lista de requisitos, las seis parecen detalles de implementación; puestas en una tabla, dibujan otra cosa: el conjunto de generaciones que reciben puntuación no es una muestra del conjunto de generaciones.

Y el sesgo va en la dirección peor. Un usuario abandona un borrador, en parte, porque el borrador era malo, de modo que las generaciones peores son exactamente las que no tienen nota, y la tasa de aceptación que se informa está inflada por construcción. Es el caso clásico de datos que faltan de forma dependiente del valor que tendrían, la categoría que Donald Rubin formalizó en 1976 y la única de las tres que no se arregla ignorándola. Las dos correcciones que funcionan son instrumentales antes que estadísticas: registrar explícitamente el abandono como resultado, con su denominador, e informar siempre de la cobertura junto a la tasa —«ochenta y seis por ciento de aceptación sobre el treinta y uno por ciento de las generaciones»—, porque un porcentaje sin cobertura al lado invita a leerlo como si fuera del total.

Hay un segundo límite de la señal de usuario, independiente del anterior y más difícil de aceptar para quien la defiende: aceptar no es lo mismo que estar bien. Que alguien publique el texto significa que le pareció suficiente, no que fuera cierto. Los casos que ilustran esto en cualquier sistema que redacta sobre datos son siempre del mismo tipo: con un contexto pobre, el generador rellena con lo que parece plausible —un puesto que nadie mencionó, una tecnología que no está en ninguna parte, una cifra inventada— y el resultado se lee bien, precisamente porque la invención es coherente. El usuario lo acepta. La aceptación sube. La fundamentación no la puede ver nadie desde ahí, porque comprobarla exige comparar la salida con el contexto de entrada, que es justo lo que el usuario no hace.

Esa es la función que justifica poner un juez automático sobre el tráfico real, y no la de sustituir al usuario. Hay dimensiones que el usuario juzga mejor que nadie —si le sirve, si el tono es el suyo— y dimensiones que no puede juzgar sin hacer el trabajo a mano: si cada afirmación está sostenida por el contexto, si la respuesta se inventó una restricción, si el texto contiene algo que en ese mercado es ilegal. Para esas, un segundo modelo que lee la generación y el contexto y emite una puntuación es el único instrumento disponible que cubre el cien por cien de las operaciones desde la primera, y no el veinte por ciento que sobrevive a las exclusiones.

Dónde se coloca ese juez decide cuánto cuesta ponerlo. Hay tres sitios y el orden en que conviene recorrerlos suele ser el inverso al que parece.

El más barato para empezar es por lotes, fuera del producto: se vuelca una muestra de generaciones reales, se pasan por la rúbrica en un entorno de laboratorio y se publica un informe. No toca el código de producción, no depende de ninguna plataforma, se puede hacer en una tarde y contesta las preguntas que el equipo está discutiendo esta semana. El coste medido de pasar dos llamadas de modelo sobre mil casos reales está en el orden de un dólar, de modo que el dinero nunca es el argumento; el argumento es el reloj y la disciplina con los datos, porque un volcado de tráfico real contiene datos de personas y hay que anonimizarlo en el mismo guion que lo extrae.

El más correcto a medio plazo es dentro del servicio, escribiendo la puntuación por el mismo canal por el que ya se escriben las demás. Tiene la propiedad que lo hace fácil de aprobar: no cambia ningún contrato. El texto ya está en el servicio, el canal de puntuaciones ya existe, y lo único que sale hacia fuera es un número. Se dispara después de haber respondido al usuario, muestreado, y con una regla que hay que escribir en el diseño: una puntuación perdida no puede afectar nunca a la operación. El nombre de la puntuación debe distinguir sin ambigüedad lo que dijo una máquina de lo que hizo una persona; un prefijo basta, y evita la confusión que aparece el día que alguien construye un panel con las dos mezcladas.

El tercero es la plataforma de observabilidad, ejecutando evaluadores sobre las trazas que ya se recogen. Es el destino natural y su límite es el enmascarado: un juez solo puede puntuar lo que la traza lleva, y las decisiones de qué se registra y qué se oculta —tomadas, con razón, por motivos de privacidad— determinan qué dimensiones son evaluables ahí. Conviene comprobarlo antes de planificar sobre ello, porque descubrir que el campo que hace falta está enmascarado es un descubrimiento caro.

La vigilancia de la deriva es la tarea permanente que empieza el día que todo esto funciona. Hay tres derivas y ninguna avisa. El modelo cambia bajo el mismo nombre, y con él la calibración del generador y la del juez. El tráfico cambia: un mercado nuevo, una campaña, un tipo de usuario que antes no llegaba; la evaluación fuera de línea sigue en verde porque su corpus es el de siempre. Y la rúbrica envejece, porque los fallos que describe ya se arreglaron y los nuevos no están en ella. La defensa es un procedimiento periódico y aburrido: una muestra de cincuenta a cien casos de producción etiquetados a mano cada trimestre, que sirve a la vez para recalibrar el juez, para comprobar si su acuerdo con las personas se ha movido y para alimentar el corpus con casos que el equipo no habría inventado.

Ese es, de hecho, el circuito completo, y conviene verlo entero porque cada pieza de este libro ocupa un lugar en él. Producción genera trazas; una persona las lee y las clasifica; los fallos que aparecen se convierten en casos del corpus y, si son frecuentes, en puntuadores; el corpus con sus puntuadores forma la puerta que gatea el siguiente cambio; el cambio se despliega y vuelve a producción. La evaluación fuera de línea no descubre casi nada: lo que hace es impedir que vuelva a ocurrir lo que ya se descubrió. Descubrir es tarea de producción. Un equipo que solo tiene la primera mitad se protege con eficacia de los fallos del trimestre pasado.

Falta una distinción que se confunde en casi todas las conversaciones y que cuesta incidentes: un guardarraíl no es una evaluación. Un guardarraíl se ejecuta dentro de la petición y decide sobre esa petición: bloquea, avisa o deja pasar. Una evaluación se ejecuta fuera y decide sobre una versión del sistema. Comparten rúbricas y a veces código, y por eso se mezclan, pero sus modos de fallo son opuestos. El de una evaluación es medir mal; el de un guardarraíl es fallar abierto: cuando la llamada al modelo que comprueba el contenido da error, el código que la envuelve suele devolver «sin hallazgos» y la operación continúa sin haber sido comprobada, con una línea de registro y nada visible para nadie. Es la decisión razonable —no se puede bloquear a un usuario porque un proveedor esté caído— y es un agujero que hay que medir: contar cuántas veces no se pudo comprobar, informarlo como una categoría propia y nunca como un aprobado, y vigilar esa cifra como se vigila la calidad. Lo mismo vale para los descartes silenciosos: un resultado que el sistema filtra por seguridad y no registra es un fallo que no existirá en ningún panel.

El último eval de este artículo es el que menos gente escribe y el que más desconcierto ahorra: medir el acuerdo entre las distintas superficies del propio producto. Cuando dos llamadas distintas juzgan el mismo objeto —una que revisa mientras el usuario escribe y otra que decide si se puede publicar—, no hay ninguna garantía de que coincidan, y en la práctica no coinciden: el mismo hallazgo sale como sugerencia amable en una y como bloqueo en la otra, o la corrección que una propone la marca la otra como problema. Cada una pasa sus propias pruebas; la incoherencia vive exactamente en el hueco que ninguna de las dos mide. El remedio es un eval de tres líneas conceptuales: se pasan los mismos casos por las dos superficies y se cuenta el desacuerdo, igual que se mide el acuerdo entre un juez y una persona. La cifra que sale es, en muchos productos, la más útil de todo el panel, porque el usuario no experimenta la calidad media de cada llamada: experimenta la contradicción entre las dos.