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 las ventajas y desventajas de cada método de búsqueda obtenidas a través de ChatGPT y los flujos de respuesta sí/no
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 se realizará con Qwen probando 50 elementos de cada tabla: docs_chunks, api_mapping, label_prototypes
En cada tabla se tomarán alrededor de 50 muestras, divididas en casos relevantes y no relevantes, para observar cómo se diferencian las respuestas sí y no
Esta prueba no solo verifica que la búsqueda funcione, sino que también comprueba si el validador de evidencia directa de Qwen acepta o descarta el JSONL como evidencia válida para el fragmento de código
Al hacerlo manualmente, la cantidad de pruebas reales resulta mucho mayor de lo esperado
Se crearon 50 ítems de prueba para Godot, y cada ítem requiere revisar las tres tablas docs_chunks, api_mapping, label_prototypes
Si la función/sintaxis es común, se crea un fragmento de código Godot y se generan datos esperados sí/no para docs_chunks, api_mapping y 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 prácticamente la carga de 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 día; el objetivo de hoy se redujo a 5 ítems
Después de completar los 5, en lugar de simplemente aumentar el número de pruebas, se cambiará el enfoque a analizar primero los patrones de respuesta sí/no obtenidos hasta ahora
En la práctica se avanzó con 5 de los 50 ítems
Aunque solo se hicieron 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 evidencias 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 una sintaxis común o una diferencia de versión, y se registrará la respuesta cruda separando versión base para generar 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 evitar mezclar sintaxis común, evidencias exclusivas de Godot 3, evidencias exclusivas de Godot 4 y evidencias de migración bidireccional
Mientras tanto, la conversión de la documentación oficial de Markdown a JSONL continúa; hasta hoy se han convertido aproximadamente 600 de los 1 570 documentos Markdown totales