Warum sich Tensor-Shape-Bugs oft erst spät zeigen

Du kennst das Gefühl. Das Training läuft, der Loss sinkt, die Metriken wirken solide. Dann, nach Wochen im Produktivbetrieb, fällt auf, dass die Modell-Ausgaben systematisch falsch sind – und niemand weiß, warum.

Schuld ist meist eine Achse, die in deinem Kopf etwas anderes bedeutet als im Code. Kein Absturz, kein Kompilierfehler. Nur ein stilles Problem, das jede Vorhersage betrifft.

Das Notation-Problem

Was nicht benannt ist, lässt sich schlecht prüfen. Die meisten Tensor-Frameworks interessieren sich nicht für die Bedeutung einer Dimension. Eine Shape wie (32, 768, 12, 64) könnte für (batch, sequence, heads, dim_per_head) stehen – oder ganz andere Inhalte meinen.

Solange die Zahlen stimmen, akzeptiert das Framework jede Operation. Die semantische Bedeutung geht dabei verloren. Genau das ist der unsichtbare Fehler: nicht mathematisch falsch, sondern falsch in der Absicht.

Was eine gute Notation leisten kann

Stell dir vor, deine Tensor-Operationen würden ihre Bedeutung mittragen. Statt blind zu suchen, welche Achse welche Aufgabe erfüllt, könntest du sie von vornherein festlegen:

tensor: [batch=32, sequence=128, heads=12, dim_per_head=64]

Dann prüft das System automatisch, dass:

• Broadcasting nur dort stattfindet, wo es auch vorgesehen ist
• Reduktionen nur die Achsen betreffen, die man wirklich meint
• Aufmerksamkeitsköpfe von den Feature-Dimensionen getrennt bleiben
• LayerNorm die richtigen Achsen normalisiert

Der Compiler wird zum Helfer. Er erkennt einen Achsen-Tausch, noch bevor du drei Wochen lang trainierst.

Was stille Bugs wirklich kosten

In der Forschung verschwenden Teams oft Stunden dabei, die Ursache für nicht-replizierbare Zahlen zu finden. Manchmal ist der Fehler schlicht eine falsche Achsenreihenfolge. In der Produktion können solche Probleme eine Modell-Genauigkeit von 96% auf 94% sinken lassen – klein genug, um zu verstecken, groß genug, zu wirken.

In Teams wirkt sich das ebenfalls auf die Zusammenarbeit aus. Werden Achsen-Namen nicht explizit festlegt, trifft man häufig auf unterschiedliche Konventionen. Diese impliziten Verwirrungen können beim Mergen von Codebase-Teilen zu neuen Mismatches führen.

Wie bessere Benennung mehr Möglichkeiten erlaubt

This gets at something deeper: notation influences what you can reason about.