2026-06-14 Retrospectiva

Pensamentos no ônibus que vai para Seul

Hoje, dentro do ônibus que vai para Seul, repensei o pipeline de dataset/RAG do Godot 4 que havia projetado anteriormente. No dia 12 de junho, imaginei uma estrutura que rastreava a documentação oficial, coletava projetos Godot no GitHub e colocava um chatbot RAG na frente para determinar se era Godot 3/4 e gerar dados de instrução.

Mas, ao refletir novamente hoje, percebi que ainda há muitas dúvidas a serem resolvidas para que essa estrutura funcione bem na prática. Em especial, a distância entre “coletar documentos” e “o modelo usar esses documentos adequadamente” é maior do que eu imaginava, e isso continua me incomodando.

Primeira dúvida: o chatbot RAG consegue lidar com todo o contexto?

Antes, eu pensava que, ao rastrear a documentação oficial do Godot e criar um chatbot RAG, seria possível usar isso para classificar ou validar projetos coletados no GitHub. Contudo, ao imaginar o cenário de raspar projetos do GitHub, convertê‑los para md ou jsonl e alimentar tudo de uma vez ao chatbot, surgiu a dúvida:

O modelo consegue receber todo esse contexto de entrada?

Mesmo um único projeto Godot inclui README, estrutura de diretórios, vários arquivos .gd, arquivos de cena, caminhos de recursos etc. Quando se adicionam trechos de documentação oficial encontrados via RAG, a entrada pode crescer rapidamente. O fato de a documentação rastreada existir não garante que o modelo consiga ler de forma estável todo o projeto e os documentos relevantes a cada solicitação.

Portanto, criar um chatbot RAG não significa inserir o documento inteiro, mas sim construir uma estrutura de busca/seleção que decida quais trechos de documento trazer para cada pergunta. Se essa parte for fraca, o modelo pode perder arquivos importantes ou ler documentos desnecessários, perdendo o contexto do projeto que realmente importa.

Segunda dúvida: basta uma única resposta de código para cada pergunta?

A segunda dúvida diz respeito ao formato do dataset de instrução. Por exemplo, ao considerar a pergunta “Crie um mapa para mim”, a resposta pode não ser apenas um bloco de código simples.

Para que um LLM gere uma resposta, ele precisa passar por várias etapas: observar a estrutura do projeto, identificar quais cenas e scripts existem, verificar os assets disponíveis, ler o estilo de código existente, conferir se está de acordo com a sintaxe do Godot 4 e, por fim, decidir quais arquivos e códigos modificar.

Ou seja, a pergunta “Crie um mapa para mim” parece ser um único pedido, mas internamente requer múltiplas camadas de raciocínio. Se o conjunto de dados de treinamento contiver apenas o código final, fica em dúvida se o modelo aprenderá esse processo de julgamento intermediário.

Os dados de resposta corretos podem precisar incluir não só o código completo, mas também informações como quais arquivos devem ser lidos, quais evidências foram usadas para a decisão, por que determinada API foi escolhida, etc. Especialmente se quisermos que o agente se comporte como um agente de codificação, pode ser mais adequado registrar um fluxo “pergunta → exploração → julgamento → modificação → verificação” nos dados, em vez de apenas “pergunta → resposta”.

Terceira dúvida: ao processar por chunks, o peso do Python não reaparecerá?

A terceira dúvida envolve o viés de linguagem. Mesmo que eu dê o prompt “Crie um mapa no Godot 4”, pode acontecer de, ao dividir projetos ou documentos em chunks para leitura, o peso do código Python ou dos padrões de solução em Python se torne mais dominante.

Modelos de codificação genéricos provavelmente foram treinados muito mais intensamente em Python. Assim, apenas prefixar com a palavra Godot pode ser insuficiente. Se os chunks retornados não contiverem contexto suficiente do Godot 4, ou se, durante o raciocínio intermediário, padrões de codificação genéricos forem evocadas, há risco de a resposta fluir para uma solução em estilo Python.

Portanto, não basta dizer “Faça isso no Godot 4”. É preciso reforçar o contexto do Godot 4 de forma mais robusta nas etapas de prompt e pré‑processamento dos dados. Por exemplo, anexar tags específicas de Godot 4 aos dados de entrada, filtrar mais rigorosamente dados que misturam código Godot 3 ou de outras linguagens, ou injetar repetidamente a restrição “Esta tarefa segue o padrão GDScript do Godot 4” antes da geração da resposta.

Resumo do dia

A ideia central que tive hoje é que RAG ou rastreamento por si só não são a solução. Mais importante que coletar muitos documentos é projetar como o modelo lerá o contexto relevante e quais julgamentos ele deve fazer em cada solicitação.

A estrutura atual parece precisar ser dividida em etapas adicionais:

• Em vez de inserir todo o projeto de uma vez, criar uma estrutura pesquisável baseada em arquivos/funcionalidades/dependências.
• Avaliar se os dados de instrução precisam incluir não só o código final, mas também o processo de exploração e julgamento.
• Projetar prompts, tags, filtros e critérios de dados preferenciais de forma mais forte para que o contexto do Godot 4 não seja diluído durante o raciocínio.

Em resumo, para criar um “modelo de codificação Godot 4” não basta reunir apenas código Godot 4. É preciso refletir nos dados como o modelo lê o projeto, como ele decide que algo é Godot 4 e como escolhe a melhor resposta.

Retrospectiva

Hoje não foi um dia de muita codificação prática, mas foi um dia de perceber novamente as lacunas do design anterior. Enquanto pensava distraído no ônibus, percebi problemas que havia deixado passar à mesa. Dizer que vamos criar um chatbot RAG parece fácil, mas na prática tudo – unidades de busca, tamanho de contexto, estrutura de dados de pergunta/resposta, controle de viés de linguagem – está interconectado.

Ainda não há resposta. Mas o surgimento dessas dúvidas é um sinal positivo. Registrar as dúvidas agora servirá como referência para saber o que validar quando implementarmos o pipeline no futuro.

A seguir, com base nessas dúvidas, preciso detalhar como dividir o contexto do projeto, até que ponto incluir o processo de inferência nos dados de instrução e como criar regras de pré‑processamento que mantenham o contexto do Godot 4 forte.