Tecnologia. Inteligente.

Há um tempo atrás, escrevi aqui no Tecnologia Inteligente um artigo onde eu criticava algumas esperanças meio irreais sobre o que se pode fazer com bases de dados (ou datasets, o anglicismo que efetivamente usamos o tempo todo no nosso trabalho imensamente grandes. Já neste artigo, pretendo analisar um problema que de certa forma é oposto - o das bases de dados pequenas demais.

Sim! Por incrível que pareça, em uma era onde se fala em “dilúvio de dados” em quase todos os campos da Ciência e terabytes rapidamente caminham para a trivialidade, ainda assim às vezes, em certos casos específicos, a quantidade de dados disponível é muito menor do que poderia ser considerado satisfatório. 

De fato, tive inspiração para escrever este artigo porque nas últimas semanas estava lidando com um dataset biológico muito pequeno, com dados caracterizando apenas seis amostras. Ah, sim, aqui é importante frisar que era um dataset pequeno em número de amostras, mas cada amostra era caracterizada pelos valores de expressão de dezenas de milhares de genes, totalizando um tamanho de uns dois megas.

O que, a propósito, há muito parece um tamanho ridículo em nossa era onde facilmente temos arquivos de vários gigas, mas de qualquer modo já é um tamanho humanamente intratável e que exige análises computadorizadas.

Outro comentário pertinente é relacionado com o fato de que muitos podem achar estranho um dataset biológico ser pequeno, já que a fama é de serem enormes. Bom, o caso é que muitas vezes, para certos problemas, coletar dados de um grande número de amostras pode ser difícil, ou caro, ou ambos. Pense em indivíduos com condições médicas raras, ou então em exames médicos que são caríssimos, e vai ser fácil juntar os pontos para ver como aparecem com razoável freqüencia datasets biológicos minúsculos.

Bom, qualquer que seja o motivo da escassez de amostras, como lidar com esses números reduzidos em um estudo de aprendizagem supervisionada? Eu tenho a seguinte receita de bolo de três passos:

Validação leave-one-out

Depois que são treinados com (duh! dados de treino, classificadores são validados com dados de teste que eles nunca “viram”, os famosos out-of-sample.  Dado um conjunto inicial de amostras, existem diversas formas de “produzir” conjuntos de teste e treinamento.

A mais simples delas é simplesmente escolher aleatoriamente uma fração (digamos, 2/3) das amostras para treinamento, e usar o restante para teste.

Uma segunda forma mais sofisticada e confiável, que torna mais improvável a seleção de conjuntos de treino e teste irrealmente favoráveis, é a chamada cross-validation.

Nesta política de validação, o dataset inicial é dividido em n subconjuntos com mais ou menos o mesmo número de amostras, e correspondentemente são feitos n pares de treino e teste: no primeiro par o subconjunto 1 é usado para teste e o restante para treinamento; no segundo par o subconjunto 2 é usado para teste e o restante para treinamento; e assim por diante.

Pois bem, no caso de datasets com pouquíssimas amostras, o ideal é usar o leave-one-out (”deixe um de fora“, numa tradução literal que funciona), que é o caso especial de cross-validation onde n é igual ao número de amostras da base - isto é, a cada par só uma amostra é usada como teste e todas as outras para treinamento.

Esse tipo de validação minimiza ao extremo a probabilidade de formação de pares “privilegiados” de treino e teste, a qual já não é tão pequena assim em datasets minúsculos.

Análise de Permutação:

Vamos supor que você foi cuidadoso na fase anterior de validação, usando leave-one-out, e descobriu que seus classificadores têm um desempenho maravilhoso nos dados, com altas acurácias tanto nos conjuntos de treino quanto de teste.

Mas, se você for realmente rigoroso (alguns diriam paranóico, mas a paranóia quase chega a ser uma virtude na Ciência :), deverá considerar a possibilidade de que talvez seus resultados sejam tão bons porque o número de amostras é pequeno e é fácil para o seu algoritmo decorar algumas propriedades numéricas dos dados que *por coincidência* podem ser usadas para distinguir corretamente as categorias (digamos que casos de controles), mas não necessariamente são relacionados com o problema real que está sendo estudado.

A solução para verificar essa terrível possibilidade é fazer a assim-chamada análise de permutação. Esta é um “embaralhamento”: consiste em trocar aleatoriamente os rótulos de categoria entre as amostras. Gerando muitas permutações diferentes e vendo que as acurácias dos testes feitos com dados “embaralhados” são menores que o resultado obtido com os dados reais, pode-se inferir que as acurácias excelentes devem ser também “reais”, correspondendo a padrões relevantes para o problema investigado.

Nota: aqui estou falando em acurácia - que talvez seja a métrica de qualidade de classificação mais comum, óbvia e intuitiva - mas existem outras métricas, e o que estou dizendo aqui usando acurácia também vale para elas.

Comportamento com métodos não-determinísticos:

Às vezes, nem a análise de permutação pode ser suficiente. Se o dataset for muito pequeno mesmo, o número total de permutações pode ser tão modesto que não permite calcular um alto valor de significância estatística.

No dataset de apenas seis amostras que mencionei, o número de embaralhamentos utilizáveis era de apenas 18. Quando se nota que tradicionalmente o limiar de significância interessantemente para os biólogos é de 0.05, ou uma chance em 20 dos seus resultados serem “falsos”, 18 permutações parecem problemáticas para decidir se seus resultados passam nesse limiar. Como então contornar essa forma extrema do problema dos datasets pequenos?

Uma opção interessante pode ser usar um método de classificação não-determinístico (por exemplo GA, GP, vários modelos de redes neuronais, etc) e realizar vários testes de classificação sobre os seus dados reais e sobre os dados permutados.

Um método não-determinístico não necessariamente produz o mesmo classificador com os mesmos dados de entrada, e assim no final essa etapa de validação terá gerado um monte de classificadores diferentes - uns melhores, uns piores que os outros. Interessantemente, agora é possível se falar em comparação de distribuições de acurácias, e não de um dado pontual de acurácia nos dados reais versus um pequeno conjunto de acurácias “embaralhadas”.

Essas distribuições podem ser tão grandes quanto se queira - basta gerar mais classificadores de forma não-determinística - e quanto maior o número de pontos amostrais envolvidos, mais estatisticamente significativa será qualquer discrepância entre as distribuições com e sem embaralhamento.

Moral da história

Enfim, o ideal mesmo em vários processos científicos é trabalhar com números grandes de amostras, mas se as vicissitudes da vida um dia obrigarem você a lidar com datasets minúsculos, não se desespere! Com os macetes descritos há uma boa chance de você espremer (admitidamente de forma um tanto lenta e dolorosa)  alguns padrões confiáveis apesar de tudo; ou na pior das hipóteses demonstrar confiavelmente que seu dataset não presta mesmo.

Está rolando em San Francisco a TechCrunch 50, uma grande conferência onde startups se apresentam para a imprensa, investidores, empreendedores e outros formadores de opinião do Vale do Silício. É provavelmente o maior evento dedicado ao lançamento de novos produtos, sites e empresas inovadoras do mundo. As empresas selecionadas (52 de um total de mais de 1000 inscrições) têm que manter seus produtos em segredo até a conferência.

Como a conferência já começou, podemos anunciar que um dos produtos lançados foi desenvolvido todinho aqui no Labs, e está em beta atualmente. O StockMood.com é uma ferramenta para auxílio a pequenos investidores na bolsa dos EUA. O sistema usa processamento de linguagem natural e inteligência artificial para determinar o “tom” (positivo ou negativo) de artigos que saem na imprensa sobre uma empresa.

Correlacionando o tom dos artigos com o movimento do preço da ação ao longo do tempo, ele tenta quantificar o “humor” da ação, e gera alertas quando o humor e o tom dos artigos do dia chegam a valores muito altos ou muito baixos. Esses alertas indicam uma possível reversão dos preços. O sistema de classificação do tom de artigos está longe de ser perfeito, mas os usuários podem corrigir os erros do sistema pelo site, gerando alertas melhores e permitindo que o próprio classificador aprenda com os erros.

A foto acima (by Andrew Mager) é do Brett, CEO da nova startup, durante a apresentação. A recepção ao StockMood.com foi geralmente bem positiva, como nesse artigo da Fortune. embora o modelo de negócios da empresa ainda esteja sendo refinado. O beta será limitado, por enquanto, a 1000 usuários cadastrados, então se você achou a idéia interessante e não tem medo do inglês, cadastre-se!

E, finalmente, parabéns a toda a equipe do StockMood.com, especialmente ao Fabrício Aguiar e ao Gustavo Gama, que vocês conhecem um pouco de posts aqui no blog.

A declaração recente da Marissa Mayer, “Vice President of Search Product and User Experience at Google”, de que o Google já resolveu 90% do problema de busca, mas que os 10% ainda vão dar um bom trabalho, incomodou muita gente na webosfera.

Prá quem não conhece a moça, Marissa é certamente uma das executivas mais importantes da indústria atualmente, e talvez um dos pontos máximos que um profissional de usabilidade almejaria hoje em dia.

O que há por trás dessa declaração? Bem, podemos desfilar vários aspectos interessantes aqui.

Uma delas é que frequentemente, no desenvolvimento de software, fala-se sempre da regra do 80/20 ou a Regra de Pareto, que originalmente falava que 80% das consequências vinham de 20% das causas. Mas claro que a proporção foi ganhando outros usos, como “80% do desenvolvimento leva 20% do tempo e os 20% restantes levam os outros 80% do tempo”.

Em bom e claro Português, “o diabo vive nos detalhes”

De fato, muito da busca na web chegou a um nível de refinamento e desempenho formidáveis, mas o que significa dizer que 80% ou 90% do problema já está resolvido? E é neste pé que os críticos da web resolveram pegar para criticar o argumento da Marissa.

Segundo a techcrunch por exemplo, o que resta das coisas a serem indexadas e buscadas ainda é muito grande. Ainda não temos resultados satisfatórios GENÉRICOS para buscas semânticas, buscas em imagens, buscas em filmes, e muitos et ceteras.

Podemos dizer, certamente, que existe um grande potencial em buscas de imagens, por exemplo, em contextos restritos, e este é um mercado que deve crescer rapida e intensamente nos próximos anos. Mas se você quer buscar pela foto do gato com o cachorro, a menos que vc tenha intervenções humanas de forma inteligente, não se resolveu ainda o problema computacional de definir o que é exatamente um cachorro. Mas se você souber formatos de armas, talvez consiga localizar, com algum bom grau de precisão, armas num recinto por exemplo.

E aí podemos estender para as buscas em linguagem natural e etc, e a conclusão é: ainda tem muito terreno a ser caminhado neste aspecto, e isso significa, em termos de inovação, que há muito o que explorar ainda nesta área. Será que 10% é achar uma agulha numa cena de 1 segundo no youtube?

Enquanto isso, silenciosamente, coisas acontecem no Yahoo.

Ninguém do porte desta moça dá declarações impensadas. Stay tuned.

Update 11/9: 2 dias depois, Marissa escreveu uma declaração, voltando atrás, e concordando basicamente com a opinião das pessoas (eu entre elas) que acham que ainda falta muito chão, inclusive citando nosso bom e velho Pareto

Interessante esta iniciativa do The Washington Post de se aliar ao Predictify e criar um mecanismo onde as pessoas podem ler notícias e dar seus palpites futurísticos. E além das pessoas poderem palpitar, as que acertarem mais podem ser premiadas também. Em dinheiro. Bandeira levantada pelo site Techcrunch.

Por um lado, podemos até pensar que hajam pessoas com informação e capacidade analítica suficientes para fazer boas previsões de muitas coisas. Há inclusive sites de apostas que apostam sobre praticamente qualquer coisa, desde resultados de jogos até oscilações de humor da bolsa. Tentar prever o futuro é um jogo e tanto.

Mas o grande jogo aqui certamente não é prever o futuro, mas envolver os leitores do jornal. Web 2.0 na veia. Afinal, predições também são uma forma de emitir opinião.

Interessante que a ciência também está sempre atrás de predições. Lembrei de um livro que eu comprei mas que, uh… eu não gostei, chamado Chance Discovery, onde o Yukio Ohsawa explica sua teoria que busca basicamente insights nos dados que não se “encaixam” no padrão, com aplicações que vão desde a predição de terremotos (afinal, é um autor japonês, e terremotos são uma coisa séria por lá), oscilações na bolsa, até prospecção de novas oportunidades de negócios, criação de novos produtos, e muitos et ceteras. Isso tudo, claro, incluindo o elemento humano na análise, como fator fundamental na produção do insight.

Apesar de não ter gostado do livro, ainda assim há análises na web que conseguem extrair uma discussão interessante, como este post que mantém um pé atrás no ceticismo, comparando o autor ao Genichi Taguchi, cujo trabalho influenciou por exemplo o Six Sigma, da famigerada Qualidade Total, e ressaltando a importância do fator subjetivo na análise.

Há um mês atrás eu postei sobre o WikiProteins, que é um Wiki biológico destinado à anotação de proteínas.

Mais recentemente, no início desse mês, a PloS Biology publicou um artigo sobre o Wiki Genes. O Wiki Genes é algo bastante parecido como o WikiProteins, mas voltado para prover informação sobre genes. E é voltado para ser implementado na própria WikiPedia!

A idéia dos caras foi a de colocar uma entrada na WikiPedia pra cada gene humano (e ainda pra alguns organismos modelo como o camundongo). A premissa foi a de que editores de Wikis preferem editar entradas já existentes do que criar novas. Dessa forma, a geração desses stubs (entradas no Wiki com pequenas coleções de informações) deverá alavancar a edição de genes humanos na WikiPedia.

O que eles fizeram foi parsear as entradas de todos os genes presentes no Entrez Gene e gerar cerca de 7500 stubs. Melhor do que as meras 650 entradas que existiam anteriormente. Aparentemente o resto das entradas ainda está sendo gerado - o Entrez Gene contém informação de 39950 genes humanos - não que esse seja o número total de genes humanos, mas essa é outra história.

O parser, que foi feito em Java, produz um stub diretamente em “wiki-text” e o código-fonte está disponível.

Também na PLoS saiu bem recentemente um outro artigo sobre um Wiki na área de biologia, dessa vez o Wiki Pathways. Os pathways, na biologia, são uma representação de uma miríade de interações, reações e regulações, seja entre genes, proteínas ou compostos biológicos. Por serem extremamente complexos e difíceis de curar e compilar, a estratégia foi também a de gerar um Wiki.

Aparentemente, com essa enxurrada de dados biológicos sendo gerados à todo vapor (vide as “ômicas” da vida – genômicas, proteômicas,metabolômicas, etc.), a corrente agora é para a integração desses dados, em ferramentas que permitem updates rápidos e fáceis.

E pelo visto, esses novos Wikis são o tipo de ferramenta que vêm a calhar nesse momento, pois tornam os dados acessíveis e editáveis aos curadores especialistas bem como para a comunidade em geral.

Vamos ver se a moda pega.

Recentemente, um artigo na Wired, escrito pelo seu próprio editor, o Chris Anderson, fez uma declaração bombástica: a de que o método científico está obsoleto porque os “algoritmos do Google” podem achar correlação de qualquer coisa com qualquer coisa. Ok, quem ler o artigo vai ver que eu estou supersimplificando e comprimindo tudo em uma frase, mas eu não diria que a versão descomprimida e complicada soa menos bombástica ou mais aceitável. Pelo contrário!

Nem bem uma semana passou após a emissão dessa opinião, uh, digamos, polêmica, e vários artigos pipocaram pela Internet dizendo basicamente duas coisas: que o método científico continua muito bem, obrigado, e que o autor provavelmente não tem uma noção conceitual muito clara do que é Ciência. Um exemplo particularmente bem-humorado desse contra-ataque é o artigo do Daily Galaxy. Não vou chover muito no molhado e só vou ressaltar um argumento bem interessante que vi por aí para desconstruir essa alegada “obsolescência do método científico”:

Primeiro, vamos desconsiderar as limitações do Google e outros search engines - sim, apesar de impressionantes, eles são ferramentas de domínio e capacidade limitados, feitas especificamente para produzir resultados de buscas de páginas Web (e outros tipos de documentos online) que satisfaçam a maioria das pessoas. Mas vamos supor que em um futuro não muito distante o Google se torne (como quer o editor da Wired) uma espécie de oráculo que saiba tudo de qualquer coisa e que em teoria substitui a Ciência. Vamos supor que alguém pergunte ao oráculo algo como “quero a cura da gripe” e o Google magicamente, usando só correlação de dados, mostre a fórmula da tal droga que cura gripe. Agora, uma pergunta para o leitor: você tomaria essa droga sabendo que ela é apenas o que algoritmos estatísticos “acham” que deve ser uma solução, sendo que ela nunca foi testada sequer em cobaias? Se a sua resposta é “não”, é um sinal de que você considera o método científico, e toda a parte de validação experimental, necessários sim.

Acho que o artigo irrealisticamente entusiástico da Wired é só um indício de uma manifestação recente do que chamo de “Sindrome da Panacéia Universal”. É uma síndrome recorrente, com inúmeras encarnações ao longo da história da Ciência e da Tecnologia, que basicamente são produzidas toda vez que algum recurso inovador e revolucionário se populariza. Essa síndrome aliás pode se materializar em vários níveis e em vários contextos, muitas vezes bem específicos. Por exemplo, no contexto da pesquisa de IA do início dos Anos 90 aqui no Brasil, redes neurais estavam muito na moda e havia um “hype” de que elas poderiam solucionar todos os problemas da aprendizagem de máquina. Também ao longo dos 90, nos campos de engenharia de software e linguagens de programação, havia um hype em torno da Orientação por Objetos, que também era “vendida” por muitos como a solução para todos os problemas do desenvolvimento, engenharia e arquitetura de software. E assim cada época vai adorando suas “balas de prata” até que as pessoas caem na real. (Ou então surja uma nova moda de bala de prata para substituir a anterior.

O hype de panacéia universal que a Wired caiu vítima, porém, além de mais recente é de um nível mais abrangente. Eu o chamo de a Panacéia do Dilúvio de Dados. Porque hoje em dia a capacidade de armazenamento de dados sobe às alturas, armazena-se dados sobre qualquer coisa, os dados são acessíveis de qualquer lugar e, o que talvez seja o ponto crucial, pode-se fazer buscas nesses dados, começa-se a criar no imaginário popular (ou quem sabe seja só no, como diria o Kenji, “imaginário computeiro” a noção de que a resposta para todas as perguntas e a solução para todos os problemas está nessa massa gigantesca de dados online, é só saber minerá-los direito; ela teria se tornado o próprio Logos, o Conhecimento Definitivo.

O meu reality check para isso é primeiro reconhecer que massas gigantescas de dados são sim coisas fascinantes e muito úteis - sei muito bem disso, uma boa parte do meu trabalho nos projetos do Vetta Labs com a Biomind envolve a análise de bases de dados biológicas com nossas ferramentas de aprendizagem de máquina. Mas, uma vez feito esse reconhecimento, também tenho de reconhecer que, em última instância, os resultados da nossa mastigação de dados servem é para sugerir ao biólogo o que eles devem investigar (e às vezes como a investigação deve ser feita) com seus experimentos; não serve de forma alguma para eliminar esses experimentos, mas antes para guiá-los, dar prioridades e mesmo levar à geração de novas hipóteses. De fato, esses métodos de mineração de dados não vieram para depor o Método Científico, mas antes para ajudar a Ciência, como uma nova (e extremamente poderosa) ferramenta analítica. E sinto que essa conclusão que tirei da minha experiência profissional e acadêmica com Bioinformática é generalizável sem problemas para todas áreas da ciência e da tecnologia. Assim, parece que as notícias do assassinato do Método Científico pela Panacéia do Dilúvio de Dados foram grandemente exageradas…

Depois dos 2 excelentes posts do Lúcio sobre Machine Learning (ML), você pode estar se perguntando: mas como utilizo tudo isso na prática? Neste post irei apresentar (sem detalhes para não ficar chato) uma ferramenta bastante difundida e utilizada no mundo na área de ML: o Weka (Waikato Environment for Knowledge Analysis).

Weka é um pacote de código aberto (com licença GNU General Public License) composto de algoritmos de ML implementados em Java. Seu desenvolvimento foi iniciado em 1993 e ficou nas mãos de uma equipe da Universidade de Waikato na Nova Zelândia durante aproximadamente 13 anos. Em 2006, o projeto foi incorporado ao conjunto de soluções de uma empresa de BI chamada Pentaho.

A versão mais recente conta com diversos algoritmos de ML implementados, incluindo algoritmos de clustering, classificação, regras de associação e regressão. Além dos algoritmos, também conta com uma gama de implementações relacionadas com pré-processamento dos dados, filtros e interfaces para visualização. Para entrada de dados, o Weka permite os formatos ARFF (formato desenvolvido especificamente para o Weka), CSV e leitura diretamente do banco de dados via JDBC. Além da possibilidade de utilizar o Weka incluído no seu código Java, também é possível utilizar uma ferramenta gráfica chamada de Explorer para entrada de dados e execução dos algoritmos. Pelo Explorer, você pode ter uma visão gráfica dos seus dados de entrada, executar facilmente diferentes filtros e algoritmos e realizar avaliações dos modelos. Porém, ao lidar com quantidades muito grandes de dados (o que geralmente é o caso na utilização de ML) e também para automatizar o processo, é melhor utilizar o Weka diretamente no seu código.

O código do projeto é muito bem estruturado e escrito, adotando as melhores práticas e padrões de desenvolvimento orientado por objetos. Em um projeto desenvolvido aqui no Labs, tive que modificar o código de um filtro para adaptá-lo aos nossos requisitos. E essa tarefa não foi um bicho de sete cabeças, mesmo sendo um código totalmente desconhecido a princípio.

Pra finalizar, gostaria de deixar uma dica de um excelente livro para os interessados no assunto, tanto de Machine Learning e Data Mining em geral quanto do Weka. O livro é Data Mining: Practical Machine Learning Tools and Techniques.

Volta e meia surge algum artigo aqui no blog falando de aplicações de inteligência artificial e frequentemente usando termos que podem soar meio misteriosos para muitos, como o críptico “aprendizagem de máquina”, às vezes também usado em sua forma original em Inglês, “machine learning”. Penso que talvez esse termo pode ainda evocar na cabeça de muitos uma imagem de coisa scifi incompreensível, então decidi escrever este artigo (em dois “capítulos”) sobre o beabá da aprendizagem de máquina para mostrar que, uma vez explicado, o tal Machine Learning (ou ML) pode até parecer meio prosaico…

A definição vaga e por alto (e não sei se existe uma definição exata e profunda, a propósito de ML como um todo é: um método ou algoritmo para descobrir de forma automatizada padrões em uma massa de dados. Acho que essa definição não diz muito coisa sem exemplos, então vamos dar alguns nomes a alguns bois.

Vamos supor que você tenha um banco de dados com características de várias pessoas. As características podem ser qualquer coisa (digamos, peso, altura, idade, etc), desde que possam ser comparadas de forma quantitativa ou lógica. Esse conjunto de valores de características descrevendo cada pessoa é chamado vetor de características, em jargão de ML.

Já que o valor da altura de uma pessoa é comparável com o valor da altura de outra, o mesmo acontecendo com peso, idade e demais dimensões (=outro jargão de ML - bem, na verdade de ciências exatas em geral, nesse caso do vetor de características, então acaba que dois vetores inteiros podem ser comparados um com o outro, levando em conta todas as suas dimensões ao mesmo tempo. É possível criar o que chamamos de medida de similaridade, que é simplesmente uma conta envolvendo todas as dimensões de dois vetores que no final solta um número - quanto mais alto esse valor, mais similares são esses vetores.

De posse dessa medida, já é possivel fazer coisas divertidas em ML - por exemplo juntar as pessoas parecidas umas com as outras, dividindo o conjunto original em vários subconjuntos de pessoas parecidas. Esse tipo de processo é o chamado clustering - ou aglomeração, traduzindo - e é a base da vertente de ML chamada de aprendizado não-supervisionado.

A parte do “aprendizado” nesse nome vem do fato de que antes os elementos do conjunto de dados sendo analisado eram completamente amorfos, não-estruturados, “farinha do mesmo saco” por assim dizer; após o clustering, porém, temos grupos separados nos quais veremos padrões. No exemplo do clustering de pessoas, talvez se forme um aglomerado de pessoas baixas e gordas, outro de pessoas altas, um de pessoas velhas de peso médio, e por aí vai.

Já a parte do “não supervisionado” vem do fato de que não é preciso dizer ao algoritmo de clustering sendo usado (existe uma infinidade deles) se os resultados que ele está produzindo são bons ou ruins, ele mesmo toma suas próprias “decisões” de como fazer melhor a aglomeração. Aliás, é difícil dizer quantitativamente e de forma geral, irrestrita, se um clustering é bom ou ruim, no sentido de que é algo um tanto subjetivo - existe uma multiplicidade de métricas de qualidade de clustering, com aplicações apropriadas caindo em vários casos diferentes.

Existe também, é claro, a aprendizagem supervisionada, o outro grande campo da Aprendizagem de Máquina. Mas isso é assunto para a Parte 2 deste artigo…

Um dos causos mais famosos e mais mal-interpretados da história do Data Mining é a famosa correlação entre cervejas e fraldas.

Existe a lenda de uma loja que descobriu que homens que compravam fraldas entre 5 e 7 da tarde das Quintas e Sábados, também compravam cerveja. Os donos então puseram fraldas perto das cervejas e as vendas subiram. Um monte de hipóteses surgiram, desde o cara que ia trocar a fralda alcoolizado (má idéia) até a auto-recompensa, etc.

Bem, a história não é bem assim. Na verdade, ela parece ser BEM DIFERENTE disto.

Um lugar onde há muitos dados é no supermercado. No esforço de entender melhor o comportamento do consumidor, especialmente a partir do início da década de 90, começou-se a estudar o chamado Market Basket (Cesta de compras), que nada mais é que a lista de produtos que o cliente levou numa compra.

Tentar encontrar padrões, computacionalmente, nestes dados, muitas vezes se dá na forma de regras de associação. A forma mais comum de expressar uma regra destas é “SE [CONDIÇÃO] ENTÃO [CONCLUSÃO]“. Por exemplo: SE leite E açúcar ENTÃO café (muita gente que compra leite e açúcar compra também café).

Algoritmos automáticos para obter estas regras vão encontrar, em sua grande maioria, as regras óbvias e as regras inúteis. Eventualmente, surgem regras que podem resultar em insights bacanas que levarão ao lucro. Mas como o nome diz, em Data Mining, a gente escava toneladas de terra prá achar uns gramas de ouro.

A geração destas regras é um processo demorado, então os supermercados acabam trabalhando com categorias de produtos (ao invés de produtos individuais) e restringem o campo de busca a assuntos mais específicos. Há várias maneiras de obter estas regras como esta bem didática que eu encontrei usando excel.

Voltando à cerveja e às fraldas, a verdade sobre esta história parece ser bem menos glamourosa. Talvez, ninguém tenha realmente ganhado rios de dinheiro vendendo cerveja e fraldas juntas.

Errou a wikipédia. Tsc Tsc. [UPDATE: o Girino diz que corrigiu]

Mas o Data Mining, muitas vezes, traz mais perguntas que respostas.

Dado que cerveja e fraldas estão correlacionados, o que é melhor? Deixar um perto do outro prá facilitar a compra impulsiva ou deixar um longe do outro prá forçar o sujeito a andar pela loja e possivelmente comprar algo mais no caminho?

Outro aspecto dos Market Baskets é que à medida em que sabemos quem é o cliente (geralmente via cartão de crédito ou de fidelidade), abre-se margem para analisar o Market Basket ao longo do tempo. O supermercado sabe que se você comprou um cortador de grama, provavelmente vai comprar um regador, etc.

Está no ar o WikiProteins beta, que é parte de uma iniciativa iniciada anteriormente, o WikiProfessional. A idéia é a mesma do WikiPedia porém voltada para a anotação de proteínas.

A anotação é um processo de caracterização de proteínas, principalmente de sua função. Existem biólogos em constante processo de anotação de proteínas e genes. Esse processo pode se dar em intervalos curtos de tempo, como em projetos genomas, onde diversos novos genes são descobertos e precisam ser anotados. Ou como em projetos de longo prazo, como a anotação de todo o UniProt, por exemplo.

Em ambos os casos todos os tipos de informações sobre genes e proteínas tentam ser coletados, assim como dados de função, localização, informações estruturais, artigos científicos relacionados, etc. O WikiProteins provê exatamente esse tipo de informação de maneira editável por qualquer um.

É claro que foi necessário um esforço computacional inicial pesado pra reunir diversas informações de proteínas e genes em um único pool inicial pra servir de startup pro wiki. E os dados foram minerados de fontes bem confiáveis, como o PubMed, UniProt e BioMed Central.

Os autores fizeram uso de metodologias de text mining/data mining que demandaram a criação de um componente de software, denominado Knowlet. Os Knowlets, segundo os autores, “combinam múltiplos atributos e valores para os relacionamentos entre conceitos” (tradução minha). Mais sobre isso no paper da Genome Biology.

Só pra constar, eu andei testando o WikiProteins com uns genes que o Lúcio me passou Esses genes parecem ser relacionados com nefropatia em pacientes diabéticos. Mais especificamente o gene PCSK1, que é uma proteína neuroendócrina. O WikiProteins me retornou uma série de informações relevantes e minha impressão é que o site promete.

Infelizmente ele não me retornou exatamente o que eu queria saber - e isso eu obtive com o bom e velho Gene Cards :

…susceptibility gene for non insulin dependent diabetes (type II) and…”

Bom, acho que agora é hora de promover o site e editar o Wiki…

PS: Ah, esse post foi de dica de um amigo, o Durfan