Claude Fable 5.5 vs Fable 5.1 : quels tests avant de migrer ?
Que sait-on du parcours de migration ?
| Question de migration | Ce que vous pouvez faire maintenant | Ce qui doit attendre des preuves |
|---|---|---|
| Peut-on changer directement l’identifiant du modèle ? | Repérer la configuration de la route actuelle | Confirmer l’identifiant exact du candidat et le contrat de requête |
| Outils et sorties structurées se comporteront-ils pareil ? | Conserver schémas, jeux de test et contrôles d’acceptation | Réexécuter sur une route candidate vérifiée |
| Les conversations existantes continueront-elles correctement ? | Sauvegarder des historiques représentatifs nettoyés | Tester l’acceptation et la continuation des historiques |
| Cache et coûts seront-ils transférables ? | Relever usage actuel et frais réels | Vérifier règles et facturation du candidat ; ne pas présumer de portabilité du cache |
| Un remplacement complet est-il nécessaire ? | Identifier les charges qui ont réellement besoin d’un progrès | Comparer les résultats et décider s’il faut migrer |
La suite propose une procédure de migration. Elle n’implique ni prise en charge d’une fonction précise par Fable 5.5 ni sortie programmée.
Partez des contraintes réelles de l'intégration Fable 5.1
tool_choice any et tool. Il décrit aussi les restrictions sur les blocs de thinking lors d'un retour vers un modèle antérieur ou d'une modification du début de conversation. Ce sont des règles existantes de 5.1, pas des changements 5.5 nouvellement découverts ; vérifiez séparément leur application à la route de passerelle précise.| Dépendance existante | À conserver dans l'application actuelle | Question pour la future migration |
|---|---|---|
| Sélection d'outil | Schémas, action métier requise et vérification effective par l'application | Le candidat prend-il en charge le contrôle choisi et exécute-t-il l'action sans sélection forcée non prise en charge ? |
| Historique avec thinking | Messages dans l'ordre original, blocs opaques tels que reçus et version de transformation | Quels blocs restent valides sur le candidat et le modèle de repli ? |
| Compression côté client | Historiques avant/après, tours résumés et blocs ultérieurs conservés | L'historique transformé est-il accepté tout en préservant les décisions de l'utilisateur ? |
| Streaming et parsing | Événements bruts, assemblage des appels d'outils, branches de fin/erreur et version du parseur | Le parseur reconstruit-il la sortie et distingue-t-il fin et interruption ? |
| Usage et cache | Catégories sans double compte, dépenses réelles, exécutions à froid et à chaud | Le candidat préserve-t-il le cache attendu et quel est le nouveau coût de session ? |
La distinction diagnostique est importante : si une requête 5.1 est déjà rejetée après réécriture de tours antérieurs par votre application, c'est un problème de l'intégration actuelle. Il ne faut pas l'attribuer à un successeur non testé. Exécutez d'abord chaque jeu d'essai sur la route actuelle et documentez ses échecs avant d'ajouter le candidat.
L'état métier et l'état de raisonnement du modèle nécessitent aussi des restaurations distinctes. L'ID du ticket et son responsable approuvé appartiennent à l'état durable de l'application. Les blocs de thinking sont des éléments d'historique propres au modèle ; les conserver ne garantit pas qu'un autre modèle les lise. Le repli peut garder les faits métier approuvés tout en nécessitant une autre représentation documentée de l'historique.
Ne changez pas modèle, prompt système, outils et compression dans la même expérience. Conservez modèles de prompts, définitions et réponses représentatives d'outils, ainsi que versions des parseurs. Distinguez les sorties consommées par logiciel de celles relues par une personne. Commencez en sandbox ou avec des réponses enregistrées : doubler messages, créations d'enregistrements ou débits n'est pas un effet acceptable du test.
Construire un jeu de réexécution capable de détecter les régressions
Incluez les sessions Fable 5.1 réussies autant que les échecs non résolus. Un candidat qui répare une tâche difficile mais perturbe les workflows courants n’est pas forcément une amélioration pour votre application. Définissez le résultat attendu avant de regarder sa sortie.
| Cas de réexécution | Contrôle | Exemple d’échec |
|---|---|---|
| Nouvelle requête | Respect des instructions et champs requis | Champ obligatoire disparu ou contrainte ignorée |
| Historique long existant | Conservation des états importants et décisions utilisateur | Suite qui contredit une décision déjà acceptée |
| Appel et résultat d’outil | Arguments, séquence et réponse finale valides | Outil répété ou résultat mal interprété |
| Sortie structurée | Schéma et sens des champs validés | JSON valide avec mauvais identifiant ou valeur |
| Requête interrompue ou échouée | Reprises et repli laissent un état cohérent | Effet externe dupliqué ou état partiel abandonné |
| Tâche courante réussie | Qualité et latence actuelles préservées | Une réussite habituelle devient un échec ou expire |
N’utilisez que les fonctions documentées pour la route candidate. Marquez une fonction non prise en charge ou non vérifiée comme bloquante pour le workflow qui en dépend, au lieu de retirer silencieusement ce cas des résultats.
Exemple complet pour un agent Fable 5.1 existant
TEST-17 et la demande de modifier ce ticket au lieu d’en créer un autre. C’est un scénario illustratif, pas une observation du modèle.Réexécutez-le sous trois formes : nouvelle requête contenant l’état requis, historique original et session reprise après un timeout simulé. Gardez des réponses d’outils déterministes au premier passage. Effectuez ensuite un test distinct en sandbox avec des erreurs d’outils réalistes.
| Critère d’acceptation | Preuve à conserver | Réaction en cas d’échec |
|---|---|---|
| Le bon ticket est mis à jour | Nom de l’outil, arguments et enregistrement final en sandbox | Refuser un mauvais ID ou une création involontaire |
| Les champs approuvés restent intacts | Diff avant/après de l’enregistrement | Refuser une modification non autorisée |
| Une reprise ne répète pas une action déjà exécutée et enregistrée | Identifiant d’action de l’application et journal d’exécution | Arrêter le cas et examiner reprises et gestion d’état |
| La réponse finale reflète les faits | Comparaison avec le résultat d’outil enregistré | Refuser un succès annoncé après une mise à jour échouée |
| Le repli reprend sans risque | État récupéré et réexécution sur la route conservée | Ne pas étendre le trafic avant récupération fonctionnelle |
Conservez une fiche compacte par tentative : ID du cas, route, versions client et prompt, transformation de l’historique, journal d’outils, raisons de réussite ou d’échec, frais et temps de revue. Laissez vide un résultat non testé au lieu de le déclarer réussi. Si les nouvelles requêtes passent mais pas les anciennes sessions, examinez d’abord le traitement de l’historique avant de changer tous les prompts. Si les deux échouent sur le même état attendu, vérifiez d’abord les contrats de requête et d’outil.
Ce cas rend une promesse d’amélioration réfutable : une réponse fluide ne masque ni un ticket dupliqué ni un état corrompu. Appliquez ce principe aux actions importantes de votre propre application.
{
"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"]
}L'instruction passe la priorité de TEST-17 à high, conserve responsable et statut, et interdit un autre ticket. Pour l'état neuf, fournissez ticket actuel et instruction. Pour l'historique, gardez approbation, réponse de création et instruction de mise à jour. Pour la reprise, laissez la sandbox appliquer la modification, puis masquez sa réponse : cela simule un timeout après une écriture validée. L'application doit réconcilier l'enregistrement existant avant de répéter l'opération ; une clé d'idempotence n'aide que si le contrat documenté de l'outil la respecte réellement.
normal ; la bonne priorité échoue si le responsable change ; un second ticket échoue même si le premier a été correctement modifié. Examinez l'état et le journal d'exécution : une écriture superflue suivie d'une correction peut se cacher derrière un instantané final correct. Si la réponse d'outil est perdue, l'assistant ne doit pas annoncer comme confirmée une modification non vérifiée.Conservez ensemble état initial, historique envoyé, arguments d'outils, état final et réponse. Si les deux modèles échouent à reprendre après l'écriture, corrigez d'abord la restauration de l'application avant de conclure sur la qualité du modèle. Ce jeu d'acceptation est réutilisable aujourd'hui sur Fable 5.1 ; la colonne 5.5 reste non testée jusqu'à l'existence d'une route vérifiée.
Diagnostiquer les échecs de reprise d’historique
Si une nouvelle requête réussit et que son équivalent historique échoue, comparez les messages réellement livrés au modèle : paires d’appels et résultats d’outils, décisions utilisateur conservées et contenus précédemment générés. Gardez l’historique original et versionnez chaque transformation pour identifier ce qui change le résultat.
Ne supposez pas qu’une entrée de cache, une référence de conversation ou un champ propre à un fournisseur se transfère entre modèles. Vérifiez d’abord son périmètre documenté. Si une conversion est nécessaire, testez l’historique converti contre le même état attendu et consignez les informations supprimées ou résumées.
Publiez séparément les nombres de cas réussis, échoués et non testés pour sessions nouvelles et continuées, avec leurs raisons. La réussite du premier groupe n’autorise pas la migration des conversations existantes.
Passer de la réexécution à un déploiement réversible
EvoLink peut offrir une interface de passerelle commune pour choisir les modèles ; les comportements propres à chacun restent à valider. Rendez explicites les configurations actuelle, candidate et de repli. Ne renseignez pas le candidat avec un identifiant Fable 5.5 deviné.
Transformer les résultats en décision de déploiement
Rédigez la décision avant le déploiement, en précisant qui peut l’arrêter et quel état préserver. Un meilleur taux moyen ne suffit pas s’il s’accompagne d’un nouvel échec critique.
| Résultat hypothétique de réexécution | Décision | Action suivante |
|---|---|---|
| Plus de tâches réussies, mais une action externe dupliquée | Ne pas promouvoir | Corriger ou isoler la frontière d’action, puis retester les deux configurations |
| Nouvelles requêtes réussies ; anciennes sessions échouées | Ne pas migrer les conversations existantes | Diagnostiquer la conversion ; évaluer séparément les nouvelles sessions |
| Qualité validée, mais latence au-delà du seuil fixé | Ne pas en faire le modèle universel par défaut | Tester une file clairement identifiée de tâches tolérant ce délai |
| Une seule classe de tâches progresse dans son budget | Envisager un déploiement limité à cette classe | Valider les erreurs de classification et son repli |
| Résultats validés, mais route conservée incapable de reprendre l’état | Suspendre l’extension | Rétablir puis tester un chemin de récupération viable |
Ce sont des exemples de décision, pas des résultats observés de Fable 5.5. Fixez les seuils numériques selon votre application plutôt que de copier un pourcentage arbitraire. Examinez suffisamment de trafic normal et en échec pour le périmètre prévu ; un petit échantillon reste incertain.
Pour revenir en arrière, nommez route précédente et version de configuration, suspendez les nouvelles affectations au candidat, identifiez les tâches en cours, rapprochez les effets externes déjà réalisés et ne reprenez que depuis un état connu. Consignez déclencheur et résultat de récupération. Un repli présent uniquement dans la configuration n’a pas démontré sa capacité de récupération.
Qu’est-ce qui justifierait la migration ?
Si le candidat n’apporte aucun bénéfice significatif, garder Fable 5.1 est une décision valable tant que sa route reste disponible et adaptée. Si un seul workflow progresse, ne migrer que celui-ci peut être plus défendable que changer tous les modèles par défaut. Aucun choix n’impose de traiter une sortie non vérifiée comme une échéance.
FAQ
Puis-je remplacer l’identifiant Fable 5.1 par un identifiant Fable 5.5 deviné ?
Non. L’identifiant exact et le contrat de requête doivent être confirmés. Le slug d’une page n’est pas un identifiant de modèle API utilisable.
Fable 5.5 est-il rétrocompatible avec Fable 5.1 ?
Les sources consultées n’établissent aucune rétrocompatibilité. Vérifiez champs de requête, réponses, outils et comportement avec état pour la route exacte prévue.
Peut-on réutiliser les conversations existantes ?
Préparez-les pour les tests, sans présumer de compatibilité. Testez séparément nouvelles sessions et reprise d’historique, en vérifiant la conservation des états et décisions importants.
Les caches de prompts seront-ils transférés ?
Ne présumez pas de leur portabilité. Vérifiez périmètre et règles de facturation de la route candidate et intégrez les frais liés au cache à l’évaluation.
Faut-il changer les prompts en même temps que le modèle ?
Commencez par une référence figée. Si un ajustement propre au candidat est nécessaire, versionnez-le séparément et évaluez-le sur des tâches non utilisées pour le réglage.
Un test miroir est-il sûr pour les agents utilisant des outils ?
Seulement s’il ne peut pas répéter involontairement des actions externes et convient aux données envoyées. Utilisez des réponses enregistrées ou une sandbox pour les premiers essais et comptez le coût des requêtes dupliquées.
Revenir au réglage précédent suffit-il pour un retour arrière ?
Pas toujours. Vérifiez la route de repli et traitez tâches en cours, état des conversations et effets externes. Revenir sur une configuration n’annule pas une action déjà exécutée.
Faut-il migrer avant une annonce officielle ?
Sources et périmètre
- Présentation des modèles Anthropic : vérification de l’identité et de la documentation.
- Actualités Anthropic : recherche de preuves de sortie.
- EvoLink Fable 5.1 : référence du modèle actuel.
