Der Praxistest in Kürze

Für Seetours, die Vertriebsmarke von AIDA Cruises, erzeugt ein Sprachmodell Entwürfe für Angebotsseiten. Aus Reisedaten, Bildverweisen und redaktionellen Regeln sollen Reisebeschreibungen mit Hafenabschnitten und vollständigem HTML entstehen. Preise liefert das Buchungssystem; die Redaktion prüft und veröffentlicht den Entwurf.

Die Aufgabe ist anspruchsvoller, als ein flüssiger Reisetext vermuten lässt. Jeder Hafen braucht den richtigen Abschnitt, jedes Bild die passende Zuordnung und jede verwendete URL muss exakt übernommen werden. Bei einer Reise mit zwanzig Häfen kommen viele Bindungen zusammen. Ein überzeugend formulierter Absatz hilft wenig, wenn darunter das Bild eines anderen Hafens steht.

Wir haben dafür auch lokal betriebene Modelle erprobt. In diesem Workflow erreichten die getesteten Varianten, einschließlich gpt-oss-120b, bei der vollständigen HTML-Erzeugung nicht die Qualität der eingesetzten kommerziellen Frontier-Modelle. Das ist eine Erfahrung aus einem konkreten Projekt, kein allgemeines Ranking lokaler und gehosteter KI. Ohne einen veröffentlichten Vergleich mit identischen Prompts, Modellversionen, Einstellungen und Fehlerquoten lässt sich daraus kein belastbarer Abstand in Prozent ableiten.

Die Aufgabe ist der Maßstab

„Lokal oder Cloud?“ beschreibt zunächst den Betriebsort. „Offene oder geschlossene Gewichte?“ ist eine andere Frage. Weder der Betriebsort noch die Lizenz legt für sich genommen fest, wie gut ein Modell Reiseinformationen zuordnet oder Anweisungen einhält.

Für unsere Aufgabe zählt das fertige Ergebnis: Sind alle geforderten Häfen vorhanden? Passen die Bilder? Sind die URLs vollständig und unverändert? Ist das HTML verwendbar? Und wie viel muss die Redaktion nacharbeiten? Diese Kriterien sagen für den Einsatz mehr aus als eine allgemeine Benchmark-Punktzahl.

Auch gute Einzelresultate reichen nicht. Eine Angebotsredaktion braucht Qualität über viele unterschiedliche Routen hinweg: kurze Reisen ebenso wie lange Hafenfolgen, ähnliche Ortsnamen und wiederkehrende Bildmotive. Die schwierigsten Fälle gehören deshalb in die Bewertung.

Training und Nachtraining können den Unterschied machen

Ein Sprachmodell muss hier gleichzeitig schreiben, zuordnen und Regeln befolgen. Training auf strukturierten Daten und gezieltes Nachtraining für Anweisungsbefolgung sind dafür relevante Faktoren. Wie stark ein bestimmter Anbieter diese Fähigkeiten trainiert hat, lässt sich aber nicht allein aus dem Produktnamen erschließen.

Bei geschlossenen Modellen sind Trainingsdaten, Modellaufbau und Betrieb nur teilweise öffentlich dokumentiert. Unser Ergebnis belegt deshalb weder eine bestimmte Datenmenge noch eine überlegene Positionskodierung. Aussagen wie „Das Modell hat mehr korrekte HTML-Dokumente gesehen“ wären ohne weitere Belege eine mögliche Erklärung, keine nachgewiesene Ursache.

Dasselbe gilt für zusätzliche Rechenschritte vor der Antwort. Reasoning kann bei Aufgaben mit mehreren Bedingungen helfen. Es ist jedoch keine exklusive Eigenschaft kommerzieller Cloud-Modelle: Auch gpt-oss ist als Reasoning-Modell ausgelegt. Quelle: OpenAI, gpt-oss Model Card.

Warum die Parameterzahl nicht genügt

gpt-oss-120b besitzt rund 117 Milliarden Parameter, von denen pro Token etwa 5,1 Milliarden aktiv sind. Als Mixture-of-Experts-Modell wählt es für einzelne Verarbeitungsschritte einen Teil seiner Experten aus. Quelle: OpenAI, Introducing gpt-oss.

Gesamtparameter und aktive Parameter beschreiben damit unterschiedliche Eigenschaften. Aus den 5,1 Milliarden aktiven Parametern folgt aber nicht, dass ein dichtes 70-Milliarden-Modell die Zuordnungsaufgabe zwangsläufig besser löst. Architektur, Training und die konkrete Aufgabe bleiben Teil des Vergleichs. „Aktive Parameter“ sind auch kein Maß für die Tiefe eines Modells.

Für die Auswahl heißt das: Die größere Zahl auf dem Etikett ersetzt keinen Test mit den eigenen Daten. Ein größeres Modell kann helfen, muss aber nicht die Fehler beheben, die den Ablauf tatsächlich aufhalten.

Lange Kontexte bleiben eine eigene Herausforderung

Die Studie „Lost in the Middle“ zeigte bei den untersuchten Modellen, dass die Position relevanter Informationen im Kontext die Leistung beeinflussen kann. Informationen in der Mitte wurden teils schlechter genutzt als am Anfang oder Ende. Das ist ein Befund zu den dort untersuchten Aufgaben und Modellen, keine Diagnose für jeden Fehler auf einer Seetours-Angebotsseite. Quelle: Liu et al., Lost in the Middle.

Die praktische Konsequenz ist trotzdem hilfreich: Wir sollten nicht nur prüfen, ob alle Reisedaten in das Kontextfenster passen. Wir müssen prüfen, ob das Modell sie verlässlich verwendet. Klar getrennte Hafenabschnitte, eindeutige Kennungen und überschaubare Teilaufgaben machen diese Prüfung einfacher.

Quantisierung prüfen, statt sie zur Erklärung zu machen

Quantisierung reduziert die numerische Genauigkeit von Modellgewichten und kann Speicher sparen. Welche Folgen das für die Qualität hat, hängt unter anderem vom Modell und vom Verfahren ab. Bei gpt-oss wurden die Expertengewichte bereits mit Blick auf MXFP4-Quantisierung trainiert. Quelle: OpenAI, Introducing gpt-oss.

Ein vertauschtes Hafenbild lässt sich deshalb nicht ohne Weiteres auf „weggerundete Nachkommastellen“ zurückführen. Dafür müssten verschiedene Präzisionsvarianten desselben Modells unter vergleichbaren Bedingungen getestet werden. Ebenso wenig können wir voraussetzen, dass geschlossene Cloud-Modelle grundsätzlich mit voller numerischer Präzision laufen.

Quantisierung gehört in die Dokumentation eines Modellvergleichs. Als alleinige Erklärung für unser Projektergebnis reicht sie nicht aus.

Die Modellwahl ist nur ein Teil der Architektur

Im Seetours-Workflow werden die Reisedaten zuerst aus dem Buchungssystem beschafft und zu einem Kontext verdichtet. Bildverweise, interne Linkziele und Schreibregeln ergänzen diesen Kontext. Nach der Generierung prüft und repariert das System das HTML und validiert die Links. Der Entwurf bleibt bis zur redaktionellen Freigabe unveröffentlicht.

Daraus lässt sich eine weitere Architekturentscheidung ableiten: Exakte URLs, Preise und verbindliche Zuordnungen sollten möglichst aus geprüften Daten und festen Regeln stammen. Das Modell kann Formulierungen vorschlagen; wiederkehrende technische Strukturen lassen sich durch Templates erzeugen. Eine solche Aufteilung muss im konkreten Workflow getestet werden und ist keine nachträgliche Behauptung über bereits umgesetzte Funktionen.

Ob dafür am Ende ein lokales oder ein gehostetes Modell eingesetzt wird, entscheidet die Qualität der abgegrenzten Aufgabe zusammen mit Datenanforderungen, Betrieb und Aufwand. Unsere Erfahrung spricht dafür, diese Grenze bewusst zu ziehen: Was soll das Modell formulieren, was kann die Software zuverlässig einsetzen und was muss ein Mensch freigeben?

Der Projektbericht zeigt, wie dieser Redaktionsprozess in die gesamte Vertriebsplattform eingebettet ist: Seetours – ein eigener Vertriebskanal für AIDA Cruises.