2026-07-28 Informe de búsqueda de código fuente real del Flow Debugger
Propósito
En el registro anterior se indicaba que el proyecto real de Godot se había dividido en 134 fragmentos y se había buscado, y que la documentación relacionada estaba incluida en los resultados superiores. Solo con esa expresión no se podía saber qué se devolvió en cada fragmento, si el JSONL devuelto existía realmente en SQLite, o si la documentación más directa estaba en SQLite pero había sido relegada en la clasificación.
Este informe registra por separado las siguientes tres preguntas.
- ¿Qué candidato JSONL devolvió el Source Flow Debugger para cada fragmento?
- ¿El candidato devuelto coincide exactamente con el JSONL original verificado en SQLite?
- ¿La evidencia directa encontrada en todo SQLite apareció en los primeros lugares, o es necesario mejorar la clasificación?
El punto final de Qwen está interrumpido, por lo que esta vez solo se ejecutaron la búsqueda y la comparación con SQLite. No se registró la clasificación de versiones de Godot de Qwen ni los resultados de aprobación/rechazo de candidatos, y el hecho de que apareciera un candidato de búsqueda no se consideró una verificación final exitosa.
Entrada fija
- Repositorio:
godotengine/godot-demo-projects - Licencia: MIT
- Commit:
cae8dc567a56d3e7936f171bcb85f0ccb9634ad0 - Proyecto:
2d/hexagonal_map - Archivos de entrada:
project.godot,map.tscn,tileset.tres,tileset_edit.tscn,troll.gd,troll.tscn - Número de archivos de entrada: 6
- Número de fragmentos generados: 134
- Fragmentos AST: 3
- Fragmentos directos: 131
El SQLite usado en la ejecución esoutputs/godot-rag-sqlite/godot-rag.sqlite3, y en el momento de la ejecución conteníadocs_chunks 2 265 entradas, api_mapping 1 133 entradas,label_prototypes 2 entradas y 3 399 embeddings.
Estado de la ejecución
| Etapa | Estado | Significado de esta ejecución |
|---|---|---|
| SQLite FTS5 + Okapi BM25 | Ejecutado | Se buscaron los 134 fragmentos completos |
| embedding | No ejecutado | No se configuró la clave de la API de embedding |
| reranker | No ejecutado | No se configuró la clave de la API del proveedor |
| Qwen validator | No ejecutado | El punto final de Qwen está detenido |
Por lo tanto, la clasificación siguiente no es la clasificación final de la estrategia F completa, sino el resultado de la fase lexical/BM25.
Resultados de la comparación total
| Ítem | Resultado |
|---|---|
| Fragmentos | 134 |
| Candidatos BM25 devueltos por fragmento | 80 |
| Candidatos devueltos comparados con SQLite | 10 720 |
| Candidatos sin duplicados | 844 |
| Candidatos no encontrados en SQLite | 0 |
Candidatos cuyo provenance no es verified |
0 |
Candidatos cuyo raw_json devuelto difiere del original en SQLite |
0 |
Devoluciones de docs_chunks |
10 713 |
Devoluciones de api_mapping |
7 |
Devoluciones de label_prototypes |
0 |
La consistencia de los datos devueltos era correcta. Cuando se consultaron en SQLite las tablas e IDs mostrados por el Source Flow Debugger, los 10 720 registros existían, su provenance era verified y el raw_json devuelto coincidía con el almacenado.
Sin embargo, eso no significa que la calidad de la búsqueda fuera perfecta. Como los 134 fragmentos llenaron todos los 80 candidatos máximos, los candidatos lexicales no se redujeron lo suficiente. Además, en 9 fragmentos la protección del ancla de nombre de archivo hizo que un documento con puntuación BM25 más baja ascendiera al primer puesto.
Resultados representativos de fragmentos
Casos bien buscados
| Fragmento | Resumen de entrada | Resultado devuelto | Comparación con SQLite |
|---|---|---|---|
| 1 | Descripción del formato del archivo project.godot |
Manually editing project.godot posición 1 |
ID y texto original coinciden |
| 13 | TileMapLayer, tile_map_data, TileSet |
TileMapLayer atributo posición 1, método posición 2, TileData posición 3 |
Todos verificados en docs_chunks |
| 42 | TileSetAtlasSource, región de textura |
TileSetAtlasSource posición 1, TileSetSource posición 2 |
Evidencia de clase directa |
| 125 | _physics_process, Input.get_axis, move_and_slide |
Physics process posición 1, documentos de movimiento 2D posiciones 5‑7, CharacterBody2D posición 8 |
Documentos de movimiento/física presentes |
| 130 | Nodo CharacterBody2D |
Clase CharacterBody2D posición 1 |
Evidencia de clase directa |
El documento en posición 1 del fragmento 1 no alcanzó el primer puesto solo por la puntuación BM25, sino que se mantuvo gracias a la protección del ancla lexical project.godot. En este caso, la descripción del formato del archivo coincidía directamente, por lo que la protección resultó válida.
Casos que necesitan mejora de ranking
Chunk 123: extends CharacterBody2D
- Real 1.º:
Collision exceptions - Documentación de la clase
CharacterBody2D: 17.º - Mapeo
KinematicBody2D -> CharacterBody2D: 6.º
SQLite tenía la documentación exacta de la clase CharacterBody2D, pero se ubicó después de la documentación amplia de colisión·movimiento. No es una falta de datos, sino un problema de ranking. En chunks de declaración corta es necesario tratar el nombre de la clase y los campos estructurales que coinciden perfectamente con mayor fuerza que los tokens de contexto general.
Chunk 124: tan(deg_to_rad(30))
- Real 1.º:
Setting up the spring arm and camera Evaluating expressions: 2.º y 3.º
Aunque la documentación número 1 también contiene un ejemplo de uso de deg_to_rad, no está completamente fuera de contexto; sin embargo, el tutorial 3D superó a la documentación que explica la llamada en sí. Es necesario reordenar para distinguir la explicación de la API directa de los ejemplos de uso simples.
Estructuras candidatas que requieren re‑validación de Qwen
Chunk 13: PackedByteArray incluido en map.tscn
El mapeo PackedByteArray -> byte[] quedó en el puesto 48. El JSONL de guardado describe la migración de colecciones en C#, pero la entrada es un recurso de escena GDScript. Los tokens coinciden, pero el lenguaje y el contexto de aplicación difieren, por lo que no debe aprobarse en la fase de búsqueda final.
Chunk 130: Nodo que ya usa CharacterBody2D
El mapeo KinematicBody2D -> CharacterBody2D quedó en el puesto 3. Este mapeo es relevante para la detección de versiones, pero el chunk actual no contiene la API anterior KinematicBody2D. No es un candidato para advertencia de migración; Qwen debe ver el JSONL y el chunk original y clasificarlo como evidencia de Godot 4 o como no aplicable.
El texto original del JSONL de SQLite se conservó tal cual en reviewCases del informe de lectura automática.
Por qué label_prototypes tiene 0 casos
Los prototipos de SQLite son solo los siguientes dos:
enum PlaneSemanticLabelclass OpenXRSpatialComponentPlaneSemanticLabelList
El chunk hexagonal_map no contenía ninguno de los dos patrones de entrada. Por lo tanto, que label_prototypes sea 0 en esta ejecución no es una omisión, sino el resultado de que el filtro de evidencia estructural actuó directamente.
Conclusión actual
- Se verificó la consistencia de datos entre los candidatos devueltos y el texto original de SQLite.
- Configuraciones de proyecto representativas, TileSet, TileMapLayer y búsquedas de funciones de movimiento incluyeron la documentación relevante en los primeros puestos.
- No todos los chunks alcanzan el límite superior de 80 candidatos, por lo que la reducción de candidatos no es suficiente.
- En declaraciones de clases cortas y llamadas a funciones únicas, se observó que la documentación más directa queda relegada.
- Los mapeos estructurales pueden entrar como candidatos solo por tokens relacionados, de modo que Qwen no puede decidir la aprobación mientras está inactivo.
Criterios para la próxima re‑ejecución
Cuando el endpoint de Qwen esté listo nuevamente, se usarán el mismo commit y los mismos 134 chunks para añadir los siguientes valores:
- Clasificación de cada candidato estructural:
Godot 3,Godot 4,No relacionado,Evidencia insuficiente - Decisión de rechazo para candidatos con desalineación de contexto lingüístico, como
PackedByteArray -> byte[] - Rechazo de candidatos de migración en chunks que ya usan la API objetivo
- Decisión de rechazo para JSONL de control negativo no relacionado
- Cambios en el ranking de documentación directa antes y después de aplicar embedding y reranker