JSONL‑Beweis‑Matching‑Prompt‑Beobachtung

Erstellungsdatum: 27. Juni 2026

Zweck

Heute, bevor wir in Source Flow Debugger eine echte Datenbanksuche einbinden, ließ ich GPT ein Demo‑Godot‑Code‑Chunk und JSONL‑Kandidaten erzeugen und prüfte, ob das LLM anhand dieses JSONL korrekt die Relevanz bzw. Irrelevanz beurteilt.

Der erste Gedanke war einfach.

SOURCE_CODE + JSONL Kandidat
  -> Enthält dieses JSONL den entsprechenden Quellcode?
  -> Ja / Nein

Aber in der Praxis war diese Frage allein nicht ausreichend. Es trat ein Phänomen auf, bei dem das LLM nicht die direkten Zeichenkettenbelege in JSONL nutzte, sondern sein eigenes Wissen über Godot oder die breite thematische Ähnlichkeit heranzog und zu dem Schluss kam, dass es „Ja“ sei.

Demo-Datenerstellung

Zuerst ließ ich GPT einen beliebigen Godot-Chunk sowie zugehörige JSONL und nicht zugehörige JSONL erzeugen.

Die Absicht der Anfrage war wie folgt.

Zufällige Godot‑Chunks und zufällige JSONL‑Dateien erstellen.  
Die Godot‑Chunks werden absichtlich in Godot 3‑Code geschrieben.  
Die JSONL‑Dateien enthalten sowohl solche, die als Grundlage für die Godot 4‑Umwandlung dienen, als auch völlig unrelatede.  
Wenn man sie einem LLM gibt, testet man, ob der Unterschied zwischen relevanten und irrelevanten JSONL‑Dateien erkennbar ist.

Aufnahme:

Anfangs‑Prompt‑Problem

Zuerst fragte ich wie folgt.

Enthält diese jsonl den Quellcode?  
Bitte antworten Sie nur mit Ja / Nein.

Bei dieser Methode wird sowohl bei Eingabe eines relevanten JSONL Ja ausgegeben, als auch bei Eingabe eines irrelevanten JSONL Ja ausgegeben.

Das Problem war, dass die Frage zu allgemein war. Wenn man nur fragt: „Enthält der Quellcode die gesuchten Inhalte?“, kann das LLM bereits anhand breiter Begriffe wie Godot, Godot3, Godot4, migration, 2D, physics entscheiden, dass es relevant ist.

In diesem Fall könnte der Retriever falsche JSONL‑Dateien zurückliefern, und das LLM würde sie mit eigenem Wissen auffüllen und einfach mit „Ja“ antworten. Das entspricht nicht der gewünschten Validierung.

Überarbeitete Eingabeaufforderung

Also habe ich die Eingabeaufforderung in einen Begründungsabgleich-Entscheider umgewandelt.

Du bist ein JSONL‑Beweis‑Matching‑Entscheider.

Bestimme für den untenstehenden **SOURCE_CODE**, ob das nachfolgende JSONL eine direkte Transformations‑Begründung enthält.

Entscheidungskriterien:
- Einer der Werte **source_api**, **source_pattern**, **match_terms**, **required_when_seen_in_code** oder **before_code** im JSONL muss exakt mit einem tatsächlichen String oder API‑Aufruf im **SOURCE_CODE** übereinstimmen, damit die Antwort „Ja“ lautet.
- Das bloße Auftreten allgemeiner Begriffe wie *Godot*, *Godot3*, *Godot4*, *migration*, *2D*, *physics* gilt nicht als relevant.
- Negative Formulierungen im JSONL wie „does not describe“, „not related“, „unrelated“, „does not apply“ werden nicht als Beweis anerkannt.
- Handelt das JSONL von einer anderen API, einem anderen Node oder einem anderen System, lautet die Antwort „Nein“.
- Verwende ausschließlich die im JSONL angegebenen Zeichenketten als Beweis und greife nicht auf dein eigenes Godot‑Wissen zurück.
- Die Antwort muss ausschließlich **„Ja“** oder **„Nein“** sein.

Bei diesem Prompt wurde das Bewertungskriterium auf „direkte Zeichenkettenbegründung“ eingeschränkt.

Insbesondere wurde festgelegt, dass eines der folgenden Felder exakt mit dem tatsächlichen Zeichenketten‑/API‑Aufruf im SOURCE_CODE übereinstimmen muss.

source_api
source_pattern
match_terms
required_when_seen_in_code
before_code

Auch hat man verhindert, dass das LLM mit breiten Stichwörtern und seinem eigenen Godot‑Wissen schlussfolgt.

Ergebnis nach der Korrektur

Die zugehörige JSONL wurde als ja ausgegeben.

Unabhängig JSONL wurde mit Nein angezeigt.

Durch dieses Ergebnis wurde erneut bestätigt, dass die LLM‑Validierungsphase nach der Datenbanksuche nicht nur eine einfache semantische Ähnlichkeitsbewertung darstellt, sondern zunächst prüfen muss, ob im gefundenen JSONL‑Datensatz ein direkter textlicher Beleg für das aktuelle Chunk vorhanden ist.

Heute gewonnene Kriterien

DB‑Suchergebnis‑Validierungs‑Prompt muss die folgenden Kriterien erfüllen.

• Eine breite thematische Ähnlichkeit wird nicht als Begründung anerkannt.
• Es darf nicht erlaubt sein, fehlende Begründungen mit dem Vorwissen des LLM über Godot zu füllen.
• Die im JSONL angegebenen Felder müssen exakt mit dem tatsächlichen String/API‑Aufruf des aktuellen Chunks übereinstimmen.
• Negativ erwähnte Inhalte im JSONL werden nicht als relevante Begründung akzeptiert.
• Für die erste Relevanz‑/Irrelevanz‑Bewertung ist es besser, sie kurz und eindeutig mit Ja oder Nein zu beantworten.

Diese Kriterien sind wichtig, wenn morgen die DB‑Suche angehängt wird.

Nachdem die Kandidaten‑JSONL aus docs_chunks, api_mapping und label_prototypes abgerufen wurden, sollte die Qwen‑Validierungsphase wie folgt funktionieren.

chunkText
  -> DB‑Suche zum Sammeln von JSONL‑Kandidaten
  -> Prompt + chunkText + abgerufene JSONL
  -> Prüfen, ob JSONL direkte textuelle Begründungen enthält
  -> Nicht relevante JSONL verwerfen
  -> Nur relevante JSONL als Grundlage für spätere Erklärungen/Migration verwenden

Der Kern des heutigen Experiments war nicht „Ob das LLM korrekt weiß“, sondern „Ob man das LLM dazu bringen kann, nur anhand der in JSONL angegebenen Belege zu entscheiden“. Wenn das nicht funktioniert, kann das LLM auch irrelevante Kandidaten, die der Retriever mitgebracht hat, plausibel zusammenfügen. Daher muss nicht nur die Suchqualität, sondern auch der Prompt zur Überprüfung der Suchergebnisse separat entworfen werden.