KI trifft Katalogisierung. Tests zur automatisierten Erstellung von formalen Metadaten an der Österreichischen Nationalbibliothek

2.2.1 Aufbau des Workflows

Allgemein gesehen kann der Ablauf in drei Grundblöcke (s. Abbildung 1) unterteilt werden: 1. Vorverarbeitung der PDFs, 2. LLM, 3. Postprozessierung der Metadaten.

Bei der Vorverarbeitung der PDFs werden nur die für die Erschließung relevanten Seiten (Titelseite, Impressum) extrahiert. Die verwendeten Sprachmodelle verarbeiten ausschließlich Text und keine Bilder oder PDFs. Daher umfasst der Vorbereitungsschritt der PDFs auch eine OCR der relevanten Seiten, um den so generierten Text an das LLM weitergeben zu können. Mit Microsoft Power Automate und dem AI Builder ist es möglich, PDFs in einer verarbeitbaren Qualität OCR zu lesen. Alternativ wäre es durch Python-Pakete wie pdftotext möglich, den Text aus einem elektronischen Dokument zu extrahieren, allerdings werden hier wichtige Informationen ausgelassen. Zum Beispiel werden die verantwortlichen Körperschaften bei dieser Art von Dokument gerne in der Form von Logos – ohne hinterlegten Text – angegeben. Solche Informationen gehen durch eine Textextraktion von pdftotext verloren. Da wir die Verantwortlichkeitsangabe oder die Angabe des geistigen Schöpfers als essenziell für die Auffindung von Ressourcen sehen und diese somit prioritär zu erfassen sind, haben wir den Weg der OCR für die Textextraktion gewählt. Hiermit können wir auch garantieren, dass exakt dieselben Prompts für das lokale LLM wie auch für die proprietäre Variante zur Verfügung stehen und die Ergebnisse vergleichbar sind. Der letzte Schritt in der Vorverarbeitung der PDFs, die nur mehr als stark gekürzter OCR-Text vorliegen, ist die Einbettung in einem Prompt und stellt den Übergang zum zweiten Block des Workflows, die Interaktion mit den LLMs, dar. Der PDF-Text wird in einer Variable abgespeichert und wird als Teil des Prompts an das LLM gegeben.

This is the title page of a publication: [OCR-Text]

Extract metadata from the following text and return the result only in this exact format:

Title / Title Supplement / Author / Publisher / Publication Period / Place of Publication / Editor

• If any of these fields are missing, replace them with [N/A].

• The place of publication must be a city, not a country.

• Return ONLY the metadata in the specified format.

• No labels, explanations, or additional text.

• Do not include abstracts or summaries.

Es ist ersichtlich, dass die Metadaten in Form einer Liste abgefragt werden, wobei die einzelnen Kategorien durch einen Schrägstrich getrennt werden (Titel, gefolgt von Titelzusatz, Autor*innen, Verlag, Veröffentlichungszeiträume, Veröffentlichungsorte, Herausgebende). Mit diesem Schritt wollen wir gewährleisten, dass der produzierte Output vom LLM in seiner Form stabil bleibt und so für eine automatisierte Weiterverarbeitung geeignet ist. Die Position in der Liste gibt Auskunft darüber, um welche Kategorie es sich handelt. Die Liste ist aus der Arbeit mit Power Automate/ChatGPT entstanden. Im weiteren Verlauf des Projekts, bei dem wir uns vermehrt mit einer lokalen Anwendung auseinandersetzen, soll der generierte Output in einem von uns vordefinierten JSON-Schema erstellt werden. Der Prompt, wie er hier abgebildet ist, ist das Ergebnis vieler Tests. In dieser Variante konnten die wenigsten Fehler und die größte Stabilität verzeichnet werden.

Damit kommen wir auch schon zum letzten Block des Workflows, der Postprozessierung des Outputs. Durch ein stabiles Schema können die Daten gezielt weiterbearbeitet werden. Da das verfolgte Ziel des Projekts der Qualitätsvergleich dieser zwei LLMs ist, war es nicht essenziell, vollständige MARC21-Einträge zu erhalten. Für die manuelle Evaluierung im Testsetting wurden die Metadaten daher in Exceltabellen gespielt. Konzeptuell verfolgen wir für die Erstellung von bibliographischen Katalogdaten die Template-Strategie, bei der in definierten MARC-Vorlagen ausgewählte Felder durch den variablen Output aus einem LLM ergänzt werden (also nur einzelne Metadatenfelder mittels LLM erstellt werden, nicht der gesamte Record).

Im nächsten Schritt werden die zwei entwickelten Erschließungsansätze (Power Automate/ChatGPT und lokales Llama) im Detail vorgestellt. Der Fokus der Beschreibung verlagert sich nun auf die beiden ersten Grundblöcke unserer Workflows: die Vorprozessierung der PDFs und die Interaktion mit dem LLM.

2.2.2 Power Automate/GPT

Der Power Automate Workflow ist tief verankert im Universum von Microsoft (Sharepoint, OneDrive, Office) und diese Integration ist für den Bedienungserfolg an der Österreichischen Nationalbibliothek entscheidend.

Der Aufbau setzt sich dabei folgendermaßen zusammen. Start- und Ausgangspunkt ist ein Ordner, in unserem Fall ein Sharepoint-Ordner. Der Flow (die Ausführung) wird automatisch gestartet, wenn in diesem speziellen Ordner eine Datei erstellt (oder dorthin verschoben) wird (s. Abbildung 2).

Mit dieser Aktion wird automatisiert eine Kette von weiteren Aktionen eingeleitet. Die erste zentrale Aktion ist dabei die bereits erwähnte OCR-Lesung der Ressourcen. Der OCR-Text wird in einer Variable gespeichert und bleibt dynamisch (nach Abschluss des Flows wird der Wert durch den nächsten Flow geändert). Dabei wird Zeile für Zeile der OCR-Text des vorliegenden Dokuments zu einem Gesamttext aneinandergekettet.

Abb. 2:

Power Automate Flow (Auszug)

In einem nächsten Schritt wird der Prompt als Text-String mit der Variable des OCR-Texts ergänzt und in ein JSON gepackt. Die formalen Kriterien des JSON-Schemas für eine korrekte Interpretation des Prompts werden von Open AI vorgegeben. Der Prompt wird in besagtem Schema über einen HTTP-Post Request an die API von Open AI zu Chat GPT übermittelt. Um die API zu benützen, wird ein Key benötigt, der bei Open AI mittels Kreditkartenzahlung erworben werden kann. In diesem Schritt verlassen die Informationen das Power Automate Universum, der Input wird nun von dem ausgewählten Sprachmodell, in unserem Fall gpt-4o-2024-08-06, verarbeitet. Daraus wird eine JSON-Antwort retourniert, welche geparsed werden muss, um die relevante Information aus dem Output zu extrahieren. Um zu vermeiden, dass kreative Metadaten erstellt werden, sogenannte Halluzinationen, die nicht die vorhandenen Informationen aus dem jeweiligen OCR-Text verwenden, wurde die Temperatur des Sprachmodells auf 0 gestellt. Damit soll gewährleistet werden, dass abgeleitet vom Input ausschließlich die Antwort mit der höchsten Wahrscheinlichkeit erhalten wird.

Obgleich von Microsoft die Power-Automate-Anwendung als einfach bedienbar und auch von Nicht-Programmierenden als leicht verwendbar angepriesen wird, war ein hoher Aufwand notwendig, den Workflow in dieser Form aufzusetzen. Die bausatzartige, modulare Architektur der Anwendung ist für Neulinge, wie wir es waren, anfangs befremdlich und wenig intuitiv. Zahllose Trials and Errors waren notwendig, um die Module in Einklang zu bringen, die nach außen einfach sprechende Namen haben, aber unter der Oberfläche dann doch reguläre Programmierkenntnisse erfordern. Zusätzlich sind einige der Funktionalitäten nur durch einen Premium-Zugang erhältlich und setzen eine weitere kostenpflichtige Subskription voraus. In diesem Zusammenhang war das Einbinden von Open AI wesentlich unkomplizierter, ein Account für den API-Zugang ist notwendig und inkludiert auch ein Guthaben, das gekauft werden muss, um die Schnittstelle verwenden zu können. Von diesem Guthaben werden die Kosten von Anfragen (Input) und die generierten Antworten (Output) abgezogen.

Ist aber der Power Automate Flow einmal aufgesetzt und funktionsfähig, erlaubt die vollständige Automatisierung ein sehr flüssiges Arbeiten. In anderen Worten, funktioniert der Ablauf, werden Dateien in den Ordner verschoben und einige Augenblicke später wird das Ergebnis automatisch in die Excel-Liste eingetragen. Power Automate operiert im Hintergrund und muss für die Verwendung nicht aktiv bedient werden. Einer der Vorteile, der daraus entsteht, ist, dass Mitarbeitende somit leicht automatisiert Metadateien extrahieren können. Das Einzige, das gemacht werden muss, ist eine Datei in einen Ordner zu geben – der Kontakt mit der KI erfolgt im Hintergrund und ist, abgesehen von den Ergebnissen, nicht wahrnehmbar.

2.2.3 Lokales LLM: Llama-3.1-8B-Instruct

Der zweite Ansatz, der im Projekt umgesetzt wurde, versucht sich aus dem Microsoft/OpenAI Universum zu entfernen und ein lokales, deutlich kleineres Sprachmodell für die Metadatenextraktion zu verwenden. Dies war nur teilweise möglich, da zu diesem Zeitpunkt einige Komponenten, beispielsweise die OCR, Probleme darstellten, deren Lösung wir nicht innerhalb des Projekts verorteten. Aus diesem Grund, sowie dem Wunsch der Vergleichbarkeit der Ergebnisse wurde der Abschnitt der OCR-Lesung für das lokales LLM aus dem Power Automate Workflow verwendet. Der OCR-Text wurde in einer simplen Textdatei gespeichert.

Abb. 3:

Dialogerstellung bei Llama-3.1-8B

Abb. 4:

Übergabe des Dialogs an die Chat Completion

Aufgrund von Erfahrungsberichten anderer Bibliotheken^[9] mit lokalen LLMs ist unsere Entscheidung auf die Llama-Familie von Meta gefallen. Nachdem die ÖNB eine GPU zur Verfügung hat, waren die technischen Gegebenheiten der GPU als auch das Leitmotiv „use the smallest AI that works“^[10] für die LLM-Größe von 8 Milliarden Parameter ausschlaggebend. Der von Meta zur Verfügung gestellte Code für die Interaktion (in unserem Fall Chat Completion) mit dem LLM wurde von uns so adaptiert, dass es vom Prinzip gleich funktioniert wie der Workflow mit GPT. Der OCR-Text wird in der Dialogfunktion mit dem Prompt an das LLM übergeben und die generierten Antworten in eine Excel-Liste gespielt. Über eine Vorschleife werden die OCR-Texte (Variablenname txtStr) und deren Dateiname in eine Dialogliste gespeist (s. Abbildung 3).

Auch in diesem Dialog gibt es einen statischen Teil, der stets dieselbe Aufforderung der Metadatenextraktion enthält und einen dynamischen Teil (OCR-Text= txtStr), der jedes Mal durch eine neue Datei ersetzt wird. Das dahinterliegende Prinzip ist also bei beiden LLMs ident. Durch eine weitere Vorschleife (s. Abbildung 4) werden die einzelnen Dialoge für jede Datei über die Chat Completion vom Sprachmodell verwendet.

Ohne die Unterstützung der Softwareentwickelnden und Programmierenden der ÖNB hätten wir diesen Schritt nicht umsetzen können. Die technischen Gegebenheiten der GPU mit lokalem Host stellten für uns eine neue und ungewohnte Umgebung dar, deren Spielregeln wir nur sukzessive zu verstehen lernten. Das führte auch dazu, den Fokus auf die Vorprozessierung der Dateien, bzw. Postprozessierung des LLM-Outputs zu lenken. Nachdem hier jeder Schritt der Verarbeitung von uns begleitet wird, ist der Grad der Involvierung sehr hoch (mit dem positiven Effekt, dass die Lernkurve des technischen Verständnisses stark angestiegen ist). Gleichzeitigt bedeutet diese Involvierung auch einen hohen Grad an zeitintensiver Betreuung. Der Workflow ist noch stark prototypisch, die Verwendung durch andere Mitarbeitende nur eingeschränkt zielführend. Außerdem muss gesagt werden, dass der Automatisierungsgrad bei dieser Pipeline noch in den Kinderschuhen steckt und viele Arbeitsstunden notwendig sind, Abläufe zu streamlinen.

2.2.4 Testmethode und Evaluierung

Das Testdatenset von 200 elektronischen Publikationen wurde in zehn Pakete von je 20 Dokumenten aufgeteilt. In der ersten Testphase war für uns relevant, nicht nur herauszufinden, wie akkurat die jeweiligen Metadaten sind, sondern auch welche Arten von Fehlern bei der maschinellen Erschließung häufig auftreten können. Zur Erinnerung: Die folgenden Metadatenkategorien wurden erfragt: Titel, Titelzusatz, Autor*innen, Verlag, Veröffentlichungszeitraum, Veröffentlichungsort und Herausgebende.

Grob teilen wir die Fehlerbereiche in zwei Kategorien auf: inhaltliche Fehler und Fehler der Zeichensetzung. Unter inhaltlichen Fehlern verstehen wir qualitative Aspekte in Bezug auf den Gesamtinhalt der sieben Metadatenkategorien. So sollte bei fehlerhaften Metadaten pro Metadatenkategorie angemerkt werden, um welche Art Fehler es sich handelte: leerer Inhalt (1), doppelter Inhalt (2), falscher Inhalt (3), falsche Zuweisung (4), Halluzination (5), OCR-Fehler (6), unvollständiger Inhalt (7). Pro Metadatenfeld kann nur eine Kategorie gewählt werden.

Ein leerer Inhalt (1) geht davon aus, dass eine Kategorie nicht befüllt wurde, während ein falscher Inhalt (3) zusammenfasst, wo tatsächlich inkorrekte Inhalte angeführt wurden. Ein unvollständiger Inhalt (7) wurde dann ausgewählt, wenn z. B. nur Teile des Titels erfasst wurden oder auch nicht alle Autor*innen genannt wurden. Eine falsche Zuweisung (4) sollte gewählt werden, wenn Metadaten zwar richtig erkannt wurden, aber nicht den richtigen Metadatenkategorien zugewiesen wurden. Ein klassisches Beispiel wäre die Unterscheidung zwischen Titel und Untertitel oder Autor*in und Herausgebende. Da die Evaluierungsmethode vor den ersten Testergebnissen festgelegt wurde, wurden auch Fehlerarten antizipiert, die so tatsächlich nicht oder kaum vorgefallen sind, wie zum Beispiel der doppelte Inhalt (2) oder die Halluzination (5).

Bei den Fehlern in der Zeichensetzung wurde nicht mehr unterschieden, bei welchen Kategorien Abweichungen auftraten, dafür welche Art an Fehlern auf Zeichenebene allgemein wie häufig vorkommt. Dazu wurden vier Ebenen evaluiert: Buchstaben (a), Groß-/Kleinschreibung (b), Leerzeichen (c), Sonderzeichen (d). Während entgegen der Antizipation auf graphematischem Level (a, b) kaum Fehler zu verzeichnen waren, wurde hinsichtlich der Leer- und Sonderzeichen (c, d) untersucht, inwiefern Interpunktion und andere typografische Zeichen bei der maschinellen Erschließung relevant sind. An dieser Stelle sei angemerkt, dass hierbei besondere bibliothekarische Sonderzeichen, wie die ISBD-Zeichensetzung, nicht als fehlerhaft markiert wurden, sollten diese gefehlt haben. Prinzipiell sollte sich das Thema Zeichensetzung allerdings als ein vernachlässigbares hinsichtlich der Evaluierung herausstellen.

Es handelt sich also um ein ausgeklügeltes System einer qualitativen Evaluierung. Da wir nicht alle Kategorien vorhersehen konnten, gab es zudem die Möglichkeit unerwartete Fehler oder allgemeine Kommentare zu notieren. Zusammenfassend wollten wir wissen, wie viele Dokumente vollständig korrekt erschlossen wurden, wie viele nicht – und darunter, bei wie vielen Dokumenten welche Fehlerarten bei welchen Metadatenkategorien am häufigsten vorkamen.

2.2.5 Ergebnisse und Interpretation

Bei der Zeichensetzung konnten wir beobachten, dass beide Ansätze ähnlich gute Ergebnisse liefern – und kaum Fehler auftraten. Bei GPT wurden nur 27 fehlerhafte Datensätze markiert, bei Llama waren es doppelt so viele. Die Zeichensetzung sollte sich jedoch in der Evaluierung als vernachlässigbare Kategorie erweisen und wird auch im Folgenden nicht weiter beachtet.

Auf inhaltlicher Ebene konnten GPT 50 und Meta Llama 25 vollständig korrekte Datensätze erstellen – von 200 Dokumenten. Das bedeutet im Umkehrschluss, dass GPT in 75 % aller Fälle mindestens einen Fehler in einer Kategorie eingebaut hat und Llama sogar in 88 %. Wir wollten in weiterer Folge wissen, wie gravierend die Fehler der fehlerhaften Metadaten waren – sind sie im Sinne einer Katalogisierungsunterstützung noch brauchbar oder nicht? Dabei beträgt die durchschnittliche Fehleranzahl auf inhaltlicher Ebene 1,58 bei GPT und 2,46 bei Meta Llama.

Werfen wir einen Blick auf die Kategorie „Titel“ (s. Abbildung 5), so wird sofort sichtbar, dass sowohl GPT als auch Llama annähernd ähnlich oft (GPT 125, Llama 104) den Titel richtig erkannt haben. Die meisten Fehler finden wir bei falschen Inhalten (Llama 62, GPT 27), leeren Inhalten (GPT 25, LLama 2), unvollständigen Inhalten (Llama 16, GPT 12) und falschen Zuweisungen (Llama 12, GPT 9).

Abb. 5:

Fehleranalyse Kategorie „Titel“

Untersuchen wir hingegen die erfassten Autor*innen, die geistigen Schöpfer*innen, so können wir die Aussage treffen, dass die erstellten Angaben überwiegend korrekt sind (GPT 158, Llama 136). In wenigen Fällen werden an dieser Stelle Fehler produziert – zu den häufigsten Fehlerkategorien gehören hier der leere Inhalt im Falle von GPT (24 Dokumente) und die falsche Zuweisung bei Llama (22 Fälle).

Wir konnten durch unsere Evaluierungsmethode durchaus feststellen, wie unterschiedlich Metadatenfelder durch die einzelnen Ansätze erfasst wurden und worin die häufigsten Fehlerquellen bestanden. Auch wenn es zu Fehlern kommt und die gewonnenen Metadaten nicht den derzeitigen intellektuellen Erfassungsstandards entsprechen, so können trotzdem maschinell Metadaten extrahiert werden, die im Sinne einer Katalogisierungsunterstützung intellektuell weiterverarbeitet werden können.

Abb. 6:

Fehleranalyse Kategorie „Autor*innen“

2.2.6 Daraus abgeleitete Konsequenzen für Phase 2

Aus dieser Testrunde haben wir erste Konsequenzen, auch in Bezug auf unsere Arbeitshypothesen, abgeleitet: (1) Das lokale, deutlich kleinere Sprachmodell liefert gegenüber GPT an vielen Stellen stabile Ergebnisse und zeigt das Potenzial für bessere Ergebnisse durch ein Finetuning. (2) Die Kombination von Power Automate und GPT kann, wenn sie erst einmal aufgesetzt ist, ein unterstützendes Tool für die Erschließung darstellen. Rechtliche und technische Barrieren beschränken das Einsatzgebiet vorerst. (3) Unterschiedliche Anwendungsgebiete verlangen unterschiedliche Lösungen – es gibt nicht den einen KI-unterstützten Ansatz, sondern eine Vielzahl, abhängig nach den Bedürfnissen und Anforderungen, die daran gestellt werden.

2.3.1 Feinabstimmung mit QLoRA

Mithilfe von QLoRA^[11] adaptieren wir ein LLM,^[12] um formale Metadaten aus PDFs zu extrahieren. QLoRA ist eine effiziente Methode zur Adaption von LLMs unter Berücksichtigung von Ressourcenbeschränkungen. Dies wird erreicht, indem das zu adaptierende LLM dabei unverändert bleibt und nur die Parameter kleiner hinzugefügter Module, der so genannten Adapters, beim Training gelernt werden müssen. In unserem Fall kann so die Anzahl der zu trainierenden Parameter auf ca. 0,5 % des Basismodells reduziert werden.

Als Datenbasis für das Training dienen 2 521 PDFs und die entsprechenden von Erschließer*innen erstellten Metadaten. Wir extrahieren den Textinhalt der PDFs und beschneiden lange Texte. Es sei betont, dass keine OCR stattfindet. Alle vor dem Jahr 2025 erstellten Datensätze dienen als Trainingsdaten (2 381), wohingegen wir alle neueren Datensätze als Testdaten (140) nutzen.

Wir leiten das Basismodell mittels one-shot prompting^[13] an, die Metadaten als JSON nach einem bestimmten Schema zu extrahieren. Zusätzlich beschränken wir bei der Extraktion der Metadaten aus den Testdaten das LLM darauf, JSON nach eben diesem Schema zu generieren.^[14] Wir trainieren für lediglich 5 Epochen, da die Verlustkurve bereits stark abflacht.

Wir evaluieren die erstellten Metadaten anhand des Anteils richtig extrahierter Felder, abzüglich der Anzahl zusätzlicher Felder, die nicht in den von Erschließer*innen erstellten Metadaten enthalten sind. Hervorzuheben ist, dass in dieser Form der Evaluation bereits kleine Fehler (z. B. fehlende Punktuation, fehlerhafte Normalisierung) dazu führen, dass das gesamte Feld als falsch gewertet wird. Das auf die Extraktionsaufgabe adaptierte LLM schneidet deutlich besser ab (51 % korrekt extrahierte Felder) als das Basismodell ohne Adaption (19 % korrekt extrahierte Felder). Hauptgründe für die hohe Fehlerquote des Basismodells und damit zugleich für den Unterschied zum adaptierten Modell liegen in der fehlenden Normalisierung von Namen und der Extraktion von zusätzlichen Feldern, die zwar faktisch korrekt sind, jedoch nicht in den von Erschließer*innen erstellten Metadaten vertreten sind.

2.3.2 Ausblick: nächste Schritte und weitere Phasen

Die zweite Projektphase im Jahr 2025 sollte neben der Verbesserung der Leistung eines lokalen LLMs untersuchen, ob die beiden Ansätze (oder auch andere maschinelle Verfahren) auch für andere Erschließungsszenarien unterstützend eingesetzt werden können. An der Österreichischen Nationalbibliothek werden Inhaltsverzeichnisse von Sammelbänden, aber auch von wissenschaftlichen Zeitschriften, gescannt („IV-SCAN“) und mit den darin enthaltenen Informationen Artikeldatensätze erstellt. Aufgrund der Diversität der Layouts dieser Inhaltsverzeichnisse wird intellektuell stark eingegriffen.

Erste Tests mit Power Automate/GPT haben ergeben, dass gerade bei einspaltigen Inhaltsverzeichnissen sowohl die OCR-Lesung als auch die Metadatenextraktion und -kategorisierung funktioniert. Im weiteren Projektverlauf wird der automatisierte Workflow dahingehend ausgebaut, um sowohl bei Retroprojekten der Zeitschriftenerschließung als auch im operativen Tagesgeschehen aktiv einsetzbar zu sein.

Das Potenzial zur maschinellen bzw. automationsunterstützten Erschließung sehen wir auch bei weiteren Ressourcenarten und Beständen der Österreichischen Nationalbibliothek. Formale Metadaten zu extrahieren, diese in den Katalog zu integrieren und damit eine Zugänglichkeit der Dokumente überhaupt zu ermöglichen, ist das primäre Ziel. Qualitativ hochwertige, mit Normdaten angereicherte und klassifizierte bzw. beschlagwortete Datensäte mithilfe maschineller Unterstützung zu erstellen, ist ein langfristiges Ziel, das in Folgeprojekten erarbeitet wird.