Buenas a todos, les dejo aca un resumen de la solución que envié. Quiero aprovechar para agradecer al banco y los sponsors por organizar esta competencia. En especial a Rafael y Pablo de Ombú por la dedicación durante la misma. La oportunidad de aprender en este tipo de eventos en inmensa. Son pocos los lugares donde se pueden compartir experiencias con otras personas que le dedicaron tantas horas al mismo problema. Fue un gusto conocer a muchos de ustedes en el evento de cierre.
\n\nCuando tenga algo de tiempo abro un hilo aparte porque me interesa saber si alguno uso redes y comparar modelos/resultados. Por mi parte hice varios modelos de redes y otros no GBRT para intentar ayudar a la solución GBRT. No tuve resultados concluyentes y no los incluí. La solución final que seleccioné fueron tres modelos basados en LightGBM muy similares. Explico el modelo principal y al final detallo el cambio que hice para los otros dos.
\n\nFeatures: Abrí todas las categorías en one-hot-encoding y agregé algunas features adicionales temporales, por ejemplo, mes y offset en dias. Definí reglas de agregación generales para un determinado intervalo de tiempo (min, mean, max). Mas abajo explico como se armaron los intervalos. Al final del proceso hago una poda de features. No dediqué tiempo a evaluar si en todos los casos hacían sentido las agregaciones.
\n\nCreé dos features totalizadores sobre las paginas que estaban relacionadas con créditos ya que se sospecha que la conversión a identificar viene por ese lado y agregué un feature con las conversiones pasadas del cliente. También incluí la porción de navegación por dispositivo y velocidades.
\n\nUtilizé los textos para generar features nuevos contando la frecuencia de palabras. Considerando que previo a esto estoy estoy en varios miles de features y los conteos de tokens son muy dispersos aplico PCA para reducir a unas pocas features adicionales por textos.
\n\nEl set de datos lo agrego para determinado período. Adicionalmente a agregar el intervalo completo genero un set de features adicional tomado solo el último mes del intervalo. Finalmente genero un tercer set de features haciendo la relación entre el último mes y el intervalo completo.
\n\nPoda de features: Elimino features en base al uso en varias corridas del LightGBM. Esto no debería impactar en mayor medida el rendimiento, pero acelera mucho la búsqueda de hiperparámetros.
\n\nSet de entrenamiento/objetivo: Una de las cosas que mas efecto tuvo en el resultado fue entrenar con un objetivo de un solo mes en lugar de trimestral. De esta forma puedo entrenar con datos hasta noviembre. Si hubiera usado un objetivo trimestral estaría obligado a quedarme en septiembre.
\n\nSobre el conjunto de datos de entrenamiento genero múltiples combinaciones de ventanas de entrenamiento con su respectivo objetivo. Se genera un set de datos con meses [1, 2] con el mes 3 como objetivo. Se adicionan todos los intervalos hasta Noviembre [1,2,3] para 4; [1,2,3,4] para 5… hasta [1…11] para 12.
\n\nEntreno 10 folds partiendo por clientes. Tengo cuidado de hacer la partición por clientes porque de otra forma podría dejar fuera el cliente para un intervalo e incluirlo para otro. Registro la performance de los diez folds por separado y uso los 10 modelos entrenados para generar una predicción.
\n\nPara mejorar la estimación de rendimiento y hacer stacking de modelos entreno aplicando la misma lógica y asumiendo que solo tengo datos hasta el mes 9. Es decir, genero intervalos [1,2] para 3 + [1,2,3] para 4 hasta [1,2,3,4,5] para 6 y mido contra las conversiones de 7,8 y 9. Nuevamente registro la performance de los 10 folds y genero 10 predicciones meses [10,11 y 12]. Esta performance contra el último trimestre la uso para determinar el mejor stacking.
\n\nConsiderando el promedio y desvio de performance de los 20 folds (10 folds con datos completos mas 10 folds de datos parciales) evalúo el rendimiento.
\n\nHago random search posterior búsqueda bayesiana para identificar hiperparámetros.
\n\nPara los dos modelos adicionales que incluyo en el stacking modifiqué el armado de intervalos para que se saltee uno y dos meses: [1] para 3, [1,2] para 4… [1…10] para 12 en el primer caso y [1] para 4, [1,2] para 5 … [1…9] para 12 en el segundo.
\n\nCreo que no estoy dejando nada afuera.
", "comments": [], "comment_count": 0, "messages": [ { "id": 636170, "postDate": "2019-09-28T23:10:33.817Z", "content": "Buenas a todos, les dejo aca un resumen de la solución que envié. Quiero aprovechar para agradecer al banco y los sponsors por organizar esta competencia. En especial a Rafael y Pablo de Ombú por la dedicación durante la misma. La oportunidad de aprender en este tipo de eventos en inmensa. Son pocos los lugares donde se pueden compartir experiencias con otras personas que le dedicaron tantas horas al mismo problema. Fue un gusto conocer a muchos de ustedes en el evento de cierre.
\n\nCuando tenga algo de tiempo abro un hilo aparte porque me interesa saber si alguno uso redes y comparar modelos/resultados. Por mi parte hice varios modelos de redes y otros no GBRT para intentar ayudar a la solución GBRT. No tuve resultados concluyentes y no los incluí. La solución final que seleccioné fueron tres modelos basados en LightGBM muy similares. Explico el modelo principal y al final detallo el cambio que hice para los otros dos.
\n\nFeatures: Abrí todas las categorías en one-hot-encoding y agregé algunas features adicionales temporales, por ejemplo, mes y offset en dias. Definí reglas de agregación generales para un determinado intervalo de tiempo (min, mean, max). Mas abajo explico como se armaron los intervalos. Al final del proceso hago una poda de features. No dediqué tiempo a evaluar si en todos los casos hacían sentido las agregaciones.
\n\nCreé dos features totalizadores sobre las paginas que estaban relacionadas con créditos ya que se sospecha que la conversión a identificar viene por ese lado y agregué un feature con las conversiones pasadas del cliente. También incluí la porción de navegación por dispositivo y velocidades.
\n\nUtilizé los textos para generar features nuevos contando la frecuencia de palabras. Considerando que previo a esto estoy estoy en varios miles de features y los conteos de tokens son muy dispersos aplico PCA para reducir a unas pocas features adicionales por textos.
\n\nEl set de datos lo agrego para determinado período. Adicionalmente a agregar el intervalo completo genero un set de features adicional tomado solo el último mes del intervalo. Finalmente genero un tercer set de features haciendo la relación entre el último mes y el intervalo completo.
\n\nPoda de features: Elimino features en base al uso en varias corridas del LightGBM. Esto no debería impactar en mayor medida el rendimiento, pero acelera mucho la búsqueda de hiperparámetros.
\n\nSet de entrenamiento/objetivo: Una de las cosas que mas efecto tuvo en el resultado fue entrenar con un objetivo de un solo mes en lugar de trimestral. De esta forma puedo entrenar con datos hasta noviembre. Si hubiera usado un objetivo trimestral estaría obligado a quedarme en septiembre.
\n\nSobre el conjunto de datos de entrenamiento genero múltiples combinaciones de ventanas de entrenamiento con su respectivo objetivo. Se genera un set de datos con meses [1, 2] con el mes 3 como objetivo. Se adicionan todos los intervalos hasta Noviembre [1,2,3] para 4; [1,2,3,4] para 5… hasta [1…11] para 12.
\n\nEntreno 10 folds partiendo por clientes. Tengo cuidado de hacer la partición por clientes porque de otra forma podría dejar fuera el cliente para un intervalo e incluirlo para otro. Registro la performance de los diez folds por separado y uso los 10 modelos entrenados para generar una predicción.
\n\nPara mejorar la estimación de rendimiento y hacer stacking de modelos entreno aplicando la misma lógica y asumiendo que solo tengo datos hasta el mes 9. Es decir, genero intervalos [1,2] para 3 + [1,2,3] para 4 hasta [1,2,3,4,5] para 6 y mido contra las conversiones de 7,8 y 9. Nuevamente registro la performance de los 10 folds y genero 10 predicciones meses [10,11 y 12]. Esta performance contra el último trimestre la uso para determinar el mejor stacking.
\n\nConsiderando el promedio y desvio de performance de los 20 folds (10 folds con datos completos mas 10 folds de datos parciales) evalúo el rendimiento.
\n\nHago random search posterior búsqueda bayesiana para identificar hiperparámetros.
\n\nPara los dos modelos adicionales que incluyo en el stacking modifiqué el armado de intervalos para que se saltee uno y dos meses: [1] para 3, [1,2] para 4… [1…10] para 12 en el primer caso y [1] para 4, [1,2] para 5 … [1…9] para 12 en el segundo.
\n\nCreo que no estoy dejando nada afuera.
", "rawMarkdown": "Buenas a todos, les dejo aca un resumen de la solución que envié. Quiero aprovechar para agradecer al banco y los sponsors por organizar esta competencia. En especial a Rafael y Pablo de Ombú por la dedicación durante la misma. La oportunidad de aprender en este tipo de eventos en inmensa. Son pocos los lugares donde se pueden compartir experiencias con otras personas que le dedicaron tantas horas al mismo problema. Fue un gusto conocer a muchos de ustedes en el evento de cierre. \n\nCuando tenga algo de tiempo abro un hilo aparte porque me interesa saber si alguno uso redes y comparar modelos/resultados. Por mi parte hice varios modelos de redes y otros no GBRT para intentar ayudar a la solución GBRT. No tuve resultados concluyentes y no los incluí. La solución final que seleccioné fueron tres modelos basados en LightGBM muy similares. Explico el modelo principal y al final detallo el cambio que hice para los otros dos. \n\n**Features**: Abrí todas las categorías en one-hot-encoding y agregé algunas features adicionales temporales, por ejemplo, mes y offset en dias. Definí reglas de agregación generales para un determinado intervalo de tiempo (min, mean, max). Mas abajo explico como se armaron los intervalos. Al final del proceso hago una poda de features. No dediqué tiempo a evaluar si en todos los casos hacían sentido las agregaciones. \n\nCreé dos features totalizadores sobre las paginas que estaban relacionadas con créditos ya que se sospecha que la conversión a identificar viene por ese lado y agregué un feature con las conversiones pasadas del cliente. También incluí la porción de navegación por dispositivo y velocidades.\n\nUtilizé los textos para generar features nuevos contando la frecuencia de palabras. Considerando que previo a esto estoy estoy en varios miles de features y los conteos de tokens son muy dispersos aplico PCA para reducir a unas pocas features adicionales por textos. \n\nEl set de datos lo agrego para determinado período. Adicionalmente a agregar el intervalo completo genero un set de features adicional tomado solo el último mes del intervalo. Finalmente genero un tercer set de features haciendo la relación entre el último mes y el intervalo completo.\n\n**Poda de features**: Elimino features en base al uso en varias corridas del LightGBM. Esto no debería impactar en mayor medida el rendimiento, pero acelera mucho la búsqueda de hiperparámetros. \n\n**Set de entrenamiento/objetivo**: Una de las cosas que mas efecto tuvo en el resultado fue entrenar con un objetivo de un solo mes en lugar de trimestral. De esta forma puedo entrenar con datos hasta noviembre. Si hubiera usado un objetivo trimestral estaría obligado a quedarme en septiembre.\n\nSobre el conjunto de datos de entrenamiento genero múltiples combinaciones de ventanas de entrenamiento con su respectivo objetivo. Se genera un set de datos con meses [1, 2] con el mes 3 como objetivo. Se adicionan todos los intervalos hasta Noviembre [1,2,3] para 4; [1,2,3,4] para 5… hasta [1…11] para 12. \n\nEntreno 10 folds partiendo por clientes. Tengo cuidado de hacer la partición por clientes porque de otra forma podría dejar fuera el cliente para un intervalo e incluirlo para otro. Registro la performance de los diez folds por separado y uso los 10 modelos entrenados para generar una predicción. \n\nPara mejorar la estimación de rendimiento y hacer stacking de modelos entreno aplicando la misma lógica y asumiendo que solo tengo datos hasta el mes 9. Es decir, genero intervalos [1,2] para 3 + [1,2,3] para 4 hasta [1,2,3,4,5] para 6 y mido contra las conversiones de 7,8 y 9. Nuevamente registro la performance de los 10 folds y genero 10 predicciones meses [10,11 y 12]. Esta performance contra el último trimestre la uso para determinar el mejor stacking.\n\nConsiderando el promedio y desvio de performance de los 20 folds (10 folds con datos completos mas 10 folds de datos parciales) evalúo el rendimiento. \n\nHago random search posterior búsqueda bayesiana para identificar hiperparámetros.\n\nPara los dos modelos adicionales que incluyo en el stacking modifiqué el armado de intervalos para que se saltee uno y dos meses: [1] para 3, [1,2] para 4… [1…10] para 12 en el primer caso y [1] para 4, [1,2] para 5 … [1…9] para 12 en el segundo. \n\nCreo que no estoy dejando nada afuera.", "votes": 10 } ], "complete": true, "source": "live", "fetched_at": "2026-10-19T11:55:32Z", "competition_id": 15128, "competition_slug": "banco-galicia-dataton-2019", "team_id": 3419614, "solution_url": "/competitions/banco-galicia-dataton-2019/writeups/aaraneo-soluci-n-1er-puesto" }