💻 computer science

EmbeddedKittens: An Evaluation of Code Embeddings for Scratch

Este artigo avalia empiricamente quatro modelos de linguagem de grande escala e cinco abordagens de embedding para programas Scratch, demonstrando que modelos treinados em grandes conjuntos de dados abertos podem capturar efetivamente informações estruturais e semânticas para apoiar tarefas de análise de aprendizagem, como a previsão de correção funcional em pequenos ambientes de sala de aula, sem a necessidade de ajuste fino adicional.

Autores originais: Benedikt Fein, Gordon Fraser

Publicado 2026-07-22

📖 7 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Benedikt Fein, Gordon Fraser

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você esteja tentando ensinar um robô superinteligente a entender a linguagem humana. Você alimenta o robô com milhões de livros, filmes e sites e, eventualmente, ele aprende a prever a próxima palavra em uma frase com uma precisão incrível. Esta é a magia dos Modelos de Linguagem de Grande Escala (LLMs). Agora, imagine que você quer que esse mesmo robô entenda o código-fonte — as instruções que os programadores escrevem para dizer aos computadores o que fazer. Como o código se parece um pouco com uma linguagem estranha e estruturada, pesquisadores descobriram que esses robôs também podem aprender a entendê-lo, ajudando desenvolvedores a escrever softwares mais rápido ou até mesmo a corrigir erros automaticamente.

Mas aqui está a reviravolta: nem todo código se parece com texto. Nas escolas, muitas crianças aprendem a programar usando o Scratch, um sistema colorido baseado em blocos, onde você encaixa peças de quebra-cabeça em uma tela em vez de digitar linhas de texto. É como construir com peças de Lego em vez de escrever uma história. A grande questão para os cientistas é: será que esses mesmos "cérebros robóticos" que leem código baseado em texto também conseguem entender esses quebra-cabeças visuais de blocos? E, se conseguirem, qual método funciona melhor? Isso é importante porque, se pudermos ensinar robôs a entender o Scratch, poderemos construir ferramentas para ajudar professores a corrigir tarefas, identificar alunos com dificuldades ou dar dicas instantâneas, tornando o aprendizado de programação muito mais fluido para a próxima geração.

O Grande Desafio do Tradutor de Código

Neste estudo, os pesquisadores Benedikt Fein e Gordon Fraser partiram para responder a uma pergunta complicada: Podemos ensinar computadores a "entender" programas de Scratch o suficiente para ajudar em uma sala de aula? Eles não apenas adivinharam; eles construíram um parquinho digital para testar diferentes tipos de "tradutores de código".

Pense em um tradutor de código como uma forma de transformar um programa complexo do Scratch em um único número secreto (ou um "vetor") que captura a essência do programa. Se dois programas são semelhantes, seus números secretos devem estar próximos. Se forem diferentes, os números devem estar distantes. Os pesquisadores queriam ver qual tradutor era o melhor nesse jogo.

Os Competidores

Eles alinharam cinco tipos diferentes de tradutores para competir:

Os Leitores "Planos": Estes modelos tratam o código como uma lista simples de palavras, ignorando a estrutura. É como ler uma receita, mas ignorar o fato de que algumas etapas acontecem dentro de uma "tigela de mistura" e outras no "fogão".
Os Leitores de "Árvore": Estes modelos observam a estrutura do código, como uma árvore genealógica de instruções. Eles entendem que alguns blocos estão aninhados dentro de outros.
Os Leitores de "Fluxo": Estes são os mais avançados. Eles não veem apenas a estrutura; eles rastreiam como a informação se move através do programa, como observar a água fluindo por canos. Eles sabem se uma variável muda em um bloco e é usada em outro.
Os "Grandes Cérebros" (LLMs): Estes são os modelos de IA gigantes e pré-treinados (como os que alimentam os chatbots) que já leram milhões de documentos de texto. Os pesquisadores pediram a eles que olhassem para o código do Scratch e adivinhassem o que ele estava fazendo.

O Teste: Nomeando os Personagens

Para testar esses tradutores, os pesquisadores criaram um jogo chamado "Nomeação de Sprites". No Scratch, cada personagem (ou "sprite") tem um nome. A tarefa era simples: mostrar ao modelo o código dentro de um sprite e pedir que ele adivinhasse o nome do sprite. É como mostrar o diário de um personagem para alguém e perguntar: "Qual é o nome deste personagem?".

Os resultados mostraram uma hierarquia clara. Os vencedores foram os leitores de "Fluxo" (especificamente um modelo chamado GGNN). Ao prestar atenção em como os blocos se conectam e como os dados se moveem entre eles, esses modelos foram muito melhores em entender a "história" do código. Eles adivinharam o nome do sprite com uma precisão significativamente maior do que os outros.

Os modelos de "Grandes Cérebros" (LLMs) e os leitores "Planos" tiveram um desempenho ruim nesta tarefa específica de nomeação. Eles tiveram dificuldade em adivinhar os nomes corretos porque os programas de Scratch raramente usam os nomes de variáveis sofisticados ou funções personalizadas que esses grandes modelos estão acostumados a ver em códigos baseados em texto. Em vez disso, o Scratch depende fortemente da estrutura dos blocos e de como eles se conectam. No entanto, é importante notar que mesmo o modelo vencedor de "Fluxo" não foi perfeito; ele ainda cometeu erros, o que significa que nenhum modelo era um oráculo impecável. Os LLMs não foram os únicos a falhar em atingir pontuações perfeitas, mas foram consistentemente superados pelos modelos que entendiam a estrutura e o fluxo do programa.

A Barreira Linguística

Os pesquisadores também testaram se a língua usada pelos alunos importava. O Scratch é usado em todo o mundo, no Brasil, na China, na Polônia e em muitos outros lugares. Eles descobriram que os modelos funcionavam melhor quando o código era escrito em inglês ou em outras línguas que utilizam o alfabeto latino (como A, B, C). Quando o código usava outros sistemas de escrita (como caracteres chineses ou o cirílico russo), os modelos ficavam confusos. Isso sugere que, para que essas ferramentas funcionem globalmente, elas precisam melhorar na compreensão de diferentes línguas e símbolos, não apenas do inglês.

Da Nomeação à Avaliação: Podemos Usar Isso na Aula?

A verdadeira magia aconteceu a seguir. Os pesquisadores perguntaram: "Se esses modelos são bons em nomear sprites, eles também podem ajudar professores?".

Eles testaram duas grandes ideias:

Verificação de Correção: O modelo consegue olhar para o programa bagunçado de um aluno e dizer se ele funciona, mesmo sem executá-lo? Eles encontraram uma ligação forte entre o "entendimento" do modelo sobre o código e se o código realmente passava nos testes. Se o modelo achava que o código estava "próximo" da solução, o código geralmente funcionava. Isso significa que esses modelos poderiam atuar como um "substituto" para verificar o dever de casa instantaneamente.
Rastreamento de Progresso: O modelo pode mostrar o quanto um aluno progrediu? Eles usaram um mapa especial para plotar o progresso do aluno. À medida que os alunos adicionavam recursos aos seus jogos, seu "mapa de código" se movia para mais perto da solução final. Os modelos rastrearam essa jornada com sucesso, mostrando aos professores exatamente onde o aluno estava travado ou o quanto ele já havia avançado.

Curiosamente, para essas tarefas mais amplas (como classificar o tipo de projeto ou rastrear o progresso), os LLMs na verdade tiveram um desempenho muito bom, às vezes igualando ou superando os modelos estruturais especializados. Isso sugere que, embora os LLMs possam perder os detalhes estruturais minúsculos necessários para nomear um personagem específico, eles são muito bons em entender o "quadro geral" de um projeto.

O Veredito

O estudo conclui que sim, é possível usar embeddings de código para o Scratch, mas você tem que escolher a ferramenta certa para o trabalho. Para tarefas que exigem um entendimento estrutural profundo (como nomear um sprite), modelos especializados que entendem o fluxo e a estrutura dos blocos são os campeões. Os gigantescos chatbots (LLMs) não são a melhor escolha para esses quebra-cabeças específicos porque eles perdem os detalhes estruturais nos quais o Scratch se baseia.

No entanto, para tarefas educacionais mais amplas (como correção de tarefas ou rastreamento de progresso), os LLMs são surpreendentemente eficazes e podem ser tão bons quanto os modelos especializados. Melhor ainda, esses modelos especializados, uma vez treinados, podem ser usados para outras tarefas — como corrigir tarefas ou rastrear o progresso — sem a necessidade de serem retreinados para cada nova atividade. Isso é uma grande vitória para os professores, pois significa que eles poderiam ter ferramentas automatizadas poderosas para ajudar os alunos a aprender, mesmo em pequenas salas de aula onde não há dados suficientes para treinar um novo IA do zero.

Em resumo, os pesquisadores encontraram uma maneira de dar aos computadores um "senso" do código Scratch que vai além de apenas ler palavras. Ao entender a forma e o fluxo dos blocos, esses modelos podem nos ajudar a construir um futuro mais inteligente e de maior suporte para o ensino de programação.

Resumo Técnico: EmbeddedKittens: Uma Avaliação de Embeddings de Código para Scratch

Declaração do Problema

A proliferação de embeddings de código e de Grandes Modelos de Linguagem (LLMs) transformou a engenharia de software e a análise educacional, particularmente para linguagens baseadas em texto como Python e Java. No entanto, sua aplicação a ambientes de programação visual baseados em blocos, como o Scratch, permanece uma questão em aberto. O Scratch apresenta desafios únicos:

Diferenças Estruturais: O código Scratch consiste em blocos visuais posicionáveis livremente, em vez de sequências lineares de tokens, e depende fortemente de execução concorrente e mensagens orientadas a eventos entre "sprites", o que os embeddings de texto padrão podem falar em capturar.
Diversidade Linguística: A comunidade Scratch é altamente internacional, com usuários empregando diversos idiomas naturais para identificadores, comentários e elementos de interface (UI). Os modelos padrão frequentemente assumem identificadores centrados no inglês.
Escassez de Dados para Educação: Benchmarks comuns de embeddings de código (ex: nomeação de métodos, geração de documentação) são inviáveis para o Scratch devido à falta de comentários e documentação nos projetos dos alunos. Além disso, conjuntos de dados de sala de aula são tipicamente pequenos demais para treinar modelos específicos para tarefas do zero.

O problema central é determinar qual abordagem de embedding de código é mais adequada para a análise de aprendizagem no Scratch, especificamente se os modelos conseguem captar informações estruturais e semânticas sem a necessidade de um ajuste fino (fine-tuning) extensivo em ambientes educacionais com escassez de dados.

Metodologia

Os autores, Benedikt Fein e Gordon Fraser, conduziram uma avaliação empírica envolvendo quatro questões de pesquisa (RQs) para avaliar a viabilidade e o desempenho de várias abordagens de embedding.

1. Pré-processamento e Representação de Dados

Os autores utilizaram o LitterBox para analisar projetos Scratch (formato JSON) em Árvores de Sintaxe Abstrata (ASTs). Eles implementaram o EmbeddedKittens, uma ferramenta de pré-processamento, para converter o código Scratch em formatos adequados para diferentes arquiteturas de modelos:

Sequências de Tokens Planas (Flat Token Sequences): Usadas para o NeuralCodeSum (Transformer) e LLMs (GPT-5-mini, DeepSeek Coder v2, Mistral Small 3.1, Gemma 3). A AST foi percorrida via busca em profundidade para criar uma representação textual (ex: motion_movesteps(10)). Para LLMs, o formato ScratchBlocks foi utilizado, pois se alinha melhor aos seus dados de pré-treinamento.
Caminhos de AST (AST Paths): Usados para code2vec e code2seq, representando o código como conjuntos de caminhos entre os nós folha da AST.
Subárvores de Instrução (Statement Subtrees): Usadas para o ASTNN, dividindo a AST em subárvores por instrução, codificadas por um GRU bidirecional.
Grafos de Fluxo de Controle/Dados (Control/Data Flow Graphs): Usados para o GGNN (Gated Graph Neural Network). Esta abordagem estendeu a AST com arestas semânticas representando fluxo de dados (LastRead, LastWrite, ComputedFrom), fluxo de controle (GuardedBy) e manipulação de eventos específica do Scratch (transmissão de mensagens entre sprites).

2. Tarefas Experimentais

RQ1 (Nomeação de Sprite): Uma tarefa de baseline onde os modelos preveem o nome de um sprite com base em seu código. Isso serve como um proxy de sumarização de código, já que projetos Scratch carecem de nomes de métodos ou documentação.
RQ2 (Internacionalidade): Avaliação do desempenho do modelo através de 10 idiomas naturais diferentes (incluindo scripts não latinos como chinês, japonês e russo) para avaliar o impacto da diversidade linguística.
RQ3 (Classificação de Programa): Ajuste fino de embeddings de sprites pré-treinados para classificar programas inteiros por categoria (ex: jogo, animação) ou pelo seu projeto base (classificação de remix).
RQ4 (Estimativa de Correção): Uso de embeddings como um modelo substituto (surrogate) para estimar a correção funcional de programas de alunos, medindo a distância até uma "solução modelo" no espaço de embedding, em comparação com os resultados reais de suítes de teste.
RQ5 (Rastreamento de Progresso): Aplicação da técnica de "projeção de variância-progresso" para visualizar o progresso dos alunos ao longo do tempo usando os embeddings, mapeando a distância de um projeto inicial até uma solução.

3. Modelos Avaliados

Modelos de Embedding Dedicados: NeuralCodeSum, code2vec, code2seq, ASTNN, GGNN.
LLMs Pré-treinados: GPT-5-mini, DeepSeek Coder v2, Mistral Small 3.1, Gemma 3, e Qwen 3 Embedding.

Principais Contribuições

Avaliação Sistemática: A primeira comparação estruturada de cinco abordagens diferentes de embedding de código e quatro LLMs especificamente para o domínio Scratch.
Tarefa de Nomeação de Sprite: A introdução de uma nova tarefa de "nomeação de sprite" para servir como um baseline para a sumarização de código no Scratch, superando a falta de benchmarks tradicionais.
Análise Multilíngue: A criação e avaliação de conjuntos de dados através de 10 idiomas distintos, destacando as disparidades de desempenho em ambientes de scripts não latinos.
Aplicabilidade Educacional: Demonstração de que embeddings pré-treinados podem ser transferidos para tarefas educacionais (estimativa de correção, rastreamento de progresso) sem a necessidade de ajuste fino para a tarefa, abordando o problema da escassez de dados em sala de aula.
Ferramental Open Source: O lançamento do EmbeddedKittens, uma ferramenta de pré-processamento para converter código Scratch em vários formatos prontos para embedding.

Resultados

RQ1: Sumarização de Código (Nomeação de Sprite)

Informação Estrutural é Crítica: Modelos que incorporam informação estrutural e de fluxo de controle superaram significativamente aqueles que utilizam sequências de tokens planas. O GGNN obteve o melhor desempenho (F1 = 0.550), seguido pelo ASTNN (F1 = 0.342).
Limitações dos LLMs: LLMs pré-treinados tiveram um desempenho pobre (F1 ≤ 0.081) na tarefa específica de gerar nomes de sprites, provavelmente porque o Scratch carece das funções customizadas e nomes de variáveis que os LLMs tipicamente utilizam para inferência em linguagens baseadas em texto.
Discrepância de Métricas: Embora o GGNN tenha alcançado altos escores BLEU, seus escores ROUGE-2 foram menores, sugerindo que ele frequentemente gerava subtokens corretos, mas em ordens incorretas ou com repetições.

RQ2: Internacionalidade

Viés de Linguagem: Os modelos performaram melhor em inglês e outros idiomas baseados no alfabeto latino. O desempenho caiu significativamente para scripts não latinos (ex: coreano, russo, chinês).
Problemas de Tokenização: Os autores atribuem o baixo desempenho em scripts não latinos à estratégia de subtokenização (divisão por espaços em branco/camel case), que é ineficaz para scripts sem esses delimitadores.
Escassez de Dados: O baixo desempenho em idiomas com menos usuários de Scratch (ex: coreano) foi vinculado à escassez de dados de treinamento nesses idiomas específicos.

RQ3: Classificação de Programas

Transferibilidade: Embeddings de sprites pré-treinados (especificamente GGNN e Qwen 3 Embedding) puderam ser efetivamente ajustados para classificação de programas.
Desempenho de LLMs: Surpreendentemente, o Qwen 3 Embedding (uma abordagem baseada em LLM) superou o modelo dedicado GGNN na classificação de categoria de programa (F1 = 0.562 vs. 0.475), sugerindo que, para categorização de alto nível, a similaridade semântica capturada por LLMs é suficiente, mesmo que os detalhes estruturais sejam menos críticos.
Robustez: Tanto os embeddings de GGNN quanto os baseados em LLM formaram clusters robustos, identificando corretamente remixes de projetos base com alta precisão (>97%).

RQ4 & RQ5: Correção e Progresso

Validade do Modelo Substituo (Surrogate): Foi encontrada uma correlação linear estatisticamente significativa entre o fitness baseado em embedding (distância para a solução) e o fitness real da suíte de testes. Isso confirma que os embeddings pré-treinados capturam informações semânticas e estruturais relevantes para a correção.
Visualização de Progresso: Os embeddings mapearam com sucesso o progresso dos alunos em um espaço 2D. O GGGG e o Qwen-whole (LLM processando o programa inteiro) mostraram fortes correlações com o progresso real ( $R^2 \approx 0.7$ ), enquanto a agregação por sprite com LLMs foi menos eficaz.
Sem Necessidade de Ajuste Fino: Crucialmente, esses resultados foram alcançados usando modelos pré-treinados apenas na tarefa de nomeação de sprite, sem posterior ajuste fino para correção ou progresso, validando sua utilidade em cenários de sala de aula com poucos dados.

Significância e Alegações

O artigo afirma que embeddings de código são viáveis e eficazes para o Scratch, desde que os modelos levem em conta a complexidade estrutural da linguagem.

Papéis Complementares: Os autores propõem um modelo de uso complementar:
- Modelos Estruturais Dedicados (ex: GGNN): Mais adequados para tarefas que exigem insights estruturais profundos, como detecção de bugs ou geração de dicas para o próximo passo, e podem ser implantados localmente com baixa sobrecarga de recursos.
- LLMs Pré-treinados: Mais adequados para tarefas de alto nível que envolvem similaridade semântica, como recomendação de projetos ou estimativa de progresso, aproveitando seu amplo pré-treinamento, mas exigindo mais recursos computacionais.
Impacto Educacional: O estudo demonstra que embeddings pré-treinados podem servir como "modelos substitutos" para análise de aprendizagem em ambientes onde coletar grandes conjuntos de dados rotulados para treinamento específico de tarefas é impossível. Isso permite ferramentas como correção automatizada, rastreamento de progresso e estimativa de dificuldade de exercícios em configurações típicas de sala de aula.
Direções Futuras: Os autores sugerem modestamente que trabalhos futuros explorem a melhoria da tokenização para scripts não latinos, a integração de informações visuais (posições dos blocos) e a adaptação desses conceitos para outros sistemas orientados a eventos.

O artigo conclui que, embora a transferência de embeddings de código para o Scratch seja bem-sucedida, a escolha do modelo depende fortemente da aplicação educacional específica e dos recursos computacionais disponíveis.