Depurador de Validación Qwen Datos Sintéticos E2E Contrato

Fecha de creación: 15 de julio de 2026

Propósito del documento

Qwen Validation Debugger es una herramienta que permite probar todo el flujo con datos sintéticos antes de que el Retriever y el validador de producción estén terminados.

Para un tema de prueba se crean códigos de Godot 3 y Godot 4, y se generan los JSONL que coinciden y los que no coinciden con esos códigos. Luego se insertan los mismos JSONL en cada versión del código para verificar que la decisión final sea sí o no según corresponda.

No se modificaron el esquema de respuesta ni los tipos de decisión existentes.

Alcance de la gramática: common, separate
Tablas JSONL: docs_chunks, api_mapping, label_prototypes
Ranuras: positive, negative
Decisión final: sí, no

No se añadieron valores de decisión de terceros, puntuaciones ni campos de razones adicionales.

Flujo completo

TEST_ITEM
  -> clasificación común / separada
  -> guardar resultados de clasificación
  -> generar código de versión objetivo
  -> verificar el analizador del motor Godot real
  -> verificar código de sí/no de Qwen
  -> generar JSONL solo con código aprobado
  -> verificar el esquema JSON existente
  -> verificar evidencia directa con el código actual
  -> validación cruzada entre JSONL y código

separate elemento crea primero el código de Godot 3. El código de Godot 4 toma ese código de Godot 3 como REFERENCE_GODOT3_CODE y genera un código correspondiente que mantiene la misma funcionalidad y flujo de ejecución.

Separación de la clasificación y la entrada de generación de código

La respuesta de clasificación mantiene los cinco campos existentes.

{
  "syntax_scope": "common 또는 separate",
  "label": "짧은 한국어 라벨",
  "reason": "분류 근거",
  "godot3_focus": "Godot 3 코드 생성 포인트",
  "godot4_focus": "Godot 4 코드 생성 포인트"
}

reason, godot3_focus, godot4_focus se conservan en la visualización y el registro, pero no se transmiten al prompt de generación de código. Incluso si la fase de clasificación explica una sintaxis de versión incorrecta, se hace para que esa frase no sirva como base factual para la siguiente generación de código.

Para la generación de código solo se utilizan las siguientes entradas:

Elementos de prueba
common o separate
Versión objetivo de generación
Código de Godot 3 que pasó previamente al generar separate Godot 4
En caso de reintento, el código rechazado inmediatamente anterior y el diagnóstico real de la inspección

Contrato de código compuesto

El código generado debe ser un archivo GDScript completo que el motor pueda analizar, no una cadena que parezca un fragmento de código.

La primera línea de ejecución es la declaración extends.
Se utiliza una clase que realmente posee la API de prueba.
Las funciones normales no se anidan dentro de otras funciones.
Se emplea la API de funcionamiento real del elemento de prueba.
No se simula la acción objetivo con pass, comentarios o llamadas locales.
No se mezclan sintaxis exclusivas de versiones opuestas en comentarios o código.
El código de Godot 4 mantiene la funcionalidad, entrada, objetivo y resultados del código de Godot 3 que pasó primero.

Los elementos cuya sintaxis varía claramente entre versiones, como RPC, se incluyen en el prompt como un contrato de sintaxis oficial. Esto no es una lógica de sustitución posterior de palabras en el resultado generado. No se modifica arbitrariamente la cadena de código generada; se inserta tal cual en el analizador del motor.

Inspección real del motor Godot

Qwen pudo haber pasado sintaxis incorrecta simplemente revaluando su propio código. En pruebas reales, hubo casos en los que el código de Godot 3 contenía @rpc de Godot 4 y el verificador de Qwen respondió “sí”.

Actualmente, después de generar el código, se ejecuta inmediatamente el motor real.

Godot 3: --no-window --check-only --script
Godot 4: --headless --check-only --script
common: Verificación en ambos Godot 3 y Godot 4

El archivo ejecutable se puede especificar como GODOT3_BIN o GODOT4_BIN. La instalación local predeterminada se coloca en el directorio de datos del usuario fuera del repositorio. El código a inspeccionar se crea solo como un archivo temporal y se elimina después de la inspección. En el registro de diagnóstico se eliminan la ruta temporal y la ruta del directorio personal del usuario.

La generación y la verificación del código se realizan como máximo tres veces. Si falla, se cambia la semilla para no repetir la misma respuesta, y el código anterior junto con el diagnóstico real del motor se incluyen en el siguiente prompt de generación.

Mantener el esquema JSONL

Los campos de nivel superior son los mismos que los de las tres definiciones de tabla existentes.

docs_chunks

chunk_id, doc_version, source_url, source_file, source_sha256,
doc_type, symbol, section_path, heading, content, code_blocks,
language_tags, godot_version_tags, api_symbols, token_count, metadata

api_mapping

mapping_id, source_api, target_api, change_type, godot_from,
godot_to, confidence, evidence_chunk_ids, match_terms, notes,
negative_patterns

label_prototypes

prototype_id, label, task_type, input_pattern, expected_finding,
recommended_action, evidence_mapping_ids, evidence_chunk_ids,
severity, validator_rules

validator_rules también usa solo los cuatro campos existentes.

{
  "required_when_seen_in_code": [],
  "before_code": "",
  "after_code": "",
  "reject_when_seen_in_code": []
}

Después de recibir la respuesta, se verifica el esquema JSON original para campos obligatorios, tipos, enum y si hay campos adicionales. Si el modelo escribe confidence como número o section_path como cadena, se rechaza y se vuelve a generar hasta un máximo de tres veces.

generación de positivo y negativo

El JSONL positivo utiliza evidencia directa del código compuesto actual.

docs_chunks: describe directamente el propósito, objetivo, flujo de entrada y resultado del código.
api_mapping: el source_api de Godot 3 y el target_api de Godot 4 deben estar presentes en el código real respectivamente.
label_prototypes: la evidencia before debe estar en el código de Godot 3, la evidencia after en el código de Godot 4.
Los negative_patterns y reject_when_seen_in_code del positivo son arreglos vacíos.

Para generar JSONL negativo no se proporciona el código actual ni el ítem actual. Se selecciona dinámicamente el ítem de muestra siguiente al ítem actual como NEGATIVE_TEST_ITEM y se crea el JSONL solo con ese otro ítem. Después de la generación, el servidor compara directamente con el código actual y rechaza si la evidencia source/before se superpone.

Este proceso no sustituye nombres de API o frases uno a uno. Solo se usan la selección del orden de muestra y la comparación de cadenas del resultado real.

orden de verificación

La verificación se procesa en el siguiente orden.

Si el resultado queda determinado por la estructura de ranura de versión, se juzga como no sin llamar al modelo.
Si no hay ninguna evidencia directa de la migración previa en el código actual, se juzga como no.
Sólo si no se cumplen los dos criterios anteriores, Qwen compara el significado y el modo de uso.

La puerta determinista no crea un nuevo estado. El valor de retorno sigue siendo sí o no como antes.

JSONL	objetivo de verificación	respuesta esperada
`docs_chunks` positivo de la misma versión	código de referencia	sí
`docs_chunks` positivo de versión diferente	código cruzado	no
`docs_chunks` negativo	cualquier código	no
migración `3 -> 4` positivo	código Godot 3	sí
migración `3 -> 4` positivo	código Godot 4	no
migración `3 -> 4` negativo	cualquier código	no

robustez de la solicitud API

Desactivar la salida de thinking.
Clasificación, código y JSONL solicitan respuestas con el esquema JSON que solo contiene los campos existentes.
El juicio final permite solo sí o no mediante gramática.
La regeneración de código y JSONL cambia la semilla.
HTTP 429, 502, 503, 504, cierre de conexión y tiempo de espera de la solicitud se reintentan hasta tres veces.

La clave API solo se incluye en la solicitud con el valor actual ingresado en la memoria del navegador. No se registra en repositorios, documentos, logs o commits.

resultados del examen del 15 de julio de 2026

Se aprobaron 27 pruebas unitarias de contrato.

En la inspección real del motor Godot se verificó lo siguiente.

El código remote func de Godot 3 pasó el analizador de Godot 3.
Al agregar @rpc al código de Godot 3, fue rechazado con Unexpected '@'.
El código @rpc de Godot 4 pasó el analizador de Godot 4.

Los resultados del examen RunPod Qwen fueron:

E2E total inicial: 5/12 aprobados. Se detectó código compuesto de Godot 3 incorrecto y juicios de alta correlación.
Después de aplicar la inspección del motor y el contrato de generación: 10/12 aprobados.
Con ítems negativos dinámicos y puerta de cadena directa aplicada, migración negativa: 4/4 aprobados.
Los 2 casos restantes fueron ejemplos donde el modelo ignoró la cláusula de ranura que impide volver a aplicar la migración positiva a Godot 4. Esa condición se trasladó a una puerta de versión determinista y las pruebas unitarias la aprobaron.
Se inició una re‑prueba total, pero el servicio RunPod devolvió HTTP 502 en /v1/models y en la solicitud de generación, interrumpiendo el proceso. No fue un rechazo de código o JSONL, sino una falta de respuesta del servicio remoto.

Si el servicio remoto vuelve a responder, se deberá volver a ejecutar desde cero los 12 casos E2E.