¿Cuándo optimizarías recall por encima de precisión, y cómo fijas el umbral en la práctica?

Optimiza recall cuando un positivo perdido cuesta más que una falsa alarma, como en cribado de fraude o detección de enfermedades donde de todos modos un humano revisa cada aviso. Optimiza precisión cuando actuar sobre un positivo es caro o molesto, como enviar ofertas o bloquear cuentas. Fija el umbral a partir del coste esperado en lugar de dejarlo por defecto en 0,5, barriendo umbrales y eligiendo la pérdida esperada mínima.

Empiezo preguntando qué pasa con cada tipo de error. En una cola de fraude, un falso negativo es dinero que se va más un contracargo, mientras que un falso positivo son treinta segundos del tiempo de un analista, así que gana el recall y bajo el umbral. En un modelo de notificaciones push se invierte: un falso positivo irrita a un usuario real y te puede costar una desinstalación, así que quiero precisión aunque llegue a menos gente. Para elegir el número concreto, pongo un coste aproximado a cada tipo de error, barro el umbral por el conjunto de validación y dibujo el coste esperado. Suele tener una cuenca clara, y cojo el centro de la cuenca en lugar del mínimo exacto, porque el mínimo salta entre folds. La restricción que la gente olvida es la capacidad. En un proyecto de fraude la curva de coste decía que marcáramos alrededor del cuatro por ciento de las transacciones, pero el equipo de revisión podía con unos mil casos al día, así que el umbral real era el que produjera mil. Lo dije con claridad en lugar de fingir que la elección era puramente estadística.