2026-06-21 Rétrospective | idea_world

Reposant la question sur le flux de conversion JSONL de la documentation officielle de Godot

J’ai collé le schéma de 2026-06-21-initial-rag-classifier-architecture.md dans Qwen et demandé une direction de code Python pour convertir un document Markdown en JSONL.

Le cœur de la première question était un script de conversion simple.

J’ai besoin d’un code Python qui prend du Markdown en entrée et le convertit en JSONL
Ce serait bien d’inclure également la commande d’exécution
Le contenu JSONL doit être généré en appelant l’API Qwen
Un mécanisme de vérification est nécessaire pour que le schéma ne soit pas corrompu lors de l’enregistrement en JSONL
Je veux vérifier le format JSONL à l’aide d’expressions régulières ou de validation de schéma
Il serait utile que le modèle détermine à quelle table mapper lors de l’appel API
Si nécessaire, il faut générer les schémas complets de docs_chunks, api_mapping, label_prototypes

Extension de la réflexion du script CLI vers un outil web

J’ai ensuite estimé qu’un simple convertisseur CLI ne permettait pas de visualiser le flux, et j’ai envisagé une architecture appelée depuis le web.

Il serait pratique de pouvoir saisir une clé API dans l’interface web
Le support du téléchargement d’un fichier Markdown ou d’un dossier serait souhaitable
Pouvoir voir le diff ou les modifications avant/après la conversion directement dans le navigateur serait utile
Au lieu de simplement créer le fichier résultat, le processus de conversion et les résultats de validation doivent pouvoir être examinés par une personne

En posant cette question, j’ai réalisé que le convertisseur JSONL doit être davantage un outil de traitement de données révisé et approuvé par un humain, plutôt qu’un simple script batch.

Reconfirmation du problème où un fichier peut alimenter plusieurs tables

La question supplémentaire la plus importante était que un fichier Markdown ne doit pas forcément être mappé à une seule table.

Par exemple, un même document de migration peut générer simultanément trois types de JSONL :

Les morceaux de documentation officielle → docs_chunks.jsonl
Les règles de modification d’API → api_mapping.jsonl
Les exemples de conversion/classification → label_prototypes.jsonl

Ainsi, le convertisseur ne doit pas se limiter à produire un seul JSONL à partir d’un fichier, mais doit d’abord interroger Qwen pour déterminer quelles tables sont nécessaires, puis, si plusieurs réponses sont obtenues, générer plusieurs enregistrements JSONL à partir d’un même fichier.

Nouvelle orientation de conception définie aujourd’hui

La conversion Markdown → JSONL est divisée en étapes classification → génération → validation → sauvegarde.
Qwen peut lire le texte et décider quelles tables cibles sont requises.
Cependant, la réponse de Qwen ne doit pas être acceptée aveuglément ; un validateur de schéma local décide du stockage final.
Les expressions régulières sont utilisées uniquement pour une validation de format minimale, tandis que la validation réelle des champs est mieux assurée par JSON Schema ou Pydantic.
On part du principe qu’un même fichier Markdown peut produire plusieurs sorties JSONL.
L’interface web n’est pas seulement une commodité ; elle constitue une couche de contrôle où l’utilisateur vérifie et approuve les enregistrements générés automatiquement.

Mémo des tâches suivantes

Rédiger un premier jet de JSON Schema pour docs_chunks, api_mapping et label_prototypes.
Concevoir le prompt qui demande à Qwen, à partir d’un fichier Markdown, d’identifier les tables cibles possibles.
Définir la règle de séparation et de sauvegarde des fichiers lorsqu’une réponse Qwen contient plusieurs enregistrements de tables.
Créer d’abord un script CLI de validation ligne‑par‑ligne des JSONL.
Puis étendre l’interface web pour gérer le téléchargement, la conversion, le diff, les résultats de validation et le flux d’approbation/rejet.

Questions à laisser en suspens

En confiant la détermination du mapping de table à Qwen, dans quels cas une approbation humaine est‑elle absolument requise ?
Le candidat api_mapping doit‑il être inséré directement dans la base de données ou seulement stocké avec le statut candidate ?
Dans l’interface web, le diff doit‑il être affiché entre le Markdown original et le JSONL, ou entre la version actuelle du JSONL et la version précédente ?
Lors d’un téléchargement de dossier, comment gérer la relance des fichiers ayant échoué ou partiellement réussis ?