idea_world_labDEV JOURNAL
miércoles, 17 de junio de 2026

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

Imagen de la estructura

Estructura completa de generación de datos basada en el detector RAG de Godot

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ón

Flujo 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 final

Esta 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.jsonl

2. 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.jsonl

Documentació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_code

Archivo guardado:

label_prototypes.jsonl

3. 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
yield

A 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()
  - @export

4. 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.jsonl

Contenido:

  • 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.jsonl

Contenido:

  • old_api -> new_api mapeo
  • change_type, category, etc.

3. Datos de respuesta de transformación/modificación

Archivo:

migration_fix.jsonl

Contenido:

  • código before/after
  • Razón del cambio
  • Lista de configuraciones

4. Preguntas/Respuestas de datos SFT

Archivo:

instruction_sft.jsonl

Contenido:

  • instruction/input/output
  • Muestras de varios patrones

5. Datos de preferencia DPO

Archivo:

dpo_preference.jsonl

Contenido:

  • chosen
  • rejected
  • Razón/Condición

6. Datos del Repo Explorer

Archivo:

repo_explorer.jsonl

Contenido:

  • Predicción de los archivos que deben leerse para resolver tareas/errores
  • Razón para leerlos

7. Datos del parche

Archivo:

patch_generation.jsonl

Contenido:

  • 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 final

Principios 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.