Amazon Nova 2 Lite vs Claude Fable 5.1 pour extraire des données de documents : comment concevoir une comparaison reproductible

Quelle décision cette comparaison résout-elle, et ce qu’elle ne permet pas de conclure

La question pertinente n’est pas de savoir quel modèle est « meilleur » dans l’absolu, mais lequel convient à un flux précis d’extraction documentaire. Le cas d’usage considéré consiste à transformer des factures, des contrats courts, des formulaires et des documents PDF contenant des tableaux en données conformes à un schéma défini. Dans ces flux, une réponse qui semble correcte ne suffit pas : elle doit préserver les valeurs pertinentes, respecter les types imposés, distinguer une absence d’une valeur réelle et laisser une traçabilité suffisante pour corriger les erreurs.

Les informations fournies décrivent Amazon Nova 2 Lite et Claude Fable 5.1 selon leurs fournisseurs, mais elles ne contiennent pas les résultats d’une évaluation commune exécutée sur les deux. Il n’est donc pas possible d’affirmer, à partir de ces sources, que l’un atteint une meilleure exactitude, une latence plus faible ou un coût effectif inférieur à l’autre pour un portefeuille documentaire donné. Il ne serait pas non plus rigoureux d’extrapoler des comparaisons d’Amazon avec d’autres modèles à l’affrontement envisagé ici.

La conclusion opérationnelle, avant d’effectuer un essai, est conditionnelle. Nova 2 Lite peut être évalué comme modèle multimodal de la famille Nova 2 via Amazon Bedrock. Claude Fable 5.1 peut être évalué selon la voie d’accès et les conditions de disponibilité documentées par Anthropic. La sélection ne sera défendable qu’après avoir fixé une voie d’accès, un corpus gelé, une définition de la correction, une politique de tentatives supplémentaires et une méthode homogène d’imputation des coûts auxiliaires.

Une comparaison utile doit séparer trois niveaux. Le premier est la capacité déclarée par chaque fournisseur : modalités prises en charge, API, traitement des documents et contrôles disponibles. Le deuxième est le résultat mesuré sur un ensemble documentaire concret. Le troisième est le risque d’exploitation : données incomplètes, OCR défaillant, documents non équivalents, changements de version, quotas, politiques de rétention et contrôle humain. Confondre ces niveaux produit souvent une décision apparemment quantitative, mais difficile à auditer.

Modèles, voies d’accès et asymétries à fixer

Amazon documente Nova 2 Lite dans Amazon Bedrock, y compris les identifiants de modèle, les options d’inférence et les possibilités d’utilisation régionale ou globale. La documentation de Nova décrit aussi des capacités liées à la compréhension de documents, des PDF, des tableaux et des mises en page. Ces capacités doivent être vérifiées dans la modalité exacte souscrite, car un essai textuel n’équivaut pas à un essai qui transmet des images ou des documents au modèle.

Anthropic identifie Claude Fable 5.1 dans sa documentation et sur sa page produit, où l’entreprise communique également sa disponibilité, ses prix et des capacités liées aux PDF et aux tableaux. Avant toute comparaison, l’équipe doit consigner l’identifiant exact utilisé, la date, la région ou le lieu de traitement lorsqu’il s’applique, la version de l’API, les limites configurées, le budget de sortie ainsi que tout réglage de raisonnement ou de cache. Sans cette trace, un résultat ultérieur pourrait ne pas être reproductible.

Il existe une asymétrie méthodologique potentielle concernant la sortie structurée. La documentation d’Anthropic sur les sorties structurées décrit un mécanisme fondé sur JSON Schema et avertit que la compatibilité dépend de la plateforme et du modèle. D’après les informations fournies, Fable 5.1 ne figure pas parmi les modèles Bedrock compatibles avec les sorties structurées. Cela ne démontre pas que Fable 5.1 ne puisse pas produire de JSON valide par d’autres voies ; cela impose en revanche de documenter le mécanisme employé de chaque côté et de ne pas présenter deux intégrations distinctes comme si elles étaient identiques.

Deux options sont acceptables, mais elles ont des implications différentes. La première consiste à employer l’interface native de chaque fournisseur et à mesurer le système réellement déployable, en déclarant les différences de plateforme. La seconde impose un dénominateur commun : une instruction exigeant du JSON, une validation externe par rapport au même schéma et un nombre identique de tentatives supplémentaires. La seconde réduit les avantages d’intégration spécifiques ; la première reflète mieux l’expérience opérationnelle. Elles ne doivent pas être mélangées sans les étiqueter comme des expériences distinctes.

Conception reproductible pour l’extraction structurée

Le corpus doit être gelé avant l’observation des résultats et représenter le travail à automatiser. Une répartition pratique inclut du texte numérique propre, des tableaux simples, des tableaux sur plusieurs pages, des numérisations, des formulaires, des documents comportant des champs ambigus et des documents incomplets. Il faut conserver le fichier d’origine, un identifiant non sensible, le type documentaire, la langue, le canal d’entrée et les incidents connus. Si des données réelles sont utilisées, l’ensemble d’évaluation doit respecter les politiques internes et contractuelles applicables.

Chaque document nécessite une vérité de référence indépendante du modèle. Pour les champs critiques, deux réviseurs devraient annoter la valeur attendue, l’absence légitime, l’ambiguïté et l’élément visuel ou textuel qui l’étaye. En cas de désaccord, une troisième révision ou une règle d’arbitrage doit résoudre le cas. La proportion de documents relus deux fois et les désaccords non résolus doivent être publiés comme une partie de l’incertitude, et non dissimulés dans un unique indicateur d’exactitude.

Le schéma doit représenter à la fois la donnée et son état. Par exemple, une date peut être valide, absente, illisible, ambiguë ou hors périmètre. Forcer systématiquement une chaîne de caractères peut transformer une omission en invention. Il est utile d’exiger des champs de preuve, un niveau de confiance exprimé selon des règles propres et une liste d’incidents ; toutefois, une confiance déclarée par le modèle ne prouve pas qu’elle est bien calibrée. Elle se mesure en comparant ce signal aux erreurs observées.

L’instruction doit être identique quant à l’objectif sémantique : extraire uniquement ce qui est visible ou explicitement inférable suivant une règle documentée, renvoyer une absence lorsque les preuves manquent et ne pas compléter des valeurs plausibles. Si l’interface d’un fournisseur ajoute des instructions système ou des éléments de format obligatoires, ils doivent être conservés, archivés et comptabilisés dans la configuration. Il faut également enregistrer toute conversion préalable de PDF, tout OCR, toute réduction d’images ou toute division en pages.

Les exécutions répétées sont nécessaires même lorsque la configuration semble déterministe. Au minimum, chaque combinaison de modèle, de type documentaire et de configuration doit être exécutée trois fois. Les résultats doivent rendre compte de la dispersion et, lorsque la taille de l’échantillon le permet, d’intervalles d’incertitude. Un écart isolé de quelques champs ne doit pas devenir une recommandation d’achat s’il relève de la variation observée ou s’il provient d’un faible nombre de documents.

Les métriques importantes : format, sens, délai et coût

Le taux de JSON valide mesure combien de réponses peuvent être analysées sans réparation qui modifierait leur contenu. C’est nécessaire, mais insuffisant. Un JSON parfaitement valide peut contenir un mauvais fournisseur, un montant inventé ou une date décalée. Il faut donc le combiner avec l’exactitude par champ et l’exactitude par document. Cette dernière peut être définie strictement : un document ne compte comme correct que si tous les champs critiques correspondent à la référence et qu’aucune valeur non étayée n’apparaît.

Les omissions et les hallucinations doivent être comptées séparément. Une omission est un champ qui devait être extrait mais qui manque ou est incorrectement marqué comme absent. Une hallucination est une valeur présentée comme extraite sans preuve dans le document, ou contraire à la référence. Dans les contrats, la facturation ou la conformité, les hallucinations peuvent avoir un coût opérationnel supérieur à celui d’une omission, car une révision détecte souvent plus facilement une case vide qu’une donnée plausible mais erronée. La pondération doit refléter le risque du processus, et non une préférence générique.

La signalisation de l’incertitude doit être évaluée comme une classification. Si le modèle signale un doute dans les cas réellement ambigus ou illisibles, il apporte une valeur pour l’orientation vers une révision humaine. S’il déclare une forte certitude lors d’erreurs graves, ce signal ne permet pas d’automatiser les décisions. Le rapport doit inclure la couverture : la fraction du corpus pouvant passer sans révision sous un seuil de risque ; et la précision conditionnelle : combien de ces documents acceptés sont effectivement corrects.

La latence doit être mesurée de bout en bout, depuis le démarrage de la demande par le système jusqu’à l’obtention d’une sortie validée ou l’épuisement des tentatives supplémentaires. Il faut distinguer les percentiles, et non seulement les moyennes, et mesurer selon la taille et la complexité du document. Les temps de chargement, de conversion de fichiers, d’OCR s’il existe, d’inférence, de validation et de nouvelle tentative doivent aussi être séparés. Sinon, un goulot d’étranglement externe peut être attribué à tort au modèle.

Le coût utile n’est pas le prix annoncé par jeton. Pour chaque document, on additionne l’entrée, la sortie, les lectures ou écritures de cache applicables, le traitement des fichiers, les tentatives supplémentaires et les services auxiliaires. Le coût total est ensuite divisé par le nombre de documents qui satisfont la définition de la correction. Si une révision humaine est exigée, deux mesures distinctes sont nécessaires : le coût par résultat automatique correct et le coût par résultat final accepté, incluant le travail de révision. Les deux sont valides, mais répondent à des décisions différentes.

Résultats : ce qui peut être affirmé aujourd’hui et comment interpréter un futur essai

Aucune mesure du corpus proposé n’a été fournie pour Amazon Nova 2 Lite ni pour Claude Fable 5.1. Les sections de résultats doivent donc rester sans verdict de performance jusqu’à l’exécution et à la publication du protocole. La documentation AWS peut justifier l’entrée de Nova 2 Lite dans l’évaluation par ses capacités déclarées de compréhension documentaire et ses modalités associées. La documentation Anthropic peut justifier l’inclusion de Fable 5.1 par les capacités et conditions communiquées pour les PDF et les tableaux. Aucune de ces descriptions ne remplace un taux observé de champs corrects.

Un résultat favorable à Nova 2 Lite sur des documents numériques propres ne démontrerait pas une supériorité sur des numérisations, des tableaux complexes ou des contrats ambigus. De même, un résultat favorable à Claude Fable 5.1 dans une configuration dotée d’une fonction de sortie structurée ne démontrerait pas que l’avantage vient du modèle plutôt que de l’intégration. La ventilation par catégorie documentaire n’est pas un détail éditorial : elle permet à une équipe d’appliquer la conclusion à son propre portefeuille.

AWS publie un exemple d’architecture combinant Nova 2 Lite avec un autre modèle Claude pour la numérisation de documents scannés. Ce contenu est utile pour illustrer une architecture en plusieurs étapes et la nécessité de répartir coûts et tâches. Il ne doit pas servir de preuve comparative entre Nova 2 Lite et Claude Fable 5.1 : l’exemple mentionné utilise un autre modèle Claude et un cas documentaire différent.

Un futur essai devrait aussi rapporter les échecs récurrents, et pas seulement des agrégats. Parmi les catégories utiles figurent : cellule de tableau affectée à la mauvaise colonne, confusion entre sous-total et montant total, date normalisée de manière incorrecte, mauvaise partie contractante, erreur liée à une rotation ou à une faible résolution, perte d’une page, valeur non visible et non-respect du schéma. Un ensemble d’exemples anonymisés et révisables aide à déterminer si une moyenne élevée dissimule un type d’échec inacceptable.

Confidentialité, rétention et conditions pouvant invalider une décision fondée uniquement sur les métriques

Le choix de la voie d’accès affecte aussi bien l’évaluation que le déploiement. Amazon Bedrock documente des politiques de rétention des données ainsi que des contrôles de sécurité et de confidentialité. Anthropic documente séparément les conditions de rétention de son API, y compris des options telles que la rétention nulle lorsqu’elles sont disponibles dans les conditions applicables. Ces politiques doivent être vérifiées pour le compte, le produit, la région et l’accord contractuel précis ; une affirmation générale au sujet d’un fournisseur ne remplace pas cette vérification.

Avant de charger des documents réels, l’équipe doit classifier les données, déterminer si elles contiennent des informations personnelles, financières, contractuelles ou réglementées, et confirmer qui peut accéder aux instructions, réponses, fichiers et journaux. Elle doit aussi vérifier si le schéma JSON, les métadonnées de traçabilité et les exemples d’erreur contiennent des informations sensibles. La minimisation des données peut être plus importante qu’un faible écart de latence ou de prix.

La résidence des données, le chiffrement, la gestion des identités, les clés gérées par le client et les contrôles réseau peuvent déterminer quel service est admissible. AWS décrit des contrôles d’entreprise pour Bedrock, y compris des mécanismes de sécurité et d’isolation. L’évaluation doit consigner les contrôles activés, car une configuration de laboratoire avec des autorisations étendues peut ne pas représenter une architecture approuvable en production.

Il ne faut pas supposer que les données ne sont pas utilisées à des fins d’entraînement, qu’elles sont supprimées immédiatement ou qu’elles sont traitées dans un emplacement donné sans confrontation avec la documentation et le contrat en vigueur. Les politiques évoluent et peuvent dépendre de la modalité d’accès. Si une exigence de conformité n’est pas confirmée, la décision doit être « en attente de validation », et non une recommandation technique provisoire présentée comme suffisante.

Décision par scénario et limites de cette comparaison

Dans un scénario où le coût acceptable doit être le plus bas, la décision doit reposer sur le coût par document correct à l’intérieur d’un seuil minimal d’exactitude, et non sur le prix unitaire annoncé. Pour une exactitude maximale, l’exactitude par document critique, le taux d’hallucinations et le calibrage de l’incertitude doivent prévaloir. Pour une latence minimale, il faut examiner les percentiles de bout en bout sous la charge prévue. Pour une forte criticité, l’option adéquate peut être une combinaison d’extraction, de validation déterministe et de révision humaine, même si un modèle obtient une bonne moyenne agrégée.

Lorsque les deux modèles ne satisfont pas un seuil défini pour les champs critiques, la conclusion correcte est qu’aucun ne doit approuver automatiquement ces documents dans cette configuration. Les alternatives sont d’améliorer la qualité d’entrée, de séparer l’OCR de l’extraction, de diviser les documents par pages ou sections, de restreindre le schéma, d’ajouter des règles de validation, d’employer un routage par risque ou de maintenir une révision humaine. Changer de modèle sans diagnostiquer la cause peut déplacer l’erreur sans la résoudre.

Le calendrier de mise à jour doit dépendre de changements importants : nouvel identifiant de modèle, modification des prix, changement de limites ou de modalités, mise à jour des politiques de données, changement de région, évolution du corpus de production ou apparition d’un nouveau type documentaire. Chaque nouvelle mesure doit conserver la version précédente afin d’éviter de comparer des résultats incompatibles. La recommandation doit expirer explicitement si des composants qui n’ont pas été testés à nouveau changent.

En synthèse, les sources permettent d’établir qu’il existe des capacités et des contrôles documentés justifiant l’évaluation des deux options, mais elles ne permettent pas de quantifier un avantage entre elles dans l’extraction fiable de documents. Une décision traçable exige un essai propre et reproductible. Jusqu’à sa publication, toute préférence doit être considérée comme une hypothèse d’intégration, de coût ou de conformité, et non comme un résultat de qualité démontré.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.