BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos De volta para o futuro: desmistificando o viés cognitivo

De volta para o futuro: desmistificando o viés cognitivo

Pontos Principais

  • O viés nos dados criou um gargalo na IA corporativa que não pode ser resolvido por meio da otimização excessiva de algoritmos de aprendizado de máquina ou pela invenção de novos algoritmos;
  • O viés cognitivo é a presença acidental de informações nos dados de treinamento que nunca estarão legitimamente disponíveis em produção. Em termos leigos, é como o Marty McFly (em De volta para o futuro) viajando para o futuro, colocando as mãos no Almanaque Esportivo e usando-o para apostar nos jogos do presente;
  • Não há bala de prata que resolva isso. Uma combinação de métodos estatísticos e recursos de engenharia podem ajudar a detectar e corrigir este efeito;
  • Recursos que exibem esse viés precisam ser diferenciados dos preditores verdadeiros e com isto, determinar o limite correto é a chave fundamental;
  • No Salesforce Einstein, a conscientização sobre esse viés com nossos clientes foi o primeiro obstáculo, antes que pudéssemos resolvê-lo.

Era uma vez, um executivo que acompanhava os leads de vendas informando os dados mínimos necessários para inserir um registro de lead. A entrada de dados é uma dor, todos sabemos disso! Enquanto ele trabalhava no processo de conversão dos leads, alguns deles se transformavam em compras. No momento da conversão, ele preenchia informações adicionais apenas para aqueles que tinham o resultado positivo de conversão em compras. Se treinar seu algoritmo de aprendizado de máquina com anos de tais dados rotulados, ele correlacionará esses recursos com um rótulo positivo, embora eles nunca estivessem realmente disponíveis antes da conversão. O processo de negócios criou um viés nos dados desde o início.

Essa história se repete em diferentes casos de uso, usuários e dados corporativos. Algoritmos de aprendizado de máquina frequentemente assumem que um mítico "conjunto de dados perfeito" é alimentado para prever a rotulação desejada. Na realidade, muitas vezes há muito ruído nos dados. O calcanhar de Aquiles neste domínio é o Hindsight Bias (também conhecido como label leakage ou data leakage). É a presença acidental de informações nos dados utilizados para treinamento que nunca estarão legitimamente disponíveis em um ambiente de produção, causando resultados irreais no ambiente de pesquisa, levando a resultados ruins no ambiente de produção.

Albert Einstein certa vez descreveu o seguinte cenário:

Se tivesse uma hora para resolver um problema, dispensaria 55 minutos pensando no problema e 5 minutos pensando em soluções.

Então, vamos nos aprofundar neste problema um pouco mais, com um exemplo:

Desmistificando o viés cognitivo utilizando o Titanic

Na comunidade de aprendizado de máquina, a previsão de sobrevivência do Titanic é bem conhecida. A falta de salva-vidas suficientes foi responsável por muitas vidas perdidas após o naufrágio. Grupos específicos de passageiros, como mulheres, crianças e a classe alta, tinham maior probabilidade de sobreviver do que outros. O aprendizado de máquina é usado para identificar esses sinais e prever quais passageiros sobreviveriam à tragédia.

O que muitos não sabem é que os dados utilizados no desafio de Kaggle trata-se da versão filtrada e limpa. Os dados originais possuíam recursos adicionais, dois dos quais eram particularmente problemáticos: os campos Boat e Body. No rescaldo do naufrágio, era atribuído aos passageiros um número de barco, caso chegassem em segurança a um barco salva-vidas, ou um número de corpo, caso fossem eventualmente encontrados mortos. Bem, claro! Se houver um número de corpo, o passageiro está morto. Você não precisa de um algoritmo sofisticado de aprendizado de máquina para lhe dizer isso.

Ao utilizar o conjunto de dados original, as informações sobre o rótulo desejado foram inseridas nos dados de treinamento. Barco e corpo só são conhecidos no futuro após o evento já ter ocorrido. Eles não são conhecidos no presente ao fazer a previsão. Se treinarmos o modelo com esses dados, ele terá um desempenho ruim no presente, já que essa informação não estaria legitimamente disponível.

Este problema é conhecido formalmente como viés cognitivo. E ocorre predominante em dados do mundo real, que testemunhamos em primeira mão ao criar aplicações preditivas no Salesforce Einstein. Aqui está um exemplo real no contexto da previsão da conversão do lead de vendas: os dados tinham um campo chamado deal value, que era preenchido intermitentemente quando um lead era convertido ou estava próximo de ser convertido (semelhante aos campos Boat e Body na história do Titanic).

Em termos leigos, é como o Marty McFly (em De volta para o futuro) viajando para o futuro, colocando as mãos no Almanaque Esportivo e usando-o para apostar nos jogos do presente. Como a viagem no tempo ainda está a alguns anos, o viés Cognitivo é um problema sério hoje em dia.

O viés cognitivo versus a modelagem de algoritmo

Algoritmos de Aprendizado de Máquina ocupam o centro do palco hoje em aplicações de inteligência artificial. Há uma corrida para ganhar uma fração de uma melhoria percentual na precisão do modelo, otimizando os algoritmos de modelagem ou inventando novos. Embora isso seja útil, é possível obter um retorno maior para o investimento, focando onde o gargalo é o aprendizado de máquina aplicado, especificamente com dados corporativos. O viés cognitivo é uma dessas áreas, em sua maioria inexplorada. Então, como podemos resolver esse problema?

Estratégias para mitigação

1. Análise estatística para recursos de entrada

Há um conjunto de testes estatísticos que podemos executar nos recursos de entrada para detectar uma forte associação dos recursos ao rótulo desejado. A Correlação de Pearson fornece uma medida numérica no intervalo (-1,1) entre o recurso e o rótulo, que expressa a intensidade da associação entre o recurso e o rótulo, bem como a direção. Embora funcione muito bem para recursos numéricos, ele também pode funcionar para recursos categóricos assim que forem vetorizados. No entanto, se os categóricos tiverem um grande número de valores exclusivos (por exemplo, cidades no mundo), a correlação perderá a associação com rótulos devido à diluição do recurso em várias colunas durante a vetorização. Isso pode ser resolvido utilizando CramersV e, portanto, é um teste estatístico mais preferido para recursos categóricos.

O impacto de tais características tendenciosas pode ser mais complicado quando afeta uma pequena fração dos exemplos. Imagine dados geográficos globais. A parte das linhas em que City = San Francisco pode ser uma em mil. O Lift é uma medida alternativa que captura essa dispersão do Viés Cognitivo.

2. Análise estatística para recursos derivados

Uma estratégia que se mostrou útil é executar alguma engenharia preliminar de recursos antes de executar testes estatísticos nos recursos de entrada.

Por exemplo, muitas características categóricas com viés cognitivo seguem o padrão de ser nulo, até que o rótulo desejado seja determinado. Eles tendem a ter algum valor preenchido, próximo ao quanto o rótulo é especificado. Os campos boat e body, por exemplo, dos dados do Titanic são exemplos desse padrão. A maneira de eliminá-los é adicionar um recurso derivado do indicador nulo (isNull) e usar o CramersV como um teste estatístico.

A correlação nem sempre captura recursos numéricos com viés cognitivo. Por exemplo, no contexto de prever se em uma oportunidade de vendas haverá ganho ou perda, havia um recurso chamado receita esperada. O sistema preencheu o valor depois que o vendedor fechou a oportunidade. Quando o vendedor perdeu a oportunidade, o sistema calculou a receita esperada como 0 ou 1. Caso contrário, o sistema a calculou como um número grande. Uma árvore de decisão pode ser usada para descobrir as duas faixas: [0,1] e [2, infinito]. Depois de colocar um recurso numérico, é possível tratá-lo como um recurso categórico. Um teste estatístico como o CramersV pode então revelar a forte associação entre o bin específico e o rótulo, expondo assim o viés.

O outro padrão digno de nota que observamos: características categóricas disfarçadas de texto. Por exemplo, ao prever se em um acordo haverá perda ou ganho, havia um recurso chamado Lost no palco. Claramente, fortemente tendencioso, foi definido como um recurso de texto, mas com apenas três valores possíveis. Uma checagem de cardinalidade em tais recursos, convertendo-os em categóricos e, em seguida, aplicando os testes estatísticos de CramersV pode revelar um viés cognitivo.

3. Treinamento versus score de distribuição

Algumas vezes, o viés cognitivo mais indescritível pode não ser exposto às técnicas apresentadas anteriormente apenas olhando para os dados de treinamento. Uma das principais suposições por trás do treinamento de um algoritmo de aprendizado de máquina é que os dados usados para treinamento são semelhantes aos dados utilizados para score.

Como os recursos com viés retrospectivo contêm informações sobre o rótulo no momento ou logo antes de o rótulo real ser determinado, podemos observar a distribuição dos recursos nos dados de treinamento e os dados de score (antes de conhecer o rótulo real). Se alguma das características apresentar uma lacuna estatisticamente significativa nas duas distribuições, isso é um candidato a viés cognitivo.

Temporal or timestamp cutoff is a related technique. Here, we determine a cutoff timestamp as the moment in time when the prediction event is supposed to occur, based on current and past records. We then exclude all data before the event of interest, so we are not using any data that we collected close to the prediction or after, i.e., in the future.

4. Validação cruzada e a preparação de dados

É crucial executar toda preparação de dados e engenharia de recursos em cada validação cruzada. Por exemplo, se usarmos as informações do rótulo em qualquer etapa de engenharia de recursos, como a categorização, introduzimos inerentemente o viés cognitivo nos dados. O mesmo se aplica aos métodos de seleção de recursos, remoção de outliers, codificação e dimensionamento de recursos para redução de dimensionalidade. Se executarmos qualquer um deles nos dados inteiros antes da validação cruzada, então os dados de teste em cada dobra do procedimento de validação cruzada desempenharam um papel na escolha dos recursos, e isso introduz um viés cognitivo nos dados.

Isto é um viés cognitivo ou uma predição verdadeira?

Em todos os métodos discutidos até agora, o aspecto mais difícil é descobrir o limite certo para os seus dados e caso de uso, o que ajudaria a revelar um viés cognitivo. Qual deve ser a medida de correlação, além da qual um recurso é considerado como tendencioso? 0,9 é um bom limiar ou deveria ser 0,75? Em que ponto um recurso é tendencioso versus realmente um verdadeiro preditor? É preciso tomar a mesma decisão em todas as outras medidas estatísticas, incluindo a diferença na distribuição de treinamento e pontuação e assim por diante.

No Salesforce Einstein, nossa experiência na criação de modelos para uma ampla variedade de casos de uso e dados de diferentes formas e tamanhos ajuda a informar limites aceitáveis. No entanto, está longe de ser cravado na pedra. Estamos continuamente fazendo iterações nos limites para refletir os dados e problemas do mundo real.

Conclusão

O viés cognitivo na IA corporativa é um problema mais prevalente quando comparada à IA na academia ou para um consumidor. O desafio mais significativo que enfrentamos foi a conscientização com nossos clientes. Depois que passamos por isso, entender os processos de negócios e os padrões de dados que introduzem esse viés foi crucial. Essa jornada nos ajudou a desenvolver soluções que automatizam a detecção do viés cognitivo. O resultado que encontramos foram previsões de aprendizado de máquina mais confiáveis.

Sobre o autor

Mayukh Bhaowal é diretor de gerenciamento de produtos no Salesforce Einstein, trabalhando em aprendizado automatizado de máquina e com experiência em ciência de dados. Mayukh recebeu seu mestrado em Ciência da Computação pela Universidade de Stanford. Antes da Salesforce, Mayukh trabalhou em startups no domínio de aprendizado de máquina e análise. Ele atuou como Head of Product de uma startup de plataforma ML, a Scaled Inference, apoiada pela Khosla Ventures, e liderou o produto em uma startup de comércio eletrônico, a Narvar, apoiada pela Accel. Ele também foi gerente de produto no Yahoo e Oracle.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT