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, via chatbot RAG, 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
    • Um único projeto do GitHub inclui README, estrutura de diretórios, vários arquivos .gd, arquivos de cena e caminhos de recursos
    • Quando se adicionam ainda os trechos de documentação oficial buscados via RAG, o tamanho da entrada cresce, tornando mais crítico projetar quais arquivos e trechos devem ser selecionados em vez de simplesmente acumular documentos
  • Questionei o formato do conjunto de dados de perguntas/respostas
    • Uma solicitação como “crie um mapa” pode não ser resolvida apenas com um trecho de código de resposta
    • Na prática, são necessárias etapas de inferência como entender a estrutura do projeto, identificar assets a usar, analisar o estilo de código existente, revisar a sintaxe do Godot 4 e decidir quais arquivos modificar
    • Assim, me pergunto 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 durante o processamento por chunks
    • Mesmo ao pedir “crie um mapa com Godot 4”, o modelo pode, ao ler o projeto e a documentação em chunks, ressurgir com pesos pré‑treinados de Python
    • Senti a necessidade de injetar fortemente o contexto de Godot 4 no início do prompt e filtrar ainda mais na fase de pré‑processamento para evitar que código de 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 quais julgamentos 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 o design de prompts, tags, filtros e critérios de dados preferenciais para que o contexto de Godot 4 não seja diluído durante a inferência
  • Retrospectiva de desenvolvimento: docs/retrospectives/2026-06-14.md