idea_world_labDEV JOURNAL
Sonntag, 21. Juni 2026

2026-06-21 Rückblick

Godot‑Offizielle‑Dokumentation JSONL‑Umwandlungs‑Flow erneut gefragt

Ich habe Qwen den Schemainhalt von 2026-06-21-initial-rag-classifier-architecture.md eingefügt und nach einem Python‑Code gefragt, der ein Markdown‑Dokument in JSONL umwandelt.

Der Kern der ersten Frage war ein einfacher Umwandlungsskript.

  • Ich brauche Python‑Code, der Markdown als Eingabe nimmt und in JSONL umwandelt
  • Es wäre gut, wenn ein Ausführungsbefehl mitgeliefert wird
  • Der JSONL‑Inhalt soll über die Qwen‑API erzeugt werden
  • Da das Schema beim Speichern nicht beschädigt werden darf, ist eine Prüf‑Logik nötig
  • Ich möchte das JSONL‑Format per regulärem Ausdruck oder Schema‑Validierung prüfen
  • Es wäre hilfreich, wenn das Modell entscheidet, zu welcher Tabelle die API‑Aufrufe gemappt werden sollen
  • Falls nötig, muss das gesamte Schema für docs_chunks, api_mapping, label_prototypes erzeugt werden

Vom CLI‑Skript zur webbasierten Anwendung erweitert

Danach kam ich zu dem Schluss, dass ein reiner CLI‑Umwandler den Flow nicht gut genug visualisiert. Deshalb habe ich über eine webbasierte Aufrufstruktur nachgedacht.

  • Es wäre gut, wenn man im Web‑Interface einen API‑Key eingeben kann
  • Unterstützung für das Hochladen einzelner Markdown‑Dateien oder ganzer Ordner wäre wünschenswert
  • Es wäre hilfreich, Diff‑ oder Änderungsinformationen vor und nach der Umwandlung im Web zu sehen
  • Statt nur die Ergebnisdatei zu erzeugen, muss der Umwandlungs‑ und Prüfungsprozess vom Menschen überprüft werden können

Durch diese Frage wurde mir klar, dass der JSONL‑Umwandler kein reines Batch‑Skript, sondern ein Daten‑Aufbereitungstool sein muss, das von Menschen geprüft und genehmigt wird.

Das Problem, dass eine Datei mehreren Tabellen zugeordnet werden kann, erneut bestätigt

Die wichtigste Zusatzfrage war, dass eine Markdown‑Datei nicht zwingend nur einer Tabelle zugeordnet werden muss.

Zum Beispiel kann ein einzelnes Migrations‑Dokument gleichzeitig drei Arten von JSONL erzeugen.

  • Offizielle Beschreibungs‑Chunks → docs_chunks.jsonl
  • API‑Änderungsregeln → api_mapping.jsonl
  • Umwandlungs‑/Klassifizierungs‑Beispiele → label_prototypes.jsonl

Daher muss der Umwandler nicht nur eine Datei einlesen und ein einzelnes JSONL erzeugen, sondern zuerst über Qwen bestimmen, welche Tabellendatensätze benötigt werden, und bei mehreren Antworten mehrere JSONL‑Datensätze aus einer Datei erzeugen können.

Heute festgelegte Design‑Richtung

  • Die Markdown‑zu‑JSONL‑Umwandlung wird in die Phasen Klassifizierung → Erzeugung → Validierung → Speicherung unterteilt.
  • Qwen kann die Eingabe lesen und entscheiden, welche Ziel‑Tabellen benötigt werden.
  • Die Antworten von Qwen werden nicht blind vertraut; ein lokaler Schema‑Validator entscheidet über das endgültige Speichern.
  • Reguläre Ausdrücke dienen nur zur minimalen Formatprüfung; die eigentliche Feld‑Validierung sollte mit JSON‑Schema oder Pydantic erfolgen.
  • Es wird als Grundannahme angenommen, dass aus einer Markdown‑Datei mehrere JSONL‑Ausgaben entstehen können.
  • Das Web‑UI ist nicht nur eine Komfortfunktion, sondern kann als Prüf‑Schicht dienen, in der automatisch erzeugte Datensätze vom Menschen bestätigt oder abgelehnt werden.

Nächste Arbeitspunkte

  1. Entwurf eines JSON‑Schemas für docs_chunks, api_mapping und label_prototypes.
  2. Prompt‑Design, das Qwen dazu bringt, aus einer einzelnen Markdown‑Datei die Ziel‑Tabellen‑Kandidaten zu bestimmen.
  3. Regeln erstellen, wie bei mehreren Tabellendatensätzen die Ausgabe pro Datei getrennt gespeichert wird.
  4. Zunächst ein CLI‑Skript für die zeilenweise JSONL‑Validierung entwickeln.
  5. Anschließend das Web‑UI erweitern, sodass Hochladen, Umwandlung, Diff, Validierungsergebnis und Genehmigungs‑/Ablehnungs‑Flow sichtbar werden.

Offene Fragen

  • Wie kann Qwen die Tabell‑Zuordnung übernehmen, und in welchen Fällen muss ein Mensch zwingend genehmigen?
  • Soll die api_mapping‑Kandidatur sofort in die Datenbank übernommen werden oder nur im Status candidate gespeichert werden?
  • Soll das Diff im Web‑UI im Vergleich zum Original‑Markdown oder im Vergleich zur vorherigen JSONL‑Version angezeigt werden?
  • Wie sollen fehlgeschlagene und teilweise erfolgreiche Dateien bei einem Ordner‑Upload erneut versucht werden?