%! suppress = EscapeAmpersand %! suppress = DocumentclassNotInRoot \documentclass[a4paper, twoside]{IEEEtran} \usepackage{array} \usepackage[utf8]{inputenc} \usepackage[T1]{fontenc} \usepackage{lmodern} \usepackage[ngerman]{babel} \usepackage[style=ieee, backend=biber, bibencoding=utf8]{biblatex} \addbibresource{literatur.bib}\usepackage{csquotes} \renewcommand*{\bibfont}{\footnotesize} \usepackage{booktabs} \usepackage{microtype} \usepackage{xcolor} \usepackage{graphicx} \usepackage{listings} \lstset{basicstyle=\footnotesize\ttfamily, breaklines=true, keepspaces=true, columns=fixed, numberstyle=\tiny, keywordstyle=\color{blue}} \usepackage{tikz} \usepackage{pgfplots} \usetikzlibrary{positioning,fit,calc,backgrounds,patterns} \usepackage{tabularray} \usepackage{stfloats} \usepackage{float} % Definiert die Kompatibilität mit der Version von pgfplots \pgfplotsset{compat=1.17} \renewcommand{\lstlistingname}{Codebeispiel} \lstdefinestyle{mystyle}{ language=Python, basicstyle=\ttfamily\small, commentstyle=\color{green}, keywordstyle=\color{blue}, numberstyle=\tiny\color{gray}, stringstyle=\color{purple}, breakatwhitespace=false, breaklines=true, captionpos=b, keepspaces=true, numbers=left, numbersep=5pt, showspaces=false, showstringspaces=false, showtabs=false, tabsize=2, escapeinside={(*@}{@*)} % for escaping to LaTeX } \lstset{style=mystyle} \newcommand{\DavinciCode}{code\babelhyphen{nobreak}davinci\babelhyphen{nobreak}002} \title{Vorstellung von Program-aided Language Model Prompts \thanks{Dieser Beitrag entstand im Rahmen des \emph{Konferenzseminars Machine Learning}, das im Wintersemester 2023/24 vom Fachbereich Informatik und Naturwissenschaften der Fachhochschule Südwestfalen durchgeführt wurde. --- Als Basis für diese \LaTeX-Vorlage dient das IEEE Conference Template der IEEE Computational Intelligence Society.}} \author{ \IEEEauthorblockN{Philipp Horstenkamp\\} \IEEEauthorblockA{Fachhochschule Südwestfalen} \vspace{3mm} Konferenzseminar Machine Learning\\ Wintersemester 2023/24 } \begin{document} \maketitle \begin{abstract} Eines der Herausforderungen bei der Nutzung von Large Language Models (LLMs) ist die eingeschränkte Fähigkeit, mathematische Operationen präzise auszuführen. Ähnlich wie der menschliche Verstand neigen sie dazu, mathematische Ergebnisse mit Flüchtigkeitsfehlern zu berechnen. Eine Lösung hierfür bietet die Umwandlung von mathematischen Problemstellungen in einfachen Programmcode. Dieser Ansatz nutzt die Rechenkapazität analog zu einem Taschenrechner, um arithmetisch-logische Berechnungen durchzuführen, statt auf die Generierung des nächsten wahrscheinlichen Tokens durch das Sprachmodell zu vertrauen. Durch diese Methode lassen sich die Stärken des Aufgabenmodells mit denen der direkten Ausführung mathematischer Operationen verbinden, um mathematisch präzisere Ergebnisse zu erzielen. Dieses Prinzip wird im Paper „PAL: Programming Aided Language Model“~\cite{gao2023pal} vorgestellt und auf aktuelle Implementierung eingegangen. \end{abstract} %„PAL: Programming Aided Language Model“ \begin{IEEEkeywords} LLM, Prompt-Engineering, Mathematical, Informatik, NL \end{IEEEkeywords} \section{Einleitung}\label{sec:einleitung} Seit der Veröffentlichung von ChatGPT im Jahr 2023 haben Large Language Models (LLMs) stark an Popularität gewonnen. Allerdings begann ihre Entwicklung bereits deutlich früher. Schon vor einigen Jahren war es möglich, LLMs einzusetzen, um Rechenwege auszuformulieren und so zu symbolischen Lösungen zu gelangen, die anschließend konkret berechnet werden konnten. Jedoch hat diese schrittweise Berechnung das Problem, dass mathematische Operationen innerhalb eines Sprachmodells gelöst werden müssen, das seine Kenntnisse aus einem Textkorpus ableitet, welcher als Grundlage zum Lernen dient. Dies und die Tatsache, dass LLMs darauf ausgelegt sind, die nächsten Zeichen vorherzusagen, erschweren es ihnen, korrekt formulierte Probleme präzise zu lösen. Verlagert man jedoch die Berechnung in eine Software, die vom LLM generiert wird, kann dieses Problem umgangen und eine deutlich höhere Qualität. Ergebnisse erreicht werden. Zum Zeitpunkt des PAL-Papers wurde das Lösen von Problemen mittels Few-Shot-Learning vorangetrieben. Few-Shot-Learning verwendet eine Reihe von Frage- und Antwortpaaren als Beispiele, um zu zeigen, wie eine Problemlösung aussehen könnte. Dies führt dazu, dass Fragestellungen vom LLM im Schema der Beispiele angegangen werden und das LLM somit eine gewisse Führung erhält. PAL nutzt Few-Shot-Prompting, um ein LLM dazu zu bringen, eine Python-Funktion als Antwort zurückzugeben. Dabei ist es wichtig, dass die gegebenen Beispiele maßgeblich die zu lösenden Probleme eingrenzen. Das im Januar 2023 vorgestellte PAL-Verfahren ist nun ein integrierter Teil von beispielsweise ChatGPT. Ob sich dies direkt aus dem hier vorgestellten PAL-Paper entwickelt hat, lässt sich nicht eindeutig feststellen. Nachfolgend ein Vergleich, wie dies in Chain-of-Thought, PAL und dem aktuellen ChatGPT4 aussehen kann~\cite{CoT}~\cite{gao2023pal}~\cite{ChatGPTexample}. \begin{figure*}[htbp] \centering \includegraphics[width=\textwidth]{PAL Example Expanded.drawio.pdf} \caption{CoT\cite{CoT} vs. PAL\cite{gao2023pal} vs. ChatGPT4\cite{ChatGPTexample} nach\cite{gao2023pal}} \label{fig:cot-pal-chatgpg} \end{figure*} \section{Hintergrund}\label{sec:hintergrund} \subsection{Few-shot Prompting} Eine der erstaunlichen Fähigkeiten von Large Language Models (LLMs) besteht darin, dass sie anhand weniger Beispiele, die zeigen, wie man eine Problemstellung einer bestimmten Art lösen könnte, diese Lösungsansätze oft auf andere Probleme übertragen können~\cite{few-shot2}~\cite{few-shot1}. Beide Ansätze können, wie in den ersten beiden Eingabe-/Ausgabe-Kombinationen in \ref{fig:cot-pal-chatgpg} gezeigt, aus nur wenigen Beispielen bestehen. Wichtig dabei ist, dass sich die Lösungen auch stilistisch sehr stark an den gegebenen Beispielen orientieren. Dies ist eine Technik zur Nutzung eines LLMs und keine Modifikation am LLM selbst. Few-shot Prompting gehört daher zum Gebiet des Promptings und nicht der Erstellung von LLMs. Im Gegensatz zu Few-Shot Prompts stehen Zero-Shot Prompts. Bei diesen wird lediglich eine Beschreibung des Lösungsansatzes oder eine Formatierungsanweisung gegeben. \subsection{Chain of Thought (CoT)} Eine der weit verbreiteten Techniken, um mehr aus LLMs herauszuholen, ist, diese anzuregen, ihre Antwort schrittweise aufzubauen. Die Few-shot-Variante dazu besteht darin, dass die Beispiele die Zwischenschritte sowohl inhaltlich ausformulieren als auch die notwendigen mathematischen Operationen strukturieren. Dadurch wird das LLM angeregt, sowohl den Gedankengang, der zum Ergebnis führt, durchzuführen, als auch nicht einfach zu einem Ergebnis wie z. B. „42“ zu gelangen, weil „42“ oft als Beispiel genutzt wird. Diese Technik wird allgemein als „Chain of Thought“ bezeichnet und im entsprechenden Paper~\cite{CoT} dargelegt. \section{Program-aided Language Models} Die natürliche Fortsetzung von Chain of Thought (CoT)~\cite{CoT} besteht darin, das Modell anzuregen, mathematische und logische Probleme in Form von Programmcode zu formatieren, welcher die eigentlichen mathematischen Operationen ausführt. Dieser Ansatz beseitigt die größte Schwachstelle, die zeitgenössische Large Language Models (LLMs) bei mathematischen und logischen Operationen aufweisen. Indem der Programmcode so gestaltet wird, dass er den Gedankengang der Problemlösung nachzeichnet, werden die Stärken von Chain of Thought-Prompts genutzt und die Schwächen von LLMs bei mathematischen Operationen effektiv umgangen. Beim Aufbau von Program-Aided Language (PAL) Prompt-Beispielen ist zu beachten, dass die Variablen sich an den Grundsatz der Verbalisierung halten und aussagekräftige Namen haben sollten, die möglichst gut im Fließtext der Aufgabenstellung wiederzufinden sind, um die Verbindung zu diesen besonders deutlich zu machen. Obwohl es möglich ist, die Schritte einzeln auszuführen und dann mit den Ergebnissen weiterzuarbeiten, wurde der Ansatz der einfachen, statt der einmaligen Ausführung gewählt. \section{Experimente} Die Experimente zur Quantifizierung der Effizienz von Program-Aided Language (PAL) wurden auf Datensätzen durchgeführt, die bereits für Chain of Thought (CoT) verwendet wurden~\cite{CoT}. Hierbei wurde sowohl die Fähigkeit zum Lösen mathematischer, abstrakter als auch algorithmischer Probleme quantifiziert. Die CoT-Beispiele, welche die Lösungsstile aufzeigen, wurden direkt übernommen und in den PAL-Stil einer Antwort übertragen. Um eine gute Vergleichbarkeit zu gewährleisten, wurden äquivalente Beispiele in beiden Stilen verwendet, um die Qualität der Ergebnisse beider Algorithmen unter gleichen Bedingungen zu testen. Beispielsweise wurden zufällig die Beispiele 3, 6 und 8 aus der Menge der Beispiele ausgewählt. Probleme wurden sowohl mit CoT als auch mit PAL unter Verwendung dieser Kombination gelöst. Auf diese Weise kann der Zufallsfaktor, der die Passgenauigkeit der Beispiele zum Problem beeinflusst, minimiert werden, was die Ergebnisse vergleichbarer macht. Auf die Beispiele und die Fragestellung folgt stets die Aufforderung, Antworten in Python zu formulieren, und zwar in dem vorgegebenen Format. Neben CoT und PAL wurde auch die direkte Frage nach einem Ergebnis getestet, um die qualitativen Unterschiede deutlich aufzeigen zu können. \subsection{Mathematische Berechnungen} Zur Evaluation des KI-Modells wurden mathematische Aufgaben aus acht Datensätzen auf Grundschulniveau verwendet. Die Experimente zeigten, dass Kommentare und lange Beschreibungen zwischen den Codezeilen die Ergebnisse nicht verbessern. Daher sind die Beispiele recht schlicht gehalten. In Codebeispiel \ref{list:math-prompt-example} ist ein Beispiel aus dem PAL-Repository, welches zeigt, wie ein solcher mathematischer Prompt aussehen kann. Das Beispiel wurde dabei nicht übersetzt, da unklar ist, inwiefern eine Übersetzung die Qualität von generiertem Code schwächt, besonders da Code im Wesentlichen in Englisch geschrieben wird. Um die mathematischen Anteile von den Lösungsansätzen zu unterscheiden, wurde einer der Datensätze (GSM8K) editiert und die Zahlen durch große Zahlen ersetzt, bei denen die Ergebnisse von mathematischen Operationen nicht aus dem Gedächtnis kommen, sondern gerechnet werden müssen. Dies ermöglicht einen guten Vergleich, wie gut oder schlecht die Lösungsansätze im Gegensatz zur direkten Mathematik sind. Es schließt nahezu aus, dass die korrekten Ergebnisse einfach geraten werden. Dieser so editierte Datensatz wird als GSM-HARD bezeichnet. \begin{lstlisting}[language=Python, caption=Prompt Beispiel für mathematische Probleme, label=list:math-prompt-example] (*@\textbf{Q: Olivia has \$23. She bought five bagels for \$3 each. How much money does she have left?}@*) # solution in Python: ddef solution(): """Olivia has $23. She bought five bagels for $3 each. How much money does she have left?""" money_initial = 23 bagels = 5 bagel_cost = 3 money_spent = bagels * bagel_cost money_left = money_initial - money_spent result = money_left return result \end{lstlisting} \subsection{Abstraktes Denken} In diesem Abschnitt wurden verschiedene Probleme gelöst, die sich auf die räumliche Beziehung und Attribute von Objekten beziehen. Ein Beispiel dafür sind Probleme wie: "Ein grauer Esel, ein brauner Hund, eine graue Katze und ein roter Hahn stehen aufeinander. Welche Farbe hat das Tier unter dem Hund?" Des Weiteren wurden Aufgaben zu verschobenen und gefilterten Daten bearbeitet. Im Beispiel gibt es tabellarische Daten über Pinguine, die nach Attributen gefiltert und anschließend gezählt werden müssen. Dies wird anhand eines Beispieldatensatzes über Pinguine demonstriert. Zuletzt wurden Probleme bezüglich des Verständnisses von Datum und Zeitabständen behandelt, wie zum Beispiel: "Peters Reise sollte 5 Stunden dauern. Er hat aber doppelt so lange gebraucht wie geplant. Wenn er um 23 Uhr angekommen ist, wann ist er losgefahren?" Für alle drei Problemstellungen gibt es jeweils separate Prompts im Stil von Codebeispiel \ref{list:math-prompt-example}. \subsection{Algorithmische Aufgaben} Hier wird sich mit dem Lösen von deterministischen Aufgabenstellungen auseinandergesetzt, nicht mit allgemeinen, sondern mit spezifischen Fragestellungen wie dem kategorischen Zählen von Objekten oder dem Erstellen von Sequenzen nach Anweisungen. Codebeispiel \ref{list:obj-count} zeigt, wie ein mögliches Beispiel für einen Zählerprompt aussehen kann. \begin{lstlisting}[language=Python, caption=Prompt Beispiel zum Zählen von Objekten, label=list:obj-count] (*@\textbf{Q: I have a chair, two potatoes, a cauliflower, a lettuce head, two tables, a cabbage, two onions, and three fridges. How many vegetables do I have?}@*) # solution in Python: def solution(): """Olivia has $23. She bought five bagels for $3 each. How much money does she have left?""" def soloution() """Counting all vagetables. Chair, table and friges arn't counted.""" vegetables_to_count = { 'potato': 2, 'cauliflower': 1, 'lettuce head': 1, 'cabbage': 1, 'onion': 2 } return sum(vegetables_to_count.values()) \end{lstlisting} Als Standard-LLM für die Experimente welche PAL quantifizieren wurde das CODEX LLM model \DavinciCode genutzt. Experimente mit andern modellen wurden der einfachheit halber aus dieser Vorstellung herausgenommen. \section{Ergebnisse} Die Ergebnisse in den Tabellen \ref{tab:math-performance} und \ref{tab:algo-performance} zeigen, dass PAL-Prompts wesentlich besser funktionieren als CoT Prompts und die direkte Anfrage an LLMs. \subsection{Ergebnisse der mathematischen Aufgaben} \begin{table*}[t] \centering \resizebox{\linewidth}{!}{% \begin{tabular}{l|cccccccc||r} Algorithm & GSM8K & GSM-HARD & SVAMP & ASDIV & SINGLEEQ & SINGLEOP & ADDSUB & MULTIARITH & Ø \\ \hline \hline DIRECT & 19,7 & 5,0 & 69,9 & 74,0 & 86,8 & 93,1 & 90,9 & 44,0 & 60,42 \\ CoT & 65,6 & 23,1 & 74,8 & 76,9 & 89,1 & 91,9 & 86,0 & 95,9 & 75,41 \\ PAL & 72,0 & 61,2 & 79,4 & 79,6 & 96,1 & 94,6 & 92,5 & 99,2 & 84,32 \\ \hline \end{tabular} } \caption[Mathematik prompt ergebnisse]{ Ergebnisqualität von verschiedenen Prompt techniken gegenüber verschiedenen Datensätzen.\\ Ausgelassen wurden dabei Ergebnisse von abweichenden LLMs. } \label{tab:math-performance} \end{table*} In Tabelle \ref{tab:math-performance} zeigt sich, besonders durch den Unterschied zwischen GSM8K und GSM-HARD, wie groß die Schwierigkeiten von CoT und der direkten Berechnung bei mathematischen Operationen sind, gerade weil der einzige Unterschied die Größe der Zahlen ist. Die direkte Berechnung fällt von ohnehin schon schlechten $19,7\%$ auf $5,0\%$ ($\Delta_{Direkt}=-74\%$). Ähnlich verhält es sich bei der Berechnung mit CoT-Prompts, die von $65,6\%$ auf $23,1\%$ fallen ($\Delta_{CoT}=-70$). Auch wenn die Qualität der Berechnungen für PAL fällt, geschieht dies nur von $72,0\%$ auf $61,2\%$ ($\Delta_{PAL}=-14,3\%$). Das deutlich robustere Verhalten gegenüber komplexen Rechenoperationen macht sich mit einem Qualitätsunterschied von $1224\%$ zwischen der Direktberechnung und PAL bemerkbar. Auch das wesentlich bessere CoT hat immer noch einen Qualitätsunterschied von $264\%$ zu PAL unter GSM-HARD. Aber auch mit allen anderen Datensätzen sind PAL-Prompts CoT-Prompts und direkten Anfragen überlegen. Eine manuelle Analyse der Prompts zeigt, dass das Vorgehen bei CoT- und PAL-Prompts in 16 von 25 Fällen die Antworten annähernd gleich aufbaut, was wiederum die „einfache“ mathematische Operation mit komplexeren Zahlen als Fehlerquelle aufzeigt. Die Ergebnisqualität kann weiter gesteigert werden, wenn man über die Mehrheitsentscheidung geht und eine Aufgabe mit unterschiedlichen Beispielen im Prompt löst und dann die mehrheitlich erhaltenen Ergebnisse nutzt. Die Ergebnisse von PAL steigen von $72,0\%$ auf $80,4\%$ ($\Delta_{PAL-M}=11\%$), die von CoT von $65,6\%$ auf $78,4\%$ ($\Delta_{CoT-M}=19\%$). Die Qualitätsverbesserung durch Mehrheitsentscheidungen ist zwar für PAL nicht so stark wie für CoT, was allein schon durch das geringere Verbesserungspotenzial und den geringeren Zufallsanteil bei Berechnungen via PAL zu erklären ist. Die Experimente zum Mehrheitsentscheid wurden nur auf GSM8K durchgeführt. \subsection{Ergebnisse der Aufgaben zum Abstrakten Denken \& Algorithmen} Die Ergebnisse zum abstrakten Denken und zu Algorithmen können in Tabelle \ref{tab:algo-performance} gefunden werden. Auch hier wurden die Ergebnisse, die nicht mit dem Codex-Modell „code-davinci-002“ berechnet wurden, ausgelassen. So steigt das Lösen von Positionsaufgaben in Objektfolgen um $8,8\%$ (COLORED OBJECT). Aussagen über tabellierte Daten steigen in ihrer Qualität um $14\%$ am Beispiel der Pinguin-Daten. Das Zählen von Objekten, welches bei der direkten Verwendung von LLMs besonders schwierig ist, erreicht mit PAL eine Erfolgsrate von $96,7\%$. CoT erreicht hier immerhin $73\%$. Auch hier sind wieder deutliche Qualitätssteigerungen zu erkennen. Dabei ist wichtig zu erwähnen, dass die Ergebnisqualität bei bis zu 26 Ergebnissen bei PAL-Prompts stabil ist und bei CoT-Prompts annähernd stetig abnimmt. Auch hier wird, wie bei den mathematischen Aufgaben, gezeigt, dass der Umgang mit mehr Datenpunkten für PAL wesentlich einfacher ist als für CoT. Dieses Verhalten findet sich in allen Ergebnissen wieder. Die Stabilität von PAL gegenüber einer gesteigerten Komplexität ist wesentlich höher. \begin{table}[H] \centering \resizebox{\linewidth}{!}{% \begin{tabular}{l|ccccc} \hline Algorithm & COLORED OBJECT & PENGUINS & DATE & REPEAT COPY & OBJECT COUNTING \\ \hline DIRECT & 75,7 & 71,1 & 49,9 & 81,3 & 37,6 \\ COT & 86,3 & 79,2 & 64,8 & 68,8 & 73,0 \\ PAL & 95,1 & 93,3 & 76,2 & 90,6 & 96,7 \\ \hline \end{tabular} } \caption{ Ergebnisqualität von verschiedenen Prompt Techniken gegenüber logischen und algorithmischen Aufgaben.\\ Ausgelassen wurden dabei Ergebnisse von abweichenden LLMs. } \label{tab:algo-performance} \end{table} \subsection{Analyseergebnisse} Neben den oben beschriebenen Experimenten wurden weitere Fragestellungen untersucht. Hier sind die Ergebnisse: \begin{itemize} \item PAL funktioniert auch auf schwächeren Large Language Models (LLMs). Die Vorteile skalieren etwa mit der Qualität des Modells. \item Experimente, die Modelle vergleichen, welche sowohl Code als auch Text generieren, zeigen, dass diese nur eine Mindestqualität erfüllen müssen. Funktionieren tut es mit beiden. \item Experimente, bei denen Python-Syntax als Strukturierungshilfe für Chain of Thought (CoT) genutzt wurde, zeigten nur eine geringe Verbesserung gegenüber der direkten Berechnung. \item Experimente zur Quantifizierung, ob und inwieweit Kommentare und gute Variablennamen eine Rolle spielen, zeigen, dass: \begin{enumerate} \item Kommentare die Qualität von PAL leicht verbessern. \item Werden Variablennamen und Kommentare weggelassen, erhält man Ergebnisse, welche die Qualität von CoT-Prompts oft nicht erreichen. \end{enumerate} \item Steigende LLM Qualität verringert das durch PAL erschließbare Verbesserungspotential (Abbildung\ref{fig:diff-llm}). Daher sind qualitative verbesserungen bei Besseren LLMs weniger stark sichtbar. Auch bei geringerer Prozentualer verbesserung ist PAL für die Nachvollziehbarkeit durch den Nutzer aber sehr dankbar. \end{itemize} \begin{figure}[htbp] \centering \begin{tikzpicture} \begin{axis}[ ybar, bar width=20pt, symbolic x coords={text-davinci-001, text-davinci-002, text-davinci-003}, xtick=data, nodes near coords, nodes near coords align={vertical}, ymin=0,ymax=80, enlarge x limits=0.2, ylabel={Prozentsatz}, legend style={at={(0.5,-0.15)}, anchor=north,legend columns=-1}, width=\columnwidth, height=6cm, ] \addplot [fill=red,postaction={pattern=north east lines}] coordinates {(text-davinci-001,26.5) (text-davinci-002,65.8) (text-davinci-003,65.3)}; \addplot [fill=blue] coordinates {(text-davinci-001,8.6) (text-davinci-002,46.9) (text-davinci-003,69.8)}; \legend{CoT,PAL} \end{axis} \end{tikzpicture} \caption{Vergleich der Ergebnisqualität von PAL und CoT bei verschiedenen LLM modellen.} \label{fig:diff-llm} \end{figure} \section{Ähnliche Werke \& Implementierungen} Few-shot Prompting~\cite{few-shot2}~\cite{few-shot1} und Chain of Thought (CoT) haben zur Entwicklung des PAL-Papers beigetragen. Allerdings wurden die Qualitätsergebnisse, die durch PAL erreicht wurden, dort nicht erreicht. Es gibt weitere Lösungsansätze, die über zusätzliche Tokens für Daten und mathematische Operationen arbeiten~\cite{Demeter_Downey_2020}. Diese Ansätze sind jedoch komplexer, weniger zuverlässig und weniger allgemeingültig. Es gibt auch Large Language Models (LLMs), die einen Fokus auf mathematische Probleme und den Output von Code haben. Dabei ist die Qualität der Ergebnisse natürlich besser als bei einem Standardmodell, aber nur geringfügig~\cite{pi2022reasoning}. Diese können auch genutzt werden, um Code zu generieren und in Echtzeit auszuführen. Der dem PAL sehr ähnliche Ansatz von Program of Thought (PoT)~\cite{chen2023program} erschien etwa zeitgleich und wird auch in PAL referenziert. Der Fokus von PoT liegt mehr auf mathematischen Problemen. Meiner Meinung nach wird dort auch weniger die Promptgestaltung untersucht als hier. Auch die Vergleiche mit GSM-HARD, die ich persönlich sehr aussagekräftig finde, finden nicht statt. Stattdessen wurden andere Datensätze verwendet. Darauf aufbauend gibt es Prompt-Techniken wie die "Automatic Model Selection with Large Language Models for Reasoning", die CoT und PAL parallel durchführen lässt und dann einem LLM die Entscheidung überlässt, welches der Ergebnisse korrekt ist. Damit ließ sich die Qualität der Ergebnisse von GSM8K auf $96,5\%$ steigern, um $34\%$~\cite{zhao2023automatic}. Die beliebte Python/JavaScript-Bibliothek LangChain hat PAL-Prompts als Teil ihres Funktionsumfangs~\cite{langchain}. Auch aktuellere Veröffentlichungen stellen deutlich fest, dass auch für neuere LLMs die Qualität von PAL besser ist als die von CoT~\cite{kabra2023programaided}. Es erweitert PAL zudem um einen Reliability-Wert. Eine ähnliche Integration von Programmiersprachen findet in Binder~\cite{binder} statt, wobei es primär um die Analyse von Daten via Pythons Pandas und SQL geht. Zeitgenössische Python-Libraries wie zum Beispiel PandasAI~\cite{Venturi} verwenden diesen Ansatz, um Fragen über und Aufgaben an Daten zu erledigen. Dies ist die logische Fortführung der tabellierten Pinguin-Daten in einer als Library zur Verfügung stehenden Implementierung. PandasAI arbeitet allerdings nicht mit Few-shot-Prompts, sondern über Zero-shot-Prompts. Daneben gibt es Ansätze wie "Automatic Multi-Step Reasoning and Tool-Use for Large Language Models"~\cite{paranjape2023art}, die anders als PAL nicht mit Few-shot-Prompts arbeiten. Stattdessen wird das LLM eingefroren, wenn der Code ausgeführt wird, und die Ergebnisse werden direkt in den Fließtext eingebettet, bevor die Ausführung des LLMs auf Grundlage der Ergebnisse fortgesetzt wird. Das in ChatGPT verwendete Analysemodul ist ein weiteres Beispiel, in dem schnell Code generiert wird, anstatt dass Berechnungen direkt im Code durchgeführt werden. \section{Ausblick} Die vorgestellte Prompt-Technik PAL zeigt einen ersten Schritt, bei dem während der Antwort von Large Language Models (LLMs) auf eine Frage oder Aufgabe Python-Code ausgeführt wird. Das erschlossene Verbesserungspotenzial von mathematisch-logischen Operationen in LLMs durch PAL ist beeindruckend. Die Lösung besticht durch ihre schlichte technische Eleganz. Schon beim Lesen des Abstracts entsteht der Eindruck, PAL einsetzen oder implementieren zu können. Die Quantifizierung einzelner Einflussfaktoren wie der Reihenfolge und Art der Beispiele ist hilfreich. Insbesondere die Tatsache, dass PAL-Prompts einfache „Übersetzungen“ von CoT-Prompts sind und gemeinsam eingesetzt werden, macht die Ergebnisse vertrauenswürdig. Der technische Fortschritt sowohl bei LLMs als auch bei der Integration von LLMs in Software bzw. umgekehrt der Software in LLMs über das letzte Jahr war erstaunlich. Lösungen, die PAL integrieren oder vergleichbar wie PAL arbeiten, gibt es vermehrt, was deutlich zeigt, wie gut der mit PAL verfolgte Ansatz funktioniert. Auch wenn das PAL-Paper versucht hat, das 175-Milliarden-Parameter-Modell, auf dem es evaluiert wurde, in Kontext zu setzen, ist nicht ganz klar, wie die Performance bei einem aktuellen LLM aussehen würde. Es ist jedoch kaum vorstellbar, dass die Ergebnisse schlechter sind als eine direkte Query oder CoT-Ergebnisse auf diesen Modellen, schon allein deshalb, weil PAL in der Evaluation auf größeren Modellen überlegen war. Das vor einem Jahr für die Versuche zu PAL verwendeten LLM-Modelle \DavinciCode ist nun von OpenAI als Legacy-Modelle markiert und wird zum 04.01.2024 auslaufen. Dies zeigt deutlich wie schnell dort der Technische Fortschritt ist. Was ich persönlich am PAL-Paper vermisse, ist die Angabe, wie oft der Programmcode unausführbar war. Oft kann ein Large Language Model mit dem Traceback eines Fehlers Programmcode reparieren. Dies könnte zu einer weiteren Verbesserung führen, die nicht zwingend mehr CPU verbraucht, wie die Mehrfachausführung einer Aufgabe für einen Mehrheitsentscheid. Das Potenzial ist hier leider nicht quantifizierbar, obwohl sich dies hätte leicht feststellen lassen müssen. Dies ist zum Beispiel in PandasAI geschehen ~\cite{Venturi}. Dort wird nicht ausführbarer Code dem LLM zur Korrektur oder Verbesserung zurückgegeben. Fragwürdig ist natürlich auch, ob die Ergebnisse von PAL in anderen Sprachen genauso gut ausfallen würden, da möglicherweise eine losere Kopplung von beispielsweise deutschsprachigen Benennungen in der Aufgabenstellung und englischsprachigen Variablenbenennungen im Code die Qualität senken könnte. Alternativ könnte die deutsche Sprache zwischen Programmcode ungewöhnlicher sein als die englische und somit für eine schlechte Datenlage bei der Codegenerierung sorgen. Dies zu Quantifizieren ist aber sicherlich schwierig. % https://chat.openai.com/share/3a78d9db-9caa-4745-a417-0ef229bd7728 \printbibliography \end{document}