idea_world_labDEV JOURNAL
sexta-feira, 12 de junho de 2026

2026-06-12 retrospectiva

Decidi escrever a retrospectiva novamente

Deixo uma retrospectiva depois de um tempo. O motivo de não ter registrado antes não foi apenas por estar ocupado, mas principalmente porque eu queria deixar apenas textos perfeitos. Eu queria registrar somente depois que os resultados estivessem claramente organizados, e achava desnecessário deixar registros de falhas ou mudanças de direção no meio do caminho.

Mas, ao olhar para trás, percebo que esse processo foi o mais significativo. Nos últimos 10 dias, não houve muitos resultados concluídos, mas investiguei bastante o que seria necessário para criar um modelo de codificação especializado em Godot, onde encontrei bloqueios e alterei decisões. Por isso, hoje decidi organizar todo esse fluxo.

Experimento com modelo local

Inicialmente, para economizar a taxa de uso do RunPod, tentei colocar um modelo da série Qwen no meu PC local. Como estou usando uma RTX 3060, pensei que um modelo de cerca de 9B poderia rodar de alguma forma no WSL.

Entretanto, não funcionou como esperado. Havia sérios problemas de velocidade de conexão de rede e latência de resposta, e antes mesmo de receber uma única resposta, a fase de inferência levava mais de 5 minutos. Nesse ritmo, a velocidade dos experimentos era muito lenta e seria difícil integrar a ferramenta de desenvolvimento, então interrompi imediatamente a execução do modelo local.

O que ficou claro com esse experimento foi que, no meu ambiente, é mais importante projetar a estrutura do conjunto de dados e o pipeline de treinamento antes de tentar rodar um modelo grande localmente.

Investigação do conjunto de dados Godot

Para treinar o modelo, era necessário ter dados. Então procurei um conjunto de dados utilizável para aprendizado de código Godot 4 e encontrei o wallstoneai/godot-gdscript-dataset no Hugging Face.

No início, pensei que fosse apenas um conjunto de arquivos .gd reunidos, mas ao analisar com Gemini percebi que a estrutura era o que realmente importava. O ponto chave não era extrair arquivos individualmente de um repositório GitHub, mas sim expandir um repositório inteiro para preservar o contexto do projeto.

Esse conjunto de dados parece combinar o README.md do repositório, arquivos .gd e a estrutura de diretórios em um único texto, incluindo nome do projeto, versão do Godot, árvore de arquivos e conteúdo de cada arquivo em formato markdown. Dessa forma, o modelo vê não apenas trechos isolados de código, mas também a estrutura do projeto e as relações entre arquivos.

Um aspecto particularmente importante foi a forma de distinguir versões Godot 3/4. O Godot não possui uma estrutura típica de projetos web com package.json ou requirements.txt. Em vez disso, é preciso ler valores dentro do arquivo project.godot, como config_version e config/features, ou usar diferenças de sintaxe GDScript.

Por exemplo, no Godot 3 aparecem expressões como onready var e KinematicBody, enquanto no Godot 4 usamos @onready e CharacterBody3D. Capturando essas diferenças com regex ou analisadores, obtive a ideia de que, mesmo sem um arquivo de versão baseado em JSON, é possível filtrar versões em linguagens menos populares.

Apenas o conjunto de dados não foi suficiente

Depois, assisti a um vídeo no YouTube sobre fine‑tuning de uma linguagem de programação antiga chamada OPL.

Mesmo assistindo, ainda não consegui entender completamente. O processo de coleta de dados e o de fine‑tuning precisam estar conectados, mas a pergunta “Se eu tenho apenas o conjunto de dados, o que e como eu devo treinar?” continuava sem resposta.

Então perguntei ao meu mentor da SSAFY como coletar dados de uma linguagem menos popular em uma versão específica da forma mais eficaz. Recebi uma resposta crucial.

Primeiro, o conjunto de dados que eu estava consultando é mais um conjunto de código bruto do que um conjunto de dados de treinamento de assistente. Se eu quiser um chatbot, inserir apenas o código bruto não será suficiente.

Segundo, a partir do conjunto de dados bruto devo gerar pares de pergunta/resposta para o LLM. Só depois de ouvir isso ficou claro o que eu precisava fazer: não basta reunir apenas código Godot 4, preciso gerar dados de pergunta e respostas para criar um conjunto de dados de instruções.

Sem essa etapa, ao solicitar “desenhe um mapa”, o modelo pode responder em Python em vez de Godot, já que os modelos existentes foram treinados muito mais com dados Python. Se os dados de resposta não forem claros, há grande chance de aparecer código de versões antigas do Godot ou até de outras linguagens.

Conjunto de dados de instruções e dúvidas sobre prompting

Como candidato a conjunto de dados de instruções, também procurei o Magicoder-Evol-Instruct-110K.

A maior parte, porém, era focada em Python. Usá‑lo diretamente não parecia adequado para criar um modelo exclusivo para Godot 4.

Então surgiu a dúvida: “Será que preciso mencionar Godot explicitamente?” Se eu inserir bastante dados de Godot, talvez o modelo responda em código Godot mesmo sem o usuário especificar.

Essa questão foi esclarecida ao conversar com um veterano da faculdade. Hoje em dia, pode ser mais vantajoso projetar bem a estrutura de prompting ou de busca baseada em documentos do que depender apenas de RAG, e criar documentos markdown indexados por vetores para que o modelo encontre as informações necessárias pode ser uma abordagem mais prática.

Concluí que, nesta fase, é mais provável obter respostas corretas ao dar um contexto claro, como “crie um mapa usando Godot”, em vez de apenas “crie um mapa”. Como os pesos dos modelos existentes favorecem Python, é necessário reforçar a condição “Godot” logo no início do prompt.

Redesenho da arquitetura

Inicialmente, eu imaginei a arquitetura de forma simples.

Coleta de conjunto de dados -> Criação de conjunto de dados de perguntas/respostas -> Treinamento do modelo

Mas logo percebi que essa estrutura era muito perigosa. Se eu coletar dados sem conhecer bem o que mudou do Godot 3 para o 4, código incorreto pode acabar como dado de resposta correta. Mesmo ao criar um conjunto de dados de perguntas/respostas, código Python ou código do Godot 3 pode se misturar.

Então imaginei uma estrutura que usa a documentação oficial como ponto de referência. Crawler a documentação de migração do Godot 3 para 4 e a documentação oficial do Godot 4, criar um chatbot RAG e colocá‑lo na frente para determinar se o código coletado é de Godot 3 ou 4, se usa APIs antigas ou se é adequado ao Godot 4.

O diagrama anexado é o rascunho do pipeline que organizei nessa ocasião.

Pipeline de treinamento de modelo especializado em Godot

O fluxo geral é o seguinte:

  • Rastrear a documentação oficial do Godot e a documentação de migração para criar uma base de conhecimento RAG.
  • Coletar projetos Godot no GitHub por repositório.
  • Mesclar README, estrutura de arquivos e código GDScript em um único contexto.
  • Filtrar na primeira fase usando o arquivo de configuração project.godot e diferenças de sintaxe do GDScript.
  • Usar o chatbot RAG para determinar se o código é Godot 3/4 e se utiliza APIs antigas.
  • Apenas os dados refinados para Godot 4 são transformados em conjuntos de dados de instrução/resposta.
  • Treinar o modelo de codificação Godot 4 com SFT e dados DPO/Preferência.

Direção de SFT e DPO

Depois, ao consultar o ChatGPT, obtive também direções inesperadas. Eu só pensava em “um modelo que gera código Godot 4”, mas consegui dividir a tarefa de treinamento de forma mais detalhada.

No SFT, podem ser criadas as seguintes tarefas:

  • Classificação de código Godot 3/4
  • Conversão de código Godot 3 para Godot 4
  • Geração de código Godot 4
  • Correção de erros em Godot 4
  • Rejeição ou correção de APIs Godot 3

No DPO/Preferência, é possível definir claramente respostas ruins e boas. Por exemplo, considerar uma resposta que mistura sintaxe Godot 3 como resposta ruim e uma resposta escrita puramente em código Godot 4 como resposta boa.

Com essa perspectiva, percebi que não se trata apenas de “coletar muitos dados”, mas de decidir primeiro “o que consideramos uma boa resposta”.

Crawling da documentação oficial do Godot

Para tentar realmente essa abordagem, encontrei uma ferramenta de crawling e usei o crawl4ai.

Crawlei e documentei cerca de 1.500 páginas, incluindo a documentação oficial do Godot 4, o guia de migração do Godot 3 → 4, a referência de classes do Godot 4 e os tutoriais do Godot 4.

No início pensei que talvez estivesse crawling demais, mas, comparado ao tamanho total do contexto do modelo, isso representa cerca de 3 % do total. Se não for inserido todo de uma vez no modelo, mas usado em uma estrutura de RAG ou busca de documentos, é uma quantidade manejável.

Pipeline de dados e preocupações com I/O

Ao redesenhar a arquitetura, também me preocupei com I/O de disco e timing de treinamento. Quando coleta, pré‑processamento, pós‑processamento, armazenamento, reindexação e treinamento ocorrem sequencialmente, surgem gargalos inevitáveis.

Consultei um veterano da faculdade sobre isso. A resposta foi que, em vez de fazer fine‑tuning em tempo real, é melhor acelerar a coleta e o processamento dos dados e realizar o treinamento em batch.

Por exemplo, só executar reinforcement learning ou fine‑tuning quando o conjunto de dados atingir certo volume. Processar apenas quando ultrapassar um limiar, como um “slot de replicação”, reduz o gargalo de I/O; as partes que exigem baixa latência são a coleta e o preparo dos dados, não o treinamento.

O custo de reindexação não pode ser eliminado completamente por questões estruturais. Portanto, ao invés de tentar removê‑lo, é mais realista definir critérios claros de quando reindexar e quando treinar.

Resumo do dia

Resumindo os últimos 10 dias: comecei de forma vaga querendo “criar um modelo de codificação para Godot”. Agora tenho uma estrutura mais concreta.

Um dataset apenas com código bruto não basta. São necessários: dados de código refinados baseados no Godot 4, estrutura de avaliação baseada na documentação oficial, dados de instrução/resposta, tarefas SFT, e critérios DPO/Preference.

Além disso, com meu nível atual, criar um modelo de codificação do zero sem um modelo grande como o Qwen é inviável. Comparando o desempenho de um modelo local inicial com o do ChatGPT para codificação, percebi que não dá para ignorar diferenças de tamanho do modelo e quantidade de pré‑treinamento.

Mesmo assim, a direção está muito mais clara. Posso criar uma base de conhecimento a partir da documentação oficial do Godot 4, filtrar os dados coletados e definir critérios de respostas boas e ruins para gerar dados de treinamento.

Retrospectiva

Ao escrever esta retrospectiva, o que mais percebi foi que devemos baixar o padrão de registro. Se tentarmos registrar apenas resultados perfeitos, o processo realmente importante desaparece. Experimentos que falharam, julgamentos ambíguos, arquiteturas que mudaram no meio do caminho são os materiais que geram as próximas decisões; se não os deixarmos registrados, não saberemos mais por que fizemos certas escolhas.

Daqui para frente, em vez de tentar publicar apenas resultados concluídos, pretendo registrar o processo com mais frequência. Acho que, ao invés de adiar a retrospectiva porque o pensamento de ter falhado vem primeiro, é melhor registrar incluindo as falhas e as reflexões, pois essa é a direção mais adequada.

Quero aproveitar este dia como um ponto de partida para continuar registrando retrospectivas de forma consistente. Não precisa ser um texto perfeito, nem um processo final. O importante é deixar registrado o que eu tentei, o que aprendi e, na próxima vez, sob quais critérios eu irei agir.