/
Kompendiale Texte generieren
Document toolboxDocument toolbox

Kompendiale Texte generieren

Owned by Manuel Kummerländer
Feb 18, 2025
14 min read

Definition

Ein Kompendium gibt Überblick über ein bestimmtes Fachgebiet und fasst die wesentlichen Informationen prägnant zusammen. Als Datengrundlage in Generierungsprozessen können sie Klarheit, Präzision und Konsistenz der Daten verbessern und helfen dabei Mehrdeutigkeiten zu vermeiden.

Erstellungsprozess

Ziel ist es, prägnante, qualitativ hochwertige Texte zu erstellen, die einen klaren Überblick über das Thema bieten. In Anlehnung an die Erstellung eines Kompendiums kann man folgende Prozess-Schritte nutzen:

  1. Zielsetzung klären

    1. Zielgruppe und Ausrichtung festlegen z.B. für Lehrende, Bildungsstufe, Fachbereich …

    2. Umfang festlegen (wie detailliert sollte der Text werden)

  2. Informationssammlung

    1. relevante Ideen und Materialien sammeln

  3. Konzepte und Themen bestimmen und hervorheben

    1. spezifische Entitäten wie Personen, Orte, Organisationen oder Fachbegriffe im gesammelten Material mit Named Entity Recognition (NER) identifizieren

  4. Verknüpfung mit Wissensdatenbank

    1. mit Named Entity Linking (NEL) an Wissensdatenbanken anbinden um die Datenqualität zu verbessern und potenzielle Lücken zu schließen (mögl. Datenbanken sind z.B. Wikipedia, Wikidata, DBPedia usw.)

  5. Struktur des kompendialen Text planen

    1. Gliederung erstellen und Entitäten einbeziehen (Haupt- und Unterpunkte)

    2. Reihenfolge festlegen

    3. Optional: können Beziehungen zwischen den Entitäten dargestellt werden

  6. Inhalte zusammenfassen und verdichten

    1. wesentliche Informationen extrahieren

    2. kürzen und präzisieren

  7. Überarbeitung / Feedback

    1. Kohärenz und Konsistenz über den gesamten Text herstellen

    2. einheitliche und sprachlich passende Begriffsverwendung für die Zielgruppe

 

Welcher Prozess wird projektintern für QA Paare vorgeschlagen?

image-20250117-085235.png

  • gesäuberte Volltexte = Informationssammlung

  • Themenbestimmung = Konzepte und Themen bestimmen (NER)

  • Wikidata, DBPedia, … = Verknüpfung mit Wissensdatenbanken (NEL)

Use-Case KI-Workflow (Stand 01/2025)

image-20250117-095706.png
KI Workflow vom Coworking am 08.01.2025

Geplant ist die Generierung des kompendialen Textes auf Basis des generierten Themenbaums, der in einer Sammlungsstruktur vorliegt oder bereits im Schritt der Themenbaum-Erstellung.

Use-Case 1: vor der Themenbaumgenerierung

  • keine Grundstruktur vorhanden

  • Verfahren zur Extraktion von Strukturen aus Dokumenten der Domäne ist notwendig

  • umfangreiche Textgrundlage vorhanden

Use-Case 2: nach der Themenbaumgenerierung

  • Grundstruktur ist bereits vorhanden und kann genutzt werden (z.B. durch Einbezug unterer Ebenen, um einen Teil der Gliederung zu übernehmen)

  • nur unzureichende Textgrundlage der Sammlungen → Titel, Beschreibungstext und einige Keywords

  • Volltextextraktion ist ohne Inhalte in den Sammlungen nicht möglich

Use-Case 3: nach der Themenbaumgenerierung und Inhaltszuordnung

  • Grundstruktur ist bereits vorhanden und kann genutzt werden (z.B. durch Einbezug unterer Ebenen, um einen Teil der Gliederung zu übernehmen)

  • bessere Textgrundlage der Sammlungen → Infos aus den zugehörigen Inhalte können genutzt werden

  • Volltextextraktion für Inhalte ist möglich

Vorhandene Services

OER Recommender von Yovisto

Gibt Inhalte und mit diesen verknüpfte andere Inhalte und Personen (Entitäten) zurück. Arbeitet auf Basis von Knowledge-Graphen. Knoten sind mit Schema.org und DBPedia verbunden. Nutzt die Entitäten und Kategorien für die Analyse von Überschneidungen/Verbindungen.

URL: https://yovisto.github.io/its-rec/

Analyse und Tests zum Service: Analyse Service: OER Recommender

Entitäten Extraktion von Yovisto

Text kann durch Anhang an die Dienst-URL übergeben werden. Liefert Entitäten und zugehörige Kategorien im JSON Format zurück. Liefert zusätzlich den Input Text angereichert um URLs zu Wikipedia Artikel zurück. Die Inhalte der Artikel oder Beschreibungen von DBPedia und Wikidata sind nicht direkt verfügbar.

URL (Abruf durch anhängen des Textes): https://wlo.yovisto.com/services/extract/Weimar+in+Thüringen

Findet 2 Entitäten => “Thüringen” und “Weimar”

  • scheint fast alle im Text enthaltenen Entitäten zu erkennen

  • Fehler können bei sehr kurzen Beschreibungen oder einzelnen Begriffen auftreten wie z.B. bei Addition (hat Addition mit Bezug zu Mathematik erst genannt, nachdem der String komplexer wurde)

  • bei allgemeinen Begriffen / Entitäten liefert es teils kontextferne Infos

  • Textoutput zu den Entitäten gibt es nicht (mit Ausnahme der Kategorielisten)

    • es ist jedoch möglich die Wikipedia-URL aus dem angereicherten Text zu extrahieren

  • Wikidata oder DBPedia Id sind nicht zugänglich - es wird immer nur der Name der Entität genannt

  • im NER Prozess bestimmte Klassen der Entitäten sind nicht sichtbar

  • mit längeren Texten ab ca. 2 Absätzen kann der Dienst nicht umgehen

Analyse und Tests zum Service: Analyse Service: Entitäten Extraktion von Yovisto

Kidra Volltext-Extraktion

Gibt bereinigten Volltext zu einer URL zurück. Es kann zwischen simpler und browserbasierter Methode (für Webseiten mit Javascript) gewählt werden. Erfordert keine generative KI.

URL: Python-Kidra Staging

  • die Volltextextraktion liefert Text-Output (keine strukturierten Markdown)

  • Textoutput ist z.T. nicht sauber gefiltert und enthält noch Zeilenumbrüche (für KI aber unkritisch)

  • die Extraktion von Seiten wie LeifiPhysik schlägt z.T. mit beiden Methoden (simple und browser) fehl

  • die Extraktion von komplexen Seiten wie bpb liefert teilweise nur die einleitenden Absätze - aber nicht den Rest Seite

  • Andreas hat im Ticket https://edu-sharing.atlassian.net/browse/GEN-32 einige Problemstellen dokumentiert, die sich teilweise mit den Beobachtungen überschneiden:

    • HTTP-Status-Codes ungenügend:

    • Keine klare Rückmeldung über die Verfügbarkeit oder den Status der Zielseite (z. B. 404-Fehlerseiten).

    • Probleme mit JavaScript-lastigen Webseiten:

      • Volltext wird nicht extrahiert, wenn Seiten stark auf JavaScript angewiesen sind.

    • Unpräzise Volltexte:

      • Extrahierter Text ist oft generisch oder unvollständig (z. B. Beschreibungen statt tatsächlichem Inhalt).

    • Cloudflare-geschützte Webseiten:

      • Seiten mit Bot-Management durch Cloudflare sind nicht auslesbar.

    • Instabilität bei hoher Anfragefrequenz:

      • API reagiert unberechenbar bei zu vielen Anfragen und liefert HTTP 500.

      • Notwendigkeit von Throttling für stabile Nutzung (z. B. 45 Requests/Minute).

    • Fehlende Infrastrukturklarheit:

      • Unklare Konfiguration und Nutzung des Headless Browsers innerhalb der API.

    • Edge-Cases unvermeidbar:

      • Technische und inhaltliche Ausnahmen bleiben bestehen, trotz möglicher Verbesserungen.

  • Service hat noch keinen Produktiv-Status auf Grund der genannten Fehler

Analyse und Tests zum Service: Analyse Service: KIDRA Volltextextraktion

Kidra Link-Wikipedia

Gibt relevante Wikipedia Artikel zu einem Text zurück und liefert zusätzlich eine angepasste Version des Textes, indem die Artikel verlinkt sind.

URL Python-Kidra Staging

  • scheint eine minimal veränderte Version des Yovisto Entitäten Extraktions-Dienst zu sein und hat nur minimale Unterschiede zu diesen

  • der inhaltliche Output ist identisch - es gibt nur kleine Unterschiede in der Formatierung von Scorings und URL´s

  • mit längeren Texten ab ca. 2 Absätzen kann der Dienst nicht umgehen

Triple Store

Enthält WLO Daten sowie Wissen aus diversen Datenquellen, das miteinander vernetzt ist. Genaue Evaluation ist noch offen. Infos dazu werden gesammelt.

URL Analyse Service: Triple Store & SPARQL

Anmerkung zu den Diensten

Der Yovisto Dienst bzw. KIDRA Wikipedia Linker geben Kategorien zurück, die mit dem Begriff in Verbindung stehen können (aber nicht müssen!) wie z.B. zu Lichtmikroskop die Kategorie Gerätebau. Es werden also auch möglicherweise unrelevante Kategorien ausgegeben. Arbeitet mit längeren Texten (ab zwei Absätzen) nicht fehlerfrei. Teils streuen die Kategorien auch in andere Bereiche aus.

Für die Bestimmung von Überschneidungen von Kategorien wie im Recommender ist dies nicht jedoch nicht relevant und kann dabei helfen Wissen zu strukturieren z.B. durch Überschneidung der Kategorie Städte in Thüringen für Weimar und Erfurt. Auch für Empfehlungen oder das Metadaten-Management ist dies vorteilhaft.

Eine Funktion die beschreibende Texte zu den Entitäten wiedergibt, um z.B. kompendiale Texte zu bilden, scheint es jedoch nicht zu geben. Man könnte sich jedoch der angebotenen Wikipedia URL bedienen und diese mittels Volltextextraktion auslesen. Eine Option zum Auslesen der Wikidata-Beschreibungen ist nicht direkt verfügbar.

Es ist davon auszugehen das NER und NEL Prozesse im Backend zusammengelegt laufen und nicht alle Prozessdetails nach außen geben.

Die Volltext-Extraktion scheint noch zu viele Probleme zu haben, als das man sie produktiv nutzen könnte. Hier wäre zu prüfen, ob man die dahinter liegenden Frameworks gegen aktuellere Software austauschen könnte z.B. Crawl4AI oder für die simple Variante: newspaper4k/goose3.

Zum OER Recommender gibt es auf https://edu-sharing.atlassian.net/wiki/spaces/ITsJOINTLY/pages/182648836 eine Beschreibung. Die Verlinkung anderer Inhalte klappt gut, wobei es jedoch teilweise zu nicht nachvollziehbaren Empfehlungen aus anderen Fachbereichen kommen kann. Die in der Beschreibung erwähnte Nutzung externer Informationen ist potentiell über die Entitäten Id die ermitteln werden möglich - aber nicht live abrufbar. Es werden keine Wikipedia- oder Bilbiotheks URL angezeigt.

SPARQL Abfragen auf den Triple Store könnten eigene gute Möglichkeit sein, um an den nötigen Kontext zu kommen. Eventuell kann ein besser zugängliches Interface für häufig genutzte Abfragen geschaffen werden.

Pipelines

Pipeline für inhaltsleere Themenbäume/Sammlungen (Use-Case 2)

Analyse der Bedingungen

  • es können in diesem Szenario mit inhaltsleeren Sammlungen keine Inhalte ausgelesen und als Daten-Basis verwendet werden

  • es können keine gesammelten PDF mit Wissen ausgewertet werden, sofern es dafür keine Funktion wie z.B. eine Vektordatenbank oder ähnliches gibt

  • unsere Dienste zur Entitäten-Ermittlung können Kategorien auf Basis der Beschreibungstexte der Sammlungen/Untersammlungen liefern

    • diese führen aber alle mit dem Begriff verbundenen Kategorien und streuen in anderen Bereiche

  • auf Basis von Entitäten Wissen abzurufen ist bei einer kleiner Textmenge (2-3 Zeilen Beschreibungstext) ungenau und repräsentiert nicht das Wissen, das die Sammlung umfasst

  • mit größeren Textmengen funktionieren unsere Entität-Services nicht

    • diese können nur Satzweise arbeiten → macht sie langsam und es geht Kontext verloren

  • unsere Services liefern keine Beschreibungstexte zu den Entitäten

    • es gibt die Möglichkeit mit zuvor genannten Service Wikipedia URL zu erhalten

  • große Sprachmodelle wie z.B. gpt-4o-mini sind auf Wikipedia trainiert und können die URL in der Regel auch recht treffsicher ermitteln

  • große Sprachmodelle können größere Textmenge in einem Schritt verarbeiten und so den Kontext nutzen

  • Detailwissen kann von Quellen wie Wikipedia, Wikidata, DBPedia einbezogen werden

  • Domän-spezifisches Wissen könnte eventuell mit einer Internetsuche über Duckduckgo integriert werden

Prozess-Schritte

  1. Erweiterung der Textbasis zu jeder Sammlung
    Erhöht die Treffsicherheit und Vielfalt bei der nachfolgenden Entitäten-Extraktion

    1. Prompt zur Erstellung eines 1-2 Seiten langen zusammenfassenden Textes basierend auf dem Kontext des gesamten Themenbaums, den Metadaten des Themenbaums (Bildungsstufe, Bildungssektor, Fach …) und dem Verweis auf die Sammlung, für die der Text sein soll

    2. Steuerung der Länge kann u.a. über die Tokenvorgaben erfolgen (2 Seiten sollten jedoch reichen, um die wichtigsten Entitäten zu finden)

    3. falls ein deutlich umfangreicherer Text benötigt wird, muss Schritt 1 in zwei Teile verteilt werden - 1. Schritt wäre dann die Erstellung der Gliederung und Schritt 2 die Abarbeitung der Gliederungselemente mit entsprechender Textgenerierung.

  2. Extraktion von Entitäten (NER) und Linking der Wissensquelle Wikipedia (NEL)
    Um weiteres Wissen anbinden zu können, werden die Entitäten bestimmt (NER) und mit Wissensquellen verlinkt (NEL)

    1. für die Entitäten-Extraktion wird der Text aus dem ersten Prozess Schritt verwendet und mit einem großen LLM verarbeitet, da dies den Kontext gut versteht und schneller arbeitet als unsere eigenen Dienste, die satzweise vorgehen müssen (NER)

    2. da große LLM auf Wikipedia trainiert sind kann gleich ein Teil des Entitäten Linking auf Wikipedia mit erledigt werden - es können damit bereits 80% der Wikipedia URL korrekt generiert werden (für 100% Treffsicherheit braucht es eine zusätzlich Korrekt-Runde) → OutPut: Entitäten, Klassen, Wikipedia-URLs

    3. Alternativen zum großen LLM:

      1. zshot von IBM ist ein gutes Framework für NER/NEL Aufgaben, das u.a. mehrere von Facebook auf Wikipedia und Wikidata trainierte Modelle vereint für NEL Aufgaben enthält

      2. unsere eigenen Dienste können Satzweise arbeiten (langsamer, mit geringeren Kontext)

  3. (Optional) Verbesserung des Linking auf Wikipedia (NEL)
    In diesen optionalen Schritt können für die ca. 20 % der Entitäten, wo keine Wikipedia-Texte abgerufen werden konnten nochmals mit einer Suche nach korrekten URL gesucht werden. Dadurch steigt die Qualität bis fast 100%. Dieser Schritt kann über die wikipedia Bibliothek oder per request auf https://www.wikidata.org/w/api.php durchgeführt werden.

    1. Kombination von Schritt 2 und 3 spart Zeit im Vergleich zu klassischen Abfragen

  4. Linking von weiteren Wissensquellen (NEL) z.B. Wikidata
    Mit den in Schritt 2 (und 3) ermittelten Entitäten kann man weitere Wissensdatenbanken verlinken. Dies kann mit einem NEL-Model erfolgen (siehe z.B. bei IBM zshot) oder direkt über die API/Suchangebote der Wissensquellen erfolgen. Hier exemplarisch mit Wikidata:

    1. Übergabe der Entitäten an die Wikidata-Suche (die Wikidata Action API wird über eine GET-Anfrage an den Endpunkt https://www.wikidata.org/w/api.php aufgerufen. Der Parameter action bestimmt, welche Aktion die API ausführen soll. Zwei zentrale Aktionen sind:

      • wbsearchentities: Sucht nach Entitäten anhand von Labels und Aliasen

      • wbgetentities: Ruft alle Details einer Entität anhand ihrer ID ab

    2. Bestimmung der Übereinstimmung der abrufen Kandidaten, mit den in Schritt 2 ermittelten Infos zu den Entitäten

      1. wahlweise via LLM → genau/schnell

      2. oder via Cosine Similarity → billiger/etwas ungenauer (z.B. mit sklearn.metrics.pairwise cosine_similarity)

    3. mehr Details zur Ansprache von Wikidata: https://medium.com/@dreamai/linking-extracted-entities-to-wikidata-why-and-how-168eacb4fb87

  5. (Optional) Zusammenführung der Texte aus Schritt 1 bis 4
    Die in Schritt 1 gebildete Textbasis kann jetzt um die Referenzen der Wissensquellen ergänzt werden. Dieser Schritt ist jedoch optional, da die Zusammenführung auch im Prompt erfolgen kann (ist eventuell günstiger und lässt mehr Spielraum für Anpassungen)

  6. (Optional) Wissen aus dem Internet
    Abfrage einer Suchmaschine zum Sammlungsthema → liefert teilweise mehr spezifisches Wissen → streut aber auch stärker

    1. Abfrage von Duckduckgo oder ähnlicher Suche mit Sammlungsnamen + Bildungsstufe

    2. erfordert eventuell das Auslesen von PDF Files

  7. QA Paare bilden

    1. Kontext und Wissen wird an Prompt für die QA Paare übergeben. Parameter können die Auswahl des zu übergebenden Wissens, die Anzahl der QA Paare und deren Zeichen längen sein (mehr Wissen → längerer Generierungsdauer; längere QA Paare → längere Generierungsdauer)

    2. QA Paare sollten zwischen 200 und 300 Zeichen lang sein - andere Werte können jedoch getestet werden

    3. gpt-4o und gpt-4o-mini beherrschen bis zu 16000 Output Token - wenn die Aufrufe entsprechend eingestellt werden, sind 20-30 QA Paare kein Problem

    4. zu übergebendes Wissen:

      1. Kontext Metadaten Themenbaum (Bildungsstufe, Fach, Bildungssektor …)

      2. Sammlungstitel, Beschreibung, Keywords

      3. Optional 1: kompendiale Texte aus Schritt 1

      4. Optional 2: zusätzlich Beschreibungstexte (z.B. Wikipedia) der Entität übergeben

      5. Optional3 : Textkorpus der Internetsuche übergeben

    5. die beste Qualität ist wahrscheinlich mit dem max. Info-Input zu erwarten

    6. der Prompt sollte Formatierungs- und Qualitätshinweise für Bildung enthalten

    7. der Prompt kann auf die Nutzung verschiedener Fragetypen hingewiesen werden siehe: Frage-Antwort-Paare

image-20250121-105828.png
Ergebnis von Schritt 1 (Erweiterte Textgrundlage)
image-20250121-105914.png
Ergebnis von Schritt 2 (und 3) (NER und NEL mit Wikipedia)
image-20250122-090615.png
Ergebnis QA Paare mit gemischten Fragetypen und 300 Zeichen Länge bei max. Input

Demo-Code

Code-Repo (Stand: 22.01.25): https://github.com/janschachtschabel/topictreegenerator

Google Colab Notebook der Demo: https://colab.research.google.com/drive/15D_Uu8FRlaYgWk6jQRNn7EBlbziSfHxw?usp=sharing

Muster-Output: https://drive.google.com/file/d/1SnFuiX6K6YaQUDHF2wr3U2KElc5wI0vT/view?usp=sharing

  • Programm-Code

    • Python

  • Funktionen

    • Generierung Themenbäume

      • Anzahl der Sammlungen/Untersammlungen für alle 3 Ebenen sowie Kontext kann angegeben werden

      • neu: von YwD empfohlene Kategorien “Allgemeines” und “Methodik und Didaktik” können angefordert werden

    • Generierung kompendiale Texte

      • Erweiterung Textgrundlage je Sammlung/Untersammlung

      • Extraktion von Entitäten mit GPT (NER)

      • Linking der Entitäten zu Wikipedia/Wikidata (NEL) mit GPT Unterstützung

    • Generierung von QA Paaren

      • mit verschiedenen Parametern testbar (Anzahl der QA Paare, übergebenes Wissen, Zeichenlänge …)

      • Prompt für Bildung ist bereits integriert

Screenshot 2025-01-22 103055.png
Screenshot 2025-01-22 104449.png

Fazit und Fragen zur Pipeline

fragekiworkflow.png

  • Frage: Sollten nach der Generierung des Themenbaums in einer Sammlungsstruktur zuerst Inhalte eingeordnet und diese in die Erzeugung kompendialer Texte einbezogen werden?

    • pro: Wissen könnte auf den Inhalten basieren > Texte und QA Paare werden spezifischer und können eventuell Details enthalten, die über allgemeines KI Wissen hinaus geht

    • contra: dadurch wird eventuell nicht das Weltwissen im kompendialen Text abgebildet, sondern nur das Wissen, das durch die aktuellen Inhalte verfügbar ist → dynamische QA Generierung wird erforderlich

    • contra: erfordert eventuell Volltextabrufe der Inhalte, um die Beschreibungstexte anzureichern

    • Experiment wurde hierfür bei Beschreibungstexten bereits vorgenommen

  • Frage: Könnte man anbieten einen erzeugten Themenbau automatisch mit einer Vorauswahl an Inhalte zu füllen (es könnte auf den Such-Pool zugegriffen werden)

    • pro: eventuell ein Einsatzgebiet für den Recommender?

    • contra: löschen unpassender Inhalte kann die Redaktion auch mehr Arbeit kosten

  • Frage: Können eigene Services effektiv eingesetzt werden?

    • es ist möglich DBPedia Beschreibungen aus dem Tripplestore zu holen

    • ob dies für andere Wissensquellen auch möglich ist, müßte nochmal besprochen werden

  • Frage: Wieviele QA Paare werden für unseren Use-Case benötigt?

    • Was soll mit den QA Paaren der Sammlungen gemacht werden?

  • Frage: Welches Wissen ist noch im Triple Store verfügbar und wie können SPARQL Abfragen dazu formuliert werden?

    • Nutzung des bereits vorhandenen Datenspeichers prüfen, um eigene Dienste stärker in den Fokus zu rücken.

  • Frage: Kann der Einbezug von Wissen aus einer Intersuche (Duckduckgo) spezifisches Wissen z.B. für die Schule einbringen, was mit Wikipedia nicht möglich ist?

Pipeline für Themenbäume/Sammlungen mit Inhalten (Use-Case 3)

Analyse der Bedingungen

  • es können in diesem Szenario die Inhalte der Sammlungen genutzt werden, um zusammenfassend die Sammlung zu beschreiben

    • Risiko: diese entsprechen dann dem Füllstand der Sammlung und müssen nicht zwingend das Welt-Wissen repräsentieren → macht es eventuell notwendig diesen Vorgang später erneut zu starten

    • Vorteil: Sammlung repräsentiert die Inhalte genauer

  • es können keine gesammelten PDF mit Wissen ausgewertet werden, sofern es dafür keine Funktion wie z.B. eine Vektordatenbank oder ähnliches gibt

  • unsere Dienste zur Entitäten-Ermittlung können Kategorien auf Basis der Beschreibungstexte der Sammlungen/Untersammlungen liefern

    • diese führen aber alle mit dem Begriff verbundenen Kategorien auf und streuen in anderen Bereiche

  • auf Basis von Entitäten Wissen abzurufen ist bei einer kleiner Textmenge (2-3 Zeilen Beschreibungstext) ungenau und repräsentiert nicht das Wissen, das die Sammlung umfasst

  • mit größeren Textmengen funktionieren unsere Entität-Services nicht

    • diese können nur Satzweise arbeiten → macht sie langsam und es geht Kontext verloren

  • unsere Services liefern keine Beschreibungstexte zu den Entitäten

    • es gibt die Möglichkeit mit zuvor genannten Services Wikipedia URL zu erhalten

  • große Sprachmodelle wie z.B. gpt-4o-mini sind auf Wikipedia trainiert und können die URL in der Regel auch recht treffsicher ermitteln

  • große Sprachmodelle können größere Textmenge in einem Schritt verarbeiten und so den Kontext nutzen

  • Detailwissen kann von Quellen wie Wikipedia, Wikidata, DBPedia einbezogen werden

  • Domän-spezifisches Wissen könnte eventuell mit einer Internetsuche über Duckduckgo integriert werden

Prozess-Schritte

  1. Erweiterung der Textbasis zu jeder Sammlung
    Erhöht die Treffsicherheit und Vielfalt bei der nachfolgenden Entitäten-Extraktion

    1. Prompt zur Erstellung eines 1-2 Seiten langen zusammenfassenden Textes basierend auf dem Kontext des gesamten Themenbaums, den Metadaten des Themenbaums (Bildungsstufe, Bildungssektor, Fach …) und dem Verweis auf die Sammlung, für die der Text sein soll

    2. Steuerung der Länge kann u.a. über die Tokenvorgaben erfolgen (2 Seiten sollten jedoch reichen, um die wichtigsten Entitäten zu finden)

    3. falls ein deutlich umfangreicherer Text benötigt wird, muss Schritt 1 in zwei Teile verteilt werden - 1. Schritt wäre dann die Erstellung der Gliederung und Schritt 2 die Abarbeitung der Gliederungselemente mit entsprechender Textgenerierung.

  2. Extraktion von Entitäten (NER) und Linking der Wissensquelle Wikipedia (NEL)
    Um weiteres Wissen anbinden zu können, werden die Entitäten bestimmt (NER) und mit Wissensquellen verlinkt (NEL)

    1. für die Entitäten-Extraktion wird der Text aus dem ersten Prozess Schritt verwendet und mit einem großen LLM verarbeitet, da dies den Kontext gut versteht und schneller arbeitet als unsere eigenen Dienste, die satzweise vorgehen müssen (NER)

    2. da große LLM auf Wikipedia trainiert sind kann gleich ein Teil des Entitäten Linking auf Wikipedia mit erledigt werden - es können damit bereits 80% der Wikipedia URL korrekt generiert werden (für 100% Treffsicherheit braucht es eine zusätzlich Korrekt-Runde) → OutPut: Entitäten, Klassen, Wikipedia-URLs

    3. Alternativen zum großen LLM:

      1. zshot von IBM ist ein gutes Framework für NER/NEL Aufgaben, das u.a. mehrere von Facebook auf Wikipedia und Wikidata trainierte Modelle vereint für NEL Aufgaben enthält

      2. unsere eigenen Dienste können Satzweise arbeiten (langsamer, mit geringeren Kontext)

  3. (Optional) Verbesserung des Linking auf Wikipedia (NEL)
    In diesen optionalen Schritt können für die ca. 20 % der Entitäten, wo keine Wikipedia-Texte abgerufen werden konnten nochmals mit einer Suche nach korrekten URL gesucht werden. Dadurch steigt die Qualität bis fast 100%. Dieser Schritt kann über die wikipedia Bibliothek oder per request auf https://www.wikidata.org/w/api.php durchgeführt werden.

    1. Kombination von Schritt 2 und 3 spart Zeit im Vergleich zu klassischen Abfragen

  4. Linking von weiteren Wissensquellen (NEL) z.B. Wikidata
    Mit den in Schritt 2 (und 3) ermittelten Entitäten kann man weitere Wissensdatenbanken verlinken. Dies kann mit einem NEL-Model erfolgen (siehe z.B. bei IBM zshot) oder direkt über die API/Suchangebote der Wissensquellen erfolgen. Hier exemplarisch mit Wikidata:

    1. Übergabe der Entitäten an die Wikidata-Suche (die Wikidata Action API wird über eine GET-Anfrage an den Endpunkt https://www.wikidata.org/w/api.php aufgerufen. Der Parameter action bestimmt, welche Aktion die API ausführen soll. Zwei zentrale Aktionen sind:

      • wbsearchentities: Sucht nach Entitäten anhand von Labels und Aliasen

      • wbgetentities: Ruft alle Details einer Entität anhand ihrer ID ab

    2. Bestimmung der Übereinstimmung der abrufen Kandidaten, mit den in Schritt 2 ermittelten Infos zu den Entitäten

      1. wahlweise via LLM → genau/schnell

      2. oder via Cosine Similarity → billiger/etwas ungenauer (z.B. mit sklearn.metrics.pairwise cosine_similarity)

    3. mehr Details zur Ansprache von Wikidata: https://medium.com/@dreamai/linking-extracted-entities-to-wikidata-why-and-how-168eacb4fb87

  5. (Optional) Zusammenführung der Texte aus Schritt 1 bis 4
    Die in Schritt 1 gebildete Textbasis kann jetzt um die Referenzen der Wissensquellen ergänzt werden. Dieser Schritt ist jedoch optional, da die Zusammenführung auch im Prompt erfolgen kann (ist eventuell günstiger und lässt mehr Spielraum für Anpassungen)

  6. Abruf der Metadaten der Inhalte
    Die Inhalte der Sammlungen werden ausgelesen. Je nach Umfang könnte man dann eine Kombination einiger Metadatenfelder nutzen, um einen Textkorpus zu bilden.

    1. Titel + Beschreibungstext + Keywords (kann zu großen Kontext ergeben)

    2. Titel + Keywords (Minimal-Variante)

  7. (Optional) Wissen aus dem Internet
    Abfrage einer Suchmaschine zum Sammlungsthema → liefert teilweise mehr spezifisches Wissen → streut aber auch stärker

    1. Abfrage von Duckduckgo oder ähnlicher Suche mit Sammlungsnamen + Bildungsstufe

    2. erfordert eventuell das Auslesen von PDF Files

  8. QA Paare bilden

    1. Kontext und Wissen wird an Prompt für die QA Paare übergeben. Parameter können die Auswahl des zu übergebenden Wissens, die Anzahl der QA Paare und deren Zeichen längen sein (mehr Wissen → längerer Generierungsdauer; längere QA Paare → längere Generierungsdauer)

    2. QA Paare sollten zwischen 200 und 300 Zeichen lang sein - andere Werte können jedoch getestet werden

    3. gpt-4o und gpt-4o-mini beherrschen bis zu 16000 Output Token - wenn die Aufrufe entsprechend eingestellt werden, sind 20-30 QA Paare kein Problem

    4. zu übergebendes Wissen:

      1. Kontext Metadaten Themenbaum (Bildungsstufe, Fach, Bildungssektor …)

      2. Sammlungstitel, Beschreibung, Keywords

      3. Optional 1: kompendiale Texte aus Schritt 1

      4. Optional 2: zusätzlich Beschreibungstexte (z.B. Wikipedia) der Entität übergeben

      5. Optional 3: Textkorpus der Inhalte

      6. Optional 4: Textkorpus aus der Internetsuche

    5. die beste Qualität ist wahrscheinlich mit dem max. Info-Input zu erwarten

    6. der Prompt sollte Formatierungs- und Qualitätshinweise für Bildung enthalten

    7. der Prompt kann auf die Nutzung verschiedener Fragetypen hingewiesen werden siehe: Frage-Antwort-Paare

Related content