Um incomodo meu como professora na área da Computação e agora mais recente, ensinando sobre Inteligência Artificial, o de que existe uma sequência que se tornou quase canônica nos cursos do mercado. Basicamente, inicia assim, apresenta-se o problema, carrega-se um dataset, treina-se um modelo, avalia-se a acurácia. O dado aparece sempre como insumo, algo que já está dado, como o próprio nome sugere e o modelo como o objeto de interesse intelectual. Essa inversão tem consequências pedagógicas e epistemológicas que raramente são discutidas e que vou tentar nomeá-las.
A tese é: quem não aprende a origem de uma solução não consegue reconhecer problemas novos, aprende a executar e não a criar.
Uma aula sobre MongoDB
Recentemente, meus estudantes do curso técnico em inteligência artificial estavam aprendendo banco de dados. Seguimos uma sequência deliberada: primeiro modelagem conceitual, depois estrutura relacional em MySQL e só então banco de dados não relacional com MongoDB. Na metade de uma aula sobre MongoDB, a maioria da turma já estava operando com segurança. Mas é claro, e isso não tem nada a ver com o MongoDB ser intuitivo ou bonitinho. É que, uma vez compreendida a rigidez dos bancos relacionais, a flexibilidade do não relacional faz sentido imediato. Os estudantes estavam aprendendo uma nova sintaxe E entendendo por que ela existe.
Esse “por que da exostência” é muita coisa.
O MongoDB não surgiu porque alguém quis simplificar a vida dos desenvolvedores. Surgiu porque o modelo relacional, criado para um mundo de dados estruturados e previsíveis, começou a encontrar seus limites diante de volumes massivos, dados heterogêneos e necessidade de escala horizontal. O NoSQL é uma resposta a um problema histórico (um problema sobretudo humano num contexto histórico específico). Quem aprende MongoDB sem ter aprendido SQL não sabe o que o MongoDB resolve e por isso não sabe quando ele é a resposta errada, nem consegue imaginar o que seria necessário quando nenhum dos dois for suficiente.
Agora, inverta essa sequência, ensine NoSQL primeiro porque “é o mais usado em projetos de IA” e quando esse profissional precisar resolver problemas no futuro onde a solução adequada é um banco relacional você vai ver como será um caminho tortuoso.
O mesmo problema, em escala maior
A mesma coisa acontece com toda a área de Inteligência Artificial, uma arquitetura transformer não surgiu do nada. Surgiu das limitações das redes recorrentes para lidar com dependências de longo prazo em sequências. O mecanismo de atenção foi proposto como solução a um problema específico e documentado. O GPT é uma resposta a perguntas que pesquisadores levavam anos tentando responder. Quem aprende a usar modelos pré-treinados sem nenhuma noção de estrutura de dados, sem entender o que é um atributo, o que é uma relação, o que significa representar o mundo em formato tabular ou vetorial é um profissional que opera uma solução sem ter a menor ideia do problema que ela resolve. Uma incapacidade de perceber quando a ferramenta disponível é inadequada para o problema em mãos, e a incapacidade ainda maior de contribuir com o que ainda precisa ser construído.
Um currículo que pula a fundação para chegar logo aos resultados impressionantes forma, sistematicamente, trabalhadores que sabem criar agentes de IA com ferramentas prontas, mas não conseguem treinar um modelo do zero, questionar a estrutura de um dataset, ou projetar arquiteturas para problemas que ainda não têm solução no mercado. A sequência de aprendizagem define o horizonte do que o profissional consegue imaginar fazer (no presente e no futuro). Se torna um profissional deslumbrado (ou maravilhado) pelas por todas as soluções tecnológicas que vê, entretanto, mesmo formado na área não é capaz de construir suas próprias soluções para problemas semelhantes ou nos quais quer resolver.
Estrutura como teoria do mundo
Aprender estrutura de dados não é aprender a programar melhor. É aprender que toda organização de informação implica uma teoria sobre o que existe, o que importa e o que pode ser comparado.
Quando se define que um campo é do tipo VARCHAR(255), está-se tomando uma decisão sobre o que pode ser dito naquele espaço. Quando se normaliza uma tabela, está-se afirmando algo sobre quais relações são independentes entre si. Quando se escolhe uma chave primária, está-se definindo o que individualize uma entidade no mundo modelado.
A própria noção de entidade, atributos, relacionamentos pressupõe escolhas de abstração escolhidas por pessoas (sejam as que programa, sejam as que administram o negócio).
Essas decisões nunca são neutras. O banco de dados de uma clínica que armazena gênero como campo binário não é apenas um banco de dados tecnicamente limitado é um banco de dados que produz invisibilidade de diferentes pessoas. O sistema de avaliação escolar que registra apenas notas numéricas não capta o que não foi previsto como mensurável. A estrutura do dado é sempre uma ontologia operacional e ontologias têm política.
Álvaro Vieira Pinto (2005), aponta que a alienação tecnológica começa quando o ser humano deixa de reconhecer nos artefatos o produto de suas próprias escolhas históricas. Ensinar estrutura de dados é, nesse sentido, um ato de desfetichização, mostrar que antes do modelo há uma tabela, antes da tabela há um modelo conceitual, antes do modelo conceitual há uma decisão sobre o que conta como real.
Uma questão curricular com consequências
O debate sobre o que ensinar primeiro em IA é uma questão sobre que tipo de profissional o mercado e a sociedade vão ter disponível para lidar com sistemas que já organizam crédito, saúde, educação e segurança pública. Ainda há um problema adicional no qual eu gosto de trazer com frequência e que agrava esse quadro: o sequestro da metodologia de projetos.
A aprendizagem baseada em projetos (Project-Based Learning) tem estrutura definida. Parte de um problema autêntico, exige investigação, envolve colaboração e, sobretudo, requer reflexão contínua sobre o processo. O que uma parcela significativa dos cursos de tecnologia chama de “aprendizagem por projetos” é outra coisa. Entregar um projeto não é trabalhar com PBL. Uma pessoa pode construir um chatbot funcional sem ter passado por nenhuma das etapas que a metodologia pressupõe, sem ter formulado o problema, sem ter investigado alternativas, sem ter refletido sobre o que aprendeu no percurso.
Essa confusão é bastante propícia nos currículos, ela busca nas teorias educacionais uma maneira de justificar a precarização da formação tecnológica, segue a mesma lógica que atravessa todo este ensaio: tomar o resultado como prova do processo. Assim como ensinar a usar um modelo pré-treinado é tratado como equivalente a ensinar inteligência artificial, entregar um projeto é tratado como equivalente a aprender por projetos. Em ambos os casos, estamos ocultando o percurso (as dores e as delícias do processo de aprender) e é no percurso que está a aprendizagem real.
Thomas e Mergendoller (2000), ao sistematizar os elementos centrais do PBL fazem a distinção entre um projeto educativo de uma tarefa complexa apontando que é a centralidade da investigação sustentada e da reflexão sobre o processo. Sem isso, o projeto é apenas uma embalagem. E embalagens bonitas criam a aparência de profundidade onde existe apenas superfície.
A diferença entre quem opera modelos prontos e quem entende a estrutura que os sustenta não é (somente) uma questão de soft skill versus hard skill. É uma questão de posição epistêmica, afinal, quem tem condições de questionar o que foi construído e de construir o que ainda não existe? Currículos que ensinam IA de trás para frente (do resultado para o fundamento, da ferramenta para o problema, do produto para o processo) são pedagogicamente preguiçosos e fazem uma escolha sobre quem vai ter autoridade técnica e intelectual sobre esses sistemas no futuro.
