Hoy el objetivo es decidir qué flujo elegir entre varias alternativas de búsqueda/validación
Manteniendo chunkText como entrada tal cual, debemos determinar cómo combinar BM25, búsqueda de texto completo de PostgreSQL, embedding, reranker y el validador de evidencia directa de Qwen
Al principio no había un diseño definitivo; se había reunido material sobre los pros y contras de cada método de búsqueda obtenido mediante ChatGPT y los flujos de respuesta sí/no como referencia
Posteriormente, basándonos en simulaciones de cada alternativa y una tabla comparativa integral, se decidió adoptar prioritariamente la estrategia F
La estrategia F consiste en conectar BM25 + embedding + reranker + validador de evidencia directa de Qwen
Es decir, se usa chunkText como entrada de búsqueda, se amplían los candidatos con BM25 y embedding, se reordenan con el reranker y, al final, Qwen verifica si el JSONL encontrado constituye una evidencia directa que coincida con el fragmento de código actual
La siguiente validación será con Qwen probando 50 ítems en cada tabla: docs_chunks, api_mapping, label_prototypes
En cada tabla se tomarán alrededor de 50 muestras, se dividirán en casos relevantes y no relevantes, y se observará cómo difieren las respuestas sí y no esperadas
Esta prueba no solo verifica que la búsqueda funcione, sino que el validador de evidencia directa de Qwen acepte o descarte el JSONL como prueba directa del fragmento de código
Al hacerlo manualmente, la cantidad real de pruebas resulta mucho mayor de lo anticipado
Se crearon 50 ítems de prueba para Godot, y cada ítem requiere revisar las tres tablas docs_chunks, api_mapping y label_prototypes
Si es una función/sintaxis común, se genera un fragmento de código Godot, datos esperados sí/no para docs_chunks, datos esperados sí/no para api_mapping y datos esperados sí/no para label_prototypes; luego se inserta el prompt + código de prueba + los 6 datos para observar el patrón de respuesta
Si no es una función común, hay que crear códigos separados para Godot 3 y Godot 4, lo que duplica el trabajo
Para resumir los resultados más adelante con métricas de clasificación como F1‑score, será necesario registrar manualmente los resultados true/false de todos los casos
Por eso se consideró imposible terminar los 50 ítems en un solo día; el objetivo de hoy se redujo a 5 ítems
Después de completar los 5, en lugar de seguir aumentando la cantidad de pruebas, se cambiará el enfoque a analizar primero los patrones de respuesta sí/no obtenidos hasta ahora
En la práctica se ejecutaron 5 de los 50 ítems
Aunque solo fueron 5, se observó que el flujo de respuestas difiere entre el JSONL generado con base en Godot 3 y el generado con base en Godot 4
En particular, en código con diferencias de versión, el JSONL de Godot 3 puede producir sí al evaluar código de Godot 4 debido a cadenas comunes o evidencia de migración, y viceversa, cuando el JSONL de Godot 4 evalúa código de Godot 3, la mezcla de cadenas source/target puede generar resultados ambiguos
Por lo tanto, en pruebas futuras no solo se verificará si las 6 respuestas son sí/no, sino que primero se distinguirá si se trata de sintaxis común o diferencia de versión, y se registrará la respuesta cruda separando versión de generación del JSONL y versión del código evaluado
Este proceso implica no solo ajustar el prompt de validación, sino también modificar la estrategia de prompting y la de recolección de datos
En adelante, al crear JSONL se deberá separar claramente los criterios de recolección/generación para: sintaxis común, evidencia exclusiva de Godot 3, evidencia exclusiva de Godot 4 y evidencia bidireccional de migración
Mientras tanto, la conversión de la documentación oficial Markdown → JSONL continúa; hasta hoy se han convertido aproximadamente 600 de los 1 570 documentos Markdown totales