Continuando co tema dos concursos de aprendizaxe automática en Habré, gustaríanos presentar aos lectores dúas plataformas máis. Certamente non son tan grandes como kaggle, pero definitivamente merecen atención.

Persoalmente, non me gusta moito o kaggle por varias razóns:

• en primeiro lugar, as competicións alí adoitan durar varios meses, e a participación activa require moito esforzo;
• en segundo lugar, núcleos públicos (solucións públicas). Os seguidores de Kaggle aconsellan tratalos coa calma dos monxes tibetanos, pero en realidade é unha vergoña cando algo no que levas traballando durante un mes ou dous resulta de súpeto colocado nun prato para todos.

Afortunadamente, os concursos de aprendizaxe automática celébranse noutras plataformas e discutiranse algúns destes concursos.

IDAO	SNA Hackathon 2019
Idioma oficial: inglés, organizadores: Yandex, Sberbank, HSE	Lingua oficial rusa, organizadores: Mail.ru Group
Rolda en liña: 15 de xaneiro - 11 de febreiro de 2019; Final in situ: do 4 ao 6 de abril de 2019	en liña - do 7 de febreiro ao 15 de marzo; fóra de liña: do 30 de marzo ao 1 de abril.
Usando un determinado conxunto de datos sobre unha partícula do Gran Colisionador de Hadrones (traxectoria, momento e outros parámetros físicos bastante complexos), determina se é un muón ou non. A partir desta declaración, identificáronse 2 tarefas: - nun só tiñas que enviar a túa predición, - e no outro - o código completo e o modelo para a predición, e a execución estaba suxeita a restricións bastante estritas sobre o tempo de execución e o uso da memoria	Para a competición SNA Hackathon, recompiláronse rexistros de mostras de contido dos grupos abertos nas fontes de noticias dos usuarios de febreiro a marzo de 2018. O conxunto de probas contén a última semana e media de marzo. Cada entrada do rexistro contén información sobre o que se mostrou e a quen, así como como reaccionou o usuario ante este contido: valorouno, comentouno, ignorouno ou ocultouno da fonte. A esencia das tarefas do SNA Hackathon é clasificar cada usuario da rede social Odnoklassniki o seu feed, elevando o máis alto posible aquelas publicacións que recibirán unha "clase". Na fase en liña, a tarefa dividiuse en 3 partes: 1. clasifica os postos segundo diversas características colaborativas 2. clasifica as publicacións en función das imaxes que conteñan 3. clasifica os postos segundo o texto que conteñan
Métrica personalizada complexa, algo así como ROC-AUC	Media ROC-AUC por usuario
Premios da primeira etapa - Camisetas para N prazas, paso á segunda etapa, onde se pagaba aloxamento e comidas durante o concurso. Segunda fase -??? (Por certos motivos, non estiven presente na entrega de premios e ao final non puiden saber cales foron os premios). Prometeron portátiles a todos os membros do equipo gañador	Premios para a primeira etapa: camisetas para os 100 mellores participantes, paso á segunda etapa, onde se pagou a viaxe a Moscova, aloxamento e comidas durante a competición. Ademais, cara ao final da primeira etapa, anunciouse os premios para o mellor en 3 tarefas na etapa 1: todos gañaron unha tarxeta de vídeo RTX 2080 TI! A segunda fase foi unha fase por equipos, os equipos estaban formados por 2 a 5 persoas, premios: 1º lugar - 300 rublos 2º lugar - 200 rublos 3º lugar - 100 rublos premio do xurado - 100 rublos
Grupo oficial de Telegram, ~190 participantes, comunicación en inglés, as preguntas tiveron que esperar varios días para obter unha resposta	Grupo oficial en telegrama, ~1500 participantes, discusión activa de tarefas entre participantes e organizadores
Os organizadores achegaron dúas solucións básicas, sinxelas e avanzadas. O sinxelo requiría menos de 16 GB de RAM e a memoria avanzada non cabía en 16. Ao mesmo tempo, mirando un pouco cara adiante, os participantes non foron capaces de superar significativamente a solución avanzada. Non houbo dificultades para lanzar estas solucións. Cómpre sinalar que no exemplo avanzado había un comentario cunha pista sobre por onde comezar a mellorar a solución.	Aportáronse solucións primitivas básicas para cada unha das tarefas, que foron facilmente superadas polos participantes. Nos primeiros días da competición, os participantes atoparon varias dificultades: en primeiro lugar, os datos ofrecíanse en formato Apache Parquet e non todas as combinacións de Python e o paquete parquet funcionaron sen erros. A segunda dificultade foi descargar imaxes da nube de correo; polo momento non hai un xeito sinxelo de descargar unha gran cantidade de datos á vez. Como resultado, estes problemas atrasaron os participantes un par de días.

IDAO. Primeira etapa

A tarefa consistiu en clasificar as partículas muónicas/non muónicas segundo as súas características. A característica fundamental desta tarefa foi a presenza dunha columna de peso nos datos de adestramento, que os propios organizadores interpretaron como confianza na resposta para esta liña. O problema era que bastantes filas contiñan pesos negativos.

Despois de pensar durante uns minutos na liña coa suxestión (a suxestión simplemente chamou a atención sobre esta característica da columna de peso) e construír este gráfico, decidimos comprobar 3 opcións:

1) inverte o obxectivo de liñas con pesos negativos (e pesos en consecuencia)
2) mover os pesos ao valor mínimo para que comecen desde 0
3) non use pesos de corda

A terceira opción resultou ser a peor, pero as dúas primeiras melloraron o resultado, a mellor foi a opción número 1, que de inmediato nos levou ao actual segundo posto na primeira tarefa e primeiros na segunda.

O noso seguinte paso foi revisar os datos para detectar os valores que faltan. Os organizadores déronnos datos xa peiteados, onde faltaban bastantes valores, e foron substituídos por -9999.

Atopamos valores que faltan nas columnas MatchedHit_{X,Y,Z}[N] e MatchedHit_D{X,Y,Z}[N], e só cando N=2 ou 3. Como entendemos, algunhas partículas non pasar os 4 detectores e detívose na 3ª ou 4ª placa. Os datos tamén contiñan columnas Lextra_{X,Y}[N], que aparentemente describen o mesmo que MatchedHit_{X,Y,Z}[N], pero usando algún tipo de extrapolación. Estas escasas estimacións suxeriron que Lextra_{X,Y}[N] podería substituírse polos valores que faltan en MatchedHit_{X,Y,Z}[N] (só para as coordenadas X e Y). MatchedHit_Z[N] encheuse ben coa mediana. Estas manipulacións permitíronnos acadar o 1o posto intermedio en ambas as tarefas.

Tendo en conta que non deron nada por gañar a primeira etapa, puidemos parar alí, pero seguimos, fixemos uns fermosos debuxos e presentamos novidades.

Por exemplo, descubrimos que se trazamos os puntos de intersección dunha partícula con cada unha das catro placas detectoras, podemos ver que os puntos de cada unha das placas están agrupados en 5 rectángulos cunha relación de aspecto de 4 a 5 e centrados en o punto (0,0), e en Non hai puntos no primeiro rectángulo.

Número de placa / dimensións do rectángulo	1	2	3	4	5
Placa 1	500h625	1000h1250	2000h2500	4000h5000	8000h10000
Placa 2	520h650	1040h1300	2080h2600	4160h5200	8320h10400
Placa 3	560h700	1120h1400	2240h2800	4480h5600	8960h11200
Placa 4	600h750	1200h1500	2400h3000	4800h6000	9600h12000

Unha vez determinadas estas dimensións, engadimos 4 novas características categóricas para cada partícula: o número do rectángulo no que corta cada placa.

Tamén observamos que as partículas parecían espallarse cara aos lados desde o centro e xurdiu a idea de avaliar dalgún xeito a "calidade" desta dispersión. Idealmente, probablemente sería posible elaborar algún tipo de parábola "ideal" dependendo do punto de despegue e estimar a desviación deste, pero limitámonos á liña recta "ideal". Unha vez construídas estas liñas rectas ideais para cada punto de entrada, puidemos calcular a desviación estándar da traxectoria de cada partícula a partir desta recta. Dado que a desviación media para o obxectivo = 1 foi de 152 e para o obxectivo = 0 foi de 390, avaliamos provisionalmente esta característica como boa. E, de feito, esta función chegou inmediatamente á cima das máis útiles.

Estivemos encantados e engadimos a desviación dos 4 puntos de intersección para cada partícula da liña recta ideal como 4 características adicionais (e tamén funcionaron ben).

Os enlaces a artigos científicos sobre o tema do concurso, que nos facilitaron os organizadores, fixeron pensar que estamos lonxe de ser os primeiros en resolver este problema e, se cadra, existe algún tipo de software especializado. Despois de descubrir un repositorio en github onde se implementaron os métodos IsMuonSimple, IsMuon, IsMuonLoose, trasladámolos ao noso sitio con pequenas modificacións. Os métodos en si eran moi sinxelos: por exemplo, se a enerxía é inferior a un determinado limiar, entón non é un muón, se non, é un muón. Obviamente, tales funcións sinxelas non poderían aumentar no caso de usar o aumento do gradiente, polo que engadimos outra "distancia" significativa ao limiar. Estas características tamén foron lixeiramente melloradas. Quizais, analizando os métodos existentes máis a fondo, fose posible atopar métodos máis fortes e engadilos aos sinais.

Ao final da competición, axustamos lixeiramente a solución "rápida" para o segundo problema; ao final, difería da liña de base nos seguintes puntos:

1. Nas filas con peso negativo o obxectivo foi invertido
2. Encheuse os valores que faltan en MatchedHit_{X,Y,Z}[N]
3. Profundidade reducida a 7
4. Reduciuse a taxa de aprendizaxe a 0.1 (antes 0.19)

Como resultado, probamos máis funcións (non con moito éxito), seleccionamos parámetros e adestramos catboost, lightgbm e xgboost, probamos diferentes combinacións de predicións e antes de abrir o privado gañamos con confianza na segunda tarefa e na primeira estivemos entre os líderes.

Despois de abrir o privado quedamos no 10o posto para a 1a tarefa e 3o para a segunda. Todos os líderes mesturáronse, e a velocidade en privado era maior que na librería. Parece que os datos estaban mal estratificados (ou por exemplo non había filas con pesos negativos no privado) e isto foi un pouco frustrante.

SNA Hackathon 2019 - Textos. Primeira etapa

A tarefa consistía en clasificar as publicacións dos usuarios na rede social Odnoklassniki en función do texto que contiñan; ademais do texto, había algunhas características máis da publicación (idioma, propietario, data e hora de creación, data e hora de visualización). ).

Como enfoques clásicos para traballar co texto, destacaría dúas opcións:

1. Asignación de cada palabra nun espazo vectorial n-dimensional de forma que palabras similares teñan vectores similares (le máis en o noso artigo), despois ben atopando a palabra media para o texto ou ben utilizando mecanismos que teñan en conta a posición relativa das palabras (CNN, LSTM/GRU).
2. Usando modelos que poidan funcionar inmediatamente con frases enteiras. Por exemplo, Bert. En teoría, este enfoque debería funcionar mellor.

Dado que esta foi a miña primeira experiencia con textos, estaría mal ensinarlle a alguén, así que ensinarei eu mesmo. Estes son os consellos que me daría ao comezo do concurso:

1. Antes de correr para ensinar algo, mira os datos! Ademais do texto en si, os datos tiñan varias columnas e era posible espremerlles moito máis ca min. O máis sinxelo é facer a codificación de destino para algunhas das columnas.
2. Non aprendas de todos os datos! Había moitos datos (uns 17 millóns de filas) e non era absolutamente necesario utilizalos todos para probar hipóteses. O adestramento e o preprocesamento foron bastante lentos e, obviamente, tería tempo de probar hipóteses máis interesantes.
3. <Consello polémico> Non hai que buscar un modelo asasino. Pasei moito tempo descubrindo a Elmo e Bert, esperando que me levasen inmediatamente a un lugar alto e, como resultado, usei incorporacións preadestradas de FastText para a lingua rusa. Non puiden acadar mellor velocidade con Elmo, e aínda non tiven tempo de descifralo con Bert.
4. <Consello polémico> Non é necesario buscar unha función de asasinato. Mirando os datos, notei que ao redor do 1 por cento dos textos non contén texto. Pero había ligazóns a algúns recursos e escribín un analizador sinxelo que abriu o sitio e sacou o título e a descrición. Pareceume unha boa idea, pero entón deixeime levar e decidín analizar todas as ligazóns para todos os textos e de novo perdín moito tempo. Todo isto non supuxo unha mellora significativa no resultado final (aínda que descubrín que se derivaba, por exemplo).
5. Funcionan as funcións clásicas. Nós Google, por exemplo, "funcións de texto kaggle", lemos e engadimos todo. TF-IDF proporcionou unha mellora, así como funcións estatísticas como a lonxitude do texto, as palabras e a cantidade de puntuación.
6. Se hai columnas DateTime, paga a pena analizalas en varias características separadas (horas, días da semana, etc.). As características que se deben destacar deben ser analizadas mediante gráficos/algunhas métricas. Aquí, por capricho, fixen todo correctamente e destaquei as características necesarias, pero unha análise normal non tería mal (por exemplo, como fixemos na final).

Como resultado da competición, adestrei un modelo de keras con convolución de palabras e outro baseado en LSTM e GRU. Ambos utilizaron incorporacións de FastText previamente adestradas para a lingua rusa (intentei outras incorporacións, pero estas foron as que mellor funcionaron). Despois de facer a media das previsións, ocupei o sétimo lugar final de 7 participantes.

Despois da primeira etapa publicouse artigo de Nikolai Anokhin, que ocupou o segundo posto (participou fóra de concurso), e a súa solución ata algunha etapa repetiu a miña, pero foi máis aló debido ao mecanismo de atención consulta-clave-valor.

Segunda etapa OK e IDAO

As segundas fases das competicións desenvolvéronse case de xeito consecutivo, polo que decidín miralas xuntos.

En primeiro lugar, eu e o equipo recén adquirido acabamos na impresionante oficina da empresa Mail.ru, onde a nosa tarefa era combinar os modelos de tres pistas da primeira etapa: texto, imaxes e colaboración. Para iso dedicouse algo máis de 2 días, que resultou ser moi pouco. De feito, só puidemos repetir os nosos resultados desde a primeira etapa sen recibir ningún beneficio da fusión. Ao final, quedamos no 5o lugar, pero non puidemos utilizar o modelo de texto. Despois de mirar as solucións doutros participantes, parece que valeu a pena tentar agrupar os textos e engadilos ao modelo de colaboración. Un efecto secundario desta etapa foron as novas impresións, a reunión e comunicación con participantes e organizadores xeniais, así como a grave falta de sono, que puido afectar o resultado da fase final de IDAO.

A tarefa na fase final de IDAO 2019 foi prever o tempo de espera para unha orde para os taxistas de Yandex no aeroporto. Na fase 2 identificáronse 3 tarefas = 3 aeroportos. Para cada aeroporto, ofrécense datos minuto a minuto sobre o número de pedidos de taxi durante seis meses. E como datos de proba, proporcionáronse os datos do mes seguinte e minuto a minuto sobre os pedidos das dúas últimas semanas. Houbo pouco tempo (2 días), a tarefa foi bastante concreta, só chegou unha persoa do equipo á competición e, como resultado, foi un lugar triste cara ao final. As ideas interesantes incluíron intentos de utilizar datos externos: tempo, atascos e estatísticas de pedidos de taxi de Yandex. Aínda que os organizadores non dixeron cales eran estes aeroportos, moitos participantes asumiron que eran Sheremetyevo, Domodedovo e Vnukovo. Aínda que esta suposición foi refutada despois da competición, as características, por exemplo, dos datos meteorolóxicos de Moscova melloraron os resultados tanto na validación como na táboa de clasificación.

Conclusión

1. As competicións de ML son xeniais e interesantes! Aquí atoparás o uso de habilidades na análise de datos, e en modelos e técnicas astutos, e simplemente o sentido común é benvido.
2. ML xa é un enorme corpo de coñecemento que parece estar crecendo exponencialmente. Púxenme o obxectivo de familiarizarme con diferentes áreas (sinais, imaxes, táboas, texto) e xa me decatei do moito que hai que estudar. Por exemplo, despois destes concursos decidín estudar: algoritmos de agrupación, técnicas avanzadas para traballar con bibliotecas de aumento de gradiente (en particular, traballar con CatBoost na GPU), redes de cápsulas, o mecanismo de atención de consulta-clave-valor.
3. Non só por cagar! Hai moitos outros concursos nos que é máis fácil conseguir polo menos unha camiseta, e hai máis posibilidades para outros premios.
4. Comunícate! Xa existe unha gran comunidade no campo da aprendizaxe automática e da análise de datos, hai grupos temáticos en telegram, slack e xente seria de Mail.ru, Yandex e outras empresas responden preguntas e axudan aos principiantes e aos que continúan o seu camiño neste campo. de coñecemento.
5. Aconsello a todos os que se inspiraron no punto anterior que visiten datafest — unha importante conferencia gratuíta en Moscova, que terá lugar os días 10 e 11 de maio.

Fonte: www.habr.com