idea_world_labDEV JOURNAL
domingo, 14 de junho de 2026

14 de junho de 2026

  • No ônibus rumo a Seul, reorganizei minhas dúvidas sobre o conjunto de dados/pipeline RAG do Godot 4
    • Antes, eu imaginava rastrear a documentação oficial do Godot, converter projetos do GitHub para formatos md e jsonl, e usar um chatbot RAG para determinar se o projeto era Godot 3 ou 4
    • Contudo, passei a questionar se seria viável colocar todo o contexto do projeto e os trechos de documentação oficial encontrados em uma única entrada de modelo
  • Refleti sobre os limites de contexto de entrada ao criar um chatbot RAG
    • Cada projeto do GitHub inclui README, estrutura de diretórios, múltiplos arquivos .gd, arquivos de cena e caminhos de recursos
    • Quando se adiciona a documentação oficial recuperada via RAG, o tamanho da entrada cresce, tornando mais crítico projetar quais arquivos e trechos de documento selecionar ao invés de simplesmente acumular documentos
  • Levantei dúvidas sobre o formato do conjunto de dados de perguntas/respostas
    • Solicitações como “crie um mapa” podem não se resumir a um único trecho de código de resposta
    • Na prática, são necessárias várias etapas de inferência: entender a estrutura do projeto, identificar assets, analisar estilo de código existente, revisar a sintaxe do Godot 4 e decidir quais arquivos modificar
    • Assim, questionei se basta colocar apenas o código final no conjunto de instruções ou se devemos também registrar os processos de exploração e decisão
  • Considerei a possibilidade de que o peso do Python volte a dominar ao processar em unidades de chunk
    • Mesmo pedindo “crie um mapa no Godot 4”, o modelo pode, ao ler o projeto e a documentação em chunks, ressurgir com pesos pré‑treinados centrados em Python
    • Concluí que é necessário injetar fortemente o contexto do Godot 4 no início do prompt e filtrar ainda mais na fase de pré‑processamento para evitar que código Godot 3 ou respostas ao estilo Python se misturem
  • Resumo do dia
    • RAG ou crawling não são soluções por si só; o essencial é projetar como o modelo lerá o contexto da solicitação e que julgamento ele fará
    • Decidimos dividir o contexto do projeto por arquivo/role/dependência e incluir, nos dados de instrução, não só a resposta final, mas também, quando necessário, o fluxo de exploração e decisão
    • É preciso reforçar ainda mais o design de prompts, tags, filtragem e critérios de dados preferenciais para que o contexto do Godot 4 não seja diluído durante a inferência
  • Retrospectiva de desenvolvimento: docs/retrospectives/2026-06-14.md