2026-07-03 retrospectiva

O que fiz hoje

Hoje deixei um stream de 24 horas no YouTube rodando enquanto coletava dados, fiz testes de tradução e, usando a ferramenta de validação criada em 30 de junho, realizei as verificações.

Na parte do Conversor Markdown → JSONL, a quantidade de conversões de documentos oficiais para JSONL subiu de 737 para 850. Hoje, em vez de iniciar uma grande implementação nova, continuei a coleta enquanto o RunPod estava ativo e, nesse intervalo, fui verificando gradualmente os fluxos de validação e tradução.

Na parte de tradução, estou experimentando um pipeline que usa a API gratuita de modelos da NVIDIA. Via segredos do workflow do GitHub consegui alguns resultados positivos e vi a geração de README em japonês e chinês. Ainda não é o momento de dizer que está totalmente implementado, mas quanto mais documentos houver, mais forte se torna a necessidade de um fluxo automático de tradução.

Satisfação por ter criado a ferramenta de validação

O que mais me impressionou hoje foi perceber o quanto foi acertado ter criado a ferramenta de validação em 30 de junho. Sem ela, a situação poderia ter sido muito pior.

No método antigo, eu precisava pedir ao Qwen que gerasse código e JSONL separadamente, colar tudo no prompt, e comparar a resposta esperada mentalmente. Agora basta clicar em um item, gerar o código e o JSONL, aplicar a validação ao código Godot 3 e ao código Godot 4, e visualizar o prompt bruto e a resposta bruta em uma única tela. Ainda há trabalho manual, mas pelo menos conseguimos ver exatamente onde está o erro.

Hoje verifiquei até o item 10 dos 50 itens de teste. Nesse processo, alguns casos em que o LLM gerou respostas incorretas foram encontrados.

• No item 1, o candidato docs_chunks foi marcado como “sim” porque continha a mesma pista de _ready() ou de viewport, embora na realidade fosse uma descrição de código diferente.
• Nos itens 3, 4 e 7, o JSONL de migração de Godot 3 foi inserido em código no formato de Godot 4 e ainda assim recebeu “sim”.
• No item 8, docs_chunks foi considerado “sim” por tratar de rastreamento/movimento ou APIs semelhantes, embora o comportamento real do SOURCE_CODE fosse diferente.
• Nos itens 6, 9 e 10, tudo passou conforme o esperado, indicando que a direção de melhoria não está totalmente equivocada.

Esses problemas não surgem porque um único JSONL esteja errado, mas porque, ao usar busca híbrida, o Qwen pode decidir usar um candidato semelhante como base ou descartá‑lo como mero resultado de busca. Portanto, em vez de bloquear tokens específicos, precisamos refinar o prompt de validação para que ele avalie com mais precisão a relação entre o código atual e o candidato JSONL.

Reflexões

Hoje não foi um dia de implementações chamativas. Rodei a coleta automática, cliquei manualmente nas validações e revisei JSONL e resultados, o que fez o tempo passar mais devagar do que eu esperava. Ainda assim, sinto que fiz algo útil e fico satisfeito.

A validação leva mais tempo do que se imagina. Mesmo que pareça apenas revisar um código e um JSONL, os tipos de docs_chunks, api_mapping e label_prototypes variam, assim como o código base em Godot 3 versus Godot 4. Só com 10 itens já surgem muitos casos diferentes.

Mesmo assim, ao identificar antecipadamente os pontos problemáticos, podemos reduzir falhas inesperadas nas buscas de banco de dados e nos fluxos de validação do Retriever. Quero continuar capturando esses problemas antecipadamente nos próximos testes.

Se fosse melhorar, talvez combinar o RunPod com APIs gratuitas seja uma alternativa. Se a API gratuita de modelos da NVIDIA ou outros endpoints gratuitos puderem ser usados de forma estável para tradução, validação auxiliar e sincronização de documentos, a dependência do RunPod poderia ser reduzida.