10. Oktober 2023 von Lilian Do Khac
R-Schnittstellenintegration zur Aleph Alpha Luminous API
Große Sprachmodelle über eine bereits zur Verfügung gestellte und schicke Oberfläche zu bedienen, erhöht die Zugänglichkeit für viele Menschen – auch für diejenigen, die keine Programmiersprachen beherrschen. So lässt sich wohl auch der Hype um hiesige Fundamentalmodelle ein Stück weit erklären, obwohl die zugrundeliegende Technologie schon seit 2020 (siehe GPT-2) zur Verfügung steht. In meinem Blog-Beitrag möchte ich mich auf die Backend-Komponente in R konzentrieren und zeigen, wie mit R die Schnittstellenintegration zu Aleph Alpha bewerkstelligt wird. Letztendlich muss ein solches Fundamentalmodell für die produktive Vollintegration an die vorhandenen Schnittstellen angepasst und es müssen etwaige Kontroll- und Monitoringmechanismen (#AIGovernance) eingebaut werden. Im Folgenden zeige ich, wie man mit R (und mit ein bisschen Unterstützung von Python) an die Aleph Alpha API.
API-Vorbedingungen für Aleph Alpha
Zunächst brauchen wir einen Aleph-Alpha-Token, um die API ansprechen zu können. Diesen Token bekommt ihr von eurem Aleph Alpha Account. In der folgenden Abbildung seht ihr, wie ihr einen Aleph Alpha Account anlegt und wie er mit Guthaben aufgefüllt wird. Übrigens: Wenn ihr euch weitergehend für Aleph Alpha interessiert, empfehle ich euch den Beitrag zum Thema „Quickstart mit einem europäischen Large Language Model: Aleph Alpha’s Luminous“ von meinem Kollegen Marc Mezger.
Abbildung 1: So legt ihr einen Aleph Alpha Account an, Quelle: https://app.aleph-alpha.com/
Nachdem ihr euren Account erfolgreich angelegt habt, könnt ihr euch über „Buy Credits“ (Abbildung 1 oben rechts) > „Account“ (links neben „User Profile“) einen Token generieren (Abbildung 2 rechts blau markiert).
Abbildung 2: So generiert ihr einen Aleph Alpha Account Token, Quelle: https://app.aleph-alpha.com/
Aleph-Alpha-API-Parameter
Bevor wir weitermachen, möchte ich noch einen kurzen Blick auf die wichtigsten Parameter werfen, die man zur Einstellung von Luminous kennen sollte. Eine entsprechende Dokumentation gibt es auf der Aleph-Alpha-Homepage. Einige Parameter sind obligatorisch und müssen immer angegeben werden, andere sind optional. Bei Aleph Alpha kann man sich über die verschiedenen Aufgaben informieren. Eine Aufgabe ist zum Beispiel die Einbettung des Textes in die mathematische Repräsentationsform, mit der Sprachmodelle arbeiten können, oder die Summarisierung, mit der ein Textinput zusammengefasst werden soll.
Der wichtigste Endpoint ist die Completion. Damit gestaltet ihr eure eigenen Summarization-, Evaluation- oder Q&A-Anweisungen, gefolgt von Embedding und Explain. Mehr Endpoints braucht ihr nicht, um eure Ideen umzusetzen.
Abbildung 3: Aleph Alpha API-Dokumentation, Quelle: https://docs.aleph-alpha.com/api/complete/
In der folgenden Tabelle findet ihr die wesentlichen Parameter:
| Parametername | Obligatorisch/Fakultativ | Beschreibung |
| model (string) | Obligatorisch | Die Luminous-Modellfamilie umfasst verschiedene Mitglieder. |
| prompt (object) | Obligatorisch | Ein Prompt ist eine Anweisung in natürlicher Sprache zur Interaktion mit einem Sprachmodell. Mehr dazu später in diesem Beitrag. Die maximale Kontextlänge beträgt bei Luminous = 2.048 Token (entspricht ca. 2,5 DIN A4 Seiten). Das bedeutet, dass euer Input und euer Output zusammen nicht mehr als ca. 2.048 Token umfassen sollten. |
| maximum_token (integer) | Obligatorisch | Angabe, wie viele Token maximal erzeugt werden sollen. Danach wird die Ausgabe abgebrochen. |
| temperature (number) | Fakultativ | Mit der Temperature kann die Kreativität der Modellausgabe beeinflusst werden. Oder statistisch ausgedrückt: Die „Zufallswahrscheinlichkeit“ der Ausgabe wird beeinflusst. Eine Temperatur = 0 lässt weniger Zufall zu oder zwingt das Modell zum Determinismus. Dies ist besonders wichtig für Anwendungen im Bereich der Dokumentenklassifikation oder Named Entity Recognition. Eine hohe Temperatur lässt mehr Zufall zu, d.h. auch Ausgabekandidaten mit geringerer Eintrittswahrscheinlichkeit erhalten eine „Chance“. Dies ist besonders bei der Generierung neuer Texte von Vorteil. |
| top_k (integer) | Fakultativ | Top_ k macht in gewisser Weise dasselbe wie die Temperatur. Auch hier würde ein höherer Wert die Modellausgabe dazu anregen, zufälliger zu agieren. Das heißt, wenn beispielsweise k = 3 wäre, würde einer der drei wahrscheinlichsten Kandidaten zufällig ausgewählt und nicht der wahrscheinlichste. |
| top_p (number) | Fakultativ |
Top_p macht in gewisser Weise dasselbe wie Top_k, wobei hier der Wert p nicht ganzzahlig, sondern als stetige Zahl dargestellt wird. Es wird eine Menge von besten Kandidaten ausgewählt, deren Summe eine Wahrscheinlichkeit ergibt, die größer als der eingestellte Wert top_p ist. Temperatur, top_k und top_p dürfen nicht gleichzeitig verwendet werden. |
| presence_penalty (number) | Fakultativ | Die Wahrscheinlichkeit, dass ein bereits generierter Token erneut generiert wird, wird verringert. Es besteht keine Abhängigkeit zu bereits existierenden Token. Voraussetzung: repetition_penalties_include_prompt = true. |
| frequency_penalty (number) | Fakultativ | Dieser Parameter hat eine ähnliche Funktion wie presence_penalty. Hier besteht jedoch eine Abhängigkeit von der Anzahl bereits vorhandener Token. Voraussetzung: repetition_penalties_include_prompt = true. |
| sequence_penalty (number) | Fakultativ | Ein höherer Wert verringert die Wahrscheinlichkeit, dass ein bereits im Prompt enthaltenes Token produziert wird. Voraussetzung: repetition_penalties_include_prompt = true. |
| repetition_penalties_include_prompt (boolean) | Fakultativ | Vorbedingung, die die Eingabeaufforderung für die drei zuvor erläuterten Parameter berücksichtigt. Dies ist besonders wichtig, wenn die Modellausgabe nicht wiederholt werden soll. |
| repetition_penalties_include_completion (boolean) | Fakultativ | Vorbedingung, die bei der Ausgabe für die drei oben erläuterten Parameter berücksichtigt wird. Dies ist besonders wichtig, wenn die Modellausgabe nicht wiederholt werden soll. |
| best_of (integer) | Fakultativ | Die besten n Ausgabekandidaten werden ausgegeben. |
| stop_sequence (string) | Fakultativ | Eine Liste von Zeichen, die einen Abbruch der Sprachgenerierung einleitet. |
| target (string) | Obligatorisch (für „Explain“) | Dies ist das Ausgabeergebnis, das erläutert werden soll. Diese Eingabe ist nur für „Explain“ relevant. |
| prompt_granularity (object) | Fakultativ (für „Explain“) | Die Granularität der Erläuterungen ist wählbar. Auswahl: Token, Wort, Satz, Absatz, Benutzerdefiniert. Diese Eingabe ist nur für „Explain“ relevant. |
R-Vorbedingungen
Um nun mit R auf die Aleph Alpha API zugreifen zu können, braucht ihr die in Abbildung 4 in Zeile 9 bis 10 abgebildeten Bibliotheken. PDF-Tools benötigt ihr für das Parsen von PDF-Dokumenten (Zeilen 27 bis 28) und Reticulate, um mit Python arbeiten zu können. Weitere Python-Pakete, die ihr brauchen werdet, sind in den Zeilen 16 bis 19 abgebildet. Zum Python und Jinja File kommen wir im nächsten Abschnitt. In Abbildung 4 habe ich als Beispiel ein (öffentlich verfügbares) Gerichtsurteil geladen, für das ich eine kurze Zusammenfassung einer bestimmten Seite (maschinell) erzeugen lassen wollte. Die erzeugte Zusammenfassung findet ihr in der Konsole beziehungsweise in Abbildung 5.
Abbildung 4: R Script
Abbildung 5: Das Ergebnis der maschinell erstellten Zusammenfassung mit Luminous, https://www.sozialgerichtsbarkeit.de/node/174141
Über R die Aleph Alpha API ansprechen
In Abbildung 4, Zeile 22 und 33 bis 34 sprechen wir über R die Aleph Alpha API an, wofür leider entweder nur Python oder RUST (oder andere) Clients vorhanden sind. Deshalb bedienen wir uns mittels Reticulate Python’s und haben zu diesem Zweck ein Python File (siehe Abbildung 6) erstellt. Darin werden die aus R übergebenen Parameter (der Token und die geparste PDF-Seite) an Aleph Alpha weitergegeben und das Ergebnis wird anschließend in R zurückgespielt. Ab Zeile 14 seht ihr einige der zuvor beschriebenen Parameter. Für die Zusammenfassung habe ich Luminous-Extended-Control verwendet und auf maximal 260 Ausgabetoken beschränkt. Was wir noch sehen, ist ein Jinja File, das in Zeile 7 (siehe Abbildung 6) bezogen wird. In diesem habe ich den Prompt für die Zusammenfassung hinterlegt.
Abbildung 6: Python File
Abbildung 7 zeigt alles, was nötig ist für den Aufbau des Prompt und um die Instruction-Modelle von Aleph Alpha anzusprechen. Es gibt eine Instruction (hier eine Bitte zur Zusammenfassung des Inputs), einen Input (die geparste PDF-Seite) und eine Response (die Ausgabe). Es ist ebenfalls möglich, direkt im Python- oder R-Code zu kodieren. Mit einem Jinja File ist es eleganter und später auch angenehmer auszutauschen oder zu auditieren.
Abbildung 7: Jinja File
Ausblick
Ich hoffe, ich konnte euch zeigen, wie toll es mit R sein kann, neue Technologien zu verknüpfen. Mit einer Anbindung an R Shiny wird es noch viel besser und ihr könnt flexibel und schnell in – ich nenne es einfach mal „Mockups“, wobei das in anderen Zusammenhängen wohl ausschließlich Papierskizzen sind – R und R Shiny Mockups mit Aleph Alpha Luminous (oder anderen Basismodellen wie OpenAI oder Cohere) erstellen. Auf diese Weise können Ideen sehr anschaulich getestet und mit anderen Teilnehmenden diskutiert werden. Außerdem können eventuell notwendige Vorverarbeitungsschritte frühzeitig erkannt und in einer Implementierung berücksichtigt werden.
Kategorie: |
|
Schlagwörter: |
Schnittstellen Aleph Alpha Künstliche Intelligenz |