Tecnologia. Inteligente.

Eu sempre gostei de ciência mais aplicada. Por exemplo, voltada pra descoberta de alguma nova droga ou para os efeitos de alguma substância sobre os seres vivos.

Acabo de voltar de um congresso de bioquímica (SBBq), em Águas de Lindóia – SP, e lá deu pra ver um punhado de pôsteres sobre trabalhos científicos bem aplicados. Mas teve um que me chamou a atenção porque tinha uma foto de uma avenida de São Paulo, cheia de carros e bastante poluída, como as fotos abaixo

Bom o pôster tratava dos efeitos do phenantrene ( um hidrocarboneto poliaromático que é um dos produtos da combustão do diesel) em neutrófilos humanos (células do sistema imunológico). A conclusão era de que a exposição ao phenantrene atuava inibindo a mobilidade e aumentando a mortalidade dessas células – ou seja, imunossupressão.

Uma nota interessante da autora do pôster foi a de que o phenantrene é expelido em grandes quantidades pela combustão do diesel, aparentemente em forma de pó. Ou seja, se moramos em grandes cidades, estaremos incondicionalmente expostos a grandes quantidades dessa substância. Não dá pra saber como seria o efeito do phenantrene se inspirarmos ou se nossa pele ficar coberta por ele, durante longos intervalos de tempo, pois não existem estudos sobre isso. Mas dá pra ter uma idéia do que acontece no sistema imunológico.

E aí eu me lembrei de uma nota técnica publicada recentemente pela Anvisa, sobre a quantidade de agrotóxicos proibidos para uso em alimentos no Brasil. A tabela é de dar medo, porque diz que 44% dos tomates e 40% dos alfaces testados possuíam agrotóxicos proibidos para uso ou em quantidades acima do permitido.

Paranóia ou não o engraçado é que eu percebi que nos dias subseqüentes à publicação alguns sites de notícias trouxeram artigos com títulos do gênero: “Comer tomates todos os dias faz bem pra pele” ou “Comer tomates combate o câncer de próstata”.

Assim como o phenantrene, e também muito esquisito, se pararmos pra pensar, é que não existem estudos sobre os efeitos da exposição crônica a baixas doses de agrotóxicos em seres humanos, apenas os efeitos agudos – neurotoxicidade e câncer, por exemplo.

E aí fica a pergunta: onde estão os estudos sobre o efeito prolongado da exposição a essas substâncias?

E melhor ainda, por que não adotar o biodiesel (cuja combustão não produz tantos compostos nocivos) e os alimentos orgânicos (que não foram expostos a agrotóxicos)?

Há algum tempo aqui no Blog, um post do Kenji chamou atenção para a categorização e recuperação de imagens. Com o aumento da oferta de câmeras digitais (cada dia melhores e mais baratas) e a farta disponibilidade de imagens na WEB (Picasa, Flickr e afins), a capacidade de humana de categorizar e buscar imagens tem diminuído rapidamente (quem nunca se esqueceu em qual pasta armazenou aquela foto perfeita?). Uma maneira de automatizar este processo é utilizar um sistema de Recuperação de Imagens com Base no Conteúdo - RIBC (em inglês Content-Based Image Retrieval).

Na abordagem RIBC, como nome indica, o próprio conteúdo visual é utilizado na análise da imagem. De maneira geral esta análise é realizada utilizando alguma técnica de Processamento Digital de Imagens ou Visão Computacional. Mas o que seria este conteúdo visual de uma imagem? De forma simples, é possível definir o conteúdo visual com base em atributos de baixo nível como cores, formas e texturas presentes na imagem.

Assim, para a categorização de uma base de dados visuais qualquer (como as fotos de suas últimas férias), algoritmos que, por exemplo, detectam correlações entre as cores, orientação em texturas ou formas presentes nas imagens são empregados na geração de vetores de características (feature vectors).

Consultas a uma base já categorizada podem ocorrer de várias formas:

• busca por exemplo, onde uma imagem de exemplo é fornecida. Tal imagem pode ser um desenho criado pelo usuário ou algum imagem pré-existente;
• busca por distribuição de cores, onde a distribuição de cores esperada é fornecida (60% azul e 40% verde representando imagens panorâmicas com o horizonte ao fundo);
• busca por formas, onde a forma desejada é fornecida (como o formato de um automóvel);

A recuperação da informação visual é, então, realizada pela comparação entre os vetores de características da base e aquele obtido da consulta.

Uma das aplicações mais interessante desta tecnologia, e que serve para ilustar o seu uso, pode ser encontrada no site do Museu Hermitage de São Petersburgo, Rússia. Desenvolvido em parceria com a IBM, o site possibilita ao visitante virtual pesquisar a grande coleção de arte do museu utilizando o sistema QBIC de recuperação de informação visual. Consultas por distribuição de cores e por desenho de exemplo são permitidas e os resultados são bastante interessantes (veja um exemplo nas imagens abaixo).

Consulta

Resultado

A RIBC é um campo de pesquisa ainda em aberto e muito desafios não possuem soluções satisfatórias como, por exemplo, a realização de consultas semânticas como “fotos de cachorros”. E, exatamente por isso, é uma área tão interessante ;-).

Na semana passada saiu uma notícia no site da Folha que achei muito engraçada. OK não era assim tão engraçada mas era, no mínimo, curiosa. O avião onde voava o Tony Blair foi interceptado por caças israelenses por engano (veja a nota publicada no site da Folha). Além do fato em si soar meio bizarro, o que achei particularmente divertido foi o teor contido nas entrelinhas da explicação dada para o ocorrido:

“Um novo sistema teria sido implantado nos últimos meses para identificar aviões suspeitos, e as forças israelenses estão em alerta depois que o grupo radical islâmico palestino Hamas utilizou uma aeronave para derrubar um muro na fronteira com o Egito, há cinco meses. A imprensa britânica lembrou que o sistema de defesa aérea de Israel é um dos mais rigorosos do mundo, e que seus aviões de guerra respondem muitas vezes a alarmes falsos.”

Posso até estar enganado mas gosto muito da idéia de imaginar que eles têm um sistema capaz de identificar aviões hostis ou que representam risco. Um sistema desses obviamente seria heurístico e estaria sujeito à famigerada taxa de acerto. Ou seja, ele funciona bem e identifica corretamente aviões suspeitos com uma taxa de acerto de X%. No caso do avião do Tony Blair, o sistema teria dado um falso positivo.

Quando se está tentando resolver um problema do “mundo real” usando técnicas de inteligência artificial ou heurísticas é muito comum se negligenciar o aspecto da taxa de acerto esperada no funcionamento do sistema e das conseqüencias dos erros esperados quando eles acontecerem (e eles vão acontecer). Na minha opinião esse tipo de negligência é mais ou menos como desenvolver um software convencional sem se preocupar com a qualidade de sua interface ou com sua usabilidade. Ou seja, você corre o risco de desenvolver um sistema que tem um bom conteúdo mas que não serve para nada na prática!

Tomando esse exemplo hipotético do sistema de defesa israelense, suponha que os responsáveis pelo seu desenvolvimento tivessem duas alternativas para o método de reconhecimento. Uma cujo funcionamento esperado fosse:

• Se a aeronave for realmente hostil, a probabilidade do alarme ser disparado é 99,9%
• Se a aeronave não for hostil, a probabilidade do alarme ser disparado é 1%

E outra cujo funcionamento esperado fosse:

• Se a aeronave for realmente hostil, a probabilidade do alarme ser disparado é 80%
• Se a aeronave não for hostil, a probabilidade do alarme ser disparado é 0,01%

Qual método é melhor?

A resposta para essa pergunta não faz sentido se você não considerar a estratégia geral da defesa israelense e seus objetivos com o sistema bem como os custos relacionados ao disparo de um alarme dessa natureza (tirar 2 ou 3 caças do chão para interceptar uma aeronave custa dinheiro além de pontos negativos de publicidade no caso de um falso alarme). Desconsiderar essas questões podem invalidar completamente a escolha do método, por melhor que sejam os argumento científicos que embasam a escolha.

É esse tipo de coisa que torna difícil transformar novidade científica em inovação. Por definição a inovação tem de estar incluída dentro de um contexto de uso no mundo real, fora de um laboratório de pesquisa. Meu exemplo hipotético pode parecer óbvio mas esse padrão pode se repetir em diversas situações onde a escolha não é tão simples, e nesses casos ser sensível a esse tipo de variável é o que muitas vezes diferencia uma empresa de inovação que tem um produto de sucesso de outra que não tem.

Richard Wettel é um estudante de doutorado na Suíça, e desenvolveu uma tecnologia bem interessante para visualização de bases de código. O CodeCity usa a metáfora de cidades para apresentar os componentes de uma base de código orientada por objetos de forma tridimensional, bem bonitinha. Classes são prédios e pacotes são os bairros. Diversas métricas, como tamanho, complexidade e outras podem ser representadas como características dos prédios (altura, cor, e assim por diante).

Não sei se serve pra alguma coisa útil, mas que é bonitim é. Abaixo, o CodeCity visualizando o próprio código:

Então semana passada o Google anunciou o Google Friend Connect. O que é isso? Uma maneira de adicionar funcionalidades “sociais” ao seu site ou aplicação web sem escrever código. Eles vão disponibilizar um conjunto de widgets que você pode adicionar ao seu site, sem programação nenhuma do seu lado.

Quando você adiciona o seu widget, os usuários de redes sociais podem logar nas redes uma única vez e ter acesso às funcionalidades sociais do seu site, assim como às funcionalidades dos outros sites que se integrarem ao Friend Connect. Eles podem convidar seus amigos nas redes para visitarem o seu site, fazer novos amigos (inclusive de outras redes), navegar pelos perfis públicos dos usuários logados no momento (inclusive de outras redes), adicionar comentários e reviews no seu site, etc.

Dessa forma, você pode tornar seu site mais interativo e atrair visitantes, mas sem gastar esforço com programação. Discussões e comentários podem ser feitos de forma integrada às redes sociais. Você pode criar updates no seu site que são automaticamente divulgados nas redes através dos perfis dos usuários que “assinam” o seu site via Friend Connect.

E esse é só o começo, porque os widgets são compatíveis com o Open Social, a tecnologia do Google para a criação de aplicações sociais portáveis para múltiplas redes. Ou seja, desenvolvedores do mundo todo poderão criar aplicações que você pode usar no seu site via Friend Connect. Talvez haja um novo mercado para desenvolvedores independentes de software: criar aplicações legais usando Open Social para o Friend Connect.

Outro aspecto interessante é a integração de múltiplas redes. Você pode usar o Friend Connect, por exemplo, para permitir que usuários das grandes redes, como o Orkut, participem de redes muito mais especializadas, sem ter que se registrar duas vezes, duplicar listas de amigos, etc.

Esses dois fatores, a facilidade de oferecer conteúdo e funcionalidade diferenciados e a portabilidade do seu “contexto social” podem levar a uma explosão no número de redes sociais especializadas e a uma maior integração entre conteúdo e interação social. A diferença entre redes sociais, de um lado, e fóruns e sites de notícias colaborativos, de outro, tende a sumir, já que o Friend Connect permite que você “leve” seu contexto social das redes para esse tipo de site.

Infelizmente o Friend Connect ainda está em desenvolvimento, e há preocupações com privacidade, também. Mas que a coisa promete, promete.

“Imagination will often carry us to worlds that never were. But without it we go nowhere.” Carl Sagan

Este é o primeiro de uma série de posts descrevendo uma paixão antiga minha, fruto de um trabalho de pesquisa iniciado há mais de 12 anos: o futebol de robôs. Apesar (ou justamente por isso) de ser um perna-de-pau de primeira na vida real, me envolvi nesta que é, para a maior parte dos mortais, uma modalidade esportiva (?) no mínimo curiosa.

O futebol de robôs surgiu na primeira metade dos anos 90 como uma forma divertida de desenvolver as habilidades de robôs autônomos atuando em equipe para atingir uma determinada meta. Para os que acham que é uma mera brincadeira, há diversos exemplos sérios e concretos de como a tecnologia desenvolvida pode ser útil para a humanidade:

• tarefas repetitivas mas não facilmente automatizáveis, como limpar a sua casa:

• lavar as louças:

Ops, como eu ia dizendo, diversos exemplos sérios e concretos:

• tarefas em ambientes inóspitos ou perigosos, como dar manutenção em gasodutos, implantar bases submarinas para extração de petróleo ou reparar linhas de transmissão de alta-tensão;

• situações extremas onde é necessário tomadas muito rápidas de decisão, como a automação do controle de veículos na iminência de um acidente;

• e qualquer outra situação onde o ser humano não possa ou não deva agir, por risco ou por incapacidade, e que haja necessidade de tomada de decisão rápida com base em variáveis do ambiente e em eventual comunicação com outros agentes (planejamento em equipe).

A menção ao futebol de robôs geralmente traz ao imaginário leigo imagens de robôs humanóides driblando, fazendo embaixadinhas e comemorando os gols. Apesar disto ser o objetivo final destes projetos, algo assim só deverá ser alcançado, na mais otimista das hipóteses, daqui a 20 anos. Hoje até já temos robôs humanóides, mas uma partida típica nesta categoria ainda se parece mais com um jogo de idosos portadores de esclerose múltipla, ou outra disfunção motora:

Portanto, para evitar frustrações, vamos assumir que me refiro especificamente à categoria das “caixinhas com rodas”: pequenos robôs capazes de “empurrar” a bola até o gol, desviando dos adversários quando possível:

Sim, eu sei que tem muito menos glamour do que os tais humanóides esclerosados acima, mas como sempre dizia meu grande orientador na graduação, Prof. Mário Campos, KISS (Keep It Simple, Stupid).

Nesta categoria, de pequenas caixinhas com rodas, os dois campeonatos mais conhecidos são a copa RoboCup e a copa Mirosot. Foi nessa última que nós participamos nos idos de 1998 e 1999, inclusive conquistando um honroso título de campeão sul-americano em 1999 (ok, os outros times não eram lá muito fortes também, mas ninguém precisa ficar sabendo disso).

Então vamos começar a falar do que interessa: a tecnologia. O projeto de um time de futebol de robôs envolve diversos estágios multi-disciplinares:

• projeto mecânico;

• projeto elétrico e eletrônico;

• componentes de software para suporte (sensoriamento e transmissão de comandos);

• componentes de software para estratégia e controle.

Tentarei dar uma breve visão dos últimos dois itens, especialmente nos componentes de visão (sensoriamento), controle e estratégia. São estes três os itens que mais me interessam, e que, suponho, sejam de maior interesse dos leitores deste blog. Portanto, este artigo será seguido de três outros, cada um descrevendo uma dessas três áreas.

Espero também que os leitores mais técnicos me perdoem pelo estilo literário menos científico. Mantendo a linha editorial do blog, pretendo escrever da forma mais simples possível para o leigo. Sempre que possível, deixarei referências para quem quiser se aprofundar no assunto.

Renato Mangini é arquiteto de software sênior. Foi sócio fundador da Vetta Technologies e da Vetta Labs e hoje ele trabalha em sua startup de tecnologia (nome e produto ainda não divulgados). Sua formação acadêmica inclui um bacharelado em Ciência da Computação e um mestrado inacabado, ambos pela UFMG, e cursa agora um MBA no Ibmec.

May 16, 2008 by Renato Mangini Inteligência Artificial, Robótica 2 Comentários

(No Ratings Yet)

 Loading ...

Lembram do meu último post sobre dois artigos que descrevem a criação bio-computacional de enzimas artificiais? Pois é, o David Baker, autor daqueles papers, lançou uma nova “moda”. Um jogo online chamado fold-it. O objetivo é competir para criar conformações, ou enovelamentos (ou ainda foldings), mais prováveis pra uma proteína. Quanto melhor for o enovelamento, mais pontos o jogador ganha.

A pergunta que voces devem estar fazendo agora é: o que um cientista renomado quer lançando um jogo online? É claro que não é só pela diversão .

David Baker há anos vem estudando maneiras de computar o enovelamento de proteínas. O motivo é que o enovelamento, ou conformação final de uma proteína, influencia criticamente em sua função.

E criar uma enzima nova requer descobrir exatamente o folding dessa enzima a partir de sua seqüência de aminoácidos. O problema é que essa não é uma tarefa fácil – calcular o enovelamento de um proteína requer efetuar até trilhões de cálculos.

A idéia do jogo começou com o Rosetta, um algoritmo que usa o método de Monte Carlo para predizer a melhor conformação de uma proteína. Já existe há anos um programa de rede distribuída chamado Rosetta@home, que usa computadores voluntários do mundo inteiro com o objetivo de rodar o Rosetta, enquanto ociosos - um screen saver é aberto e mostra como o programa tenta descobrir o enovelamento de diversas proteínas.

Mas os usuários verificavam que esse programa fazia coisas visivelmente idiotas - o que era meio de se esperar, por ser um algoritmo força bruta. A idéia do David Baker foi de, ao invés de usar uma marreta pra solucionar o problema, usar a capacidade de resolver problemas 3D do cérebro humano, usando um jogo.

E o pior é que funciona – houve situações em que o jogador conseguiu achar corretamente a conformação uma proteína, com forma já conhecida, mais rápido que o computador!

Mas a grande “jogada” do David Baker é fazer com que os jogadores criem conformações novas para proteínas ainda não conhecidas. Essas conformações poderão servir para a síntese de drogas e enzimas ainda não conhecidas, de maneira mais rápida… e divertida

Faz um certo tempo que li um artigo muito interessante do Jason Cohen no CM Crossroads com o título “Checklists – You build me up just to knock me down”. Resumidamente, o autor trata da construção de checklists de revisão de código mais eficientes e para isso ele cita algumas “regras do dedão”, como:

• 10 itens no máximo, porque mais do que isso atrapalha e torna o preenchimento cansativo para o revisor. Para ratificar esse valor, ele cita George Miller [1], autor do famoso estudo sobre a capacidade cognitiva humana de processamento de informação que propõe como limite sete mais ou menos dois.
• Nada de itens genéricos ou óbvios como “o código faz o que é esperado” ou “o código está legível”, pois a revisão é feita justamente para encontrar esse tipo de problema.
• Nenhum item que possa ser detectado de forma automática via ferramentas como PMD, FindBugs, Checkstyle, dentre outras.
• Verificar coisas fáceis de esquecer, como fechamento de conexões de banco.
• Construir o checklist de forma empírica, com os erros mais freqüentes da equipe para uma determinada tecnologia.
• Sempre atualizar o checklist e remover os itens que não são mais relevantes.

Apesar de tratar de revisão de código, essas dicas podem ser empregadas em outros checklists, como de revisão de modelo de arquitetura, de especificação de caso de uso, plano de projeto, etc. Porém, uma coisa que me chamou a atenção no artigo foi algo não abordado por ele: a função do checklist. Qual é a utilidade daqueles papéis ou planilhas que, em muitas vezes, são preenchidos de forma “automática” e sem muita atenção?

A primeira e mais óbvia é de guia. Como não se pode contar com o “bom-senso” do revisor na inspeção do artefato, o checklist serve como um roteiro a ser seguido durante a verificação, uma base de critérios a serem inspecionados que asseguram a qualidade do artefato desenvolvido.

A segunda função, menos evidente, é a de contrato. Ao preencher o checklist, o revisor atesta que os pontos citados foram verificados e que o artefato está de acordo com o padrão estabelecido. Essa função pode não ser muito clara em grande parte das inspeções, mas ela fica evidente em “pré-verificações”, ou seja, naquelas em que o revisor é o próprio autor do artefato. Recordo-me de um checklist de término de implementação, utilizado em um dos projetos no qual trabalhei, e que funcionava da seguinte forma:

• ao final da implementação de um caso de uso, o desenvolvedor preenchia um checklist contendo algumas verificações a serem feitas no caso de uso, como se o fluxo principal era seguido corretamente, se não havia mensagens sem tradução na interface, se os botões funcionavam corretamente, dentre outras;
• se o desenvolvedor detectasse algum problema, ele retornava à codificação para corrigir o problema encontrado.
• se nenhum dos problema listados fosse encontrado, o desenvolvedor entregava o checklist preenchido para o testador, atestando que o código estava pronto para ser testado;
• o testador verificava novamente os itens do checklist e se aparece alguma não-conformidade, um bug era criado na ferramenta de controle de issues e o desenvolvedor era “amigavelmente advertido” pelo gerente do projeto.

Problemas encontrados pelo testador em um dos itens do checklist eram como uma quebra de contrato entre o desenvolvedor e o testador, passível de retaliação. Lembro-me que antes desse processo ser implementado, os testadores reclamavam do grande volume de erros “bobos” encontrados durante os testes; depois do checklist, o número desses casos caiu sensivelmente (ah, as maravilhas do behaviorismo… :-D)

A terceira, mais sutil ainda, é a de evidência. Durante o processo de certificação de CMMI nível 3 da Vetta Technologies, os checklists de inspeção de código e de verificação de artefatos serviram não só como evidência de que esses procedimentos eram aplicados nos projetos mas também como comprovação que eram feitos de maneira uniforme, definida e documentada. Ou seja, algo que fazíamos de uma forma praticamente natural (e que muitos encaravam como apenas uma mera formalidade) foi de grande utilidade nesse processo.

Sendo assim, da próxima vez que for preencher um checklist, pense no que está fazendo: dependendo da função, a “mera formalidade” pode acabar em um belo “puxão de orelha”.

[1] George Miller também é conhecido por ser um dos responsáveis pela criação do Wordnet, banco de dados lexical e semântico da língua inglesa bastante usado em projetos de processamento natural de linguagem e correlatos.

Paulo Ferreira de Moura Junior, bacharel em Ciência da Computação pela UFMG, é arquiteto e líder técnico da Vetta Technologies.

Naquele estranho (e meio nojento - tudo bem, muito nojento) filme de 1986 do Cronenberg, “A Mosca”, em algum momento a repórter interpretada pela Geena Davis pergunta ao cientista vivido pelo Jeff Goldblum como ele conseguiu construir um teleportador do nada no galpão dele. O cientista responde que na verdade ele não fez aquilo sozinho e nem do nada, ele contratava equipes de cientistas ao longo do globo pedindo coisas esquisitas do tipo “quero um analisador molecular obedecendo tais e tais especificações”, e aí uns meses depois lá chegava o analisador molecular. As equipes independentes de cientistas que resolviam esses sub-problemas e criavam esses componentes só enxergavam o que precisavam enxergar, não tinham noção de onde a solução que eles desenvolveram seria aplicada, e principalmente não tinham a menor idéia do projeto do teleportador que o personagem principal estava desenvolvendo.

No mundo real, longe das referências nerd envolvendo obras de ficção científica, devo dizer que nós aqui do Vetta Labs às vezes nos sentimos um pouco como os cientistas do filme que construíram o analisador molecular sabe-se lá para ser usado em que. Como diz o ditado, “o segredo é a alma do negócio”, e isso é particularmente aplicável quando o negócio envolve a análise de informações de outras empresas que querem ao mesmo tempo terceirizar serviços de mineração de dados e preservar o sigilo de seus contratos e seus clientes.

Pois bem, uns meses atrás, em mais um daqueles exemplos das maravilhas do outsourcing de pesquisa, fomos contratatos pela Novamente para analisar os dados de um terceiro cliente-cujo-nome-não-será-revelado, que como dá para suspeitar pela omissão do nome era justamente desses que preferem manter seus dados e planos envoltos em mistério. Recebemos uma base de dados composta por dezenas de milhares de tuplas, cada uma formada por um punhado de valores correspondendo a um pequeno conjunto de variáveis. O problema que nos foi colocado foi tentar prever uma das variáveis em especial com base nos valores de todas as outras, com uma taxa de acerto superior a um certo limite mínimo aceitável. A variável a ser predita era, para todos os fins práticos, lógica, do tipo “sim” ou “não”. As demais variáveis eram bem variadas, algumas claramente numéricas, outras também lógicas, e finalmente umas que talvez fossem numéricas ou talvez fossem simbólicas. O caso é que não tínhamos nem muita certeza do tipo de algumas das variáveis porque não nos foi dada qualquer informação sobre as mesmas. Os nomes de algumas variáveis até davam pistas do que elas deviam ser (mas não exatamente em que unidades elas estavam sendo medidas), porém outras variáveis tinham nomes herméticos que não ajudavam muito do ponto de vista da, digamos, semântica dos dados.

Assim, inventando uma base de dados parecida para fins de exemplificação, vamos supor que temos um conjunto aparentemente desprovido de sentido de quatro variáveis chamadas TUTU, PEDRA, CAVALO e CHUVA, e com base nelas temos de prever se o valor de uma quinta variável RESPOSTA é “sim” ou “não”. Existem dezenas de milhares de combinações-exemplo de valores de TUTU, PEDRA, CAVALO e CHUVA com valores conhecidos de RESPOSTA, e com base nelas devemos achar regras engraçadas como, digamos, “Se TUTU vale mais que 0.65, PEDRA tem valor ‘mole’ ou ‘redonda’, CAVALO pode ter qualquer valor e CHUVA vale ‘forte’, então RESPOSTA é ’sim’, caso contrário ‘não’”, regras essas capazes de prever RESPOSTA corretamente com uma acurácia maior que um mínimo estipulado pelo cliente.

Numa situação dessas, o bom minerador de dados deve se ater àquela máxima que acredita-se o filósofo-patrono das ciências exatas, o Pitágoras, soltou uns 25 séculos atrás: “Tudo são números”. É verdade que, como já exemplificamos várias vezes aqui no blog, quando mais informação você tem sobre uma base de dados, melhor, e às vezes é inclusive interessante usar outras bases de dados direta ou indiretamente relacionadas para “amplificar” a base objeto do seu estudo. Porém, nas situações em que não podemos (ou não devemos saber mais a respeito dos dados, o puro uso da lógica e da matemática podem ainda assim ser surpreendentemente efetivos.

Foi assim no caso dessa base de dados “misteriosa”. Devo dizer que criar uma abordagem capaz de passar do limite de acurácia mínimo pedido pelo cliente foi bem… desafiador, talvez inclusive devido ao desconhecimento da semântica dos dados. Mas, no final, chegamos a uma método bem robusto capaz de resolver até nossas dúvidas sobre o tipo exato de algumas variáveis. Nessa metodologia (da qual falarei apenas por alto para não “falar demais” :), desenvolvemos uma maneira de medir a “capacidade de predição” de uma variável quando assumia um dado valor (não importando se esse valor é um número, uma string, lógico, etc), e também para qual resposta (”sim” ou “não”) tendia esse dado valor de dada variável. No final, ao contrário do exemplo acima, nossas regras verificavam não os valores diretos das variáveis, mas sim a capacidade de predição dos valores que elas estavam assumindo na tupla em questão, e com base nisso decidiam se a tupla apontava para “sim” ou um “não”.

Conseguimos com essa abordagem ultrapassar (por pouco) a acurácia mínima pedida pelo cliente, inclusive em um segundo conjunto de tuplas completamente desconhecidas, seguindo o mesmo formato de dados, que o cliente nos forneceu para uma validação adicional. É possível que agora formalizemos um serviço de análise e desenvolvimento de mais longo prazo - e quem sabe até com um véu de mistério menos espesso. De qualquer forma, a lição que ficou foi: os números são seus amigos, não se desespere se eles são a única coisa ajudando você em seu trabalho de análise de dados.

Enzimas são potentes catalizadores. Elas podem tornar a velocidade de uma reação química bilhões de vezes maior. Porém as enzimas foram designadas, ou melhor, moldadas durante a evolução, para catalizar apenas reações que ocorrem em seres vivos.

Dois papers publicados na revista Nature descrevem pela primeira vez um método from scratch para se criar enzimas que catalizam reações químicas não-naturais. O método envolve o uso de técnicas de modelagem computacional, bioquímica e biologia molecular - por exemplo, métodos quantum-mecânicos, o algoritmo de hashing RosettaMatch e evolução in vitro.

Os autores criaram efetivamente uma enzima que consegue catalizar uma reação não-natural, a reação de Kemp (onde um íon de hidrogênio é removido de uma ligação carbono-hidrogênio), até um milhão de vezes mais rápido que a reação não catalizada.

Agora resta criar um método para criar enzimas customizáveis em larga escala. As aplicações, para a indústria farmacêutica por exemplo, são ilimitadas.