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, em vez de um design definitivo, reunimos os prós e contras de cada método de busca obtidos via ChatGPT e respostas de fluxo 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 em cada tabela: docs_chunks, api_mapping e label_prototypes
Em cada tabela, dividiremos aproximadamente 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 o processo é manual, a quantidade real de testes é muito maior do que o esperado
Criamos 50 itens de teste para Godot e, para cada um, precisamos validar as três tabelas: docs_chunks, api_mapping e label_prototypes
Se for uma função/comando comum, criamos um 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 conjuntos de dados para observar como o padrão de resposta varia
Caso não seja comum, devemos produzir códigos separados para Godot 3 e Godot 4, dobrando efetivamente o esforço
Para resumir os resultados posteriormente em métricas de classificação como F1‑score, será necessário registrar manualmente o resultado true/false de todos os casos
Concluímos que terminar os 50 itens em um único dia é inviável; portanto, o objetivo de hoje foi reduzir para 5 itens
Após completar os 5, em vez de simplesmente aumentar a quantidade de testes, vamos primeiro analisar os padrões de resposta 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 validar código de Godot 4 devido a trechos comuns ou justificativas de migração, e vice‑versa, quando strings de origem/alvo 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/não; primeiro distinguiremos se o caso se trata de sintaxe comum ou diferença de versão, e então registraremos separadamente a versão de geração do JSONL e a versão do código avaliado como estratégia de registro bruto
Esse processo revelou 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: sintaxe comum, justificativas exclusivas para Godot 3, justificativas exclusivas para Godot 4 e justificativas bidirecionais de migração, para evitar mistura nos critérios de coleta/geração
Paralelamente, a conversão de documentação oficial de Markdown → JSONL continua; até hoje, cerca de 600 dos 1 570 documentos Markdown foram convertidos em JSONL