¿Es el umbral de decisión un hiperparámetro en la regresión logística?

Las clases pronosticadas a partir de la regresión logística (binaria) se determinan utilizando un umbral en las probabilidades de pertenencia a la clase generadas por el modelo. Según tengo entendido, normalmente se usa 0.5 por defecto.

Pero variar el umbral cambiará las clasificaciones predichas. ¿Esto significa que el umbral es un hiperparámetro? Si es así, ¿por qué (por ejemplo) no es posible buscar fácilmente en una cuadrícula de umbrales usando el GridSearchCVmétodo scikit-learn (como lo haría para el parámetro de regularización C).

El umbral de decisión crea una compensación entre la cantidad de positivos que predice y la cantidad de negativos que predice, porque, tautológicamente, aumentar el umbral de decisión disminuirá la cantidad de positivos que predice y aumentará la cantidad de negativos que usted predice

El umbral de decisión no es un hiperparámetro en el sentido de ajuste del modelo porque no cambia la flexibilidad del modelo.

La forma en que piensa acerca de la palabra "sintonizar" en el contexto del umbral de decisión es diferente de cómo se sintonizan los hiperparámetros. Cambiar $C$ y otros hiperparámetros del modelo cambia el modelo(por ejemplo, los coeficientes de regresión logística serán diferentes), mientras que ajustar el umbral solo puede hacer dos cosas: intercambiar TP por FN y FP por TN. Sin embargo, el modelo sigue siendo el mismo, porque esto no cambia los coeficientes. (Lo mismo es cierto para los modelos que no tienen coeficientes, como los bosques aleatorios: cambiar el umbral no cambia nada sobre los árboles). Entonces, en un sentido estricto, está en lo correcto al encontrar la mejor compensación entre los errores es "ajuste", pero te equivocas al pensar que cambiar el umbral está vinculado a otros hiperparámetros del modelo de una manera optimizada por GridSearchCV.

Dicho de otra manera, cambiar el umbral de decisión refleja una elección de su parte acerca de la cantidad de falsos positivos y falsos negativos que desea tener. Considere lo hipotético que establece el umbral de decisión a un valor completamente inverosímil como -1. Todas las probabilidades no son negativas, por lo que con este umbral predecirá "positivo" para cada observación. Desde cierta perspectiva, esto es genial, porque su tasa de falsos negativos es 0.0. Sin embargo, su tasa de falsos positivos también está en el extremo de 1.0, por lo que, en ese sentido, su elección del umbral en -1 es terrible.

Lo ideal, por supuesto, es tener un TPR de 1.0 y un FPR de 0.0 y un FNR de 0.0. Pero esto suele ser imposible en aplicaciones del mundo real, por lo que la pregunta se convierte en "¿cuánto FPR estoy dispuesto a aceptar por cuánto TPR?" Y esta es la motivación de las curvas roc .

Pero variar el umbral cambiará las clasificaciones predichas. ¿Esto significa que el umbral es un hiperparámetro?

Sí, lo hace, más o menos. Es un hiperparámetro de su regla de decisión , pero no la regresión subyacente.

Si es así, ¿por qué (por ejemplo) no es posible buscar fácilmente en una cuadrícula de umbrales usando el método GridSearchCV de scikit-learn (como lo haría para el parámetro de regularización C).

Este es un error de diseño en sklearn. La mejor práctica para la mayoría de los escenarios de clasificación es ajustar el modelo subyacente (que predice las probabilidades) utilizando alguna medida de la calidad de estas probabilidades (como la pérdida logarítmica en una regresión logística). Posteriormente, se debe ajustar un umbral de decisión sobre estas probabilidades para optimizar algún objetivo comercial de su regla de clasificación. La biblioteca debería facilitar la optimización del umbral de decisión en función de alguna medida de calidad, pero no creo que lo haga tan bien.

Creo que este es uno de los lugares donde Sklearn se equivocó. La biblioteca incluye un método, predicten todos los modelos de clasificación con umbrales 0.5. Este método es inútil, y recomiendo no invocarlo nunca. Es lamentable que sklearn no fomente un mejor flujo de trabajo.