6 de dezembro de 2021 18:26:38

Projeto T Novidades

por Hindemburg Melão Jr. 


Esse artigo trata de algumas atualizações sobre o projeto T. Caso não esteja familiarizado com a proposta do projeto T, por gentileza, leia https://www.saturnov.org/2021/projetot

Ontem (30/11/2021), foi dado o primeiro passo concreto no desenvolvimento do sistema principal do projeto T. Nessa primeira etapa, foi desenvolvido um miniprojeto de IA, muito pequeno e elementar, mas dentro de 3 a 6 meses é muito provável que já tenhamos alguns avanços importantes. Minhas estimativas iniciais eram de que poderia levar 2 a 5 anos para que os primeiros frutos fossem colhidos, mas depois de implementar e testar alguns sistemas básicos de machine learing, ficou claro que minha estimativa era demasiado conservadora e até mesmo pessimista. Há muito material pronto, possibilitando que em poucas horas seja implementado um sistema básico de IA. Se tivesse que implementar a partir do zero, usando uma linguagem como C++, sem acesso a bibliotecas prontas, provavelmente levaria uns 2 meses, mas com as bibliotecas prontas disponíveis, pode ser realizado em questão de minutos ou horas.

Porém à medida que o projeto avançar, a expectativa é de que cada vez será mais difícil e improvável encontrar algum material pronto. Para fazer uma réplica de MuZero, sem nenhum aprimoramento, provavelmente 1 semana seria suficiente. Mas para implementar todos os recursos planejados até agora, estimo que se não houvesse imprevistos, levaria de 2 a 3 meses. Mas quase sempre há imprevistos, além disso é muito provável que, durante a implementação, ocorram várias outras ideias que não haviam sido consideradas antes de “colocar a mão na massa”. Isso é bom, porque conduz a resultados melhores do que os planejados, mas tem também o lado negativo de demandar mais tempo que o planejado. Considerando prós e contras, uma estimativa de 6 meses me parece razoavelmente realista.

O miniprojeto de ontem foi um sistema de IA para reconhecer imagens. Numa primeira etapa, o sistema é treinado com base em 10.000 imagens de 10 categorias de objetos: “Camiseta”, “Calça”, “Suéter, “Vestido”, “Casaco”, “Sandália”, “Camisa”, “Tênis”, “Bolsa”, “Bota”. O sistema recebe fotos de 1.000 objetos de cada categoria e tenta reconhecer padrões nas formas dos contornos das imagens e na distribuição das intensidades de brilho (tons de cinza) que permitam distinguir os objetos de uma mesma categoria dos objetos de outras categorias. Em seguida, o sistema examina outras 10.000 imagens, todas elas diferentes das primeiras 10.000, mas que também estão distribuídos nas mesmas 10 categorias. Por fim, conta-se quantas imagens ele reconheceu corretamente. Alguns são bem fáceis, como “tênis” e “calça”. Mas outros são difíceis – inclusive para humanos – como “casaco” e “suéter”. A taxa de acertos foi de 88%, sendo que entre os 12% de erros, nenhum desses erros envolveu confusões entre objetos muito diferentes um do outro (confundir uma bota com um casaco, por exemplo).

Não há nada de espetacular nisso, mesmo porque todas as fotos são com fundo branco, não há objetos secundários em cada imagem que dificultem o reconhecimento do objeto principal, o ângulo em que os objetos estão posicionados é o mesmo em todas as imagens, os tamanhos são semelhantes etc. Há vários outros sistemas de IA similares e melhores, mas o detalhe interessante a ser ressaltado é a rapidez com que podem ser implementados e aprimorados sistemas como esse. Há 50 anos, projetos assim nem sequer existiam. Há 10 anos existiam, mas exigiam vários meses de trabalho para serem implementados. Agora podem ser implementados em questão de minutos e aprimorados em poucas horas.

Embora seja um sistema “simples”, é extremamente poderoso. Com pequenos aprimoramentos e personalizações, poderia fazer diagnósticos com base em radiografias, tomografias, ultrassonografias ou ressonâncias. É incrível que algo assim possa ser implementado e configurado em questão de horas. As imagens abaixo mostram 40 exemplos sorteados entre as 10.000 imagens usadas no treinamento:

01.png


Conforme se pode verificar, as diferenças entre botas e tênis são sutis, assim como as diferenças entre casaco e suéter. Mesmo assim, o sistema consegue distinguir corretamente na maioria das vezes. A seguir, uma amostra de 24 resultados sorteados entre as 10.000 imagens de validação, já indicando se o sistema acertou (barra azul maior) ou se errou (barra vermelha maior):

02.png


Houve apenas 2 erros entre 24 objetos, com mais de 90% de acertos. Além disso, os dois objetos com identificação equivocada apresentam “anomalias”, pois o fundo é branco e esses objetos apresentam vastos detalhes brancos, dificultando que o sistema possa distinguir se essas partes são buracos no objeto ou se são cores na superfície desses objetos. A utilização de fundo branco pode ser uma faca de dois gumes, pois ao mesmo tempo que facilita alguns reconhecimentos, também produz alguns “falsos-positivos” e “falsos-negativos”.

Depois dos testes iniciais com 10.000 imagens, foi realizado um teste mais abrangente com 60.000 imagens, sendo 30.000 na otimização e 30.000 na validação. No conjunto total de 30.000 imagens de validação, esse sistema obteve 88,7% de acertos.

O mesmo sistema, com pequenas modificações, também consegue reconhecer a qualidade de um filme com base na “leitura” e “interpretação” dos reviews dos espectadores. O sistema é treinado com base em 25.000 reviews e 25.000 rótulos que informam se cada review é positivo ou negativo. Em seguida, ele “lê” outros 25.000 reviews, mas dessa vez sem ter acesso aos rótulos. Então, com base no que está escrito em cada review, ele tenta classificar os vídeos como “bons” ou “ruins”. Como há apenas 2 categorias, a probabilidade de acerto casual é cerca de 50%, mas ele consegue 84% de acertos logo nas primeiras gerações e chega a mais de 90% após transcorridas mais de 1000 gerações.

Seria mais interessante se houvesse notas para comparar aos reviews, em vez de ter apenas a informação se o review é positivo ou negativo, mas aparentemente não há uma base de dados com tais informações. Encontrei bases de dados que incluem notas de especialistas, notas do público, nome do filme, gênero, ano de publicação, idioma etc., mas não inclui reviews. E na base de dados com os reviews não constam os nomes, por isso não teria como unir ambas e atribuir os reviews de uma base à outra de forma correta. Poderia fazer um scraping que capturasse da Internet os reviews e as notas, mas seria um processo trabalhoso e não creio que o tempo aplicado nisso estaria justificado. De qualquer modo, é interessante que o sistema consiga distinguir entre reviews positivos e negativos, embora ele não entenda de fato o que os textos dizem. Apenas identifica palavras, frases e fragmentos de textos que são mais comuns nos reviews positivos que nos negativos e vice-versa.

É ainda um IA relativamente básico, mas é o primeiro passo para desenvolver algo semelhante ao MuZero e depois fazer os aprimoramentos necessários para que opere no Mercado Financeiro. Na verdade, nem será necessário desenvolver cerca de 80% a 90% do esqueleto desse sistema, porque já existe muita coisa pronta. Só será necessário fazer algumas personalizações e depois os aprimoramentos. O volume de material pronto me pareceu surpreendente, no início, mas quando se considera que a Deep Mind disponibilizou publicamente um pseudocódigo, é natural que algumas pessoas já tenham implementado muita coisa e disponibilizado também. Assim, além de não ser necessário reinventar a roda, também não será necessário construir a roda. Bastará fazer os aprimoramentos nas rodas que já estão disponíveis.

O gráfico abaixo mostra a evolução do sistema que reconhece as imagens. A configuração utilizada tem apenas 128 neurônios e 2 camadas. A curva mostra a evolução ao longo de 60 ciclos, por um método de otimização baseado em gradiente de primeira ordem de funções estocásticas (Nadam). O eixo y mostra a porcentagem de acertos para otimizações realizadas até determinado número de ciclos:

03_N_TF_001_60_2_128_gelu_sparse_categorical_crossentropy.png


Usando uma rede mais complexa e mais profunda, com 1024 neurônios, 6 camadas e deixando evoluir por 100 ciclos, o modelo de ajuste P4 aos melhores resultados obtidos chega a cerca de 0,893 de acurácia contra 0,887 no caso acima, mas o tempo necessário para uma otimização com as propriedades do próximo gráfico é muito maior. A curto prazo, portanto, não seria uma boa escolha, porque a vantagem é muito pequena em troca de um tempo muito maior aplicado na otimização. Por outro lado, no caso com 128 neurônios e 2 camadas, a evolução alcançou seu limite assintótico por volta do 20º ciclo e daí em diante ficou apenas oscilando, enquanto a rede mais complexa, com 1024 neurônios e 6 camadas, continuou evoluindo até o 100º ciclo, embora o ritmo de evolução tenha ficado muito mais lento a partir do 20º ciclo:

03_N_TF_001_60_2_128_gelu_sparse_categorical_crossentropy.png


Outro ponto a ser considerado é que nesse caso específico do reconhecimento de imagens pode haver “erros” no gabarito. Depois vou fazer alguns testes com casos objetivos, como reconhecimento de números e letras manuscritos, nos quais não haja margem para discordar se o objeto é um número 8 ou uma letra B. No caso das imagens, algumas delas são bastante ambíguas e acho natural que a resposta do sistema não coincida com a do gabarito, por isso rotular as classificações do sistema como “erradas” pode não ser um procedimento adequado.

Nos anos 1990, por exemplo, um dos primeiros sistemas de IA baseado em redes neurais foi alimentado com milhares de fotos de florestas, algumas das quais encobriam zonas militares e outras não, para que o sistema aprendesse a diferenciar os dois grupos. O resultado foi que o sistema diferenciou fotos tiradas de manhã de fotos tiradas à tarde, porque a luz solar incidia de lados opostos e isso produzia uma diferença mais importante do que outros fatores. O sistema não tinha como saber o que as pessoas gostariam que ele reconhecesse. Ele apenas tentava encontrar diferenças sistemáticas que possibilitassem classificar cada imagem como pertencendo a um dos dois grupos.

Então o mesmo sistema foi novamente alimentado com as mesmas fotos, porém dessa vez cada foto na qual se sabia haver uma base militar foi colocada numa categoria e aquelas nas quais não havia foram colocadas em outra categoria, e o sistema foi informado de que ele precisaria distinguir uma categoria da outra, em vez de ele próprio descobrir as categorias existentes. Como resultado, a performance ficou muito melhor, mas ainda sujeita a várias falhas, porque além da iluminação havia detalhes que não se distribuíam uniformemente entre os dois grupos de fotos e que eram mais relevantes como padrões visuais do que as diferenças que eles gostariam de encontrar.

No caso dessas imagens de calçados e roupas, embora sejam mais simples, tem o problema já citado: alguns detalhes na superfície do objeto que tenham cor branca podem ser confundidos com descontinuidades na superfície, por ser a mesma cor do fundo. Isso pode afetar a performance, porque mesmo que o sistema seja capaz de distinguir os detalhes que diferenciam um casaco de um suéter, dependendo do tom de cinza que esses detalhes estiverem presentes na imagem, o sistema pode não os interpretar corretamente, e não seria uma falha no sistema, mas sim uma falha no método de classificação e na escolha das imagens. Outro problema é que simplesmente a classificação feita por uma pessoa sobre o que ela considera ser um suéter e o que ela considera ser um casaco não está necessariamente certo todas as vezes. Portanto o gabarito pode estar contaminado de forma irreparável, e a taxa máxima de acertos talvez seja cerca de 90%.

Essas 10 figuras podem ser distribuídas em 5 grupos de categoriais ou meta-categorias:

• Calças
• Vestidos
• Calçados
• Blusas
• Bolsas

Confundir uma bolsa com uma calça seria um problema grave, mas confundir um tipo de calçado com outro tipo de calçado não é tão grave. Voltando para o quadro das imagens acima, podemos ver que há alguns objetos classificados como “suéter” mas que seria difícil inclusive para um humano distinguir de um casaco. A bota que é confundida com uma sandália, se analisar com cuidado, pode-se perceber que se a parte branca for interpretada como um vazado, realmente se parece com uma sandália. Além disso, se fosse analisar todas as sandálias e todas as botas no banco de dados de aprendizado, provavelmente seriam encontradas mais sandálias semelhantes a essa bota específica do que botas semelhantes a essa bota específica. Mas não é bem esse o problema que eu gostaria de comentar. O problema é que há uma gap muito larga entre a morfologia de cada uma dessas 5 meta-categorias, e uma gap muito estreita entre as categorias internas de cada meta-categorias. Isso é ruim e antinatural, porque a distribuição das diferenças fica com concentrações muito densas em certas regiões e lacunas em outras, em vez de ter uma distribuição suave como uma gaussiana.

Para que o treinamento e o aprendizado fossem mais eficientes, seria melhor se a variabilidade morfológica se distribuísse aproximadamente como uma gaussiana, com níveis de dissimilaridade variando de 0 a, digamos, 4 desvios-padrão (numa amostra com tamanho de 60.000), e que as variabilidades dentro de cada meta-categorias fossem claramente mais estreitas em algumas características específicas do que quando esses objetos fossem comparados a outros de categorias diferentes. Mas o que se observa é que há alguns objetos de categorias distintas cujas dissimilaridades são muito estreitas, menores do que as variações observadas dentro de sua própria categoria, inclusive nas características fundamentais que os classifica. Isso equivale a impor regras ruins de classificação.

No Xadrez também existe esse tipo de problema, que é o afogamento ou pat (stalemate). Pela lógica, deveria ser vitória do lado que coloca o Rei do oponente afogado, mas por algum motivo exótico é considerado empate. Isso gera uma inconsistência nos objetivos do jogo, mas não chega a causar muito dano na qualidade do aprendizado. Porém nos casos de sistema mais simples como este, a presença de inconsistências no treinamento tem peso maior e causa maior dano ao aprendizado.

Se um objeto que se parece mais com uma bota é classificado como sandália, nas características relevantes para a medida de similaridade, isso vai atrapalhar o sistema, em vez de ajudá-lo a fazer melhores classificações. Além do problema já citado: o sistema não tem como saber que em alguns casos a cor branca representa o fundo, isto é, não faz parte do objeto, e em outros casos a cor branca faz parte da superfície do objeto. O sistema está sendo “enganado” com uma informação ambígua que atrapalha seu treinamento e seu aprendizado.

Assim, há objetos muito fáceis de reconhecer, outros muito difíceis, sem que haja os níveis intermediários que seriam úteis para uma avaliação mais acurada, bem como para um treinamento mais eficiente. Além disso, há casos nos quais não é uma questão de dificuldade, mas sim de inadequação, por não ser possível classificar corretamente determinados objetos a partir dos outros que foram usados no treinamento. Vou enviar algumas sugestões sobre isso aos autores da lista de imagens e alguns pesquisadores que publicaram artigos com base nessa lista, pois muitas conclusões devem estar distorcidas pelos motivos a citei acima.

No Mercado Financeiro, certamente ocorrem problemas desse tipo, de ruídos espúrios e operações insanas perturbando o desdobramento natural das cotações. Por isso é desejável que o sistema seja capaz de lidar com dificuldades desse tipo. Mas durante a etapa de seleção das melhores estratégias de otimização, não faz sentido que ocorra esse tipo de problema, cujo efeito será apenas aumentar a incerteza nos escores obtidos pelos diferentes métodos de otimização e dificultar a escolha do melhor método.

O principal sintoma de que há problemas com essa base de dados é que parece haver um limite assintótico evolutivo perto de 0,9 de acurácia, e esse limite provavelmente está relacionado a falhas no conjunto de dados, não a limitações inerentes ao sistema. Certamente há também limitações no sistema, mas não faz muito sentido que o uso de configurações progressivamente mais complexas esbarrem num teto perto de 0,9, a menos que o limite de 1,0 seja inalcançável devido a problemas no gabarito.

Em breve pretendo voltar a testar esse mesmo banco de dados com outros sistemas mais sofisticados, para verificar em que medida essa hipótese sobre o problema ser inerente aos dados pode ser uma explicação adequada.

Além das duas otimizações comentadas acima, foram realizadas outras com números de neurônios variando entre 16 e 2048 e números de camadas variando entre 1 e 16. Também foram alteradas as proporções entre a fração da base utilizada no treinamento e na validação. Os resultados desses testes, a princípio, parecem corroborar o que foi dito acima, mas por enquanto são inconclusivos.

Depois que eu tiver feito testes com reconhecimento de números e letras, haverá mais dados para opinar sobre isso. Se o resultado também esbarrar num teto de acurácia perto de 89%, então talvez o problema não seja inerente à base de dados, mas sim ao sistema. Por outro lado, se não houver limite (isto é, o limite for 100%), isso não implica necessariamente que haja problemas nessa base de dados, mas seria um indício a ser somado para corroborar essa hipótese, pois ao utilizar uma base de dados na qual não haja erros no gabarito nem os outros problemas citados, o limite assintótico em 0,89 seria suprimido, sugerindo que o limite poderia estar de fato associado a esses problemas.

Quando comecei a me interessar por investimentos, em 2005, deparei com muitas ferramentas de baixa qualidade, conhecimentos esotéricos, superstições, não havia bibliografia de qualidade aceitável, era um campo de atuação perdido no tempo, com pensamento medieval, pseudocientífico. Agora, na área de IA, é muito diferente, há muitas ferramentas de boa qualidade, bibliografia de boa qualidade. Isso é muito estimulante, sob diversos aspectos, mas também significa que há uma concorrência muito mais forte e mais bem qualificada.

Nesse cenário, a existência de boa bibliografia significa que não será necessário reinventar a roda, mas significa também que os concorrentes que estão há anos nessa área não precisaram inventar e descobrir os recursos que utilizam. Uma das implicações disso é a seguinte:

Uma pessoa que estivesse há 30 anos no Mercado Financeiro não tinha praticamente nenhuma vantagem em comparação a alguém que estivesse começando hoje, pois 30 anos “estudando” sem bibliografia adequada, ela teria que descobrir tudo quase do zero, ou continuaria tão ignorante quanto era quando começou. Ela poderia aprender muitas inutilidades sobre análise técnica, análise fundamentalista e similares, mas que de nada serviriam para lidar com os problemas que ela precisaria resolver, não proporcionando a ela nenhuma vantagem competitiva em relação a alguém que começasse agora. Assim, uma pessoa que começasse hoje, com visão um pouco mais aguda, poderia rapidamente ultrapassá-la. A diferença fundamental é que no Mercado Financeiro não se aprende nada útil nos livros ou cursos. As técnicas ensinadas não servem para nada. O único jeito é estudar as propriedades do Mercado e descobrir por si como as coisas funcionam.

No campo de IA não é assim. Alguém com 30 anos de experiência tem algumas vantagens importantes, mesmo que não tenha inventado ou descoberto nada, porque como a bibliografia disponível é boa e confiável, nesses 30 anos ela pode ter aprendido muita coisa útil a partir dos livros. Por outro lado, os avanços são muito rápidos e os conhecimentos se tornam obsoletos em poucos anos. Alguém que tivesse estudado por 30 anos, de 1985 a 2015, e ficassem parado, sem adquirir novos conhecimentos, de 2015 a 2020, estaria em desvantagem em comparação a alguém que tivesse ingressado na área em 2015 e estudado até 2020. Isso, claro, supondo aptidões semelhantes e habilidades gerais semelhantes nas duas pessoas.

A pessoa que começou em 1985, mesmo que não tivesse parado em 2015 e tivesse continuando estudando e se atualizando até 2020, ainda assim é incerto se em 2020 estaria mais bem preparada que a pessoa que começou em 2015, porque o volume de conhecimento anterior a 2015 agregaria pouco, e se a pessoa que começou em 2015 fosse um pouco mais jovem ou tivesse alguma vantagem cognitiva ou epistemológica, já seria suficiente para que seus 5 anos de experiência fossem mais relevantes que os 35 da outra.

Embora eu esteja ingressando tardiamente nessa área, creio que haja perspectivas promissoras. Além disso, não estou começando totalmente do zero. Minha experiência com o desenvolvimento do Saturno V, embora seja pífio sob o ponto de vista de programação, tem grande valor sob o ponto de vista das investigações que levaram ao desenvolvimento da estratégia e todos os processos relacionados, por isso a experiência adquirida nesse processo é reaproveitável.

Uma das possibilidades que me parece promissora a curto prazo consiste em usar diferentes versões do Saturno V, que produzam excelentes resultados em trechos específicos do histórico, mas não fiquem ruins no restante do histórico, para gerar trechos de treinamento com pontos de entrada e saída promissores. Por exemplo: a versão A fica muito bem entre 1986 e 1995, com 75% ao ano, mas não tão bem no restante do histórico, com média 17% ao ano. A versão B fica muito bem de 1995 a 1998, com 82% ao ano, mas não tão bem no restante do histórico, com média de 19% ao ano. E assim por diante, até cobrir todo o histórico de 1986 a 2021. O uso combinado dessas versões não produziria uma vantagem muito grande em comparação ao uso de apenas uma versão que funcione bem de 1986 a 2021, digamos, com 35% ao ano, porque embora ela fique muito bem em momentos específicos, não fica tão bem nos outros trechos. Além disso, o número de parâmetros utilizados pelo Saturno não possibilitaria chegar a uma configuração suficientemente versátil para que fique muito bem no histórico inteiro, com, digamos, 60% ao ano, e não seria simples fazer alterações na estratégia de modo a introduzir novos parâmetros úteis. Na verdade, introduzir 1 parâmetro útil já demandaria um tempo imenso, e exigiria testar milhares de parâmetros aparentemente promissores até encontrar algum realmente útil.

Mas com uma abordagem diferente, seria possível combinar essas versões que ficam bem em diferentes períodos, sem ser forçado a levar junto os trechos ruins do restante do histórico. Isso pode ser feito da seguinte forma: Os trechos bons são recortados e “costurados”, formando um histórico de 1986 a 2021 contendo exclusivamente os trechos com resultados mais favoráveis de cada versão. Em seguida, um sistema de IA baseado em deep learing é treinado para criar uma rede neural cujos critérios de entrada e saída sejam capazes de reproduzir muito aproximadamente os pontos de entrada e saída reunidos nesses trechos costurados. Não ficarão idênticos, mas ficarão, digamos, 90% semelhantes, com o detalhe que não terá as partes ruins do histórico. Além disso, a estratégia subjacente será completamente diferente da estratégia do Saturno. Apenas terá pontos de entrada semelhantes, mas os critérios utilizados para chegar a essas mesmas decisões serão muito diferentes, muito mais sofisticados e possivelmente mais versáteis.

Desativando os switches, o Saturno V fica com 100 a 200 parâmetros a serem otimizados. Se não desativar, o número é muito maior, mas são muito redundantes, por isso pode-se dizer que há entre 100 e 200 parâmetros não muito redundantes. Um sistema como o descrito acima pode ter centenas de milhares de parâmetros ou mesmo milhões de parâmetros. Com isso se consegue uma flexibilidade muito maior, mas também aumenta o risco de overfitting.

Em todos os sistemas, sempre há certa dose de overfitting, por isso os resultados fora do intervalo de otimização quase sempre ficam um pouco piores num intervalo diferente. Isso é natural e não representa um problema em si. O problema só acontece quando o overfitting é tão grande que os resultados fora do intervalo de otimização ficam muito diferentes, a tal ponto que praticamente inutilizam a estratégia. Nesse caso, a expectativa é de que haverá um pouco de overfitting, mas o impacto provocado será provavelmente menor do que o aumento na performance, resultando num aumento líquido bastante substancial, não apenas na performance, mas também na estabilidade.

Uma das dificuldades no Saturno V é otimizar os parâmetros de adaptabilidade. Isso geralmente requer fazer otimizações, comparar os resultados e alterar manualmente vários desses parâmetros. Mas com um sistema baseado numa arquitetura diferente, os parâmetros de adaptabilidade passam a ser otimizados automaticamente e em conjunto com os demais parâmetros. Na verdade, tornam-se indistintos os parâmetros de adaptabilidade e os parâmetros da própria estratégia. Tudo é otimizado em conjunto de maneira mais sinérgica e harmoniosa.

Outra dificuldade é testar novas alterações na estratégia de forma suficientemente rápida e variada. A cada nova ideia de alteração, ela precisa ser implementada, o que já demanda algumas horas ou dias, depois precisa ser executada algumas centenas ou milhares de vezes, comparar com a estratégia anterior, o que leva mais alguns dias. Com esse sistema o processo muda completamente, e cada novo teste já é baseado numa estratégia ligeiramente diferente, e o conjunto de todas as modificações são comparados entre si de forma “automática” e ponderada. Há algumas desvantagens nisso, porque não se consegue “enxergar” os critérios que estão sendo utilizados, nem compreender o que está ocorrendo quando os dados atravessam as “camadas ocultas”, de modo que não se consegue mais fazer intervenções humanas para aprimorar algo, pois toda a estrutura se torna ininteligível.

Na estrutura atual do Saturno V, se quiser forçar as operações a serem um pouco mais longas, ou muito mais longas, ou se quiser alargar ou estreitar os stops, é relativamente fácil saber quais parâmetros precisam ser modificados para isso e quanto devem ser modificados para produzir o efeito desejado. Mas com o novo sistema isso não é impraticável, porque em vez de haver 1 ou 2 ou 5 parâmetros que determinam o tamanho das operações, na nova situação praticamente todos os parâmetros combinados é que determinam o tamanho das operações, assim como todas as demais características são determinadas pelo entrelaçamento de todos os parâmetros. Além disso, o número de parâmetros se torna muito maior. Por isso, de certo modo, perde-se o controle sobre o que está acontecendo com os dados que entram, são processados e geram determinado refeito. Pode-se conhecer os efeitos produzidos, mas não há como saber quais foram os processamentos nos dados de entrada que conduziram aos resultados observados. Acho isso um pouco desconfortável, sob o ponto de vista conceitual, mas quando se considera sob o ponto de vista prático, essa mudança deve trazer ganhos nas performances, redução nos riscos e melhora na estabilidade.

A ideia a longo prazo ainda não é essa. É um pouco “pior” sob o ponto de vista conceitual, e melhor sob o ponto de vista prático. No fim das contas, não nos interessa tanto compreender os princípios físicos e matemáticos que permitem a um avião voar. O que nos interessa é que ele pode nos transportar com rapidez, conforto e segurança. Nesse contexto, entre uma aeronave mais simples, como um monomotor ou um ultraleve – que tem menos segurança, menos conforto e menor velocidade – ou um avião a jato de alta tecnologia, que não compreendemos tão bem como ele funciona, mas sabemos – pelos resultados experimentais – que ele é superior ao outro nos quesitos que nos interessam, é natural preferir o melhor, ainda que tenhamos uma compreensão menos completa sobre como ele funciona em nível mais fundamental de sua estrutura e na interação de sua estrutura com o meio no qual ele opera.

A longo prazo, a ideia é um sistema totalmente novo e desenvolvido a partir do zero. Mas isso demandará um tempo considerável. No caso de AlphaZero, levou cerca de 9 horas de treinamento, mas utilizou milhares de GPUs. Com um equipamento de menor poder de processamento, levaria meses ou anos. Mas se partir de um sistema pronto que já produz bons resultados, em vez de partir do zero, o tempo de processamento é reduzido a um patamar razoável. Com isso, pode-se usar o que o Saturno V já “sabe” para transmitir ao novo sistema os “conhecimentos” do Saturno V sobre como ele deve proceder, em vez de o novo sistema começar a aprender do zero. Além disso, o aprendizado não precisa partir de uma versão específica do Saturno. Pode partir de uma combinação das melhores versões do Saturno em cada cenário específico. O próprio sistema já pondera como deve ser o uso ótimo dessas várias versões combinadas.

O histórico gerado pela combinação de trechos promissores de diferentes versões do Saturno, bem como o histórico gerado pelo sistema de IA, ambos podem ser usados para alimentar o sistema baseado em MuZero, que partirá daí e melhorará progressivamente essa estratégia. MuZero estaria sendo sub-utilizado, porque ele poderia começar a aprender do zero, em vez de partir de um conhecimento pronto, mas levaria muito mais tempo para chegar a resultados expressivos se começasse do zero. Portanto essa será uma solução de curto prazo, mas não é a melhor solução. Numa etapa posterior, o sistema será treinado a partir do zero, evitando “vícios” que provavelmente estão presentes na estratégia do Saturno e, com isso, deve alcançar performances substancialmente maiores, porém demorará mais tempo até que os bons resultados comecem a ser obtidos. Por isso a combinação das soluções me parece a mais promissora nesse momento, pois combina resultados promissores a curto prazo e excepcionalmente promissores a médio e longo prazo.

As estimativas preliminares eram de que seria possível ter algo operante em 6 meses, porque haveria uma equipe altamente capacitada trabalhando nisso. Com o fechamento do fundo e a dissolução dessa equipe, as estimativas foram revisadas para 2 anos. Agora as novas perspectivas voltaram a ser bastante promissoras e provavelmente em menos de 6 meses já teremos os primeiros resultados concretos sobre isso. Com o detalhe que em 6 meses não estaremos apenas aplicando o que já se conhece e se utiliza, mas sim implementando várias melhorias nos recursos tradicionalmente utilizados, e algumas inovações relevantes, porque embora as ferramentas disponíveis sejam poderosas e muito interessantes, há também vários erros já detectados e ampla margem para aprimoramentos.

Para exemplificar, citarei apenas mais uma falha relativamente grave no uso típico de redes neurais, cuja imagem já diz muito sobre o problema de modelagem, e num próximo artigo analisarei esse caso com mais detalhes. A imagem é esta:

05_.png


Os detalhes serão comentados em breve, num artigo exclusivo sobre esse tema.

A falha que será analisada agora é no Stockfish 14.1, o melhor programa de Xadrez do mundo e várias vezes campeão mundial. No arquivo “types.h”, que pode ser baixado em https://github.com/official-stockfish/Stockfish/archive/refs/tags/sf_14.1.zip, pode-se encontrar esse trecho (imagem abaixo), a partir da linha 180:

06.png


Não é necessário programar em C++ para entender o problema. O que o código acima aborda são os pesos relativos das peças e os critérios sobre como esses pesos devem mudar. Nos programas mais antigos, geralmente se utiliza peso 1 para o Peão, 3 para o Cavalo, 3.25 ou similar para o Bispo, 5 para a Torre e 9.5 para a Dama. Há ligeiras variações de um programa para outro, mas não se afasta muito disso e esses pesos são fixos para a partida inteira. Com o passar dos anos, começaram a testar o uso de pesos diferentes para a fase de abertura, meio-jogo e final, e constataram que isso produz um ganho de performance. Então todos os principais programas do mundo começaram a adotar isso, inclusive Stockfish. Mas há um erro relativamente básico nisso, e continuam repetindo esse erro há mais de 10 anos.

Na verdade, há mais de um erro nessa situação. O primeiro é que não faz sentido atribuir valores {a, b, c, d, e} para as peças até que a soma do peso total de peças sobre o tabuleiro fique menor que z, e então abruptamente alterar esses valores para {a1, b1, c1, d1, e1}, como se, um instante para o outro, o jogo deixasse de ser meio-jogo e se transformasse num final, como se cruzasse uma fronteira e a jurisdição mudasse completamente. Não é assim. Não faz sentido atribuir peso 126 ao Peão enquanto o material sobre o tabuleiro fica entre 15.257 e 3.915, então o material passa para 3.914 e repentinamente o Peão começa a valer 208. As mudanças de 15.257 até chegar em 3.914 não afetaram em nada o valor do Peão, mas a mudança de 3.915 para 3.914 altera dramaticamente o valor do Peão em 65%.

Pode parecer surpreendente que algo tão óbvio não foi corrigido até hoje. Talvez porque não seja óbvio. Apenas parece óbvio depois que o problema é apontado, acompanhado de uma descrição e de uma solução. A maioria dos problemas parece fácil depois de resolvidos. Se fosse óbvio, a equipe de 190 cientistas da computação que trabalham no projeto provavelmente já teria corrigido, sobretudo quando se considera que a esmagadora maioria das mudanças que fazem no código diariamente não afeta praticamente nada, e essa seria uma alteração tremendamente impactante.

Uma maneira mais correta de modelar esse problema seria respeitando o fato de que há um processo gradual em que a posição vai paulatinamente evoluindo, deixando de ter características de abertura e passando a ter cada vez mais características de meio-jogo, sendo sempre uma mistura das três coisas (abertura, meio-jogo e final) em diferentes proporções, e estas proporções vão se modificando ao longo da partida. Por isso não deveria haver uma mudança brusca nos valores das peças. Deveria usar uma função suave na qual gradualmente os pesos das peças fossem sendo modificados conforme o material sobre o tabuleiro fosse diminuindo. Isso tornaria as avaliações das posições muito mais acuradas.

Outro erro é que os valores das peças não deveriam mudar juntos nem no mesmo ritmo. Uma Torre vale pouco mais que um Bispo no início do jogo, porque ela tem pouca mobilidade, não pode ser ativada rapidamente para cooperar com as demais peças, depois ela passa a valer muito mais que um Bispo no meio-jogo, e nessa transição ela ganha bastante em valor relativo, mas do meio-jogo para o final, não há muita diferença, portanto a curva que deveria representar a atualização das forças relativas deveria contemplar essas características e tratar individualmente cada peça, conforme suas particularidades. O ritmo em que o peso do Bispo varia ao longo da partida não é igual ao ritmo que o peso da Torre varia. Casa peça tem seu próprio ritmo de variação, e esse ritmo pode acelerar ou desacelerar em momentos específicos. Isso seria bem fácil e rápido de implementar, o custo de processamento com isso também seria baixíssimo, enquanto o ganho em qualidade de análise e performance seria substancial.

Há mais erros nesse pequeno trecho de código, como tomar como base o peso total sobre o tabuleiro como único critério, quando deveria levar em consideração outros fatores, entre os quais a estrutura de Peões. Mas a descrição feita até aqui já proporciona uma ideia sobre o tipo de erro relativamente básico que se está cometendo na área.

Vale destacar que o Xadrez tem sido, desde os anos 1950, um dos principais recursos para pesquisa de desenvolvedores de sistemas de inteligência artificial, ou até o principal recurso. E Stockfish é desenvolvido por uma equipe de 190 programadores de vários países, muitos dos quais são livres docentes, professores eméritos, pesquisadores destacados na área de Ciência da Computação, Aprendizado de Máquina e Inteligência Artificial, portanto estão entre protagonistas mundiais nesse campo. A lista completa dos colaboradores pode ser encontrada no arquivo “authors.txt” no link citado acima.

Eles aplicam diversos recursos de ponta, como sistema MCTS para podar ou ramificar a árvore de buscas, utilizam redes NNUE para avaliar as posições e decidir quais os melhores lances em cada posição etc. De que adianta usar todos esses recursos, se falham na simples tricotomia de uma variável que deveria assumir valores contínuos? A resposta é que adianta muito, e estão fazendo um excelente trabalho, porém poderia ser muito melhor se evitassem vários erros que estão cometendo, alguns primários, outros sutis e complexos. Escolhi esse trecho do código para analisar por ser mais didático e não exigir praticamente nenhum conhecimento para que se possa enxergar o problema apontado e compreender suas consequências.

O problema central é que geralmente eles utilizam tecnologias muito sofisticadas, mas não compreendem os princípios subjacentes, ou compreendem de forma muito superficial, apenas o suficiente para operacionalizá-los. Outro problema é que eles não têm uma visão suficientemente profunda e completa da situação na qual o problema está inserido e não sabem com clareza o que estão tentando resolver, eles não se fazem as “perguntas certas”, que os ajudaria a dar respostas que pudessem levá-los a avançar mais rapidamente e consistentemente com o desenvolvimento. Tanto é que Larry Kaufman, aos 74 anos de idade e trabalhando em conjunto com Mark Lefler, tem se mantido em pé de igualdade com seu programa Dragon-Komodo, praticamente tão forte quanto Stockfish, com 3516 de rating contra 3546 de Stockfish (veja lista de rating CCRL: https://ccrl.chessdom.com/ccrl/4040/)
Kaufman foi um dos melhores jogadores do mundo e é uma pessoa extremamente lúcida e talentosa, Mark Lefler também é um pesquisador destacado na área e seus artigos técnicos são fontes de pesquisa inclusive para os desenvolvedores de Stockfish, que se beneficiam com as ideias dele para aprimorar o programa que desenvolvem. Há algumas falhas nos artigos de Kaufmann e Lefler, entre as quais analiso duas delas em meu livro “Xadrez, os 2022 melhores jogadores de todos os tempos, 2 novos métodos para cálculo de rating”, que será publicado nas próximas semanas. Mas em geral os textos e Lefler e Kaufman são mais profundos e mais corretos que a grande maioria desse gênero.

Além de Kaufman e Lefler trabalharem sozinhos, eles dispõem apenas de equipamento caseiro para seus testes e otimizações, enquanto a equipe de 190 programados que trabalha em Stockfish dispõe de numerosas máquinas para testar e selecionar as configurações mais promissoras, inclusive muitos deles trabalham em universidades e empresas de tecnologia que colocam à disposição seus mainframes em períodos ociosos para serem utilizados no desenvolvimento de Stockfish. Mesmo nessa situação de extrema desvantagem, Lefler e Kaufman têm mantido seu programa Komodo praticamente no mesmo nível de Stockfish, inclusive sagrando-se tetra-campeão mundial em 2016, 2017, 2018 e 2019, à frente de Stockfish e muitos outros concorrentes. Com isso, chegamos a outro ponto que acho importante comentar.

Uma questão que já foi analisada em artigo de 2011, mas que convém relembrar e atualizar é sobre uma pessoa sozinha competir com gigantes da Tecnologia, como Google, Microsoft ou IBM. Em 1999 foi promovido um evento singular no qual Kasparov jogou sozinho contra 250.000 oponentes. O nome do evento foi “Kasparov contra o resto do mundo”, e ele venceu. Entre os representantes do “resto do mundo” não estavam incluídos o segundo melhor, o terceiro melhor etc., mas o fato é que não faria muita diferente se estivessem. Naquele caso, as decisões dos lances eram por votações, mas também não mudaria muito se adotassem qualquer outro critério. Por exemplo: se fosse um fórum no qual todos os jogadores pudessem opinar, argumentar e decidir os melhores lances.

Uma situação análoga ocorreu em 1995, quando o programa Fritz 3, rodando num simples Pentium 90 MHz, foi campeão mundial de computadores, tendo entre seus adversários o Star Socrates II, desenvolvido pelo MIT, com 1864 pares de processadores Intel Paragon, com capacidade de processamento cerca de 4000 vezes maior, além de ter sido desenvolvido pela equipe do MIT, com amplos recursos monetários e tecnológicos, enquanto o Fritz foi desenvolvido tão somente por seu criador Frans Morsch e seu colaborador Mathias Feist. Além do Star Socrates II, o evento também contou com a participação de Frenchess, desenvolvido pela Commissariat a l'Energie Atomique da France, com 128 co-processadores Alpha e outros mainframes. E esse caso não é exceção. A qualidade de jogo do Fritz 3 era claramente superior à dos programas desenvolvidos pelas grandes equipes de universidades e centros de pesquisa, a tal ponto que mesmo rodando em hardware muito mais modesto, obteve resultados melhores.

O supercomputador da IBM DeepBlue, por exemplo, registrado no Guinness Book de 1998 por ter sido o primeiro a vencer um campeão mundial humano num match em ritmo clássico de jogo, desenvolvido por uma equipe de especialistas e assessorados por grandes jogadores contratados para prestar consultoria no projeto, ajustando seu rating ao poder de processamento, não ficaria sequer entre os 10 melhores programas do mundo da época, cada um dos quais desenvolvido por apenas 1 pessoa, eventualmente por uma dupla.

Portanto, embora haja vantagem em dispor de farto equipamento e de recursos, esses não são os fatores determinantes. O Saturno, por exemplo, embora tenha passado por uma fase recente ruim, ainda acumula resultados muito superiores aos de vários fundos multibilionários, só perdendo para o sistema de James Simons. Há uma frase de Voltaire que poderia ser aplicada nessa situação, com pequenas ressalvas: “comitê é um grupo de pessoas que leva 1 hora para fazer o que uma pessoa sozinha poderia fazer em 15 minutos”. Não é bem assim, depende muito da tarefa a ser resolvida, se puder ser fracionada em partes e se os componentes do comitê forem especialistas para tratar das diferentes partes do projeto, pode-se não apenas resolver mais rapidamente como também chegar a resultados melhores com o trabalho em equipe. Porém quando o comitê se reúne para deliberar sobre alguma questão, muitas vezes os frutos produzidos com a reunião não são melhores do que as soluções que poderiam ter sido formuladas por um dos integrantes trabalhando sozinho.

Depende muito dos problemas a serem resolvidos. Todos os problemas cujas soluções já tiverem sido encontradas e basta colocá-las em prática, a distribuição de tarefas pode ser mais vantajosa quando se trabalha com uma grande equipe, desde que haja sinergia e foco, naturalmente. Mas quando o problema que precisa ser resolvido ainda não possui uma solução e o trabalho consiste justamente em descobrir ou inventar uma solução apropriada, geralmente não há vantagem em ter uma equipe trabalhando nisso, ou a vantagem pode ser muito pequena. Nesse caso específico é diferente de ambas as situações, porque existem problemas que essas equipes estão tentando resolver, e para alguns desses problemas eu já tinha uma solução em 2013 ou 2014. Além disso, há outros problemas sobre os quais essas equipes estão trabalhando, mas que provavelmente não encontraram o caminho promissor, pois se tivessem encontrado já o teriam resolvido, e sobre os quais já tenho uma ideia razoável sobre como deve ser a estratégia de resolução.

A evolução do projeto T continuará a ser divulgada, conforme houver novidades relevantes. Vou gravar um pequeno vídeo para mostrar alguns detalhes que podem ser mais bem descritos dessa forma do que por meio de textos e o link será informado em seguida.