2026-07-28 Relatório de Busca de Fonte Real

Objetivo

Nos registros anteriores, foi anotado apenas que o projeto Godot real foi dividido em 134 blocos e pesquisado, e que a documentação relacionada foi incluída nos resultados superiores. Apenas com essa afirmação não era possível saber o que foi retornado em cada bloco, se o JSONL retornado realmente existia no SQLite, ou se a documentação mais direta estava no SQLite mas foi rebaixada na classificação.

Este relatório registra separadamente as três perguntas a seguir.

O Source Flow Debugger retornou quais candidatos JSONL em cada bloco?
Os candidatos retornados são exatamente os mesmos JSONL originais verificados no SQLite?
As evidências diretas encontradas em todo o SQLite apareceram no topo, ou a classificação precisa ser melhorada?

O endpoint Qwen está indisponível, portanto, desta vez executamos apenas a busca e a comparação com o SQLite. Não registramos a classificação da versão Godot do Qwen nem os resultados de aprovação/rejeição de candidatos; o fato de um candidato ter sido encontrado não é tratado como verificação final bem‑sucedida.

Entrada fixa

Repositório:
godotengine/godot-demo-projects
Licença: MIT
Commit: cae8dc567a56d3e7936f171bcb85f0ccb9634ad0
Projeto: 2d/hexagonal_map
Arquivos de entrada: project.godot, map.tscn, tileset.tres,
tileset_edit.tscn, troll.gd, troll.tscn
Número de arquivos de entrada: 6
Número de blocos gerados: 134
Blocos AST: 3
Blocos diretos: 131

O SQLite usado na execução foi
outputs/godot-rag-sqlite/godot-rag.sqlite3, contendo, no momento da execução, 2.265 registros em docs_chunks, 1.133 em api_mapping, 2 em label_prototypes e 3.399 embeddings.

Estado da execução

Etapa	Status	Significado desta execução
SQLite FTS5 + Okapi BM25	Executado	Todas as 134 blocos foram pesquisadas
embedding	Não executado	Não foi configurada a chave da API de embedding
reranker	Não executado	Não foi configurada a chave da API do provider
Qwen validator	Não executado	O endpoint Qwen está interrompido

Portanto, a classificação abaixo não representa a classificação final da estratégia F completa, mas sim o resultado da fase lexical/BM25.

Resultado geral da comparação

Item	Resultado
Blocos	134
Candidatos BM25 retornados por bloco	80
Candidatos retornados comparados ao SQLite	10.720
Candidatos após remoção de duplicatas	844
Candidatos não encontrados no SQLite	0
Candidatos cujo provenance não é `verified`	0
Candidatos cujo `raw_json` difere do SQLite	0
Retornos de `docs_chunks`	10.713
Retornos de `api_mapping`	7
Retornos de `label_prototypes`	0

A consistência dos dados retornados estava correta. Quando as tabelas e IDs mostrados pelo Source Flow Debugger foram consultados novamente no SQLite, os 10.720 registros existiam, o provenance era verified e o raw_json retornado coincidiu com o armazenado.

Entretanto, isso não significa que a qualidade da busca esteja perfeita. Como os 134 blocos preencheram todos os 80 candidatos máximos, os candidatos lexicais não foram suficientemente filtrados. Além disso, em 9 blocos, a proteção de âncora de nome de arquivo fez com que um documento com pontuação BM25 mais baixa fosse promovido ao primeiro lugar.

Resultados de blocos representativos

Casos bem pesquisados

Bloco	Resumo da entrada	Resultado retornado	Comparação SQLite
1	Descrição do formato do arquivo `project.godot`	`Manually editing project.godot` em 1º lugar	ID e texto original coincidem
13	`TileMapLayer`, `tile_map_data`, `TileSet`	`TileMapLayer` atributo 1º, método 2º, `TileData` 3º	Todos verificados em `docs_chunks`
42	`TileSetAtlasSource`, região de textura	`TileSetAtlasSource` 1º, `TileSetSource` 2º	Evidência direta da classe confirmada
125	`_physics_process`, `Input.get_axis`, `move_and_slide`	`Physics process` 1º, documentos de movimento 2D 5º‑7º, `CharacterBody2D` 8º	Documentação de movimento/física presente
130	Nó `CharacterBody2D`	Classe `CharacterBody2D` 1º	Evidência direta da classe confirmada

O documento em 1º lugar do bloco 1 não ficou no topo apenas por pontuação BM25; foi mantido graças à proteção da âncora lexical project.godot. Nesse caso, a descrição do formato do arquivo corresponde exatamente, confirmando que a proteção foi válida.

Caso que precisa de melhoria de ranking

Chunk 123: `extends CharacterBody2D`

Primeiro lugar real: Collision exceptions
Documentação da classe CharacterBody2D: 17º lugar
Mapeamento KinematicBody2D -> CharacterBody2D: 6º lugar

O SQLite continha a documentação exata da classe CharacterBody2D, mas ela foi posicionada depois da documentação ampla de colisão·movimento. Não se trata de falta de dados, mas de problema de ranking. Em chunks curtos de declaração, nomes de classe e campos estruturais que correspondem exatamente precisam ser tratados com mais força do que tokens de contexto geral.

Chunk 124: `tan(deg_to_rad(30))`

Primeiro lugar real: Setting up the spring arm and camera
Evaluating expressions: 2º e 3º lugares

Mesmo que a documentação de primeiro lugar contenha um exemplo de uso de deg_to_rad, não é totalmente irrelevante, porém o tutorial 3D ficou à frente da documentação que explica a própria chamada. É necessário reordenar para distinguir entre explicação de API e exemplo de uso simples.

Estrutura candidata que precisa de revalidação pelo Qwen

Chunk 13: `PackedByteArray` incluído em `map.tscn`

O mapeamento PackedByteArray -> byte[] ficou em 48º lugar. O JSONL de armazenamento descreve migração de coleções C#, mas a entrada é um recurso de cena GDScript. Os tokens coincidem, porém linguagem e contexto de aplicação são diferentes, portanto não deve ser aprovado na fase de busca final.

Chunk 130: Nó que já usa `CharacterBody2D`

O mapeamento KinematicBody2D -> CharacterBody2D ficou em 3º lugar. Esse mapeamento é relevante para detecção de versão, mas o chunk atual não contém a API anterior KinematicBody2D. Não é um candidato a aviso de migração; o Qwen deve analisar JSONL e o chunk original e classificar como justificativa do Godot 4 ou como desnecessário.

O texto original do SQLite JSONL desses dois casos foi preservado intacto em reviewCases do relatório de leitura automática.

Por que `label_prototypes` tem 0 ocorrências

Os protótipos no SQLite são apenas os dois seguintes:

enum PlaneSemanticLabel
class OpenXRSpatialComponentPlaneSemanticLabelList

O chunk hexagonal_map não continha nenhum desses padrões de entrada. Portanto, o fato de label_prototypes ser 0 nesta execução não é uma omissão, mas o resultado esperado do filtro de base estrutural direto.

Conclusão atual

A consistência dos dados entre os candidatos retornados e o texto original do SQLite foi confirmada.
Configurações de projeto representativas, TileSet, TileMapLayer e buscas de funções de movimento incluíram documentos relevantes nas posições superiores.
Nem todos os chunks atingiram o limite superior de 80 candidatos, portanto a redução de candidatos não foi suficiente.
Em declarações de classe curtas e chamadas de função únicas, documentos mais diretos foram empurrados para posições inferiores.
Como o mapeamento estrutural pode entrar como candidato apenas pelos tokens relacionados, o Qwen não pode decidir sobre aprovação enquanto está offline.

Critérios para a próxima reexecução

Quando o endpoint do Qwen estiver novamente disponível, usar o mesmo commit e os mesmos 134 chunks para acrescentar os seguintes itens:

Classificação de cada candidato estrutural como Godot 3, Godot 4, Não relacionado ou Base insuficiente
Decisão de rejeição para candidatos com incompatibilidade de contexto de linguagem, como PackedByteArray -> byte[]
Rejeição de candidatos de migração em chunks que já utilizam a API alvo
Decisão de rejeição para JSONL de controle negativo que não são relevantes
Mudança no ranking dos documentos diretos antes e depois da aplicação de embedding e reranker