En una edición reciente de Technically Speaking , vimos cómo incorporar variables derivadas de la minería de texto en un modelo predictivo para mejorar el rendimiento del modelo. (Si no ha visto la presentación, es posible que desee verla antes de seguir leyendo). El estudio de caso se centró más en la minería de texto que en el modelado predictivo, así que ahora veamos dos pasos principales del modelado que no se discutieron: a saber, validar el modelo y calificar nuevas observaciones.
Modelo de validación
En el modelado predictivo, es crucial probar la precisión del modelo antes de usarlo para generar predicciones. Queremos asegurarnos de que nuestro modelo no esté "sobreajustado", capturando con precisión los datos con los que fue entrenado pero generando predicciones inexactas para datos que no ha visto antes. Un gran meme que captura el concepto de sobreajuste ha estado circulando por Internet desde hace un tiempo.
Una forma de verificar el sobreajuste es reservar o "retener" un subconjunto de nuestros datos, entrenar el modelo con los datos restantes y luego probar el modelo en el conjunto de reserva. Medimos el rendimiento de predicción del modelo tanto en los datos de entrenamiento como en los de reserva, y si vemos una gran caída en la precisión desde el entrenamiento hasta los conjuntos de prueba, tenemos evidencia de que nuestro modelo está sobreajustado.
De hecho, utilizamos este procedimiento de validación de reserva al construir el modelo Bootstrap Forest en el estudio de caso, aunque lo pasamos por alto. A continuación se muestra una tabla de medidas de ajuste del modelo del procedimiento de validación. JMP proporciona una serie de medidas para comparar el rendimiento del conjunto de entrenamiento y prueba (si tienes curiosidad, lee sobre ellas). aquí ); vimos Entropy RSquare y Tasa de clasificación errónea para el grupo de prueba en la presentación. Ninguna de las medidas muestra una caída pronunciada en el rendimiento desde el entrenamiento hasta la prueba (aunque hay algunas caídas leves en un par de medidas, lo cual no es inusual), por lo que concluimos que nuestro modelo no está sobreajustado.
Quizás notes algo: también hay una columna "Validación" en esta tabla. ¿De qué trata eso? En realidad, aquí dividimos nuestros datos en tres subconjuntos: entrenamiento, validación y prueba. En nuestro modelo Bootstrap Forest, el conjunto de entrenamiento se usa para encontrar las mejores divisiones en cada árbol de decisión, mientras que el conjunto de validación se usa para decidir cuándo dejar de hacer nuevas divisiones en cada árbol, así como cuándo dejar de hacer nuevos árboles. Es decir, el algoritmo de ajuste del modelo continúa siempre que cada nueva división o árbol dé como resultado un mejor rendimiento en el conjunto de validación. Una vez que el rendimiento del conjunto de validación se nivela, el algoritmo se detiene. (¿Recuerdas la estadística de Entropía RSquare? Esa es la estadística de validación utilizada en este proceso). Una vez que el algoritmo se detiene, la precisión del modelo resultante se evalúa utilizando el conjunto de pruebas. En JMPPro , todo esto sucede automáticamente al especificar una columna de validación en la ventana de especificación del modelo, como vio en la presentación .
No todos los modelos requieren una validación en tres partes como ésta. Solo es necesario que los modelos que utilizan un procedimiento de ajuste iterativo y un subconjunto de datos separado (el conjunto de validación) decidan cuándo dejar de ajustar. Para los modelos que no implican un procedimiento de ajuste iterativo (la regresión logística, por ejemplo, que podríamos haber usado aquí) solo se necesitan conjuntos de entrenamiento y prueba.
JMP Pro tiene una manera sencilla de dividir nuestros datos para la validación del modelo. Usamos la utilidad Crear columna de validación, que realiza un muestreo aleatorio o pseudoaleatorio (sin reemplazo) de nuestros datos para crear cada subconjunto, con los subconjuntos registrados en una columna de validación en nuestra tabla de datos.
Aquí utilizamos muestreo aleatorio estratificado para crear nuestros subconjuntos, que se explica en el párrafo en la parte superior de la segunda captura de pantalla. Hubo un fuerte desequilibrio en algunas de nuestras variables categóricas y queríamos evitar una situación en la que, por ejemplo, pocas o ninguna de las violaciones agravadas terminaran en el conjunto de prueba. Esto sería problemático, porque necesitamos ver cómo se desempeña el modelo en violaciones agravadas para obtener una medida válida de la precisión del modelo.
Puede ver en el informe de distribución interactivo a continuación que tenemos una representación coincidente de cada columna de estratificación en nuestros tres subconjuntos de datos. Con casi 40.000 filas de datos, existe una buena posibilidad de que hubiéramos estado bien sin usar la estratificación, pero no fue mala idea ir a lo seguro. La estratificación es uno de varios procedimientos de muestreo pseudoaleatorio diferentes que la utilidad Crear columna de validación puede implementar (consulte aquí para más).
La utilidad Crear columna de validación volvió a colocar una columna llamada "Validación" en nuestra tabla de datos (que está disponible para descargar en la página de presentación de Technically Speaking) y luego la introdujimos en la plataforma Bootstrap Forest para activar el proceso de validación. No encontramos evidencia de sobreajuste, por lo que suponiendo que nos sentimos cómodos con la precisión general del modelo, estamos listos para usarlo para generar predicciones (“puntuar”) nuevas observaciones.
Puntuación de nuevas observaciones
Imagine que tenemos un grupo de violaciones del código de construcción recién emitidas y queremos asignar una probabilidad de multa financiera a cada una, que usaremos para ponderar cada monto de multa impuesta en nuestras proyecciones financieras. Por ejemplo, una multa impuesta de $1000 por una infracción con una probabilidad de penalización de 0,7 tendría un pago previsto de $700. Por supuesto, el demandado en última instancia pagará 1.000 dólares o 0 dólares, pero en promedio para muchas infracciones, la suma de nuestras proyecciones debería aproximarse a nuestros ingresos finales (eso esperamos). Obtenemos las probabilidades de penalización de nuestro modelo Bootstrap Forest, pero ese modelo tomó como entrada las puntuaciones del Análisis de Temas. Por lo tanto, debemos aplicar nuestras nuevas violaciones a través de ambos modelos. Esta no es una práctica poco común, utilizar el resultado de un modelo como entrada para otro.
JMP Puede generar modelos como fórmulas de columna en la tabla de datos original (debajo de las opciones del triángulo rojo en las plataformas de modelado) y se ejecutarán con cualquier dato nuevo que agreguemos a la tabla. Para calificar nuevas observaciones, simplemente agregamos las nuevas infracciones a nuestra tabla, y las fórmulas de columna calculan automáticamente las puntuaciones de los temas y las probabilidades de penalización. Luego creamos una nueva fórmula de columna que multiplica las probabilidades de multa por los montos de la multa impuesta y obtenemos nuestros pagos proyectados. A continuación tenemos proyecciones de 1.000 nuevas infracciones. Predecimos que estos nos generarán alrededor de 1,84 millones de dólares en ingresos, aunque aproximadamente un tercio de ese total corresponde únicamente a los 100 pagos más grandes proyectados en esa cola positiva. La precisión de nuestra proyección dependerá en gran medida de lo que suceda con esas violaciones.
(Un comentario aparte: hemos descrito la forma de apuntar y hacer clic para calificar las observaciones, pero la puntuación podría automatizarse fácilmente mediante secuencias de comandos en JSL (JMP Scripting Language). El modelo también podría implementarse fuera de JMP en un lenguaje como Python o JavaScript, con la capacidad de JMP Pro para escribir código de puntuación en otros lenguajes).
Y esto resalta quizás la pregunta más importante de todas: ¿Qué tan buenas son realmente nuestras proyecciones? Hemos ajustado estadísticas como Entropy RSquare para capturar el rendimiento del modelo, pero lo que en realidad Lo que más nos importa es la exactitud de las proyecciones financieras. En la práctica, habríamos evaluado esto como parte de la fase de construcción del modelo generando una proyección de ingresos para nuestro conjunto de prueba y comparándola con los ingresos reales que observamos. No hicimos esto aquí porque, lamentablemente, los datos disponibles no contenían los importes de las sanciones impuestas inicialmente, sino sólo los importes finales después de la adjudicación. (En el ejemplo de puntuación anterior, imaginamos algunos montos de penalización inicialmente impuestos con fines expositivos).
Un pensamiento de despedida
Si bien hemos llegado a nuestro objetivo (un modelo que asigna probabilidades de sanciones financieras a nuevas violaciones), un proyecto como este nunca se termina realmente. Con el tiempo, pueden surgir nuevos tipos o tendencias de violaciones, nuevas políticas pueden alterar la relación entre las características de las violaciones y los pagos de multas, o las probabilidades de pago de multas podrían simplemente cambiar con el tiempo debido a factores no medidos como la capacidad de aplicación de la ley o la indulgencia. Las tendencias a lo largo del tiempo en el siguiente gráfico podrían sugerir lo último. (El ancho de la línea representa el total de infracciones por año, lo que deja claro que todavía no tenemos suficientes datos en 2020 para confiar en el aumento repentino de este año).
Por muchas razones posibles, nuestro modelo puede volverse menos preciso a medida que pasa el tiempo. Deberíamos reajustar nuestros modelos de Análisis de Temas y Bosque Bootstrap periódicamente, incorporando los datos más recientes (y quizás descartando datos más antiguos) para garantizar que nuestras predicciones sigan siendo precisas.
