Por qué cancelamos ECO-1
Cancelamos ECO-1, nuestros modelos propios de entidades y moderación. Qué medimos, qué corregimos y por qué no seguimos.
Hace un tiempo empezamos a experimentar con modelos propios ajustados, una familia llamada ECO-1. La idea era probar si podíamos detectar referencias importantes en respuestas anónimas y clasificar señales de moderación. Para entidades usamos LACE, un proceso de revisión cruzada. La moderación era otro experimento, con un clasificador ajustado aparte. El problema apareció cuando miramos qué necesitaba de verdad el producto.
El 2 de octubre presentamos los dos experimentos como previews de Nubi, con los nombres nubi-moderation-preview y nubi-entity-preview. En ese momento todavía estaban en evaluación y ninguno estaba integrado en Moodinary. Este texto cuenta la decisión que tomamos después.
En los comentarios sintéticos, el extractor rondaba un F1 de 0,90, una medida que combina precisión y cobertura. Pero eso no quería decir que entendiera cómo habla la gente. En una revisión manual de 90 comentarios anónimos reales encontramos 28 referencias indirectas a personas o grupos. La versión nueva coincidió con 6; la anterior, con 15. No es una medición de precisión ni una prueba completa: no teníamos una anotación independiente de cada comentario. Entre los casos que no encontró había referencias a docentes y amistades. Sí alcanza para ver que el número del conjunto sintético no respondía la pregunta que nos importaba.
Y la pregunta había cambiado. No necesitábamos construir otro detector de nombres para esconderlos. Queríamos que Moodinary ayudara a ver temas, momentos, lugares y referencias a personas o roles. Un extractor de PII no resuelve eso. Y ya no teníamos evidencia de que desarrollar uno propio justificara su carga de evaluación y operación.
La otra parte de ECO-1, la de moderación, tampoco justificó seguir. Su primera versión quedó por debajo de los sistemas que ya usábamos en las cuatro etiquetas. La segunda también. Además, su primera nota de desarrollo se había calculado con ejemplos que ya se habían usado para entrenar; no era una evaluación limpia. La versión siguiente eligió durante el desarrollo y volvió a usar una prueba pequeña que ya había sido vista antes. No había una razón seria para convertir esos resultados en una promesa.
También tenemos que corregir una publicación anterior: los cuatro valores que mostramos para la preview de moderación eran los de la línea base completa, no los resultados propios del modelo. En la primera versión, el modelo obtuvo F1 de 0,837, 0,686, 0,942 y 0,851; en la segunda, 0,462, 0,457, 0,389 y 0,635. Son resultados sintéticos sobre una prueba pequeña ya vista, así que tampoco sirven como estimación limpia de cómo rendiría con comentarios reales. El paper explica la comparación y sus límites.
Llegamos a considerar un piloto pago con otro tipo de modelo. Lo paramos antes de lanzarlo. El acceso y las licencias de las bases candidatas no estaban resueltos, no podíamos demostrar un tope de gasto que cubriera todo el proceso y tampoco teníamos una evaluación limpia lista. No hubo entrenamiento pago de ese piloto, ni una subida del adaptador, ni un cambio en producción.
Hoy no teníamos suficientes respuestas reales, obtenidas con el consentimiento adecuado, para evaluar un modelo propio. Sin eso, o datos sintéticos que se parezcan mucho mejor a los comentarios reales, seguir entrenando nos daba números pero no una respuesta confiable.
Encontramos un error en los offsets de entidades, vimos lo fácil que es confiar de más en una nota sintética y entendimos que habíamos apuntado a una tarea más estrecha que la necesidad del producto. El próximo trabajo va por otro lado: explorar pronósticos del clima emocional de los equipos y bajar los costos de la plataforma.
Si querés revisar el detalle técnico, las limitaciones y el registro de costos, está el paper completo: en español (PDF) y en inglés (PDF). Ahí separamos el uso medido, lo facturado y las reservas. No son lo mismo.