Registro de estrategia e implementación del depurador de validación de Qwen

Fecha de creación: 30 de junio de 2026

Propósito

Este documento registra la razón por la que se creó tools/qwen-validation-debugger y el flujo de funcionamiento real.

El 28 de junio se crearon manualmente fragmentos de código de Godot y archivos JSONL con Qwen, y se concatenó directamente prompt + fragmento de código + JSONL para verificar cómo aparecían los resultados de “sí”/“no”. Este método fue útil para orientarse, pero a medida que aumentaba la cantidad de ítems, el costo de copiar manualmente, recordar los criterios de generación y comparar los resultados se volvió demasiado alto.

Por eso, el 30 de junio se convirtió este proceso en una herramienta web independiente. El objetivo de esta herramienta no es el entrenamiento final del modelo, sino permitir rastrear visualmente la relación entre el código de prueba generado por Qwen y el JSONL, y detectar rápidamente decisiones incorrectas de “sí”/“no”.

Pantalla actual

La herramienta se ejecuta en http://localhost:8520/.

La pantalla se divide en tres áreas principales.

• Izquierda: lista de verificación de 50 ítems de prueba de Godot
• Centro/parte superior derecha: etiqueta de IA y resultado de generación de código de Godot del ítem seleccionado
• Parte inferior: ranuras de generación/validación de JSONL para docs_chunks, api_mapping, label_prototypes

Por qué se necesitó una herramienta independiente

Originalmente se le pidió directamente al chatbot de Qwen lo siguiente.

Crearé un fragmento de código de Godot,  
generaré un JSONL correcto y uno incorrecto según el formato `docs_chunks/api_mapping/label_prototypes`.  
Y verificaré que al combinar `SOURCE_CODE` con el JSONL la respuesta sea **sí** o **no** correctamente.

Sin embargo, al realizar pruebas manuales, descubrí que había más ejes que verificar de lo que pensé.

Si la sintaxis es común, hay 6 ranuras.

Código común
  docs_chunks       Explicación base / Otra descripción de código
  api_mapping       Común/Innecesario / Conversión irrelevante
  label_prototypes  Común/Innecesario / Conversión irrelevante

Si es una sintaxis de separación de versiones, hay 12 ranuras.

Godot 3 código
  docs_chunks       explicación base / otra descripción de código
  api_mapping       conversión necesaria / conversión no aplicable
  label_prototypes  conversión necesaria / conversión no aplicable

Godot 4 código
  docs_chunks       explicación base / otra descripción de código
  api_mapping       ya aplicado / conversión no aplicable
  label_prototypes  ya aplicado / conversión no aplicable

Si se sigue creando esto manualmente, se dedica más tiempo a copiar/pegar y organizar los resultados que a la propia prueba. Por eso, se agruparon los ítems, el código, el JSONL y los resultados de validación en una sola pantalla mediante una GUI.

Flujo completo

flowchart TD
  A["50 ítems de prueba"] --> B["Seleccionar ítem"]
  B --> C["Etiquetado Qwen"]
  C --> D{"¿Es sintaxis común?"}
  D -->|"común"| E["Generar código común"]
  D -->|"separado"| F["Generar código Godot 3"]
  D -->|"separado"| G["Generar código Godot 4"]
  E --> H["6 ranuras JSONL"]
  F --> I["6 JSONL según Godot 3"]
  G --> J["6 JSONL según Godot 4"]
  I --> K["Validar código Godot 3"]
  I --> L["Validar código Godot 4"]
  J --> K
  J --> L
  H --> M["Validar código común"]

Herramienta llama a Qwen en tres roles diferentes.

Etapa de etiquetado

Al hacer clic en un ítem, Qwen primero decide si se trata de sintaxis común o separación por versión.

Por ejemplo, _process(delta) se usa tanto en Godot 3 como en Godot 4 como función de actualización de fotogramas, por lo que puede considerarse sintaxis común.

En cambio, Aplicar velocidad y aceleración de movimiento del jugador puede variar en la forma de llamar a move_and_slide() según el cuerpo físico, por lo que se crean códigos separados para Godot 3 y Godot 4.

Diseño de slots JSONL

Al principio, los slots se dividían simplemente en JSONL correcto y JSONL incorrecto. Sin embargo, ese criterio era demasiado grueso.

docs_chunks son evidencias explicativas. Por lo tanto, si la explicación coincide directamente con el código, la respuesta es Sí; si el documento explica otro comportamiento de código, la respuesta es No.

Pero api_mapping y label_prototypes no son simples explicaciones, sino evidencias de transformación al pasar de Godot 3 a Godot 4. Así, si un código ya escrito para Godot 4 contiene api_mapping o label_prototypes marcados como Sí, podría leerse como “ya está en Godot 4 y aún así se pide migrar”.

Por eso, cambiamos los nombres de los slots de la siguiente manera.

Gracias a este criterio, Sí/No dejó de ser una simple valoración de relevancia y pasó a ser una valoración acorde al propósito de cada tabla.

Separación del código base de generación y del código objetivo de verificación

Lo que más cambió hoy es este punto.

En la primera implementación, un slot solo se verificaba contra su propio código.

JSONL creado con código de Godot 3  
  -> Verificado solo en código de Godot 3  

JSONL creado con código de Godot 4  
  -> Verificado solo en código de Godot 4

Sin embargo, la verificación realmente necesaria es más amplia que esto.

El JSONL creado con código de Godot 3 debe producir 아니오 cuando se adjunta al código de Godot 4. Por el contrario, también se debe observar qué resultado se obtiene cuando el JSONL creado con código de Godot 4 se adjunta al código de Godot 3. Así se puede detectar el problema en el que las cadenas source/target se mezclan y aparecen 예 incorrectamente.

Por eso, el botón se dividió de uno a dos.

Ahora cada ranura del elemento de separación de versiones puede realizar todas las verificaciones siguientes.

Godot 3 código generado JSONL  
  -> Verificación de código Godot 3  
  -> Verificación de código Godot 4  

Godot 4 código generado JSONL  
  -> Verificación de código Godot 3  
  -> Verificación de código Godot 4

Dentro de la herramienta se separa de la siguiente manera.

Criterio de cálculo de la respuesta esperada

Los resultados de la verificación siguen recibiéndose de Qwen como sí o no. Sin embargo, la respuesta esperada ya no se calcula mirando solo una ranura, sino considerando tabla + versión base para generar el JSONL + versión objetivo de la verificación + naturaleza de la ranura.

Este criterio no es la norma final de evaluación, sino una guía de depuración para observar dónde falla el emparejamiento de argumentos de Qwen en esta etapa.

Cambios en el prompt de verificación

En el prompt de verificación ahora se incluyen dos piezas de información de versión.

JSONL_GENERATED_FROM_CODE_VERSION:
godot3

VERIFY_TARGET_CODE_VERSION:
godot4

Así se incluye para evitar que Qwen responda “sí” simplemente porque target_api dentro del JSONL coincide con el código actual.

En api_mapping y label_prototypes son importantes los siguientes criterios.

• source_api, source_pattern, input_pattern, before_code, required_when_seen_in_code deben estar presentes directamente en el código actual para que sea sí.
• Si solo coinciden target_api, after_code o la forma del objetivo recomendada con el código actual, ya está aplicado, por lo que la respuesta es no.
• Cuando indica que no se necesita transformación, como signature_stable, no_change, common, la respuesta es no.
• Si el JSONL de migración se adjunta a código de Godot 4 o a código de sintaxis común y no requiere transformación adicional, la respuesta es no.

Registro de pruebas de 50 ítems

1/50 Inicialización de la función _ready() y configuración del tamaño del viewport

El 3 de julio se verificó primero el ítem 1 de los 50 ítems de prueba. Este ítem se etiquetó como código común, y el código de referencia era el siguiente.

func _ready():
    var vp_size = get_viewport().get_visible_rect().size
    position = Vector2(vp_size.x / 2, vp_size.y / 2)

Al principio, el slot incorrecto de docs_chunks se llamaba JSONL de descripción irrelevante. Sin embargo, al probarlo, descubrimos que ese nombre no era preciso. Este slot no sirve para crear intencionalmente JSONL extraños o incorrectos, sino para colocar descripciones de documentación oficial que el Retriever pueda traer como candidatos de búsqueda y ver si Qwen las descarta en la verificación final.

Por lo tanto, el significado de este slot se resumió como JSONL de descripción de otro código.

En esta prueba, el JSONL problemático describía Viewport.get_visible_rect y _ready(), pero el contenido real trataba sobre otras operaciones de código como safe area, UI scaling, $Label, $Button.rect_position. SOURCE_CODE lee el tamaño del viewport y mueve la position del nodo actual al centro de la pantalla, por lo que, aunque algunas API se superpongan, no se puede considerar como evidencia directa.

La respuesta esperada era “No”, pero Qwen devolvió “Sí”. La causa fue que el prompt de verificación interpretaba “coincidencia exacta con la cadena/API real” de forma demasiado amplia, aceptando como evidencia directa descripciones de documentos que contenían la misma API.

Cambios realizados

• Cambiar el nombre del slot incorrecto de docs_chunks de JSONL de descripción irrelevante a JSONL de descripción de otro código.
• En el prompt de generación de JSONL, definir este slot como “un JSONL tipo documentación oficial que puede compartir algunas API/temas con los candidatos de búsqueda, pero que en realidad describe el comportamiento de otro código”.
• Fortalecer el prompt de verificación: el criterio de “Sí” para docs_chunks ya no será una simple coincidencia de cadena de API, sino que debe coincidir directamente con el propósito central del código, el objeto objetivo y el resultado final.
• Incluso si aparecen la misma API o el mismo método, si el JSONL explica un propósito, objeto o resultado diferente, se considerará solo un candidato de búsqueda y se marcará “No”.
• Ajustar las etiquetas del slot y el texto de vista previa en la UI frontal según el mismo criterio.
• Añadir pruebas en core.test.js para asegurar que este criterio se mantenga en los prompts.

2/50 _process(delta) bucle de actualización por fotograma

El 3 de julio se verificó el segundo ítem. Este ítem fue etiquetado por Qwen como código común.

Resumen de la etiquetación:

syntax_scope: common
label: _process(delta) actualización por fotograma
reason: En Godot 3 y 4, la firma y la forma de invocación de la función _process(delta) son idénticas, y no hay diferencias sintácticas al escribir lógica por fotograma.

Resultado de la verificación: los 6 slots coincidieron con la respuesta esperada.

Este ítem se registra como un caso en el que la gramática común funcionó correctamente: docs_chunks se marcó como sí por ser evidencia explicativa, mientras que api_mapping y label_prototypes se marcaron como no al considerarse transformaciones comunes/innecesarias o no relacionadas.

3/50 Procesamiento de entrada de movimiento del jugador

El ítem 3 fue etiquetado por Qwen como código de separación de versiones.

Resumen de etiquetado:

syntax_scope: separate
label: Entrada de movimiento del jugador
reason: Aunque la verificación de entrada es similar, debido a la introducción de Input.get_vector() en Godot 4 y al cambio en la firma de move_and_slide() de CharacterBody2D, es necesario separar la estructura del código.
godot3_focus: Herencia de KinematicBody2D, cálculo manual de velocity.x/y y llamada a move_and_slide(up_direction)
godot4_focus: Herencia de CharacterBody2D, simplificación del movimiento diagonal con Input.get_vector() y eliminación de parámetros en move_and_slide()

Resultado de la verificación:

No coinciden:

Observación del prompt:

En la búsqueda híbrida es natural que aparezcan candidatos JSONL similares al fragmento de código. Por lo tanto, el prompt de verificación debe juzgar si el candidato de búsqueda constituye una base para aplicar realmente al CÓDIGO_FUENTE actual. Las tres discrepancias indican que la pregunta no estaba suficientemente fijada, de modo que Qwen interpretó api_mapping y label_prototypes como una coincidencia de relevancia amplia en lugar de una necesidad de migración.

En particular, el caso 3 reveló los siguientes problemas:

• Si un nombre de función que puede aparecer tanto en Godot 3 como 4 (por ejemplo, move_and_slide) coincide por sí solo, Qwen tiende a inclinarse a “Sí”.
• Cuando se adjunta un JSONL basado en Godot 3 al código de Godot 4, si el código ya está transformado, label_prototypes · conversión necesaria no debe devolver “Sí”.
• Cuando se adjunta un JSONL de conversión irrelevante basado en Godot 4 al código de Godot 3, tampoco debe devolver “Sí” si la conversión no se aplicará realmente al código actual.
• El punto clave no es el método de generación del JSONL, sino la pregunta de verificación. Se debe determinar si el código actual es pre‑cambio, post‑cambio o una transformación totalmente distinta.

Por ello, se modificó el criterio del prompt de la siguiente manera:

• Cambiar la pregunta de verificación de “¿JSONL y código están relacionados?” a “¿Debe aplicarse una migración al CÓDIGO_FUENTE actual basándose en este JSONL?”.
• Si el CÓDIGO_FUENTE actual ya está en la forma objetivo de Godot 4, aunque el JSONL parezca relacionado con la explicación de migración, se debe indicar “No” porque “ya está aplicado”.
• label_prototypes · conversión necesaria solo debe marcar “Sí” cuando el CÓDIGO_FUENTE actual contiene realmente el modo de uso, la composición de argumentos y el patrón de llamada anteriores.
• Un JSONL de conversión irrelevante debe marcar “No” incluso si el objetivo de verificación es código de Godot 3, siempre que la conversión no se aplique al CÓDIGO_FUENTE actual.
• Cada campo del JSONL constituye el contexto de juicio. En la fase de verificación se observa ese contexto para decidir si el CÓDIGO_FUENTE está en estado pre‑cambio o post‑cambio.
• Como source_api y target_api pueden compartir el mismo nombre o match_terms puede contener términos de origen/objetivo, solo una coincidencia de nombre de función o de términos amplios no basta para responder “Sí”.
• Incluso si el nombre de la función coincide, deben coincidir también los argumentos de llamada, el manejo del valor de retorno, los nodos heredados y la estructura circundante del código; solo entonces se marca “Sí”.
• Si JSONL_GENERATED_FROM_CODE_VERSION y VERIFY_TARGET_CODE_VERSION difieren, se debe indicar primero si el CÓDIGO_FUENTE actual corresponde al código previo o ya está transformado.

4/50 Aplicación de velocidad y aceleración del jugador

El ítem 4 también fue etiquetado por Qwen como código separado por versiones.

Resumen de la etiquetación:

syntax_scope: separate
label: Aplicación de velocidad y aceleración de movimiento del jugador
reason: En Godot 4, el nodo físico cambió de KinematicBody a CharacterBody, y la firma de move_and_slide() cambió a pasar argumentos, lo que altera la estructura del código.
godot3_focus: Asignar velocidad a la propiedad velocity y luego llamar a move_and_slide(), usando KinematicBody2D/3D
godot4_focus: Pasar argumentos con move_and_slide(velocity), usar CharacterBody2D/3D, y aplicar aceleración usando lerp() o move_toward()

Resultado de la verificación:

Desajustes:

Observación del prompt:

Los desajustes en el caso 4 fueron menos que en el caso 3, pero la causa es la misma. Cuando los nombres de funciones source y target son iguales o similares en api_mapping, Qwen puede otorgar Sí basándose en una evaluación amplia de relevancia de que “este JSONL describe el cambio de la función”. Sin embargo, lo que esta herramienta necesita no es una evaluación de relevancia, sino determinar si es necesario aplicar una migración al código actual.

Por lo tanto, basándose en las observaciones hasta el caso 4, el prompt de verificación se reforzó para considerar lo siguiente además de la simple coincidencia de nombres de API:

• si el código actual realmente contiene el patrón previo al cambio del JSONL
• incluso con el mismo nombre de función, si los argumentos de llamada y el manejo de valores de retorno coinciden con el código previo al cambio
• si el código objetivo de verificación ya está en la forma posterior al cambio, si la necesidad de migración es No
• que un JSONL de conversión irrelevante no sea marcado como Sí solo por simple relevancia

Límite máximo de velocidad del jugador 5/50

El ítem 5 fue etiquetado por Qwen como código de separación de versiones.

Resumen del etiquetado:

syntax_scope: separate
label: Velocidad máxima del jugador
reason: Se necesita código separado debido al cambio de nombre de clase entre KinematicBody2D de Godot 3 y CharacterBody2D de Godot 4, y a las diferencias en la firma del método move_and_slide() y la forma de pasar la velocidad.
godot3_focus: Herencia de KinematicBody2D, asignar la velocidad a self.velocity y luego llamar a move_and_slide(), limitar la velocidad con limit_length()
godot4_focus: Herencia de CharacterBody2D, asignar la velocidad a la variable velocity y pasarla explícitamente a move_and_slide(velocity), aplicar limit_length()

Flujo de código generado:

Resultados de la verificación:

Incongruencia:

Observaciones del prompt:

El caso 5 se asemeja a una situación que puede ocurrir en la búsqueda híbrida. Más adelante, al buscar en la base de datos, no solo aparecerá un JSONL completamente irrelevante, sino que también pueden aparecer candidatos similares del mismo API o del mismo manejo de movimiento/velocidad. En ese momento, el prompt de verificación debe preguntar “¿Este JSONL describe directamente el comportamiento real del SOURCE_CODE actual?” en lugar de “¿Es un candidato de búsqueda similar?”.

En este caso 5, api_mapping y label_prototypes funcionaron según lo esperado en ambas verificaciones de Godot 3/4. En particular, cuando se adjuntó a un JSONL ya aplicado al código de Godot 4 o de naturaleza no_change, pattern_validation, la respuesta fue “No”, lo que puede considerarse una señal de que se mitigaron parcialmente los problemas de juicio de migración observados en los casos 3 y 4.

Por el contrario, docs_chunks aún necesita más análisis. Dado que docs_chunks se refiere a la coincidencia de la base de explicación y no a la aplicación de la migración, si solo el nombre del API o la pista de versión coinciden y la respuesta es “Sí”, quedará ruido en la fase de verificación de candidatos de búsqueda híbrida. Por lo tanto, en futuros prompts de verificación se debe confirmar con mayor rigor que el propósito, el objeto objetivo y el estado resultante del SOURCE_CODE coincidan realmente con la descripción del JSONL para docs_chunks.

6~10/50 registro de validación adicional

Del 6 al 10 se registra primero el resultado y luego se corrige el prompt de validación. En esta fase solo se indica en qué ranura la herramienta acierta o falla, sin modificar el prompt.

Resumen general:

Resumen por ítem:

Los casos 6, 9 y 10 coincidieron totalmente con los valores esperados. En el caso 6, los flujos de Godot 3 (PackedScene.instance(), Input.is_mouse_button_pressed(1), get_viewport().get_mouse_position()) y de Godot 4 (instantiate(), InputEventMouseButton, get_global_mouse_position()) se separaron, y las opciones correctas e incorrectas se distinguieron adecuadamente. En el caso 9, las variantes de versión para movimiento y rotación del enemigo también fueron evaluadas según lo esperado. El caso 10 se clasificó como sintaxis común; la gestión fuera de la pantalla basada en get_viewport_rect().size, global_position, hide() tiene documentación que respalda “sí”, mientras que la migración de tipo api_mapping/label_prototypes se marcó como “no”.

Incongruencias:

Observación:

Al observar los casos 6~10, hay señales de mejora global. De 102 validaciones, 97 coincidieron con lo esperado y los casos 6, 9 y 10 fueron aprobados. En particular, el caso 10 (sintaxis común) mostró que tanto api_mapping como label_prototypes fueron marcados “no”, lo que indica que la política de no añadir justificaciones de migración a código común está funcionando.

Las incongruencias restantes se dividen en dos grupos. El primero, como el caso 7, ocurre cuando una justificación de migración basada en Godot 3 se marca “sí” también en código de Godot 4; aquí es necesario preguntar con mayor claridad si el código actual ya está transformado o no. El segundo, como el caso 8, ocurre cuando candidatos de docs_chunks aparecen como “sí” por temas o APIs similares; se debe discernir si la evidencia describe directamente la ejecución del código fuente o simplemente es un candidato de búsqueda parecido.

Es importante notar que no se trata de bloquear cadenas específicas o candidatos concretos. Cuando se inserten JSONL en la base de datos y se recupere mediante búsqueda híbrida, es normal que aparezcan candidatos similares pero diferentes. Por lo tanto, las correcciones posteriores deben enfocarse en que el prompt de validación evalúe con mayor precisión la relación entre el código fuente actual y los candidatos recuperados, no en filtrar manualmente.

Mejoras al prompt de validación aplicadas después del registro:

• En docs_chunks se añadió una verificación previa: cuando la versión de generación del JSONL difiere de la versión del objetivo de validación, se comprueba primero si el JSONL explica el comportamiento del código de la versión objetivo.
• Aunque una explicación pueda ser “sí” al describir una API/comportamiento común entre versiones, si el candidato describe diferencias estructurales o de nodos/API entre versiones, se verifica separadamente si coincide con el código fuente actual.
• En api_mapping y label_prototypes se añadió una primera fase para determinar si el código fuente actual es código previo a la migración, código ya migrado, código irrelevante o código que no necesita transformación.
• La respuesta “sí” solo se permite cuando el código fuente actual es pre‑migración y la transformación descrita por el JSONL debe aplicarse ahora.
• Estas mejoras no se centran en el manejo de cadenas específicas, sino en reforzar el proceso de evaluación de los candidatos traídos por la búsqueda híbrida según el código actual.

Verificación de resultados

Los resultados de la validación se muestran por cada ranura, separados por versión.

Con este método, dentro de una misma ranura se puede observar inmediatamente lo siguiente.

Godot 3 código de verificación antes / respuesta / expectativa / coincidencia  
Godot 4 código de verificación antes / respuesta / expectativa / coincidencia

Anteriormente solo se mostraba “este JSONL es correcto/incorrecto”. Ahora también se puede ver “es correcto/incorrecto cuando se adjunta a cierto código”.

Problemas que la herramienta actual ha resuelto

Cambio en la productividad del desarrollo

Antes de crear la herramienta, para realizar una sola prueba se hacía lo siguiente manualmente.

1. Explicación de los ítems de prueba a Qwen  
2. Solicitud de código Godot 3  
3. Solicitud de código Godot 4  
4. Solicitud de JSONL de respuestas correctas/incorrectas de docs_chunks  
5. Solicitud de JSONL de respuestas correctas/incorrectas de api_mapping  
6. Solicitud de JSONL de respuestas correctas/incorrectas de label_prototypes  
7. Verificar cada JSONL nuevamente con SOURCE_CODE  
8. Registrar manualmente los resultados de sí/no  
9. Comparar mentalmente si el valor esperado coincide

Ahora el mismo flujo está fijado dentro de la pantalla.

1. Hacer clic en el elemento  
2. Generar etiqueta AI  
3. Generar código común o para Godot 3/4  
4. Generar ranuras JSONL  
5. Verificar código de Godot 3 / Verificar código de Godot 4  
6. Revisar resultados y el prompt/respuesta

Particularmente, la parte en la que la productividad mejoró se acerca más a “no confundirse” que a “hacer mucho rápidamente”. En este trabajo es más importante que el criterio de juicio no fluctúe que la cantidad simple de generación. Con la aparición de la herramienta, lo siguiente se volvió más fácil.

• Fijar primero si es una gramática común o una separación por versión
• Ver continuamente en pantalla el uso de JSONL por tabla
• Separar la expectativa del criterio de generación de los resultados de verificación reales
• Verificar cruzadamente el mismo JSONL en el código de Godot 3/4
• Consultar inmediatamente el prompt y la respuesta cruda del slot que falló
• Reducir el estado que la persona debe recordar al repetir 50 ítems

Problemas aún abiertos

Esta herramienta aún no es el evaluador final. Por ahora es una herramienta de depuración.

Los problemas abiertos son los siguientes.

• La justificación de docs_chunks puede reconocerse como una explicación común aunque las versiones difieran.
• En api_mapping, si las cadenas source/target aparecen ambas en el JSONL, Qwen podría ver solo la cadena target y responder “sí”.
• En label_prototypes, la distinción de patrones before/after puede ser más importante que la coincidencia simple de cadenas.
• El cálculo de la respuesta esperada actual es solo un criterio de depuración; más adelante se deberá refinar por separado el cálculo real de score/F1.
• Es difícil separar directamente los problemas de selección de candidatos de búsqueda y de juicio del prompt de verificación solo con los resultados.

Conclusión actual

El 28 de junio se tenía la impresión de “probemos los 50 tests manualmente”. Al hacerlo, resultó que había demasiados ejes que probar, y cuando se mezclaban gramática común, separación por versión, criterio de generación y versión objetivo de verificación, rápidamente surgía confusión.

Al crear la herramienta el 30 de junio, este problema se organizó bastante. Ahora no solo se ve el JSONL generado por Qwen como correcto/incorrecto, sino que también se puede observar en qué código se generó y en qué código se verificó.

Esta herramienta podrá usarse de la misma manera cuando se añadan los resultados reales de búsqueda de docs_chunks, api_mapping y label_prototypes. Es decir, se convirtió en una herramienta base que puede extenderse no solo a datos de demostración manuales, sino también a la verificación de resultados de búsqueda en bases de datos.