Decidi escrever novamente a retrospectiva de desenvolvimento depois de muito tempo
Por querer deixar apenas registros perfeitos, acabei adiando a escrita
Para registrar de forma significativa as tentativas e reflexões dos últimos ~10 dias, organizei a pesquisa e o design de arquitetura para criar um modelo de codificação especializado em Godot
Experimento para reduzir custos do RunPod colocando um modelo da série Qwen no PC local
Tentei rodar um modelo 9B no WSL em um ambiente RTX 3060
Porém a velocidade de conexão de rede e a latência eram problemáticas; antes mesmo de gerar a resposta, a fase de “pensamento” levava mais de 5 min, então interrompi o experimento local
Investigação sobre como coletar datasets para treinamento de modelo especializado em Godot
Analisei, via Gemini, como esse dataset foi criado
O ponto chave foi mesclar, por repositório GitHub, o README.md, arquivos .gd e a estrutura do projeto em um único texto, usando o arquivo de configuração project.godot e diferenças de sintaxe GDScript para classificar versões Godot 3/4
Percebi que, ao usar pistas como config_version, config/features, onready var, @onready, KinematicBody, CharacterBody3D, é possível filtrar versões mesmo em linguagens menos populares que não possuem arquivos de dependência baseados em JSON
Para entender o fluxo de fine‑tuning, assisti a um vídeo de fine‑tuning usando a linguagem de programação clássica OPL
Notei que coletar o dataset e transformá‑lo em um formato treinável são tarefas distintas
Perguntei ao coach da SSAFY como coletar eficientemente dados de linguagens menos populares em versões específicas
Recebi a resposta de que o dataset Godot que estou usando se assemelha mais a um dataset de código bruto do que a um Q&A para treinamento de assistente
Para criar um produto tipo chatbot, é melhor gerar pares pergunta/resposta com um LLM e convertê‑los em um dataset de instruções, em vez de usar o código bruto diretamente
Sem esse passo, o modelo tenderia a responder a solicitações como “desenhe o mapa” usando respostas centradas em Python, que foram muito mais treinadas
A maior parte está focada em Python, portanto não seria adequado usar diretamente como dados de treinamento exclusivos para Godot 4
Questionei se seria possível fazer o modelo responder sobre Godot mesmo sem mencionar explicitamente “Godot”; concluí que, devido ao peso dos pesos de Python, fornecer o contexto “Godot” na pergunta aumenta a probabilidade de resposta correta
Consultei um veterano da universidade sobre RAG e estratégias de prompting
Recebi a sugestão de que, ao invés de injetar todo o corpus no modelo, seria mais realista criar uma estrutura de busca vetorial baseada em documentos Markdown e orientar o modelo a buscar as informações necessárias
Re‑indexar grandes documentos é custoso em tempo e recursos; portanto, nesta fase, uma arquitetura baseada em busca/prompting pode ser mais adequada que treinamento extensivo
Esbocei a arquitetura inicial para um modelo de codificação especializado em Godot
Inicialmente imaginei um fluxo simples: coleta de dataset → geração de pares pergunta/resposta → treinamento do modelo
Contudo, percebi que seria necessário compreender bem as mudanças de Godot 3 para 4 para filtrar corretamente e gerar dados de resposta precisos
Caso contrário, códigos de Godot 3, Python ou APIs antigas poderiam se misturar nos dados de resposta, o que exigiu repensar a arquitetura
Projetei uma estrutura onde um chatbot RAG baseado em documentação oficial fica na frente para classificar e converter versões Godot 3/4
A ideia é rastrear a documentação oficial de migração e a documentação de Godot 4, criar um chatbot RAG e usá‑lo para determinar se os dados coletados pertencem a Godot 3 ou 4
Só os dados identificados como Godot 4 seriam transformados em dataset de instruções
Obtive insights adicionais sobre treinamento SFT/DPO via ChatGPT
No SFT, podem ser criadas tarefas como classificação Godot 3/4, conversão Godot 3 → 4, geração de código Godot 4, correção de erros Godot 4 e rejeição/correção de APIs Godot 3
No DPO/Preference, pode‑se montar dados de preferência onde resposta ruim = resposta contendo código Godot 3 e resposta boa = resposta contendo apenas código puro Godot 4
Rastreei e documentei quase 1 500 páginas, incluindo a documentação oficial do Godot 4, guias de migração de Godot 3 → 4, referência de classes do Godot 4 e tutoriais
Embora parecesse muito, isso representa cerca de 3 % do contexto total de um modelo típico
Consultei novamente o veterano da universidade sobre gargalos de I/O de disco no pipeline de armazenamento e treinamento
Recomendaram que, ao invés de fazer fine‑tuning em tempo real, seja melhor coletar e pré‑processar os dados quase em tempo real, e executar o treinamento em modo batch
Decidimos adotar um processamento batch baseado em métricas, disparando RL ou fine‑tuning quando o dataset atingir um tamanho específico
Como o custo de re‑indexação não pode ser eliminado completamente, a estabilidade do pipeline de coleta e processamento de dados é mais crítica que a latência de treinamento
Direção geral consolidada até agora
Rastrear a documentação oficial e montar uma base de conhecimento RAG baseada em Godot 4
Coletar projetos Godot no GitHub e mesclar, por repositório, README, estrutura do projeto e arquivos GDScript
Aplicar filtragem inicial usando as configurações project.godot e diferenças de sintaxe Godot 3/4
Utilizar o chatbot RAG para determinar se o conteúdo é Godot 3/4, se usa APIs antigas e se é adequado para Godot 4
Gerar pares instrução/resposta a partir dos dados filtrados para Godot 4
Treinar o modelo de codificação Godot 4 com dados SFT e DPO/Preference
Retrospectiva
Nos últimos 10 dias, ao focar apenas em deixar resultados “completos”, acabei não registrando o processo
Percebi que os experimentos falhos, os bloqueios e as mudanças de decisão ao longo do caminho são os registros mais valiosos para definir os próximos passos
A partir de agora, em vez de buscar apenas resultados perfeitos, vou continuar registrando fluxos de tentativa e decisão para evoluir gradualmente