Regresión

Un coeficiente que decide un solo caso

La base de ejemplo tiene 150 filas. Se ajusta nota ~ horas + gasto + edad y el coeficiente de gasto da p = 0,201: no significativo, se descarta, se sigue. Es lo que haría cualquiera.

El paso siguiente del proyecto es volver a ajustar el modelo sin el caso de mayor distancia de Cook, que es el caso 96. Con 149 casos en lugar de 150:

El coeficiente se multiplica por dos y medio y el intervalo deja de contener al cero. Una observación entre 150 da vuelta la conclusión.

Y el caso 96 no llega al umbral clásico: su distancia de Cook es 0,948, por debajo del 1 que se cita como línea de corte en todos lados. Quien mire la tabla de diagnóstico buscando un valor mayor que 1 no va a encontrar nada y va a publicar el modelo tranquilo.

Por eso el descargable no termina en el diagnóstico. Saca el caso, vuelve a ajustar y escribe una columna —cambia_la_conclusion— que dice «Sí» cuando un coeficiente cruza el umbral de significación al sacarlo. Es la única forma de saber cuánto pesa un caso: sacarlo y volver a mirar.

Por qué ese caso pesa tanto

Porque no está lejos en la respuesta, está lejos en los predictores. El caso 96 es uno de los tres gastos enormes que el descargable de gráficos deja a la vista en su diagrama de caja, y en una regresión un valor así tiene palanca: la suya es 0,509, contra un umbral de 0,054. Un punto con palanca no es un punto más lejos del promedio. Es un punto que tira del plano de ajuste, y el plano va.

Esa es la diferencia entre mirar la distribución de una variable y mirar la geometría del modelo. Un caso puede estar dentro del rango de todas las variables por separado y aun así ser el que manda en el ajuste.

Lo que revisa

Cada supuesto que no se cumple deja una línea en avisos.csv que dice qué consecuencia tiene, no solo que falló. No es lo mismo que Shapiro-Wilk rechace con 149 casos —casi da igual— que un caso decida un coeficiente.

La logística

El mismo proyecto ajusta una regresión logística sobre una respuesta de dos categorías, y escribe el odds ratio con su intervalo, no el riesgo relativo: no son lo mismo, y con un resultado frecuente el odds ratio exagera bastante.

Al lado de la exactitud del modelo escribe la del modelo trivial, el que siempre contesta la clase más frecuente. En el ejemplo el modelo acierta el 74,5 % y el trivial el 53,0 %: la ganancia es real pero mucho más chica que lo que sugiere el primer número solo. Con clases desbalanceadas esa comparación es lo único que distingue un clasificador de una tirada al aire.

Y si el ajuste no converge —el caso típico es que algún predictor separe perfectamente las dos clases— la tabla de coeficientes queda vacía a propósito, con el aviso que explica por qué. Cuando hay separación el máximo de la verosimilitud no existe: los coeficientes se van al infinito y lo que quedó en la última vuelta no estima nada, es dónde estaba el algoritmo cuando se le acabaron las vueltas. Publicarlo igual sería exactamente el error que este proyecto existe para evitar.

Sin lm ni glm

Las dos versiones escriben los diez archivos byte a byte iguales, y las bibliotecas no lo permiten: lm resuelve por QR y numpy por SVD, así que los coeficientes se separan cerca del décimo dígito; glm y Logit de statsmodels paran de iterar con criterios distintos y ahí la diferencia llega al octavo. La salida es escribir el cálculo una vez de cada lado: eliminación de Gauss con pivoteo parcial para los sistemas, y un IRLS de veinte líneas con la misma tolerancia en los dos idiomas.

El precio está declarado adentro: las ecuaciones normales son menos estables que una QR. Por eso el VIF sale en la tabla de coeficientes y hay un aviso cuando pasa de 10, que es la señal de que el problema está mal condicionado.

Hay un detalle que se nota al comparar contra summary(glm): los coeficientes coinciden hasta el décimo decimal y la devianza coincide exacta, pero los errores estándar difieren en el sexto. No es un error.glm corta de iterar cuando la devianza deja de moverse y calcula los errores estándar con los pesos que tenía guardados en ese momento, que no están evaluados en los coeficientes finales. Acá el corte es cuando los coeficientes dejan de moverse en 10⁻¹⁰, y la información se evalúa ahí. Son tres partes por millón y no cambian ninguna conclusión, pero está documentado en el README con las dos líneas de R que lo muestran, porque si no parece un error.

Qué deja

El modelo se declara en datos/parametros.csv, no en el código: qué se explica, con qué se lo explica y con qué confianza. Cambiar de respuesta o agregar un predictor es editar una línea.

Lo que no hace

No elige el modelo. No hay selección de variables, ni paso a paso, ni criterios de información. Elegir predictores mirando valores p es la receta más rápida para un modelo que no replica en otra muestra.

No hay interacciones ni términos no lineales. Los predictores entran como están.

No hay predictores categóricos. Entran solo numéricos; para una categórica hay que construir las variables indicadoras a mano.

No hay errores estándar robustos. Cuando Breusch-Pagan rechaza, el aviso lo dice y recomienda; el cálculo no está.

Cómo está verificado

Corriéndolo: el verificador descomprime lo publicado, lo corre con Python y con R, exige que los diez archivos salgan idénticos y recalcula todo con una implementación aparte —el ajuste por SVD, que es otro algoritmo que el del descargable; el VIF, la palanca, Cook, Breusch-Pagan y Durbin-Watson escritos de nuevo; el AUC contra el estadístico de Mann-Whitney de SciPy—. Recalcula también el reajuste sin el caso influyente y la columna cambia_la_conclusion, que es lo que justifica el proyecto, y comprueba que los errores estándar de la logística salgan de los pesos convergidos y no de los de la vuelta anterior. Prueba además cuatro bases distintas: una sin respuesta binaria, una con dos predictores casi idénticos —VIF por las nubes—, una con separación perfecta en la logística y una con confianza del 99 %. Son 2.746 comprobaciones, y los veintidós sabotajes se detectan.