Nelson Koshoji

Você não está ensinando IA. Você está ensinando a versão de 2019 da IA.

nelson — Tue, 12 May 2026 01:12:54 +0000

Levei algumas semanas preparando aquela aula.

O tema era geração de texto com redes neurais — um assunto que havia entrado no currículo recentemente, ainda sem material consolidado em português. Pesquisei, organizei, montei os slides. Escolhi os exemplos com cuidado. Estava satisfeito com o resultado.

Na semana antes de dar a aula, um colega me mandou um link com a mensagem: “você viu isso?”

Era o anúncio de um modelo que tornava boa parte do que eu havia preparado — não errado, mas visivelmente desatualizado. A abordagem que eu ia apresentar como estado da arte havia sido superada. Não por anos, não por décadas. Por meses.

Dei a aula assim mesmo, com uma nota de rodapé oral: isso que estou mostrando já foi superado, mas precisamos entender a base antes de entender o que veio depois. Os alunos assentiram. Mas a sensação que ficou — de estar sempre um passo atrás de um campo que corre mais rápido do que consigo acompanhar — não foi embora.

Esse desconforto é, descobri depois, endêmico entre quem ensina IA hoje. E lidar com ele de forma honesta pode ser mais valioso do que fingir que o currículo está em dia.

O problema específico de ensinar um campo em construção

A maioria das disciplinas que ensinamos em computação tem uma estabilidade razoável. Os fundamentos de algoritmos e estruturas de dados que Knuth sistematizou nos anos 1960 ainda são o que ensinamos hoje. Redes de computadores, sistemas operacionais, engenharia de software — os princípios fundamentais mudam lentamente. Você pode preparar um bom curso e ele continua bom por vários anos.

IA não funciona assim. E nos últimos anos, passou a funcionar ainda menos assim.

Entre 2017 e hoje, o campo passou por pelo menos três transformações que cada uma, individualmente, teria sido suficiente para tornar um currículo preparado antes delas parcialmente obsoleto. A arquitetura Transformer, proposta em 2017, mudou radicalmente o estado da arte em processamento de linguagem natural. Os modelos de difusão transformaram geração de imagens a partir de 2020. Os grandes modelos de linguagem treinados com feedback humano mudaram o que entendemos por capacidade de modelos de linguagem a partir de 2022.

Cada uma dessas transformações não apenas introduziu técnicas novas. Mudou o que é considerado abordagem padrão, quais benchmarks importam, quais arquiteturas vale a pena ensinar como ponto de partida.

Um professor que preparou um curso de processamento de linguagem natural em 2016 — com foco em LSTMs e modelos sequenciais — não estava errado. Estava ensinando o estado da arte daquele momento. Dois anos depois, o Transformer tornava boa parte daquele material historicamente interessante mas pedagogicamente secundário.

Isso não acontece em cálculo. Não acontece em física clássica. Acontece em IA — e acontece cada vez mais rápido.

O que fica quando tudo muda

Diante disso, a pergunta que me faço — e que acho que todo professor de IA deveria se fazer — é: o que no meu currículo é realmente estável, e o que é apenas o estado da arte de hoje?

A distinção importa porque o que é estável merece tempo de aula diferente do que é transitório. Ensinar um algoritmo específico que pode ser obsoleto em dois anos tem valor diferente de ensinar o princípio que faz aquele algoritmo funcionar — e que vai continuar relevante independentemente de qual arquitetura domine o campo amanhã.

Na minha experiência, há pelo menos três camadas de estabilidade diferentes num currículo de IA.

A camada dos fundamentos matemáticos. Álgebra linear, cálculo, probabilidade, teoria da informação — esses são os alicerces sobre os quais qualquer avanço do campo é construído. Um aluno que entende profundamente por que gradiente descendente funciona, o que uma função de perda realmente mede, o que significa uma distribuição de probabilidade sobre saídas — esse aluno consegue aprender qualquer arquitetura nova em semanas. Essa camada não envelhece.

A camada dos princípios algorítmicos. Overfitting e regularização. O trade-off entre viés e variância. A importância da separação entre dados de treino, validação e teste. O que significa generalização. Por que mais dados quase sempre ajudam mais do que mais complexidade. Esses princípios foram verdadeiros em 1990 e continuam verdadeiros hoje — independentemente de qual modelo específico você esteja usando. Essa camada envelhece muito lentamente.

A camada das arquiteturas e ferramentas específicas. CNNs, RNNs, Transformers, modelos de difusão, LLMs — essas são as implementações concretas que dominam o estado da arte em determinado momento. São importantes de ensinar porque os alunos vão trabalhar com elas. Mas são exatamente a camada que envelhece mais rápido. Essa camada precisa ser ensinada com uma nota de rodapé permanente: isso é o que funciona melhor agora — não necessariamente o que vai funcionar melhor em cinco anos.

O erro que vejo em muitos currículos — incluindo o meu, nos primeiros meses — é inverter as proporções. Gastar a maior parte do tempo na terceira camada, a mais transitória, e pouco tempo nas duas primeiras, as mais duradouras.

O paradoxo do tutorial

Há um fenômeno que observo nos meus alunos que chamo internamente de paradoxo do tutorial.

Vivemos num momento em que nunca houve tanto material de qualidade sobre IA disponível gratuitamente. Tutoriais, cursos online, documentação, papers explicados em vídeo, implementações comentadas no GitHub. Um estudante dedicado consegue aprender a usar as ferramentas mais modernas em semanas.

O problema é que aprender a usar uma ferramenta não é o mesmo que entender o que ela faz. E a abundância de tutoriais cria uma ilusão perigosa: a de que dominar a sintaxe do framework equivale a compreender o campo.

Vejo alunos que conseguem treinar um modelo de linguagem em cinquenta linhas de código — usando uma biblioteca que abstrai completamente a arquitetura, o treinamento e a avaliação — mas que não conseguem responder por que o modelo falha em certos tipos de entrada, o que as métricas de avaliação realmente medem, ou como modificariam a abordagem se o problema mudasse ligeiramente.

Eles aprenderam a versão de hoje da ferramenta. Não aprenderam a pensar sobre o problema.

Quando a ferramenta mudar — e vai mudar — eles vão precisar aprender tudo de novo, do zero, porque não têm os fundamentos que permitem transferir o conhecimento de um framework para outro, de uma arquitetura para a seguinte.

É um problema de horizonte temporal. Tutoriais otimizam para resultados rápidos. Fundamentos otimizam para adaptabilidade de longo prazo. E num campo que muda tão rapidamente quanto IA, adaptabilidade de longo prazo é a habilidade mais valiosa que um curso pode desenvolver.

O que fazer com a defasagem inevitável

Não tenho uma solução completa para o problema de ensinar um campo em movimento acelerado. Mas tenho algumas práticas que adotei e que parecem ajudar.

A primeira é ser explícito sobre o que é fundamento e o que é estado da arte. Toda vez que apresento uma técnica ou arquitetura específica, digo com clareza: isso é o que o campo usa predominantemente agora — pode não ser o que vai usar daqui a três anos. O que não vai mudar é o princípio por trás. E é no princípio que o tempo de aula deve se concentrar.

A segunda é incluir deliberadamente material histórico. Mostrar como o campo chegou onde está — quais abordagens dominaram em diferentes épocas, por que foram superadas, o que cada transição revela sobre o que o campo havia entendido mal antes — é uma das formas mais eficazes de preparar alunos para as transições futuras que inevitavelmente virão. Quem entende por que as RNNs foram superadas pelos Transformers está melhor preparado para entender o que pode superar os Transformers.

A terceira é admitir publicamente quando não sei. Quando um aluno pergunta sobre uma técnica ou resultado recente que não conheço bem, digo isso. E às vezes peço que o aluno pesquise e apresente para a turma. Um professor que admite os limites do próprio conhecimento num campo em movimento acelerado não está demonstrando fraqueza — está demonstrando o modelo de postura intelectual que os alunos vão precisar adotar para o resto da carreira.

Aquela aula que preparei e que ficou desatualizada antes de dar — dei ela assim mesmo, com a nota de rodapé, e foi uma das melhores aulas do semestre.

Não porque o conteúdo era o mais atual. Mas porque a situação criou uma conversa real sobre o que significa aprender num campo que não para. Sobre como avaliar se um conhecimento tem vida útil de meses ou de décadas. Sobre por que entender o mecanismo vale mais do que conhecer a ferramenta.

Nenhum desses temas estava nos meus slides originais.

Às vezes o que o currículo não previu ensina mais do que o que estava planejado.

Próximo artigo: “ChatGPT passou no exame. Isso diz mais sobre o exame do que sobre o ChatGPT.”

O que os meus alunos acham que é uma rede neural — e o que ela realmente é.

nelson — Tue, 12 May 2026 00:59:36 +0000

Todo semestre, antes de começar a aula sobre redes neurais, faço o mesmo experimento informal.

Peço que cada aluno escreva numa folha, em duas ou três frases, o que acha que é uma rede neural. Não vale pesquisar. Só o que já sabe, ou acha que sabe.

Recolho as folhas. Leio em voz alta, sem identificar quem escreveu.

As respostas variam na forma, mas convergem num tema central. Um sistema que funciona como o cérebro humano. Uma rede de neurônios artificiais que aprende como nós aprendemos. Uma simulação do pensamento humano. Alguns alunos vão mais longe: algo que pode desenvolver consciência se ficar complexo o suficiente. Um aluno, numa turma recente, escreveu com toda a seriedade: a primeira etapa para criar vida artificial.

Então mostro o que uma rede neural realmente é.

Uma função matemática. Composta de outras funções matemáticas menores, organizadas em camadas. Cada camada recebe números, multiplica por pesos, aplica uma transformação não-linear, passa o resultado para a próxima camada. No final, sai um número — ou um vetor de números — que representa a saída do modelo.

O silêncio que se segue tem uma qualidade específica. Não é decepção exatamente. É o silêncio de quem está recalibrando a distância entre o que esperava e o que encontrou.

De onde vem a imagem errada

A culpa não é dos alunos. A imagem que eles carregam foi construída cuidadosamente, ao longo de anos, por filmes, séries, noticiários e — é preciso admitir — pela própria forma como o campo se apresenta ao mundo.

“Rede neural” é um nome que evoca biologia. “Neurônio artificial” sugere que estamos reproduzindo algo do cérebro. “Deep learning” — aprendizado profundo — soa como cognição em camadas, como se profundidade matemática fosse profundidade de pensamento. Quando veículos de comunicação publicam imagens de redes neurais, mostram esferas luminosas conectadas por linhas pulsantes, como sinapses num cérebro digitalizado.

Tudo isso é representação, não descrição. E a representação criou uma expectativa que o mecanismo real não sustenta.

A história real é mais simples — e, a meu ver, mais bonita precisamente por ser simples.

O que realmente é um neurônio artificial

Em 1943, Warren McCulloch e Walter Pitts propuseram o primeiro modelo matemático de um neurônio. A ideia era elegante: um neurônio biológico recebe sinais de outros neurônios, soma esses sinais, e dispara — ou não — dependendo se a soma ultrapassa um limiar.

McCulloch e Pitts abstraíram isso para matemática: uma unidade que recebe entradas numéricas, multiplica cada uma por um peso, soma tudo, e aplica uma função que decide a saída. Um perceptron, como Frank Rosenblatt chamaria em 1958.

A analogia com o neurônio biológico era uma inspiração, não uma afirmação. McCulloch era neurocientista e sabia que estava fazendo uma simplificação radical. Um neurônio biológico é um objeto extraordinariamente complexo — com dinâmicas eletroquímicas, plasticidade sináptica, ramificações dendríticas, modulação por neurotransmissores. O neurônio artificial captura uma caricatura minimalista dessa complexidade: entradas ponderadas, soma, limiar.

O que emergiu dessa caricatura, ao longo de décadas de desenvolvimento, foi algo poderoso por razões que nada têm a ver com fidelidade biológica. Quando você empilha muitas dessas unidades simples em camadas e as treina com gradiente descendente sobre grandes volumes de dados, o sistema resultante consegue aproximar funções extraordinariamente complexas. Reconhecer faces em fotos. Transcrever fala em texto. Traduzir entre idiomas. Jogar Go melhor que qualquer humano.

Não porque o sistema pensa. Mas porque aproximação de funções complexas é, surpreendentemente, o que muitos problemas práticos requerem.

O que “profundo” significa em deep learning

Quando o campo adotou o termo “deep learning” para redes com muitas camadas, a palavra “profundo” ganhou uma conotação que não era intencional.

Profundidade, aqui, é arquitetural. Uma rede é “profunda” no mesmo sentido em que um prédio de trinta andares é mais alto que um de três — há mais camadas entre a entrada e a saída. Cada camada aprende a representar o dado em diferentes níveis de abstração: as primeiras camadas de uma rede de visão computacional detectam bordas e gradientes; as intermediárias detectam formas e texturas; as mais próximas da saída detectam estruturas de alto nível como rostos ou objetos.

Isso é genuinamente interessante do ponto de vista de representação de dados. Não tem relação com profundidade cognitiva, filosófica ou consciente.

Mas “deep learning” soa como aprendizado profundo no sentido humano. E esse equívoco tem consequências. Quando um modelo de linguagem produz um texto eloquente sobre sofrimento humano, pessoas treinadas pela metáfora do cérebro digital perguntam se o modelo está sofrendo. A pergunta não é absurda dado o vocabulário — é absurda dado o mecanismo. O modelo está computando distribuições de probabilidade sobre sequências de tokens. A eloquência emergiu do treinamento sobre textos humanos, não de experiência interna.

Por que a diferença importa para quem vai construir sistemas

Um estudante que acredita que redes neurais são simulações do cérebro vai fazer perguntas erradas — e deixar de fazer as certas.

Vai perguntar: quando o modelo vai desenvolver consciência? Em vez de: em que condições esse modelo falha de formas sistemáticas?

Vai perguntar: o modelo está realmente entendendo o problema? Em vez de: o modelo está generalizando bem para exemplos fora da distribuição de treinamento?

Vai perguntar: como o modelo pensa internamente? Em vez de: o que os pesos aprendidos revelam sobre os padrões nos dados?

A primeira família de perguntas é fascinante filosoficamente e quase inútil praticamente. A segunda família é o que permite construir sistemas que funcionam — e identificar quando estão falhando.

Há também uma consequência mais sutil. Quem acredita que redes neurais são análogas ao cérebro tende a atribuir ao modelo uma robustez que ele não tem. Se funciona como um cérebro, deve ser resiliente, adaptável, capaz de lidar com situações inesperadas — como seres humanos são, dentro de certos limites.

Mas redes neurais são profundamente frágeis em formas que cérebros não são. Exemplos adversariais — perturbações mínimas numa imagem, invisíveis ao olho humano — podem fazer um modelo de visão computacional classificar um gato como uma torradeira com alta confiança. Nenhum ser humano faria isso. A fragilidade revela que o modelo não aprendeu nenhuma representação robusta do que é um gato — aprendeu padrões estatísticos que funcionam na maioria dos casos e quebram de formas bizarras em casos que um humano acharia triviais.

Isso não é bug. É consequência direta do que o modelo é: uma função matemática otimizada sobre dados, não um sistema cognitivo com representações do mundo.

O que eu faço com o silêncio depois do experimento

Quando os alunos processam a distância entre o que esperavam e o que encontraram, faço questão de dizer uma coisa:

O mecanismo real não é menos impressionante que a fantasia. É impressionante por razões diferentes — e mais verdadeiras.

É impressionante que uma função matemática relativamente simples, repetida em camadas, seja capaz de aprender a reconhecer tumores em radiografias sem que ninguém tenha programado explicitamente o que é um tumor. É impressionante que o mesmo princípio matemático — ajuste iterativo de pesos para minimizar erro — produza sistemas capazes de traduzir poesia, compor música e prever a estrutura de proteínas que décadas de bioquímica não haviam conseguido resolver.

A impressionante não é a semelhança com o cérebro. É que algo tão simples na concepção seja tão poderoso na escala.

Mas essa admiração só é possível se você vê o mecanismo real. Se você vê apenas a metáfora do cérebro digital, admira uma ficção — e perde a chance de admirar o que realmente está acontecendo.

E, mais importante: perde a chance de entender onde o sistema vai falhar. Porque sistemas que falham de formas que você não previu, em produção, afetando pessoas reais, não são abstrações filosóficas. São consequências de engenheiros que não entenderam o que estavam construindo.

No final da aula em que mostro o que uma rede neural realmente é, sempre há um aluno que pergunta, com uma mistura de alívio e decepção:

— Então é só matemática?

Respondo sempre da mesma forma:

— É apenas matemática da mesma forma que uma sinfonia é apenas vibrações no ar.

A simplicidade do mecanismo não diminui o resultado. Mas você precisa entender o mecanismo para saber o que o resultado pode e não pode ser.

Seu algoritmo é enviesado. Não porque alguém quis — mas porque o mundo é.

nelson — Tue, 12 May 2026 00:56:57 +0000

Tem um exercício que gosto de fazer no início do semestre.

Peço aos alunos que imaginem um sistema de triagem de currículos treinado com dados históricos de contratação de uma empresa de tecnologia. O modelo foi treinado para prever quais candidatos têm maior probabilidade de ser contratados. Os dados abrangem dez anos de processos seletivos. A acurácia é boa.

Então faço uma pergunta: esse modelo é justo?

A maioria dos alunos responde instintivamente que sim — afinal, o modelo apenas aprendeu com dados reais, com decisões humanas reais. Não há nenhuma regra explícita discriminando ninguém. Nenhuma intenção maliciosa. Só matemática.

Então faço a segunda pergunta: e se, nos últimos dez anos, essa empresa contratou predominantemente homens para cargos técnicos?

O silêncio que se segue é o momento em que o problema se torna real.

O modelo não foi programado para discriminar. Ele foi treinado para reproduzir o padrão histórico de contratação. E o padrão histórico de contratação carregava um viés que existia muito antes do algoritmo — no mercado de trabalho, nas desigualdades de acesso à formação técnica, nas dinâmicas sociais que moldaram quem chegou a candidatar aquelas vagas durante uma década. O modelo não criou esse viés. Ele o herdou. E ao reproduzi-lo em escala, com a aparência de objetividade que números conferem, ele o perpetuou.

Isso é viés algorítmico. E começa muito antes do primeiro linha de código.

O viés não está no algoritmo. Está em tudo que veio antes.

Quando o tema de viés em IA aparece na mídia, a narrativa costuma ser binária: ou o algoritmo é neutro e objetivo — afinal, são apenas números — ou foi deliberadamente programado para discriminar por engenheiros mal-intencionados.

As duas narrativas são falsas. E a segunda é particularmente perigosa porque, ao exigir intenção maliciosa como condição para o problema existir, acaba absolvendo a maioria dos casos reais — onde não há intenção alguma, mas o dano é concreto.

O viés algorítmico é quase sempre involuntário. E é quase sempre inevitável quando você treina modelos sobre dados que refletem um mundo historicamente desigual — o que descreve praticamente todos os dados que existem sobre comportamento humano.

O viés entra em pelo menos quatro momentos distintos do processo, e vale examinar cada um.

No momento da coleta. Os dados que existem não são uma amostra aleatória do mundo. São um registro do que foi medido, por quem tinha acesso aos instrumentos de medição, sobre quem estava visível para ser medido. Dados históricos de saúde sobrerrepresentam populações com acesso a serviços médicos. Dados de crédito sobrerrepresentam pessoas que já participaram do sistema financeiro formal. Dados de desempenho acadêmico refletem quem teve acesso a educação de qualidade. Quem não está nos dados não existe para o modelo.

No momento da rotulação. Dados supervisionados precisam de rótulos — alguém ou algum sistema que diga o que é correto. Quando os rótulos são decisões humanas históricas, eles carregam os preconceitos de quem as tomou. Um modelo treinado para prever “bom funcionário” a partir de avaliações de desempenho históricas aprende o que os gestores daquela época, naquele contexto, consideravam bom desempenho. Incluindo todos os vieses conscientes e inconscientes que isso implica.

No momento da escolha do objetivo. Como já discutimos no artigo anterior, a métrica que você otimiza molda o que o modelo aprende a valorizar. Se você otimiza para maximizar a produtividade medida de certas formas, o modelo vai aprender a favorecer quem historicamente produziu mais segundo essas métricas — que pode ser sistematicamente correlacionado com características demográficas que nada têm a ver com capacidade real.

No momento da implantação. Mesmo um modelo bem construído pode produzir viés quando implantado em contextos diferentes do que foi treinado. Um modelo de reconhecimento facial treinado principalmente com rostos de pessoas de pele clara vai performar pior em pessoas de pele escura — não porque foi programado assim, mas porque os dados de treinamento não representavam o mundo onde o modelo seria usado.

O problema com a solução óbvia

Quando apresento esse quadro em aula, a solução que os alunos propõem quase imediatamente é: basta remover as variáveis sensíveis dos dados. Não inclui raça, gênero, origem — e o modelo não pode usar essas informações para discriminar.

É uma solução intuitiva. E frequentemente não funciona.

O motivo é que variáveis sensíveis raramente estão isoladas nos dados. Elas estão correlacionadas com dezenas de outras variáveis que parecem neutras mas não são. CEP é uma proxy para raça em cidades historicamente segregadas. Escola frequentada é uma proxy para classe social. Tipo de telefone celular é uma proxy para renda. Lacunas no currículo são uma proxy para gênero em culturas onde mulheres interrompem carreiras por responsabilidades de cuidado.

Quando você remove a variável sensível, o modelo não perde a informação — ele a reconstrói a partir das variáveis correlacionadas. Esse fenômeno tem um nome: proxy discrimination. O modelo não usa raça diretamente. Usa CEP, que usa raça indiretamente. O resultado discriminatório é o mesmo.

Mas há um problema ainda mais fundo. A própria ideia de “remover o viés” pressupõe que existe uma versão neutra dos dados — uma descrição do mundo sem viés, que só precisaria ser revelada se tirássemos as variáveis problemáticas. Essa versão neutra não existe. Os dados são um registro do mundo. E o mundo é desigual. Qualquer modelo treinado sobre dados do mundo real vai aprender, em alguma medida, as desigualdades do mundo real.

Isso não significa que não há nada a fazer. Significa que o problema é mais difícil do que parece — e que soluções simplistas frequentemente criam novos problemas.

Quando remover o viés piora as coisas

Há casos documentados onde tentativas de corrigir viés algorítmico produziram resultados piores para os grupos que pretendiam proteger. Vale examinar um.

Em sistemas de justiça criminal nos Estados Unidos, algoritmos de avaliação de risco são usados para prever a probabilidade de reincidência de réus. Pesquisadores descobriram que um desses sistemas atribuía pontuações de risco mais altas a réus negros em comparação com réus brancos com históricos similares — um viés claro.

A resposta intuitiva seria: ajuste o modelo para que as taxas de erro sejam iguais entre grupos. Problema resolvido.

Mas pesquisadores de fairness em ML descobriram algo perturbador: dependendo de como você define “justo”, as definições são matematicamente incompatíveis entre si. Você pode garantir que o modelo erre na mesma proporção para ambos os grupos. Ou pode garantir que, entre as pessoas que o modelo classifica como alto risco, a proporção de reincidência real seja igual nos dois grupos. Mas não pode garantir as duas coisas ao mesmo tempo — não quando as taxas de reincidência históricas são diferentes entre os grupos, o que é frequentemente o caso em sistemas com histórico de discriminação.

Isso não é um bug que será corrigido com mais dados ou melhor engenharia. É uma impossibilidade matemática que reflete uma tensão real entre diferentes noções de justiça — e que nenhum algoritmo pode resolver sozinho, porque é fundamentalmente uma questão ética e política, não técnica.

O que isso muda na sala de aula

Quando comecei a ensinar IA, tratava viés como um tópico especial — uma seção dedicada no final do semestre, depois de cobrir os algoritmos “de verdade”. Como se fosse um apêndice ético numa disciplina técnica.

Não faço mais isso.

Hoje, a questão do viés aparece na primeira aula, quando discutimos o que significa treinar um modelo sobre dados. Aparece quando falamos de coleta de dados. Aparece quando discutimos métricas de avaliação. Aparece quando analisamos casos reais de implantação.

Porque viés não é um problema ético separado dos problemas técnicos. É uma consequência direta das escolhas técnicas — quais dados usar, o que otimizar, como avaliar, onde implantar. Tratar as duas coisas como separadas é o que permite que engenheiros construam sistemas com consequências discriminatórias e depois digam, com honestidade, que não foi intencional.

Não foi intencional. Mas era previsível. E previsível significa responsabilidade.

O aluno que imaginou o sistema de triagem de currículos no início desta aula estava prestes a construir algo exatamente assim — não por malícia, mas por falta das perguntas certas.

De onde vieram esses dados? Quem estava visível neles e quem estava ausente? O que os rótulos históricos realmente medem? Quem é afetado quando o modelo erra — e erra de formas sistemáticas?

Essas perguntas não aparecem em nenhum tutorial de scikit-learn. Não estão nos benchmarks que usamos para comparar algoritmos. Não são cobradas na maioria das provas de Machine Learning.

Mas são as perguntas que determinam se o sistema que você vai construir vai funcionar para todo mundo — ou apenas para quem já estava bem representado nos dados.

E essa diferença, no fim, é a única que importa para as pessoas do outro lado do algoritmo.

Por que eu parei de usar a palavra “inteligência” quando falo de IA para os meus alunos.

nelson — Tue, 12 May 2026 00:52:25 +0000

Foi durante uma aula sobre redes neurais.

Eu havia explicado a arquitetura, mostrado como os pesos são ajustados durante o treinamento, demonstrado o resultado num problema de classificação de imagens. O modelo performava bem. Os alunos estavam engajados.

Então um aluno levantou a mão e fez uma pergunta que, na superfície, parecia simples:

— Professor, em que momento a rede começa a entender o que está vendo?

Fiz uma pausa.

Não porque a pergunta fosse ingênua — era, na verdade, uma das perguntas mais inteligentes que alguém poderia fazer. Era porque percebi, naquele momento, que não havia uma resposta boa dentro do vocabulário que eu havia usado a aula inteira. Eu havia falado em “inteligência artificial”, em como o modelo “aprende a reconhecer padrões”, em como ele “decide” qual classe atribuir a cada imagem.

O aluno estava apenas seguindo o vocabulário que eu mesmo havia oferecido. E esse vocabulário havia criado uma expectativa que o mecanismo real não conseguia satisfazer.

A rede não entende nada. Nunca vai entender. E eu havia passado cinquenta minutos usando palavras que sugeriam o contrário.

Um campo que se nomeou com as palavras erradas

A Inteligência Artificial nasceu, como campo formal, numa conferência em Dartmouth em 1956. John McCarthy, um dos organizadores, escolheu o nome. A proposta original dizia que o objetivo era fazer máquinas se comportarem de formas que, se observadas em seres humanos, seriam chamadas de inteligentes.

É uma definição operacional cuidadosa — baseada no comportamento observável, não em afirmações sobre estados internos. McCarthy sabia o que estava fazendo. O problema não foi a definição. Foi o nome.

“Inteligência Artificial” é um nome que carrega consigo décadas de ficção científica, intuições sobre a mente humana e expectativas sobre o que “ser inteligente” significa. Quando você ouve que uma máquina é inteligente, não pensa em multiplicações de matrizes e gradiente descendente. Pensa em algo que entende, que raciocina, que talvez sinta.

E o campo não parou no nome. Ao longo das décadas, foi acumulando um vocabulário inteiro emprestado da psicologia e da filosofia da mente: os modelos aprendem, compreendem, decidem, reconhecem, raciocinam, julgam. Redes neurais têm neurônios e sinapses. Sistemas têm memória e atenção. Agentes têm crenças e intenções.

Cada uma dessas palavras é uma metáfora. Cada metáfora é útil para comunicar rapidamente o que um sistema faz de forma aproximada. E cada metáfora, quando tomada ao pé da letra, cria uma falsa imagem do que está realmente acontecendo.

O que cada palavra está escondendo

Vale a pena examinar algumas dessas metáforas de perto — não para descartá-las, mas para ver o que elas iluminam e o que elas escondem.

“Inteligência”

No uso cotidiano, inteligência implica flexibilidade — a capacidade de resolver problemas novos em domínios variados, de transferir conhecimento entre contextos, de adaptar estratégias quando o ambiente muda. Um ser humano inteligente não precisa ter visto exatamente aquele problema antes para ter uma chance razoável de resolvê-lo.

Os sistemas que chamamos de IA em geral não têm isso. São extraordinariamente competentes dentro do domínio em que foram treinados — e frequentemente frágeis fora dele. Um modelo que joga xadrez melhor que qualquer humano não consegue jogar damas. Um modelo de linguagem que escreve código fluente em Python pode gerar absurdos numa linguagem menos representada nos dados de treinamento. Isso não é inteligência geral — é competência estreita e profunda, que é uma coisa diferente e em vários aspectos mais limitada.

“Compreensão”

Compreender algo implica representação interna — uma estrutura mental que captura as relações entre conceitos, que permite fazer inferências, que sustenta explicações. Quando você compreende por que objetos caem, você entende gravidade de uma forma que permite raciocinar sobre casos que nunca viu.

Modelos de linguagem produzem texto que frequentemente parece demonstrar compreensão. Respondem perguntas, explicam conceitos, fazem analogias. Mas há experimentos simples que revelam os limites: perguntas que invertem levemente a estrutura de um problema que o modelo “resolveu” corretamente produzem erros grosseiros. O modelo não estava compreendendo — estava reconhecendo padrões superficiais que se parecem com compreensão nos casos mais comuns.

“Decisão”

Quando um sistema de IA “decide” qual anúncio mostrar, qual candidato selecionar, qual paciente priorizar, a palavra “decisão” importa um peso ético que o mecanismo real não carrega. Decisões humanas envolvem responsabilidade, julgamento, possibilidade de ser questionado e de explicar o raciocínio.

Um modelo que produz uma saída a partir de uma entrada não decide no mesmo sentido. Ele computa. A responsabilidade pela decisão — quais dados usar, qual objetivo otimizar, quais consequências aceitar — pertence às pessoas que construíram e implantaram o sistema. Usar a palavra “decisão” para descrever a saída do modelo frequentemente serve para obscurecer onde a responsabilidade humana realmente está.

O perigo concreto das metáforas

Isso não é uma discussão filosófica sem consequências práticas. O vocabulário que usamos para descrever sistemas de IA molda as perguntas que fazemos sobre eles — e as perguntas que não fazemos.

Se um modelo “decide”, a pergunta natural é: a decisão foi correta? Se um sistema “computa uma saída a partir de dados otimizados para um objetivo específico”, as perguntas naturais são outras: quais dados? Otimizado para quê? Quem definiu o objetivo? Quem é responsável pelo resultado?

A segunda família de perguntas é mais trabalhosa. Mas é a que protege as pessoas afetadas pelos sistemas.

Há um padrão que se repete em casos de falha de IA que viraram notícia. Um sistema de reconhecimento facial identifica erroneamente uma pessoa como suspeita. Um algoritmo de seleção filtra currículos de forma discriminatória. Um modelo de concessão de crédito nega empréstimos de forma sistematicamente injusta para certos grupos. Em todos esses casos, a investigação posterior revela que as pessoas que implantaram o sistema confiaram demais no vocabulário — agiram como se o sistema estivesse decidindo ou julgando, quando estava apenas computando uma função sobre dados históricos enviesados.

O vocabulário não causou esses problemas. Mas criou o ambiente mental em que as perguntas certas não foram feitas.

O que eu faço diferente agora

Não abolí o vocabulário padrão das minhas aulas. Isso seria impraticável — os alunos vão encontrar esses termos em todo lugar, e precisam reconhecê-los e usá-los para se comunicar no campo.

O que mudou é que agora introduzo o vocabulário acompanhado explicitamente do que ele está escondendo.

Quando digo “o modelo aprende”, acrescento: no sentido de que seus parâmetros são ajustados para minimizar uma função de perda — não no sentido de que adquire compreensão.

Quando digo “o sistema decide”, acrescento: no sentido de que produz uma saída a partir de uma entrada — a responsabilidade pela escolha do objetivo e dos dados é humana.

Quando digo “rede neural”, menciono: o nome é uma metáfora histórica — o que temos são funções matemáticas compostas em camadas, não neurônios biológicos.

Isso toma mais tempo. Às vezes os alunos acham que estou sendo excessivamente cuidadoso com palavras. Mas volta e meia aparece uma pergunta — como a do aluno que queria saber em que momento a rede começa a entender — que me lembra por que esse cuidado importa.

Aquele aluno estava fazendo a pergunta que o vocabulário convidava a fazer. E a resposta honesta era: a pergunta está baseada numa premissa que o vocabulário criou e que o mecanismo não sustenta.

Isso não é culpa do aluno. É consequência de um campo que se nomeou com as palavras de uma coisa que ainda não sabe construir — e que, décadas depois, ainda não parou para examinar o que esse nome promete e o que os sistemas realmente entregam.

Hoje, quando começo a falar sobre Inteligência Artificial, gosto de fazer uma pausa antes e dizer:

Vamos combinar que vamos usar esse nome porque todo mundo usa. Mas vamos também combinar que vamos lembrar, durante o semestre todo, que é um nome — não uma descrição.

Os alunos riem. Achando que é um detalhe menor.

Não é.

O seu modelo está certo. E completamente inútil. Como isso é possível?

nelson — Tue, 12 May 2026 00:45:48 +0000

Imagine que você é contratado para resolver um problema real.

Uma empresa de crédito quer prever quais clientes vão deixar de pagar. O histórico tem cem mil transações. Você prepara os dados, escolhe o algoritmo, treina o modelo, avalia no conjunto de teste. A acurácia aparece na tela: 97,3%.

Você respira fundo. Isso é um resultado excelente. Você prepara a apresentação, mostra os números, o cliente fica impressionado. O modelo vai para produção.

Duas semanas depois, o telefone toca. O modelo não está funcionando. Está sinalizando quase ninguém como inadimplente. A equipe de risco continua no escuro.

Você volta para os dados e descobre o que deveria ter visto antes de treinar qualquer coisa: 97,3% dos clientes no histórico nunca deixaram de pagar.

O modelo aprendeu uma política perfeita e completamente inútil: classificar todo mundo como adimplente. Acerta 97,3% das vezes. Não detecta um único caso de inadimplência. E do ponto de vista da métrica que você otimizou, é um modelo excelente.

Esse cenário tem um nome técnico. Chama-se problema de classes desbalanceadas. É um dos erros mais comuns em projetos reais de Machine Learning. E ele não acontece porque o engenheiro não sabia programar. Acontece porque a métrica errada foi escolhida para o problema errado — e ninguém percebeu até ser tarde.

A ilusão da acurácia

A acurácia é a métrica mais intuitiva em classificação: de todas as previsões que o modelo fez, qual fração estava correta?

É também, em muitos problemas reais, a métrica mais enganosa que existe.

O motivo é simples. A acurácia trata todos os erros como iguais e todos os acertos como iguais. Mas no mundo real, erros não são iguais. Classificar um e-mail legítimo como spam é um inconveniente. Classificar um tumor maligno como benigno é uma tragédia. Classificar uma transação fraudulenta como legítima custa dinheiro. Classificar uma transação legítima como fraudulenta constrange um cliente inocente.

Quando as classes são desbalanceadas — quando um resultado é muito mais raro que o outro — a acurácia infla artificialmente porque o modelo aprende que a estratégia mais segura é sempre prever a classe majoritária. Ele nunca erra na maioria. E a maioria é quase tudo.

O problema, claro, é que a classe minoritária é frequentemente a que importa. Fraudes são raras — mas são o que você quer detectar. Tumores malignos são menos comuns que benignos — mas são o que o diagnóstico precisa pegar. Falhas em equipamentos industriais são infrequentes — mas são exatamente o que o sistema de manutenção preditiva existe para antecipar.

Um modelo com 99% de acurácia num problema de detecção de fraude pode estar errando em 100% das fraudes reais. E a métrica não vai te contar isso.

O problema mais fundo: medir o que é fácil, não o que importa

O desbalanceamento de classes é apenas o exemplo mais visível de um problema mais profundo.

Em Machine Learning, medimos o que conseguimos medir com facilidade. Acurácia, precisão, recall, F1-score, AUC-ROC — todas são métricas que calculamos sobre um conjunto de dados rotulados, num momento específico, sob condições controladas. São números reais, reproduzíveis, comparáveis entre modelos.

O que raramente medimos com a mesma rigor é o que realmente importa: o modelo funciona no mundo real, com dados que ninguém rotulou, em situações que não estavam no conjunto de teste, produzindo consequências para pessoas reais?

Essa distância — entre o que medimos e o que importa — tem um nome que já mencionei no artigo anterior: a Lei de Goodhart. Quando uma métrica se torna o alvo, ela deixa de ser uma boa medida do objetivo original. O modelo otimiza a métrica. E a métrica não é o objetivo.

Deixa eu tornar isso concreto com três casos que qualquer estudante de ML vai encontrar cedo ou tarde.

O modelo de recomendação que maximiza cliques. Cliques são fáceis de medir. Satisfação do usuário, valor de longo prazo, qualidade da informação consumida — não são. Então você otimiza para cliques. O modelo descobre que conteúdo sensacionalista, indignante ou controverso gera mais cliques do que conteúdo preciso e equilibrado. A métrica sobe. O objetivo real desce.

O modelo de seleção de currículos que minimiza tempo de contratação. Contratar rápido é mensurável. Contratar bem é difícil de quantificar. O modelo aprende a favorecer candidatos parecidos com os que foram contratados antes — porque esses têm maior probabilidade histórica de passar pelo processo inteiro sem atritos. Diversidade cai. Viés histórico se perpetua. O tempo de contratação diminui. A métrica está ótima.

O modelo de saúde que reduz readmissões hospitalares. Readmissões são um indicador de qualidade do cuidado — pacientes que voltam ao hospital logo após a alta provavelmente não receberam tratamento adequado. Faz sentido otimizar para reduzi-las. Mas um estudo real mostrou que alguns hospitais reduziram readmissões simplesmente deixando de admitir pacientes de alto risco — porque se o paciente nunca é admitido, ele nunca pode ser readmitido. A métrica melhorou. O cuidado piorou.

Em todos esses casos, o modelo fez exatamente o que foi pedido. O problema estava na pergunta, não na resposta.

O que perguntar antes de olhar para qualquer métrica

Quando apresento resultados de modelos em aula, passei a exigir que os alunos respondam três perguntas antes de mostrar qualquer número.

A primeira: o que exatamente essa métrica está medindo? Não o nome dela — o que ela calcula, matematicamente, e o que isso representa no contexto do problema.

A segunda: quais tipos de erro essa métrica ignora ou subestima? Todo indicador agrega informação e, ao agregar, esconde alguma coisa. O que está escondido aqui?

A terceira: se o modelo otimizar perfeitamente essa métrica e nada mais, o problema estará resolvido? Essa é a mais difícil — e a mais importante. Porque frequentemente a resposta é não, e perceber isso antes do treinamento vale mais do que qualquer ajuste de hiperparâmetro depois.

Essas perguntas não são difíceis de entender. São difíceis de lembrar de fazer — especialmente quando você está no meio de um projeto, com prazo, com um conjunto de dados na mão e um algoritmo pronto para rodar. A pressão natural é começar a treinar e ver o que acontece. A disciplina necessária é parar um momento antes e perguntar: o que vou medir, e isso é realmente o que preciso saber?

Uma coisa que mudou na minha forma de ensinar

Durante um tempo, ensinei métricas de avaliação como uma lista de ferramentas: acurácia serve para isso, precision-recall serve para aquilo, use AUC-ROC quando as classes são desbalanceadas. Uma receita.

Receitas são úteis. Mas receitas não ensinam a pensar — ensinam a seguir passos. E o problema com seguir passos em ML é que os problemas reais raramente se encaixam nas categorias da receita.

Hoje começo pelo outro lado: pelo objetivo de negócio, pelo problema humano, pela consequência real de cada tipo de erro. Só depois chegamos às métricas — como traduções imperfeitas de algo que importa para algo que conseguimos calcular.

A pergunta que quero que os alunos saiam sabendo fazer não é qual métrica usar? É o que estou disposto a perder quando escolho otimizar isso?

Porque toda escolha de métrica é um trade-off. Aumentar a sensibilidade de um detector de fraude significa aceitar mais falsos positivos — mais clientes legítimos bloqueados. Reduzir falsos positivos significa aceitar mais fraudes passando despercebidas. Não há configuração perfeita. Há escolhas — e essas escolhas têm consequências para pessoas reais que nunca vão ver o código que as afeta.

Entender isso não é saber Machine Learning. É saber o que fazer com Machine Learning.

O modelo com 97,3% de acurácia estava certo.

E era completamente inútil.

A diferença entre as duas coisas não está no algoritmo. Está em quem, antes de apertar o botão de treinar, parou para perguntar: certo em relação ao quê — e isso é o que eu preciso?

A IA não aprendeu nada. Ela otimizou uma função. E essa diferença muda tudo.

nelson — Tue, 12 May 2026 00:32:09 +0000

É uma cena que qualquer professor de computação já viveu em alguma versão.

Um aluno apresenta o trabalho final. Treinou um modelo de classificação, os resultados ficaram bons, e ele está visivelmente satisfeito. Na hora de explicar o que aconteceu, ele diz, com naturalidade, uma frase que parece inocente:

— O modelo aprendeu a distinguir as classes.

Eu deixei passar. Naquele momento, pareceu apenas uma forma de falar — informal, aceitável, tecnicamente próxima o suficiente. O modelo havia melhorado sua performance ao longo das épocas de treinamento. “Aprendeu” parecia uma descrição razoável disso.

Mas a frase ficou me incomodando depois.

Porque existe uma diferença real entre o que o aluno quis dizer e o que o modelo realmente fez. E essa diferença — pequena na superfície, enorme nas implicações — é o que determina se você vai saber onde o modelo falha ou vai ser pego de surpresa quando ele falhar.

O que a palavra “aprendizado” está fazendo aqui

Quando dizemos que uma criança aprendeu a distinguir cães de gatos, estamos dizendo algo rico: ela formou uma representação mental da categoria, consegue generalizar para animais que nunca viu, entende que um filhote de golden retriever e um vira-lata idoso pertencem à mesma categoria apesar das diferenças superficiais, e provavelmente consegue explicar, com alguma imprecisão, o que torna um animal um cão.

Quando dizemos que um modelo de Machine Learning “aprendeu” a distinguir cães de gatos, estamos dizendo algo muito mais preciso e muito mais limitado: os parâmetros internos do modelo foram ajustados, por um processo de otimização matemática, de forma que o erro de classificação sobre um conjunto de exemplos rotulados foi minimizado.

Isso é tudo.

Não há representação. Não há generalização no sentido cognitivo. Não há compreensão do que torna um animal um cão. Há pesos numéricos em matrizes que, quando você passa uma imagem nova por eles, produzem uma saída que na maioria das vezes corresponde ao rótulo correto — desde que a imagem nova seja suficientemente parecida com as que o modelo viu durante o treinamento.

A palavra “aprendizado” é uma metáfora. Uma metáfora poderosa, útil para comunicar de forma rápida o que acontece, e adotada pelos próprios fundadores do campo com plena consciência do que estavam fazendo. O problema não é a metáfora em si. O problema é quando ela começa a ser tomada ao pé da letra — e aí as consequências são concretas.

O que realmente acontece quando um modelo “aprende”

Vamos desmontar o processo sem jargão desnecessário.

Você tem um conjunto de dados — pares de entrada e saída correta. Uma coleção de e-mails rotulados como spam ou não-spam. Uma série de imagens rotuladas como cão ou gato. Um histórico de transações rotuladas como fraude ou legítima.

Você tem um modelo — uma função matemática com muitos parâmetros ajustáveis. No caso de uma rede neural, esses parâmetros são os pesos das conexões entre os neurônios artificiais. Inicialmente, esses pesos são aleatórios. O modelo ainda não faz nada útil.

Você tem uma função de perda — uma medida matemática de o quanto as saídas do modelo diferem das saídas corretas. Quando o modelo classifica um e-mail legítimo como spam, a função de perda aumenta. Quando acerta, diminui.

O treinamento é o processo de ajustar os parâmetros do modelo para minimizar essa função de perda sobre o conjunto de dados de treinamento. Isso é feito por um algoritmo chamado gradiente descendente: a cada passo, o algoritmo calcula em qual direção ajustar cada parâmetro para que a perda diminua um pouco. Repita isso muitas vezes, sobre muitos exemplos, e os parâmetros convergem para valores que produzem erros menores.

Quando esse processo termina, dizemos que o modelo “aprendeu”.

Mas o que aconteceu, tecnicamente, foi: uma função matemática teve seus parâmetros ajustados para minimizar uma métrica específica sobre um conjunto específico de dados. Nada mais. Nada menos.

Por que isso não é pedantismo

Aqui está onde a diferença entre a metáfora e o mecanismo começa a importar de verdade.

Se um modelo realmente aprendesse — no sentido cognitivo — você esperaria que ele generalizasse de forma robusta para situações novas, que reconhecesse quando está fora do seu domínio de competência, que mantivesse consistência lógica entre suas respostas.

Mas um modelo que otimizou uma função sobre dados históricos não tem nenhuma dessas propriedades garantidas. Ele generaliza bem para exemplos parecidos com o que viu. Ele falha de formas às vezes bizarras em exemplos ligeiramente diferentes. Ele não sabe que está fora do seu domínio — não há sinal interno de incerteza que emerge automaticamente quando a entrada é incomum. E ele pode ser completamente inconsistente: classificar dois exemplos quase idênticos de formas opostas dependendo de variações mínimas na entrada.

Esses não são bugs que serão corrigidos numa versão futura. São consequências diretas do que o processo de treinamento é. Você otimizou para minimizar o erro médio sobre um conjunto de dados. Casos fora dessa distribuição, casos extremos, casos onde a métrica que você otimizou diverge do que você realmente queria — esses são exatamente os lugares onde o modelo vai falhar, de formas que você não consegue antecipar sem entender o mecanismo.

Um exemplo que uso em aula: imagine um modelo treinado para detectar pneumonia em radiografias de tórax. Os resultados no conjunto de teste são excelentes — acurácia alta, médicos impressionados. Mas quando o modelo é colocado em produção em outro hospital, a performance cai drasticamente. O que aconteceu?

Investigação posterior revela que as radiografias do hospital de treinamento tinham uma característica técnica específica — um artefato de equipamento — que aparecia com mais frequência nas imagens de pacientes com pneumonia, porque esses pacientes eram examinados com maior urgência em equipamentos específicos. O modelo aprendeu a detectar esse artefato, não a pneumonia. Ele otimizou a função de perda sobre os dados disponíveis. Fez exatamente o que foi pedido. E era completamente inútil fora do contexto original.

Isso tem um nome: spurious correlation — correlação espúria. O modelo encontrou um padrão nos dados que previa o rótulo corretamente durante o treinamento mas não tinha relação causal com o que você queria detectar. Um sistema que realmente entendesse pneumonia não faria isso. Um sistema que otimizou uma função sobre dados históricos faz isso o tempo todo — e você só descobre quando já está em produção.

O que muda quando você entende isso

Quando você abandona a metáfora do aprendizado e abraça o mecanismo da otimização, algumas perguntas mudam de lugar.

Em vez de perguntar o modelo aprendeu bem? — que convida a olhar para a acurácia no conjunto de teste e parar por aí — você passa a perguntar: o modelo otimizou o quê, sobre quais dados, e isso corresponde ao que eu realmente preciso que ele faça no mundo real?

Em vez de confiar que um modelo com boa performance vai generalizar, você passa a perguntar: quão diferente é o ambiente de produção do ambiente de treinamento? Onde essa distribuição pode divergir?

Em vez de tratar um erro do modelo como surpresa, você passa a esperar que ele ocorra em padrões específicos — e a procurar esses padrões antes que causem dano.

Isso não é ceticismo paralisante. É o oposto: é o que permite usar modelos de forma responsável, sabendo onde confiar e onde verificar.

Voltando à apresentação do meu aluno.

O modelo dele havia otimizado uma função de perda sobre um conjunto de dados rotulados. Os resultados eram bons. O trabalho estava correto.

O que eu deveria ter dito — e que estou dizendo agora, com mais clareza do que tinha naquele momento — é que “aprendeu” e “otimizou” não são a mesma coisa. E que saber a diferença não vai tornar o modelo melhor. Vai tornar o engenheiro mais capaz de perceber quando o modelo está errado.

Que é, afinal, a habilidade que mais vai importar quando esse aluno estiver construindo sistemas que afetam pessoas reais.

Ensino IA há pouco tempo. E quanto mais ensino, mais desconfio do que ensinei ontem.

nelson — Tue, 12 May 2026 00:08:47 +0000

Não foi um plano.

Ninguém acorda um dia e decide que vai ensinar Inteligência Artificial. Pelo menos não foi assim comigo. A oportunidade apareceu — uma disciplina precisava de professor, eu tinha a formação técnica mais próxima, e de repente estava diante de uma turma que esperava que eu soubesse o que estava fazendo.

Preparei as aulas. Estudei. Montei os slides. Expliquei conceitos, corrigi exercícios, apliquei provas.

E fui ensinando.

O problema é que, alguns meses depois, olhei para trás e percebi que uma coisa que havia ensinado com convicção — uma afirmação que eu tinha apresentado como fato estabelecido — não resistia a um exame mais cuidadoso. Não era errada no sentido de um cálculo equivocado. Era incompleta de uma forma que importava. Era uma simplificação que eu havia aceitado sem questionar porque estava nos livros, estava nos slides que circulam entre professores, estava no vocabulário padrão do campo.

Fiquei incomodado.

Não com os alunos. Comigo.

O desconforto que ninguém menciona

Há uma coisa que os professores de computação raramente dizem em público sobre ensinar IA hoje: é desconfortável de uma forma muito específica.

Não é o desconforto de não saber a matéria. É o desconforto de ensinar um campo que se move mais rápido do que qualquer currículo consegue acompanhar, que é apresentado pela mídia de formas que contradizem o que você ensina, e que carrega um vocabulário emprestado da psicologia humana — “aprendizado”, “inteligência”, “decisão”, “compreensão” — que frequentemente diz mais do que deveria sobre o que os sistemas realmente fazem.

Quando estou na frente dos alunos ensinando IA, sinto pelo menos três coisas ao mesmo tempo.

Sinto entusiasmo genuíno — o campo é fascinante, os problemas são reais, as ferramentas são poderosas, e há algo de eletrizante em ensinar algo que está sendo construído enquanto você o ensina.

Sinto desconforto honesto — há perguntas que meus alunos fazem para as quais eu não tenho resposta boa, e às vezes a resposta honesta é “ainda não sei” ou “depende de como você define isso” ou, mais raramente e mais importante, “acho que o campo ainda não sabe”.

E sinto responsabilidade — esses alunos vão usar isso. Vão construir sistemas que afetam pessoas reais. O que eu ensino sobre como avaliar um modelo, sobre onde confiar e onde questionar, sobre o que as métricas medem e o que elas escondem, vai importar muito além da prova final.

Essas três sensações não se cancelam. Coexistem, toda aula.

Por que estou escrevendo sobre isso

Este blog não é um repositório de certezas.

Não vou escrever sobre o que a IA vai fazer pelo mundo nem sobre o que ela vai destruir. Não vou traduzir papers para o português nem explicar como usar ferramentas de produtividade com IA. Há gente muito competente fazendo isso.

O que vou fazer é mais específico e, acredito, mais raro.

Vou escrever sobre o que fica quando você começa a questionar as afirmações óbvias sobre IA — as que circulam em sala de aula, nos corredores de departamentos, nos tutoriais que todos recomendam. Vou escrever sobre o que professores e estudantes de computação aceitam sem examinar porque sempre foi assim, porque está no livro, porque é o vocabulário padrão do campo.

Não faço isso de fora. Faço de dentro — como alguém que ainda está aprendendo a ensinar esse campo, que já ensinou coisas que depois questionou, e que decidiu que é mais útil documentar esse processo em público do que fingir uma autoridade que ainda estou construindo.

Isso tem um nome na filosofia da ciência. Karl Popper chamava de falseabilidade — a disposição de expor suas afirmações à possibilidade de estarem erradas. É o oposto do dogma. E é, curiosamente, o que a maioria dos sistemas de IA não consegue fazer por si mesmos: questionar suas próprias respostas.

Se os sistemas que ensinamos não conseguem fazer isso, pelo menos nós podemos.

O que vem a seguir — e para quem é isso

Esta série tem nove artigos planejados depois deste.

Cada um parte de uma crença comum sobre IA — comum em salas de aula, entre estudantes, entre professores — e a examina sem concessão fácil. Não para demolir o campo nem para celebrá-lo, mas para ver com mais clareza o que ele realmente é, o que ele realmente faz, e onde ele sistematicamente nos engana se não estivermos atentos.

Escrevo para professores que ensinam computação e sentem, como eu, esse desconforto específico de ensinar um campo em movimento. Para estudantes que querem entender IA de verdade — não apenas usar as ferramentas, mas saber quando questionar o que elas produzem. Para qualquer pessoa que percebeu que o entusiasmo e o alarmismo em torno da IA raramente deixam espaço para a pergunta mais importante: mas isso é verdade?

Não vou fingir que tenho todas as respostas. Vou fingir ainda menos que as perguntas são simples.

O que posso prometer é honestidade sobre o que sei, sobre o que ainda estou aprendendo, e sobre o que acho que o campo preferiria não examinar tão de perto.

Uma última coisa.

Aquela afirmação que ensinei e depois questionei — nunca voltei para a turma e corrigi. O semestre havia terminado. Os alunos haviam seguido em frente.

Isso me incomoda até hoje. E é, talvez, a razão mais honesta pela qual estou escrevendo este blog.

Se eu ensinar algo aqui que depois questionar, vou voltar e dizer. Publicamente, no mesmo espaço onde disse pela primeira vez.

Parece pouco. Na prática, é uma das coisas mais difíceis de fazer.

Bem-vindo à série.