Claude Opus 5.5 und Sonnet 5.5 im Anfrage-Triage: Was vor der Auswahl gemessen werden sollte

Entscheidend ist nicht, welches Modell fähiger wirkt, sondern welches diesen Ablauf mit weniger Risiko bewältigt

Ein Vergleich von Claude Opus 5.5 und Claude Sonnet 5.5 für den Kundenservice setzt zunächst voraus, dass klar ist, was mit „Triage“ gemeint ist. In dieser Evaluation soll das Modell weder dem Kunden antworten noch eine Lösung formulieren oder eigenständig über eine Entschädigung entscheiden. Die Aufgabe besteht darin, eine kurze Anfrage in strukturierte Daten umzuwandeln, die einer Person oder einem nachgelagerten System bei der Klassifizierung und Weiterleitung an das zuständige Team helfen.

Dieser Unterschied ist wichtig. Ein Modell kann eine flüssige Antwort erzeugen und trotzdem das Anliegen falsch erkennen, eine nicht mitgeteilte Information erfinden oder übersehen, dass Angaben fehlen. Im operativen Betrieb können solche Fehler schwerer wiegen als Tonfall oder Antwortlänge. Der Vergleich sollte daher konkrete Felder und Weiterleitungsentscheidungen messen – nicht bloß allgemeine Eindrücke zur Gesprächsqualität.

Die verfügbaren verifizierten Belege reichen nicht aus, um für diesen Ablauf einen Sieger zu benennen. Es fehlt eine gemeinsame Bewertung beider Modelle anhand von Supportanfragen, einer einheitlichen Bewertungsrubrik und reproduzierbaren Ergebnissen für Klassifizierung, Extraktion und Eskalation. Die verfügbaren Informationen zu Sonnet 5.5 können zur Beschreibung des Modells dienen, belegen aber nicht dessen Leistung gegenüber Opus 5.5 bei dieser Aufgabe. Ein Vergleich von Medium-Konfigurationen nennt beide Modelle, liefert im verifizierten Material jedoch ebenfalls keine Ergebnisse zur Anfrage-Triage.

Dieser Leitfaden präsentiert deshalb weder Punktzahlen noch gibt er vor, ein Test sei bereits durchgeführt worden. Stattdessen beschreibt er ein Verfahren, das ein Team anwenden kann, sofern es den Zugriff auf die exakten Modellvarianten bestätigt und die Bedingungen jeder Ausführung dokumentiert. Bis dahin muss jede Empfehlung für eines der Modelle vorläufig bleiben. Weitere Modellvergleiche finden sich in der Vergleichsübersicht; auch sie ersetzen jedoch keine Evaluation, die auf den konkreten Ablauf und die eigenen Daten zugeschnitten ist.

Aufgabe und Ausgabeformat festlegen, bevor der Test beginnt

Der erste Schritt ist eine Spezifikation, die nicht von den Antworten eines der Modelle abhängt. Für jede Anfrage soll das System ausschließlich die Felder zurückgeben, die der Prozess tatsächlich benötigt. Ein beispielhaftes Schema könnte eine Hauptkategorie, gegebenenfalls zusätzliche Kategorien, Dringlichkeit, das erwähnte Produkt oder den erwähnten Dienst, eine ausdrücklich genannte Kennung, fehlende Angaben, einen Vertrauensgrad und die Entscheidung enthalten, ob der Vorgang fortgesetzt oder eskaliert werden soll. Das Team muss festlegen, welche Felder verpflichtend sind und welche Werte jeweils zulässig sind.

Klassifizierung und Weiterleitung dürfen nicht gleichgesetzt werden. „Abrechnungsproblem“ kann eine zutreffende Klassifizierung sein, aber für die Weiterleitung möglicherweise nicht ausreichen, wenn die Anfrage zugleich einen dringenden Dienstausfall meldet. Die Bewertungsrubrik muss festlegen, wie mehrere Anliegen in einer Nachricht behandelt werden, ob mehrere Kategorien zulässig sind und nach welcher Regel die Priorität bestimmt wird. Ohne diese Definition können zwei Prüfende dieselbe Ausgabe unterschiedlich bewerten.

Die syntaktische Gültigkeit sollte außerdem getrennt von der inhaltlichen Richtigkeit bewertet werden. Eine Antwort kann das strukturierte Format genau einhalten und ihre Felder trotzdem falsch befüllen. Umgekehrt kann das Modell die Anfrage richtig verstehen, aber das für die Integration erforderliche Format verfehlen. Diese Dimensionen sind getrennt zu bewerten, damit ein operatives Problem nicht hinter einer zusammengefassten Punktzahl verschwindet.

Anweisungen, Schema, Kategorien, Eskalationsregeln und Bewertungsverfahren werden vor dem Test festgelegt. Änderungen nach Testbeginn sind als neue Testversion zu dokumentieren. Die Regeln dürfen nicht nachträglich angepasst werden, um das Ergebnis eines Modells zu begünstigen.

Einen Testsatz erstellen, der echte Anfragen abbildet – nicht nur einfache Beispiele

Ein aussagekräftiger Test sollte einfache und schwierige Fälle enthalten. Eindeutige Beispiele zeigen, ob das Modell ein Anliegen erkennt, wenn es direkt formuliert ist. Unvollständige Anfragen prüfen, ob fehlende Informationen erkannt werden. Mehrdeutige Fälle zeigen, ob das Modell eine Prüfung anfordert oder eine unbegründete Kategorie auswählt. Sinnvoll sind außerdem Nachrichten mit mehreren Anliegen, Tippfehlern, Abkürzungen und kontextabhängigen Verweisen – sofern solche Merkmale auch im zu bewertenden Kanal vorkommen.

Der Testsatz sollte die Verteilung abbilden, die das Team für die spätere Verarbeitung erwartet, zugleich aber genügend Beispiele für seltene Risiken enthalten, damit diese gesondert untersucht werden können. Kommt eine dringende Kategorie im tatsächlichen Anfrageaufkommen nur selten vor, könnte sie in einer kleinen Zufallsstichprobe ganz fehlen. Das Team kann deshalb eine zusätzliche Gruppe von Risikofällen aufnehmen und separat auswerten. Dabei muss klar bleiben, dass diese Gruppe nicht die tatsächliche Häufigkeit der Fälle repräsentiert.

Jeder Fall benötigt ein Referenzlabel und eine kurze Begründung für die erwartete Entscheidung. Bei strittigen Beispielen sollten vorzugsweise zwei Personen die Bewertungsregel prüfen und sich auf die Referenz einigen, bevor die Modelle verglichen werden. Können die Prüfenden einen Fall anhand der vorhandenen Richtlinie nicht entscheiden, sollte dieser als unsicher markiert, aus der Hauptbewertung ausgeschlossen oder separat ausgewertet werden.

Um zu vermeiden, dass der Testsatz zu einer auswendig lernbaren Prüfung wird, sollte ein Teil der Fälle für die Bewertung zurückgehalten und nicht zur Anpassung der Anweisungen verwendet werden. Anfragen sind zu anonymisieren und auf die für den Test erforderlichen Angaben zu beschränken. Identifizierbare Gespräche dürfen erst dann in ein Werkzeug kopiert werden, wenn geklärt ist, dass die Bedingungen des verwendeten Kanals eine solche Nutzung erlauben.

Prüfen, ob der Vergleich tatsächlich gleichwertige Bedingungen abbildet

Der in einer Benutzeroberfläche angezeigte Name reicht nicht aus, um festzustellen, was genau getestet wird. Vor dem Test müssen die exakte Modellkennung des jeweiligen Zugangs, das Datum, die verwendete Schnittstelle oder API und die konfigurierbaren Parameter festgehalten werden. Wenn einer der Zugänge auf eine andere Variante verweist, zusätzliche Werkzeuge verwendet oder eine Konfiguration anwendet, die der andere nicht bietet, handelt es sich nicht mehr um einen streng gleichwertigen Vergleich.

Die verfügbaren Informationen zu Sonnet 5.5 beschreiben Änderungen, Kompatibilität und weitere Angaben zu diesem Modell, decken aber Opus 5.5 nicht ab und legen nicht allein fest, wie sich beide Zugänge angleichen lassen. Ein vorliegender Vergleich von Medium-Konfigurationen benennt beide Modelle. Das kann ein Ansatzpunkt für weitere Untersuchungen sein, belegt aber weder, dass der vom Team gewählte operative Zugang dieselben Parameter bereitstellt, noch, dass der Supportablauf dort gemessen wurde.

Sind die Kontrollmöglichkeiten nicht identisch, darf keine künstliche Gleichwertigkeit behauptet werden. Möglich sind zwei getrennte Analysen: eine Untersuchung der Fähigkeiten mit einer gemeinsamen Konfiguration, soweit sie verfügbar ist, und eine Untersuchung der operativen Leistung über die tatsächlich vorgesehenen Kanäle. Bei der zweiten Analyse müssen die Unterschiede ausdrücklich dokumentiert werden. Ebenso festzuhalten sind Ausgabelimits, verfügbare Werkzeuge, automatische Wiederholungen und alle Umformungen durch die Plattform.

Die Anweisungen sollten identisch bleiben, wenn der Einfluss des Modells isoliert werden soll. Wird für jedes Modell ein anderer Prompt angepasst, wird die Kombination aus Modell und Konfiguration verglichen – nicht nur die Modelle. Für die Auswahl einer Produktionslösung kann ein solcher Versuch sinnvoll sein, muss aber entsprechend bezeichnet und dokumentiert werden.

Qualität nach Dimensionen messen und Fehler untersuchen, die Entscheidungen verändern

Die Hauptbewertung sollte nach Dimensionen aufgeschlüsselt werden. Für die Klassifizierung wird der Anteil richtiger Labels ermittelt und nach Kategorie ausgewiesen: Ein Gesamtdurchschnitt kann verdecken, dass das System gerade bei der sensibelsten Anfrageart versagt. Bei der Extraktion wird jedes Feld einzeln geprüft; dabei zählen sowohl ausgelassene als auch unbegründet hinzugefügte Angaben. Wenn mehrere Werte zulässig sind, muss die Bewertungsrubrik deren Beurteilung festlegen.

Für die Erkennung fehlender Informationen braucht es eine ausdrückliche Referenz: Welche Angabe fehlt, ob sie wirklich notwendig ist und ob die richtige Reaktion darin besteht, nachzufragen, das Feld leer zu lassen oder den Fall zu eskalieren. Es reicht nicht, ein Modell dafür zu belohnen, dass es häufig „weiß ich nicht“ sagt. Unnötige Enthaltungen können den Support verlangsamen; fehlende Zurückhaltung bei relevanter Unsicherheit kann dagegen dazu führen, dass ein Fall in der falschen Warteschlange landet.

Bei der Eskalation sind beide Arten von Fehlern zu messen. Eine Eskalation, die die Richtlinie nicht verlangt, bindet menschliche Kapazität. Wird ein unsicherer Fall nicht eskaliert, kann eine Vermutung zur operativen Entscheidung werden. Das Team sollte diese Kosten entsprechend den möglichen Folgen gewichten. Ist es deutlich schwerwiegender, nicht zu eskalieren, als unnötig zu eskalieren, kann ein konservativer Schwellenwert festgelegt werden. Dann sollte auch ausgewiesen werden, welche zusätzliche Prüflast daraus entsteht.

Formatfehler sind getrennt von der inhaltlichen Qualität zu erfassen. Berichtet werden kann der Anteil der Ausgaben, die das Schema erfüllen, und – unter den gültigen Ausgaben – der Anteil, der außerdem die inhaltlichen Kriterien besteht. Fehler mit besonders großer Auswirkung sollten manuell geprüft werden: falsch zugewiesene Dringlichkeit, erfundene personenbezogene Angaben, fehlerhafte Weiterleitung und eine unterlassene Eskalation.

Unterschiede zwischen den Modellen sollten ohne Berücksichtigung der statistischen Unsicherheit und der einzelnen Fälle nicht als endgültig gelten. Bei einem kleinen Testsatz können bereits wenige Beispiele den Prozentwert stark verändern. Zähler, Nenner und beobachtete Fehler zu veröffentlichen, erleichtert die Einordnung stärker als eine einzelne Gesamtnote.

Latenz und Kosten pro akzeptiertem Fall berechnen – nicht nach Eindruck beurteilen

Die Latenz sollte mit einem einheitlichen Verfahren gemessen werden: vom Absenden der Anfrage bis zu dem Zeitpunkt, an dem die Ausgabe verfügbar ist und validiert wurde. Neben der Zahl der Durchläufe sollten der Median und ein Wert aus dem oberen Latenzbereich, etwa das 95. Perzentil, ausgewiesen werden. Die Messungen sollten die Bedingungen abdecken, die das Team im Produktivbetrieb erwartet; ein einzelner Durchlauf bildet die Schwankungen des Dienstes nicht zwingend ab.

Für die Kosten müssen der Kanal, das Datum, die abgerechneten Einheiten und die für diese Konfiguration geltenden Tarife dokumentiert werden. Die hier verifizierten Informationen reichen nicht aus, um einen vollständigen Preisvergleich für beide Modelle über die Kanäle zu bestätigen, die ein Team verwenden würde. Ein Preis aus einer Sekundärquelle, für eine andere Variante oder von einem anderen Datum darf nicht so behandelt werden, als entspräche er den tatsächlichen Kosten der geprüften Integration.

Aussagekräftiger als die nominellen Kosten pro Aufruf sind die Kosten pro akzeptiertem Fall. Dafür werden die beobachteten Ausführungskosten und die erforderlichen Prüfkosten addiert und durch die Zahl der Fälle geteilt, die die Bewertungsrubrik erfüllen. Löst eine ungültige Ausgabe Wiederholungen oder menschliches Eingreifen aus, kann diese Arbeit ebenfalls in die operativen Kosten einfließen – sofern die Methode im Voraus festgelegt und für beide Optionen gleich angewandt wird.

Die Berechnung darf keine Kosten vermischen, die nicht tatsächlich erfasst wurden. Werden Infrastruktur, Prüfzeit oder Wiederholungen ausgeklammert, muss das angegeben werden. Das Ergebnis gilt für die untersuchte Konfiguration und das betrachtete Volumen, nicht als allgemeine Eigenschaft des Modells.

Datenschutz und Governance als Eigenschaften des Zugangskanals behandeln

Datenschutz lässt sich weder aus dem Modellnamen noch aus der Fähigkeit zur Klassifizierung ableiten. Er hängt von den Bedingungen des konkreten Dienstes ab: Welche Daten übermittelt werden, wie lange sie gespeichert bleiben, wer darauf zugreifen kann, ob sie für andere Zwecke genutzt werden und welche Kontrollen der verwendete Kanal bietet. Diese Bedingungen können sich zwischen einer Nutzeroberfläche, einem Geschäftsdienst und einer API unterscheiden. Sie dürfen deshalb nicht als allgemeine Eigenschaft von Opus 5.5 oder Sonnet 5.5 dargestellt werden.

Vor einem Test mit echten Supportanfragen muss die verantwortliche Stelle den Kanal bestimmen, die geltenden Bedingungen prüfen und die erforderliche interne Freigabe einholen. Ist eine solche Überprüfung nicht möglich, sollten synthetische oder angemessen anonymisierte Daten verwendet werden. Dabei ist zu berücksichtigen, dass eine Anonymisierung nicht automatisch jedes Risiko beseitigt. Geheimnisse, Zugangsdaten und nicht erforderliche personenbezogene Informationen sind ebenfalls auszuschließen.

Auch wenn die Bedingungen für die Datenverarbeitung akzeptabel sind, sollte die Ausgabe zunächst als Vorschlag gelten – bis die Evaluation und das Kontrolldesign eine weitergehende Nutzung rechtfertigen. Eine falsche Klassifizierung kann Bearbeitungszeiten oder die erbrachte Unterstützung beeinflussen. Für Entscheidungen über Priorität, Zugang, Entschädigung oder Schließung eines Falls muss die Richtlinie festlegen, welche menschliche Prüfung erforderlich ist und wie Fehler korrigiert werden.

Eine Schlussfolgerung veröffentlichen, ohne ihre Aussagekraft zu überdehnen

Ein aussagekräftiger Bericht würde Gesamtergebnisse und Resultate nach Anfrageart zusammen mit dem Prüfverfahren, der Zahl der Fälle, den Referenzlabels, den Anweisungen und den verifizierten Konfigurationen präsentieren. Er würde außerdem Ausschlüsse, unsichere Fälle, Fehler mit besonders großen Auswirkungen und Zugangsbedingungen erläutern, die sich nicht angleichen ließen. Soweit die Veröffentlichungsbedingungen es erlauben, sollten die für eine Wiederholung erforderlichen Materialien bereitgestellt werden – ohne Daten, die Kunden identifizieren könnten.

Die Schlussfolgerung sollte auf die untersuchte Population, den Kanal und die Konfiguration begrenzt bleiben. Erzielt Sonnet 5.5 in einem Testsatz mit häufigen Anfragen geringere Kosten pro akzeptiertem Fall, beweist das nicht, dass es sich für alle Arten von Support besser eignet. Erkennt Opus 5.5 in einer bestimmten Stichprobe mehr mehrdeutige Fälle, belegt auch das keinen allgemeinen Vorteil. Ein Ergebnis kann einen stillen Test oder einen begrenzten Pilotbetrieb mit menschlicher Prüfung rechtfertigen, nicht aber eine sofortige Automatisierung.

Die Bedingungen für einen Produktionstest müssen im Voraus festgelegt werden: höchstzulässiger Anteil kritischer Fehler, Anteil gültiger Ausgaben, Eskalationsrichtlinie, Datenschutzkontrollen und Verfahren für eine Rücknahme. Werden die Bedingungen nicht erfüllt, ist es ratsam, die menschliche Prüfung beizubehalten oder die Einführung auszusetzen. Versagen beide Modelle bei einer Kategorie ähnlich, liegt das Problem möglicherweise am Schema, an der Richtlinie oder an der Datenqualität – und nicht an einem Unterschied, den die Auswahl zwischen den Modellen beheben könnte.

Mit den derzeit verifizierten Belegen lässt sich keines der beiden Modelle als Sieger für die Anfrage-Triage empfehlen. Es lässt sich aber genau bestimmen, was für eine Entscheidung noch fehlt: Modellkennungen und Zugangskanäle bestätigen, eine Bewertungsrubrik festlegen, dieselbe Fallsammlung unter dokumentierten Bedingungen ausführen und die operativ relevanten Fehler messen. Bis diese Daten vorliegen, ist jede Auswahl eine zu prüfende Hypothese und keine belegte Schlussfolgerung.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.