RAG-Chatbot: Technische Dokumentation

1.1 Was ist Retrieval-Augmented-Generation (RAG)?

Bei RAG-Systemen können Large Language Models (LLMs) – dazu zählen etwa die GPT-Modellreihe von OpenAI, die Mistral-Reihe der Firma Mistral AI oder Metas Llama - um zusätzliche externe Wissensquellen (z. B. den AI Act) erweitert werden, ohne dass das LLM aufwändig neu mit diesen zusätzlichen Daten trainiert werden muss. Die Anfangsbuchstaben RAG stehen für die einzelnen Arbeitsschritte, die das RAG-System durchläuft, um eine Antwort auf eine Benutzeranfrage zu generieren:

1. Relevante Quellen erheben - „Retrieve”
2. Anfrage (Prompt) um die relevanten Quellen erweitern - „Augment“
3. Antwort erstellen - „Generate“

Im Zusammenhang mit dem Einsatz von RAG-Systemen (etwa für das Wissensmanagement in Unternehmen) wird immer wieder die Frage gestellt, wo es welche Datenflüsse gibt und wie es um die Data Privacy bestellt ist. Die vorliegende Implementierung des RTR AI Act Chatbots zeigt, dass in allen Verarbeitungsschritten alle Daten lokal bleiben können: Sowohl die externen Wissensquellen, die Benutzereingaben als auch das LLM können auf eigener Hardware betrieben werden.

1.2 Überblick zu den Arbeitsschritten des RAG-Chatbots

Damit eine Anfrage von einem RAG-System inhaltlich korrekt beantwortet werden kann, müssen die für eine Beantwortung relevanten Daten erhoben werden. Dazu gibt es verschiedene Möglichkeiten, eine davon ist „Neural Retrieval“. Dabei wird davon ausgegangen, dass jene Dokumente für die Fragenbeantwortung am relevantesten sind, die der Frage semantisch am „ähnlichsten“ sind. Technisch wird dazu ein s.g. „Embedding Model“ verwendet. Damit also eine Frage verarbeitet werden kann, muss sie zunächst mit einem Embedding Modell in einen sogenannten Anfragevektor umgewandelt werden.

Vektoren sind einfach Listen von Zahlen bzw. Koordinaten in einem mehrdimensionalen Raum und diese Zahlen bzw. Koordinaten repräsentieren bestimmte Eigenschaften oder Merkmale des Textes (s.u. für eine detaillierte Erklärung). Ebenso wird mit den externen Wissensquellen (hier der Text des AI Acts und Material der KI-Servicestelle in der RTR) verfahren, wobei in beiden Fällen dasselbe Embedding Modell verwendet werden muss. Doch bevor die Texte der externen Wissensquellen vektorisiert werden können, müssen sie zunächst einmalig in Abschnitte, sogenannte Chunks, unterteilt werden. Das kann automatisiert passieren (in Fließtext etwa durch überlappende Teile) oder manuell. Im Fall des AI Act RAGs wurde ein eigenes Tool verwendet: das Annotation Tool.  Jeder der Chunks soll dabei einen logisch zusammenhängenden Text (einen „Gedankengang“) repräsentieren. Für den Text des AI Acts erfolgt das grundsätzlich nach Artikeln, Erwägungsgründen und Anhängen, beim Material der KI-Servicestelle thematisch (z.B. nach den FAQs). Für einen optimalen Retrieve-Prozess sollten die Chunks eine Größe von 500 bis 1000 Zeichen (inklusive Leerzeichen) haben. Da manche Artikel und Anhänge des AI Acts aber an die 10.000 Zeichen und mehr umfassen (etwa Artikel 3 und 5 oder Anhang III), ist in solchen Fällen eine weitere Unterteilung des jeweiligen Artikels etc. nötig. Diese weitere Unterteilung erfolgt dann nach thematischen Gesichtspunkten.

Im RAG-System wird der Anfragevektor mit den Vektoren der externen Wissensquellen abgeglichen (siehe Abbildung oben, RAG Schritt 1 - Retrieve). Es wird der sogenannte Kontext erhoben, d.h. jene Passagen der externen Wissensquellen, welche die höchste semantische Ähnlichkeit mit der aktuellen Anfrage haben. Bei diesen Passagen handelt es sich um Artikel, Erwägungsgründe und Anhänge des AI Acts sowie Material der KI-Servicestelle, wobei jeweils auch die Querverweise mit angezeigt werden. Diese Querverweise wurden ebenfalls im Annotation Tool für jeden Chunk definiert: Gerade bei Gesetzestexten sind oft etwa Definitionen oder Erwägungsgründe für eine genaue Auslegung einzelner Begriffe notwendig, die durch eine semantische Ähnlichkeitssuche alleine nicht gefunden werden, wie sich in ersten Tests herausgestellt hat.

Der Kontext kann im Fall des für den AI Act Chatbot verwendeten RAG-Systems maximal 22.000 Token umfassen, was in etwa 88.000 Zeichen (inklusive Leerzeichen) entspricht. Dies ist einerseits vom verwendeten LLM-Modell vorgegeben, außerdem auch von der GPU der eingesetzten Hardware. Der Kontext ist in der Ausgabe des Chatbots unter Relevante Quellen schwarz markiert aufgeführt. Darunter sind in grau weitere Passagen der externen Wissensquellen aufgelistet, die eine geringere Ähnlichkeit mit der aktuellen Anfrage aufweisen und nicht dem LLM übergeben werden, weil die maximal mögliche Anzahl an Token bereits erreicht war. Prompt, Anfrage und Kontext werden zusammengefügt (RAG Schritt 2 - Augment) und an das LLM übergeben, welches eine Antwort generiert (RAG Schritt 3 - Generate).

Sowohl das verwendete Embedding Modell (Arctic Embed 2 von Snowflake) als auch das LLM (Mistral Small von Mistral) sind Open Source und werden lokal auf einem RTR Server gehostet, als Framework wird Ollama eingesetzt. Die vorliegende Implementierung des RTR AI Act Chatbots zeigt damit, dass alle Daten lokal bleiben können. Datenflüsse gibt es von der Anfrage jeweils zum Embedding Modell und zum LLM, und schließlich als Antwort wieder zurück zum LLM (siehe Abbildung oben). Während ein vollkommen lokales Hosting möglich ist, ist dieses nicht notwendig: Sowohl für das „Retrieval“ können externe Dienste eingesetzt werden, und auch LLMs können über API-Call genutzt werden.

Im Folgenden werden die einzelnen RAG-Schritte im Detail erklärt.

1.3 Retrieve – Wie werden relevante Quellen erhoben?

Für den Abruf („Retrieve“) relevanter Quellen soll die jeweilige Anfrage mit den externen Wissensquellen (hier der AI Act und Material der KI-Servicestelle) abgeglichen werden können. Ziel ist die Identifizierung von Artikeln, Erwägungsgründen und Anhängen des AI Acts sowie von Material der KI-Servicestelle mit Informationen zur Beantwortung der jeweiligen Anfrage. Die Vorbereitung dafür findet bereits bei der Einbindung der externen Wissensquellen in das RAG-System statt, wenn die Daten vorverarbeitet und indexiert werden (siehe Abbildung unten, Schritt 1). Wie bereits im vorigen Abschnitt beschrieben, müssen die Texte zunächst einmalig in Chunks unterteilt werden, bevor sie beim Vector Embedding in mathematische Vektoren umgewandelt werden. Vektoren sind Listen von Zahlen bzw. Koordinaten in einem mehrdimensionalen Raum und diese Zahlen bzw. Koordinaten repräsentieren bestimmte Eigenschaften oder Merkmale des Textes. Für den AI Act Chatbot wird das Embeddingmodell Arctic Embed 2 von Snowflake verwendet, dessen Vektoren über 1024 Dimensionen, d.h. Merkmale bzw. Elemente, verfügen. Jede der 1024 Dimensionen des Vektors wiederum wird durch eine Gleitkommazahl mit 32 Bit Genauigkeit im Zahlenbereich zwischen 1 und -1 dargestellt.

Bei der Darstellung eines Begriffs als Vektor spielt die sogenannte semantische Ähnlichkeit eine zentrale Rolle, d.h. die Ähnlichkeit der Bedeutung von Begriffen im jeweiligen Kontext. So sind einander etwa Synonyme, wie z.B. Auto und Fahrzeug, semantisch ähnlich, weil sie mit unterschiedlichen Worten dasselbe zugrunde liegende Objekt beschreiben. Beim Embedding werden Begriffe so dargestellt, dass dabei ihre semantischen Beziehungen und Kontextinformationen erfasst werden. Die relativen Positionen der Vektoren spiegeln die semantischen Ähnlichkeiten und Beziehungen zwischen den Begriffen wider. So können auch Homonyme, d.h. gleichlautende Begriffe mit unterschiedlicher Bedeutung wie etwa Schloss (Schließvorrichtung, Gebäude) anhand des sie umgebenden Kontextes („ein Schloss besichtigen“, „ein Schloss wechseln“), unterschieden werden.

Eine Anfrage an den AI Act Chatbot wird ebenfalls in einen Vektor umgewandelt (siehe Abbildung unten, Schritt 2). Wichtig ist, dass jeweils dasselbe Embedding-Modell für die Vektorisierung der externen Wissensquelle und der Anfrage verwendet werden muss. Der Anfragevektor wird dann mit den Vektoren der externen Wissensquellen abgeglichen (siehe Abbildung unten, Schritt 3). Es werden jene Vektoren der externen Wissensquelle ausgewählt, welche die höchste Ähnlichkeit mit der aktuellen Anfrage haben. Die semantische Ähnlichkeit von Begriffen kann mittels der sogenannten Kosinus-Ähnlichkeit ihrer Vektoren berechnet werden (siehe Beispiel weiter unten). Bei einer Anfrage an den AI Act Chatbot wird der Kontext, d.h. die relevanten Quellen, nach semantischer Ähnlichkeit geordnet aufgeführt, wobei der jeweilige Prozentwert der Kosinus-Ähnlichkeit entspricht.

Um die Qualität der Antwort des AI Act Chatbots zu steigern, werden im Kontext zu jedem Chunk auch die jeweiligen Querverweise aus der Datenbank nachgeladen und mit übergeben, d.h. z.B. die relevanten Erwägungsgründe zu einem Artikel (siehe Abbildung unten, Schritt 4).

1.3.1 Beispiele für Vektor Embedding

In der Tabelle unten wird ein fiktives und stark vereinfachtes Beispiel für das Vektor Embedding verschiedener Begriffe (Zeilen: Katzen, Autos, Rose, Baby) gegeben. Das Embedding geschieht (ebenfalls stark vereinfacht dargestellt) über Merkmale (Spalten: Tier, Mensch, Plural, Pflanze), welche verschiedene Aspekte der Begriffe repräsentieren sollen. Jede Spalte repräsentiert jeweils eine Dimension des Begriffsvektors und der Zahlenwert die Ausprägung des Merkmals. Die Spalte mit […] verweist auf weitere Dimensionen, welche in diesem vereinfachten Beispiel weggelassen wurden. Zum Vergleich: das für den AI Act Chatbot verwendete Embedding Modell Arctic Embed 2 von Snowflake erstellt Vektoren mit 1024 Dimensionen, was also eine Tabelle mit 1024 Spalten ergeben würde.

Der resultierende Vektor für Katzen ist hier [.91, .19, …, .94, -.51], diese Liste von Zahlen entspricht auch Koordinaten in einem mehrdimensionalen Raum.

 Stark vereinfachtes Beispiel für Vektor Embedding © RTR (CC BY 4.0)

Beim Vektor Embedding wird auch der Kontext, in dem Begriffe vorkommen, mit berücksichtigt. Bei homonymen Begriffen, wie z.B. „Schloss“, wird die jeweilige Bedeutung im Kontext ersichtlich. Wie die Abbildung unten zeigt, liegen die Vektoren für den Begriff „Schloss“ in den Phrasen „Tür ins Schloss gefallen“ und „das Schloss knacken“ im Vektorraum nahe beieinander. Der Vektor für den Begriff „Schloss“ in der Phrase „das Schloss besichtigen“ weist hingegen deutlich in eine andere Richtung, liegt aber seinerseits nahe am Vektor des Begriffs „Burg“ in der Phrase „die Burg besichtigen“. Auch hier handelt es sich um ein stark vereinfachtes Beispiel.

1.3.2 Berechnung der Kosinus-Ähnlichkeit

Entscheidend für die Ähnlichkeit zweier Begriffe ist der Winkel θ zwischen den beiden Begriffsvektoren (siehe Abbildung unten). Dieser Winkel wird typischerweise mit dem griechischen Kleinbuchstaben theta (θ) bezeichnet. Je kleiner der Winkel θ zwischen den Begriffsvektoren, desto größer ist die semantische Ähnlichkeit der Begriffe.

Der Kosinus des Winkels θ zwischen den zwei Vektoren a und b entspricht der sogenannten Kosinus-Ähnlichkeit (abgekürzt sim von similarity) der beiden Vektoren. Mathematisch berechnet man die Kosinus-Ähnlichkeit nach folgender Formel: 

Das innere Produkt (Skalarprodukt) der Vektoren a und b  wird geteilt durch das Produkt der Beträge, d.h. der Längen, der Vektoren.

Man erhält für die Kosinus-Ähnlichkeit Werte zwischen 1 und -1 mit folgender Bedeutung:

1. sim = 1
       a. Maximale Ähnlichkeit, d.h. die beiden Begriffe sind semantisch identisch
2. 0 < sim < 1
       a. Es gibt eine semantische Ähnlichkeit
       b. Je größer der Wert, desto größer ist die Ähnlichkeit
3. sim = 0
       a. Die Vektoren sind orthogonal, d.h. im Winkel von 90 Grad zueinander
       b. Begriffe haben keine semantische Ähnlichkeit bzw. keine gemeinsame Bedeutung
4. sim = -1
       a. Winkel von 180 Grad zwischen den Vektoren
       b. Dies kommt praktisch selten vor und entspricht einer gegensätzlichen Bedeutung der Begriffe
5. -1 < sim < 0
       a. Je näher der Wert an 0 liegt, desto geringer ist die semantische Ähnlichkeit der Begriffe
       b. Je näher der Wert an -1 liegt, desto größer wird die gegensätzliche Bedeutung der Begriffe 

1.3.3 Beispiel für die Kosinus-Ähnlichkeit von 3 Begriffen

In einem System soll die semantische Ähnlichkeit der 3 Begriffe Kuh, Schaf und Rose erhoben werden, und dazu die Kosinus-Ähnlichkeit verwendet werden. Zur Demonstration der Berechnung der Kosinus-Ähnlichkeit werden hier Vektoren mit nur 2 Dimensionen verwendet.

Die Begriffsvektoren:

1. Rose [0.2, 0.9]
2. Kuh [0.8, 0.4] 
3. Schaf [0.9, 0.2]

Die Begriffsvektoren lassen sich grafisch in einem Koordinatensystem darstellen (siehe Abbildung unten). Man sieht auf den ersten Blick, dass die Vektoren der Begriffe Kuh und Schaf fast deckungsgleich sind. Der Vektor des Begriffs Rose hingegen weist in eine deutlich andere Richtung als die beiden anderen Vektoren.

Wie semantisch ähnlich sind die Begriffe Kuh und Schaf?

Berechnung der Kosinus-Ähnlichkeit von Kuh (Vektor a) und Schaf (Vektor b):

Die Kosinus-Ähnlichkeit der Begriffe Kuh und Schaf beträgt etwa 0.971, d.h. die Begriffe Katze und Hund sind sich semantisch zu etwa 97% ähnlich. Der Winkel θ zwischen den Vektoren beträgt nur 13.83 Grad, was einer hohen semantischen Ähnlichkeit entspricht.

Zum Vergleich: die angegebenen Prozentwerte für die relevanten Quellen im AI Act Chatbot entsprechen jeweils der Kosinus-Ähnlichkeit zum Anfragevektor, wobei die Vektoren 1024 Dimensionen haben.

Wie semantisch ähnlich sind die Begriffe Rose und Kuh?

Die Kosinus-Ähnlichkeit der Begriffe Rose und Kuh beträgt etwa 0.6309, d.h. die Begriffe Rose und Schaf sind sich semantisch zu etwa 63% ähnlich. Der Winkel θ zwischen den beiden Vektoren beträgt 50.88 Grad, was einer geringen semantischen Ähnlichkeit entspricht.

1.4 Augment – Wie ist ein RAG-Prompt aufgebaut?

Der Prompt spielt in einem RAG-Chatbot eine wichtige Rolle, da er das zugrunde liegende LLM dazu veranlasst, eine bestimmte Art von Antwort zu generieren. Um den Prompt zu erstellen, wird die ursprüngliche Benutzeranfrage um den Kontext, d.h. die zuvor identifizierten relevanten Dokumente der externen Wissensquellen, erweitert („Augment“).

Typischerweise bestehen RAG-Prompts aus Komponenten, die bei jeder Anfrage gleich bleiben (Rollenzuweisung, Aufgabendefinition und – falls erforderlich - zusätzlichen Anweisungen), und variablen Komponenten, die je nach Anfrage unterschiedlich sind (Benutzeranfrage und Kontext).

Der Prompt des KI-Servicestelle AI Act Chatbots setzt sich wie folgt zusammen:

1. „Du bist ein spezialisierter KI-Assistent zur Beantwortung von Fragen über die EU-Verordnung über Künstliche Intelligenz (EU AI Act).“
   [Rollenzuweisung]
2. „Deine Aufgabe ist es, präzise, verständliche und ausschließlich auf den bereitgestellten Quellen basierende Antworten zu liefern.“
   [Aufgabendefinition]
3. „Strikte Richtlinien für die Beantwortung von Fragen:
   
       a. Themenfokus: Nur Fragen zum AI Act beantworten
   
       […]
   
       b. Strikte Quellenbindung – Keine Halluzinationen, keine Vermutungen
   
       […]
   
       c. Korrekte und vollständige Quellenangaben in jeder Antwort
   
       […]
   
      Beispiel einer belegten Antwort:
   
     ```
   
      Der AI Act definiert Hochrisiko-KI-Systeme nach bestimmten Kriterien [1]. Hier ist das konkrete Kriterium B einschlägig [2]. Alternativ könnte auch Kriterium F                  betrachtet werden[3].
   
      Quellen:
   
      [1] Titel Quelle 1
   
      [2] Art 175 EU AI Act
   
      [3] KI-Servicestelle: Kriterium F
   
      ```
   
       d. Keine allgemeinen Floskeln oder rechtlichen Disclaimer
   
       […]
   
       e. Antwortstruktur & Formatierung
   
       […]“
   [zusätzliche Anweisungen]
   
4. „Bereitgestellte Quellen des EU AI Act und der KI-Servicestelle:
   [Es folgen die im Retrieve-Prozess identifizierten relevanten externen
   Wissensquellen.]“
   [Kontext]
5. „Aufgabe:
   
   Nutze ausschließlich die oben bereitgestellten Informationen aus dem AI Act und erstelle eine rechtlich fundierte, präzise und belegte Antwort.
   
   Beziehe dich durch Endnoten bzw. Fußnoten auf deine Quellen. Führe die Quellen am Ende der Antwort an.
   
   Anfrage: Ich möchte E-Mails automatisch mit einem LLM beantworten. Muss ich das offenlegen?
   
   Antwort:“
   [Benutzeranfrage mit Aufgabendefinition] 

1.5 Generate – Welche Vorteile bietet ein RAG-System als Auskunftsquelle?

Der Prompt wird an das LLM für die Erstellung der Antwort („Generate“) übergeben.  Hier werden die Vorteile eines RAG-Systems gegenüber einem reinen LLM-System sichtbar. So können LLMs mit dem Kontext um zusätzliche externe Wissensquellen (z. B. eine Datenbank) erweitert werden, ohne dass das LLM aufwändig neu mit diesen zusätzlichen Daten trainiert werden muss. Die Antworten eines RAG-Systems sind präziser und relevanter, da aktuelle und kontextspezifische Informationen mit einbezogen werden können. Zudem lassen sich durch die externen Wissensquellen die sogenannten Halluzinationen eingrenzen, die unter anderem dann entstehen, wenn relevante Informationen nicht in der Wissensbasis des LLM-Systems vorhanden sind.  Schließlich kann schnell auf benötigte Informationen zugegriffen werden, ohne dass man selbst aufwändige Recherchen in umfangreichen Dokumenten durchführen muss. Interne Wissensbestände lassen sich so effizienter nutzen.

Ein weiterer wichtiger Aspekt, den man bei der Betrachtung von Retrieval-Augmented-Generation (RAG)-Systemen beachten sollte, sind deren Grenzen. Ein RAG-System funktioniert nur dann gut, wenn der relevante Kontext in den externen Wissensquellen auch tatsächlich gefunden werden kann. Dies erfordert gut organisierte und durchsuchbare Datenquellen. Ist dies nicht der Fall, kann die Genauigkeit der Antworten leiden. Zudem ist die Struktur der Antworten stark abhängig von der Qualität des Prompts und der Fähigkeiten des LLMs. Wenn diese nicht klar oder gut definiert sind, könnten die Antworten unvollständig oder weniger kohärent ausfallen.

Alternativ oder zusätzlich zu einem RAG kann in bestimmten Fällen ein umfassendes Fine-Tuning des LLMs sinnvoller sein, insbesondere wenn es darum geht, eine sehr große Menge an spezifischen Daten zu berücksichtigen oder bestimmte Stile der Ausgaben einzuhalten. Ein gut abgestimmtes Fine-Tuning kann die Leistungsfähigkeit eines LLMs für eine bestimmte Aufgabe erheblich steigern, indem es die Modellparameter besser an die spezifischen Erfordernisse der Anwendung anpasst. 

1.6 Qualitätssicherung

Für die Qualitätssicherung ist es erforderlich, die Verlässlichkeit des RAG objektiv und nachvollziehbar zu messen. Bei der vorliegenden Implementierung des RTR AI Act Chatbots erfolgt diese Qualitätssicherung automatisiert mittels eines vordefinierten Fragenpools, bestehend jeweils aus einer Frage zum AI Act, den relevanten Quellen und der Antwort. Nur eine Hälfte der Fragen waren dem Entwicklungspartner bekannt (diese sind hier aufgeführt). Zur Auswertung wurden einerseits die im Retrieve-Schritt gefundenen Quellen mit den relevanten Quellen des vordefinierten Fragenpools abgeglichen. Außerdem wurde die Antworten des RTR AI Act Chatbots mittels Chat GPT-4o mit den Antworten des Fragenpools verglichen und in 4 Kategorien (Kein inhaltlicher Unterschied, Überschießende Antwort mit/ohne Widerspruch, Widersprüchliche Antwort) eingeordnet. Zudem wurde der Stil der Antwort hinsichtlich der Professionalität bewertet. Folgender Prompt wurde für Chat GPT-4o verwendet:

„Untenstehend folgt eine Frage zum AI Act sowie zwei Antworten auf diese Frage. Deine Aufgabe ist es, eine Einschätzung zur Gleichwertigkeit aus juristischer Sicht der Antworten zu treffen.
    Frage: 
    {question}
    Antwort A:
    {existing_answer}
    Antwort B:
    {new_answer}
    Aufgabe zur Beurteilung: Obenstehend wurde eine rechtliche Frage zum AI Act zweimal beantwortet als "Antwort A" und "Antwort B".
    Vergleiche die beiden Texte und bestimme, wie stark die Antwort B von Antwort A abweicht. 
    Berücksichtige Fälle, wo Antwort B alle Aspekte von Antwort A abdeckt, aber darüber hinausgehend beantwortet. 
    Es handelt sich um ein juristisches Lehrbuch über das AI-Gesetz in der EU. Die Fragen werden dort abgedruckt. Relevant sind juristische Unterschiede. Relevant sind,  ob andere rechtliche Schlüsse und Subsumptionen gezogen werden. Nicht relevant sind reine Änderungen in der Formulierung. 
    Wie unterscheiden sich die beiden Antworten? Bitte halte dich strikt an die folgende Struktur und bewerte in:
    1: Kein Unterschied: Beide Antworten enthalten nur dieselbe Information. Beide Antworten kommen zu den selben juristischen Schlüssen.
    2: Überschießende Antwort, kein Widerspruch: Beide Antworten enthalten dieselben juristischen Schlüsse. Eine Antwort behandelt mehrere juristische Aspekte als die andere Antwort.
    3: Überschießende Antwort, Widerspruch: Beide Antworten enthalten die selben juristischen Schlüsse. Eine Antwort behandelt noch mehr Aspekte, die aber potentiell einen Widerspruch auslösen. Das ist insbesondere dann der Fall, wenn unterschiedliche Schlüsse zur Kategorisierung eines KI-Systems getroffen werden.
    4: Widersprüchliche Antwort: Beide Antworten enthalten juristische Schlüsse, die zueinander im Gegensatz stehen.
    Zusätzlich bewerte den Stil der Antwort B:
    gut: Professionelle Antwort, sie schafft juristische Klarheit.
    schlecht: Unprofessionelle Antwort, sie ist im juristischen Kontext und für ein Lehrbuch zum AI Act nicht professionell. Etwa wird der Leser gedutzt, oder es wird auf weitere Gespräche und Hilfestellungen verwiesen. Oder es wird auf die DSGVO oder andere Gesetze verwiesen, die nicht der AI Act sind.
    Beginne deine Antwort mit der Schulnote, direkt mit der Ziffer. Erläutere dann in zwei Sätzen, wie sich der Schluss zusammensetzt. Danach bewerte den Stil der Antwort mit "gut" oder "schlecht" und erläutere deine Entscheidung in einem Satz. Beginne mit "gut" oder "schlecht".
    Bitte fasse den Vergleich zwischen zwei Fragen unter dem Titel 'Zusammenfassung:' zusammen.
    Entferne bitte alle ** vor und nach den Wörtern. Zum Beispiel sollte **Frage:** zu Frage: geändert werden.
    Bitte halte dich strikt an die folgende Struktur und gib IMMER alle Abschnitte aus, auch wenn sie leer sind:
    Frage:
    Bestehende Antwort:
    Neue Antwort:
    Zusammenfassung:“

Ein weiteres Element der Qualitätssicherung bildet eine integrierte Feedbackmöglichkeit in der Website. 

1.7 Energieverbrauch

Für jede Anfrage werden der Energieverbrauch des Prozessors (CPU), der Grafikkarte (GPU) und des Arbeitsspeichers (RAM) angegeben, wobei der Stromverbrauch direkt auf Hardware-Ebene gemessen wird und jeweils ein Mittelwert über die Nutzungsperiode der Anfrage berechnet wird (Script siehe hier):

1. Der Energieverbrauch der CPU wird über das Running Average Power Limit (RAPL)-Interface ermittelt, das in der verwendeten Intel-CPU (Intel Core™ i5-13500-Prozessor) verbaut ist.
2. Der Energieverbrauch der GPU wird mittels NVIDIA Management Library (NVML) ermittelt, indem über eine API Informationen zum Energieverbrauch der verwendeten NVIDIA RTX 4000 ADA Grafikkarte abgerufen werden.
3. Für den Energieverbrauch des Arbeitsspeichers wird der aktuelle RAM-Speicherbedarf (in GB) ermittelt und von einem durchschnittlichen Energiebedarf von 0.375 Watt pro GB ausgegangen.

Der sogenannte Power Usage Effectiveness (PUE)-Wert gibt an, in welchem Verhältnis der Gesamtenergieverbrauch zum Energieverbrauch der Hardware selbst steht. Nach Angaben des Betreibers des Rechenzentrums (Hetzner, siehe hier) liegt der PUE-Wert zwischen 1,1 und 1,16, d.h. es werden zwischen 10 und 16% des gemessenen Energieverbrauchs für Kühlung etc. der Hardware verwendet.

Die Vergleichsbeispiele für den Energieverbrauch werden wie folgt berechnet:

    a. Haarföhn mit 2200 Watt Leistung: 

    (Gesamt-Energieverbrauch (Wattstunden) /  2200 Watt) * 3600 = Betriebsdauer (Sekunden)

    b. Handyakku mit 5000 Milliamperestunden Kapazität, 5 Volt Spannung, Wirkungsgrad beim Aufladen ist 80 Prozent:

    (Gesamt-Energieverbrauch (Wattstunden) / 5 Volt) * 1000 
    => Umrechnung in Milliamperestunden
    (Milliamperestunden / 5000 Milliamperestunden) * 0,8 * 100 = Ladung des Handyakkus (Prozent) 

1.8 Informationen zu eingesetzten Ressourcen

Alle Bestandteile des AI Act Chatbots laufen auf dedizierter Hardware. Konkret zur Anwendung kommt ein Server mit einer NVIDIA RTX 4000 ADA Grafikkarte, einem Intel Core™ i5-13500-Prozessor und 64 GB Arbeitsspeicher. Als Betriebssystem kommt Ubuntu 24.04 LTS zum Einsatz. Der gesamte Speicherverbrauch des Servers, zusammensetzend aus Daten, Betriebssystem, Sprachmodell und Embedding-Modell beträgt weniger als 100 GB.