Refine paper evaluation framing and conclusions

docs/Facharbeit.typ

@@ -153,6 +153,12 @@ Für die spätere Analyse des Prototyps lassen sich klare Evaluationskriterien f
 
 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.
 
+== Auswahl der Evaluationsbeispiele
+
+Die Evaluation dieser Facharbeit verfolgt bewusst nicht das Ziel, einen breiten Benchmark mit möglichst vielen Ressourcen aufzubauen. Stattdessen basiert sie auf sechs ausgewählten X-Beiträgen, die jeweils einen eigenen analytischen Mehrwert besitzen. Die Beispiele wurden also nicht nach bloßer Anzahl, sondern danach ausgewählt, welchen zusätzlichen Aspekt sie für die Beurteilung des Prototyps sichtbar machen: einen klaren Direkttreffer, eine Mehrfachklassifikation, einen spezifischen Blattknoten, einen Grenzfall zwischen benachbarten Teilgebieten sowie einen Fall, in dem der bestehende Tag-Baum erweitert werden könnte.
+
+Für jedes Beispiel wurde bei der Auswertung notiert, welche ein bis drei Tags nach inhaltlicher Lektüre des Beitrags als sachlich vertretbare Zielkategorien gelten. Diese Referenz dient als qualitative Orientierung, ist aber kein formaler Goldstandard im statistischen Sinn. Der Evaluationslauf soll daher nicht allgemeine Leistungswerte über soziale Medien oder über LLM-Tagging insgesamt beweisen, sondern zeigen, wie sich der Prototyp in einem kleinen, technisch geprägten und bewusst gewählten Anwendungsfenster verhält.
+
 = Umsetzung
 
 == Datenerhebung
@@ -244,37 +250,110 @@ Entscheidend ist daher weniger, wie jede einzelne Hilfsroutine des Scrapers inte
 
 = Evaluation
 
-== Vergleich: Klassische Machine-Learning-Ansätze vs. Large Language Models
+== Einordnung klassischer Machine-Learning-Verfahren gegenüber dem LLM-Ansatz
 
 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.
+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 dennoch plausibel, weil er ohne vorgängiges Spezialtraining eine inhaltlich brauchbare Erstklassifikation ermöglichen kann. Diese Einordnung bleibt jedoch theoretisch; ein empirischer Baseline-Vergleich wurde im Rahmen dieser Facharbeit nicht durchgeführt.
 
 == Analyse der Ergebnisse
 
-Für die eigentliche Evaluation wurde der Prototyp auf sechs neuen X-Beiträgen aus dem Themenfeld Compilerbau und Programmiersprachen ausgeführt. Alle sechs Ressourcen erhielten mindestens einen gespeicherten Tag. Insgesamt wurden elf Tag-Zuordnungen gespeichert. Der Mittelwert der gespeicherten Konfidenzen lag bei rund `0.91`; der niedrigste Wert lag bei `0.80`, der höchste bei `0.99`. Wegen der kleinen Stichprobe sind diese Werte nicht als allgemeingültige Leistungsmetriken zu verstehen, sie zeigen aber deutlich, dass die Pipeline auf diesem Datensatz stabil arbeitet und fachlich spezifische Ergebnisse erzeugen kann.
+Für die eigentliche Evaluation wurde der Prototyp auf sechs bewusst ausgewählten X-Beiträgen aus dem Themenfeld Compilerbau und Programmiersprachen ausgeführt. Alle sechs Ressourcen erhielten mindestens einen gespeicherten Tag, insgesamt wurden elf Tag-Zuordnungen persistiert. Die dabei mitgespeicherten Konfidenzwerte lagen zwischen `0.80` und `0.99`; sie werden im Folgenden jedoch nicht als Gütemaß interpretiert, sondern lediglich als heuristische Metadaten des Systems. Die Aussagekraft der Evaluation ergibt sich daher nicht aus aggregierten Kennzahlen, sondern aus der qualitativen Betrachtung der ausgewählten Fälle.
 
-Besonders überzeugend ist die inhaltliche Präzision der vergebenen Tags. Ein Tweet über eine Einführung in Compiler wurde mit `cs/theory/compilers` klassifiziert. Ein anderer Beitrag mit Ressourcen zu Registerallokation, SSA, Codegenerierung und Optimierung wurde passend unter `cs/theory/compilers/code_generation`, `cs/theory/compilers/optimization` und `cs/theory/compilers/analysis` einsortiert. Für einen Beitrag über den Optimizer-Workflow von LLVM vergab das System `cs/theory/compilers/llvm` und `cs/theory/compilers/optimization`. Die Empfehlung des Buchs _Types and Programming Languages_ wurde mit `cs/theory/compilers/type_systems` und `cs/theory/type_theory` klassifiziert. Auch der Zig-Beitrag wurde sinnvoll erfasst: Er erhielt `cs/theory/compilers/parsing` und `cs/programming_languages/zig`.
+#figure(
+  [
+    #set text(size: 8.5pt)
+    #table(
+      columns: (1.1fr, 1.65fr, 1.65fr, 1.3fr, 1.35fr),
+      align: (left, left, left, left, left),
+      stroke: 0.4pt,
+      inset: 5pt,
+      table.header(
+        [Beispiel],
+        [Akzeptable Tags],
+        [Vorhergesagte Tags],
+        [Gezeigter Aspekt],
+        [Kurzbewertung],
+      ),
+      [Compiler-Intro],
+      [`cs/theory/compilers`],
+      [`cs/theory/compilers`],
+      [klarer Direkttreffer],
+      [inhaltlich passend und ausreichend spezifisch],
 
-Diese Ergebnisse sprechen für eine hohe Effektivität des Ansatzes in inhaltlich klaren Fachfällen. Das Modell bleibt nicht auf grobe Oberbegriffe beschränkt, sondern nutzt die Hierarchie tatsächlich bis auf spezifische Blätter wie `llvm`, `code_generation`, `optimization`, `history`, `type_systems` oder `type_theory`. Zugleich zeigt der Datensatz, dass das System nicht nur vorhandene Kategorien nutzt, sondern die Taxonomie bei Bedarf sinnvoll erweitert. Beim Zig- und Lexer-Beitrag schlug das Modell `cs/theory/compilers/lexical_analysis` vor. Da die zugehörige Mindestkonfidenz bei `0.80` lag und damit oberhalb des festgelegten Schwellenwerts, wurde dieser Tag automatisch in den Tag-Baum übernommen. Gerade dieser Fall zeigt, dass das Verfahren nicht nur klassifiziert, sondern die bestehende Struktur auch kontrolliert verfeinern kann.
+      [Lattner-Keynote],
+      [`cs/theory/compilers/history` oder `cs/theory/compilers`],
+      [`cs/theory/compilers/history`],
+      [thematische Einordnung eines historischen Bezugs],
+      [überzeugender thematischer Fokus statt bloßer Oberkategorie],
+
+      [Compiler-Ressourcen],
+      [`cs/theory/compilers/analysis`; `code_generation`; `optimization`],
+      [`cs/theory/compilers/analysis`; `code_generation`; `optimization`],
+      [starke Mehrfachklassifikation],
+      [nahezu lehrbuchartiger Mehrfachtreffer],
+
+      [LLVM-Pipeline],
+      [`cs/theory/compilers/llvm`; `optimization`],
+      [`cs/theory/compilers/llvm`; `optimization`],
+      [spezifischer Blattknoten],
+      [sehr präzise auf ein Subgebiet zugeschnitten],
+
+      [TAPL],
+      [`cs/theory/type_theory`; optional `cs/theory/compilers/type_systems`],
+      [`cs/theory/compilers/type_systems`; `cs/theory/type_theory`],
+      [Grenzfall zwischen Nachbargebieten],
+      [plausibel, aber mit interpretativem Spielraum],
+
+      [Zig-Lexing],
+      [`cs/theory/compilers/parsing`; optional `cs/programming_languages/zig`],
+      [`cs/theory/compilers/parsing`; `cs/programming_languages/zig`],
+      [Taxonomiegrenze und Sprachbezug],
+      [inhaltlich sinnvoll, zugleich Hinweis auf mögliche Verfeinerung],
+    )
+  ],
+  caption: [Qualitative Fallübersicht des Evaluationslaufs. Die akzeptablen Tags dienen als autorseitige Referenz für diese sechs Beispiele und nicht als statistischer Goldstandard.]
+) <fig:qualitative-evaluation>
+
+=== Angemessenheit
+
+Auf der Ebene der inhaltlichen Angemessenheit wirken die sechs Klassifikationen insgesamt plausibel. Besonders klar ist dies bei den Fällen `Compiler-Intro`, `Compiler-Ressourcen` und `LLVM-Pipeline`, in denen die vorhergesagten Tags den Kern des jeweiligen Beitrags direkt treffen. Beim Buch _Types and Programming Languages_ zeigt sich dagegen ein interpretativer Grenzfall: `cs/theory/type_theory` ist sachlich naheliegend, während `cs/theory/compilers/type_systems` als engere, aber noch vertretbare Spezifizierung gelesen werden kann. Gerade dieser Fall ist für die Evaluation wertvoll, weil er keinen perfekten Treffer im trivialen Sinn zeigt, sondern die Grauzone zwischen benachbarten Teilgebieten sichtbar macht.
+
+=== Spezifität
+
+Ein zentrales Qualitätsmerkmal des Prototyps ist die Tendenz, nicht bei sehr allgemeinen Oberkategorien stehenzubleiben. In mehreren Fällen greift das System auf spezifische Blattknoten wie `cs/theory/compilers/llvm`, `cs/theory/compilers/code_generation`, `cs/theory/compilers/optimization` oder `cs/theory/type_theory` zurück. Dass der Beitrag zum allgemeinen Compiler-Einstieg nur unter `cs/theory/compilers` eingeordnet wird, ist dabei kein Mangel, sondern ein passender Ausdruck des breiten Inhalts. Die Beispiele zeigen daher, dass Spezifität im Evaluationslauf nicht pauschal maximiert, sondern am jeweiligen Material ausgerichtet wurde.
+
+=== Hierarchische Konsistenz
+
+Auch die hierarchische Konsistenz fällt im kleinen Evaluationslauf positiv auf. Die vorhergesagten Tags liegen sämtlich innerhalb der vorhandenen Struktur des Tag-Baums und erzeugen keine offenkundig widersprüchlichen Kombinationen. Beim Zig-Lexing-Beispiel wird zusätzlich sichtbar, dass die bestehende Taxonomie nicht jede feine Unterscheidung bereits explizit enthält: Neben `cs/theory/compilers/parsing` schlug das Modell dort den neuen Tag `cs/theory/compilers/lexical_analysis` vor. Für die Evaluation ist dieser Fall deshalb nützlich, weil er nicht nur einen Treffer, sondern zugleich eine inhaltliche Lücke der aktuellen Hierarchie offenlegt.
+
+=== Robustheit
+
+Im dokumentierten Evaluationslauf konnten alle sechs Beispiele als strukturierte JSON-Ausgaben verarbeitet und in die Datenbank übernommen werden. Für die praktische Robustheit des Systems ist das bedeutsam, weil die Antwort nicht bloß gelesen, sondern maschinell geparst, gespeichert und später wieder exportiert werden muss. Gerade hier zeigt sich der Mehrwert der im Abstract erwähnten strukturierten Modellausgaben: Das JSON-Schema begrenzt die Offenheit der Modellantwort, ermöglicht Retry-Logik bei fehlerhaften Antworten und stellt eine verbindliche Schnittstelle zwischen Sprachmodell und Anwendung bereit. Aussagen über allgemeine Zuverlässigkeit lassen sich aus sechs Fällen zwar nicht ableiten, für den untersuchten Prototyp-Lauf ist die Schnittstelle jedoch funktionsfähig.
+
+=== Praktische Anschlussfähigkeit
+
+Schließlich zeigt der Evaluationslauf eine gewisse praktische Anschlussfähigkeit. Die Ressourcen werden nicht nur einmalig klassifiziert, sondern mit Tags, Begründungen und möglichen Tag-Vorschlägen dauerhaft gespeichert. Dadurch lassen sich Such-, Export- und Review-Schritte an die Klassifikation anschließen. Auch die automatische Behandlung neuer Tag-Vorschläge ist in diesem Sinn anschlussfähig, sollte aber nicht als wissenschaftlich validierte Entscheidung missverstanden werden: Der Schwellenwert von `0.75` ist eine pragmatische Systemeinstellung für den Prototyp, keine statistisch begründete Kalibrierung.
 
 == Fehleranalyse
 
-Die Fehleranalyse zeigt im aktuellen Stand weniger grobe semantische Fehlklassifikationen als vielmehr Grenzen der Taxonomie und der Modellkonsistenz. So wurde der Beitrag über _Types and Programming Languages_ nicht nur unter `cs/theory/type_theory`, sondern zusätzlich unter `cs/theory/compilers/type_systems` eingeordnet. Diese Entscheidung ist inhaltlich noch vertretbar, zeigt aber, dass die Grenzen zwischen benachbarten Unterbereichen der Hierarchie nicht immer trennscharf gezogen werden. Ähnliche Überschneidungen können auch bei Tags wie `analysis`, `optimization` oder `history` auftreten, wenn ein kurzer Beitrag mehrere Aspekte zugleich berührt.
+Die wichtigste Grenze dieser Evaluation liegt in ihrer Anlage selbst. Sechs Beispiele erlauben eine differenzierte qualitative Betrachtung, aber keine belastbare Aussage über allgemeine Leistungswerte des Systems. Hinzu kommt, dass alle Beiträge von X beziehungsweise Twitter stammen und thematisch aus einem relativ engen technischen Umfeld kommen. Die Evaluation beschreibt daher bewusst einen prototypischen Anwendungsbereich und keinen repräsentativen Querschnitt digitaler Ressourcen.
+
+Auch inhaltlich zeigt die Fehleranalyse weniger grobe semantische Fehlklassifikationen als vielmehr Grenzen der Taxonomie und der Modellkonsistenz. So wurde der Beitrag über _Types and Programming Languages_ nicht nur unter `cs/theory/type_theory`, sondern zusätzlich unter `cs/theory/compilers/type_systems` eingeordnet. Diese Entscheidung ist inhaltlich noch vertretbar, zeigt aber, dass die Grenzen zwischen benachbarten Unterbereichen der Hierarchie nicht immer trennscharf gezogen werden. Ähnliche Überschneidungen können auch bei Tags wie `analysis`, `optimization` oder `history` auftreten, wenn ein kurzer Beitrag mehrere Aspekte zugleich berührt.
 
 Auf technischer Ebene traten während der Entwicklung ebenfalls zwei relevante Probleme auf. Erstens zeigte sich, dass eine erzwungene Neuklassifikation mit `--force` zunächst alte und neue Tag-Zuordnungen kumulierte, anstatt die bestehende Zuordnung eines Beitrags zu ersetzen. Zweitens erwies sich eine nachträgliche Normalisierung von Tag-Pfaden als zu unflexibel, weil sie fehlerhafte Modellantworten verdecken konnte. Beide Punkte wurden behoben, verdeutlichen aber, dass die Zuverlässigkeit des Gesamtsystems nicht allein vom Modell abhängt, sondern ebenso von der sauberen Nachverarbeitung seiner Ausgabe.
 
-Die neue Taxonomie-Workflow-Regelung bringt zudem einen bewussten Zielkonflikt mit sich. Automatische Übernahmen oberhalb von `0.75` beschleunigen die Weiterentwicklung des Tag-Baums, beruhen aber weiterhin auf heuristischen Konfidenzwerten des Modells. Deshalb bleibt die manuelle Prüfung über `classifier review-tags` für schwächere oder zweifelhafte Vorschläge notwendig. Die Fehleranalyse zeigt damit, dass nicht nur semantische Treffsicherheit, sondern auch ein klug gestalteter Kontrollmechanismus zur Qualität des Systems beiträgt.
+Die neue Taxonomie-Workflow-Regelung bringt zudem einen bewussten Zielkonflikt mit sich. Automatische Übernahmen oberhalb von `0.75` beschleunigen die Weiterentwicklung des Tag-Baums, beruhen aber weiterhin auf heuristischen Konfidenzwerten des Modells. Deshalb bleibt die manuelle Prüfung über `classifier review-tags` für schwächere oder zweifelhafte Vorschläge notwendig. Ebenso ist zu beachten, dass der Prototyp mit einem nicht deterministischen Sprachmodell arbeitet: Wiederholte Läufe könnten in Grenzfällen andere Tag-Kombinationen hervorbringen. Kosten- und Latenzaspekte sind für reale Anwendungen ebenfalls relevant, wurden in dieser Arbeit aber nicht systematisch gemessen. Die Fehleranalyse zeigt damit, dass nicht nur semantische Treffsicherheit, sondern auch ein klug gestalteter Kontrollmechanismus zur Qualität des Systems beiträgt.
 
 == Stärken und Schwächen des Ansatzes
 
-Eine wesentliche Stärke des entwickelten Ansatzes liegt in seiner unmittelbaren praktischen Einsetzbarkeit ohne vorgängige Trainingsphase. Der aktuelle Testlauf zeigt, dass bereits mit einem bestehenden Tag-Baum und ohne gelabeltes Korpus fachlich differenzierte Zuordnungen entstehen können. Gerade bei kurzen technischen Beiträgen ist das ein relevanter Vorteil, weil hier die Kombination aus Weltwissen, Kontextverstehen und hierarchischer Einordnung besonders gefragt ist. Die hohe Spezifität der vergebenen Tags im Compiler-Datensatz spricht klar dafür, dass der LLM-Ansatz für solche Ressourcen sehr effektiv ist.
+Eine wesentliche Stärke des entwickelten Ansatzes liegt in seiner unmittelbaren praktischen Einsetzbarkeit ohne vorgängige Trainingsphase. Der aktuelle Testlauf zeigt, dass bereits mit einem bestehenden Tag-Baum und ohne gelabeltes Korpus fachlich differenzierte Zuordnungen entstehen können. Gerade bei kurzen technischen Beiträgen ist das ein relevanter Vorteil, weil hier die Kombination aus Weltwissen, Kontextverstehen und hierarchischer Einordnung besonders gefragt ist. Für den hier untersuchten kleinen X-Datensatz erweist sich der LLM-Ansatz deshalb als überzeugend nutzbar.
 
 Eine weitere Stärke ist die Verbindung von Klassifikation und Taxonomiepflege. Der Prototyp speichert nicht nur Tags und Begründungen, sondern kann neue Kategorien kontrolliert in die bestehende Struktur übernehmen. Der automatisch ergänzte Tag `cs/theory/compilers/lexical_analysis` zeigt, dass das System Lücken der Hierarchie nicht nur erkennt, sondern in klaren Fällen auch praktisch schließen kann. Gleichzeitig bleibt durch die Review-Funktion eine menschliche Kontrollinstanz für unsichere Vorschläge erhalten. Hinzu kommt die saubere Modularisierung in Extraktion, Vorverarbeitung, Klassifikation und Speicherung, die das System technisch überschaubar und erweiterbar macht.
 
-Den Stärken stehen dennoch mehrere Schwächen gegenüber. Erstens sind die modellseitigen Konfidenzwerte heuristisch und nicht im statistischen Sinn kalibriert. Zweitens hängt die Qualität stark von der vorhandenen Taxonomie ab. Fehlen passende Kategorien, kann das Modell zwar neue Tags vorschlagen, doch deren automatische Übernahme bleibt eine Abwägung zwischen Tempo und Kontrolle. Drittens besteht eine Abhängigkeit von externen Komponenten, insbesondere vom Python-Scraper und vom LLM-Aufruf über die Codex-CLI. Viertens ist die empirische Basis weiterhin klein und thematisch eng auf Compiler- und Programmierspracheninhalte konzentriert. Der Ansatz ist daher als Prototyp bereits überzeugend, benötigt für eine allgemeine Bewertung jedoch breitere Daten und systematischere Vergleichsmaßstäbe.
+Den Stärken stehen dennoch mehrere Schwächen gegenüber. Erstens sind die modellseitigen Konfidenzwerte heuristisch und nicht im statistischen Sinn kalibriert. Zweitens hängt die Qualität stark von der vorhandenen Taxonomie ab. Fehlen passende Kategorien, kann das Modell zwar neue Tags vorschlagen, doch deren automatische Übernahme bleibt eine Abwägung zwischen Tempo und Kontrolle. Drittens besteht eine Abhängigkeit von externen Komponenten, insbesondere vom Python-Scraper und vom LLM-Aufruf über die Codex-CLI. Viertens ist die empirische Basis weiterhin klein und thematisch eng auf Compiler- und Programmierspracheninhalte konzentriert. Der Ansatz ist daher als Prototyp für einen klar begrenzten Anwendungsfall überzeugend, erlaubt aber keine weitreichenden Aussagen über allgemeine LLM-Qualität bei der Verschlagwortung beliebiger digitaler Ressourcen.
 
 == Ethische und gesellschaftliche Aspekte
 
@@ -288,15 +367,15 @@ Schließlich sind auch Daten- und Plattformfragen relevant. Der aktuelle Prototy
 
 == 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.
+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 mit maschinenlesbarer JSON-Ausgabe 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. Im konkreten Evaluationslauf mit sechs neuen Ressourcen konnten alle sechs Beiträge direkt und mit insgesamt elf fachlich plausiblen Tag-Zuordnungen klassifiziert werden. Die Ergebnisse deckten zentrale Unterbereiche wie Compiler-Optimierung, Codegenerierung, LLVM, Parsing, Zig, Type Systems und Type Theory ab. Zusätzlich wurde mit `cs/theory/compilers/lexical_analysis` ein neuer, modellseitig vorgeschlagener Tag automatisch in den Baum aufgenommen. Damit zeigt der Prototyp nicht nur Klassifikationsfähigkeit, sondern auch eine erste Form kontrollierter struktureller Weiterentwicklung.
+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. Im konkreten Evaluationslauf mit sechs bewusst ausgewählten Ressourcen konnten alle sechs Beiträge direkt und mit insgesamt elf fachlich plausiblen Tag-Zuordnungen klassifiziert werden. Die Ergebnisse deckten zentrale Unterbereiche wie Compiler-Optimierung, Codegenerierung, LLVM, Parsing, Zig, Type Systems und Type Theory ab. Zusätzlich wurde mit `cs/theory/compilers/lexical_analysis` ein neuer, modellseitig vorgeschlagener Tag automatisch in den Baum aufgenommen. Damit zeigt der Prototyp nicht nur Klassifikationsfähigkeit, sondern auch eine erste Form kontrollierter struktureller Weiterentwicklung in seinem begrenzten Anwendungsfenster.
 
 == 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 klar positiv beantworten. Der durchgeführte Testlauf zeigt, dass LLMs kurze technische Ressourcen bereits ohne projektspezifisches Training sehr wirksam semantisch einordnen können, sofern der Tag-Baum passende fachliche Ankerpunkte bereitstellt. Gerade bei kontextreichen Kurztexten aus dem Bereich Compilerbau und Programmiersprachen erwies sich der Ansatz als erstaunlich treffsicher und ausreichend spezifisch.
+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 nicht allgemein, wohl aber für den untersuchten Anwendungsfall vorsichtig positiv beantworten. Der durchgeführte Testlauf legt nahe, dass LLMs kurze technische Ressourcen bereits ohne projektspezifisches Training brauchbar semantisch einordnen können, sofern der Tag-Baum passende fachliche Ankerpunkte bereitstellt. Gerade bei kontextreichen Kurztexten aus dem Bereich Compilerbau und Programmiersprachen erwies sich der Ansatz als vielversprechend und ausreichend spezifisch.
 
-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. Außerdem sinkt die Zuverlässigkeit bei inhaltsarmen oder stark dialogischen Beiträgen deutlich. 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 bereits jetzt ein sehr leistungsfähiges Werkzeug zur semantischen Vorstrukturierung von Ressourcen.
+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. Außerdem sinkt die Zuverlässigkeit bei inhaltsarmen oder stark dialogischen Beiträgen vermutlich deutlich, ohne dass dies mit dem hier gewählten kleinen Datensatz bereits belastbar gezeigt werden könnte. 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 praktikables Werkzeug zur semantischen Vorstrukturierung klar technischer Ressourcen.
 
 == Ausblick auf zukünftige Entwicklungen
 

docs/template.typ

@@ -48,8 +48,7 @@
   // Inhaltsverzeichnis on a new page, then continue without page break
   #pagebreak()
   #set align(left)
-  #heading(level: 1, numbering: none, outlined: false)[Inhaltsverzeichnis]
-  #outline()
+  #outline(title: [Inhaltsverzeichnis])
 
   // Document body
   #pagebreak()