%! 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}
\usetikzlibrary{positioning,fit,calc,backgrounds}
\usepackage{tabularray}
\usepackage{stfloats}
\usepackage{float}

\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}

\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}

\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:Few-shot-prompting}

\subsection{Few-shot Prompting}
Eine der erstaunlichen fähigkeiten von LLMs ist das sie mit wenigen beispielen welche zeigen wie man ein Problem
einer bestimmten art lösen könnte diese Lösungen oft auf andere probleme übertragen können ~\cite{few-shot2}~\cite{few-shot1}.

Beide können wie in der den ersten beiden Eingabe / Ausgabe combination in \ref{fig:cot-pal-chatgpg} aus nur wenigen beispielen bestehen.
Wichtig dabei ist das sich die lösungen auch stilistisch sehr stark an den gegebenen beispielen Orientieren.
Dies ist eine Technik um ein LLM zu nutzen und keine modifikation am LLM selber.
Few-shot Prompting gehört daher zum Gebiet des Prompting, nicht der LLM erstellung.

Gegenüber von Few-Shot Prompts stehen Zero Shots. Bei diesen wird einfach nur 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 ist das die Beispiele, die Zwischenschritte sowohl inhaltlich ausformulieren als auch die nötigen mathematische Operationen gliedert.
So wird das LLM angeregt sowohl den Gedankengang welcher zum ergebnis fürt durchzuführen und nicht einfach zu einem Ergebnis wie z. B. 42 zu kommen, weil 42 oft als Beispiel genutzt wird.
Diese Technik wird im Allgemeinen Chain of Thought genannt ~\cite{CoT} paper dargelegt.

\section{Program-aided Language Models}

Die natürliche Fortsetzung von CoT~\cite{CoT} ist das Model anzuregen Mathematische und
logische probleme als programmcode zu formatieren welcher die eigentliche Mathematische operation ausführt.
Dies entfernt die Stärkste schwachstelle welche Zeitgenössische LLMs gegenüber Mathematisch/Lögischen operationen haben.
Solange der Programmcode so aufgebaut ist das er den Gedankengang der Problemlösung aufbaut werden so die
stärken von Chain of Thought Prompts genutzt und die Schwächen für mathematische Operation von LLMs vollständig zu umgehen.

Beim Aufbau von PAL prompt beispielen ist zu beachten,
das die Variablen sich an den grundsatz der Verbalisierung halten und aussagekräfte Namen haben sollten, die möglichst gut im Fließtext der
Aufgabenstellung wiederzufinden sind, damit die Verbindung zu diesen Besonders deutlich wird.

Auch wenn es möglich ist die Schritte einzeln auszuführen und dann mit den ergebnissen weiterzuarbeiten wurde der einfachere anstatt der einmaligen Ausführung.

\section{Experimente}

Die Experimente zur Quantifizierung der Effizienz von PAL wurden auf den Datensätzen welche schon für CoT~\cite{CoT} verwendet wurden ausgeführt.
Dabei wird sowohl die fähigkeit zum Lösen mathematischer Probleme,
abstrakten Problemen und algorithmische Probleme quantifiziert.
Die CoT Beispiele, welche den Lösungsstiele zeigen werden,
dabei einfach von CoT übernommen und in den PAL style einer Antwort übertragen.
Um eine gute vergleichbarkeit zu gewährleisten,
werden dabei die equivalent beispiele in beiden Stilen verwendet, um die Qualität der ergebnisse beider algorithmen unter gleichen Bedingungen zu testen.

So wurden zum Beispiel zufällig Beispiele 3, 6 und 8 aus der Mänge ger beispiele ausgewählt und Probleme wurden sowohl über CoT als auch über PAL mit dieser Kombination ein Problem gelöst.
So kann der Zufallsfaktor wie gut Beispiele zum Problem passen herausgerechnet werden und die Ergebnisse werden vergleichbarer.
Auf die Beispiele und die Fragestellung folgt immer die Forderung das Antworten in Python ausfallen sollen und zwar in dem dargelegten Format.

Neben CoT und PAL wurde auch noch die Direkte frage nach einem Ergebnis probiert um die Qualitativen unterschiede sauber anzeigen zu können.

\subsection{Mathematische Berechnungen}

Zur evaluation des KI models wurden mathematische Aufgaben aus 8 Datensetzen auf Grundschulniveau verwendet.
Experimente konnte gezeigt werden, dass Kommentare und lange beschreibungen zwischen den Codezeilen die ergebnisse nicht verbessern.
Daher sind die Beispiele recht schier.

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 in wie weit eine Übersetzung die Qualität von generiertem code Schwächt.
Gerade da Code im wesentlichen in Englisch geschrieben wird.

Um die Mathematischen anteile von den Lösungsansetzen zu machen wurde einer der Datensätze (GSM8K) editiert
und die Zahlen durch große Zahlen zu ersetzt bei denen die Ergebnisse von Mathematischen operationen nicht aus
dem "Gedächtnis" kommen sondern gerechnet werden müssen.
Damit lässt sich auch besonders gut vergleichen wie gut oder schlecht die Lösungansatze sind im gegensatz zur direkten Mathematik.
Es schließt natürlich auch annähernd aus das die Korrekten ergebnisse einfach geraten werden.
Dieser so editierte Datensatz nennt sich GSM-HARD.

\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}

Hier wurden verschiedene Probleme gelöst. Dies ging es um Attribute von Objekten welche Relative zu einander Position sind.
Also um Probleme wie ein Grauer Esel, ein Brauner hund, eine Graue katze und eine Roter Hahn stehen aufeinander.
Welche farbe hat das Tier unter dem Hund?
Dann geht es um aussagen wie Verschobene und gefilterte Daten.
Im Beispiel gibt es Tabellarische Daten zu Pinguinen welche nach Attributen gefiltert und danach Gezählt werden müssen.
Dies wird hier an einem Beispieldatensatz über Pinguine gemacht.
Zuletzt geht es noch um das Verständnisse von Datum und Zeitabstände. Probleme wie Peters Reise sollte 5 Stunden dauern.
Er hat aber doppel so lange gebraucht wie geplant.
Wenn er um 23 Uhr angekommen ist. Wann ist er losgefahren?

Zu allen drei Problemstellungen gibt es jeweils separate Prompts im stile von Codebeispiel \ref{list:math-prompt-example}.

\subsection{Algorithmische Aufgaben}

Hier wird sich mit dem Lösen von Deterministische aufgabenstellungen auseinandergesetzt.
Nicht mit allgemeinen sondern spezifischen fragestellungen wie dem Kategorischen zählen von Objekten, oder dem erstellen von Sequenzen nach Anweisungen.

Codebeispiel \ref{list:obj-count} zeigt einen 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 code\babelhyphen{nobreak}davinci\babelhyphen{nobreak}002 genutzt.
Experimente mit andern modellen wurden der einfachheit halber aus dieser Vorstellung herausgenommen.

\section{Ergebnisse}

Die Ergebnisse in Tabellen \ref{tab:math-performance} und \ref{tab:algo-performance} zeigen das PAL wesentlich besser arbeitet als CoT und die Direkte anfrage.

\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 im Besonderen durch dem Unterschied von GSM8K und GSM-HARD
wie groß die Schwierigkeiten von CoT und der und der Direkten berechnung in den Mathematischen operation ist.
Gerade weil der einzige Unterschied die Größe der Zahlen ist.
Die direkte Berechnung fällt von sowieso schon schlechten $19,7\%$ auf $5,0\%$ ($\Delta_{Direkt}=-74\%$).
Ähnlich sieht es für die Berechnung mit CoT Prompts aus. Diese fallen von $65,6\%$ auf $23,1\%$ ($\Delta_{CoT}=-70\%$).
Auch wenn die Qualität der Berechnungen für PAl fällt, tut sie es nur von $72,0\%$ auf $61,2\%$ ($\Delta_{PAL}=-14,3\%$).
Das sehr viel 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 $264\%$ zu PAL unter GSM-HARD.
Aber auch mit allen anderen Datensätzen sind PAL Prompts CoT Prompts und direkten Anfragen überlegen.

Eine manuelle Analyze der Prompts zeigt das das Vorgehen bei CoT und PAL Prompts in 16 aus 25 Fällen die Antworten annähernd gleich aufbaut.
Welches wieder die "einfache" Mathematische Operation mit komplexeren Zahlen als Fehlerquelle aufzeigt.

Die Ergebnisqualität kann weiter gesteigert werden wenn man über die Majority 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\%$) $65,6$ auf $78,4\%$ ($\Delta_{CoT-M}=19\%$).
Die Qualitätsverbesserung durch Mehrheitsentscheide ist zwar für PAL nicht so stark wie für CoT.
Dies ist allein schon durch das schon geringe Verbesserungspotenzial und den geringeren Zufallsanteil bei berechnungen via PAL zu erklären.
Die Experimente zum Mehrheitsentscheid wurden nur auf GSM8K durchgeführt.

\subsection{Ergebnisse der Aufgaben zum Abstrakten Denken \& Algorithmen}

Die ergebnisse zum Abstrakten Denken und Algorithmen können in \ref{tab:algo-performance} gefunden werden.
Auch hier wurden wie der ergebnisse welche nicht mit dem codex model code\babelhyphen{nobreak}davinci\babelhyphen{nobreak}002 berechnet worden sind weggelassen.

So steigt das lösen von Positionen in Objektfolgen um $8,8\%$ (COLORED OBJECT).
Aussagen über Tabulierte 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 so besonders schwer ist erreich mit PAL $96,7\%$. CoT erreicht dort Immerhin $73\%$.

Auch hier sind wieder deutliche Qualitätssteigerungen zu finden. Dabei ist wichtig zu sagend das die Ergebnisqualität
    bei bis zu 26 Ergebnissen bei PLA Prompts stabil ist und bei CoT Prompts annähernd stetig abnimmt.
Auch hier wird wie bei den Mathematischen aufgaben gezeigt das der Umgang mit mehr Datenpunkte wesentlich einfacher ist als für CoT.
Dieses verhalten findet sich wohl in allen ergebnissen wieder das die Stabilität von PAL gegenüber einer gesteigerten Komplexität wesentlich höher ist.

\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 noch einigen anderen Fragestellungen nachgegangen.
Hier die Ergebnisse.

\begin{itemize}
    \item PAL funktioniert auch auf schwächeren LLMs. Die Benefits skalieren etwa mit der Qualität des Models.
    \item Experimente die Code wie auch Text generierende Modelle vergleichen das diese nur eine Mindestqualität erfüllen müssen.
Funktionieren tut es mit beiden.
    \item Experimente bei denen der Python syntax als Strukturierungshilfe für CoT genutzt wurde zeigten nur eine geringe Verbesserung gegenüber der direkten berechnung.
    \item Experimente zur Quantifizierung ob und in wie weit Kommentare und gute Variablennamen eine Rolle spielen zeigen das:
    \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 of nicht erreichen.
    \end{enumerate}
\end{itemize}

\section{Ähnliche Werke}

Few-shot prompting ~\cite{few-shot2}~\cite{few-shot1} und CoT haben zu dem PAL-Paper geführt.
Die Qualität der durch PAL erreichten ergebnisse wurden dort wohl aber nicht erreicht.

Es gibt weitere Lösungsansätze welche über extra Tokens für daten und mathematische operationen arbeiten ~\cite{Demeter_Downey_2020}.
Diese ansätze sind aber Komplexer, weniger zuverlässig und weniger Allgemeingültig.

Es gibt auch LLM welche mit einem Fokus auf Mathematische Probleme und den Output von Code haben.
Dabei ist die Qualität der Ergebnisse natürlich besser als bei einem Standartmodel aber nur geringfügig ~\cite{pi2022reasoning}.
Diese können natürlich auch genutzt werden um Code zu generieren und in der Laufzeit durchzuführen.

Der dem PAL sehr ähnliche ansatz vom Program of Though (PoT) ~\cite{chen2023program} ist etwa zeitgleich erschienen und wird auch in PAL referenziert.
Der Fokus von PoT ist 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 finden nicht statt. Dafür sind andere datensätze verwendet worden.

Darauf aufbauend gibt es Prompt Techniken wie die "Automatic Model Selection with large Language Models for Reasoning" welche CoT und PAL parallel durchführen lässt und dann ein LLM entscheiden lässt welches der ergebnisse korrekt ist.
Damit lies sich die Qualität von ergebnissen von GSM8K auf $96.5\%$ steigern um $\Delta34\%$ ~\cite{zhao2023automatic}.

Die beliebte Python/JavaScript library LangChain hat PAL Prompts als Teil ihres Funktionsumfanges ~\cite{langchain}.

Auch aktuellere veröffentlichungen sagen deutlich aus das auch für neuere LLMs die Qualität von PAL besser ist als CoT ~\cite{kabra2023programaided}.
Es erweitert PAL zudem um einen Reliablitlty value.

Eine ähnliche integration von programmiersprachen findet in Binder ~\cite{binder} statt.
Dabei geht es aber primär um das Analysieren von Daten via pythons pandas und SQL.
Zeitgenössische Python LBRs wie zum Beispiel PandasAI~\cite{Venturi} verwenden diesen Ansätz um Fragen über, und Aufgaben an Daten zu erldigen.
Dies ist die Logische fortführung von den Tabuarisieren Pinguin Daten in einer als LBR zur Verfügung stehenden Implementierung.
Pandas AI zumindest arbeitet aber nicht mit Few-shot Prompts sondern über Zero shot prompts.

Daneben gibt es andere ansätze die Automatic multi-step reasoning and tool-use for large language models ~\cite{paranjape2023art} welches anders als PAL nicht mit Few-shot Prompts arbeitet dafür aber das LLM einfriert wenn der Code ausgeführt wird und die ergebnisse direkt in den Fliestext einbetted und danach die ausführung des LLMs auf grundlage der ergebnisse fortführt.

Das in ChatGPT verwendete Analyze modul ist ein anderes beispiel wo schnell code generiert wird anstelle davon das Berechnungen gleich im code durchgeführt werden.

\section{Ausblick}

Die Vorgestellte Prompt technik PAL zeigt einen ersten schritt welcher während der Antwort von LLMs auf eine Frage / Aufgabe Python code ausführt.
Das erschlossene Verbesserungspotential von Mathematisch Logischen operationen in LLMs durch PAL ist beeindruckend.
Die Lösung besticht damit für mich im Besonderen durch sine schlichte technische Eleganz.
Schon beim lesen des Abstracts hat man das gefühl PAL einsetzen/implementieren zu können.

Die Quantifizierung einzelner Einflussfaktoren wie der Reihenfolge und Art der der Beispiele, in der Bemühung um Quantifizierbarkeit sind Hilfreich.
Im Besonderen das PAL Prompts einfache "Übersetzungen" von CoT prompts sind welche gemeinsam eingesetzt werden macht die ergebnisse Vertrauenerweckend.

Der Technische fortschritt sowohl bei LLMs wie auch der integration von LLMs in Software bzw.
andersherum 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 natürlich versucht hat das 175B Parameter Code Model auf dem es Evaluiert würde in Kontext zu setzen ist natürlich nicht ganz klar wie die Performance bei einem aktuellen LLM aussehen würde.
Es ist für mich jedoch gänzlich unvorstellbar das die Ergebnisse schlechter sind als eine Direkte Query oder CoT ergebnisse auf diesen Modellen.
Schon allein deshalb weil PAL in der Evaluation auf 175B Parametern größeren Modellen überlegen war.

Was ich Persönlich am PAL paper vermisse ist die angabe wie oft der Programmcode unausführbar war.
Oft can ein Large Language Model mit dem Traceback eines Fehlers programmcode Reparieren.
Dies könnte zu einer weiteren verbesserung führen die nicht so zwingend mehr CPU verbraucht wie die Mehrfachausführung einer Aufgabe für einen Mehrheitsentscheid.
Das potential ist hier aber leider nicht quantifizierbar auch wenn 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 / verbesserung zurückgegeben.

Fragwürdig ist natürlich auch ob die ergebnisse von PAL in anderen sprachen genauso gut ausfallen würden,
weil dabei evtl. eine Losere kopplung von z.B. deutschsprachigen Benennungen in der Aufgabenstellung und englischsprachigen Variablenbenennungen im code
die Qualität senken kann.
Alternative könnte z.B. die Deutsche sprache zwischen Programmcode ungewöhnlicher sein als die Englische und dort für eine schlechte Datenlage bei der Codegenerierung sorgen.

% https://chat.openai.com/share/3a78d9db-9caa-4745-a417-0ef229bd7728

\printbibliography
\end{document}
