Claude Fable 5.5 vs Fable 5.1: So prüfen Sie ein Upgrade
Was ist über den Upgrade-Pfad bekannt?
| Migrationsfrage | Was jetzt möglich ist | Was Belege benötigt |
|---|---|---|
| Lässt sich die Modell-ID direkt austauschen? | Konfigurationsort der aktuellen Route ermitteln | Exakte Kandidaten-ID und unterstützten Anfragevertrag bestätigen |
| Verhalten sich Tools und strukturierte Ausgaben gleich? | Schemas, Testdaten und Abnahmekriterien sichern | Replay mit einer verifizierten Kandidatenroute ausführen |
| Werden bestehende Gespräche korrekt fortgesetzt? | Repräsentative bereinigte Verläufe sichern | Annahme und Fortsetzung der Verläufe testen |
| Bleiben Cache und Kosten übertragbar? | Aktuelle Nutzung und tatsächliche Kosten erfassen | Kandidatenregeln und Abrechnung prüfen; keine Cache-Übertragbarkeit annehmen |
| Ist ein vollständiger Ersatz nötig? | Tatsächlich verbesserungsbedürftige Workloads bestimmen | Ergebnisse vergleichen und entscheiden, ob überhaupt migriert wird |
Der weitere Leitfaden schlägt ein Migrationsverfahren vor. Er behauptet weder bestimmte Fable-5.5-Funktionen noch einen geplanten Veröffentlichungstermin.
Beginnen Sie bei den tatsächlichen Integrationsgrenzen von Fable 5.1
tool_choice-Modi any und tool. Er beschreibt außerdem Einschränkungen für Thinking-Blöcke beim Wechsel zu älteren Modellen oder bei Änderungen früherer Gesprächsinhalte. Das sind bestehende 5.1-Regeln, keine neu entdeckten 5.5-Änderungen. Prüfen Sie ihre Gültigkeit für die konkrete Gateway-Route separat.| Bestehende Abhängigkeit | Was aus der aktuellen App erhalten bleiben sollte | Was die spätere Migration beantworten muss |
|---|---|---|
| Toolauswahl | Toolschemas, erforderliche Geschäftsaktion und deren tatsächliche Prüfung durch die App | Unterstützt der Kandidat die Steuerung und führt er die Aktion ohne nicht unterstützte erzwungene Auswahl aus? |
| Verlauf mit Thinking-Blöcken | Nachrichten in Originalreihenfolge, unverändert empfangene opake Blöcke und Version der Verlaufstransformation | Welche Blöcke bleiben auf Kandidat und Rückfallmodell gültig? |
| Clientseitige Komprimierung | Verläufe vor/nach der Änderung, zusammengefasste Turns und beibehaltene spätere Blöcke | Wird der transformierte Verlauf akzeptiert und bleiben Nutzerentscheidungen erhalten? |
| Streaming und Parsing | Rohe Eventbeispiele, Zusammenbau von Toolaufrufen, Abschluss-/Fehlerzweige und Parser-Version | Rekonstruiert der vorhandene Parser die Ausgabe und unterscheidet Abschluss von Unterbrechung? |
| Nutzung und Cache | Überschneidungsfreie Nutzungskategorien, reale Kosten sowie kalte und warme Läufe | Bleibt das erwartete Cache-Verhalten erhalten und wie hoch sind die neuen Sitzungskosten? |
Die Diagnose ist entscheidend: Wird ein 5.1-Request bereits abgelehnt, nachdem Ihre App frühere Turns umschreibt, ist das ein bestehendes Integrationsproblem. Es darf nicht als Regression eines ungetesteten Nachfolgers gezählt werden. Führen Sie jede Fixture zuerst auf der aktuellen funktionierenden Route aus und dokumentieren Sie Fehler vor Aufnahme des Kandidaten.
Geschäftszustand und Modell-Denkzustand brauchen getrennte Wiederherstellungspfade. Ticket-ID und genehmigte Zuständigkeit gehören in den dauerhaften App-Zustand. Thinking-Blöcke sind modellspezifische Gesprächsartefakte; ihr Erhalt garantiert nicht, dass ein anderes Modell sie lesen kann. Ein Fallback kann genehmigte Geschäftsfakten behalten und dennoch eine andere dokumentierte Verlaufsdarstellung benötigen.
Ändern Sie Modell, Systemprompt, Tools und Komprimierung nicht gemeinsam in einem Experiment. Speichern Sie Promptvorlagen, Tooldefinitionen, repräsentative Toolantworten und Parser-Versionen. Unterscheiden Sie softwareverarbeitete von menschlich geprüften Ausgaben. Beginnen Sie mit Sandbox oder aufgezeichneten Toolantworten: Doppelte Nachrichten, Datensätze oder Abbuchungen sind keine akzeptablen Vergleichsnebenwirkungen.
Einen Replay-Satz aufbauen, der Regressionen erkennt
Nehmen Sie erfolgreiche Fable-5.1-Sitzungen und ungelöste Fehler auf. Ein Kandidat, der eine schwierige Aufgabe löst, aber häufige Abläufe stört, ist für Ihre Anwendung möglicherweise kein Upgrade. Definieren Sie das erwartete Ergebnis vor Sichtung der Kandidatenausgabe.
| Replay-Fall | Prüfung | Beispiel für ein Scheitern |
|---|---|---|
| Neue Anfrage | Erforderliche Anweisungen und Ausgabefelder eingehalten | Pflichtfeld fehlt oder Randbedingung ignoriert |
| Langer bestehender Verlauf | Wichtiger Zustand und Nutzerentscheidungen bleiben erhalten | Fortsetzung widerspricht einer zuvor akzeptierten Entscheidung |
| Tool-Aufruf und Tool-Ergebnis | Argumente, Reihenfolge und Endantwort korrekt | Tool wiederholt oder Ergebnis falsch interpretiert |
| Strukturierte Ausgabe | Schemavalidierung und Feldbedeutung korrekt | Gültiges JSON enthält falsche ID oder falschen Wert |
| Unterbrochene oder gescheiterte Anfrage | Retry und Fallback hinterlassen konsistenten Zustand | Externe Aktion doppelt ausgeführt oder Teilzustand aufgegeben |
| Erfolgreiche Routineaufgabe | Bestehende Qualität und Latenz erhalten | Häufiger bisheriger Erfolg scheitert oder läuft ins Timeout |
Verwenden Sie nur für die Kandidatenroute dokumentierte Funktionen. Markieren Sie eine nicht unterstützte oder ungeprüfte Funktion als Migrationshindernis für den davon abhängigen Workflow, statt den Fall stillschweigend aus den Ergebnissen zu entfernen.
Konkreter Replay-Fall für einen bestehenden Fable-5.1-Agenten
TEST-17 und die Nutzeranweisung, dieses Ticket zu aktualisieren statt ein weiteres anzulegen. Das ist ein illustratives Anwendungsszenario, kein Bericht über Modellverhalten.Spielen Sie es in drei Formen ab: als neue Anfrage mit dem erforderlichen Zustand, als ursprünglichen Gesprächsverlauf und als nach simuliertem Timeout fortgesetzte Sitzung. Halten Sie Tool-Antworten im ersten Durchlauf deterministisch. Führen Sie danach einen separaten Sandbox-Test mit realistischen Tool-Fehlern aus.
| Abnahmekriterium | Aufzubewahrender Beleg | Reaktion auf einen Fehler |
|---|---|---|
| Das richtige Ticket wird aktualisiert | Tool-Name, Argumente und resultierender Sandbox-Datensatz | Falsche ID oder unbeabsichtigtes Anlegen ablehnen |
| Vom Nutzer freigegebene Felder bleiben erhalten | Vorher-/Nachher-Diff des Datensatzes | Nicht autorisierte Feldänderung ablehnen |
| Ein Retry wiederholt keine bereits abgeschlossene Aktion | Aktions-ID der Anwendung und Tool-Ausführungsprotokoll | Fall stoppen und Retry-/Zustandsbehandlung prüfen |
| Die Endantwort entspricht dem Geschehen | Antwort mit aufgezeichnetem Tool-Ergebnis vergleichen | Behaupteten Erfolg nach fehlgeschlagenem Update ablehnen |
| Fallback kann sicher fortsetzen | Wiederhergestellter Zustand und Replay auf der beibehaltenen Route | Verkehr erst ausweiten, wenn Wiederherstellung funktioniert |
Speichern Sie je Versuch einen kompakten Datensatz: Fall-ID, Modellroute, Client- und Prompt-Versionen, Verlaufstransformation, Tool-Protokoll, Erfolgs-/Fehlergründe, Kosten und Review-Zeit. Lassen Sie nicht getestete Ergebnisse offen, statt sie als bestanden zu markieren. Bestehen neue Anfragen, historische Sitzungen aber nicht, untersuchen Sie zuerst die Verarbeitung des Verlaufs, bevor Sie überall Prompts ändern. Scheitern beide am selben erwarteten Zustand, prüfen Sie zunächst Anfrage- und Tool-Vertrag.
Dieser Test macht eine Upgrade-Behauptung widerlegbar: Eine flüssige Antwort kann weder ein doppeltes Ticket noch beschädigten Zustand verdecken. Übertragen Sie das Muster auf folgenreiche Aktionen Ihrer Anwendung.
{
"case_id": "ticket-update-17",
"before": {
"ticket_count": 1,
"ticket": {"id": "TEST-17", "owner": "Mina", "priority": "normal", "status": "open"}
},
"instruction": "Set TEST-17 priority to high. Keep its owner and status. Do not create another ticket.",
"expected_after": {
"ticket_count": 1,
"ticket": {"id": "TEST-17", "owner": "Mina", "priority": "high", "status": "open"}
},
"allowed_changed_fields": ["ticket.priority"],
"forbidden_operations": ["create_ticket", "close_ticket"]
}Die Anweisung erhöht die Priorität von TEST-17 auf high, behält Zuständigkeit und Status bei und verbietet ein neues Ticket. Für den Fall mit frischem Zustand liefern Sie Ticket und Anweisung. Für den Verlaufsfall behalten Sie Genehmigung, Erstellungsantwort und Änderungsanweisung. Für die Wiederherstellung führt die Sandbox die Änderung aus, verbirgt aber ihre Antwort: ein Timeout nach bestätigtem Schreiben. Die App muss den bestehenden Datensatz abgleichen, bevor sie die Operation wiederholt. Ein Idempotenzschlüssel hilft nur, wenn der dokumentierte Toolvertrag ihn tatsächlich berücksichtigt.
normal bleibt. Die korrekte Priorität reicht nicht, wenn sich die Zuständigkeit ändert. Ein zweites Ticket ist ebenfalls ein Fehler, auch wenn das erste korrekt aktualisiert wurde. Prüfen Sie Zustand und Ausführungslog: Ein zusätzlicher Schreibvorgang mit anschließender Korrektur kann hinter einem richtigen Endzustand verschwinden. Nach verlorener Toolantwort darf der Assistent eine ungeprüfte Änderung nicht als bestätigt darstellen.Speichern Sie Ausgangszustand, gesendeten Verlauf, Toolargumente, Endzustand und abschließende Antwort gemeinsam. Scheitern beide Modelle bei der Wiederherstellung nach erfolgtem Schreiben, reparieren Sie zunächst den Wiederherstellungsmechanismus der App. Diese wiederverwendbare Abnahme-Fixture ist schon heute auf Fable 5.1 anwendbar; die 5.5-Spalte bleibt bis zu einer verifizierten Route ungetestet.
Fehler bei der Fortsetzung von Verläufen diagnostizieren
Besteht eine neue Anfrage, ihr historisches Gegenstück aber nicht, vergleichen Sie die tatsächlich ans Modell übergebenen Nachrichten: Tool-Aufruf-/Ergebnispaare, erhaltene Nutzerentscheidungen und zuvor generierte Inhalte. Bewahren Sie den Originalverlauf auf und versionieren Sie jede Transformation, um die wirksame Änderung zu erkennen.
Nehmen Sie nicht an, dass Cache-Einträge, Gesprächsreferenzen oder anbieterspezifische Felder auf ein anderes Modell übertragbar sind. Prüfen Sie zuerst den dokumentierten Geltungsbereich. Benötigt ein Workflow eine Verlaufskonvertierung, testen Sie den umgewandelten Verlauf gegen denselben erwarteten Zustand und dokumentieren Sie entfernte oder zusammengefasste Informationen.
Berichten Sie bestandene, gescheiterte und ungetestete Fälle samt Gründen getrennt für neue und fortgesetzte Sitzungen. Erfolgreiche neue Sitzungen geben bestehende Gespräche nicht automatisch zur Migration frei.
Vom Replay zum reversiblen Rollout
EvoLink kann eine gemeinsame Gateway-Schnittstelle für die Modellauswahl bieten; modellspezifisches Verhalten bleibt prüfpflichtig. Halten Sie aktuelles Modell, Kandidat und Fallback ausdrücklich getrennt konfiguriert. Tragen Sie keine erratene Fable-5.5-ID als Kandidaten ein.
Aus Replay-Ergebnissen eine Freigabeentscheidung ableiten
Dokumentieren Sie vor dem Rollout die Entscheidung, einschließlich Stoppberechtigung und zu erhaltendem Zustand. Eine höhere durchschnittliche Erfolgsquote genügt nicht, wenn sie mit einem neuen kritischen Fehler einhergeht.
| Hypothetisches Replay-Ergebnis | Entscheidung | Nächster Schritt |
|---|---|---|
| Kandidat besteht mehr Aufgaben, führt aber eine externe Aktion doppelt aus | Nicht freigeben | Aktionsgrenze korrigieren oder isolieren; beide Konfigurationen erneut prüfen |
| Neue Anfragen bestehen, historische Sitzungen scheitern | Bestehende Gespräche nicht migrieren | Verlaufskonvertierung untersuchen; neue Sitzungen separat bewerten |
| Qualität stimmt, Latenz überschreitet das vorab definierte Limit | Nicht zum allgemeinen Standard machen | Prüfen, ob eine eindeutig erkennbare Warteschlange langsamer Aufgaben das toleriert |
| Nur eine Aufgabenklasse verbessert sich innerhalb ihres Budgets | Begrenzten aufgabenspezifischen Rollout erwägen | Klassifikationsfehler und Fallback dieser Klasse prüfen |
| Ergebnisse stimmen, aber die beibehaltene Route kann den Zustand nicht fortsetzen | Ausweitung stoppen | Nutzbaren Wiederherstellungspfad herstellen und testen |
Das sind Entscheidungsbeispiele, keine beobachteten Fable-5.5-Ergebnisse. Leiten Sie Zahlenlimits aus Anwendungsanforderungen ab, statt eine willkürliche Erfolgsquote zu übernehmen. Prüfen Sie für den geplanten Umfang genügend normalen und fehlerhaften Verkehr; eine kleine Stichprobe bleibt unsicher.
Benennen Sie für den Rollback vorige Route und Konfigurationsversion, pausieren Sie neue Kandidatenzuweisungen, identifizieren Sie laufende Aufgaben, gleichen Sie ausgeführte externe Aktionen ab und setzen Sie nur von einem bekannten Zustand aus fort. Protokollieren Sie Auslöser und Wiederherstellungsergebnis. Ein nur in der Konfiguration vorhandener Fallback hat Wiederherstellbarkeit noch nicht bewiesen.
Wann wäre das Upgrade sinnvoll?
Bringt der Kandidat keinen wesentlichen Nutzen, ist das Beibehalten von Fable 5.1 sinnvoll, solange seine Route verfügbar und geeignet bleibt. Verbessert sich nur ein Workflow, kann dessen gezielte Migration überzeugender sein als ein Wechsel aller Standards. Keine dieser Entscheidungen verlangt, eine unbestätigte Veröffentlichung als Frist zu behandeln.
FAQ
Kann ich die Fable-5.1-Modell-ID durch eine erratene Fable-5.5-ID ersetzen?
Nein. Exakter Kandidatenbezeichner und unterstützter Anfragevertrag müssen bestätigt sein. Ein Seiten-Slug ist keine nutzbare API-Modell-ID.
Ist Fable 5.5 rückwärtskompatibel mit Fable 5.1?
Die geprüften Quellen belegen keine Rückwärtskompatibilität. Prüfen Sie Anfragefelder, Antworten, Tools und zustandsabhängiges Verhalten für die konkret vorgesehene Route.
Kann ich bestehende Gesprächsverläufe weiterverwenden?
Bereiten Sie sie für Tests vor, setzen Sie Kompatibilität aber nicht voraus. Testen Sie neue Sitzungen und Verlaufsfortsetzung getrennt und prüfen Sie, ob wichtiger Zustand und Entscheidungen erhalten bleiben.
Lassen sich Prompt-Caches übertragen?
Nehmen Sie keine Cache-Übertragbarkeit an. Prüfen Sie Geltungsbereich und Abrechnung der Kandidatenroute und berücksichtigen Sie Cache-Kosten in der Evaluierung.
Sollte ich beim Modellwechsel auch Prompts ändern?
Beginnen Sie mit einer fixierten Referenz. Ist kandidatenspezifische Anpassung nötig, versionieren Sie sie separat und bewerten Sie sie auf Aufgaben, die nicht zur Optimierung verwendet wurden.
Ist ein Shadow-Test für Tool-Agenten sicher?
Nur wenn er keine unbeabsichtigten externen Aktionen wiederholt und für die übertragenen Daten geeignet ist. Verwenden Sie für frühes Replay aufgezeichnete Antworten oder eine Sandbox und berücksichtigen Sie doppelte Anfragekosten.
Genügt das Zurücksetzen der Modelleinstellung für einen Rollback?
Nicht immer. Prüfen Sie die Fallback-Route und behandeln Sie laufende Aufgaben, Gesprächszustand und externe Wirkungen. Ein Konfigurations-Rollback macht bereits ausgeführte Aktionen nicht rückgängig.
Sollte ich vor einer offiziellen Ankündigung migrieren?
Quellen und Geltungsbereich
- Anthropic-Modellübersicht: Prüfung von Modellidentität und Dokumentation.
- Anthropic-Nachrichten: Prüfung der Veröffentlichungsbelege.
- EvoLink Fable 5.1: Referenz für das bestehende Modell.
