Prompt d'observation de correspondance JSONL

Date de rédaction : 27 juin 2026

Objectif

Aujourd'hui, avant d'ajouter une recherche réelle en base de données dans le Source Flow Debugger, j'ai demandé à GPT de créer un morceau de code Godot de démonstration et des candidats JSONL, puis de vérifier si le LLM juge correctement la pertinence ou l'irrélevance de ces JSONL en se basant sur les preuves.

L'idée initiale était simple.

SOURCE_CODE + JSONL candidat  
  -> Ce JSONL contient-il le contenu correspondant au code source ?  
  -> Oui / Non

Cependant, en pratique, cette seule question était insuffisante. Le LLM ne se basait pas sur une preuve textuelle directe dans le JSONL, mais utilisait ses connaissances internes sur Godot ou des similarités thématiques larges pour juger que la réponse était « oui ».

Génération de données de démonstration

Tout d'abord, nous avons demandé à GPT de créer un fragment aléatoire de Godot ainsi que le JSONL correspondant, ainsi qu'un JSONL sans rapport.

L'intention de la requête était la suivante.

Créer un chunk Godot aléatoire et un JSONL aléatoire.  
Le chunk Godot est délibérément écrit en code Godot 3.  
Le JSONL comprend à la fois des éléments contenant les bases de conversion vers Godot 4 et des éléments totalement sans rapport.  
On teste, en le soumettant à un LLM, si la différence entre le JSONL pertinent et le JSONL non pertinent apparaît.

Capture :

Problème d’invite initiale

Au départ, j’ai demandé comme suit.

Ce fichier jsonl contient-il le contenu correspondant au code source ?  
Répondez uniquement par oui ou non.

Dans cette méthode, même lorsqu’on insère le JSONL pertinent, la réponse est « oui », et même lorsqu’on insère un JSONL non pertinent, la réponse reste « oui ».

Résultat du JSONL pertinent :

Résultat du JSONL non pertinent :

Le problème était que la question était trop large. Si l’on demande simplement « Le contenu correspond‑il au code source ? », le LLM peut juger que c’est pertinent simplement en voyant des mots généraux comme Godot, Godot3, Godot4, migration, 2D, physics.

Dans ce cas, même si le Retriever récupère un JSONL inapproprié, le LLM peut combler les lacunes avec ses propres connaissances et répondre « oui ». Ce n’est pas la validation que nous recherchons.

Prompt modifié

Ainsi, nous avons transformé le prompt en un juge de correspondance basé sur des preuves.

Vous êtes un évaluateur de correspondance JSONL.

Déterminez si le JSONL ci‑dessous contient une preuve directe de transformation pour le **SOURCE_CODE** suivant.

**Critères d’évaluation**  
- Il faut que l’un des champs du JSONL — `source_api`, `source_pattern`, `match_terms`, `required_when_seen_in_code` ou `before_code` — corresponde exactement à une chaîne de caractères réelle ou à un appel d’API présent dans le **SOURCE_CODE**. Ce n’est alors qu’à ce moment que la réponse est « Oui ».  
- Le simple fait que des mots généraux comme *Godot*, *Godot3*, *Godot4*, *migration*, *2D*, *physics* apparaissent ne constitue pas une preuve de pertinence.  
- Les mentions négatives du type « does not describe », « not related », « unrelated », « does not apply », etc., ne sont pas considérées comme une preuve valable.  
- Si le JSONL fait référence à une API, un nœud ou un système différent, la réponse doit être « Non ».  
- N’utilisez **pas** vos connaissances personnelles sur Godot ; basez‑vous uniquement sur les chaînes de caractères présentes dans le JSONL.  
- La réponse doit être **uniquement** « Oui » ou « Non ».

Dans cette invite, le critère de jugement a été limité à « preuve de chaîne directe ».

En particulier, il a été limité à ce que l'un des champs suivants corresponde directement à la chaîne réelle / appel d'API du CODE_SOURCE.

source_api
source_pattern
match_terms
required_when_seen_in_code
before_code

Encore une fois, on a empêché le LLM de raisonner avec des mots‑clés larges et ses connaissances internes sur Godot.

Résultat après modification

Le JSONL pertinent est sorti avec oui.

Le JSONL non pertinent est sorti avec non.

Grâce à ce résultat, on a confirmé que l’étape de validation du LLM après la recherche dans la base de données ne consiste pas seulement à juger la similarité sémantique, mais d’abord à vérifier « y a‑t‑il dans le JSONL trouvé une preuve textuelle qui correspond directement au chunk actuel ».

Critères obtenus aujourd’hui

Le prompt de validation des résultats de recherche dans la base de données doit respecter les critères suivants :

• La similarité de sujet large n’est pas acceptée comme preuve.
• On ne doit pas laisser le LLM combler les lacunes avec ses connaissances préexistantes sur Godot.
• Les champs explicites du JSONL doivent correspondre directement aux chaînes/API réelles du chunk actuel.
• Les informations du JSONL mentionnées négativement ne sont pas reconnues comme preuve pertinente.
• Le premier jugement de pertinence/non‑pertinence doit être bref et catégorique, limité à oui ou non.

Ces critères seront importants demain lors de l’intégration de la recherche dans la base de données.

Après avoir récupéré les JSONL candidats depuis docs_chunks, api_mapping et label_prototypes, l’étape de validation Qwen doit fonctionner comme suit.

chunkText
  -> Collecte des candidats JSONL via recherche DB
  -> prompt + chunkText + JSONL récupéré
  -> Déterminer si le JSONL contient directement une preuve textuelle
  -> Jeter les JSONL non pertinents
  -> Utiliser uniquement les JSONL pertinents comme base de décision pour les explications/migrations ultérieures

Le cœur de l'expérience d'aujourd'hui n'était pas de savoir « si le LLM connaît correctement », mais de déterminer « si l'on peut faire en sorte que le LLM se base uniquement sur les preuves écrites dans le JSONL pour prendre une décision ». Si cela échoue, même les candidats non pertinents récupérés par le Retriever peuvent être assemblés de manière plausible par le LLM. Ainsi, il faut non seulement améliorer la qualité de la recherche, mais aussi concevoir séparément le prompt de vérification des résultats de recherche.