2026-06-17 Memoria de la estructura de generación de datos basada en el detector RAG de Godot
Imagen de la estructura

Idea principal
El núcleo de esta estructura es no delegar la decisión final de la etiqueta al LLM. El LLM asume un papel de asistencia en la generación, como código de corrección, explicaciones, preguntas/respuestas SFT, respuestas malas de DPO, borradores de parches, y la asignación/verificación final de la etiqueta y el ensamblaje JSONL lo decide la canalización del sistema local.
En resumen, los principios son los siguientes.
LLM es asistente de generación
La etiqueta la decide el sistema
El JSONL final lo ensambla/verifica la canalizaciónFlujo general
Preparación del documento
-> Construir DB local
-> Ingresar datos fuente de GitHub
-> Extracción de símbolos
-> Búsqueda de reglas/vectores/palabras clave
-> Puntuación y decisión de etiquetas
-> Asistencia en la generación de LLM
-> Generación del JSONL finalEsta estructura es un borrador para crear datos de clasificación de Godot 3/4, mapeo de API, corrección de migración, SFT de instrucciones, preferencia DPO, explorador de repositorios, generación de parches y verificación de metadatos en una única canalización.
1. Preparación de la documentación
En la fase offline se recopilan y refinan los documentos oficiales de Godot.
- Recopilación de la documentación oficial de Godot
- Eliminación de texto innecesario
- Clasificación por tipo de documento
- Análisis basado en la estructura
- Generación de fragmentos de documento
- Construcción de incrustaciones e índices
Productos básicos generados:
docs_chunks.jsonl2. Tres bases de datos clave que se construyen
Base de datos de mapeo de API
Almacena la relación de cambios entre la API de Godot 3 y la API de Godot 4.
Ejemplo:
KinematicBody2D -> CharacterBody2D
yield -> await
export var -> @export
move_and_slide(v) -> move_and_slide()Archivo guardado:
api_mapping.jsonlDocumentación oficial de la base de datos vectorial
Se crean vectores DB a partir de fragmentos de documentos incrustados para la búsqueda basada en evidencia.
Usos:
- Búsqueda de fragmentos de documentación oficial relacionada
- Proporcionar evidencia de transformación
- Explicar razones de cambios en la API
- Reducir alucinaciones
Base de datos prototipo de etiquetas
Se almacena un prototipo para la búsqueda de similitud con candidatos de etiquetas.
Ejemplo de etiquetas:
godot3_code
godot4_code
mixed_code
broken_codeArchivo guardado:
label_prototypes.jsonl3. Búsqueda/Determinación de etiquetas
Cuando llegan los datos originales recopilados en GitHub, el sistema primero analiza el código y la documentación.
Ejemplo de entrada:
repo: owner/repo
file_path: scripts/Player.gd
content: ...
repo_tree: ...El sistema extrae símbolos.
Ejemplo:
KinematicBody2D
move_and_slide(velocity)
export var
yieldA continuación, se realizan las siguientes búsquedas.
- Consultar la base de datos de mapeo de API
- Buscar en la base de datos vectorial de la documentación oficial
- Buscar en la base de datos de prototipos de etiquetas
La etiqueta final se determina mediante puntuación del sistema, no por LLM.
Ejemplo:
label: godot3
confidence: 0.93
bad_apis:
- KinematicBody2D
- move_and_slide(v)
- export var
replacement_apis:
- CharacterBody2D
- move_and_slide()
- @export4. Asistencia para la generación de LLM
LLM no decide la etiqueta directamente, sino que ayuda en la tarea de generación recibiendo como entrada la etiqueta y la justificación determinadas por el sistema.
Tareas de generación posibles:
- Generación de código corregido
- Generación de explicación/justificación
- Generación de preguntas/respuestas SFT
- Generación de respuestas incorrectas DPO
- Generación de respuestas correctas para exploración de archivos
- Asistencia en la generación de parches
- Análisis de verificación/problemas
Los puntos importantes son los siguientes.
Los resultados generados por el LLM son un borrador.
Las etiquetas, el esquema final, la confianza y la verificación son gestionados por el sistema.5. Creación final de JSONL
El pipeline ensambla los resultados del sistema y los resultados generados por LLM en un único objeto JSON.
En la fase de validación se verifica lo siguiente:
- Existencia de campos obligatorios
- Consistencia de etiquetas
- Presencia de API incorrectas residuales
- Recalculado de confidence
- Conexión entre la evidencia del documento y la salida
8 conjuntos de datos generados
1. Datos de clasificación de versiones
Archivo:
version_classification.jsonlContenido:
- Clasificación Godot 3/4/mixed/broken
- Determinación valid_for_godot4
- Extracción de bad_apis
2. Datos de mapeo de API
Archivo:
api_mapping.jsonlContenido:
- old_api -> new_api mapeo
- change_type, category, etc.
3. Datos de respuesta de transformación/modificación
Archivo:
migration_fix.jsonlContenido:
- código before/after
- Razón del cambio
- Lista de configuraciones
4. Preguntas/Respuestas de datos SFT
Archivo:
instruction_sft.jsonlContenido:
- instruction/input/output
- Muestras de varios patrones
5. Datos de preferencia DPO
Archivo:
dpo_preference.jsonlContenido:
- chosen
- rejected
- Razón/Condición
6. Datos del Repo Explorer
Archivo:
repo_explorer.jsonlContenido:
- Predicción de los archivos que deben leerse para resolver tareas/errores
- Razón para leerlos
7. Datos del parche
Archivo:
patch_generation.jsonlContenido:
- before/after
- unified diff / patch
- Razón de aplicación
8. Información meta/validación
Archivo:
metadata_verification.jsonl- confianza
- puntuación
- fundamento
- ID de fragmento del documento fuente
- información de calidad/riesgo
Flujo de resumen de ejecución
GitHub datos fuente
-> Extracción de símbolos
-> Búsqueda de reglas/DB
-> Puntuación de etiquetas
-> Asistencia en la generación de LLM
-> Ensamblado y guardado del JSON finalPrincipios clave
- La etiqueta la decide el sistema.
- El LLM solo desempeña un papel de asistencia en la generación.
- El JSONL final lo ensambla y verifica la canalización.
- Se guardan conjuntamente el documento de referencia, la puntuación, la confianza y la información de origen.
- Se debe comprobar que no quede ninguna API de Godot 3 incorrecta.