Fix citation placement in Facharbeit text

docs/Facharbeit.typ

@@ -29,9 +29,9 @@ Im persönlichen wie im akademischen Kontext wird Tagging häufig dennoch manuel
 
 == Problemstellung
 
-Aus informationswissenschaftlicher Sicht handelt es sich bei der automatisierten Verschlagwortung um ein Klassifikationsproblem, das mehrere Schwierigkeiten gleichzeitig vereint. Erstens liegt häufig keine große, sauber annotierte Trainingsmenge vor. Zweitens sind die zu klassifizierenden Texte oft kurz, unvollständig oder sprachlich informell. Drittens sollen die vergebenen Tags nicht flach, sondern in einer hierarchischen Struktur organisiert werden, damit sowohl grobe als auch spezifische Themenbereiche abbildbar sind. Eine Ressource kann zudem mehreren Kategorien gleichzeitig zugeordnet werden, wodurch ein Multi-Label-Szenario entsteht @liu2023.
+Aus informationswissenschaftlicher Sicht handelt es sich bei der automatisierten Verschlagwortung um ein Klassifikationsproblem, das mehrere Schwierigkeiten gleichzeitig vereint. Erstens liegt häufig keine große, sauber annotierte Trainingsmenge vor. Zweitens sind die zu klassifizierenden Texte oft kurz, unvollständig oder sprachlich informell. Drittens sollen die vergebenen Tags nicht flach, sondern in einer hierarchischen Struktur organisiert werden, damit sowohl grobe als auch spezifische Themenbereiche abbildbar sind. Eine Ressource kann zudem mehreren Kategorien gleichzeitig zugeordnet werden, wodurch ein Multi-Label-Szenario nach Liu et al. @liu2023 entsteht.
 
-Klassische Verfahren des Machine Learning erzielen in klar umrissenen Anwendungsfällen zwar gute Ergebnisse, erfordern aber typischerweise eine vorgängige Merkmalsrepräsentation, Trainingsdaten und eine stabile Problemdefinition @manning2008. Im vorliegenden Projekt liegt die Herausforderung anders: Es existiert bereits ein hierarchischer Tag-Baum, doch es fehlt an umfangreich annotierten Beispielen für das Training eines speziellen Modells. Gleichzeitig soll das System in der Lage sein, auch für neue oder nur teilweise passende Inhalte sinnvolle Vorschläge zu machen. Daraus ergibt sich die zentrale Problemstellung, wie eine praktische, robuste und nachvollziehbare automatische Verschlagwortung unter realen Projektbedingungen umgesetzt werden kann.
+Klassische Verfahren des Machine Learning erzielen nach Manning, Raghavan und Schütze @manning2008 in klar umrissenen Anwendungsfällen zwar gute Ergebnisse, erfordern aber typischerweise eine vorgängige Merkmalsrepräsentation, Trainingsdaten und eine stabile Problemdefinition. Im vorliegenden Projekt liegt die Herausforderung anders: Es existiert bereits ein hierarchischer Tag-Baum, doch es fehlt an umfangreich annotierten Beispielen für das Training eines speziellen Modells. Gleichzeitig soll das System in der Lage sein, auch für neue oder nur teilweise passende Inhalte sinnvolle Vorschläge zu machen. Daraus ergibt sich die zentrale Problemstellung, wie eine praktische, robuste und nachvollziehbare automatische Verschlagwortung unter realen Projektbedingungen umgesetzt werden kann.
 
 == Zielsetzung und Forschungsfrage
 
@@ -43,7 +43,7 @@ Die leitende Forschungsfrage lautet daher: Inwieweit eignen sich Large Language
 
 == Informationsretrieval und Metadaten
 
-Informationsretrieval bezeichnet den Bereich der Informatik und Informationswissenschaft, der sich mit der Speicherung, Strukturierung, Suche und Wiederauffindung von Informationen beschäftigt. Anders als bei klassischen Datenbanksystemen stehen dabei häufig un- oder halbstrukturierte Inhalte im Mittelpunkt, etwa Texte, Webseiten oder Dokumente. Ziel ist es, aus einer größeren Informationsmenge diejenigen Elemente zu identifizieren, die für eine Anfrage oder einen Nutzungskontext relevant sind @manning2008. Für die Qualität eines Retrieval-Systems ist daher nicht allein entscheidend, ob Inhalte vorhanden sind, sondern ob sie in einer Form beschrieben werden, die ihre spätere Auffindbarkeit unterstützt.
+Informationsretrieval bezeichnet den Bereich der Informatik und Informationswissenschaft, der sich mit der Speicherung, Strukturierung, Suche und Wiederauffindung von Informationen beschäftigt. Anders als bei klassischen Datenbanksystemen stehen dabei häufig un- oder halbstrukturierte Inhalte im Mittelpunkt, etwa Texte, Webseiten oder Dokumente. Ziel ist es, nach Manning, Raghavan und Schütze @manning2008 aus einer größeren Informationsmenge diejenigen Elemente zu identifizieren, die für eine Anfrage oder einen Nutzungskontext relevant sind. Für die Qualität eines Retrieval-Systems ist daher nicht allein entscheidend, ob Inhalte vorhanden sind, sondern ob sie in einer Form beschrieben werden, die ihre spätere Auffindbarkeit unterstützt.
 
 Metadaten übernehmen in diesem Zusammenhang eine zentrale Rolle. Sie beschreiben Ressourcen durch zusätzliche Merkmale wie Titel, Autor, Thema, Entstehungszeitpunkt oder Schlagwörter. Solche beschreibenden Informationen schaffen eine zweite Ebene über dem eigentlichen Inhalt und ermöglichen es, Dokumente nicht nur wortwörtlich, sondern auch semantisch oder organisatorisch zu erschließen. In digitalen Wissenssammlungen sind Tags eine besonders flexible Form solcher Metadaten: Sie können thematische Zuordnungen herstellen, Querverbindungen sichtbar machen und den Übergang zwischen freier Sammlung und systematischer Ordnung erleichtern.
 
@@ -51,7 +51,7 @@ Gerade für heterogene Ressourcensammlungen sind Metadaten wichtig, weil Inhalte
 
 == Tagging-Systeme und ihre Herausforderungen
 
-Tagging-Systeme ordnen Ressourcen Schlagwörter zu, um sie thematisch zu gruppieren und leichter auffindbar zu machen. Im Unterschied zu streng kontrollierten Vokabularen oder Taxonomien sind Tags oft flexibel, offen und nutzergetrieben. Diese Offenheit ist praktisch, weil neue Begriffe schnell eingeführt werden können und Nutzerinnen und Nutzer ihre eigene Sicht auf Inhalte abbilden können. Gleichzeitig entstehen dadurch typische Probleme, etwa uneinheitliche Schreibweisen, Synonyme, Mehrdeutigkeiten und stark schwankende Detailgrade @guy2006.
+Tagging-Systeme ordnen Ressourcen Schlagwörter zu, um sie thematisch zu gruppieren und leichter auffindbar zu machen. Im Unterschied zu streng kontrollierten Vokabularen oder Taxonomien sind Tags oft flexibel, offen und nutzergetrieben. Diese Offenheit ist praktisch, weil neue Begriffe schnell eingeführt werden können und Nutzerinnen und Nutzer ihre eigene Sicht auf Inhalte abbilden können. Gleichzeitig entstehen dadurch nach Guy und Tonkin @guy2006 typische Probleme, etwa uneinheitliche Schreibweisen, Synonyme, Mehrdeutigkeiten und stark schwankende Detailgrade.
 
 Eine Ressource über Programmiersprachen könnte beispielsweise mit `rust`, `systems_programming`, `compiler`, `memory` oder `performance` markiert werden. Jede dieser Bezeichnungen ist potenziell sinnvoll, doch nicht jede repräsentiert dieselbe Ebene oder denselben Fokus. Ohne Strukturierung entstehen Sammlungen, in denen Tags nebeneinanderstehen, obwohl sie hierarchisch oder semantisch miteinander verbunden sind. Für Retrieval-Aufgaben ist das problematisch, weil die Suche entweder zu breit oder zu eng ausfallen kann.
 
@@ -59,37 +59,37 @@ Im vorliegenden Projekt wird deshalb kein flaches Tagging verwendet, sondern ein
 
 == Klassische Verfahren des Machine Learning
 
-Vor dem Aufkommen großer Sprachmodelle wurde die automatische Textklassifikation überwiegend mit klassischen Verfahren des Machine Learning umgesetzt. Diese Methoden basieren meist auf einer expliziten Merkmalsdarstellung von Texten, etwa durch Worthäufigkeiten, und einem darauf trainierten Klassifikator. Sie sind rechnerisch oft effizient und in gut definierten Szenarien leistungsfähig. Ihr Erfolg hängt aber stark davon ab, wie gut Texte vorverarbeitet, Merkmale ausgewählt und Trainingsdaten gelabelt wurden @manning2008.
+Vor dem Aufkommen großer Sprachmodelle wurde die automatische Textklassifikation überwiegend mit klassischen Verfahren des Machine Learning umgesetzt. Diese Methoden basieren meist auf einer expliziten Merkmalsdarstellung von Texten, etwa durch Worthäufigkeiten, und einem darauf trainierten Klassifikator. Sie sind rechnerisch oft effizient und in gut definierten Szenarien leistungsfähig. Ihr Erfolg hängt nach Manning, Raghavan und Schütze @manning2008 aber stark davon ab, wie gut Texte vorverarbeitet, Merkmale ausgewählt und Trainingsdaten gelabelt wurden.
 
 Für das Verständnis der späteren LLM-basierten Lösung ist ein kurzer Blick auf die zentralen klassischen Ansätze sinnvoll. Besonders relevant sind Bag-of-Words- und TF-IDF-Repräsentationen als Grundlage, Naive Bayes als probabilistisches Verfahren und Support Vector Machines als starke lineare Klassifikatoren für hochdimensionale Textdaten.
 
 === Bag-of-Words und TF-IDF
 
-Beim Bag-of-Words-Ansatz wird ein Text als ungeordnete Menge von Wörtern modelliert. Entscheidend ist dabei nicht die genaue Wortreihenfolge, sondern welche Terme vorkommen und mit welcher Häufigkeit. Auf diese Weise lässt sich jeder Text in einen Vektor überführen, dessen Dimensionen einzelnen Wörtern oder Token entsprechen. Das Verfahren ist konzeptionell einfach und für viele frühe Textklassifikationssysteme grundlegend gewesen @manning2008.
+Beim Bag-of-Words-Ansatz wird ein Text als ungeordnete Menge von Wörtern modelliert. Entscheidend ist dabei nicht die genaue Wortreihenfolge, sondern welche Terme vorkommen und mit welcher Häufigkeit. Auf diese Weise lässt sich jeder Text in einen Vektor überführen, dessen Dimensionen einzelnen Wörtern oder Token entsprechen. Das Verfahren ist nach Manning, Raghavan und Schütze @manning2008 konzeptionell einfach und für viele frühe Textklassifikationssysteme grundlegend gewesen.
 
-Eine wichtige Verfeinerung stellt TF-IDF dar, also die Gewichtung durch Term Frequency und Inverse Document Frequency. Häufige Begriffe innerhalb eines Dokuments werden stärker gewichtet, während Wörter, die in nahezu allen Dokumenten vorkommen, an Bedeutung verlieren. Dadurch wird die Repräsentation informativer, weil charakteristische Begriffe stärker hervortreten. Salton und Buckley zeigen, dass unterschiedliche Gewichtungsschemata erheblichen Einfluss auf Retrieval- und Klassifikationsergebnisse haben können @salton1988.
+Eine wichtige Verfeinerung stellt TF-IDF dar, also die Gewichtung durch Term Frequency und Inverse Document Frequency. Häufige Begriffe innerhalb eines Dokuments werden stärker gewichtet, während Wörter, die in nahezu allen Dokumenten vorkommen, an Bedeutung verlieren. Dadurch wird die Repräsentation informativer, weil charakteristische Begriffe stärker hervortreten. Salton und Buckley @salton1988 zeigen, dass unterschiedliche Gewichtungsschemata erheblichen Einfluss auf Retrieval- und Klassifikationsergebnisse haben können.
 
 Trotz ihres Nutzens bleibt die Repräsentation jedoch überwiegend oberflächenorientiert. Zwei inhaltlich ähnliche Texte können sehr unterschiedlich erscheinen, wenn sie unterschiedliche Vokabeln verwenden. Umgekehrt können Texte mit ähnlichen Begriffen thematisch verschieden sein. Genau diese Begrenzung wird bei kurzen und kontextabhängigen Ressourcen besonders sichtbar.
 
 === Naive Bayes
 
-Naive Bayes ist ein probabilistisches Klassifikationsverfahren, das auf dem Satz von Bayes beruht und die Merkmale eines Dokuments als bedingt unabhängig voneinander annimmt. Diese Annahme ist in realen Texten zwar stark vereinfacht, führt in der Praxis jedoch häufig zu brauchbaren und robusten Ergebnissen. Vor allem in frühen Anwendungen der Dokumentklassifikation war Naive Bayes wegen seiner Einfachheit und Effizienz weit verbreitet @manning2008.
+Naive Bayes ist ein probabilistisches Klassifikationsverfahren, das auf dem Satz von Bayes beruht und die Merkmale eines Dokuments als bedingt unabhängig voneinander annimmt. Diese Annahme ist in realen Texten zwar stark vereinfacht, führt in der Praxis jedoch häufig zu brauchbaren und robusten Ergebnissen. Vor allem in frühen Anwendungen der Dokumentklassifikation war Naive Bayes nach Manning, Raghavan und Schütze @manning2008 wegen seiner Einfachheit und Effizienz weit verbreitet.
 
-Für Textdaten existieren unterschiedliche Ereignismodelle, insbesondere multinomiale und Bernoulli-Varianten. McCallum und Nigam zeigen, dass die Wahl des Ereignismodells die Klassifikationsleistung deutlich beeinflussen kann und dokumentieren die Eignung von Naive Bayes für Textklassifikation trotz der starken Unabhängigkeitsannahme @mccallum1998. Die Stärke des Verfahrens liegt darin, mit vergleichsweise wenig Rechenaufwand Wahrscheinlichkeiten für Klassen zu schätzen.
+Für Textdaten existieren unterschiedliche Ereignismodelle, insbesondere multinomiale und Bernoulli-Varianten. McCallum und Nigam @mccallum1998 zeigen, dass die Wahl des Ereignismodells die Klassifikationsleistung deutlich beeinflussen kann und dokumentieren die Eignung von Naive Bayes für Textklassifikation trotz der starken Unabhängigkeitsannahme. Die Stärke des Verfahrens liegt darin, mit vergleichsweise wenig Rechenaufwand Wahrscheinlichkeiten für Klassen zu schätzen.
 
 Für komplexe Tagging-Systeme stößt Naive Bayes jedoch an Grenzen. Die Methode modelliert keine tieferen semantischen Beziehungen zwischen Begriffen und bildet Kontext nur indirekt über Worthäufigkeiten ab. Gerade bei mehrdeutigen oder sehr kurzen Texten kann das zu unscharfen Zuordnungen führen.
 
 === Support Vector Machines
 
-Support Vector Machines, kurz SVM, gehören zu den klassischen Verfahren, die für Textklassifikation lange als besonders leistungsfähig galten. Ihr Grundprinzip besteht darin, im Merkmalsraum eine trennende Hyperebene zu finden, die Klassen möglichst gut voneinander separiert. Gerade in hochdimensionalen, spärlich besetzten Textvektoren funktioniert dieser Ansatz oft zuverlässig, weil viele Dokumente trotz großer Vokabularräume linear trennbar oder nahezu trennbar sind @joachims2002.
+Support Vector Machines, kurz SVM, gehören zu den klassischen Verfahren, die für Textklassifikation lange als besonders leistungsfähig galten. Ihr Grundprinzip besteht darin, im Merkmalsraum eine trennende Hyperebene zu finden, die Klassen möglichst gut voneinander separiert. Gerade in hochdimensionalen, spärlich besetzten Textvektoren funktioniert dieser Ansatz nach Joachims @joachims2002 oft zuverlässig, weil viele Dokumente trotz großer Vokabularräume linear trennbar oder nahezu trennbar sind.
 
-Für Textklassifikation ist die Methode deshalb attraktiv, weil sie mit TF-IDF- oder ähnlichen Repräsentationen gut kombinierbar ist. Joachims zeigt, dass SVMs in diesem Bereich hohe Genauigkeit erreichen und insbesondere bei großen Merkmalsräumen robust arbeiten @joachims2002. Im Vergleich zu einfacheren Verfahren wie Naive Bayes ist das Modell jedoch schwerer interpretierbar und erfordert ebenfalls annotierte Trainingsdaten.
+Für Textklassifikation ist die Methode deshalb attraktiv, weil sie mit TF-IDF- oder ähnlichen Repräsentationen gut kombinierbar ist. Joachims @joachims2002 zeigt, dass SVMs in diesem Bereich hohe Genauigkeit erreichen und insbesondere bei großen Merkmalsräumen robust arbeiten. Im Vergleich zu einfacheren Verfahren wie Naive Bayes ist das Modell jedoch schwerer interpretierbar und erfordert ebenfalls annotierte Trainingsdaten.
 
 Auch SVMs lösen nicht das Grundproblem fehlender Semantik. Sie trennen Klassen auf Basis der vorgegebenen Merkmalsdarstellung, erzeugen diese Darstellung aber nicht selbst. Wenn relevante Inhalte in einem Text implizit bleiben oder nur durch Weltwissen erschließbar sind, kann auch ein starker Klassifikator nur begrenzt helfen.
 
 == Grenzen klassischer Ansätze
 
-Die beschriebenen Verfahren haben wesentlich zur Entwicklung moderner Textklassifikation beigetragen, doch ihre Grenzen werden im Kontext dieser Arbeit deutlich. Erstens setzen sie in der Regel ein gelabeltes Korpus voraus. Für ein persönliches oder projektbezogenes Tagging-System liegt ein solches Korpus häufig nicht vor, und seine Erstellung wäre zeitaufwendig. Zweitens hängen klassische Verfahren stark von der Qualität der Merkmalsrepräsentation ab. Werden Synonyme, Mehrdeutigkeiten oder thematische Beziehungen nicht bereits in den Merkmalen erfasst, kann das Modell sie kaum nachträglich rekonstruieren @manning2008.
+Die beschriebenen Verfahren haben wesentlich zur Entwicklung moderner Textklassifikation beigetragen, doch ihre Grenzen werden im Kontext dieser Arbeit deutlich. Erstens setzen sie in der Regel ein gelabeltes Korpus voraus. Für ein persönliches oder projektbezogenes Tagging-System liegt ein solches Korpus häufig nicht vor, und seine Erstellung wäre zeitaufwendig. Zweitens hängen klassische Verfahren nach Manning, Raghavan und Schütze @manning2008 stark von der Qualität der Merkmalsrepräsentation ab. Werden Synonyme, Mehrdeutigkeiten oder thematische Beziehungen nicht bereits in den Merkmalen erfasst, kann das Modell sie kaum nachträglich rekonstruieren.
 
 Hinzu kommt, dass kurze Social-Media-Texte oft nur bruchstückhafte Informationen enthalten. Ein Beitrag kann auf eine Debatte verweisen, implizites Fachwissen voraussetzen oder wesentliche Teile seiner Bedeutung aus Links, Autorenschaft und Diskurskontext beziehen. Ein Bag-of-Words-Modell sieht in einem solchen Fall nur wenige Terme. Für die Auswahl eines spezifischen Tags innerhalb einer Hierarchie ist dies oft nicht ausreichend.
 
@@ -99,25 +99,25 @@ Schließlich ist das Ziel dieses Projekts nicht die Vorhersage genau einer Klass
 
 === Grundprinzipien und Training
 
-Large Language Models sind neuronale Sprachmodelle, die auf sehr großen Textmengen vortrainiert werden und auf dieser Grundlage statistische Regularitäten von Sprache, Wissen und typischen Textmustern erfassen. Im Kern lernen sie, welches Token mit welcher Wahrscheinlichkeit auf einen gegebenen Kontext folgt. Durch die enorme Menge an Trainingsdaten und Parametern entstehen Modelle, die nicht nur lokale Wortfolgen, sondern auch komplexere sprachliche und semantische Zusammenhänge verarbeiten können @bommasani2021.
+Large Language Models sind neuronale Sprachmodelle, die auf sehr großen Textmengen vortrainiert werden und auf dieser Grundlage statistische Regularitäten von Sprache, Wissen und typischen Textmustern erfassen. Im Kern lernen sie, welches Token mit welcher Wahrscheinlichkeit auf einen gegebenen Kontext folgt. Durch die enorme Menge an Trainingsdaten und Parametern entstehen nach Bommasani et al. @bommasani2021 Modelle, die nicht nur lokale Wortfolgen, sondern auch komplexere sprachliche und semantische Zusammenhänge verarbeiten können.
 
 Der entscheidende Unterschied zu klassischen Textklassifikationsverfahren liegt darin, dass LLMs nicht speziell für eine einzelne Klassifikationsaufgabe trainiert werden müssen, um nützliche Ergebnisse zu liefern. Vielmehr können sie durch Anweisungen im Prompt auf neue Aufgaben ausgerichtet werden. Diese Fähigkeit macht sie insbesondere für Szenarien interessant, in denen keine große, sauber annotierte Trainingsmenge vorhanden ist, aber dennoch eine inhaltlich differenzierte Beurteilung nötig ist.
 
 === Transformer-Architektur (konzeptionell)
 
-Die gegenwärtige Leistungsfähigkeit großer Sprachmodelle ist eng mit der Transformer-Architektur verbunden. Vaswani et al. führen mit dem Transformer ein Modell ein, das auf Self-Attention basiert und dadurch Abhängigkeiten zwischen Wörtern eines Textes parallel und kontextsensitiv verarbeiten kann @vaswani2017. Anstatt Wörter nur sequenziell zu betrachten, gewichtet das Modell, welche Teile des Eingabetextes für die Interpretation eines bestimmten Tokens besonders relevant sind.
+Die gegenwärtige Leistungsfähigkeit großer Sprachmodelle ist eng mit der Transformer-Architektur verbunden. Vaswani et al. @vaswani2017 führen mit dem Transformer ein Modell ein, das auf Self-Attention basiert und dadurch Abhängigkeiten zwischen Wörtern eines Textes parallel und kontextsensitiv verarbeiten kann. Anstatt Wörter nur sequenziell zu betrachten, gewichtet das Modell, welche Teile des Eingabetextes für die Interpretation eines bestimmten Tokens besonders relevant sind.
 
 Konzeptionell ist diese Architektur für Textklassifikation deshalb bedeutsam, weil sie Beziehungen über größere Distanzen hinweg erfassen kann. Wenn in einem Text erst spät klar wird, worauf sich ein Begriff bezieht, kann ein Transformer diese Information besser einbeziehen als klassische Modelle mit starren Vektorrepräsentationen. Für die hier betrachtete Aufgabe bedeutet das, dass nicht nur einzelne Schlüsselwörter, sondern auch ihre Einbettung in den Gesamtzusammenhang berücksichtigt werden können.
 
 === Semantisches Verständnis und Kontext
 
-Im Zusammenhang mit LLMs wird häufig von semantischem Verständnis gesprochen. Fachlich präziser ist es, von kontextsensitiver Bedeutungsverarbeitung zu sprechen. Das Modell besitzt kein menschliches Verstehen, kann aber auf Basis seines Trainings sehr viele sprachliche Muster, thematische Bezüge und typische Diskurszusammenhänge in seine Vorhersagen einfließen lassen @bommasani2021. Für praktische Aufgaben wie Tagging ist genau diese Fähigkeit entscheidend, weil sie über rein oberflächenbasierte Schlüsselworterkennung hinausgeht.
+Im Zusammenhang mit LLMs wird häufig von semantischem Verständnis gesprochen. Fachlich präziser ist es, von kontextsensitiver Bedeutungsverarbeitung zu sprechen. Das Modell besitzt kein menschliches Verstehen, kann aber nach Bommasani et al. @bommasani2021 auf Basis seines Trainings sehr viele sprachliche Muster, thematische Bezüge und typische Diskurszusammenhänge in seine Vorhersagen einfließen lassen. Für praktische Aufgaben wie Tagging ist genau diese Fähigkeit entscheidend, weil sie über rein oberflächenbasierte Schlüsselworterkennung hinausgeht.
 
 Ein kurzer Text über Compilerbau kann beispielsweise Begriffe wie `intermediate representation`, `optimization passes` oder `toolchain` enthalten, ohne das Oberthema explizit zu benennen. Ein LLM kann solche Signale in Beziehung setzen und daraus eine spezifische thematische Einordnung ableiten. Gerade in technischen Wissenssammlungen ist diese Eigenschaft wertvoll, weil viele Ressourcen nur für Personen mit Vorwissen unmittelbar eindeutig sind.
 
 === Zero-Shot- und Few-Shot-Lernen
 
-Ein weiterer wichtiger Aspekt ist die Fähigkeit großer Sprachmodelle zum Zero-Shot- und Few-Shot-Lernen. Brown et al. zeigen am Beispiel von GPT-3, dass große Sprachmodelle neue Aufgaben allein auf Basis sprachlicher Instruktionen und weniger oder sogar ganz ohne Beispiele bearbeiten können @brown2020. Das Modell muss dabei nicht durch Gradientenupdates auf die konkrete Aufgabe nachtrainiert werden, sondern reagiert direkt auf die Formulierung des Prompts.
+Ein weiterer wichtiger Aspekt ist die Fähigkeit großer Sprachmodelle zum Zero-Shot- und Few-Shot-Lernen. Brown et al. @brown2020 zeigen am Beispiel von GPT-3, dass große Sprachmodelle neue Aufgaben allein auf Basis sprachlicher Instruktionen und weniger oder sogar ganz ohne Beispiele bearbeiten können. Das Modell muss dabei nicht durch Gradientenupdates auf die konkrete Aufgabe nachtrainiert werden, sondern reagiert direkt auf die Formulierung des Prompts.
 
 Für das vorliegende Projekt ist insbesondere Zero-Shot-Lernen relevant. Die Klassifikation erfolgt nicht mithilfe eines separat trainierten Tagging-Modells, sondern durch einen Prompt, der die Tag-Hierarchie, die Ressource und das gewünschte Ausgabeformat enthält. Wenige oder gar keine Beispiele im Prompt senken den Vorbereitungsaufwand und machen das System flexibel. Gleichzeitig steigt damit die Bedeutung einer präzisen Aufgabenbeschreibung, weil die Qualität der Ausgabe stark von der Formulierung des Prompts abhängt.
 
@@ -149,7 +149,7 @@ Damit die Mehrfachklassifikation nicht zu unspezifischen Sammellisten führt, we
 
 == Evaluationskriterien
 
-Auch wenn in dieser Fassung noch keine systematische Ergebnisdiskussion vorgenommen wird, lassen sich klare Evaluationskriterien formulieren. Ein erstes Kriterium ist die inhaltliche Angemessenheit: Die vergebenen Tags sollen den Gegenstand einer Ressource korrekt und nicht nur oberflächlich beschreiben. Ein zweites Kriterium ist die Spezifität. Ein System, das systematisch nur allgemeine Oberkategorien wie `cs` oder `software_development` auswählt, wäre praktisch wenig nützlich, selbst wenn die Zuordnungen formal nicht falsch wären.
+Für die spätere Analyse des Prototyps lassen sich klare Evaluationskriterien formulieren. Ein erstes Kriterium ist die inhaltliche Angemessenheit: Die vergebenen Tags sollen den Gegenstand einer Ressource korrekt und nicht nur oberflächlich beschreiben. Ein zweites Kriterium ist die Spezifität. Ein System, das systematisch nur allgemeine Oberkategorien wie `cs` oder `software_development` auswählt, wäre praktisch wenig nützlich, selbst wenn die Zuordnungen formal nicht falsch wären.
 
 Ein drittes Kriterium betrifft die hierarchische Konsistenz. Die vorgeschlagenen Tags müssen in die bestehende Struktur passen und dürfen keine semantisch widersprüchlichen Kombinationen erzeugen. Viertens ist die Robustheit der Ausgabe wichtig: Für die technische Nutzbarkeit muss die Antwort zuverlässig im erwarteten JSON-Format vorliegen. Fünftens ist die praktische Anschlussfähigkeit zu nennen. Ein brauchbares System muss seine Ergebnisse speichern, exportieren und bei wiederholter Verarbeitung konsistent behandeln können. Diese Kriterien verbinden damit semantische, strukturelle und technische Qualitätsanforderungen.
 
@@ -200,46 +200,111 @@ Die Verarbeitung der Ressourcen erfolgt in einer mehrstufigen Pipeline, die in [
 
 === Extraktion
 
-Die eigentliche Verarbeitung beginnt in `src/main.rs`. Dort wird zunächst die Eingabedatei eingelesen und zeilenweise verarbeitet. Für jede URL bestimmt die Funktion `determine_resource_source`, ob es sich um eine unterstützte Quelle handelt. Gegenwärtig werden nur Adressen erkannt, die `twitter.com` oder `x.com` enthalten. Alle anderen Quellen werden mit einem Hinweis übersprungen. Diese Beschränkung macht deutlich, dass der Prototyp noch kein allgemeiner Web-Scraper ist, sondern zunächst einen klar abgegrenzten Ressourcentyp implementiert.
+Die eigentliche Verarbeitung beginnt in `src/main.rs`, wo die zentrale Funktion `classify_resources` alle Schritte der Pipeline koordiniert. Dort wird die Eingabedatei eingelesen, die Quelle einer URL grob bestimmt und anschließend nur dann weiterverarbeitet, wenn es sich um einen unterstützten Ressourcentyp handelt. Gegenwärtig betrifft das ausschließlich Links von X beziehungsweise Twitter. Diese Beschränkung ist bewusst gewählt, weil der Prototyp nicht möglichst viele Quellen gleichzeitig unterstützen soll, sondern zunächst einen zusammenhängenden, gut nachvollziehbaren Anwendungsfall.
 
-Für Twitter- beziehungsweise X-Links ruft das Programm die Funktion `scrapers::twitter::scrape(url)` auf. Diese extrahiert aus der URL die Tweet-ID und startet anschließend über `Command::new("python")` das externe Skript `scrape_user_tweet_contents.py`. Wenn die Extraktion erfolgreich war, liegt im Verzeichnis `scraped-tweets/` eine TOML-Datei mit dem Namen `tweet-<id>.toml` vor. Diese Datei dient als Übergabeformat zwischen Scraper und weiterer Rust-Verarbeitung. Die Extraktion ist damit technisch ausgelagert, aber sauber in die Hauptpipeline integriert.
+Für unterstützte Links wird die Kernfunktion `scrapers::twitter::scrape(url)` aufgerufen. Sie übernimmt die Extraktion des eigentlichen Beitragsinhalts und lagert diesen Schritt an ein vorhandenes Python-Skript aus. Für die Gesamtarchitektur ist weniger die interne Hilfslogik entscheidend als die Rolle dieser Funktion innerhalb des Systems: Sie bildet die Schnittstelle zwischen der bloßen URL und einer lokal verfügbaren Rohrepräsentation des Beitrags. Damit verwandelt die Extraktion einen externen Verweis in eine Ressource, die durch die weitere Pipeline verarbeitet werden kann.
 
 === Vorverarbeitung
 
-Nach der Extraktion wird die erzeugte TOML-Datei mit `parse_scraped_tweet` eingelesen. Die Implementierung versucht zunächst, das erwartete Format mittels `serde` in eine interne Struktur zu deserialisieren. Dabei werden Felder wie `id`, `full_text` und der Autorenname unter `author.screen_name` berücksichtigt. Falls diese direkte Deserialisierung scheitert, greift eine Fallback-Routine, die relevante Zeilen manuell aus dem TOML-Text extrahiert. Diese zweistufige Verarbeitung erhöht die Robustheit gegenüber kleineren Formatabweichungen der Scraper-Ausgabe.
+Nach der Extraktion wird die erzeugte Rohdatei in eine kompakte, einheitliche Textdarstellung überführt. Die dafür zentrale Funktion ist `parse_scraped_tweet`, die aus dem Scraper-Ergebnis genau jene Informationen herauszieht, die für die spätere Klassifikation tatsächlich benötigt werden: Beitragstext, Autor und Identifikationsdaten. Ziel dieser Phase ist nicht eine vollständige Rekonstruktion aller verfügbaren Metadaten, sondern eine sinnvolle Reduktion auf den inhaltlichen Kern der Ressource.
 
-Das Ergebnis der Vorverarbeitung ist ein vereinheitlichtes Objekt vom Typ `ScrapedTweet`, das die drei wesentlichen Informationen `id`, `text` und `author` enthält. Für die Klassifikation wird daraus ein formatierter String erzeugt: `Title: Tweet by @...` und `Content: ...`. Diese Darstellung ist bewusst einfach gehalten. Sie liefert dem Sprachmodell sowohl den eigentlichen Inhalt als auch einen minimalen Kontext über die Autorschaft, ohne zusätzliche Komplexität einzuführen. In methodischer Hinsicht ist die Vorverarbeitung damit kein schweres Text-Cleaning, sondern eine zielgerichtete Normalisierung in eine LLM-freundliche Form.
+Das Ergebnis dieser Vorverarbeitung ist ein standardisiertes Eingabeformat für das Sprachmodell: `Title: Tweet by @...` und `Content: ...`. Diese Normalisierung ist für das Gesamtsystem entscheidend, weil sie sehr kurze und formal uneinheitliche Social-Media-Texte in eine konsistente Repräsentation überführt. Dadurch kann die Klassifikation später mit einer gleichbleibenden Struktur arbeiten, auch wenn die ursprünglichen Beiträge stark variieren.
 
 === Klassifikation
 
-Die Klassifikation nutzt den in der Datei `tag-tree` abgelegten hierarchischen Tag-Baum als formale Zielstruktur. Dieser Baum wird zu Beginn des Programms eingelesen und anschließend an den Klassifikationsprompt übergeben. Die Funktion `classify_with_retry` in `src/classifiers.rs` übernimmt die Orchestrierung des Klassifikationsaufrufs. Intern ruft sie `classify` auf, welches über ein Subprozesskommando `codex e` mit dem konstruierten Prompt startet. Damit ist das LLM nicht direkt als Bibliothek eingebunden, sondern über eine externe Prozessschnittstelle angebunden.
+Die Klassifikation bildet das inhaltliche Zentrum des gesamten Prototyps. Grundlage ist der in `tag-tree` abgelegte hierarchische Tag-Baum, der dem Sprachmodell als Zielstruktur vorgegeben wird. Die zentrale Funktion dafür ist `classify_with_retry` in `src/classifiers.rs`. Sie bündelt den eigentlichen Modellaufruf, die Prüfung der Rückgabe und die Wiederholung des Vorgangs, falls das Ergebnis nicht im erwarteten Format vorliegt. Damit ist sie nicht nur eine technische Hilfsfunktion, sondern der Punkt, an dem semantische Zuordnung und Systemrobustheit zusammenkommen.
 
-Die Modellantwort soll ausschließlich JSON enthalten. Dieses JSON wird in die Struktur `ClassificationResult` geparst, die die Felder `tags`, `confidence`, `new_tags` und `reasoning` umfasst. Um mit unvollständigen Antworten umgehen zu können, sind die Felder mit `#[serde(default)]` versehen. Zusätzlich enthält die Funktion eine Retry-Logik: Scheitert entweder der Modellaufruf oder das Parsen der JSON-Antwort, wird der Vorgang bis zur maximalen Versuchszahl wiederholt. Diese Fehlerbehandlung ist für die Praxis wesentlich, weil freie Sprachmodelle zwar strukturierte Ausgaben erzeugen können, ihre Formatdisziplin aber nicht absolut garantiert ist.
+Inhaltlich besteht die Aufgabe der Klassifikation darin, aus einer knappen Ressourcendarstellung eine kleine Menge möglichst spezifischer Tags abzuleiten. Zugleich soll das Modell begründen, warum diese Tags gewählt wurden, und gegebenenfalls neue Kategorien vorschlagen, wenn der vorhandene Baum nicht ausreicht. Für das Gesamtverständnis des Systems ist daher vor allem wichtig, dass die Klassifikation nicht als freier Text endet, sondern in eine strukturierte Ausgabe überführt wird, die direkt weiterverarbeitet werden kann. So entsteht die Brücke zwischen sprachlicher Interpretation und maschineller Speicherung.
 
 === Speicherung der Tags
 
-Bereits beim Programmstart wird eine SQLite-Datenbank unter dem Pfad `resources.db` geöffnet und über `init_schema()` mit den benötigten Tabellen initialisiert. Das Datenbankschema umfasst die Tabellen `resources`, `tags`, `resource_tags` und `classification_log`. Dadurch werden sowohl die eigentlichen Ressourcen als auch ihre Zuordnungen, Konfidenzwerte und Begründungen der Klassifikation gespeichert. Die Wahl von SQLite ist für einen lokalen Prototyp zweckmäßig, weil keine separate Server-Infrastruktur nötig ist und relationale Tabellen dennoch zuverlässig angelegt werden können @sqlite2026.
+Die Speicherung ist der Schritt, in dem aus einer vorübergehenden Modellantwort ein dauerhaft nutzbares Ergebnis wird. Die zentrale Funktion hierfür ist `store_classification` in `src/db.rs`. Sie übernimmt die vom Sprachmodell erzeugten Tags, Konfidenzen und Begründungen und überführt sie in die relationale Struktur der SQLite-Datenbank. Auf diese Weise werden Ressourcen, Tag-Zuordnungen und Klassifikationsbegründungen nicht nur einmalig angezeigt, sondern für spätere Suchen, Exporte und Auswertungen konserviert.
 
-Vor einer neuen Verarbeitung prüft `resource_exists(url)`, ob die betreffende URL bereits bekannt ist. So kann verhindert werden, dass identische Ressourcen bei wiederholten Läufen erneut klassifiziert werden, sofern nicht der `--force`-Schalter gesetzt ist. Nach erfolgreicher Klassifikation wird die Ressource zunächst über `insert_resource` in die Tabelle `resources` eingetragen oder aktualisiert. Anschließend erzeugt `store_classification` die Tag-Zuordnungen in `resource_tags`, legt fehlende Hierarchieeinträge in `tags` an und schreibt die Begründung sowie Tag-Vorschläge in `classification_log`. Die Speicherung ist damit nicht nur Ergebnisablage, sondern strukturelle Grundlage für spätere Auswertung, Export und Weiterverarbeitung.
+Für das große Ganze ist vor allem wichtig, dass die Datenbank mehrere Rollen gleichzeitig erfüllt. Sie speichert nicht nur den Inhalt einer Ressource, sondern auch ihre thematische Einordnung und die Begründung dieser Einordnung. Dadurch wird der Prototyp von einer reinen Demonstration zu einem Werkzeug, das Wiederverwendung und Weiterentwicklung ermöglicht. Die Speicherung bildet damit den Abschluss der Pipeline und zugleich den Ausgangspunkt für alle späteren Funktionen wie Statistik, Export oder manuelle Nachprüfung.
 
 == Implementierungsdetails
 
 === Projektstruktur
 
-Das Projekt ist bewusst modular gehalten. Die zentrale Ablaufsteuerung liegt in `src/main.rs`, wo die Kommandozeilenschnittstelle mit `clap` definiert wird. Dort werden die drei Subkommandos `classify`, `export` und `stats` bereitgestellt. `classify` verarbeitet Ressourcen aus einer Eingabedatei, `export` schreibt gespeicherte Ressourcen in eine JSON-Datei und `stats` gibt eine einfache Übersicht über Ressourcen- und Tag-Anzahlen aus. Diese Aufteilung macht die Anwendung als Werkzeug bedienbar und trennt Steuerlogik von Fachlogik.
+Die Projektstruktur folgt einer bewusst einfachen Arbeitsteilung. `src/main.rs` übernimmt die zentrale Steuerung der Anwendung, `src/classifiers.rs` bündelt die semantische Klassifikation, `src/scrapers/twitter.rs` ist für die Gewinnung der Tweet-Inhalte zuständig und `src/db.rs` organisiert die dauerhafte Speicherung. Ergänzt wird diese Struktur durch die externen Dateien `tag-tree` als Wissensstruktur und `test-classification-list` als Eingabe. Auf diese Weise bleibt die Architektur überschaubar und zugleich klar genug gegliedert, um einzelne Teile unabhängig voneinander weiterentwickeln zu können.
 
-Die Klassifikationslogik selbst liegt in `src/classifiers.rs`, die Datenbankanbindung in `src/db.rs` und die Scraper-spezifische Verarbeitung in `src/scrapers/twitter.rs`. Ergänzt wird diese Struktur durch externe Projektdateien wie `tag-tree`, `test-classification-list` und das Verzeichnis `scraped-tweets/`. Die Architektur folgt damit einer klaren Rollenverteilung: Eingabe und Ablaufsteuerung, Datenextraktion, semantische Klassifikation sowie Persistenz sind voneinander getrennt, aber über einfache Funktionsschnittstellen gekoppelt.
+Für die Facharbeit ist dabei weniger die vollständige Auflistung aller Module wichtig als die Grundidee der Architektur: Das System trennt Eingabe, Extraktion, Interpretation und Speicherung in eigenständige Verantwortungsbereiche. Diese Trennung erleichtert nicht nur die technische Wartung, sondern macht auch die konzeptionelle Logik des Projekts sichtbar.
 
 === Klassifikationslogik
 
-Die interne Klassifikationslogik des Programms ist auf idempotente und nachvollziehbare Verarbeitung ausgelegt. Für jede URL wird zunächst geprüft, ob sie bereits in der Datenbank vorhanden ist. Existiert ein Eintrag und wurde kein `--force`-Flag gesetzt, wird die Ressource übersprungen. Damit bleibt der Lauf effizient und wiederholbar. Wird `--force` verwendet, wird eine bestehende Ressource erneut klassifiziert, was insbesondere bei verändertem Prompt oder erweitertem Tag-Baum sinnvoll ist.
+Die Klassifikationslogik des Projekts lässt sich als Zusammenspiel weniger zentraler Entscheidungen beschreiben. Erstens soll eine Ressource nicht einfach irgendeinen, sondern einen möglichst spezifischen Tag erhalten. Zweitens darf eine Ressource mehreren Themenbereichen zugeordnet werden. Drittens muss das System mit Unsicherheit umgehen können, statt jede Eingabe mit derselben Entschiedenheit zu behandeln. Diese drei Anforderungen prägen sowohl den Prompt als auch die weitere Verarbeitung der Ergebnisse.
 
-Nach dem eigentlichen Modellaufruf werden die vom LLM gelieferten Informationen nicht blind übernommen, sondern zusätzlich ausgewertet. Das Programm gibt gefundene Tags, Konfidenzen und die textuelle Begründung auf der Konsole aus. Für neue Tag-Vorschläge wird der Elternknoten samt Begründung gesondert angezeigt. Außerdem wird mit `confident_tags(0.5)` eine einfache Schwelle angewandt, um sehr unsichere Klassifikationen sichtbar zu machen. Diese Schwelle ersetzt keine wissenschaftliche Evaluation, zeigt aber, wie modellinterne Sicherheitsschätzungen bereits im Prototyp in praktische Entscheidungslogik überführt werden können.
+Im großen Ganzen bedeutet das: Das Sprachmodell dient nicht nur als Textgenerator, sondern als semantischer Einordner innerhalb einer vorgegebenen Wissensstruktur. Die resultierenden Tags, Begründungen und Unsicherheiten werden anschließend so verarbeitet, dass sie für den Nutzer nachvollziehbar bleiben. Genau in dieser Verbindung aus inhaltlicher Interpretation und technischer Struktur liegt der eigentliche Kern der Klassifikationslogik.
 
 === Scraper-Implementierung
 
-Die Scraper-Implementierung ist ein gutes Beispiel für die pragmatische, prototypische Natur des Projekts. Anstatt eine vollständige Scraper-Logik direkt in Rust nachzubauen, nutzt das System ein bereits vorhandenes Python-Skript zur Extraktion von Tweet-Inhalten. Die Rust-Seite übernimmt die Rolle eines Wrappers: Sie extrahiert die Tweet-ID aus der URL, ruft das Skript mit dieser ID auf und prüft anschließend, ob die erwartete TOML-Datei erzeugt wurde. Dieser Ansatz beschleunigt die Entwicklung, weil vorhandene Werkzeuge wiederverwendet werden können.
+Die Scraper-Implementierung verdeutlicht den prototypischen Charakter des Projekts. Anstatt sämtliche Schritte selbst neu zu entwickeln, nutzt das System für die Extraktion ein vorhandenes Python-Werkzeug und bindet es in die Rust-Anwendung ein. Aus Sicht des Gesamtsystems ist dies sinnvoll, weil die Extraktion nicht Selbstzweck ist, sondern vor allem die Voraussetzung dafür schafft, dass aus einer URL überhaupt ein klassifizierbarer Text wird.
 
-Gleichzeitig zeigt die Implementierung, an welchen Stellen praktische Robustheit wichtig wird. Die durch den Scraper erzeugten TOML-Dateien folgen zwar einem erwarteten Grundschema, enthalten aber verschachtelte Felder und potenzielle Formatvarianten. Deshalb kombiniert der Parser eine reguläre `serde`-Deserialisierung mit einer manuellen Fallback-Auswertung einzelner Schlüssel wie `id`, `full_text` und `screen_name`. Für den Zweck des Prototyps ist dies ein sinnvoller Kompromiss zwischen Eleganz und Fehlertoleranz. Perspektivisch wäre denkbar, die Datenextraktion noch stärker zu standardisieren oder auf weitere Ressourcentypen auszudehnen. In der aktuellen Projektphase ist die bestehende Lösung jedoch ausreichend, um eine durchgängige Klassifikationspipeline realistisch zu demonstrieren.
+Entscheidend ist daher weniger, wie jede einzelne Hilfsroutine des Scrapers intern arbeitet, sondern welche Funktion der Scraper im Gesamtprozess erfüllt: Er stellt sicher, dass flüchtige Plattforminhalte in eine lokal verfügbare und weiterverarbeitbare Form überführt werden. Erst dadurch können die nachgelagerten Schritte der Normalisierung, Klassifikation und Speicherung zuverlässig anschließen.
 
+= Evaluation
+
+== Vergleich: Klassische Machine-Learning-Ansätze vs. Large Language Models
+
+Der Vergleich zwischen klassischen Verfahren des Machine Learning und Large Language Models zeigt, dass beide Ansätze unterschiedliche Stärken besitzen und deshalb nicht pauschal gegeneinander ausgespielt werden sollten. Klassische Verfahren wie Naive Bayes oder Support Vector Machines sind besonders dann sinnvoll, wenn ein klar definierter Anwendungsfall, ein stabiles Label-Set und ausreichend annotierte Trainingsdaten vorliegen. Unter diesen Bedingungen lassen sich nach Manning, Raghavan und Schütze @manning2008, McCallum und Nigam @mccallum1998 sowie Joachims @joachims2002 reproduzierbare Modelle trainieren, die effizient arbeiten und deren Verhalten in Bezug auf Eingabemerkmale oft leichter analysierbar ist.
+
+Für das vorliegende Projekt lagen diese Voraussetzungen jedoch gerade nicht vor. Es existierte zwar ein Tag-Baum, aber kein ausreichend großes, sauber gelabeltes Korpus. Zudem bestand die Aufgabe nicht in der Vorhersage einer einzigen festen Klasse, sondern in der Auswahl mehrerer möglichst spezifischer Tags innerhalb einer Hierarchie. Hinzu kommt, dass die verarbeiteten Texte kurz, kontextabhängig und teilweise implizit formuliert sind. In einem solchen Szenario bieten Large Language Models nach Brown et al. @brown2020 und Bommasani et al. @bommasani2021 einen praktischen Vorteil, weil sie ohne projektspezifisches Training semantische Beziehungen nutzen und durch Prompting auf neue Aufgaben ausgerichtet werden können.
+
+Gleichzeitig machen die Beobachtungen aus dem Prototyp deutlich, dass diese Flexibilität mit Kosten verbunden ist. LLMs liefern keine vollständig deterministischen Ergebnisse, ihre Konfidenzwerte sind nicht statistisch kalibriert, und die Qualität der Ausgabe hängt stark von Prompt, Modellzustand und vorhandener Tag-Struktur ab. Klassische Verfahren wären in einer späteren Projektphase dann wieder attraktiv, wenn ein größerer, manuell überprüfter Goldstandard zur Verfügung stünde. Für den prototypischen Einstieg ist der LLM-Ansatz jedoch nachvollziehbar überlegen, weil er mit geringem Vorbereitungsaufwand eine inhaltlich brauchbare Erstklassifikation ermöglicht.
+
+== Analyse der Ergebnisse
+
+Der aktuelle Datenbestand des Prototyps ist klein und explorativ, erlaubt aber bereits erste qualitative Aussagen. In der lokalen Datenbank befinden sich sieben Ressourcen. Davon wurden fünf mit mindestens einem Tag versehen, während zwei Ressourcen ohne gespeicherte Klassifikation blieben. Insgesamt wurden acht Tag-Zuordnungen gespeichert. Sechs dieser Zuordnungen liegen bei einer modellseitigen Konfidenz von mindestens `0.5`, zwei darunter. Der Mittelwert der gespeicherten Konfidenzen liegt bei rund `0.63`. Diese Zahlen sind nicht als belastbare Leistungsmetriken zu verstehen, geben aber einen Eindruck von der momentanen Arbeitsfähigkeit des Systems.
+
+Inhaltlich zeigen mehrere Fälle, dass das Verfahren bereits sinnvolle, spezialisierte Zuordnungen erzeugen kann. Ein Beitrag zu Nix-basierten Entwicklungsumgebungen wurde den Bereichen `cs/software_development/build_systems/nix` und `cs/tools/build_systems` zugeordnet und erhielt vergleichsweise hohe Konfidenzen. Auch ein Tweet über die TigerBeetle-Entwicklung wurde inhaltlich plausibel mit Robustheit und Engineering Culture verknüpft. Hier zeigt sich die Stärke des LLM-Ansatzes: Der Text wird nicht nur auf offensichtliche Schlagwörter reduziert, sondern im Kontext eines technischen Diskurses interpretiert.
+
+Besonders aufschlussreich sind jene Fälle, in denen das Modell keine perfekte Übereinstimmung mit dem vorhandenen Tag-Baum findet. Für einen Tweet zu Information Theory wurde neben bestehenden Tags auch der Vorschlag `information_theory` unter `cs/theory` erzeugt. Ein anderer Beitrag zu einem Recherchewerkzeug für wissenschaftliche Arbeiten führte zum Vorschlag `research_tools` unter `cs/software_development/educational_resources`. Drei der fünf gespeicherten Klassifikationsläufe enthielten solche neuen Tag-Vorschläge. Das deutet darauf hin, dass das System nicht nur kategorisiert, sondern zugleich Lücken der bestehenden Taxonomie sichtbar machen kann.
+
+Die Ergebnisse zeigen aber auch die Grenzen des aktuellen Stands. Ein Beitrag von Claude über ein schnelleres Modell wurde nur sehr allgemein mit `cs/software_development` bei einer niedrigen Konfidenz von etwa `0.32` klassifiziert. Auch dies ist aussagekräftig: Nicht jede Ressource lässt sich mit dem vorhandenen Baum präzise abbilden. Gerade Themen rund um KI-Modelle oder API-Produkte sind in der aktuellen Struktur unterrepräsentiert. Die Resultate sprechen daher insgesamt für eine grundsätzliche Eignung des Ansatzes, aber ebenso deutlich für die Notwendigkeit einer laufenden Pflege und Erweiterung der Tag-Hierarchie.
+
+== Fehleranalyse
+
+Die Fehleranalyse muss zwei Ebenen unterscheiden: inhaltliche Fehlklassifikationen und technische Pipeline-Probleme. Inhaltliche Unsicherheiten sind vor allem dort sichtbar, wo das Modell nur sehr allgemeine Tags vergibt oder niedrige Konfidenzen zurückliefert. Das kann daran liegen, dass die Ressource tatsächlich mehrdeutig ist, dass der Tag-Baum keinen passenden spezifischen Eintrag enthält oder dass der zugrunde liegende Tweet für eine eindeutige Einordnung zu kurz formuliert ist. Besonders deutlich wird dies bei produkt- oder plattformbezogenen KI-Beiträgen, die sich nur schwer auf eine bestehende, eher informatiktheoretische Hierarchie abbilden lassen.
+
+Technisch noch relevanter ist, dass derzeit nicht alle Ressourcen bis zum Ende der Pipeline verarbeitet werden. Zwei Ressourcen sind in der Tabelle `resources` vorhanden, besitzen jedoch weder gespeicherte Tag-Zuordnungen noch einen Eintrag im `classification_log`. Aus dem Programmablauf lässt sich ableiten, dass diese Fälle nach dem Einfügen der Ressource, aber vor dem erfolgreichen Abschluss der Klassifikation oder Speicherung abgebrochen wurden. Ein Beitrag beschreibt ein neues Vertrauensmodell für Open-Source-Projekte, ein anderer ist eine knappe Antwort in einem Diskussionsfaden. Beide Fälle sind thematisch schwerer einzuordnen als die übrigen Beispiele und illustrieren, dass kurze oder dialogische Texte das System stärker fordern.
+
+Hinzu kommt ein strukturelles Problem der aktuellen Architektur: Scraping, LLM-Aufruf und Speicherung hängen in einer linearen Pipeline voneinander ab. Fällt ein Schritt aus, entsteht ein unvollständiger Zustand, in dem eine Ressource bereits gespeichert wurde, aber noch keine Klassifikation besitzt. Für einen Prototyp ist das akzeptabel, für ein reiferes System wäre jedoch eine explizite Statusverwaltung sinnvoll, etwa mit Zuständen wie `gescraped`, `klassifiziert`, `fehlgeschlagen` oder `zur Prüfung markiert`. Die Fehleranalyse zeigt damit, dass nicht nur das Modell selbst, sondern auch die Systemarchitektur für die Gesamtqualität entscheidend ist.
+
+== Stärken und Schwächen des Ansatzes
+
+Eine wesentliche Stärke des entwickelten Ansatzes liegt in seiner praktischen Einsetzbarkeit ohne vorgängige Trainingsphase. Das System kann mit einer bestehenden Tag-Hierarchie sofort eingesetzt werden und erzeugt bereits auf einer kleinen Datenbasis nachvollziehbare thematische Zuordnungen. Die Kombination aus hierarchischem Tagging, Multi-Label-Ausgabe, JSON-Parsing und SQLite-Speicherung ergibt eine zusammenhängende Pipeline, die nicht nur demonstrativ, sondern tatsächlich nutzbar ist. Besonders positiv ist außerdem die Fähigkeit des Modells, neue Tag-Vorschläge zu generieren und damit Lücken der bestehenden Wissensstruktur sichtbar zu machen.
+
+Eine weitere Stärke ist die Modularität des Prototyps. Scraper, Klassifikationslogik und Datenbank sind voneinander getrennt, wodurch einzelne Komponenten leichter ausgetauscht oder erweitert werden können. Das System ist damit offen für weitere Ressourcentypen, für alternative LLM-Anbindungen oder für spätere Evaluationsschritte mit manuell überprüften Referenzdaten. Auch der lokale Einsatz mit SQLite ist für eine persönliche oder schulische Facharbeit angemessen, weil er geringe infrastrukturelle Hürden mit ausreichender Funktionalität verbindet.
+
+Den Stärken stehen jedoch mehrere Schwächen gegenüber. Erstens sind die vom Modell gelieferten Konfidenzwerte heuristisch und nicht verlässlich kalibriert. Zweitens ist die Qualität der Ergebnisse stark von der vorhandenen Tag-Hierarchie abhängig. Fehlen passende Kategorien, sinkt entweder die Spezifität der Ausgabe oder es müssen neue Tags vorgeschlagen werden. Drittens besteht eine deutliche Abhängigkeit von externen Komponenten, insbesondere vom Python-Scraper und vom per Kommandozeile aufgerufenen LLM. Viertens ist die empirische Basis des aktuellen Systems noch sehr klein, sodass aus den bisherigen Resultaten keine allgemeine Leistungsbewertung abgeleitet werden kann. Der Ansatz ist daher überzeugend als Prototyp, aber noch nicht als abschließend validiertes System.
+
+== Ethische und gesellschaftliche Aspekte
+
+Die Verwendung von LLMs zur automatisierten Ordnung persönlicher oder öffentlicher Informationssammlungen wirft auch ethische und gesellschaftliche Fragen auf. Zunächst betrifft dies die Verzerrungen der Modelle selbst. Sprachmodelle übernehmen nach Bommasani et al. @bommasani2021 sowie Bender et al. @bender2021 aus ihren Trainingsdaten implizite Muster, Prioritäten und Vorurteile. Diese können sich nicht nur in generierten Texten, sondern auch in Klassifikationsentscheidungen niederschlagen. Wenn ein Modell bestimmte Themengebiete systematisch anders gewichtet, beeinflusst es damit auch, wie Wissen im Zielsystem strukturiert und wiedergefunden wird.
+
+Ein zweiter Aspekt betrifft Transparenz und Nachvollziehbarkeit. Für Nutzerinnen und Nutzer ist es oft nicht ohne Weiteres ersichtlich, warum ein bestimmter Tag vergeben oder ein anderer verworfen wurde. Das Projekt reagiert darauf teilweise mit dem Feld `reasoning`, doch auch diese textliche Begründung bleibt letztlich modellgeneriert und garantiert keine echte Erklärbarkeit. In produktiven Anwendungen wäre daher zu überlegen, wie automatische Vorschläge mit menschlicher Überprüfung kombiniert werden können, damit die Organisation von Wissen nicht vollständig in eine schwer kontrollierbare Black Box ausgelagert wird.
+
+Schließlich sind auch Daten- und Plattformfragen relevant. Der aktuelle Prototyp verarbeitet Inhalte von X beziehungsweise Twitter und ist damit von einer externen Plattform abhängig, deren Datenzugang, Formate und Nutzungsbedingungen sich ändern können. Außerdem stellt sich die Frage, welche Inhalte automatisiert gespeichert, analysiert und weiterverarbeitet werden dürfen. Selbst wenn die Anwendung im privaten Kontext bleibt, zeigt sie exemplarisch ein breiteres gesellschaftliches Spannungsfeld: Automatisierte Wissensorganisation kann Produktivität erhöhen, verschiebt aber zugleich Verantwortung von Menschen auf Modelle, deren Entscheidungen nicht neutral sind. Eine reflektierte Nutzung solcher Systeme setzt deshalb nicht nur technische, sondern auch gesellschaftliche Urteilskraft voraus.
+
+= Fazit
+
+== Zusammenfassung der Ergebnisse
+
+Die Arbeit hat gezeigt, dass die automatisierte Verschlagwortung digitaler Ressourcen mit Large Language Models sowohl theoretisch begründbar als auch praktisch umsetzbar ist. Ausgehend vom Problem einer wachsenden, schwer überschaubaren Informationsmenge wurde zunächst deutlich, dass klassische Verfahren des Machine Learning in diesem Anwendungsfall zwar wichtige Grundlagen liefern, aber ohne annotierte Trainingsdaten und bei kurzen, kontextreichen Texten an Grenzen stoßen. Darauf aufbauend wurde ein LLM-basierter Ansatz entwickelt, der die Klassifikation direkt über einen strukturierten Prompt vornimmt und die Ergebnisse in einer relationalen Datenbank speichert.
+
+Mit dem implementierten Prototyp liegt nun eine durchgängige Pipeline vor, die URLs aus einer Eingabedatei einliest, X-Beiträge extrahiert, deren Inhalte normalisiert, eine hierarchische Multi-Label-Klassifikation durchführt und die Resultate speichert. Der aktuelle Datenbestand ist klein, zeigt jedoch bereits, dass das System spezialisierte Tags vergeben, unpassende allgemeine Kategorien durch neue Tag-Vorschläge ergänzen und mehrere Themen pro Ressource berücksichtigen kann. Zugleich wurden Grenzen sichtbar, etwa bei unvollständigen Klassifikationen, bei Themen außerhalb der bestehenden Hierarchie und bei der Abhängigkeit von externen Komponenten.
+
+== Beantwortung der Forschungsfrage
+
+Die leitende Forschungsfrage lautete, inwieweit sich Large Language Models dazu eignen, kurze digitale Ressourcen ohne spezielles domänenspezifisches Training automatisch in ein hierarchisches Multi-Label-Tagging-System einzuordnen. Auf Basis der theoretischen Einordnung und der prototypischen Umsetzung lässt sich diese Frage insgesamt positiv beantworten, allerdings nur unter bestimmten Bedingungen. LLMs eignen sich sehr gut als flexibler Ausgangspunkt für eine erste automatische Verschlagwortung, wenn kein gelabeltes Trainingskorpus vorhanden ist und wenn die zu verarbeitenden Texte stark von Kontext und implizitem Wissen abhängen.
+
+Ihre Eignung ist jedoch nicht grenzenlos. Die Qualität der Ergebnisse hängt stark von der Güte des Prompts, der Vollständigkeit der Tag-Hierarchie und der Robustheit der technischen Pipeline ab. LLMs ersetzen daher keine sorgfältige Modellierung des Zielsystems, sondern verschieben den Schwerpunkt von der Trainingsphase hin zur Prompt-Gestaltung, Ergebnisvalidierung und Taxonomiepflege. Für das hier untersuchte Projekt bedeutet das: Das Sprachmodell ist kein perfekter automatischer Entscheider, aber ein leistungsfähiges Werkzeug zur semantischen Vorstrukturierung von Ressourcen.
+
+== Ausblick auf zukünftige Entwicklungen
+
+Für die Weiterentwicklung des Projekts ergeben sich mehrere sinnvolle Schritte. Erstens sollte die Datenbasis deutlich erweitert werden, um die Qualität der Klassifikation auf einer breiteren Grundlage beurteilen zu können. Zweitens wäre eine manuelle Referenzannotation einzelner Ressourcen hilfreich, um systematischer zwischen gelungenen und fehlerhaften Zuordnungen unterscheiden zu können. Drittens sollte die Statusverwaltung der Pipeline verbessert werden, damit fehlgeschlagene Klassifikationen explizit erkannt, erneut angestoßen oder zur manuellen Prüfung markiert werden können.
+
+Darüber hinaus wäre eine Ausweitung auf weitere Ressourcentypen naheliegend, etwa auf klassische Bookmarks, Blogartikel, Videos oder wissenschaftliche Publikationen. Ebenso denkbar ist eine Kombination aus LLM-gestützter Vorhersage und menschlicher Kuratierung, bei der das Modell Vorschläge erzeugt, die anschließend bestätigt oder korrigiert werden. Langfristig könnte aus dem aktuellen Prototyp so ein System entstehen, das nicht nur persönliche Informationssammlungen organisiert, sondern auch als Werkzeug für individuelle Wissensarbeit, Recherche und digitale Archivierung dient.
+
+#pagebreak()
 #bibliography("refs.bib", style: "ieee", title: [Literaturverzeichnis])

docs/refs.bib

@@ -2,9 +2,7 @@
   author = {Christopher D. Manning and Prabhakar Raghavan and Hinrich Schütze},
   title = {Introduction to Information Retrieval},
   publisher = {Cambridge University Press},
-  year = {2008},
+  year = {2008}
-  doi = {10.1017/CBO9780511809071},
-  isbn = {9780511809071}
 }
 
 @article{salton1988,
@@ -14,8 +12,7 @@
   volume = {24},
   number = {5},
   pages = {513--523},
-  year = {1988},
+  year = {1988}
-  doi = {10.1016/0306-4573(88)90021-0}
 }
 
 @inproceedings{mccallum1998,
@@ -31,40 +28,35 @@
   title = {Learning to Classify Text Using Support Vector Machines},
   publisher = {Springer},
   address = {Boston, MA},
-  year = {2002},
+  year = {2002}
-  doi = {10.1007/978-1-4615-0907-3}
 }
 
 @inproceedings{vaswani2017,
   author = {Ashish Vaswani and others},
   title = {Attention Is All You Need},
   booktitle = {Advances in Neural Information Processing Systems 30 (NeurIPS 2017)},
-  year = {2017},
+  year = {2017}
-  url = {https://arxiv.org/abs/1706.03762}
 }
 
 @article{brown2020,
   author = {Tom B. Brown and others},
   title = {Language Models are Few-Shot Learners},
   journal = {arXiv preprint arXiv:2005.14165},
-  year = {2020},
+  year = {2020}
-  url = {https://arxiv.org/abs/2005.14165}
 }
 
 @article{bommasani2021,
   author = {Rishi Bommasani and others},
   title = {On the Opportunities and Risks of Foundation Models},
   journal = {arXiv preprint arXiv:2108.07258},
-  year = {2021},
+  year = {2021}
-  url = {https://arxiv.org/abs/2108.07258}
 }
 
 @article{liu2023,
   author = {Rundong Liu and others},
   title = {Recent Advances in Hierarchical Multi-label Text Classification: A Survey},
   journal = {arXiv preprint arXiv:2307.16265},
-  year = {2023},
+  year = {2023}
-  url = {https://arxiv.org/abs/2307.16265}
 }
 
 @article{guy2006,
@@ -74,13 +66,13 @@
   volume = {12},
   number = {1},
   year = {2006},
-  url = {https://mirror.dlib.org/dlib/january06/guy/01guy.html}
+  note = {Abgerufen am 05.04.2026}
 }
 
-@misc{sqlite2026,
+@inproceedings{bender2021,
-  author = {{SQLite Documentation}},
+  author = {Emily M. Bender and Timnit Gebru and Angelina McMillan-Major and Shmargaret Shmitchell},
-  title = {CREATE TABLE},
+  title = {On the Dangers of Stochastic Parrots: Can Language Models Be Too Big?},
-  year = {2026},
+  booktitle = {Proceedings of the 2021 ACM Conference on Fairness, Accountability, and Transparency},
-  url = {https://www.sqlite.org/lang_createtable.html},
+  pages = {610--623},
-  note = {Abgerufen am 25.03.2026}
+  year = {2021}
 }