Use Case
Reduzir o Desemprego com IA
Paulo Maia · 18 de janeiro de 2021
Com a COVID-19, muitas pessoas foram afetadas pela crise económica e perderam o seu emprego. Em Portugal, apenas entre fevereiro e setembro, houve um aumento de 30% no desemprego! A IA pode ser uma ferramenta poderosa na alocação de recursos limitados de forma mais eficiente. Inspirados pelo Projeto DSSG Fellowship em Parceria com o IEFP (Instituto de Emprego e Formação em Portugal), começámos a pensar em como poderíamos ajudar a reduzir o desemprego com IA.
De forma semelhante ao projeto DSSG, os objetivos que serão discutidos aqui são:
- Identificar melhor os indivíduos em risco elevado de desemprego prolongado;
- Apoiar uma alocação mais eficiente dos recursos do instituto de emprego/formação para responder às necessidades dos indivíduos desempregados.
Este é um resumo de uma discussão interna não exaustiva, apenas para fins educacionais. Existem múltiplas soluções, todas dependentes do tempo de desenvolvimento e dos dados aos quais tem acesso.
Dados e Padrões Relevantes
Vamos assumir que conseguimos recolher dados quando a pessoa desempregada se regista na plataforma online, e todas as interações relacionadas com emprego são armazenadas até o candidato encontrar um trabalho. Por razões de simplificação, podemos construir o nosso conjunto de dados a partir de uma lista de snapshots mensais das características de todos os utilizadores da plataforma, que têm um identificador único.
Que informações brutas seriam interessantes ter?
Candidato
- Dados demográficos (Idade, Género, Estado Civil, Morada)
- Lista de cursos anteriores e nível de educação
- Curriculum Vitae
- Anos de Experiência
- Distância máxima de deslocação para trabalho
- Horário em que consegue trabalhar
- Número de dependentes
- Deficiências
- Idiomas
- Competências
Como codificar de forma semelhante a informação de uma pessoa com 10 cursos anteriores versus uma com 2?
Opções de Codificação para Lista de Cursos Anteriores
- Label Encoding: Podemos representar cada curso como um número. Mas isto significa que o curso número k está a uma distância maior do curso k – 5 do que do curso k – 1, o que pode não ser a melhor forma de representar isto.
- One Hot Encoding: Podemos representar cada curso como uma nova coluna. Com elevada dimensionalidade, isto torna-se muito disperso.
- Content Based: Esta abordagem considera uma representação específica do domínio, onde conseguimos codificar os cursos por várias áreas de expertise (por exemplo, Matemática, Química, Programação, etc.). Como valores, podemos representá-lo como binário (o curso cobre essa área ou não) ou representá-lo pela nota média do candidato nessas áreas.
- Embedding Based: A partir de uma lista de cursos, treinar uma representação vetorial (embedding) do zero ou baseada em conteúdo encontrado em fontes externas, de forma que cursos semelhantes tenham distâncias menores entre eles. Podemos depois usar um modelo que consegue lidar com formatos de entrada variáveis (por exemplo, RNN, CNN).
Opções de Codificação para Curriculum Vitae (CV)
O CV do candidato também é rico em dados. Poderíamos usar várias técnicas de NLP para extrair dados daqui, como Bag of Words ou o valor médio de embedding de palavras (que tem a vantagem de ter uma representação semântica das palavras).
Nota sobre fairness: Poderíamos ter adicionado uma funcionalidade relacionada com as despesas mensais do candidato, como forma de estimar quanto dinheiro ele precisaria por mês. Mas isto poderia criar um ciclo de retroalimentação negativo. Se tem despesas baixas porque não tem capacidade para viver uma vida melhor, o modelo poderia estar a alocá-lo a ofertas com salários baixos.
Contexto
- Histórico de Desemprego (por exemplo, número total de meses desde o último emprego, estatísticas de tempo de desemprego no passado – máximo, média, etc.)
- Esforços de Procura (como o número total de entrevistas, número de entrevistas acima do limiar mínimo exigido, percentagem de entrevistas recomendadas realizadas)
- Consistência de Procura (por exemplo, desvio-padrão de dias entre entrevistas e dias entre candidaturas). Note que estas funcionalidades podem ser influenciadas pela escassez de ofertas de emprego, podendo resultar em enviesamentos indesejados no modelo!
Ofertas (Emprego/Formação)
- Nome da Oferta
- Áreas de Oferta (por exemplo, Matemática, Ciência, Programação, …)
- Remuneração da Oferta
- Requisitos
- Turnos Oferecidos
- Localização
Idealmente, representaríamos a lista de ofertas de forma comparável ao domínio da expertise do candidato, de modo que as nossas funcionalidades pudessem representar a similaridade entre a oferta e as competências do candidato. Assim, as áreas de oferta também seriam representadas numa abordagem Content Based.
Se usássemos um modelo que não conseguisse aprender esta relação diretamente (por exemplo, modelos baseados em árvores), poderíamos calcular funcionalidades pairwise, como a diferença entre a remuneração da oferta e as despesas mensais do candidato, ou a intersecção entre as áreas do candidato e da oferta.
Modelação
Depois de ter todas estas funcionalidades, podemos criar um modelo que, dado um snapshot de um candidato num mês e uma oferta de emprego, devolve uma pontuação de empregabilidade. Existem várias formas em que esta pontuação de empregabilidade pode ser modelada, todas as quais podem ser testadas e devem ser escolhidas consoante a forma como o modelo se pretenda aplicar em produção:
- Meses até encontrar um emprego: permite-nos determinar quantos meses o candidato ainda necessitará de receber um subsídio mensal do governo. Portanto, podemos priorizar os casos de acordo com esta predição.
- Número de entrevistas até o candidato ser aceite: Não nos diz nada sobre o intervalo de tempo, uma vez que o candidato pode fazer várias entrevistas num mês ou nenhuma durante vários meses.
- Classificação de risco multiclasse, de Baixo para Alto, dependendo de um limiar (isto é o que foi feito na DSSG Fellowship): não é tão acionável como os anteriores. Contudo, um modelo pode aprender estes padrões mais facilmente, uma vez que o problema é reduzido a uma classificação ordinal.
Vamos assumir, por enquanto, que o modelo nos dá os meses até o candidato encontrar um emprego.
Estimativa Fiável do Desempenho do Modelo
Podemos avaliar o desempenho do modelo usando métricas de regressão como Mean Absolute/Squared Error e os coeficientes de correlação Spearman/Pearson entre o valor alvo e o valor predito.
O tempo é um componente importante no nosso sistema de aprendizagem e, como tal, devemos prestar atenção à forma como dividimos os nossos dados para estimar o desempenho. Divisões aleatórias podem "vazar" informação no treino, fornecendo sobrestimações do desempenho do modelo.
Como estamos a construir um conjunto de dados com várias linhas para o mesmo candidato em meses diferentes, se tivéssemos o mesmo candidato em treino e teste, mas em meses diferentes, saberíamos se encontrou ou não emprego.
Uma abordagem inicial é agrupar as divisões treino/teste por candidato (A está em treino, B está em teste, no exemplo acima).
Contudo, esta abordagem ainda tem o problema de temporal leakage. Imagine que estava a treinar o modelo com dados de outubro de 2020. Sabe, uma vez que uma grande mudança no emprego começou em março de 2020, que o valor médio de "meses até emprego" aumentou, portanto poderia também ter uma sobrestimação do desempenho do modelo em predições de meses anteriores.
Uma possível solução é fazer tanto estratificação temporal como agrupada: por exemplo, treinar com uma lista de candidatos do ano anterior e testar com uma lista de outros candidatos do ano atual. No exemplo acima, poderia treinar com dados de 2019, com uma lista de candidatos não considerando A e B, e testá-lo em 2020, com os candidatos A e B.
Tomada de Decisão
Podemos otimizar os recursos do instituto de emprego calculando o desempenho do modelo para uma lista de ofertas de emprego/formação disponíveis e tendo uma função de custo que nos diga qual é a qualidade dessa oferta para esse candidato. Não vamos discutir extensivamente isto neste artigo.
Imagine, por exemplo, que queremos criar uma campanha de email marketing onde enviamos uma lista de K ofertas para cada candidato. Podemos decidir (no mínimo) dois tipos de ações:
– Melhorar as competências do candidato (por exemplo, cursos).
– Melhorar a exposição do candidato a empregos (por exemplo, entrevistas).
Este é um problema de atribuição com um número enorme de combinações possíveis e restrições de orçamento/tempo.
Duas possíveis funções de custo para este problema são:
- argmax [f(Candidate) – f(Candidate + Offer)], que nos dá o decaimento em meses até o candidato encontrar um emprego, para uma dada oferta. Queremos então encontrar a oferta que maximiza este decaimento.
- argmax [ (f(Candidate) – f(Candidate+Offer)) x UnemploymentAllowance + Costs(Offer) ], que considera custos de processamento relacionados com uma dada oferta e incorpora métricas de negócio, como o dinheiro que seria necessário para manter esse candidato.
Isto pode então ser otimizado eficientemente, por exemplo, com o uso de metaheurísticas, se a lista de opções possíveis for muito grande.
Existem algumas preocupações éticas com tais funções de custo:
- Estamos a minimizar o tempo médio para emprego em detrimento de oferecer empregos com salários mais baixos?
- A otimização disto deixará algumas pessoas numa "escassez" de ofertas de emprego apenas porque é mais difícil encontrar boas ofertas para eles?
Para considerar isto, podemos incluir alguns fatores extra na função de perda para isto, como uma busca multi-objetivo: considerando restrições de tempo para encontrar empregos para todos e, ao mesmo tempo, reduzindo o tempo médio que as pessoas passam sem um emprego.
Conclusão
Este artigo foi escrito após uma discussão interna onde discutimos este tema. Obviamente, cobre apenas uma pequena fração do que poderia ser feito com este tema. Se está interessado em ter tais discussões para um problema empresarial específico que tem, certifique-se de que nos contacta!
