idea_world_labDEV JOURNAL
dimanche 28 juin 2026

28 juin 2026

  • Aujourd’hui, l’objectif est de choisir quel flux parmi les différentes alternatives de recherche/validation adopter
    • En conservant 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, il ne s’agissait pas d’une conception définitive, mais d’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 matière de réflexion
    • Ensuite, sur la base des simulations par alternative et du tableau comparatif global, nous avons décidé d’adopter en priorité la stratégie F
    • La stratégie F consiste à enchaîner BM25 + embedding + reranker + validateur de preuve directe Qwen
    • Autrement dit, on garde chunkText comme entrée de recherche, on élargit les candidats avec BM25 et l’embedding, on les réordonne avec le reranker, puis on laisse Qwen vérifier si le JSONL récupéré constitue une preuve directement applicable au chunk de code actuel
    • La prochaine validation sera effectuée avec Qwen en testant 50 exemples pour chaque table : docs_chunks, api_mapping, label_prototypes
    • Dans chaque table, on répartira environ 50 échantillons entre des cas pertinents et non pertinents, afin d’observer comment les réponses oui et non se différencient
    • Ce test ne vise pas seulement à vérifier la pertinence de la recherche, mais aussi à voir si le validateur de preuve directe Qwen accepte ou rejette le JSONL comme preuve réellement applicable au chunk de code
    • En procédant manuellement, la quantité de tests réels s’est avérée bien plus importante que prévu
    • Nous avons créé 50 items de test Godot, et chaque item nécessite la vérification des trois tables : docs_chunks, api_mapping, label_prototypes
    • Pour une fonction/syntaxe commune, on crée un chunk de code Godot, puis les données attendues oui/non pour docs_chunks, api_mapping et label_prototypes, on ajoute le prompt + le code de test + les 6 données, et on observe comment le modèle répond
    • 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 faudra consigner manuellement le résultat vrai/faux de chaque cas
    • Nous avons donc estimé qu’il était impossible de tout terminer en une journée, et nous avons limité l’objectif d’aujourd’hui à 5 items
    • Après avoir complété les 5 items, nous passerons d’une simple augmentation du nombre de tests à une analyse préalable des schémas de réponses oui/non observés jusqu’ici
    • En pratique, nous avons traité 5 items sur les 50 prévus
    • Même avec seulement 5 items, nous avons constaté que le flux de réponses différait entre le JSONL généré à partir de Godot 3 et celui généré à partir de Godot 4
    • En particulier, pour du code avec des différences de version, le JSONL basé sur Godot 3 peut produire un oui lorsqu’on l’applique à du code Godot 4 à cause de chaînes communes ou de preuves de migration, et inversement : le JSONL de Godot 4 peut donner un résultat ambigu sur du code Godot 3 si les chaînes source/cible sont mélangées
    • Ainsi, les prochains tests ne se limiteront plus à vérifier si les 6 réponses sont simplement oui/non, mais distingueront d’abord s’il s’agit d’une syntaxe commune ou d’une différence de version, puis enregistreront séparément la version de génération du JSONL et la version du code testé dans les réponses brutes
    • Ce processus révèle qu’il ne suffit pas de modifier le prompt de validation ; il faut également revoir la stratégie de prompting et la stratégie de collecte de jeux de données
    • À l’avenir, lors de la création de JSONL, il faudra séparer davantage les critères de collecte/génération afin d’éviter le mélange entre syntaxe commune, preuves spécifiques à Godot 3, preuves spécifiques à Godot 4 et preuves de migration bidirectionnelle
    • Par ailleurs, la conversion officielle Markdown → JSONL se poursuit ; à ce jour, environ 600 sur les 1 570 Markdown totaux ont été convertis en JSONL
  • Document de suivi des tests : Qwen Godot code JSONL correspondance de preuve test checklist
  • Référence du schéma : Schéma JSONL de test Qwen et son usage
  • Mémo d’enquête : Retriever alternative de recherche Mémo ChatGPT
  • Document de décomposition à titre d’exemple : Retriever document de décomposition d’alternative de recherche
  • Documents détaillés par alternative : A texte complet actuel, B BM25 only, C embedding only, D BM25 + embedding, E Qwen query profile, F reranker + validator