Dokument – KI-Ground-Truth jenseits von OCR: Lesereihenfolge, Tabellen, Felder und Seitenbeziehungen

Document-AI-Systeme leisten mehr als OCR: Sie müssen die Struktur und die Beziehungen wiederherstellen, die eine Seite nutzbar machen. Für Teams, die KI-Trainingsdatensätze erstellen, kann ein Modell jedes Wort korrekt transkribieren und trotzdem an dem Workflow scheitern, für den es entwickelt wurde.

Eine Rechnung kann den richtigen Betrag enthalten, ihn aber der falschen Rechnungsposition zuordnen. Ein zweispaltiger Bericht kann jeden Satz enthalten und die Spalten dennoch in der falschen Reihenfolge zusammenfügen. Eine Tabelle kann jeden Zellenwert beibehalten, aber einen Wert unter der falschen Spaltenüberschrift platzieren. Das sind Fehler beim Dokumentverständnis, die allein anhand der Zeichenfehlerrate oder der Wortfehlerrate nicht erfasst werden können.

Deshalb muss die Ground Truth für Document AI über verifizierten Text hinausgehen. Wenn die Anwendung von der Lesereihenfolge, der Tabellentopologie, den Feldbeziehungen oder der seitenübergreifenden Kontinuität abhängt, benötigt der Referenzdatensatz Labels für diese Beziehungen, damit jede einzeln bewertet werden kann.

Die Unterscheidung besteht nicht darin, dass modernes OCR auf reinen Text beschränkt ist. Aktuelle Systeme wie Google Cloud Document AI können OCR-Text, Koordinaten und Layoutsignale zurückgeben. Die nützlichere Unterscheidung ist die zwischen Texterkennungsgenauigkeit und struktureller Genauigkeit: Eine Transkriptionsmetrik kann Ihnen sagen, ob die Wörter erkannt wurden, aber nicht, ob die für die Aufgabe benötigten Dokumentbeziehungen korrekt rekonstruiert wurden.

Ground Truth für Document AI bezeichnet verifizierte Referenzdaten, die zum Trainieren oder Bewerten von Systemen verwendet werden, die Dokumente in strukturierte Informationen umwandeln. Je nach Aufgabe kann sie OCR-Text und Layoutbereiche, Lesereihenfolge, Tabellenstruktur, benannte Felder, Schlüssel-Wert-Beziehungen, Dokumentklassen, Seitengrenzen und seitenübergreifende Links umfassen.

Ground Truth sollte mit der Ausgabe übereinstimmen, die bewertet wird. Wenn von einem Modell erwartet wird, dass es eine Tabellenhierarchie wiederherstellt, einem Feld seinen Wert zuordnet oder eine Tabelle über einen Seitenumbruch hinweg zusammenführt, ist eine verifizierte Transkription notwendig, aber nicht ausreichend. Das Evaluationsset muss die Beziehung selbst erfassen.

Deshalb ist beim Ausdruck „OCR-Genauigkeit“ Vorsicht geboten. Die Zeichenfehlerrate (CER) und die Wortfehlerrate (WER) messen den erkannten Text an einer Referenztranskription. Sie sind für die OCR-Qualität nützlich, geben aber keinen Aufschluss darüber, ob ein korrekt erkannter Betrag dem richtigen Feld zugewiesen wurde oder ob korrekt erkannte Blöcke in der richtigen Reihenfolge platziert wurden.

Die Lesereihenfolge erscheint in einem einspaltigen Brief trivial. Sie wird jedoch zu einem eigenen Annotationsproblem, sobald eine Seite zwei Spalten, eine Seitenleiste, ein hervorgehobenes Zitat, eine Fußnote, eine schwebende Bildunterschrift oder ein Formular mit mehreren ausgerichteten Gruppen enthält.

Die Referenzdaten benötigen daher eine explizite Ordnungseinheit. Ein Projekt kann Blöcke, Bereiche, Zeilen oder eine andere Layout-Einheit ordnen, aber die Regel muss festgelegt werden, bevor die Produktionsannotation beginnt. Andernfalls können zwei sorgfältige Prüfer unterschiedlicher Meinung sein, obwohl beide glauben, sie folgten der „natürlichen Lesereihenfolge“.

Aktuelle Forschung behandelt die Lesereihenfolge als messbare Aufgabe statt als informelles Nebenprodukt der Layouterkennung. LaTeX2Layout, veröffentlicht auf der AAAI 2026, rekonstruiert sowohl Layoutbereiche als auch die Lesereihenfolge aus Compiler-Traces und bewertet die Sequenzübereinstimmung anhand von Kendalls Tau getrennt vom Element-Grounding. ROOR annotiert die Lesereihenfolge ebenfalls in Form expliziter Ordnungsrelationen, statt anzunehmen, dass Regionsboxen eine Sequenz implizieren.

Dieselbe Richtung zeigt sich in neueren Benchmarks für visuell reichhaltige Dokumente. MosaicDoc, ebenfalls auf der AAAI 2026 veröffentlicht, kombiniert OCR-, Lesereihenfolge-, Lokalisierungs- und Document-Question-Answering-Annotationen für komplexe Zeitungs- und Zeitschriftenlayouts. Die nützliche Lehre ist kein bestimmter Benchmark-Score:  Das Lokalisieren der richtigen Bereiche und das Ordnen dieser Bereiche sind unterschiedliche Fähigkeiten; daher sollte ein Evaluationsdatensatz sie nicht als austauschbar behandeln.

Wenn die Reihenfolge für die nachgelagerte Aufgabe wichtig ist, braucht sie eigene Referenzlabels.

Bei der Tabellenextraktion gibt es mindestens zwei verschiedene Fehlermodi. Ein Modell kann den Text in einer Zelle falsch lesen oder ihn korrekt lesen und dabei die Zelle der falschen Zeile, Spalte oder visuellen Hierarchie der Kopfzeile zuordnen. Eine einzelne kombinierte Genauigkeitszahl macht es schwer, diese Fehler zu diagnostizieren.

Tree-Edit-Distance-basierte Ähnlichkeit (TEDS), eingeführt mit PubTabNet, vergleicht eine vorhergesagte Tabellenrepräsentation mit der Referenz als Baum. Rein strukturelle Varianten, die üblicherweise als TEDS-Struct oder TEDS-S ausgewiesen werden, ignorieren den Zelltext, damit Transkriptionsfehler die strukturelle Bewertung nicht dominieren. Aktuelle Tabellenextraktions-Benchmarks für 2026 weisen TEDS und TEDS-S aus genau diesem Grund weiterhin getrennt aus.

Diese Trennung ist im operativen Betrieb nützlich. Wenn die Leistung nach einer Modelländerung sinkt, muss ein Team wissen, ob die Regression von der OCR, einer übersehenen verbundenen Zelle, einer verschobenen Spaltengrenze oder einer falschen Kopfzeilen-Textkörper-Beziehung stammt. Diese Probleme erfordern unterschiedliche Korrekturen.

Auch die Domäne des Datensatzes spielt eine Rolle. PubTabNet wurde aus Tabellen wissenschaftlicher Artikel erstellt, während FinTabNet aus Finanzdokumenten erstellt wurde. Ein Modell, das eine Population gut verarbeitet, kann Schwierigkeiten haben, wenn sich die Layoutgrammatik ändert, insbesondere bei verschachtelten Kopfzeilen, Zwischensummen, verbundenen Zellen und dichter finanzieller Formatierung.

Angenommen, ein Formular enthält drei Vorkommen des Labels „Date“: Rechnungsdatum, Fälligkeitsdatum und Lieferdatum. Ein Modell kann jedes Label und jeden Datumswert lokalisieren, alle sechs Spans korrekt transkribieren und dennoch scheitern, wenn es sie falsch einander zuordnet.

Deshalb braucht die Feldextraktion oft Beziehungslabels statt nur Boxen. Der ursprüngliche FUNSD-Datensatz macht diesen Unterschied explizit: Er kennzeichnet semantische Entitäten wie Fragen und Antworten und erfasst die Verknüpfungen zwischen diesen Entitäten separat. Die Annotation besagt nicht nur „dieser Text ist hier vorhanden“, sondern auch „diese beiden Teile gehören zusammen“.

Der schwierige Teil besteht darin, die Einheit zu definieren, die verknüpft werden kann. Eine mehrzeilige Adresse könnte ein einzelner Wert, mehrere Zeilen oder eine Menge verschachtelter Felder sein. Ein vages Schema lässt jeden Annotator eine andere Wahl treffen, wodurch Uneinigkeit zu Ground-Truth-Rauschen wird.

Dieses Risiko ist nicht theoretisch. Forschende, die FUNSD erneut untersuchten, dokumentierten inkonsistente Labels und überarbeiteten den Datensatz für die Schlüssel-Wert-Erkennung. Spätere Arbeiten zur Neuetikettierung haben weiterhin Inkonsistenzen bei der Granularität und der Verknüpfung hervorgehoben. Die praktische Lehre ist einfach: Definieren Sie Entitätsgrenzen und Verknüpfungsregeln anhand schwieriger Beispiele, bevor ein großes Annotationsteam beginnt.

Modellgestützte Vorannotation kann repetitive Arbeit reduzieren. Ein Modell kann Boxen, Felder, Tabellen oder Verknüpfungen vorschlagen, und eine prüfende Person kann sie korrigieren. Doch der Vorschlag sollte ein Vorschlag bleiben: Prüfende müssen darin geschult werden, nach plausibel wirkenden strukturellen Fehlern zu suchen, statt anzunehmen, dass eine selbstsichere Modellausgabe bereits Ground Truth ist.

Eine fehlende Verknüpfung ist nicht derselbe Defekt wie ein fehlendes Feld. Das Label und der Wert können beide vorhanden und perfekt transkribiert sein, während die Beziehung zwischen ihnen falsch ist.

Eine Seite ist nicht immer die richtige Bewertungseinheit. Eine Tabelle kann auf Seite 4 beginnen und auf Seite 5 fortgesetzt werden. Ein gescannter Stapel kann drei Rechnungen direkt hintereinander enthalten, weil sie als eine PDF-Datei eingegangen sind. Ein Verweis im Text kann sich auf einen Anhang beziehen, der mehrere Seiten später folgt. Eine Abschnittsüberschrift kann eine Hierarchie festlegen, die sich über Seitenumbrüche hinweg fortsetzt.

Diese Beziehungen benötigen Labels auf Dokumentebene, wenn die Anwendung von ihnen abhängt. Nützliche Beispiele hierfür sind:

• Tabellenfortsetzung  -  ob zwei Fragmente zur selben logischen Tabelle gehören und wie die Fortsetzung verbunden werden soll.

• Dokumentgrenzen  -  wo ein logisches Dokument endet und das nächste innerhalb eines kombinierten Scans oder Pakets beginnt.

• Querverweise  -  auf welche Abbildung, Tabelle, Abschnitt oder Anmerkung sich ein Verweis tatsächlich bezieht.

• Hierarchische Struktur  -  wie Überschriften, Unterüberschriften und Textabschnitte über das gesamte Dokument hinweg verschachtelt sind.

Es ist schwieriger, dies konsistent zu annotieren, als Boxen auf einzelnen Seiten zu zeichnen. Prüfende benötigen genügend Kontext, um das gesamte Dokument zu verstehen, und die Arbeit lässt sich weniger leicht auf mehrere Personen aufteilen, ohne die Kontinuität zu verlieren.

Öffentliche Benchmarks spiegeln diese Realität zunehmend wider. DUDE wurde für mehrseitige, domänenübergreifende, visuell reichhaltige Dokumente konzipiert, während VRDU reichhaltige Schemata, komplexe Vorlagen, wiederholte und verschachtelte Felder sowie Layoutvielfalt in Geschäftsdokumenten betont. Bei einem Produktionsdatensatz geht es nicht darum, einen Benchmark nachzuahmen. Vielmehr geht es darum, zu entscheiden, von welchen seitenübergreifenden Beziehungen die tatsächliche Anwendung abhängt, und diese Beziehungen gezielt mit Labels zu versehen.

Getrennte Metriken sind keine bloße akademische Fleißarbeit. Sie machen Fehler diagnostizierbar.

Stellen Sie sich ein Feldextraktionssystem vor, das nach einem Modell-Update schlechter wird. Wenn das einzige Ergebnis „zu 92 % genau“ lautet, sagt diese Zahl dem Team nicht, wo es nachsehen soll. Die Verschlechterung könnte von der Texterkennung, der Lesereihenfolge, der Tabellenstruktur, der Feldverknüpfung, den Dokumentgrenzen oder mehreren davon gleichzeitig herrühren.

Ein nützliches Evaluationsset hält diese Signale ausreichend getrennt, um sie untersuchen zu können. Das bedeutet nicht, dass jedes Projekt ein Dutzend Dashboard-Metriken braucht. Es bedeutet, dass die berichtete Metrik zu der Aussage passen sollte, die getroffen wird. Wenn das Ziel die Transkription ist, weisen Sie eine Transkriptionsmetrik aus. Wenn das Ziel die Tabellenstruktur ist, weisen Sie eine Strukturmetrik aus. Wenn das Ziel die Key-Value-Extraktion ist, legen Sie fest, wie sowohl die Entitätenerkennung als auch die Verknüpfung bewertet werden.

Wenn zwei Fehler unterschiedliche Korrekturmaßnahmen erfordern, sollten sie in der Evaluation normalerweise unterscheidbar bleiben. Ein Gesamtwert kann weiterhin nützlich sein, sollte aber nicht die Teilmessungen ersetzen, die nötig sind, um zu diagnostizieren, was sich geändert hat.

Eine Qualitätsmetrik ohne ihre Messmethode ist kein Nachweis. „95 % genau“ wird erst nützlich, wenn ein Leser weiß, was als richtig gezählt wurde, welche Referenzlabels verwendet wurden und wie mehrdeutige Fälle aufgelöst wurden.

Dieselben Wörter können ein ganz anderes Dokument erzeugen – ein Problem beim Dokumentverständnis, wenn sich das Layout ändert. Das macht kontrollierte Designvariation zu einer nützlichen Methode, um zu testen, ob ein Modell die Dokumentstruktur gelernt hat oder nur vertraute Vorlagen.

Ein praktisches Experiment besteht darin, den Inhalt konstant zu halten und jeweils nur eine Layoutvariable zu ändern:

• einspaltiger Text gegenüber zweispaltigem Text;
• ein Feldwert direkt neben seiner Beschriftung gegenüber einem in einiger Entfernung ausgerichteten Feldwert;
• eine einfache Tabellenkopfzeile gegenüber zusammengeführten oder verschachtelten Kopfzeilen;
• eine Bildunterschrift direkt unter einem Bild gegenüber einem schwebenden Callout;
• eine Tabelle, die auf einer Seite bleibt, gegenüber derselben Tabelle, die auf einer zweiten Seite fortgesetzt wird.

Lassen Sie die Varianten dieselbe OCR-/Dokument-KI-Pipeline durchlaufen und bewerten Sie Transkription und Struktur getrennt. Wenn die Wörter korrekt bleiben, während Lesereihenfolge, Tabellentopologie oder Feldverknüpfungen schlechter werden, deutet der Test auf ein Problem der Layout-Generalisierung hin und nicht auf ein isoliertes OCR-Problem.

Für eine designorientierte Publikation ist dies ein glaubwürdigerer Blickwinkel auf den Informationsgewinn als eine weitere generische Liste der Vorteile von Dokument-KI. Dieser Ansatz macht Seitendesign zu einer kontrollierten Variablen, die gemessen werden kann. Veröffentlichen Sie keine numerischen Ergebnisse, es sei denn, das Experiment wird tatsächlich durchgeführt und seine Methodik dokumentiert.

Ein Projekt benötigt standardmäßig nicht jede Ebene. Es benötigt die Ebenen, die den tatsächlichen nachgelagerten Entscheidungen entsprechen. Ein Dokumentenklassifizierungssystem benötigt möglicherweise keine Tabellenbeschriftungen auf Zellebene. Ein Rechnungsautomatisierungssystem wahrscheinlich schon. Das Ziel ist nicht maximale Annotationsdichte, sondern ausreichende Referenzdaten, um die Aufgaben beurteilen zu können, die tatsächlich wichtig sind.

Die teuren Fehler passieren normalerweise, bevor die erste Produktionscharge gelabelt wird. Eine funktionierende Pipeline sieht so aus:
1. Definieren Sie zuerst das Schema. Legen Sie fest, was als Feld, Tabelle, Lesereihenfolge-Einheit und Dokumentgrenze gilt. Nehmen Sie schwierige Beispiele auf, nicht nur ideale Seiten.

2. Führen Sie eine Pilotcharge durch. Verwenden Sie eine kleine, aber vielfältige Stichprobe, um Unstimmigkeiten in den Richtlinien zu finden, bevor sie sich über Tausende von Seiten ausbreiten.

3. Messen Sie Unstimmigkeiten dort, wo Mehrdeutigkeit relevant ist. Nicht jedes Label benötigt eine formale Statistik zur Inter-Annotator-Übereinstimmung, aber wiederkehrende Unstimmigkeiten sollten eher eine Änderung der Richtlinien oder eine Adjudikationsregel auslösen als eine stillschweigende Mittelwertbildung.
4. Nutzen Sie modellgestützte Vorannotation selektiv. Automatisierung ist nützlich für sich wiederholende Vorschläge, während sich menschliche Aufmerksamkeit auf Beziehungen und Randfälle konzentrieren sollte, bei denen Fehler teuer sind.
5. Bewerten Sie Inhalt und Struktur getrennt. Halten Sie Transkription, Tabellentopologie, Entity-Linking und seitenübergreifende Beziehungen so getrennt, dass sich Regressionen diagnostizieren lassen.
6. Versionieren Sie das Schema und bewahren Sie die Provenienz. Ein Team sollte nachvollziehen können, welche Richtlinienversion ein Label erzeugt hat, wie es überprüft wurde und warum eine Ausnahme akzeptiert wurde.

Das kleinste nützliche Schema ist besser als ein ausgefeiltes Schema, das niemand konsistent anwenden kann. Definieren Sie nur die Labels, die echte Modell- oder Produktfragen beantworten, und machen Sie diese Labels dann reproduzierbar.

Wenn Sie einen Dokumentdatensatz lizenzieren, in Auftrag geben oder genehmigen, stellen Sie Fragen, die die Struktur hinter der zentralen Genauigkeitskennzahl offenlegen:
• Was ist die Einheit der Lesereihenfolge-Annotation: Wörter, Zeilen, Blöcke oder Regionen?
• Werden Tabellenstruktur und Zelltext getrennt ausgewertet?
• Werden Schlüssel-Wert-Beziehungen explizit gekennzeichnet oder aus der räumlichen Nähe abgeleitet?
• Wie werden wiederholte, verschachtelte und mehrzeilige Felder behandelt?
• Sind Labels für Fortsetzungen und Dokumentgrenzen seitenübergreifend verfügbar?
• Welche mehrdeutigen Fälle sind in den Annotationsrichtlinien dokumentiert?
• Gab es einen Pilotlauf und ein Verfahren zur Beilegung von Meinungsverschiedenheiten zwischen Prüfern?
• Lässt sich die Datensatzversion auf eine Schema-Version und eine Produktionscharge zurückführen?
• Welche Metriken werden berichtet, und was genau zählt als korrekte Vorhersage?

Diese Fragen verraten oft mehr über die Eignung eines Datensatzes als eine einzelne aggregierte Genauigkeitskennzahl.

Wenn Sie sich noch in der früheren Beschaffungsphase befinden, deckt DesignWizards Leitfaden zum Finden professioneller Datensätze für Machine-Learning-Projekte die breitere Datensatzsuche und -beschaffung ab. Dieser Artikel setzt einen Schritt später an, nämlich dann, wenn die Frage lautet, was die Referenzlabels selbst enthalten müssen.

Für Teams, die Dokumentdaten in Auftrag geben, deckt Wavebreak Medias Seite mit Dokumentdatensätzen für KI-Training lizenzierte und individuelle Dokumentdatensätze für OCR, Layoutverständnis, Feldextraktion, Tabellen und strukturierte Metadaten ab. Für kommerzielle Projekte behandelt die Beratung von Wavebreak Media zur Lizenzierung von KI-Datensätzen auch Nutzungsrechte, Herkunft, Freigaben und begleitende Dokumentation. Ein Dokument-KI-Projekt sollte dennoch ein eigenes strukturelles Schema und eigene Akzeptanzkriterien definieren, statt anzunehmen, dass das Wort „annotiert“ die Beziehungen abdeckt, die es benötigt.

Was ist dokumentierte Ground Truth für Document AI?

Document-AI-Ground-Truth bezeichnet verifizierte Referenzdaten, die zum Trainieren oder Bewerten von Systemen verwendet werden, die Dokumente interpretieren. Je nach Aufgabe kann sie Transkription, Lesereihenfolge, Tabellenstruktur, Feldbeziehungen, Dokumentgrenzen und seitenübergreifende Verknüpfungen umfassen.

Was ist der Unterschied zwischen OCR-Genauigkeit und Document-AI-Genauigkeit?

OCR-Metriken wie CER und WER messen, ob Text korrekt erkannt wurde. Die Bewertung von Document AI muss gegebenenfalls auch messen, ob Bereiche korrekt angeordnet, Tabellen korrekt rekonstruiert, Felder mit den richtigen Werten verknüpft und Beziehungen über Seiten hinweg erhalten wurden.

Welche Annotationen benötigt ein Document-AI-Datensatz?

Benötigt werden nur die Annotationen, die für die nachgelagerte Aufgabe erforderlich sind. Ein Formularextraktor benötigt möglicherweise Schlüssel-Wert-Verknüpfungen und Regeln für wiederkehrende Felder; ein Tabellensystem benötigt möglicherweise Annotationen für Zeilen, Spalten, Spans und Kopfzeilen; ein mehrseitiger Workflow benötigt möglicherweise Dokumentgrenzen und Fortsetzungslabels.

Wie bewertet man die Lesereihenfolge in einem Dokument?

Definieren Sie zunächst die Einheit, die geordnet wird, etwa Blöcke oder Regionen, und vergleichen Sie dann die vorhergesagte Sequenz mit einer Referenzsequenz. Forschungs-Benchmarks verwenden Rangmaße wie Kendalls Tau, aber die geeignete Metrik hängt von der Annotation und der Aufgabe ab.

Wie wird die Genauigkeit der Tabellenstruktur getrennt von der OCR gemessen?

Metriken wie TEDS-Struct oder TEDS-S vergleichen die Tabellenstruktur und schließen dabei den Zelltext aus. Dadurch können strukturelle Fehler wie eine falsche Zeilen-/Spaltenzugehörigkeit oder fehlende Spans getrennt von Transkriptionsfehlern bewertet werden.

Kann ein vorhandener OCR-Datensatz für die Bewertung von Document AI wiederverwendet werden?

Manchmal, aber in der Regel nur für die Ebenen, für die er bereits Labels enthält. Wenn die Anwendung von der Lesereihenfolge, der Tabellenstruktur, den Feldverknüpfungen oder den seitenübergreifenden Beziehungen abhängt, müssen diese Labels möglicherweise hinzugefügt werden, bevor mit dem Datensatz die vollständige Aufgabe bewertet werden kann.

Wie bewertet man mehrseitige Document-AI-Systeme?

Verwenden Sie Referenzen auf Dokumentebene für die Beziehungen, die Seitengrenzen überschreiten: Tabellenfortsetzung, Dokumentgrenzen, hierarchische Abschnitte und Querverweise. Die Genauigkeit einzelner Seiten allein kann nicht zeigen, ob diese Beziehungen erhalten geblieben sind.

Was sollte ein Käufer prüfen, bevor er eine Dokumentannotation in Auftrag gibt?

Fragen Sie, welche Beziehungen ausdrücklich mit Labels versehen werden, wie schwierige Fälle definiert werden, wie Prüfer Meinungsverschiedenheiten auflösen, welcher QA-Prozess verwendet wird und was jede gemeldete Metrik tatsächlich misst.

Der am einfachsten messbare Fehler in der Dokumenten-KI ist ein falsches Zeichen. Viele der kostspieligen Fehlschläge passieren, nachdem die Zeichen bereits korrekt sind.

Eine Tabellenzelle steht unter der falschen Kopfzeile. Ein Wert ist mit dem falschen Label verknüpft. Zwei Spalten werden in der falschen Reihenfolge gelesen. Eine Tabellenfortsetzung wird als neue Tabelle behandelt, weil im Evaluierungsset nie erfasst wurde, dass die Seiten zusammengehörten.

Eine gute Ground Truth macht diese Beziehungen sichtbar. Die Textgenauigkeit sagt einem, was erkannt wurde; die strukturelle Ground Truth sagt einem, ob die Ausgabe so organisiert war, wie es die Aufgabe verlangt.

Das ist die nützliche Trennlinie für die Evaluierung: Wenn eine nachgelagerte Entscheidung von einer Beziehung abhängt, sollte die Datensatzspezifikation angeben, wie diese Beziehung dargestellt, geprüft und bewertet wird.