SYNX 3.7: SYNXL bringt typisierte Datensatzströme in KI-Datasets

SYNX 3.7 ist da. Die Version fügt der Sprache genau einen Operator hinzu und daneben ein komplett neues Dateiformat: SYNXL — ein Datensatzstrom-Format für Datasets, gebaut für die zwei Aufgaben, in die JSONL und CSV üblicherweise gepresst werden und die beide schlecht lösen.

Kurz gesagt: Felder einmal deklarieren, danach typisierte Datensätze streamen. Verschachtelung und mehrzeiliger Text kommen mit, und fehlerhafte Zeilen werden gemeldet statt still zu verschwinden.

Warum JSONL und CSV bei Datasets wehtun

Öffne irgendeinen JSONL-Trainingsdatensatz und sieh dir an, wofür du tatsächlich bezahlst. Jeder Datensatz wiederholt jeden Schlüssel, jede Klammer, jedes Anführungszeichen. Bei einem Korpus aus einigen hunderttausend Chat-Beispielen sind allein die Feldnamen ein messbarer Anteil der Tokens, die du einem Modell gibst — und nach der ersten Zeile tragen sie keine Information mehr.

Mehrzeiliger Text ist schlimmer. Ein Prompt, ein Codebeispiel, eine Modellantwort — alles fällt zu Rauschen aus \n-Escapes zusammen, das kein Mensch liest und jedes Diff zerlegt.

CSV vermeidet die Wiederholung, gibt dafür fast alles andere auf: keine Typen, keine Verschachtelung — und die offene Frage, auf die jede CSV-Pipeline irgendwann stößt: Ist eine leere Zelle ein leerer String oder ein fehlender Wert? Setz ein Komma in ein Feld, und du steckst in Anführungsregeln, die sich je Dialekt unterscheiden.

SYNXL auf einem Bildschirm

!synxl 1
!fields id[type:int] ; score[type:float] ; messages[block]

1 ; 0.91
  messages
    - role system
      content You are a helpful assistant.
    - role user
      content |+
          def f(x):
              return x + 1

2 ; 0.74
  messages
    - role user
      content Привет

Die Feldliste wird einmal deklariert. Datensätze beginnen in Spalte null, skalare Felder werden durch ; getrennt, und jedes Feld mit der Markierung [block] klappt unter dem Datensatz in vollem SYNX auf — Listen, verschachtelte Objekte, mehrzeiliger Text. Genau dadurch lassen sich chat-förmige Daten direkt ausdrücken, statt sie in einen escapten String zu plätten.

Dieses Beispiel projiziert sich auf gewöhnliches JSON:

[{"id":1,"messages":[{"content":"You are a helpful assistant.","role":"system"},
  {"content":"def f(x):\n    return x + 1","role":"user"}],"score":0.91}, …]

Was das Format tatsächlich garantiert

• Typen dort, wo sie hingehören. [type:int], [required], [enum:a|b|c] stehen im Kopf, nicht in einer separaten Schemadatei, und werden nicht pro Zeile neu erraten.

• Leer ist nicht nichts. Ein leeres Feld ist null; ein leerer String wird als "" geschrieben. Die CSV-Mehrdeutigkeit entfällt bauartbedingt.

• Nichts geht still verloren. SYNX überspringt fehlerhafte Struktur stillschweigend. SYNXL meldet sie — fehlende Felder, überzählige Felder, gescheiterte Umwandlungen, unbekannte Block-Schlüssel — jeweils mit Datensatzindex und Zeilennummer. Ein Dataset, das eine Spalte verliert, ohne es zu sagen, ist schlimmer als eines, das laut scheitert.

• Datensätze sind unabhängig. Eine Datensatzgrenze lässt sich an einem einzigen Byte erkennen, deshalb kann das Format sicher angehängt, sauber geshardet und parallel geparst werden.

• Schema-Evolution mitten in der Datei. Eine Spalte dazugekommen? Schreib eine neue !fields-Zeile und häng weiter an. Frühere Datensätze bleiben gültig und behalten ihre ursprüngliche Form.

Für Dateien gebaut, die nicht in den Speicher passen

Die Eingabegrenze von 16 MiB, die SYNX auf ein Dokument anwendet, gilt in SYNXL pro Datensatz — Datasets sind regelmäßig Gigabytes groß und Datensätze sind unabhängig, eine Grenze für die ganze Datei schützt also nichts, was eine Grenze pro Datensatz nicht schon schützt.

Der Streaming-Reader hält genau einen Datensatz gleichzeitig. Gemessen mit der CLI an einer 142-MB-Datei mit 2,4 Millionen Datensätzen bleibt der Spitzenspeicher flach bei etwa 10 MB — über validate, parse und split hinweg; dieselbe Datei komplett in den Speicher zu lesen würde mindestens ihre eigene Größe kosten.

Die andere Hälfte von 3.7: |+

Die Sprache selbst hat genau eine Neuerung bekommen: |+, einen mehrzeiligen Öffner, der Einrückung bewahrt. Das einfache | beschneidet jede Fortsetzungszeile — für Prosa in Ordnung, für alles mit bedeutsamen Leerzeichen zerstörerisch. |+ fixiert eine Basiseinrückung an der ersten Inhaltszeile und bewahrt alles danach — Code, ASCII-Diagramme und Prompt-Gerüste bleiben in einem Wert unversehrt.

SYNX 3.6 bleibt die eingefrorene Interoperabilitätsbasis. 3.7 ist rein additiv: Ein 3.6-Parser bleibt konform für jedes Dokument, das auf 3.7-eigene Konstrukte verzichtet.

Aus dem Code lesen

SYNXL gibt es heute in vier Implementierungen, hinter jeder dieselbe Semantik:

// Rust
let doc = synx_core::synxl::parse_lines(&text)?;
for record in &doc.records { /* … */ }

// TypeScript
import { parseSynxl, streamSynxlFile } from '@aperturesyndicate/synx-format'
for (const record of streamSynxlFile('dataset.synxl')) { /* … */ }

# Python
import synx_native as synx
for record in synx.synxl_stream_file("dataset.synxl"):
    train(record["messages"])

Und aus der Shell, samt Konvertern in beide Richtungen:

synx synxl parse dataset.synxl --format ndjson
synx synxl validate dataset.synxl --constraints
synx synxl convert corpus.jsonl          # jsonl → synxl
synx synxl split dataset.synxl -n 500000 # shards that are valid on their own

Verfügbarkeit

3.7.1 ist veröffentlicht auf crates.io, npm, PyPI und NuGet.

SYNXL selbst ist in Rust, TypeScript, Python und der CLI umgesetzt. Die nativen Parser für C++, Dart, .NET, Go, Java und Swift unterstützen SYNX 3.7 einschließlich |+, lesen aber noch kein .synxl — bis dahin per CLI konvertieren oder aus einer der vier Implementierungen lesen.

Spezifikation und Konformität

SYNXL wird auf einer eigenen Achse versioniert — Formatversion 1, unabhängig von der Sprachversion — denn ein SYNXL-Dokument ist kein SYNX-Dokument: Auf oberster Ebene steht eine Folge von Datensätzen statt eines Objekts.

Der normative Text ist SYNXL-1-NORMATIVE.md, und dahinter steht eine Sammlung von 67 Konformitätsfällen, die unabhängig von jeder Implementierung aus diesem Text abgeleitet wurden. Der Rust-Runner liest zusätzlich jeden akzeptierten Fall mit allen drei Readern erneut und schlägt fehl, wenn sie sich uneinig sind.

Vollständige Dokumentation und eine Live-Spielwiese: synx.aperturesyndicate.com

Was als Nächstes kommt

SYNXL-Unterstützung für die übrigen Parser, beginnend mit Go und .NET. Die Spezifikation ist stabil und die Konformitätssuite geschrieben, deshalb ist die zweite Welle mechanisch statt explorativ — genau dafür schreibt man die Tests vor den Implementierungen.