¿Cómo realizan los científicos de datos la selección del modelo? Al abordar, por ejemplo, un problema de clasificación, ¿cómo eligen los científicos de datos entre regresión logística, SVM, KNN, árboles de decisión, redes neuronales, etc.? ¿Es diferente para Kaggle?

La respuesta de Sebastian es fantástica, como siempre. Quiero agregar un punto a los cuatro puntos que mencionó, que son “restricciones de producto”.

Como ejemplo, creamos un modelo de predicción de fraude. Sería relativamente fácil usar bosques aleatorios o regresión logística en ese modelo, pero había una restricción: no podíamos tener falsos positivos.

Podríamos haber usado umbrales para evitar falsos positivos, pero estaríamos perdiendo rendimiento predictivo. La solución fue escribir un nuevo algoritmo, una especie de sistema de puntuación probabilístico multivariante.

Estas restricciones son muy raras y aparecen principalmente en situaciones muy específicas, a menudo difíciles. En su mayoría están relacionados con el riesgo. La mayoría de las veces estamos contentos de tener un bajo riesgo. En estas ocasiones, generalmente queremos evitar por completo el riesgo.

Las implicaciones de la selección del modelo son más extremas porque cuando estamos construyendo un modelo, aceptamos un cierto grado de error. En estos casos, no lo hacemos. El producto final debe tener un comportamiento poco común. Esto crea excepciones con las que rara vez tenemos que lidiar.

Como dijo Box … “Todos los modelos están equivocados, algunos son útiles”.

Me gustaría limitar su pregunta para abarcar su objetivo: predicción, inferencia? En situaciones de trabajo diario, usted o el PI conocen la dirección del problema o qué preguntas hacer, lo que solucionará un sesgo. Primero aplica un modelo entrenado explicable simple. Usted encuentra el MSE u otra métrica apropiada para determinar que está obteniendo una señal de respuesta razonable o alguna función apropiada y con suerte degradada y repita. La validación cruzada puede ser su amigo para la mayoría de las técnicas citadas ciertamente para los conjuntos de prueba. La reducción de RSS o MSE para los datos de prueba en sus diversas encarnaciones que hacen que la compensación de varianza / sesgo funcione para una aplicación particular que conoce es un objetivo para la predicción.

Kaggel es divertido o frustrante. No son cosas cotidianas de producción de rutina. Los Kagglers generalmente operan en un ciclo de comportamiento bien conocido … obtener una corazonada, tirar todo por lo general SVM / Random Forest, etc., mira tu puntaje.

Aquí hay un artículo relativamente reciente de Wit (2012) que presenta una visión general de alto nivel de por qué los estadísticos se preocupan por esto.

http://www.philos.rug.nl/~romeyn …

Al final del documento, hay una evaluación personal interesante. Responde esas preguntas y conocerás tus prejuicios.

Aunque, estoy de acuerdo en que Kaggle puede ser un buen patio de recreo para experimentos, por lo general, ni siquiera se acerca a una aplicación del “mundo real” :). (¿Recuerda el premio NetFlix? “Netflix nunca usó su algoritmo de $ 1 millón debido a los costos de ingeniería”)

Entonces, ¡diría que realmente quieres definir una métrica para “éxito”! Es muy importante tener claro su objetivo antes de realizar cualquier tipo de modelado. En la práctica, a menudo se reduce a encontrar un punto dulce entre

1. Cumplir con la fecha límite del proyecto
2. alto rendimiento predictivo
3. alta eficiencia computacional
4. buena interpretabilidad

Estos aspectos difieren de un proyecto a otro, y es realmente importante tener claro de antemano lo que está tratando de lograr. Por ejemplo, supongamos que logró crear un modelo con un puntaje de 0,98 en su escala métrica de rendimiento favorita de 0-1. ¿Vale la pena pasar un par de días, semanas, meses o años más para obtener otra mejora de 0.05? Depende de su fecha de entrega, depende del hardware informático disponible y, con el tiempo, también puede ser importante saber qué sucede debajo del capó (¿sus colaboradores estarían contentos con otro de estos frankensteins XGBoost de conjunto de múltiples capas? )

Dado que usted preguntó sobre algoritmos particulares: Personalmente, normalmente abordaría un nuevo problema comenzando con una regresión logística simple (o regresión softmax), después de explorar el conjunto de datos, para obtener un punto de referencia inicial. A continuación, exploraría los espacios de hipótesis por partes o no lineales, como árboles de decisión, bosques aleatorios, SVM (núcleo Rbf). Si esto no es suficiente, exploraría otras opciones, incluidas MLP, RNN y ConvNets, si corresponde.

Para proporcionarle un ejemplo del mundo real en este punto: recientemente terminé usando un árbol de decisión simple para un proyecto reciente en aras de la interpretabilidad :). Estaba colaborando con biólogos experimentales que me proporcionaron cientos de mediciones experimentales de moléculas químicas que probaron en un sistema en particular. Eventualmente, querían que les dijera qué átomos particulares en qué posición son más importantes para activar esa respuesta para diseñar moléculas más efectivas. Aquí, terminé usando métodos basados ​​en árboles, ya que un árbol de decisión era algo que podía explicar fácilmente a una persona que no es de aprendizaje automático. Por ejemplo, “Si tiene un grupo ceto en esta posición y un grupo nitrógeno en esta posición, entonces … etc.”

En mi opinión, es bastante diferente entre en la vida real y en Kaggle.

En la competencia de Kaggle, solo apunta a la cima, por lo que siempre mejora la precisión de su modelo . No importa cuán complicado sea el modelo, no importa cuánto tiempo tarde en ejecutarse, siempre que haya mejorado su resultado, es bueno. Muchas veces, los modelos que hizo son realmente difíciles de interpretar, pero no es necesario, el resultado lo dice todo.

En la vida real, es diferente. Cuando trabaja en una empresa, la precisión del modelo sigue siendo importante, pero no es el único criterio para su modelo. Dado que el modelo que hizo es probable que se incluya en el producto de la compañía. Si se implementa en una aplicación en tiempo real, es decir, dispositivos de seguimiento o juegos, ciertamente no desea que el modelo se ejecute durante 10 minutos y le diga al usuario el resultado … Desea que muestre el resultado lo antes posible para que los usuarios tienen una experiencia más fluida al usar su producto. Tampoco querrás tener un modelo que se ejecute en poco tiempo pero que genere una predicción / resultado muy malo, que también arruinará la experiencia del usuario. Por lo tanto, es importante encontrar un punto medio entre la precisión del modelo y la eficiencia .

Por lo general, la interpretabilidad también es importante . Cuando tienes un modelo y quieres mostrárselo a tu jefe, excepto por un buen poder de predicción y una complejidad de tiempo razonable, quieres explicar por qué construyes este modelo, cuáles son las variables que usas, bla, bla, bla … No tienes No quiero decirle a su jefe “No sé por qué funciona, acabo de construir este modelo”, simplemente no funciona.

Otra cosa que quizás deba considerar también es cómo mejorar / actualizar su modelo en tiempo real cuando llegan nuevos datos . Esto probablemente esté más relacionado con el software, pero vale la pena considerarlo en mi opinión.

Como he sido A2A y no creo que pueda mejorar mucho las respuestas aquí, voy a llegar a algunos puntos importantes que otros han mencionado, como resumen.

1. Kaggle es diferente a la vida real.
2. La selección del modelo depende de muchas cosas, incluidos, entre otros: los datos, las suposiciones que está dispuesto a hacer, el tiempo que tiene, la necesidad de transparencia frente al poder predictivo, su audiencia, la pregunta (comercial o científica u otra) … Podría seguir.
3. Por lo tanto, concéntrese en el problema y piense en la mejor manera en que se puede abordar con lo que tiene en lugar de cuán genial es su modelo. Hacemos lo que hacemos para no parecernos geniales (o como quiera que nos veamos), sino para resolver problemas. Si resolvemos bien el problema y para satisfacción de quien sea que lo estemos resolviendo mientras nos vemos bien, eso es una ventaja adicional.

Depende de cuál es el objetivo final y cómo se ven los datos.

• Por pura precisión, generalmente uso validación cruzada en un conjunto de desarrollo para elegir el modelo final.
• Si es para explicar lo que está sucediendo, entonces la interpretabilidad es importante.
• Si se va a utilizar en un entorno de producción durante mucho tiempo, la interpretabilidad y la simplicidad técnica (es decir, qué tan fácil es depurar y cuánto tiempo lleva ejecutar) es importante.
• Para conjuntos de datos realmente grandes, la selección del modelo se reduce a qué técnica terminará en el tiempo que tengo.

Estoy de acuerdo con la respuesta de Jordon, un aspecto adicional a incluir junto con la estrategia de validación cruzada es validar el modelo con diferentes parámetros de regularización también.