Claude Fable 5 et Mythos 5 : liste de contrôle d'évaluation d'entreprise pour les opérateurs d'IA

Pourquoi il s'agit d'un problème d'évaluation, pas d'un échange de modèle

Claude Fable 5 et Claude Mythos 5 devraient faire réfléchir les équipes d'IA d'entreprise avant de modifier un seul ID de modèle de production. La question utile n’est pas de savoir si un modèle plus récent semble plus solide sur le papier. Il s'agit de savoir si un flux de travail spécifique s'améliore après la migration, avec moins de mauvaises réponses, moins de réparations manuelles, une latence acceptable, une gestion claire des refus et un profil de coûts que l'entreprise peut défendre.

La documentation d'Anthropic donne aux opérateurs plusieurs faits concrets avec lesquels travailler. Les ID de modèle d'API sont claude-fable-5 et claude-mythos-5. La fenêtre contextuelle documentée contient 1 million de jetons par défaut, avec jusqu'à 128 000 jetons de sortie. Les prix publiés indiquent 10 $ par million de jetons d'entrée et 50 $ par million de jetons de sortie. Ces chiffres sont importants, mais ils ne constituent pas en eux-mêmes une analyse de rentabilisation. Un modèle qui coûte plus cher par jeton peut toujours être le bon choix pour un flux de travail difficile s'il améliore la qualité de sortie acceptée ou réduit les tentatives après la mesure. L’inverse est également vrai. Un modèle plus solide peut s’avérer inutile lorsqu’il s’agit d’une extraction de base ou d’une réécriture de routine.

Mon point de vue : de nombreuses équipes migrent excessivement. Ils voient le lancement d’un nouveau modèle et le traitent comme une mise à niveau de dépendance. Ce n’est pas le bon modèle mental pour l’IA d’entreprise. Un modèle fait partie d'un système de production avec des invites, une récupération, des outils, des journaux, des itinéraires de secours, une révision humaine et les attentes des utilisateurs. Changez de modèle et tout le système peut bouger.

Fable 5 vs Mythos 5 : la différence entre les opérateurs

Fable 5 est le candidat que de nombreuses équipes évalueront pour une utilisation en production. Basé sur la documentation d'Anthropic, il est positionné pour des travaux exigeants de raisonnement, de codage, d'analyse, de travail dans un contexte à long terme et d'agents à long terme. Cela ne signifie pas que toutes les charges de travail de l’entreprise doivent y être transférées. Cela signifie que l’ensemble d’évaluation devrait inclure les travaux qui mettent actuellement à rude épreuve le modèle existant.

Mythe 5 a besoin d’une lecture plus froide. Anthropic le décrit comme partageant les capacités de Fable 5, mais sans classificateurs de sécurité et avec une disponibilité via le projet Glasswing. Cette distinction n’est pas cosmétique. Les classificateurs de sécurité affectent ce que le modèle refuse, la manière dont l'application doit répondre et les contrôles de gouvernance qui doivent entourer le flux de travail. Un modèle sans ces classificateurs appartient par défaut à une piste d’évaluation plus étroite, et non au trafic d’entreprise ordinaire.

Le problème de l’expérience utilisateur est facile à ignorer. Un refus peut arriver comme une réponse API réussie, et non comme une erreur d'application. Si le produit traite chaque HTTP 200 comme un contenu utilisable, un refus peut atterrir dans l'interface comme une réponse déroutante. L'application doit inspecter stop_reason: refus, décider de ce qui s'est passé et acheminer l'étape suivante avec intention.

Le cadre d'évaluation FABLE

Pour Fable 5, utilisez un plan d'évaluation au niveau des tâches. L'acronyme est utile car il maintient l'honnêteté de l'équipe : Fit, Accuracy, Behaviour, Latency, Economics.L'ajustement passe avant tout. Cartographiez le travail des candidats dans de véritables familles de tâches avant les tests. Le raisonnement documentaire, l’assistance au codage, la recherche agentique, le support client, la vérification de la conformité, la récupération des connaissances internes et la génération créative ne doivent pas partager une seule carte de score. Un modèle peut améliorer l'analyse du référentiel tout en restant inutile pour les macros de support courtes.

La précision vient ensuite, et elle doit être jugée par rapport à des exemples reconnus par l'entreprise. Créez des ensembles de données précieux avec des invites de type production, des réponses connues, des cas d'échec clairs, des demandes sensibles, des exemples d'utilisation d'outils, des échantillons de contexte long, des invites contradictoires et des exemples multilingues là où ils sont importants. Les références génériques peuvent aider avec le contexte, mais elles ne peuvent pas dire à une équipe juridique si un résumé de contrat est suffisamment sûr pour être utilisé.

Le comportement est le point où de nombreuses migrations échouent. Mesurez le taux de refus, la pertinence des refus, la sensibilité des invites, la cohérence des appels d'outils, la dégradation du contexte long et la fiabilité du format de réponse. Si un flux de travail dépend de JSON, n'acceptez pas une bonne prose comme passe-partout. Si un flux de travail appelle des outils, évaluez si le modèle a choisi le bon outil, a transmis des arguments valides, a géré les données manquantes et s'est arrêté au bon moment.

La latence nécessite un trafic réaliste. Testez séparément les invites courtes, les invites longues, les flux de travail améliorés par des outils et les tâches par lots à volume élevé. Incluez la simultanéité, les paramètres de délai d'attente, la taille du contexte, le comportement du cache, les tentatives de secours et les chemins les plus lents que les utilisateurs emprunteront réellement. La latence moyenne n'est pas suffisante. Regardez p95 et p99, car ce sont les chiffres qui façonnent souvent les tickets d’assistance.

L’économie doit être mesurée par résultat accepté, et non par appel de modèle. Incluez les jetons d'entrée, les jetons de sortie, le taux de réussite du cache, les demandes refusées, les tentatives de secours, le temps de révision humaine, la journalisation, les exécutions d'évaluation et le support opérationnel. La question utile n’est pas de savoir si Fable 5 est moins cher. Il s'agit de savoir si, pour ce flux de travail, Fable 5 produit suffisamment de résultats acceptés à un coût total acceptable.

Liste de contrôle de migration avant de remplacer un modèle Claude existant

Commencez avec un ensemble d’évaluation représentatif. Il doit contenir des requêtes normales, des cas difficiles connus, des exemples ayant échoué précédemment, des invites sensibles aux règles, des documents longs, des appels d'outils, des exigences de sortie structurées et des exemples tirés des langues utilisées par vos utilisateurs. Gardez l’ensemble suffisamment petit pour un examen attentif au début. Un test bâclé de mille exemples est moins utile que deux cents exemples avec de bonnes étiquettes.

Exécutez des comparaisons côte à côte avec le modèle de production actuel, y compris Claude Opus 4.8 s'il est déjà dans la pile. Ne demandez pas aux évaluateurs quelle réponse ils aiment. Demandez la réussite de la tâche, la gravité des erreurs factuelles, les exigences manquantes, la conformité du format, l'exactitude des appels d'outils, la nécessité d'une escalade et la confiance des réviseurs. L'examen aveugle est utile lorsque l'équipe a un biais de lancement.

Testez les refus en tant qu’état du produit. Pour chaque demande refusée, indiquez si le refus était approprié, trop large, trop restreint ou peu clair. Décidez ensuite de ce que l'utilisateur doit voir. Certains cas nécessitent une question de clarification. Certains devraient recourir à un flux de travail plus sûr ou plus restreint. Certains devraient être transmis à une personne. Certaines devraient simplement être refusées dans un langage simple.Validez le comportement dans un contexte long avec des entrées en forme de production. La fenêtre contextuelle du jeton 1M est utile, mais elle peut masquer une mauvaise architecture d'informations. Le transfert d'une bibliothèque ou d'un référentiel de politiques complet dans une invite peut fonctionner dans une démonstration et échouer en raison du coût, de la latence ou de la pression de la pertinence. Comparez les invites en contexte complet avec la récupération, les résumés, le regroupement de fichiers et le contexte mis en cache.

Testez les agents, les outils et les sorties structurées séparément du chat normal. Un modèle peut écrire un excellent plan tout en appelant le mauvais point de terminaison. Il peut produire du JSON valide dans des tâches courtes et dériver lorsque le contexte devient volumineux. Incluez la validation du schéma, les vérifications des arguments des outils, le comportement des nouvelles tentatives et l'achèvement des tâches de bout en bout.

Définissez les déclencheurs de restauration avant le lancement. Les bons déclencheurs incluent un comportement de refus inacceptable, une dérive des coûts, une régression de la latence, une rupture de schéma, une confiance moindre des évaluateurs, des taux de remontée d'informations plus élevés ou des corrections manuelles plus fréquentes. Un déploiement par étapes sans critères de restauration n'est qu'un lancement lent.

Routage de sécurité sans rompre l'expérience utilisateur

Considérez le refus comme un résultat normal. Un itinéraire pratique est simple : classez la demande, appelez Fable 5, inspectez stop_reason et toutes les informations du classificateur signalées, puis choisissez l'action suivante. L’action suivante pourrait être une clarification, une solution de repli, une escalade ou un déclin évident. L'essentiel est que c'est l'application qui décide, et non la réponse brute du modèle.

La conception de secours doit dépendre du risque lié à la tâche. Les tâches de productivité à faible risque peuvent souvent être réessayées avec une invite plus étroite ou revenir au modèle actuel. Les flux de travail réglementés nécessitent des journaux, des étiquettes de stratégie et une escalade humaine plus stricts. L'assistance destinée au client doit être soigneusement copiée afin que l'utilisateur ne soit pas exposé au langage de sécurité interne. Les agents de codage ont besoin de garde-fous concernant l’accès aux fichiers, l’exécution des commandes et la divulgation des secrets. L'équipe rouge et l'évaluation de sécurité peuvent justifier des itinéraires différents, mais uniquement avec une portée et un examen écrits.

La documentation d'Anthropic traite des options de secours, y compris les modèles au niveau de l'API et côté client. Les équipes devraient quand même tester toute la chaîne. Une solution de secours qui améliore le taux d’achèvement peut également augmenter la latence, les coûts ou l’exposition aux politiques. Les détails de facturation sont également importants : la documentation d'Anthropic indique que les demandes refusées avant qu'un résultat ne soit généré ne sont pas facturées, tandis que le comportement de repli doit encore être mesuré.

Le mythe 5 ne devrait entrer dans cette discussion qu’avec discipline. Une équipe peut avoir une raison valable d'évaluer un modèle sans classificateurs de sécurité, en particulier pour la recherche spécialisée dans le cadre du projet Glasswing. Ce n’est pas la même chose que d’y envoyer du trafic normal d’employés ou de clients. Avant d'utiliser Mythos 5, documentez les conditions d'accès, les cas d'utilisation approuvés, la surveillance, le traitement des données, les propriétaires d'examen, le processus d'incident et la raison pour laquelle Fable 5 n'est pas suffisant.

L'ensemble de contrôles doit être ennuyeux et explicite : journaux d'audit, suivi des versions d'invite et de modèle, étiquettes de politique, réexécution d'évaluation, chemins d'escalade humaine, taux de refus dans un tableau de bord et examen des incidents. Des contrôles ennuyeux sont ce qui empêche les expériences sur modèles de devenir des surprises en matière de production.

Tests de coûts : mesurez le flux de travail

Le prix du jeton n’est que le point de départ. Aux tarifs publiés dans la documentation tarifaire d'Anthropic, Fable 5 et Mythos 5 sont répertoriés à 10 $ par million de jetons d'entrée et 50 $ par million de jetons de sortie. Vérifiez les prix avant l'achat ou le lancement, car les prix des fournisseurs peuvent changer.Le coût caché est souvent lié au contexte. Une fenêtre de jetons de 1 million incite les équipes à tout inclure. Cela peut être raisonnable pour certaines tâches juridiques, d'ingénierie ou de recherche, mais cela coûte cher si le système compense une faible récupération. Testez les invites plus courtes, les invites de récupération en premier, le contexte mis en cache, les limites de sortie et les règles de secours.

Une formule de coût simple fonctionne bien : coût total du jeton d'entrée plus coût du jeton de sortie plus coût de nouvelle tentative plus coût de repli plus temps de révision plus surcharge d'orchestration, divisé par les sorties acceptées. Les refus doivent être suivis séparément afin que l'équipe puisse voir si le comportement en matière de sécurité permet de réduire les coûts, d'augmenter les frictions ou de révéler les lacunes du produit.

Le tableau doit être rempli de données mesurées et non d’optimisme du jour du lancement. Si Fable 5 réduit le temps d'examen ou améliore le taux de sortie accepté dans une évaluation mesurée, le prix symbolique plus élevé peut être justifié. Si cela ne fait que rendre les tâches faciles plus coûteuses, laissez ces tâches là où elles se trouvent.

Où ne pas encore migrer

Ne déplacez pas de tâches volumineuses et peu complexes à moins que les preuves soient solides. Une classification simple, des résumés basés sur des modèles, une extraction de base et une réécriture de routine n'ont souvent pas besoin du modèle le plus puissant de la pile. Un modèle moins cher avec de bonnes invites peut être la bonne réponse.

Évitez la migration lorsque l’équipe manque de données d’évaluation. Aucun ensemble d'or, aucune rubrique, aucune version rapide, aucun journal et aucun chemin de restauration signifient que l'équipe ne peut pas dire si la migration a amélioré quelque chose. Ce n’est pas une décision technique. C'est une supposition avec factures jointes.

Les systèmes qui ne peuvent pas gérer stop_reason: refus ne doivent pas envoyer de trafic critique vers Fable 5. Le produit doit savoir ce que signifie un refus, comment l'envoyer et quand l'acheminer ailleurs. Cela est particulièrement vrai pour les flux orientés client et régulés.

Les workflows à contexte long avec une récupération compliquée méritent un scepticisme supplémentaire. Si le système actuel comporte des documents en double, des politiques obsolètes, des métadonnées faibles ou aucun classement des sources, une fenêtre contextuelle plus grande peut simplement rendre le problème plus coûteux. Corrigez la qualité des informations avant de célébrer la taille du contexte.

Pour le mythe 5, la réponse par défaut devrait être non jusqu'à ce que les arguments en matière de gouvernance soient clairs. La disponibilité via le projet Glasswing et l’absence de classificateurs de sécurité ne sont pas des détails à écarter. Ils définissent le profil de risque.

Un plan d'évaluation sur 30 jours

Au cours de la semaine 1, inventoriez les charges de travail des candidats. Pour chacun, enregistrez le modèle actuel, l'impact sur l'utilisateur, la sensibilité des données, le volume des demandes, les critères de réussite, la gravité de l'échec et le propriétaire. Étiquetez le risque avant le début des tests.

Au cours de la semaine 2, créez l’ensemble d’évaluation et le prototype de routage. Créez des invites, configurez Claude-fable-5, ajoutez une détection de refus, préparez des itinéraires de secours et définissez des rubriques de réviseur. Gardez Mythos 5 hors de la route normale, à moins qu'il n'existe un cas d'utilisation documenté du projet Glasswing.

Au cours de la semaine 3, exécutez les tests. Comparez les sorties côte à côte, simulez la charge, testez des scénarios à contexte long, mesurez le coût par sortie acceptée et examinez les cas d'échec avec des experts du domaine. Séparez les types de tâches dans les résultats afin qu’un flux de travail puissant n’en cache pas un autre faible.Au cours de la semaine 4, décidez. La réponse peut être migrer, différer, acheminer partiellement ou continuer les tests. Portée du déploiement du document, tableaux de bord, propriétaire, déclencheurs de restauration et impact sur l'approvisionnement. Optijara peut aider les équipes à concevoir des systèmes d'évaluation de modèles, des itinéraires de sécurité, des tests de coûts et des plans de migration par étapes, mais le principe est le même pour toute équipe d'IA mature : déplacer la charge de travail uniquement lorsque les preuves indiquent que le système s'améliore.