Hoje o objetivo é decidir qual fluxo escolher entre várias alternativas de busca/validação
Mantendo chunkText como entrada, precisamos determinar como combinar BM25, busca full‑text do PostgreSQL, embedding, reranker e o validador de evidência direta Qwen
Inicialmente não havia um design definitivo; estávamos apenas reunindo os prós e contras de cada método de busca obtidos via ChatGPT e exemplos de respostas “sim”/“não” como material de decisão
Depois, com base em simulações de cada alternativa e em uma tabela comparativa consolidada, optamos por adotar prioritariamente a estratégia F
A estratégia F consiste em conectar BM25 + embedding + reranker + validador de evidência direta Qwen
Ou seja, usamos chunkText como entrada de busca, ampliamos os candidatos com BM25 e embedding, reordenamos com o reranker e, por fim, o Qwen verifica se o JSONL encontrado corresponde diretamente ao trecho de código atual
O próximo teste será feito com o Qwen, avaliando 50 itens de cada tabela: docs_chunks, api_mapping e label_prototypes
Em cada tabela, dividiremos cerca de 50 amostras entre casos relevantes e não relevantes, verificando como as respostas “sim” e “não” se comportam
Esse teste não serve apenas para checar se a busca funciona, mas para confirmar se o validador de evidência direta Qwen aceita ou rejeita o JSONL como prova direta do trecho de código
Como estamos fazendo tudo manualmente, a quantidade de testes necessários é muito maior do que esperávamos
Criamos 50 itens de teste para o Godot e, para cada um, precisamos analisar as três tabelas: docs_chunks, api_mapping e label_prototypes
Se for uma função/sintaxe comum, criamos um único trecho de código Godot, geramos os dados esperados “sim”/“não” para as três tabelas, e então inserimos prompt + código de teste + 6 dados para observar como o padrão de resposta varia
Caso não seja uma função comum, precisamos criar códigos separados para Godot 3 e Godot 4, dobrando efetivamente o esforço
Para consolidar os resultados em métricas como F1‑score, será necessário registrar manualmente o resultado true/false de todos os casos
Concluímos que não é viável concluir os 50 itens em um dia; portanto, hoje vamos reduzir a meta para 5 itens
Após completar os 5, em vez de simplesmente aumentar o número de testes, vamos analisar primeiro os padrões de respostas “sim”/“não” obtidos até agora
De fato, avançamos com 5 dos 50 itens
Mesmo com apenas 5, percebemos que o fluxo de respostas difere entre o JSONL gerado a partir de Godot 3 e o gerado a partir de Godot 4
Em códigos com diferenças de versão, o JSONL de Godot 3 pode gerar “sim” ao analisar código de Godot 4 devido a strings comuns ou evidências de migração, e vice‑versa, quando strings source/target se misturam, o resultado pode ficar ambíguo
Assim, nos próximos testes, não vamos apenas checar se as 6 respostas são “sim” ou “não”; primeiro vamos distinguir se a questão é de sintaxe comum ou diferença de versão, e então registrar separadamente a versão de referência do JSONL e a versão do código avaliado nas respostas brutas
Esse processo revela que não basta apenas ajustar o prompt de validação; também precisamos revisar a estratégia de prompting e a de coleta de dataset
No futuro, ao criar JSONL, devemos separar claramente critérios de coleta/geração para: sintaxe comum, evidência exclusiva de Godot 3, evidência exclusiva de Godot 4 e evidência bidirecional de migração
Enquanto isso, a conversão de documentação oficial Markdown → JSONL continua; até agora, cerca de 600 dos 1.570 documentos Markdown foram convertidos