11. Frameworks e Bibliotecas de IA: Redes Neurais e Deep Learning - áudio

Sabe, se olharmos para o código por trás dos sistemas de inteligência artificial mais avançados do mundo hoje, a gente não vai encontrar mágica nenhuma. O que existe, na verdade, e eu fiquei muito impressionada com isso, é uma profunda guerra filosófica sobre quem realmente comanda o show, sabe? Com certeza.

É, tipo, trata-se de uma disputa sobre o fluxo de controle, sobre como os dados se movem e, no fim das contas, sobre quem manda na cozinha, né? Quem escreve o código ou o sistema que o executa. Bem-vindos a mais essa nossa análise aprofundada. Eu sou sua anfitriã e hoje a gente vai mergulhar de cabeça nesse universo.

E essa é uma excelente forma de enxergar a situação logo de cara. Porque a narrativa de que a IA é uma caixa preta, quase mística, ela acaba escondendo o fato de que, na base, existem decisões de engenharia de software que são extremamente pragmáticas. Exato, não tem bola de cristal, né?

Nenhuma. O modo como a gente ensina uma máquina a aprender depende inteiramente da infraestrutura arquitetônica que foi escolhida lá no dia zero do projeto. Certo, vamos desempacotar isso, porque é exatamente essa infraestrutura que a gente vai destrinchar hoje. O nosso material de base para essa exploração é uma apresentação acadêmica super densa, mas muito reveladora, que foi elaborada pelo professor doutor Ivan Carlos Alcântara de Oliveira.

Um material excelente, por sinal. Muito bom mesmo. O foco do professor é mapear o ecossistema de redes neurais e deep learning, explorando as ferramentas essenciais que a indústria realmente usa. Então, a nossa missão aqui é decodificar essas ferramentas, indo desde as bibliotecas mais simples até os frameworks massivos.

que são os que sustentam as gigantes da tecnologia hoje, né? Exatamente. Para quem nos ouve, seja alguém da área de tecnologia se atualizando, ou só alguém com muita curiosidade sobre o futuro, entender essas ferramentas é o atalho perfeito para compreender como as IAs modernas são efetivamente construídas. Não é só teoria, é a prática da coisa.

E o que torna o material do professor Ivan tão rico é que ele não fica simplesmente listando softwares. Ele constrói uma linha de raciocínio que começa com a primeira encruzilhada que qualquer projeto de machine learning enfrenta. Qual encruzilhada seria essa? A escolha do paradigma de controle. E isso nos leva direto para aquele debate clássico da engenharia de software, que é a diferença entre usar uma biblioteca ou usar um framework.

Essa distinção é fundamental e, nossa, muitas vezes ela é totalmente ignorada. Segundo o material, uma biblioteca tipo o Scikit-Learn, o NumPy ou o Pandas é um conjunto de funções e classes reutilizáveis onde o desenvolvedor tem total controle do fluxo do programa.

É a chamada abordagem imperativa clássica. Isso. O código dita exatamente quando os dados são carregados, quando a função de treinamento tipo um FIT ou PREDICT é chamada. A biblioteca é super reativa, ela só se move quando recebe uma ordem explícita sua. Mas, por outro lado, quando a gente entra no território dos frameworks tipo TensorFlow, a dinâmica sofre um giro de 180 graus.

Entra em cena o que a gente chama de inversão de controle. Inversão de controle, como assim? É que um framework já possui uma arquitetura de controle própria embutida nele.

Então ele edita o ciclo de vida da aplicação. O desenvolvedor não chama o framework na hora que quer, sabe? É o framework que chama o código do desenvolvedor e ele exige que você se adapte ao modo de pensar dele. Nossa, o professor usa uma analogia culinária no texto para ilustrar isso e eu acho que vale muito a pena a gente expandir essa ideia aqui.

A analogia da cozinha é muito boa. É incrível. Usar uma biblioteca seria como estar em uma cozinha super bem equipada. O cozinheiro tem ferramentas de ponta, claro, mas ele decide exatamente quando cortar os legumes, quando ligar o forno, quando servir a refeição. O fluxo todo é ditado pelo chefe. Perfeito. E usar um framework nessa mesma lógica.

Como participar de um reality show de culinária, sabe? Daqueles com regras mega estritas. O formato do programa diz quando as coisas devem acontecer. A etapa de corte dura 10 minutos. A do forno vem em seguida. E o competidor apenas preenche as lacunas com seus ingredientes dentro daquele cronograma rígido. Essa imagem mental é perfeita. O ambiente dita o fluxo.

Mas espera aí, vamos analisar isso de forma crítica. Então, o que tudo isso significa na prática? Um framework não acaba restringindo a criatividade do desenvolvedor ao impor um fluxo tão rígido assim? Ah, o que é fascinante aqui é que essa restrição, essa inversão de controle é, na verdade, o maior superpoder do framework. Sério? Um superpoder?

Com certeza. Ao impor uma estrutura rígida, o framework tira um peso absurdo das costas do desenvolvedor. Ele gerencia o básico, o fluxo de dados, a alocação de memória. Ah, então a pessoa não precisa reinventar a roda estrutural a cada projeto.

Exatamente. Isso permite que a atenção seja totalmente focada em escalar redes neurais complexas. Sem esse controle do framework, fazer isso manualmente seria quase impossível em larga escala. Faz todo sentido. É uma troca de liberdade por poder de escala, né? Isso nos leva a uma segunda camada de decisão, que o texto aborda logo em seguida.

Se a escolha entre biblioteca e framework define quem manda na cozinha, o tipo de execução define como a receita é lida. Essa é uma bifurcação crucial no design de redes neurais. Sim, o famoso debate entre execução estática e dinâmica. O define and run contra o define by run. Aqui é que a coisa fica realmente interessante.

É a distinção que mais dividiu a comunidade de IA nos últimos tempos. Vamos começar pela execução estática, ou Define and Run. Ela tem raízes lá na eficiência computacional pura. Tá, e como ela funciona na prática? Nesse paradigma, a rede neural é definida inteiramente como um grafo completo, que é, digamos assim, congelado e compilado antes do treinamento se quer começar. É menos flexível, mas é extremamente eficiente.

Deixa eu tentar visualizar isso com outra analogia. A execução estática seria como um projeto arquitetônico, desenhado por completo antes do engenheiro assentar o primeiro tijono da obra. Isso. A planta já está toda aprovada e não muda.

Certo. E aí do outro lado a gente tem a execução dinâmica, o Define by Run, que é como montar blocos de Lego. Você vai ajustando e mudando de ideia durante a construção, em tempo real. A cada forward pass, a cada passagem para frente dos dados, a rede é redefinida. É super flexível e usa código Python bem natural, o que facilita demais a vida de quem está programando.

Frameworks como PyTorch e FastAI usam isso. Mas espera, eu preciso apertar você nessa questão. Se o modelo estático, como as versões iniciais do TensorFlow e o Psych2Learn, é muito mais eficiente globalmente e permite usar aceleradores de hardware incríveis, como as TPUs do Google, por que alguém escolheria um método dinâmico que, teoricamente, é menos eficiente?

Ah, se conectarmos isso ao quadro geral, a gente percebe que a eficiência de máquina não é a única métrica que importa no fim do dia. A eficiência humana também conta, e muito. Ah, o tempo e a sanidade do programador, né? Exato. Debugar ou consertar erros num grafo estático congelado pode ser um verdadeiro pesadelo.

Os erros só aparecem na execução final do grafo e muitas vezes não apontam para a linha de código original. Caramba, deve ser frustrante. Muito. Já a execução dinâmica permite que cientistas e pesquisadores modelem lógicas condicionais complexas usando coisas simples tipo print ou breakpoints, consertando erros em tempo real. É um ambiente perfeito para pesquisa e inovação rápida.

Troca-se um pouco de processador por menos dor de cabeça humana. Adorei. Bom, compreendendo essa teoria estrutural, acho que é hora de dar nomes aos bois, né? O mercado já consolidou algumas ferramentas principais e o material do professor Ivan detalha o perfil dos três grandes titãs da área. E é importante entender aonde cada um brilha. Temos o Scikit-Learn, o TensorFlow e o PyTorch.

Vamos começar pelo Scikit-Learn, então. Pelo que eu vi, é uma biblioteca focada em Machine Learning tradicional, certo? Execução toda em CPU, não usa placa de vídeo, GPU... Exato. Ele suporta apenas modelos mais simples, tipo os Perceptons Multicamadas, ou MLP. É ideal para dados tabulares clássicos. A grande vantagem é que a curva de aprendizado é muito baixa. Qualquer um pode começar rápido.

Certo, e aí a gente pula para os gigantes do Deep Learning, o TensorFlow, que foi criado pelo Google Brain e virou open source lá em 2015. É um framework híbrido, capaz de usar CPU, GPU e TPU. Pelo que o texto diz, é o gigante da indústria para colocar modelos complexos em produção em larga escala, né?

Sim, quando uma empresa precisa rodar IA para milhões de usuários simultâneos, o TensorFlow é geralmente a ferramenta de escolha pela robustez.

E do outro lado do ringue, a gente tem o PyTorch, criado pelo Facebook AI Research, atual meta, que virou open source em 2016. Altamente dinâmico, flexível, o texto chama de queridinho da pesquisa acadêmica. E ele é mesmo o favorito de quem faz P&D, justamente por causa daquela execução dinâmica que a gente acabou de falar. Além deles, o texto ainda menciona várias alternativas interessantes. Sim, anotei algumas aqui.

Tem o Jax, que traz uma matemática super rápida do Google. O Keras, que eu achei curioso porque agora ele funciona como uma API de alto nível do TensorFlow para deixar ele mais fácil, né? O Keras abstrai muita coisa difícil do TensorFlow. E ainda temos o Fast AI, que é ótimo para o ensino e é construído em cima do PyTorch. O Onyx, para a inferência cruzada entre plataformas. E o Deep Learning 4J, super focado no ambiente corporativo usando Java e Scala.

Nossa, é um ecossistema gigantesco. Mas olhando para esse cenário, me vem um ponto na cabeça. A gente tem a ferramenta do Google de um lado, que é o TensorFlow, e a da Meta do outro, o PyTorch. Será que a escolha das empresas por um ou outro se baseia apenas numa guerra corporativa ou em torcida por grandes marcas? Olha, isso levanta uma questão importante, porque muita gente de fora pensa que é briga de torcida.

Mas a escolha via de regra raramente é sobre lealdade corporativa. É uma decisão técnica sobre o objetivo final do projeto. Como assim? Depende do que a pessoa quer construir. Exato. Se o objetivo é fazer um teste rápido de classificação num banco de dados simples, você usa o Psychit Learning. Agora, se o objetivo é criar um pipeline super robusto para servir milhões de usuários diários de um aplicativo, o TensorFlow brilha de forma indiscutível.

Entendi. E o PyTorch? Se o objetivo é ir para o laboratório e inventar uma arquitetura de rede neural que nunca existiu antes, testar ideias malucas, a flexibilidade do PyTorch é incomparável. Você não quer a rigidez do TensorFlow atrapalhando a sua pesquisa. Perfeito.

Chega de teoria, né? Como essas diferenças arquitetônicas se manifestam quando a gente realmente precisa escrever código na tela? O material ilustra isso de um jeito muito didático com a prova dos nove. É um problema clássico usando o dataset Iris.

Ah, o íris é o Hello World da inteligência artificial. É. Para quem não conhece, a missão ali é classificar três espécies de flores. A cetosa, a versicolor e a virgínica. E para isso, a máquina usa quatro atributos morfológicos. O comprimento e a largura das pétalas e das sépalas.

E o professor Ivan mostra como as três ferramentas resolvem exatamente a mesma tarefa. A diferença de código entre elas é gritante e revela muito da filosofia de cada uma. Totalmente. Vamos para a batalha do código. Começando pela abordagem do Scikit-Learn. Gente, é de uma simplicidade extrema. É muito direto ao ponto.

Muito! Você apenas chama o MLP Classifier, define lá uma camada oculta com 10 neurônios, coloca 500 iterações máximas e pronto! Roda o Fit para treinar e o Predict para testar. Fim! É o supra-sumo da conveniência. A biblioteca esconde toda a matemática complexa de você.

Sim, mas aí a gente olha para a abordagem do TensorFlow e, uau, a coisa fica muito mais estruturada. Primeiro, ele exige a conversão de todos os dados em matrizes de tensores usando o TF.constant. Ele é rígido com os tipos de dados desde o começo.

Pois é. Aí ele usa um modelo chamado sequential, onde você vai empilhando camadas do tipo dense. Ele usa aquela função de ativação relo, né? Isso, a relo é super comum para ativar os neurônios nessas camadas ocultas. E o mais doido é que exige uma compilação prévia. Você tem que definir explicitamente o otimizador, no caso ele usa o Adam, e a função de perda, que tem aquele nome enorme, sparse categorical cross entropy.

Essa fase de compilação é justamente a execução estática brilhando. Ele está congelando o grafo. E tem um detalhe crucial no código do TensorFlow que o professor destaca. O parâmetro verbose igual a zero durante o fit de 30 épocas. Basicamente, significa um treinamento silencioso, sem imprimir atualizações na tela a cada época. E no final, as previsões são extraídas via tf.argmax.

É um código que tem cara de produção. Ele quer ser rápido e viciente e rodar de forma silenciosa.

Certo. E aí chegamos na abordagem do PyTorch. E caramba, é controle e detalhamento total. O programador precisa literalmente criar uma classe no Python que herde funções do NNModule. Você tem que definir explicitamente as camadas lá, FC1, FC2. E não para por aí. O fluxo dos dados, o caminho que a informação faz, é construído manualmente dentro de uma função chamada ForwardX.

É tudo muito manual. O laço de treinamento por 100 épocas é exposto linha por linha na tela. Tem que zerar os gradientes, chamando zero grade, fazer o passe adiante, calcular a perda com o criterion.

Sim, e a parte mais importante. Tem que retropropagar os erros chamando o backward e só então atualizar os pesos dos neurônios com o STEP. É quase exaustivo só de falar. E na hora de testar, ainda tem que usar o TORT.nograd para desativar os gradientes e economizar recursos do computador.

Certo. Vamos desempacotar isso com mais uma analogia, porque eu preciso traduzir essas linhas de código para a vida real. Manda ver. O Scikit-Learn parece ser como pedir comida em um aplicativo. Você só clica no botão e o prato chega pronto, quentinho. Uhum. Você não sabe nem quem cozinhou. Você segue o manual passo a passo, compila os ingredientes e sai um jantar excelente. E o PaiTorch.

O Pai Torche? Ah, o Pai Torche é literalmente cultivar os ingredientes no quintal, caçar o próprio jantar no mato e cozinhar do zero no fogo a lenha. Nossa, essa foi muito boa. E sabe o que é fascinante aqui? É como esse laço explícito do Pai Torche que você descreveu expõe o verdadeiro batimento cardíaco do aprendizado de máquina. O batimento cardíaco? Gostei dessa imagem.

Sim, porque enquanto no Skype Learn o método de aprendizado fica totalmente oculto debaixo dos panos, no PyTorch, com aquele comando backward, nós vemos exatamente onde a máquina percebe o seu próprio erro e decide mudar. Nós vemos a retropropagação acontecendo. É um portal direto para entender a matemática real da inteligência artificial. Isso é muito poderoso para quem está pesquisando, né? Colocar a mão na massa matemática da coisa.

Bom, ao longo dessa nossa análise detalhada hoje, a gente realmente desbravou as fundações do desenvolvimento de IA. Foi uma jornada e tanto pelo ecossistema. Foi sim. A gente navegou pelo grande debate entre as conveniências práticas das bibliotecas e o poder estrutural impositivo dos frameworks. A gente também entendeu as dores e os ganhos da execução estática versus a dinâmica.

E fechamos vendo na prática como o Scikit-Learn, TensorFlow e PyTorch lidam de jeitos tão diferentes com a mesma tarefa simples de classificar flores.

Foi incrível ver como o código reflete a filosofia de cada um. E para quem nos escuta, fica uma mensagem clara. Da próxima vez que um aplicativo de rota sugerir um caminho super rápido ou que o celular reconhecer um rosto numa foto, vocês vão saber que por trás daquela suposta mágica existe uma escolha mega cuidadosa de arquitetura de código. Com certeza.

Uma decisão humana de engenharia. Exato. Seja escolhendo uma fábrica altamente rígida e otimizada, tipo o TensorFlow, ou optando por um laboratório flexível e manual de pesquisa, tipo o PyTorch. Tudo parte de uma decisão de quem sentou no teclado.

A IA só é o que é por causa das ferramentas que a gente construiu para treiná-la. Pois é. Mas para fechar, eu quero deixar uma semente plantada na cabeça da nossa audiência para reflexão contínua. Opa, adoro provocações no final. Com ferramentas como o TensorFlow e o Keras, abstraindo cada vez mais toda essa matemática complexa com soluções de alto nível.

Será que a próxima geração de cientistas de IA vai precisar realmente entender como programar um gradiente descendente do zero ali no fogo à lenha do PyTorch? É uma excelente pergunta. Fica aí o questionamento.

Ou será que o futuro do aprendizado de máquina vai ser muito mais sobre orquestrar grandes blocos pré-fabricados do que escrever código bruto matemático? Fica essa pulga atrás da orelha para uma exploração nossa no futuro. Até a próxima!