Aujourd'hui l'objectif est de décider quel flux choisir parmi plusieurs alternatives de recherche/validation
En gardant chunkText tel quel comme entrée, il faut déterminer comment combiner BM25, la recherche en texte intégral PostgreSQL, l'embedding, le reranker et le validateur de preuve directe Qwen
Au départ ce n'était pas une conception définitive, mais un état où les avantages et inconvénients de chaque méthode de recherche obtenus via ChatGPT ainsi que les flux de réponses oui/non étaient rassemblés comme matériel de décision
Ensuite, sur la base des simulations par alternative et du tableau comparatif global, il a été décidé d'adopter en priorité la stratégie F
La stratégie F consiste à connecter BM25 + embedding + reranker + validateur de preuve directe Qwen
Autrement dit, on utilise chunkText comme entrée de recherche, on élargit les candidats avec BM25 et l'embedding, on les réordonne avec le reranker, puis Qwen vérifie en dernier si le JSONL trouvé correspond directement au fragment de code actuel
La prochaine validation sera faite avec Qwen en testant 50 éléments de chaque table docs_chunks, api_mapping, label_prototypes
Dans chaque table, on insérera environ 50 échantillons, divisés en cas pertinents et non pertinents, pour vérifier comment les réponses oui et non se répartissent
Ce test ne consiste pas seulement à voir si la recherche fonctionne, mais à vérifier si le validateur de preuve directe Qwen accepte ou rejette le JSONL trouvé comme preuve directe du fragment de code
En procédant manuellement, la quantité réelle à tester s'est avérée bien plus importante que prévu
Nous avons créé 50 items de test Godot, et chaque item nécessite de vérifier les trois tables docs_chunks, api_mapping, label_prototypes
Pour une fonction/syntaxe commune, on crée un fragment de code Godot, les données attendues oui/non pour docs_chunks, api_mapping et label_prototypes, puis on insère le prompt + le code de test + les 6 jeux de données pour observer le schéma de réponse
Si ce n'est pas une fonction commune, il faut créer séparément du code pour Godot 3 et Godot 4, ce qui double pratiquement la charge de travail
Pour résumer ces résultats plus tard avec une métrique de classification comme le F1‑score, il faut consigner manuellement le résultat vrai/faux de chaque cas
Nous avons donc jugé impossible de terminer les 50 items en une journée ; l'objectif d'aujourd'hui a été réduit à 5 items
Après avoir complété les 5, nous passerons d'une simple augmentation du nombre de tests à une analyse d'abord des schémas de réponses oui/non observés jusqu'à présent
En pratique, nous avons réalisé 5 items sur les 50 prévus
Même avec seulement 5 items, on a constaté que le flux de réponses différait entre le JSONL généré pour Godot 3 et celui pour Godot 4
En particulier, pour du code avec différence de version, le JSONL basé sur Godot 3 peut produire un oui lorsqu'il examine du code Godot 4 à cause de chaînes communes ou de preuves de migration, et inversement, le JSONL basé sur Godot 4 peut donner un résultat ambigu si des chaînes source/cible sont mélangées
Ainsi, à partir du prochain test, il ne s'agira plus seulement de vérifier si les 6 réponses sont oui/non, mais d'abord de distinguer si le problème vient d'une syntaxe commune ou d'une différence de version, puis d'enregistrer séparément la version de génération du JSONL et la version du code testé
Ce processus montre que ce n'est pas seulement le prompt de validation qui doit être ajusté, mais aussi la stratégie de prompting et la stratégie de collecte de jeux de données
À l'avenir, lors de la création du JSONL, il faudra séparer davantage les critères de collecte/génération afin d'éviter le mélange de syntaxe commune, de preuves spécifiques à Godot 3, de preuves spécifiques à Godot 4 et de preuves de migration bidirectionnelle
Par ailleurs, la conversion Markdown → JSONL de la documentation officielle continue ; à ce jour, environ 600 des 1 570 fichiers Markdown ont été convertis en JSONL