Schéma JSONL de test Qwen et son utilisation

Date de rédaction : 28 juin 2026

Objectif

Créer des morceaux de code Godot avec Qwen, puis associer à chaque morceau de code un JSONL de réponse correcte et un JSONL de réponse incorrecte afin de valider « oui »/« non ». Ce document résume le format JSONL de référence ainsi que l’usage de chaque JSONL.

Ce document ne fournit pas de données d’exemple. Il s’agit d’une documentation de schéma destinée à identifier le rôle de chaque JSONL lors des tests et les champs utilisés pour le jugement de preuve directe.

Critères communs

Chaque ligne d’un fichier JSONL contient un seul objet JSON.

{...}
{...}
{...}

Dans les tests, on ne place pas de wrapper entourant le nom de la table, mais on met les champs correspondant aux colonnes de la table cible au niveau supérieur.

Bon:
{"chunk_id":"...","content":"...","code_blocks":[...]}

À éviter:
{"table":"docs_chunks","payload":{"chunk_id":"..."}}

Les champs générés automatiquement par la base de données ou utilisés dans l'index de recherche n'ont pas besoin d'être remplis directement dans le JSONL de test.

Dans la validation directe des preuves Qwen, l'important est de savoir « quel champ du JSONL correspond directement à la chaîne réelle / API / motif du CODE_SOURCE ».

docs_chunks

Utilisation

docs_chunks est un JSONL qui stocke les explications de la documentation officielle, les tutoriels et le corps des références de classe par morceaux (chunks).

Il est utilisé pour les demandes d'explication de code, la vérification de l'utilisation des API communes, la vérification des explications de la syntaxe commune de Godot 3/4. Plutôt que les règles de migration elles‑mêmes, il sert de preuve pour vérifier « à quelle explication de la documentation officielle ce code est directement lié ».

Format JSONL

{
  "chunk_id": "text, required",
  "doc_version": "text, required",
  "source_url": "text, required",
  "source_file": "text, required",
  "source_sha256": "text, required",
  "doc_type": "text, required",
  "symbol": "text or null",
  "section_path": "array, required",
  "heading": "text or null",
  "content": "text, required",
  "code_blocks": "array, required",
  "language_tags": "array<string>",
  "godot_version_tags": "array<string>",
  "api_symbols": "array<string>",
  "token_count": "integer or null",
  "metadata": "object"
}

Directement basé sur les preuves de champ

Rôle dans les tests

api_mapping

Utilité

api_mapping est un fichier JSONL qui enregistre comment les noms, classes, fonctions et symboles ont changé de Godot 3 à Godot 4.

Il est utilisé pour les changements simples de nom, les renommages, remplacements, ou la détermination d’API dépréciées/supprimées. Les cas où la façon d’utiliser une fonction change complètement sont plutôt traités dans la section label_prototypes.

Format JSONL

{
  "mapping_id": "text, required",
  "source_api": "text, required",
  "target_api": "text or null",
  "change_type": "text, required",
  "godot_from": "text, required",
  "godot_to": "text, required",
  "confidence": "text, required",
  "evidence_chunk_ids": "array<string>",
  "match_terms": "array<string>",
  "notes": "text",
  "negative_patterns": "array<string>"
}

Directement basé sur les preuves du champ

Rôle dans les tests

label_prototypes

Utilisation

label_prototypes est un fichier JSONL qui stocke des exemples où non seulement le nom change, mais aussi la façon d’utiliser la fonction, la composition des arguments et le modèle d’appel sont entièrement modifiés.

Si api_mapping répond à la question « Quel nom a été remplacé par quoi », alors label_prototypes se rapproche de « Comment le code doit‑il être écrit ».

Format JSONL

{
  "prototype_id": "text, required",
  "label": "text, required",
  "task_type": "text, required",
  "input_pattern": "text, required",
  "expected_finding": "text, required",
  "recommended_action": "text, required",
  "evidence_mapping_ids": "array<string>",
  "evidence_chunk_ids": "array<string>",
  "severity": "text",
  "validator_rules": "object"
}

validator_rules peut avoir les sous‑champs suivants.

{
  "required_when_seen_in_code": "array<string>",
  "before_code": "text",
  "after_code": "text",
  "reject_when_seen_in_code": "array<string>"
}

Directement basé sur les preuves de champ

Rôle dans les tests

Frontières des trois JSONL

Traitement de la syntaxe commune

Les syntaxes identiques entre Godot 3 et Godot 4 ne sont pas considérées comme des différences de version.