Methodik
Methodik: So messen wir
Jede Zahl auf dieser Website lässt sich auf ein konkretes Dokument, eine Modellausgabe und die Kosten eines Laufs zurückführen. So entstehen sie.
Was wir messen
Drei alltägliche Büroaufgaben: 13 Felder aus einer Rechnung auslesen (Lieferant, Kennungen, Belegnummer, Zahlungsreferenz, Daten, Netto und Steuer je Satz, Gesamtbetrag, Währung, Bankverbindung); Kunden-E-Mails einordnen (Kategorie, Priorität, Stimmung, Kunde, Bestell- und Rechnungsnummer, Betrag, Währung, Frist); und personenbezogene Daten in Geschäftstexten finden, etwa bevor sie an einen KI-Dienst gehen (Namen, E-Mails, Telefonnummern, Adressen, Geburtsdaten, Identifikationsnummern, Bankkonten). Wir zeigen den Anteil richtiger Felder und den Anteil fehlerfreier Dokumente, denn für ein Unternehmen zählt oft die zweite Zahl mehr. Die Dokumente sind auf Tschechisch und amerikanischem Englisch.
Der Testdatensatz
Alle Dokumente sind synthetisch: aus zufälligen, aber gültigen Daten erzeugt (tschechische Firmen- und Geburtsnummern mit Prüfsumme, Bankkonten nach den Regeln der Tschechischen Nationalbank, EINs, ABA-Routingnummern). Die richtige Antwort sind also die Quelldaten, keine manuelle Abschrift, und sie enthält keine Tippfehler. Keine echten Personen- oder Firmendaten: E-Mail-Adressen nutzen .example-Domains, US-Telefonnummern den fiktiven Bereich 555-01xx, SSNs einen nie vergebenen Bereich. Ein tschechisches und ein englisches Dokument bilden ein Paar mit gleicher Struktur; so messen wir die Sprachlücke.
Rechnungen gibt es in acht Layouts mit realistischen Varianten (Kleinunternehmer ohne USt, Anzahlungsrechnung, Gutschrift, Fremdwährung) und in vier Stufen: 30 % PDF-Text, 30 % sauberes Bild, 30 % Scan (Drehung, Rauschen, JPEG), 10 % Foto (Perspektive, Schatten). Ein Drittel jedes Satzes ist nicht öffentlich; daraus veröffentlichen wir nur Gesamtwerte, damit kein Modell punktet, weil es die Antworten schon kennt.
E-Mails gibt es als einzelne Nachricht, mit langer Signatur, als Verlauf mit zitierten früheren Nachrichten und als von einem Kollegen weitergeleitete E-Mail; Fristen sind auch relativ („bis Freitag“). Die Priorität folgt festen Regeln im Prompt und ist daher keine Ansichtssache. Texte mit personenbezogenen Daten (Personalakten, Support-Tickets, Protokolle, E-Mails) enthalten bewusst auch nicht personenbezogene Angaben: Firmennamen aus Nachnamen, Firmennummern, allgemeine Adressen wie info@, Bestellnummern und Daten, die keine Geburtsdaten sind.
So läuft ein Durchgang ab
Alle Modelle rufen wir über OpenRouter mit demselben Prompt in der Sprache des Dokuments und Temperatur 0 auf, jedes Modell bei einem festen Anbieter, damit die Ergebnisse reproduzierbar sind. Unterstützt ein Modell strukturierte Ausgabe (JSON-Schema), nutzen wir sie; lehnt der Anbieter das Schema ab, fragen wir ohne Schema erneut und vermerken das. Ist die Antwort kein gültiges JSON, fragen wir noch einmal und vermerken auch das. Für jeden Aufruf speichern wir Modell, Prompt- und Datensatzversion, Tokens, Kosten, Latenz und Anbieter. Ausgaben werden zwischengespeichert, daher zahlen wir jede Woche nur für neue Modelle, Dokumente und Prompts.
So bewerten wir
Ein Feld ist richtig, wenn es nach Normalisierung des Formats exakt mit dem richtigen Wert übereinstimmt: Datumsangaben als JJJJ-MM-TT, Beträge als Zahl mit zwei Nachkommastellen (beide Trennzeichenkonventionen), Leerzeichen in Kennnummern und Kontonummern werden ignoriert. Diakritische Zeichen werden nicht normalisiert: „Horak“ statt „Horák“ ist ein Fehler. Fehler werden kategorisiert (fehlendes Feld, falscher Wert, Diakritika verloren, vertauschte Daten, Netto statt Gesamtbetrag, falscher Steuersatz, Zahlenformat, ungültiges JSON). Die Schwelle für Rechnungen liegt bei 95 % richtigen Feldern.
E-Mails: Kategorie, Priorität und Stimmung müssen exakt stimmen; relative Fristen müssen das richtige Datum ergeben. Personenbezogene Daten: Jedes Feld ist eine Liste und nur dann richtig, wenn sie vollständig ist und nichts zu viel enthält; eine als personenbezogen gemeldete Firmennummer zählt als erfundener Wert. Die Schwelle liegt bei allen Aufgaben bei 95 % richtigen Feldern.
Kosten und Sprachsteuer
Die Kosten sind der reale Tokenverbrauch, wie ihn die API in USD zurückgibt, hochgerechnet auf 1.000 Dokumente. Die Umrechnung in andere Währungen erfolgt nur für die Anzeige, zum Kurs in der Fußzeile. Die Sprachsteuer messen wir an einem Parallelkorpus aus 50 Absätzen auf Tschechisch, Deutsch, Französisch, Spanisch, Polnisch und Englisch: Wir senden den Text mit einem minimalen Ausgabelimit, ziehen den Overhead eines leeren Prompts ab und vergleichen die Eingabe-Tokens mit Englisch.
Die echten Kosten rechnen die Arbeit einer Person hinzu, die jedes fehlerhafte Dokument finden und korrigieren muss: 3 Minuten pro Dokument zu 450 CZK / 35 EUR / 40 USD pro Stunde. Tempo ist die mittlere Antwortzeit (90. Perzentil im Tooltip); gültige Antworten ist der Anteil der Dokumente mit gültigem JSON. Fehler durch Ratenbegrenzung der API rechnen wir keinem Modell an: Sie werden wiederholt, bis jedes Dokument eine Antwort hat.
Der Kostenrechner nutzt gemessene Kosten, wo wir Dokumente in der Sprache haben. Für andere Sprachen schätzt er: den an echten Dokumenten in einer anderen Sprache gemessenen Aufschlag, umgerechnet mit der Sprachsteuer der gewählten Sprache (ein Rechnungsbild kostet in jeder Sprache gleich viel, das reine Token-Verhältnis würde übertreiben). Schätzungen sind mit ≈ markiert und haben keine Genauigkeit.
Die Sprachlücke
Der Genauigkeitsunterschied zwischen tschechischen und englischen Dokumenten wird nur über Felder berechnet, die beide Versionen haben. US-Rechnungen haben keine USt-IdNr. und kein Leistungsdatum, daher fließen diese Felder nicht in den Vergleich ein.
Grenzen
Synthetische Dokumente decken nicht alles ab, was einem echten Unternehmen begegnet (handschriftliche Notizen, mehrseitige Rechnungen, ungewöhnliche Layouts). Bei rund 150 Dokumenten pro Sprache liegt die Unsicherheit der Genauigkeit bei etwa ±1 Prozentpunkt; kleinere Unterschiede zwischen Modellen sollten Sie nicht als entscheidend werten. Modelle und Preise ändern sich, daher zeigt jede Zahl das Datum des Laufs.
Unabhängigkeit
Rankings und Empfehlungen sind nicht käuflich. Kein Modellanbieter bezahlt uns für eine Platzierung. Wenn Sie einen Fehler in einer richtigen Antwort oder in der Bewertung finden, geben Sie uns Bescheid; wir korrigieren ihn und vermerken die Änderung.
Aktueller Lauf: 20260928T085806Z-5d2ece vom 28. September 2026, Datensatzversion 0.1.0.