Amazon Nova 2 Lite vs. Claude Fable 5.1 für die Datenextraktion aus Dokumenten: So konzipieren Sie einen reproduzierbaren Vergleich

Welche Entscheidung dieser Vergleich unterstützt – und was er nicht belegen kann

Die relevante Entscheidung lautet nicht, welches Modell abstrakt „besser“ ist, sondern welches zu einem konkreten Ablauf der Dokumentenextraktion passt. Der betrachtete Anwendungsfall besteht darin, Rechnungen, kurze Verträge, Formulare und PDF-Dokumente mit Tabellen in Daten zu überführen, die einem definierten Schema entsprechen. In solchen Abläufen genügt eine scheinbar richtige Antwort nicht: Sie muss die relevanten Werte bewahren, die geforderten Typen einhalten, das Fehlen eines Werts von einem tatsächlichen Wert unterscheiden und genügend Nachvollziehbarkeit für Fehlerkorrekturen bieten.

Die bereitgestellten Informationen beschreiben Amazon Nova 2 Lite und Claude Fable 5.1 aus Sicht ihrer Anbieter, enthalten jedoch keine Ergebnisse einer gemeinsamen Evaluation beider Modelle. Aus diesen Quellen lässt sich daher nicht ableiten, dass eines der Modelle bei einem bestimmten Dokumentenbestand höhere Genauigkeit, geringere Latenz oder niedrigere effektive Kosten erzielt. Ebenso wäre es nicht belastbar, Vergleiche von Amazon mit anderen Modellen auf die hier geplante Gegenüberstellung zu übertragen.

Die operative Schlussfolgerung vor Durchführung eines Tests ist folglich bedingt. Nova 2 Lite kann als multimodales Modell der Nova-2-Familie über Amazon Bedrock evaluiert werden. Claude Fable 5.1 kann über den von Anthropic dokumentierten Zugangsweg und unter den dort verfügbaren Bedingungen geprüft werden. Die Auswahl ist erst dann vertretbar, wenn ein Zugangsweg, ein eingefrorener Korpus, eine Korrektheitsdefinition, eine Wiederholungsrichtlinie und eine einheitliche Zuordnung von Zusatzkosten festgelegt sind.

Ein nützlicher Vergleich muss drei Ebenen trennen. Erstens die von jedem Anbieter erklärte Fähigkeit: unterstützte Modalitäten, APIs, Dokumentverarbeitung und verfügbare Kontrollen. Zweitens das auf einem konkreten Dokumentensatz gemessene Ergebnis. Drittens das Betriebsrisiko: unvollständige Daten, fehlerhafte OCR, nicht äquivalente Dokumente, Versionsänderungen, Kontingente, Aufbewahrungsrichtlinien und menschliche Prüfung. Werden diese Ebenen vermischt, entsteht häufig eine scheinbar quantitative, aber schwer prüfbare Entscheidung.

Modelle, Zugangswege und festzulegende Asymmetrien

Amazon dokumentiert Nova 2 Lite in Amazon Bedrock, einschließlich Modellkennungen, Inferenzoptionen sowie regionaler oder globaler Nutzungsmöglichkeiten. Die Nova-Dokumentation beschreibt zudem Fähigkeiten zur Verarbeitung von Dokumenten, PDFs, Tabellen und Layouts. Diese Fähigkeiten müssen in der exakt gebuchten Modalität überprüft werden, denn ein Test mit Text ist nicht gleichbedeutend mit einem Test, bei dem dem Modell Bilder oder Dokumente übergeben werden.

Anthropic führt Claude Fable 5.1 in seiner Dokumentation und auf der Produktseite auf und kommuniziert dort auch Verfügbarkeit, Preise sowie Fähigkeiten im Zusammenhang mit PDFs und Tabellen. Vor dem Vergleich muss das Team die genaue verwendete Kennung, das Datum, die Region oder den Verarbeitungsort soweit anwendbar, die API-Version, konfigurierte Grenzen, das Ausgabebudget und jede Denk- oder Cache-Konfiguration erfassen. Ohne diese Aufzeichnung kann ein späteres Ergebnis nicht reproduzierbar sein.

Bei strukturierter Ausgabe besteht eine mögliche methodische Asymmetrie. Die Anthropic-Dokumentation zu Structured Outputs beschreibt einen auf JSON Schema basierenden Mechanismus und weist darauf hin, dass die Unterstützung von Plattform und Modell abhängt. Nach den bereitgestellten Informationen gehört Fable 5.1 nicht zu den auf Bedrock mit Structured Outputs kompatiblen Modellen. Dies belegt nicht, dass Fable 5.1 auf anderen Wegen kein valides JSON erzeugen kann; es verpflichtet jedoch dazu, den auf jeder Seite verwendeten Mechanismus zu dokumentieren und zwei unterschiedliche Integrationen nicht als identisch darzustellen.

Es gibt zwei akzeptable Optionen mit unterschiedlichen Folgen. Die erste verwendet die native Schnittstelle jedes Anbieters und misst damit das tatsächlich einsetzbare System, wobei Plattformunterschiede offengelegt werden. Die zweite erzwingt einen gemeinsamen Nenner: einen Prompt mit JSON-Pflicht, externe Validierung gegen dasselbe Schema und dieselbe Zahl an Wiederholungen. Die zweite Option reduziert spezifische Integrationsvorteile; die erste bildet die Betriebserfahrung besser ab. Beide Ansätze dürfen nicht vermischt werden, ohne sie als getrennte Experimente zu kennzeichnen.

Reproduzierbares Design für strukturierte Extraktion

Der Korpus muss vor Sichtung der Ergebnisse eingefroren werden und die Arbeit repräsentieren, die automatisiert werden soll. Eine praktikable Aufteilung umfasst sauberen digitalen Text, einfache Tabellen, mehrseitige Tabellen, Scans, Formulare, Dokumente mit mehrdeutigen Feldern und unvollständige Dokumente. Aufzubewahren sind die Originaldatei, eine nicht sensible Kennung, Dokumenttyp, Sprache, Eingabekanal und bekannte Auffälligkeiten. Werden reale Daten genutzt, muss der Evaluationssatz die anwendbaren internen und vertraglichen Richtlinien einhalten.

Jedes Dokument benötigt eine vom Modell unabhängige Referenzwahrheit. Für kritische Felder sollten zwei Prüfende den erwarteten Wert, das legitime Fehlen, Mehrdeutigkeit und die zugrunde liegende visuelle oder textliche Evidenz annotieren. Bei Abweichungen muss eine dritte Prüfung oder eine Entscheidungsregel den Fall auflösen. Der Anteil doppelt geprüfter Dokumente und ungelöste Meinungsverschiedenheiten sind als Teil der Unsicherheit zu veröffentlichen, nicht in einer einzigen Genauigkeitszahl zu verbergen.

Das Schema sollte sowohl den Wert als auch seinen Status abbilden. Ein Datum kann beispielsweise gültig, fehlend, unleserlich, mehrdeutig oder außerhalb des Geltungsbereichs sein. Wird stets eine Zeichenkette erzwungen, kann aus einer Auslassung eine Erfindung werden. Empfehlenswert sind Evidenzfelder, ein nach eigenen Regeln ausgedrücktes Konfidenzniveau und eine Liste von Auffälligkeiten; eine vom Modell angegebene Sicherheit beweist jedoch nicht, dass sie gut kalibriert ist. Gemessen wird sie durch Vergleich dieses Signals mit den beobachteten Fehlern.

Der Prompt muss im semantischen Ziel identisch sein: nur Sichtbares oder nach einer dokumentierten Regel ausdrücklich Ableitbares extrahieren, bei fehlender Evidenz Abwesenheit zurückgeben und keine plausiblen Werte ergänzen. Ergänzt eine Anbieteroberfläche verpflichtende Systemanweisungen oder Formatelemente, müssen diese erhalten, archiviert und als Teil der Konfiguration berücksichtigt werden. Ebenfalls festzuhalten sind vorherige PDF-Konvertierung, OCR, Bildverkleinerung oder Seitenteilung.

Wiederholte Ausführungen sind auch dann erforderlich, wenn die Konfiguration deterministisch erscheint. Mindestens jede Kombination aus Modell, Dokumenttyp und Konfiguration sollte dreimal laufen. Die Ergebnisse müssen Streuung und, soweit die Stichprobengröße dies zulässt, Unsicherheitsintervalle ausweisen. Ein isolierter Unterschied von wenigen Feldern darf nicht zu einer Kaufempfehlung werden, wenn er innerhalb der beobachteten Variation liegt oder aus zu wenigen Dokumenten stammt.

Wichtige Metriken: Format, Bedeutung, Zeit und Kosten

Die Rate gültigen JSON misst, wie viele Antworten ohne eine inhaltlich verändernde Reparatur analysiert werden können. Sie ist notwendig, aber nicht ausreichend. Ein formal perfektes JSON kann einen falschen Lieferanten, einen erfundenen Betrag oder ein verschobenes Datum enthalten. Daher muss sie mit Feldgenauigkeit und Dokumentgenauigkeit kombiniert werden. Letztere kann streng definiert werden: Ein Dokument zählt nur dann als korrekt, wenn alle kritischen Felder mit der Referenz übereinstimmen und keine unbelegten Werte erscheinen.

Auslassungen und Halluzinationen müssen getrennt gezählt werden. Eine Auslassung liegt vor, wenn ein zu extrahierendes Feld fehlt oder fälschlich als abwesend markiert wird. Eine Halluzination ist ein als extrahiert dargestellter Wert ohne Beleg im Dokument oder im Widerspruch zur Referenz. Bei Verträgen, Rechnungen oder Compliance können Halluzinationen höhere Betriebskosten verursachen als Auslassungen, weil eine Prüfung eine Lücke leichter erkennt als einen plausiblen, aber falschen Wert. Die Gewichtung muss das Prozessrisiko abbilden, nicht eine allgemeine Präferenz.

Die Unsicherheitskennzeichnung ist als Klassifikationsaufgabe zu bewerten. Erkennt das Modell Zweifel bei tatsächlich mehrdeutigen oder unleserlichen Fällen, unterstützt dies die Weiterleitung an die menschliche Prüfung. Erklärt es bei schweren Fehlern hohe Sicherheit, erlaubt dieses Signal keine Automatisierung von Entscheidungen. Der Bericht muss die Abdeckung enthalten: Welcher Anteil des Korpus kann unter einem festgelegten Risikoschwellenwert ohne Prüfung passieren? Außerdem die bedingte Präzision: Wie viele dieser akzeptierten Dokumente sind tatsächlich korrekt?

Die Latenz muss Ende zu Ende gemessen werden, vom Start der Anfrage bis zum Erhalt einer validierten Ausgabe oder bis die Wiederholungen ausgeschöpft sind. Es sind Perzentile, nicht nur Mittelwerte, sowie Dokumentgröße und -komplexität zu trennen. Ladezeiten, Dateikonvertierung, gegebenenfalls OCR, Inferenz, Validierung und Wiederholung müssen ebenfalls separat erfasst werden. Andernfalls kann ein externer Engpass fälschlich dem Modell zugeschrieben werden.

Die nutzbaren Kosten entsprechen nicht dem angekündigten Tokenpreis. Für jedes Dokument werden Eingabe, Ausgabe, anwendbare Cache-Lese- oder Schreibvorgänge, Dateiverarbeitung, Wiederholungen und Hilfsdienste addiert. Anschließend werden die Gesamtkosten durch die Anzahl der Dokumente geteilt, welche die Korrektheitsdefinition erfüllen. Ist menschliche Prüfung erforderlich, gibt es zwei getrennte Kennzahlen: Kosten pro korrektes automatisches Ergebnis und Kosten pro endgültig akzeptiertes Ergebnis einschließlich Prüfaufwand. Beide sind gültig, beantworten aber unterschiedliche Entscheidungen.

Ergebnisse: Was heute gesagt werden kann und wie ein künftiger Test zu lesen ist

Für Amazon Nova 2 Lite oder Claude Fable 5.1 liegen keine Messungen des vorgeschlagenen Korpus vor. Deshalb müssen Ergebnisabschnitte ohne Leistungsurteil bleiben, bis das Protokoll ausgeführt und veröffentlicht wurde. Die AWS-Dokumentation kann begründen, Nova 2 Lite aufgrund seiner erklärten Fähigkeiten zur Dokumentverarbeitung und zugehörigen Modalitäten in die Evaluation aufzunehmen. Die Anthropic-Dokumentation kann die Aufnahme von Fable 5.1 durch die kommunizierten Fähigkeiten und Bedingungen für PDFs und Tabellen begründen. Keine dieser Beschreibungen ersetzt eine beobachtete Rate korrekter Felder.

Ein günstiges Ergebnis für Nova 2 Lite bei Dokumenten mit sauberem Text würde keine Überlegenheit bei Scans, komplexen Tabellen oder mehrdeutigen Verträgen belegen. Umgekehrt würde ein günstiges Ergebnis für Claude Fable 5.1 in einer Konfiguration mit einer strukturierten Ausgabefunktion nicht zeigen, dass der Vorteil vom Modell und nicht von der Integration stammt. Die Aufschlüsselung nach Dokumentkategorie ist kein redaktionelles Detail, sondern die Grundlage dafür, dass ein Team die Schlussfolgerung auf seinen eigenen Bestand anwenden kann.

AWS veröffentlicht ein Architekturbeispiel, das Nova 2 Lite mit einem anderen Claude-Modell zur Digitalisierung gescannter Dokumente kombiniert. Dieses Material ist als Illustration einer mehrstufigen Architektur sowie der Notwendigkeit nützlich, Kosten und Aufgaben aufzuteilen. Es darf nicht als Vergleichsnachweis zwischen Nova 2 Lite und Claude Fable 5.1 dienen: Das genannte Beispiel verwendet ein anderes Claude-Modell und einen anderen Dokumentenfall.

Ein künftiger Test sollte neben Aggregaten auch wiederkehrende Fehler berichten. Nützliche Kategorien sind: Tabellenzelle der falschen Spalte zugeordnet, Verwechslung von Zwischensumme und Gesamtbetrag, falsch normalisiertes Datum, falsche Vertragspartei, Fehler durch Drehung oder geringe Auflösung, verlorene Seite, nicht sichtbarer Wert und Nichteinhaltung des Schemas. Ein Satz anonymisierter, überprüfbarer Beispiele hilft festzustellen, ob ein hoher Mittelwert einen inakzeptablen Fehlertyp verdeckt.

Datenschutz, Aufbewahrung und Bedingungen, die eine rein metrische Entscheidung entkräften können

Die Wahl des Zugangswegs beeinflusst sowohl die Evaluation als auch den Einsatz. Amazon Bedrock dokumentiert Datenaufbewahrungsrichtlinien sowie Sicherheits- und Datenschutzkontrollen. Anthropic dokumentiert die Aufbewahrungsbedingungen seiner API getrennt, einschließlich Optionen wie Zero Data Retention, soweit diese unter den geltenden Bedingungen verfügbar sind. Diese Richtlinien müssen für das konkrete Konto, Produkt, die Region und die vertragliche Vereinbarung geprüft werden; eine allgemeine Aussage über einen Anbieter ersetzt diese Prüfung nicht.

Vor dem Hochladen echter Dokumente muss das Team die Daten klassifizieren, feststellen, ob sie personenbezogene, finanzielle, vertragliche oder regulierte Informationen enthalten, und klären, wer auf Prompts, Antworten, Dateien und Protokolle zugreifen kann. Ebenso ist zu prüfen, ob JSON Schema, Metadaten zur Nachvollziehbarkeit und Fehlerbeispiele sensible Informationen enthalten. Datenminimierung kann wichtiger sein als ein kleiner Unterschied bei Latenz oder Preis.

Datenresidenz, Verschlüsselung, Identitätsverwaltung, kundenseitig verwaltete Schlüssel und Netzwerkkontrollen können bestimmen, welcher Dienst zulässig ist. AWS beschreibt Unternehmenskontrollen für Bedrock, einschließlich Sicherheits- und Isolierungsmechanismen. Die Evaluation muss erfassen, welche Kontrollen aktiviert waren, denn eine Laborumgebung mit weitreichenden Berechtigungen kann eine für die Produktion genehmigungsfähige Architektur nicht repräsentieren.

Es darf nicht ohne Abgleich mit aktueller Dokumentation und Vertrag angenommen werden, dass Daten nicht zum Training verwendet, sofort gelöscht oder an einem bestimmten Ort verarbeitet werden. Richtlinien ändern sich und können vom Zugangsmodus abhängen. Ist eine Compliance-Anforderung nicht bestätigt, muss die Entscheidung „Validierung ausstehend“ lauten – nicht eine vorläufige technische Empfehlung, die als ausreichend dargestellt wird.

Entscheidung nach Szenario und Grenzen dieses Vergleichs

Für ein Szenario mit den niedrigsten akzeptablen Kosten muss die Entscheidung auf den Kosten pro korrektem Dokument innerhalb einer Mindestgenauigkeit beruhen, nicht auf dem angekündigten Stückpreis. Bei maximaler Genauigkeit sollten Dokumentgenauigkeit für kritische Felder, Halluzinationsrate und Kalibrierung der Unsicherheit maßgeblich sein. Bei niedrigster Latenz sind Ende-zu-Ende-Perzentile unter der erwarteten Last entscheidend. Bei hoher Kritikalität kann eine Kombination aus Extraktion, deterministischer Validierung und menschlicher Prüfung angemessen sein, selbst wenn ein Modell einen guten aggregierten Mittelwert erzielt.

Unterschreiten beide Modelle bei kritischen Feldern einen festgelegten Schwellenwert, lautet die richtige Schlussfolgerung, dass keines diese Dokumente in dieser Konfiguration automatisch freigeben sollte. Alternativen sind eine bessere Eingabequalität, die Trennung von OCR und Extraktion, das Aufteilen von Dokumenten nach Seiten oder Abschnitten, ein engeres Schema, zusätzliche Validierungsregeln, risikobasiertes Routing oder das Beibehalten menschlicher Prüfung. Ein Modellwechsel ohne Ursachenanalyse kann den Fehler verlagern, ohne ihn zu lösen.

Der Aktualisierungsplan muss von wesentlichen Änderungen abhängen: neuer Modellbezeichner, Preisänderung, Änderung von Grenzen oder Modalitäten, Aktualisierung von Datenrichtlinien, Regionswechsel, Veränderung des Produktionskorpus oder Auftreten eines neuen Dokumenttyps. Jede neue Messung muss die vorherige Version bewahren, damit keine inkompatiblen Ergebnisse verglichen werden. Die Empfehlung muss ausdrücklich verfallen, wenn Komponenten geändert werden, die nicht erneut getestet wurden.

Zusammenfassend erlauben die Quellen die Feststellung, dass dokumentierte Fähigkeiten und Kontrollen die Evaluation beider Optionen rechtfertigen; sie erlauben jedoch keine Quantifizierung eines Vorteils bei zuverlässiger Dokumentenextraktion. Eine nachvollziehbare Entscheidung erfordert einen eigenen, wiederholbaren Test. Bis zu dessen Veröffentlichung sollte jede Präferenz als Hypothese zu Integration, Kosten oder Compliance behandelt werden, nicht als nachgewiesenes Qualitätsergebnis.

Weiter entdecken

Korrekturen und Transparenz

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