diff --git a/report/Bericht.tex b/report/Bericht.tex
index 2b6c69077e3fd50af364bb427b93b57fc271c68a..90ed827d029522948874a40069cfc014c97c267b 100644
--- a/report/Bericht.tex
+++ b/report/Bericht.tex
@@ -1,13 +1,14 @@
%! TEX program = lualatex
%! BIB program = biber
\documentclass[DIV=13,fontsize=11pt,ngerman]{scrartcl}
-% DIV 13 ist meh, siehe Warnung
+% DIV 13 ist meh, siehe Warnung, aber vorgegeben durch Vorlage
\KOMAoptions{parskip = half}
\usepackage{polyglossia}
\setdefaultlanguage[babelshorthands = true]{german}
\usepackage[autostyle = true, german = quotes]{csquotes}
\usepackage{amsmath}
\usepackage{amssymb}
+\usepackage{diagbox} % Für diagonal-getrennte Zelle in Tabellen
% \usepackage{amsthm}
% \theoremstyle{definition}
% \newtheorem{definition}{Definition}[section]
@@ -22,13 +23,15 @@
\usepackage{graphicx}
% \usepackage{subfig}
\usepackage{xcolor}
-% \usepackage{tikz}
+\usepackage{tikz}
% \usetikzlibrary{arrows.meta,petri,positioning,shapes,shapes.arrows}
\usepackage[
- backend=biber,
- bibstyle=ieee,
- citestyle=ieee,
- date=year
+ backend=biber,
+ bibstyle=numeric,
+ citestyle=numeric-comp,
+ % bibstyle=ieee,
+ % citestyle=ieee,
+ date=year
]{biblatex}
\setcounter{biburllcpenalty}{7000}
\addbibresource{chessbibliography.bib}
@@ -42,221 +45,37 @@
\usepackage{enumitem}
\usepackage[
- bookmarksnumbered = true,
- colorlinks = true,
- citecolor = black,
- linkcolor = black,
- pdftitle = {DMML Bericht CHESS},
- pdfauthor = {Felix Feist and Stephan Mitte and Erik Jonas Hartnick},
- urlcolor = blue!70!cyan
+ bookmarksnumbered = true,
+ colorlinks = true,
+ citecolor = black,
+ linkcolor = black,
+ pdftitle = {DMML Bericht CHESS},
+ pdfauthor = {Felix Feist and Erik Jonas Hartnick and Stephan Mitte},
+ urlcolor = blue!70!cyan
]{hyperref}
+\input{assets/python_lstlisting} % Style setup for python lstlisting
-\title{Data Mining, Bericht Vorlage Replikation und Reproduktion\footnote{Diese Vorlage ist eine angepasste Version der Vorlage von Jonathan May und Elan Markowitz für den Kurs CS662 Advanced Natural Language Processing an der University of Southern California, die wiederum auf Arbeiten von Noah A. Smith, Jesse Dodge aufbauten (https://elanmarkowitz.github.io/USC-CS662/).}}
+\title{Replikation und Reproduktion von CHESS}
+\subtitle{Data Mining and Machine Learning}
%\head{Titel ersetzen und Sub-Titel streichen.}
-\author{Alexander Hinneburg\footnote{Diesen Titel und Autor müssen sie für ihren Bericht natürlich ändern.}}
-\date{Version 1.0, 15.1.2025}
+\author{Felix Feist, Erik Jonas Hartnick und Stephan Mitte}
+\date{31. März 2025}
\begin{document}
\maketitle
-\section{Einleitung}
-\minisec{Introduction}
-Beschreiben sie mit ein paar Sätzen den Kontext der replizierten/reproduzierten Arbeit. Es werden höchstens drei bis vier Paragraphen erwartet. Sie sollen hinreichend erklären, was das das Problem ist, das der Artikel bearbeitet, warum es ein wichtiges Problem ist. Fassen sie die Beträge des replizierten/reproduzierten Artikels zusammen. Zitieren sie in diesem Abschnitt relevante wissenschaftliche Arbeiten. Beschreiben, warum wir das Paper Replizieren wollen/ warum es spannend ist, dieses Paper zu replizieren.
+\input{content/01Einleitung}
+\input{content/02Umfang}
+\input{content/03Methoden}
+\input{content/04Ergebnisse}
+\input{content/05Diskussion}
+\input{content/06Kommunikation}
-% Was ist der Beitrag des replizierten Artikels?
-% Welche Teile der Arbeit wurden für die Replikation ausgewählt? Begründen Sie die Auswahl. Warum wurden andere Teile der Arbeit nicht repliziert?
-% Welche neuen Erkenntnisse erwarten Sie durch die geplante Reproduktion? Was steht davon nicht in dem replizierten Artikel?
-% Was ist der Beitrag bzw. sind die Beiträge Ihres Artikels über die Reproduktion der ausgewählten Arbeit?
-
-\section{Umfang der Replikation/Reproduktion}
-\minisec{Scope of reproducibility}
-
-Erklären sie die Behauptungen/Hypothesen/Experimente des Artikels, die sie für ihre Replikation/Reproduktion ausgewählt haben.
-Motivieren und begründen sie ihre Auswahl.
-Es ist sinnvoll, wenn sie sich auf die Behauptung konzentrieren, die der Hauptbeitrag des Artikels ist.
-Um den Hauptbeitrag herauszufinden, versuchen sie den Artikel in ein bis zwei Sätzen zusammenzufassen, z.B.
-\begin{quote}
- \enquote{This paper introduces a new activation function X that outperforms a similar activation function Y on tasks Z,V,W.} oder
-
- \enquote{Dieser Artikel führt eine neuartige Aktivierungsfunktion X ein, welche die ähnliche Aktivierungsfunktionen Y für die Aufgaben Z,W,V deutlich verbessert.}
-\end{quote}
-Stecken sie den Umfang ihrer Replikation/Reproduktion so klar wie möglich ab.
-Die Behauptungen ihres Berichts sollten durch die Ergebnisse ihrer Experimente unterstützt oder widerlegt werden.
-Schauen sie sich zum Beispiel diese Beschreibung an:
-\begin{quote}
- \enquote{Contextual embedding models have shown strong performance on a number of tasks across NLP. We will run experiments evaluating two types of contextual embedding models on datasets X, Y, and Z.} oder
-
- \enquote{Für Contextual-Embedding-Modelle wurde nachgewiesen, dass die bei einer Vielzahl von Aufgaben aus einem breiten Spektrum natürlichen Sprachverarbeitung (NLP) eine hervorragende Leistung erbringen. Wir evaluieren experimentell zwei verschiedene Arten von Contextual-Embedding-Modellen auf den Datensätzen X, Y, Z.}
-\end{quote}
-Der Umfang ist zu breit angelegt und es fehlt die Erwartung für ein klares Ergebnis.
-Schauen sie sich die nächste Beschreibung an:
-\begin{quote}
-\enquote{Finetuning pretrained BERT on SST-2 will have higher accuracy than an LSTM trained with GloVe embeddings.} oder
-
-\enquote{Das Anpassen eines vortrainierten BERT-Modells für die SST-2-Aufgabe führt zu einer höheren Klassifikationsrate als ein LSTM-Modell, das für GloVe-Einbettungen trainiert wurde}
-\end{quote}
-Hier ist klarer was bei der Reproduktion/Replikation herauskommen kann. Diese Aussage könnte durch ihre Ergebnisse tatsächlich bestätigt oder widerlegt werden.
-
-Führen sie eindeutig die Behauptungen auf, die sie in ihrer Arbeit untersuchen.
-\begin{itemize}
- \item Behauptung 1
- \item Behauptung 2
- \item Behauptung 3
-\end{itemize}
-Beschreiben sie was die Beiträge ihrer Arbeit sind.
-
-\section{Methoden}
-\minisec{Methodology}
-
-%In this section you explain your approach -- did you use the author's code, did you aim to re-implement the approach from the paper description? Summarize the resources (code, documentation, GPUs) that you used.
-
-\subsection{Modellbeschreibung}
-\minisec{Model descriptions}
-
-Beischreiben sie die Modelle, die im Originalartikel genutzt werden, einschließlich der Architektur, der Zielfunktion und der Parameter.
-%Describe the models used in the original paper, including the architecture, learning objective and the number of parameters.
-
-\subsection{Datenbeschreibung}
-\minisec{Data descriptions}
-
-Beschreiben sie die Datenmengen, die sie genutzt haben und wie sie sie bekommen haben.
-%Describe the datasets you used and how you obtained them.
-
-\subsection{Hyperparameter}
-\minisec{Hyperparameters}
-
-Beschreiben sie, wie sie Hyperparameter gesetzt haben. Welche Quellen haben sie für die konkreten Werte genutzt (z.B. den Forschungsartikel, Code oder sie hatten eine wohlbegründete Vermutung, educated guess).
-%Describe how you set the hyperparameters and what the source was for their value (e.g. paper, code or your guess).
-
-\subsection{Implementierung}
-\minisec{Implementation}
-
-Beschreiben sie, ob sie vorhandenen Code oder eigenen Code genutzt haben.
-Stellen sie Links zum Code bereit und beschreiben sie welche Programmiersprachen und Pakete genutzt wurden.
-Ihr Github oder Gitlab-Reposititory sollte öffentlich sein.
-Das Reposititory sollte klar dokumentiert werden.
-%Describe whether you use the existing code or write your own code, with the link to the code and which programming languages/packages were used. Note that the github repo you link to should be public and have a clear documentation.
-
-\subsection{Aufbau der Experimente}
-\minisec{Experimental setup}
-
-Erklären sie, wie sie ihre Experimente durchgeführt haben. Was für Ressourcen haben sie verwendet, z.B. GPU/CPU-Ressourcen.
-Verlinken sie ihren Code und Notebooks.
-%Explain how you ran your experiments, e.g. the CPU/GPU resources and provide the link to your code and notebooks.
-
-\subsection{Ressourcen für Berechnungen}
-\minisec{Computational requirements}
-
-Beschreiben sie die Anforderungen für die Berechnungen für jedes ihrer Experimente, z.B. die Anzahl der CPU/GPU-Stunden oder die Voraussetzungen für den Hauptspeicher und GPU-Speicher.
-Geben sie für Zeit und Speicher eigene Abschätzungen an, bevor die Experimente gelaufen sind und vergleichen sie diese mit den tatsächlich verbrauchten Ressourcen.
-Sie müssen vor den Experimenten einplanen, dass diese Informationen auch durch ihren Code gemessen und gespeichert werden.
-
-% Provide information on computational requirements for each of your experiments. For example, the number of CPU/GPU hours and memory requirements.
-% Mention both your estimation made before running the experiments (i.e. in the proposal) and the actual resources you used to reproducing the experiments.
-% \textbf{\textit{You'll need to think about this ahead of time, and write your code in a way that captures this information so you can later add it to this section.} }
-
-
-\section{Ergebnisse}
-\minisec{Results}
-
-Starten sie mit einem Überblick über die Ergebnisse.
-Bestätigen ihre Ergebnisse die aufgeführten Behauptungen?
-Dieser Abschnitt sollte hauptsächlich Fakten nennen und so präzise wie möglich geschrieben werden.
-Die Bewertung und Diskussion kann im späteren Kapitel \enquote{Diskussion} folgen.
-
-% Start with a high-level overview of your results. Does your work support the claims you listed in section 2.1? Keep this section as factual and precise as possible, reserve your judgement and discussion points for the next \enquote{Discussion} section.
-
-Beschreiben sie dann detailliert jedes einzelne Ergebnis, das sie haben.
-Zeigen sie wie es mit einer oder mehreren Behauptungen in Beziehung steht.
-Erklären sie konkret was der Kern ihres Ergebnis ist.
-Gruppieren sie die Ergebnisse in logische Abschnitte.
-Beschreiben sie klar, wo sie über den Originalartikel hinausgegangen sind, wo sie zusätzliche Experimente durchgeführt haben und wie diese mit den ursprünglichen Behauptungen in Beziehung stehen.
-
-% Go into each individual result you have, say how it relates to one of the claims, and explain what your result is. Logically group related results into sections. Clearly state if you have gone beyond the original paper to run additional experiments and how they relate to the original claims.
-
-Tipp 1: Drücken sie sich genau aus und verwenden sie eine klare und einfache Sprache, z.B.
-\begin{quote}
- \enquote{we reproduced the accuracy to within 1\% of reported value, that upholds the paper's conclusion that it performs much better than baselines.} oder
-
- \enquote{We konnten die Klassifikationsrate bis auf 1\% des angegebenen Werts reproduzieren. Dies unterstützt die Schlussfolgerung der Artikels, dass der Ansatz leistungsfähiger als die Baselines ist.}
-\end{quote}
-Oft kann man nicht die exakt gleiche numerische Zahl als Ergebnis bekommen. Deshalb müssen sie das Ergebnis bewerten, um zu entscheiden, ob ihr Ergebnis die Behauptung der Originalartikels unterstützt.
-% Getting exactly the same number is in most cases infeasible, so you'll need to use your judgement call to decide if your results support the original claim of the paper.
-
-Tipp 2: Nutzen sie Tabellen und Abbildungen, um ihre Ergebnisse darzustellen.
-% You may want to use tables and figures to demonstrate your results.
-
-% The number of subsections for results should be the same as the number of hypotheses you are trying to verify.
-
-\subsection{Ergebnis 1}
-\minisec{Result 1}
-
-\subsection{Ergebnis 2}
-\minisec{Result 2}
-
-\subsection{Zusätzliche Ergebnisse, die nicht im Originalartikel enthalten waren}
-\minisec{Additional results not present in the original paper}
-Beschreiben sie alle zusätzlichen Experimente, die über den Originalartikel hinausgehen.
-Dies können Experimente zu weiteren Datenmengen sein oder sie probieren andere Methoden bzw. weitere Vereinfachungen des Modells aus oder passen die Hyperparameter an.
-Beschreiben sie für jedes zusätzliche Experiment, was sie genau durchgeführt haben, was die Ergebnisse sind und diskutieren sie was diese Ergebnisse zeigen.
-
-% Describe any additional experiments beyond the original paper. This could include experimenting with additional datasets, exploring different methods, running more ablations, or tuning the hyperparameters. For each additional experiment, clearly describe which experiment you conducted, its result, and discussions (e.g. what is the indication of the result).
-
-\section{Diskussion}
-\minisec{Discussion}
-Beschreiben sie die weiterführenden Implikationen der experimentellen Ergebnisse.
-War der Originalartikel replizierbar bzw. reproduzierbar.
-Falls nicht, welche Faktoren haben dazu geführt, dass die Experimente nicht reproduziert werden konnten.
-
-% Describe larger implications of the experimental results, whether the original paper was reproducible, and if it wasn’t, what factors made it irreproducible.
-
-Bewerten sie, ob sie die Evidenz, die sie durch das Durchführen der Experimente erhalten haben, auch überzeugt, dass die Behauptungen des Originalartikels dadurch gestützt werden.
-Diskutieren sie die Stärken und Schwächen ihres Ansatzes, vielleicht haben sie aus Zeitgründen nicht alle Experimente durchführen können, oder vielleicht haben zusätzliche Experimente durchgeführt, die den Originalartikel weiter stärken.
-
-% Give your judgement on if you feel the evidence you got from running the code supports the claims of the paper. Discuss the strengths and weaknesses of your approach -- perhaps you didn't have time to run all the experiments, or perhaps you did additional experiments that further strengthened the claims in the paper.
-
-
-\subsection{Was war einfach?}
-\minisec{What was easy}
-Beschreiben sie welche Teile der Replikation/Reproduktion sich leicht umsetzen ließen.
-Lief der Code der Autoren problemlos? War es aufgrund der Beschreibung im Originalartikel nicht aufwändig die Methoden zu reimplementieren?
-Dieser Abschnitt soll den Lesenden zeigen, welche Teile des Originalartikels sich leicht für eigene Ansätze verwenden lässt.
-
-% Describe which parts of your reproduction study were easy. E.g. was it easy to run the author's code, or easy to re-implement their method based on the description in the paper. The goal of this section is to summarize to the reader which parts of the original paper they could easily apply to their problem.
-
-Tipp: Machen sie keine pauschalen Verallgemeinerungen. Was für sie leicht ist, muss für andere nicht leicht sein. Geben sie genügend Kontext und erklären sie warum manche Sachen leicht waren, z.B. der Code hatte eine umfangreiche Dokumentation der Schnittstellen und viele Beispiele aus der Dokumentation passten zu den Experimenten im Artikel.
-
-% Be careful not to give sweeping generalizations. Something that is easy for you might be difficult to others. Put what was easy in context and explain why it was easy (e.g. code had extensive API documentation and a lot of examples that matched experiments in papers).
-
-\subsection{Was war schwer?}
-\minisec{What was difficult}
-Beschreiben sie welche Teile ihrer Replikation/Reproduktion aufwändig oder schwierig waren oder viel mehr Zeit in Anspruch genommen haben, als sie erwarteten.
-Vielleicht waren Daten nicht verfügbar, so dass sie einige Experimente nicht verifizieren konnten, oder der Code der Autoren funktionierte nicht und musste erst debugged werden.
-Vielleicht dauerten auch einige Experimente zu lange und sie konnten sie deshalb nicht verifizieren.
-Dieser Abschnitt soll den Lesenden zeigen, welche Teile des Originalartikels schwer wiederverwendbar sind, bzw. signifikante Zusatzarbeiten und Ressourcen erfordern.
-
-% Describe which parts of your reproduction study were difficult or took much more time than you expected. Perhaps the data was not available and you couldn't verify some experiments, or the author's code was broken and had to be debugged first. Or, perhaps some experiments just take too much time/resources to run and you couldn't verify them. The purpose of this section is to indicate to the reader which parts of the original paper are either difficult to re-use, or require a significant amount of work and resources to verify.
-
-Tipp: Setzen sie sorgfältig ihre Diskussion in den richtigen Kontext, z.B. sagen sie nicht \enquote{ die Mathematik war schwer verständlich} sondern sagen sie \enquote{ die Mathematik erfordert fortgeschrittene Kenntnisse in Analysis für das Verständnis}.
-
-% Be careful to put your discussion in context. For example, don't say \enquote{the math was difficult to follow,} say \enquote{the math requires advanced knowledge of calculus to follow.}
-
-\subsection{Empfehlungen für die Replizierbarkeit / Reproduzierbarkeit}
-\minisec{Recommendations for reproducibility}
-Geben sie Empfehlungen, wie die Autoren des Originalartikels oder andere Forschende in diesem Feld die Replizierbarkeit / Reproduzierbarkeit verbessern können.
-
-% Describe a set of recommendations to the original authors or others who work in this area for improving reproducibility.
-
-\section{Kommunikation mit den Autoren}
-\minisec{Communication with original authors}
-Dokumentieren sie das Ausmaß (oder das Fehlen) der Kommunikation mit Autoren.
-Stellen sie sicher, dass der Bericht eine faire Beurteilung der Forschungsarbeiten ist. Versuchen sie deshalb mit den Autoren Kontakt aufzunehmen.
-Sie können ihnen konkrete Fragen stellen oder falls sie keine Fragen haben, den Bericht zusenden und um Feedback bitten.
-
-% Document the extent of (or lack of) communication with the original authors. To make sure the reproducibility report is a fair assessment of the original research we recommend getting in touch with the original authors. You can ask authors specific questions, or if you don't have any questions you can send them the full report to get their feedback.
-
-\nocite{Talaei2024}
\printbibliography
+% Notizen für später zur Formatierung:
+% - cites am Satzende dem typischen anpassen, erst eckige Klammern, dann Punkt \cite{Talaei}.
+% - von IEEE citestyle & bibstyle zu numeric-comp citestyle & numeric bibstyle wechseln
+% - Begriffhervorhebungen einheitlich: kursiv oder fett? ggf. Höchstens Überschriften
+% - \paragraph und \minisec sinnvoll einsetzen, nicht zu sehr mischen
\end{document}
-
diff --git a/report/Vortrag/beamercolorthemeModernBeamer.sty b/report/Vortrag/beamercolorthemeModernBeamer.sty
index d7756b28826eed6ab10894121bc9e03917e43707..c8f19879c4a18de709bfdb3e55c6f7428999d367 100644
--- a/report/Vortrag/beamercolorthemeModernBeamer.sty
+++ b/report/Vortrag/beamercolorthemeModernBeamer.sty
@@ -31,4 +31,4 @@
\setbeamercolor{title}{fg=Solitude}
\setbeamercolor{subtitle}{fg=Solitude}
\setbeamercolor{author}{fg=Solitude}
-\setbeamercolor{institute}{fg=Solitude}
+\setbeamercolor{institute}{fg=Solitude}
\ No newline at end of file
diff --git a/report/Vortrag/beamerfontthemeModernBeamer.sty b/report/Vortrag/beamerfontthemeModernBeamer.sty
index 9781c9734faec7a018cf11832eb9ab71e1f64ee9..bcd8f0ed3bdca4f921260515fc25310d78002c94 100644
--- a/report/Vortrag/beamerfontthemeModernBeamer.sty
+++ b/report/Vortrag/beamerfontthemeModernBeamer.sty
@@ -24,4 +24,3 @@
\mode
<all>
-
diff --git a/report/Vortrag/beamerinnerthemeModernBeamer.sty b/report/Vortrag/beamerinnerthemeModernBeamer.sty
index b3a4c47ddc8960d9323722fc5845abe5bf8fbea5..0f668a2f7023bf518d32aac8e66ae83d2fef338a 100644
--- a/report/Vortrag/beamerinnerthemeModernBeamer.sty
+++ b/report/Vortrag/beamerinnerthemeModernBeamer.sty
@@ -158,7 +158,7 @@
\newcommand \makesection[1]{
{
\usebackgroundtemplate{
-\includegraphics[width=\paperwidth]{AICStyleData/logos/LogoShapeLightRotated.png}
+\includegraphics[width=\paperwidth]{Vortrag/AICStyleData/logos/LogoShapeLightRotated.png}
}
\begin{frame}[plain, noframenumbering]
\section{#1}
@@ -175,7 +175,7 @@
\newcommand \makefinalpage{
{
\usebackgroundtemplate{
- \includegraphics[width=\paperwidth]{AICStyleData/logos/LogoShapeDarkRotated.png}
+ \includegraphics[width=\paperwidth]{Vortrag/AICStyleData/logos/LogoShapeDarkRotated.png}
}
\begin{frame}[plain]
\usebeamertemplate{endpage}
@@ -188,7 +188,7 @@
\newcommand \maketitlepage{
{
\usebackgroundtemplate{
- \includegraphics[width=\paperwidth]{AICStyleData/logos/LogoShapeDarkRotated.png}
+ \includegraphics[width=\paperwidth]{Vortrag/AICStyleData/logos/LogoShapeDarkRotated.png}
}
\begin{frame}[plain]
% Print the title page as the first slide
@@ -201,4 +201,3 @@
% Formatting for header columns in multi-column page
\newcommand\colheader[1]{\textcolor{NeonBlue}{\textbf{#1}}\par}
% ----------------------------------------------------------
-
diff --git a/report/Vortrag/beamerthemeModernBeamer.sty b/report/Vortrag/beamerthemeModernBeamer.sty
index db00f61f75c4d90168374ffe877c6deecf559d33..a2b8dea16cbccba854ba86d3d3f2c5856fbec35b 100644
--- a/report/Vortrag/beamerthemeModernBeamer.sty
+++ b/report/Vortrag/beamerthemeModernBeamer.sty
@@ -8,4 +8,4 @@
\usecolortheme{ModernBeamer}
\useinnertheme{ModernBeamer}
-\mode<all>
+\mode<all>
\ No newline at end of file
diff --git a/report/Vortrag/main.tex b/report/Vortrag/main.tex
index 03ea0494a2a8518bf1e2231f4524532616e6dbf6..932c28db51bd0cf47d1a862f5d51a8b229230c57 100644
--- a/report/Vortrag/main.tex
+++ b/report/Vortrag/main.tex
@@ -422,4 +422,4 @@
%-----------------------------------------------
\makefinalpage
%-----------------------------------------------
-\end{document}
+\end{document}
\ No newline at end of file
diff --git a/report/assets/embedding.tex b/report/assets/embedding.tex
new file mode 100644
index 0000000000000000000000000000000000000000..dedd9773c8b06a84ddbd05f3f057ce24e283d13a
--- /dev/null
+++ b/report/assets/embedding.tex
@@ -0,0 +1,15 @@
+\lstset{style=mypythonstyle}
+\begin{lstlisting}[language=Python, escapechar=!, float, caption=Ergänzung von LangChain um das Plugin für Ollama, label=lst:embedding]
+# In $CHESS/src/database_utils/db_catalog/preprocess.py
+...
+!\colorbox{codegreen}{ from langchain\_ollama import OllamaEmbeddings }!
+!\colorbox{codegreen}{ EMBEDDING\_FUNCTION = OllamaEmbeddings(model=\textquotedblleft mxbai-embed-large\textquotedblright) }!
+...
+
+# In $CHESS/src/workflow/agents/information_retriever/tool_kit/retrieve_entity.py
+!\colorbox{codegreen}{ from langchain\_ollama import OllamaEmbeddings }!
+...
+def __init__(self):
+ !\colorbox{codegreen}{ self.embedding\_function = OllamaEmbeddings(model=\textquotedblleft nomic-embed-text\textquotedblright) }!
+ ...
+\end{lstlisting}
\ No newline at end of file
diff --git a/report/assets/evidence.tex b/report/assets/evidence.tex
new file mode 100644
index 0000000000000000000000000000000000000000..ce761f0e00c80d1ccea41454d8884f7fd9a4c394
--- /dev/null
+++ b/report/assets/evidence.tex
@@ -0,0 +1,11 @@
+\lstset{style=mypythonstyle}
+\begin{lstlisting}[language=Python, escapechar=!, float, caption=Änderungen an der Schnittstelle zum Laden der Datensätze, label=lst:evidence]
+def initialize_tasks(self, dataset: List[Dict[str, Any]]):
+ ...
+ !\colorbox{codegreen}{if \textquotedblleft evidence\textquotedblright{} not in data: }!
+ !\colorbox{codegreen}{data = \{\textquotedblleft evidence\textquotedblright: \textquotedblleft (No hint provided)\textquotedblright, **data\} }!
+
+ !\colorbox{codegreen}{if \textquotedblleft SQL\textquotedblright{} not in data and \textquotedblleft query\textquotedblright{} in data: }!
+ !\colorbox{codegreen}{data = \{\textquotedblleft SQL\textquotedblright: data[\textquotedblleft query\textquotedblright], **data\} }!
+
+\end{lstlisting}
\ No newline at end of file
diff --git a/report/assets/implRevise.tex b/report/assets/implRevise.tex
new file mode 100644
index 0000000000000000000000000000000000000000..2785c707902b29778a7b57b1a5f2ebd39ff1f588
--- /dev/null
+++ b/report/assets/implRevise.tex
@@ -0,0 +1,24 @@
+\lstset{style=mypythonstyle}
+\begin{lstlisting}[language=Python, escapechar=!, float, caption=Änderungen an der Implementierung des revise-Tools, label=lst:revise]
+def __init__(self, ... !\colorbox{codegreen}{sampling\_count: int = 1}! ):
+ ...
+ !\colorbox{codegreen}{self.sampling\_count = sampling\_count}!
+
+def _run(self, state: SystemState):
+ ...
+ response = async_llm_chain_call(
+ prompt = ...
+ ...
+ sampling_count=!\colorbox{codegreen}{self.sampling\_count}!
+ )
+ response = [r[0] for r in response]
+
+ !\colorbox{codegreen}{revised\_sqls = [res[\textquotedblleft revised\_SQL\textquotedblright] for res in response]}!
+ for target_SQL_meta_info in target_SQL_meta_infos:
+ if target_SQL_meta_info.need_fixing:
+ !\colorbox{codegreen}{revised\_sql = DatabaseManager().aggregate\_sqls(sqls=revised\_sqls)}!
+ !\colorbox{codegreen}{chosen\_res = next(res for res in response if res[\textquotedblleft revised\_SQL\textquotedblright] == revised\_sql)}!
+ !\colorbox{codegreen}{refinement\_response = \{ \textquotedblleft refined\_sql\_query\textquotedblright: chosen\_res[\textquotedblleft revised\_SQL\textquotedblright] \} }!
+ else
+ ...
+\end{lstlisting}
\ No newline at end of file
diff --git a/report/assets/python_lstlisting.tex b/report/assets/python_lstlisting.tex
new file mode 100644
index 0000000000000000000000000000000000000000..989e82b8c098bc649ffa442bcf4c3b43f5b668d7
--- /dev/null
+++ b/report/assets/python_lstlisting.tex
@@ -0,0 +1,32 @@
+\usepackage{listings}
+
+\usepackage{color}
+\definecolor{light-gray}{gray}{0.80}
+
+\usepackage{xcolor}
+%New colors defined below
+\definecolor{codegreen}{rgb}{0,0.6,0}
+\definecolor{codegray}{rgb}{0.5,0.5,0.5}
+\definecolor{codepurple}{rgb}{0.58,0,0.82}
+\definecolor{backcolour}{rgb}{0.95,0.95,0.92}
+
+%Code listing style named "mystyle"
+\lstdefinestyle{mypythonstyle}{
+ %backgroundcolor=\color{backcolour},
+ commentstyle=\color{codegreen},
+ keywordstyle=\color{magenta},
+ numberstyle=\tiny\color{codegray},
+ stringstyle=\color{codepurple},
+ basicstyle=\ttfamily\footnotesize,
+ breakatwhitespace=false,
+ breaklines=true,
+ captionpos=b,
+ keepspaces=true,
+ numbers=left,
+ numbersep=5pt,
+ showspaces=false,
+ showstringspaces=false,
+ showtabs=false,
+ tabsize=2,
+ frame=single,
+}
\ No newline at end of file
diff --git a/report/assets/tentative.tex b/report/assets/tentative.tex
new file mode 100644
index 0000000000000000000000000000000000000000..ef575c0571d46d472d7cddb570c49a0a9b83e6fe
--- /dev/null
+++ b/report/assets/tentative.tex
@@ -0,0 +1,14 @@
+
+
+\lstset{style=mypythonstyle}
+\begin{lstlisting}[language=Python, escapechar=!, float, caption=Änderungen an der Implementierung des GC Agenten, label=lst:tentative]
+class GenerateCandidate(Tool):
+ def _run(self, state: SystemState):
+ ...
+ request_kwargs = {
+ "DATABASE_SCHEMA": state.get_schema_string(schema_type="!\colorbox{codegreen}{tentative}!",
+ "QUESTION": state.task.question,
+ "HINT": state.task.evidence,
+ }
+ ...
+\end{lstlisting}
\ No newline at end of file
diff --git a/report/chessbibliography.bib b/report/chessbibliography.bib
index d7d86c97bdbdca07361aad7173b8f377d44d1fa5..8f98870d38841241fff5d31058372e53d12a648d 100644
--- a/report/chessbibliography.bib
+++ b/report/chessbibliography.bib
@@ -1,3 +1,72 @@
+@article{lee2024mcs,
+ title={MCS-SQL: Leveraging Multiple Prompts and Multiple-Choice Selection For Text-to-SQL Generation},
+ author={Lee, Dongjun and Park, Choongwon and Kim, Jaehyuk and Park, Heesoo},
+ journal={arXiv preprint arXiv:2405.07467},
+ doi={10.48550/ARXIV.2405.07467},
+ year={2024}
+}
+
+@article{bird,
+ title={Can LLm Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs},
+ author={Li, Jinyang and Hui, Binyuan and Qu, Ge and Yang, Jiaxi and Li, Binhua and Li, Bowen and Wang, Bailin and Qin, Bowen and Geng, Ruiying and Huo, Nan and Zhou, Xuanhe and Chenhao, Ma and Li, Guoliang and Chang, Kevin and Huang, Fei and Cheng, Reynold and Li, Yongbin},
+ journal={Advances in Neural Information Processing Systems},
+ pages={42330--42357},
+ url={https://proceedings.neurips.cc/paper_files/paper/2023/file/83fc8fab1710363050bbd1d4b8cc0021-Paper-Datasets_and_Benchmarks.pdf},
+ urldate={2025-02-24},
+ volume={36},
+ year={2023}
+}
+
+@article{spider1,
+ title={Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task},
+ author={Yu, Tao and Zhang, Rui and Yang, Kai and Yasunaga, Michihiro and Wang, Dongxu and Li, Zifan and Ma, James and Li, Irene and Yao, Qingning and Roman, Shanelle and others},
+ journal={arXiv preprint arXiv:1809.08887},
+ doi={10.48550/ARXIV.1809.08887},
+ year={2018}
+}
+
+@article{spider2,
+ title={Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows},
+ author={Lei, Fangyu and Chen, Jixuan and Ye, Yuxiao and Cao, Ruisheng and Shin, Dongchan and Su, Hongjin and Suo, Zhaoqing and Gao, Hongcheng and Hu, Wenjing and Yin, Pengcheng and others},
+ journal={arXiv preprint arXiv:2411.07763},
+ doi={10.48550/ARXIV.2411.07763},
+ year={2024}
+}
+
+@Online{MxbaiEmbed2024,
+ author = {Lee, Sean and Shakir, Aamir and Koenig, Darius and Lipp, Julius},
+ title = {Open Source Strikes Bread - New Fluffy Embedding Model},
+ date = {2024-03-08},
+ url = {https://www.mixedbread.com/blog/mxbai-embed-large-v1},
+ urldate = {2025-02-27}
+}
+
+@Article{Nussbaum2024,
+ author = {Nussbaum, Zach and Morris, John X. and Duderstadt, Brandon and Mulyar, Andriy},
+ date = {2024-02-02},
+ title = {Nomic Embed: Training a Reproducible Long Context Text Embedder},
+ doi = {10.48550/ARXIV.2402.01613},
+ eprint = {2402.01613},
+ eprintclass = {cs.CL},
+ eprinttype = {arXiv},
+ abstract = {This technical report describes the training of nomic-embed-text-v1, the first fully reproducible, open-source, open-weights, open-data, 8192 context length English text embedding model that outperforms both OpenAI Ada-002 and OpenAI text-embedding-3-small on the short-context MTEB benchmark and the long context LoCo benchmark. We release the training code and model weights under an Apache 2.0 license. In contrast with other open-source models, we release the full curated training data and code that allows for full replication of nomic-embed-text-v1. You can find code and data to replicate the model at https://github.com/nomic-ai/contrastors.},
+ copyright = {Creative Commons Attribution 4.0 International},
+ keywords = {Computation and Language (cs.CL), Artificial Intelligence (cs.AI), FOS: Computer and information sciences},
+ publisher = {arXiv},
+ journal = {arXiv},
+ year = {2024},
+}
+
+@Misc{Grattafiori2024,
+ author = {Grattafiori, Aaron and Dubey, Abhimanyu and Jauhri, Abhinav and Pandey, Abhinav and Kadian, Abhishek and Al-Dahle, Ahmad and Letman, Aiesha and Mathur, Akhil and Schelten, Alan and Vaughan, Alex and Yang, Amy and Fan, Angela and Goyal, Anirudh and Hartshorn, Anthony and Yang, Aobo and Mitra, Archi and Sravankumar, Archie and Korenev, Artem and Hinsvark, Arthur and Rao, Arun and {andere}},
+ date = {2024},
+ title = {The Llama 3 Herd of Models},
+ doi = {10.48550/ARXIV.2407.21783},
+ copyright = {arXiv.org perpetual, non-exclusive license},
+ keywords = {Artificial Intelligence (cs.AI), Computation and Language (cs.CL), Computer Vision and Pattern Recognition (cs.CV), FOS: Computer and information sciences, FOS: Computer and information sciences},
+ publisher = {arXiv},
+}
+
@Misc{Talaei2024,
author = {Talaei, Shayan and Pourreza, Mohammadreza and Chang, Yu-Chen and Mirhoseini, Azalia and Saberi, Amin},
title = {CHESS: Contextual Harnessing for Efficient SQL Synthesis},
@@ -8,3 +77,52 @@
publisher = {arXiv},
}
+@Online{DeepSeekNL2SQL2024,
+ author = {Talaei, Shayan and Pourreza, Mohammadreza},
+ title = {AI4DS/NL2SQL\_DeepSeek\_33B},
+ date = {2024-05-06},
+ url = {https://huggingface.co/AI4DS/NL2SQL_DeepSeek_33B},
+ urldate = {2025-02-27}
+}
+
+@Online{ChessRepo2024,
+ author = {Talaei, Shayan and Pourreza, Mohammadreza},
+ title = {CHESS},
+ subtitle = {README -- CHESS: Contextual Harnessing for Efficient SQL Synthesis},
+ date = {2024-11-13},
+ url = {https://github.com/ShayanTalaei/CHESS},
+ urldate = {2025-02-27}
+}
+
+@online{SpiderLeaderbord,
+ author = {XLANG Lab},
+ title = {{Spider 2.0} Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows},
+ year = 2025,
+ url = {https://spider2-sql.github.io/},
+ urldate = {2025-02-19}
+}
+
+@article{seq2sql,
+ title={Seq2sql: Generating structured queries from natural language using reinforcement learning},
+ author={Zhong, Victor and Xiong, Caiming and Socher, Richard},
+ journal={arXiv preprint arXiv:1709.00103},
+ doi={10.48550/ARXIV.1709.00103},
+ year={2017}
+}
+
+@article{typesql,
+ title={Typesql: Knowledge-based type-aware neural text-to-sql generation},
+ author={Yu, Tao and Li, Zifan and Zhang, Zilin and Zhang, Rui and Radev, Dragomir},
+ journal={arXiv preprint arXiv:1804.09769},
+ doi={10.48550/ARXIV.1804.09769},
+ year={2018}
+}
+
+@article{towardscomplext2s,
+ title={Towards complex text-to-sql in cross-domain database with intermediate representation},
+ author={Guo, Jiaqi and Zhan, Zecheng and Gao, Yan and Xiao, Yan and Lou, Jian-Guang and Liu, Ting and Zhang, Dongmei},
+ journal={arXiv preprint arXiv:1905.08205},
+ doi={10.48550/ARXIV.1905.08205},
+ year={2019}
+}
+
diff --git a/report/content/01Einleitung.tex b/report/content/01Einleitung.tex
new file mode 100644
index 0000000000000000000000000000000000000000..ebc272ca1e7ab6c6810e8d95daa0109966b2559e
--- /dev/null
+++ b/report/content/01Einleitung.tex
@@ -0,0 +1,32 @@
+\section{Einleitung}
+%\minisec{Introduction}
+Diese Arbeit repliziert den Artikel \citetitle{Talaei2024} von \Citeauthor{Talaei2024} \cite{Talaei2024}, welcher sich mit der Generierung von SQL Anfragen aus Fragen in natürlicher Sprache beschäftigt. Im Bereich des Machine Learning existieren bereits viele Arbeiten zu solchen Text-To-SQL Problemen \cite{seq2sql,typesql,towardscomplext2s}.
+Durch den immensen Zuwachs an Daten und die steigende Komplexität von Datenbanksystemen können viele dieser Ansätze, selbst mit viel Rechenkapazität, der Problemstellung nicht mehr gerecht werden. In \cite{bird} wurde ein Unterschied in der \textit{Execution accuracy} von $40\%$ zwischen generierten und händisch geschriebenen SQL-Anfragen auf komplexen Datenbanken ermittelt. Aller Voraussicht nach wird die Menge an komplexen Daten in den nächsten Jahren nicht abnehmen. Die replizierte Arbeit stellt einen effektiveren Ansatz zur Lösung dieses Problems vor.
+
+Neue Text-To-SQL Lösungen müssen den folgenden Herausforderungen gerecht werden \cite[vgl.][]{Talaei2024}:
+\begin{enumerate}[label=(\roman*)]
+ \item Großer Umfang der Daten
+ \item Generieren der SQL-Anfragen für große Datenbank-Schemata
+ \item Verifikation der generierten Anfragen
+ \item Mehrdeutigkeiten in den Fragestellungen auflösen
+\end{enumerate}
+Zur Lösung dieser Probleme wird in \cite{Talaei2024} ein neues Multi-Agent-Framework präsentiert, welches mithilfe von Large Language Models (LLMs) eine effektivere Generierung der SQL-Anfragen unter den genannten Herausforderungen ermöglichen soll. Zudem wird die Adaptivität dieses Ansatzes hervorgehoben, in Anwendungsszenarien mit unterschiedlichen Budgets und Rechenkapazität der LLMs, verschiedene Systemkonfigurationen zu ermöglichen. Dadurch sollen SQL-Anfragen auch mit limitierten Ressourcen auf komplexen Datenbanken generiert werden können.
+
+Wir sehen in diesem Ansatz viel Potenzial, neuen Herausforderungen mit aktuellen Technologien zu begegnen. Die experimentellen Untersuchungen in \cite{Talaei2024} erzielen wettbewerbsfähige Ergebnisse bei anerkannten Text-To-SQL Benchmarks. Diese Ergebnisse wollen wir zunächst auf einem kleinen Subsampled Development Set (SDS) basierend auf dem BIRD-Datensatz \cite{bird}, später auf dem Spider-Datensatz \cite{spider1} reproduzieren.
+
+Aufgrund monetärer Beschränkungen ist es uns nicht möglich, Experimente mit proprietären Modellen, wie sie in \cite{Talaei2024} genutzt wurden, zu replizieren. Dies führt dazu, dass wir den vollständigen BIRD-Datensatz und den synthetisch erzeugten industrial-scale Datensatz aus \cite{Talaei2024} nicht testen können. Außerdem entfallen für unsere Experimente die Tests mit Konfigurationen für leistungsstarke LLMs. Daher möchten wir in dieser Arbeit einen qualitativen Vergleich der Ergebnisse aus \cite{Talaei2024} mit Open-Source Modellen durchführen, wobei wir hoffen, ähnliche Ergebnisse zu erzielen.
+
+Darüber hinaus testen wir verschiedene Konfigurationen des Candidate Generators, einem der vier Agenten des Frameworks. Dadurch werden wir neue Einblicke über die Konfigurationsparameter der genutzten LLMs erhalten.
+
+Nachfolgend beschreiben wir in \autoref{sec:Scope} ausführlich den Umfang unserer Replikation und formulieren die untersuchten Behauptungen. In \autoref{sec:methoden} gehen wir detailliert auf den Aufbau der Experimente und die genutzten Ressourcen ein. Die Ergebnisse präsentieren wir schließlich in \autoref{sec:ergebnisse} und diskutieren diese dann in \autoref{sec:diskussion}. % Auf die Kommunikation mit den Autoren
+
+% TODO
+% - Subsampled Spider oder voller Spider (Z. 15)
+
+%%% Hinneburgs Vorschläge:
+%Beschreiben sie mit ein paar Sätzen den Kontext der replizierten/reproduzierten Arbeit. Es werden höchstens drei bis vier Paragraphen erwartet. Sie sollen hinreichend erklären, was das das Problem ist, das der Artikel bearbeitet, warum es ein wichtiges Problem ist. Fassen sie die Beträge des replizierten/reproduzierten Artikels zusammen. Zitieren sie in diesem Abschnitt relevante wissenschaftliche Arbeiten. Beschreiben, warum wir das Paper Replizieren wollen/ warum es spannend ist, dieses Paper zu replizieren.
+
+% Was ist der Beitrag des replizierten Artikels?
+% Welche Teile der Arbeit wurden für die Replikation ausgewählt? Begründen Sie die Auswahl. Warum wurden andere Teile der Arbeit nicht repliziert?
+% Welche neuen Erkenntnisse erwarten Sie durch die geplante Reproduktion? Was steht davon nicht in dem replizierten Artikel?
+% Was ist der Beitrag bzw. sind die Beiträge Ihres Artikels über die Reproduktion der ausgewählten Arbeit?
\ No newline at end of file
diff --git a/report/content/02Umfang.tex b/report/content/02Umfang.tex
new file mode 100644
index 0000000000000000000000000000000000000000..9598eec1db843c4e6a89f274464628b5d6d0d644
--- /dev/null
+++ b/report/content/02Umfang.tex
@@ -0,0 +1,87 @@
+\section{Umfang der Replikation/Reproduktion}
+\label{sec:Scope}
+Zunächst erklären wir das Multi-Agent-Framework und stellen die experimentellen Ergebnisse aus \cite{Talaei2024} vor. Danach motivieren wir die Auswahl der Experimente für unsere Replikation und formulieren schließlich die konkreten Behauptungen, welche wir experimentell untersuchen werden.
+% ------------------------------------------------------------------
+% Allgemeine Behauptungen/Hypothesen/Experimente der Arbeit erklären
+% ------------------------------------------------------------------
+\subsection{Experimente der Autoren}
+In \cite{Talaei2024} wird ein neuer Lösungsansatz für Text-To-SQL Probleme präsentiert, welcher insbesondere für komplexe Datenbanken mit vielen Tabellen und Spalten entwickelt wurde. Dieser Ansatz versucht das Problem mit einem Multi-Agent-Framework und vier spezialisierten Agenten zu lösen. Die vier Agenten übernehmen dabei folgende Aufgaben:
+\begin{enumerate}
+ \item \textbf{Information Retriever (IR)}:
+ \begin{itemize}
+ \item Analysieren der gestellten Frage des Nutzers mit LLM-Anfragen
+ \item Ermitteln der relevanten Entitäten und deren Kontext (DB-Schema, DB-Katalog)
+ \item Syntaktische- und semantische Ähnlichkeiten mit Lokalitätssensitivem Hashing (LSH) bestimmen % und Vektor-Datenbank
+ \end{itemize}
+ \item \textbf{Schema Selector (SS)}:
+ \begin{itemize}
+ \item Reduzieren von großen DB-Schemata in leichter zu erfassende Sub-Schemata
+ \item Auswählen benötigter Tabellen und Spalten mit LLM-Anfragen
+ \end{itemize}
+ \item \textbf{Candidate Generator (CG)}: Generieren, ausführen und überarbeiten von Kandidaten mit LLM-Anfragen
+ \item \textbf{Unit Tester (UT)}:
+ \begin{itemize}
+ \item Bewerten der Kandidaten mithilfe generierter Unit-Tests
+ \item Auswählen der finalen SQL-Anfrage
+ \end{itemize}
+\end{enumerate}
+
+Text-To-SQL Modelle müssen in realen Anwendungsszenarien mit unterschiedlichen Ressourcenkapazitäten zurecht kommen. Dies schränkt die Nutzung einiger Modelle ein, da diese leistungsstarke LLMs benötigen. Aus diesem Grund bietet das Multi-Agent-Framework verschiedene verschiedene Konfigurationsmöglichkeiten an. Für die experimentellen Untersuchungen werden in \cite{Talaei2024} die folgenden zwei Varianten des Frameworks abgeleitet:
+\begin{itemize}
+ \item $CHESS_{(IR,CG,UT)}$ - Konfiguriert für maximale Genauigkeit (mehr Rechenkapazität und stärkere LLMs)
+ \item $CHESS_{(IR,SS,CG)}$ - Konfiguriert für maximale Effizienz (limitierte Rechenkapazität und schwächere LLMs)
+\end{itemize}
+Die Bewertung der erzielten Ergebnisse auf unterschiedlichen Text-To-SQL Benchmarks erfolgt anhand der \textit{Execution accuracy ($EX$)}\footnote{Die Execution accuracy ist eine übliche Metrik für Text-To-SQL Benchmarks. Für jede Frage wird eine Liste von sogenannten \textit{gold-values} bereitgestellt, welche im Ergebnis der generierten Anfrage enthalten sein müssen. Die \textit{EX} stellt den Anteil der korrekt berechneten \textit{gold-values} im Verhältnis zu allen generierten SQL-Anfragen dar.}. Die experimentellen Ergebnisse aus \cite{Talaei2024} sind in \autoref{tab:performance} zusammengefasst. Beide Varianten des Frameworks können in dem jeweiligen Benchmark mit anderen Arbeiten mithalten.
+\begin{table}[!tb]
+ \centering
+ \begin{tabular}{l|c|c|c}
+ % width must be set manually bc this cell is not the biggest cell
+ \diagbox[width=16em,trim=l]{Methode}{Datensätze} & BIRD test & BIRD dev & Spider\\
+ \hline
+ Beste Methode (Stand 03/2025) & 77.14 \cite{bird} & 75.36 \cite{bird} & 91.2 \cite{spider1} \\
+ \hline
+ $CHESS_{(IR,CG,UT)}$ & 68.31 & 71.10 & -\\
+ $CHESS_{(IR,SS,CG)}$ + proprietär & 66.69 & 65.00 & 87.2 \\
+ $CHESS_{(IR,SS,CG)}$ + Open LLMs & - & 61.5 & -\\
+ \hline
+ $\Delta EX$ = $EX_{\text{proprietär}}$ - $EX_{\text{OpenLLM}}$ & - & 3.5 & - \\
+ \end{tabular}
+ \caption{\textit{Execution accuracy} verschiedener Framework-Konfigurationen auf unterschiedlichen Benchmarks \cite[siehe][Tabelle 1,2,3]{Talaei2024}}
+ \label{tab:performance}
+\end{table}
+
+% Motivieren und begründen sie ihre Auswahl
+\subsection{Motivation}
+Das erste Ziel unserer Arbeit soll die Replikation der Ergebnisse aus \autoref{tab:performance} auf den verschiedenen Benchmarks sein. Da wir die Experimente nur mit beschränkten Ressourcen durchführen können und keinen Zugang zu proprietären LLMs haben, sind wir insbesondere an der Replikation der Konfigurationsvariante $CHESS_{(IR,SS,CG)}$ mit quelloffenen LLMs interessiert und müssen andere ressourcenintensive Konfigurationen weitestgehend ausschließen. Zudem wird in \cite{Talaei2024} mehrfach die Adaptivität des vorgestellten Ansatzes an ressourcenbeschränkte Umgebungen hervorgehoben. Daher erwarten wir für die genannte Konfiguration mit quelloffenen LLMs ähnliche Ergebnisse zu erzielen.
+
+In den Ablations-Studies des replizierten Artikels wird zudem ein signifikanter Einfluss des revise-Tools beschrieben \cite[siehe][Tabelle 4]{Talaei2024}, welches fehlerhaft generierten SQL-Anfragen überarbeitet. Dies wollen wir unter Verwendung quelloffener LLMs verifizieren.
+
+Für den Spider-Datensatz wird in \cite{Talaei2024} nur ein Ergebnis mit proprietären LLMs angeführt. Wir wollen darüber hinaus auch einen Wert mit quelloffenen LLMs beitragen und erwarten, wie schon bei den proprietären LLMs gezeigt, eine höhere \textit{Execution Accuracy}, als für den BIRD-Datensatz zu erhalten.
+
+\subsection{Behauptungen und eigener Beitrag}
+Mit den beschriebenen Experimenten wollen wir die folgenden Behauptungen überprüfen:
+\begin{itemize}
+ \item \textbf{Behauptung 1:} \textit{Das CHESS-Framework in der Konfiguration $CHESS_{(IR,SS,CG)}$ erzielt mit quelloffenen LLMs eine $EX$ auf dem SDS-Datensatz von annähernd $EX=61.5$.} \label{txt:beh1bird}
+ \item \textbf{Behauptung 2:} \textit{Das CHESS-Framework in der Konfiguration $CHESS_{(IR,SS,CG)}$ mit quelloffenen LLMs wird durch das revise-Tool signifikant beeinflusst und erzielt auf dem SDS-Datensatz eine Differenz in der Execution Accuracy ($\Delta EX$) zwischen einmalige Revision und keiner Revision von annähernd $\Delta EX = 61.22 - 57.82 = 3.40$.}\label{txt:beh2revision}
+ \item \textbf{Behauptung 3:} \textit{Das CHESS-Framework in der Konfiguration $CHESS_{(IR,SS,CG)}$ erzielt mit quelloffenen LLMs eine Differenz in der Execution Accuracy ($\Delta EX$) zwischen dem BIRD-dev und Spider-Datensatz von annähernd $\Delta EX = 65.00 - 61.5 = 3.50$.}\label{txt:beh3spider}
+\end{itemize}
+
+\paragraph{Zu Behauptung 1, 2:} Unsere Ressourcenbeschränkung beinhaltet auch eine zeitliche Komponente, weshalb wir nicht den vollen BIRD-dev Datensatz testen können. Daher beschränken wir uns bei \hyperref[txt:beh1bird]{Behauptung 1} und \hyperref[txt:beh2revision]{Behauptung 2} auf den Subsampled Development Set (SDS) aus \cite{Talaei2024} mit 147, statt 1553 Frage-Anfrage Paaren, des BIRD-dev Datensatzes. Neben den unterschiedlichen Datenbanken sind in diesen reduzierten Datensatz auch unterschiedliche Schwierigkeitsgrade enthalten. Dennoch hoffen wir bei der Untersuchung von \hyperref[txt:beh1bird]{Behauptung 1} annähernd die \textit{Execution accuracy} von $EX=61.5$ aus \cite{Talaei2024} auf dem BIRD-dev Datensatz zu erreichen.
+
+\paragraph{Zu Behauptung 2:} In den Ablations-Studies von \cite{Talaei2024} wurde der Einfluss der verschiedenen Agenten und deren Tools auf die $EX$ der generierten Anfragen untersucht. Demnach soll das revise-Tool des Candidate Generators den größten Einfluss haben. Dieses überarbeitet generierte Anfragen, wenn bei deren Ausführung ein Fehler aufgetreten ist (z.B. Syntaxfehler), das Ergebnis leer oder unerwartet war. Der \texttt{sampling\_count} gibt dabei die Anzahl durchgeführter Revisionen an. Mit \texttt{sampling\_count = 1} konnte in \cite{Talaei2024} eine Verbesserung um $\Delta EX = 3.40$ gegenüber keiner Revision (\texttt{sampling\_count = 0}) erzielt werden. Diese Verbesserung versuchen wir mit quelloffenen LLMs zu replizieren.
+
+%Bei den beschriebenen Experimenten in \autoref{tab:performance} wurde pro fehlerhafter Anfrage mehrere Überarbeitungen parallel generiert und diese als gemeinsame Stichprobe genutzt. Das führt zu einer höheren Konsistenz der überarbeiteten Anfragen. Für unser Experiment zu \hyperref[txt:beh2revision]{Behauptung 2} beschränken wir die Größe dieser Stichprobe auf 1, um ein vergleichbares Ergebnis zu erhalten.
+
+\paragraph{Zu Behauptung 3:} In einem dritten Experiment wollen wir \autoref{tab:performance} um einen Wert für $CHESS_{(IR,SS,CG)}$ mit quelloffenen LLMs auf dem Spider-Datensatz ergänzen. Wir erwarten eine Differenz zwischen der $EX$ der proprietären Modelle und der $EX$ der quelloffenen Modelle von annähernd $\Delta EX = 3.50$ zu erreichen, wie es bei dem BIRD-dev Datensatz in \cite{Talaei2024} ermittelt wurde. Die \hyperref[txt:beh3spider]{Behauptung 3} ergibt sich damit nicht aus den Behauptungen des Originalpapers, sondern ist der Beitrag unserer Arbeit.
+
+%%% Hinneburgs Vorschläge:
+%\paragraph{Erkläre Behauptung}
+%\enquote{Erklären sie die Behauptungen/Hypothesen/Experimente des Artikels, die sie für ihre Replikation/Reproduktion ausgewählt haben.}
+%\paragraph{Motivation/ Begründung der Auswahl}
+%\enquote{Motivieren und begründen sie ihre Auswahl. Es ist sinnvoll, wenn sie sich auf die Behauptung konzentrieren, die der Hauptbeitrag des Artikels ist.}
+%\paragraph{Umfang Replikation abstecken}
+%\enquote{Stecken sie den Umfang ihrer Replikation/Reproduktion so klar wie möglich ab. Die Behauptungen ihres Berichts sollten durch die Ergebnisse ihrer Experimente unterstützt oder widerlegt werden.}
+%\paragraph{Behauptungen eindeutig aufführen}
+%\enquote{Führen sie eindeutig die Behauptungen auf, die sie in ihrer Arbeit untersuchen.}
+%\paragraph{Beschreibung Beiträge unserer Arbeit}
+%\enquote{Beschreiben sie was die Beiträge ihrer Arbeit sind.}
\ No newline at end of file
diff --git a/report/content/03Methoden.tex b/report/content/03Methoden.tex
new file mode 100644
index 0000000000000000000000000000000000000000..c4cfa3e13bc0b83800df250b998a7e93131b322b
--- /dev/null
+++ b/report/content/03Methoden.tex
@@ -0,0 +1,158 @@
+\section{Methoden}
+\label{sec:methoden}
+In diesem Abschnitt beschreiben wir den Aufbau unserer Experimente und die genutzten Ressourcen. Dazu gehen wir zunächst näher auf die einzelnen Agenten des Frameworks und deren Verwendung in den abgeleiteten Varianten ein.
+
+\subsection{Modellbeschreibung}
+%\minisec{Model descriptions}
+%\enquote{Beschreiben sie die Modelle, die im Originalartikel genutzt werden, einschließlich der Architektur, der Zielfunktion und der Parameter.}
+\paragraph{Multi-Agent-Framework}
+Die größte Herausforderung bei Text-To-SQL Problemen auf komplexen Datenbanken ist der Umgang mit den vielen Informationen und verschiedensten Dateiformaten, welche den LLMs zur Verfügung gestellt werden. Hinzu kommen Mehrdeutigkeiten in den Fragestellungen und innerhalb der bereitgestellten Informationen (z.B. Spalte \textit{id}). Aus diesem Grund wird in \cite{Talaei2024} ein Multi-Agent-Framework präsentieren, welches die Aufgabenstellung in vier Teilprobleme zerlegt und diese mit spezialisierten Agenten löst. Dadurch können die vielen Informationen zielgerichteter genutzt und die Komplexität großer Datenbank-Schemata leichter erfasst werden. Jeder Agent bearbeitet die ihm zugeteilten Aufgaben mit speziellen Anfragen an ein LLM \cite[siehe][Anhang C]{Talaei2024}.
+
+Im folgenden beschreiben wir kurz die Funktionsweise der vier Agenten, deren Aufgaben wir bereits in Kapitel \ref{sec:Scope} ausführlicher dargestellt haben.
+
+Der \textbf{Information Retriever} extrahiert aus der Fragestellung zunächst wichtige Schlüsselwörter, Entitäten und erwähnte Spaltennamen mit einer \textit{few-shot} Anfrage an ein LLM. Anschließend werden ähnliche Entitäten, Spalten und Werte in der Datenbank gesucht. Dazu wird die syntaktische Ähnlichkeit von Werten mithilfe von Lokalitätssensitivem Hashing (LSH) bestimmt. Semantische Informationen über den Kontext der Daten können dabei helfen, Mehrdeutigkeiten aufzulösen und nur relevante Daten an die anderen Agenten weiterzugeben. Der Kontext der Daten wird mithilfe des Datenbank Katalogs, Metadaten des Schemas und Beschreibungen der Spalten ermittelt.
+
+Um einen geordneten Informationsfluss zwischen den Agenten zu ermöglichen, wird eine interne Repräsentation der Datenbank erzeugt und beliebig verändert. Der \textbf{Schema Selector} wählt die benötigten Tabellen und Spalten zum Generieren der SQL-Anfrage mit Hilfe von \textit{few-shot} Anfragen aus. Dabei wird die interne DB-Repräsentation stark reduziert.
+
+Nachdem nun von den vielen Daten vom Anfang nur noch die relevanten Tabellen und Spalten übrig geblieben sind generiert der \textbf{Candidate Generator} mithilfe eines weiterem LLM Aufruf die SQL-Anfrage. Anschließend wird die SQL-Anfrage auf der internen DB-Repräsentation ausgeführt und gegebenenfalls einem revise-Tool übergeben, welches mit einem LLM Aufruf die fehlerhafte Anfrage überarbeitet.
+
+Der CG kann auch mehrere mögliche SQL-Anfrage generieren. Dann ist es die Aufgabe des \textbf{Unit Tester} die passenste Anfrage auszuwählen. Dazu generiert der Unit Tester für jede Frage $k$ viele Unit Tests, sodass nur eine korrekte SQL-Anfrage diese Tests erfüllt. Dann werden die verschiedenen Kandidaten mithilfe von LLM Aufrufen getestet und bewertet. Schließlich wird die finale SQL-Anfrage ausgewählt.
+
+\paragraph{Framework Varianten}
+In dem replizierten Artikel wird die Notwendigkeit hervorgehoben, Systeme für verschiedene Anwendungsszenarien konfigurieren zu können. Dabei wird vor allem die verfügbare Rechenkapazität und Stärke der LLMs betrachtet. Die Experimente in \cite{Talaei2024} werden mit zwei konträr konfigurierten Varianten des Frameworks durchgeführt: eine für maximale Effektivität ($CHESS_{(IR,CG,UT)}$) und eine für maximale Effizienz ($CHESS_{(IR,SS,CG)}$). Diese unterscheiden sich im wesentlichen darin, dass sie für viel/wenig Rechenkapazität und starke/schwache LLMs ausgelegt sind. Wie die Namen der Varianten bereits erkennen lassen, unterscheiden sie sich auch in den verwendeten Agenten.
+
+Überraschenderweise nutzt die $CHESS_{(IR,CG,UT)}$ Variante für viel Rechenkapazität nicht den Schema Selector Agent. Dies wird in \cite{Talaei2024} damit erklärt, dass aktuelle Benchmarks wie der BIRD-Datensatz eher kleinere Datenbanken beinhalten, wodurch der Overhead des Schema Selector Agent nicht benötigt wird und sogar zu einer Reduzierung der Leistung führt. Die Bedeutung des Schema-Linkings für komplexe Datenbanken wird in \cite{Talaei2024} mit einem anderen Experiment auf einem synthetisch erzeugten Datensatz gezeigt, für den alle vier Agenten benötigt werden.
+
+In unserer Replikation nutzen wir nur die $CHESS_{(IR,SS,CG)}$ Variante, bei der auf den Unit Tester verzichtet wurde. Dadurch werden insgesamt weniger LLM Anfragen benötigt, wodurch unsere limitierten Ressourcen besser genutzt werden. Zudem generiert der Candidate Generator nur einen Kandidaten, welcher dann auch als finale SQL-Anfrage genutzt wird. Das revise-Tool innerhalb des CGs wird aber trotzdem verwendet.
+
+\paragraph{LLM Modelle}
+In unserer Konfiguration nutzen wir analog zu \cite{Talaei2024} \textit{Llama-3-70B} \cite{Grattafiori2024} für:
+\begin{itemize}
+ \item Die Agenten Information Retriever, Schema Selector und Candidate Generator selbst,
+ \item Die Tools \textit{extract\_keywords} und \textit{retrieve\_context} des Information Retrievers,
+ \item Die Tools \textit{filter\_column}, \textit{select\_tables} und \textit{select\_columns} und
+ \item Das Tool \textit{revise}.
+\end{itemize}
+Im Candidate Generator verwenden wir für das Tool \textit{generate\_candidate} das in \cite{Talaei2024} nachtrainierte Modell \textit{NL2SQL\_DeepSeek\_33B} \cite{DeepSeekNL2SQL2024}.
+
+Zusätzlich werden in der Vorberchnung und im Tool \textit{retrieve\_entity} des Information Retrievers Embedding Modelle verwendet. Diese werden in \cite{Talaei2024} nur für die proprietären Modelle beschrieben, weshalb wir für die quelloffenen Modelle solche nutzen, die mit den Embedding Modellen der proprietären Modellen vergleichbare sind: In der Vorberechnung verwenden wir \textit{mxbai-embed-large} \cite{MxbaiEmbed2024} und für das \textit{retrieve\_entity} Tool \textit{nomic-embed-text} \cite{Nussbaum2024}.
+
+\subsection{Datenbeschreibung}
+%\minisec{Data descriptions}
+%\enquote{Beschreiben sie die Datenmengen, die sie genutzt haben und wie sie sie bekommen haben.}
+
+\paragraph{BIRD} Der BIRD Benchmark (BIg Bench for LaRge-scale Database Grounded Text-to-SQL Evaluation) \cite{bird} beinhaltet $12.751$ einzigartige Fragen, verteilt über $95$ Datenbanken. Die Daten stammen aus realen Anwendungen und enthalten mitunter komplizierte Formate. Zusätzlich werden Kontextinformationen und externes Wissen (Evidence) bereitgestellt, welche für die Generierung der Anfragen genutzt werden darf. Die Datensätze können von der offiziellen Webseite\footnote{BIRD: \url{https://bird-bench.github.io/}} herunter geladen werden.
+% https://bird-bench.github.io/
+
+\paragraph{Subsampled Development Set} Dieser Datensatz wurde in \cite{Talaei2024} für weitere Experimente aus dem BIRD \textit{development-set} generiert. Er enthält $10\%$ der Fragen aus dem \textit{dev}-Set und hat 147 Frage-Anfrage Paare, wovon $81$ leicht, $54$ moderat und $12$ schwer sind. Diese Daten werden über das offizielle Github-Repository\footnote{SDS: \url{https://github.com/ShayanTalaei/CHESS}} des Artikels bereitgestellt.
+
+\paragraph{Spider}
+Der Spider-Datensatz \cite{spider1} ist eine umfangreiche, komplexe und domänenübergreifende Sammlung für die Text-to-SQL-Forschung. Er umfasst 10.181 natürlichsprachliche Fragen sowie 5.693 einzigartige und anspruchsvolle SQL-Abfragen, die auf 200 verschiedenen Datenbanken basieren. Insgesamt decken diese Datenbanken 138 unterschiedliche Domänen ab. Der Datensatz steht über das offizielle GitHub-Repository\footnote{Spider: \url{https://yale-lily.github.io/spider}} zum Download bereit. Aus dem Spider-Datensatz verwenden wir das \textit{test}-Set.
+% https://yale-lily.github.io/spider
+
+\paragraph{Subsampled Spider}
+Bei der Durchführung unserer Experimente mussten wir feststellen, dass wir mit dem kompletten Spider-Datensatz die bereitgestellten Ressourcen über mehrere Tage blockieren würden. Mit Rücksicht auf andere Nutzer haben wir uns dazu entschieden, zunächst nur eine Teilmenge des Datensatzes für unsere Experimente zu nutzen. Dabei haben wir uns an dem SDS-Datensatz orientiert und von allen Datenbanken jeweils $10\%$ der Fragen zufällig ausgewählt. Damit reduziert sich der Datensatz auf 229 Frage-Anfrage Paare.
+
+\subsection{Hyperparameter} % Hypa-Parameter :)
+%\minisec{Hyperparameters}
+% \enquote{Beschreiben sie, wie sie Hyperparameter gesetzt haben. Welche Quellen haben sie für die konkreten Werte genutzt (z.B. den Forschungsartikel, Code oder sie hatten eine wohlbegründete Vermutung, educated guess).}
+Die standardmäßige Konfiguration von Ollama sieht eine Kontextlänge von 2048 Token vor. Diese haben wir für \textit{Llama-3-70B} auf die maximal mögliche Kontextlänge von 8192 erhöht, basierend auf den Modell-Ablationen der Autoren: \enquote{[...] we can utilize
+an open-source LLM with a small context window size, specifically Llama-3 with only 8K token} \cite[Anhang D.2]{Talaei2024}
+Die Kontextlänge des \textit{NL2SQL\_DeepSeek\_33B} Modells haben wir auf die im Quellcode beschriebene Länge von 8192 Token gesetzt.
+
+Im Quellcode der vorhandenen Konfigurationen der Autoren wurden die Temperaturen der Modelle vorgegeben -- für den LLM Aufruf von \textit{extract\_keywords} der Wert $0.2$ und für den LLM Aufruf von \textit{generate\_candidate} der Wert $0.01.$ Die übrigen Temperaturen sind auf den Standardwert $0.0$ gesetzt.
+
+Als Datentyp für \textit{NL2SQL\_DeepSeek\_33B} haben wir das im Quellcode gegebene \textit{bfloat16} genutzt \cite{ChessRepo2024}. Sonstige Hyperparameter haben wir auf den Standardwerten von \textit{Ollama} und \textit{vLLM} belassen, sofern diese nicht ebenfalls durch den Quellcode der Autoren beeinflusst werden.
+
+% TODO
+% - N-Gramms erwähnen
+% - Temperaturen
+% --> eventuell 2-3 Sätze ergänzen
+
+\subsection{Implementierung}
+%\minisec{Implementation}
+% \enquote{Beschreiben sie, ob sie vorhandenen Code oder eigenen Code genutzt haben Stellen sie Links zum Code bereit und beschreiben sie welche Programmiersprachen und Pakete genutzt wurden.}
+Das von den Autoren bereitgestellte GitHub-Repository \cite{ChessRepo2024} wurde für diese Replikation in ein eigenes Repository\footnote{GitLab-Repository: \url{https://gitlab.informatik.uni-halle.de/aktxt/re-chess}} übernommen. Für die lokale Ausführung der Embedding-Modelle und \linebreak\textit{Llama-3-70B} nutzen wir das Framework \textit{Ollama} in der aktuell verfügbaren Version und für \textit{NL2SQL\_DeepSeek\_33B} die Bibliothek \textit{vLLM} in der von den Autoren vorgeschlagenen und mit den übrigen Python-Paketen kompatiblen Version 0.3.3. Dazu mussten wir \textit{LangChain} um das Plugin für \textit{Ollama} ergänzen, wie es in \autoref{lst:embedding} dargestellt ist.
+
+\input{assets/embedding}
+
+Neben den Konfigurationen der Framework-Varianten haben wir zusätzlich einige Stellen im Quellcode anpassen müssen, ohne die unsere Experimente nicht mit dem Code der Autoren durchführbar wären.
+
+Für unsere Experimente mit dem revise-Tool mussten wir dieses konfigurierbar machen, da in der aktuellen Version der Autoren der \texttt{sampling\_count} auf eins festgesetzt ist und die generierte Anfrage stets durch die Überarbeitete ersetzt wird. Unsere Änderungen sind in \autoref{lst:revise} farblich hervorgehoben. Neben der Einführung des Parameters \texttt{sampling\_count}, mussten wir von den generierten Revisionen eine finale Anfrage auswählen. Dazu haben wir die bereits vorhandene Methode \texttt{aggregate\_sqls()} genutzt, welche die Revisionen in ein Cluster einfügt und von dem größtem Cluster die kürzeste Anfrage auswählt. Dieses Verfahren kam in einer älteren Version des CHESS-Frameworks zum Einsatz.
+
+\input{assets/implRevise}
+
+Eine weitere Änderung betrifft die Schnittstelle zum Laden der Datensätze der verschiedenen Benchmarks. Hier wird explizit ein \texttt{evidence} Parameter angefordert. Dieser wird aber nur im BIRD-Datensatz genutzt. Für unsere Tests mit dem Spider-Datensatz mussten wir diesem Parameter optional machen. Außerdem wird nun das \textit{Retrieve\_Context} Tool des IR nicht mehr benötigt. Die Änderungen sind in \autoref{lst:evidence} dargestellt.
+
+\input{assets/evidence}
+
+Schließlich haben wir aus den geschlossenen Issues des original Repository erfahren, dass es einer Änderung am GC Agenten benötigt, damit dieser das reduzierte Datenbank Schema nutzt und nicht auf das Ursprüngliche zurück greift. Andernfalls wären die Berechnungen des Information Retrievers und Schema Selectors nutzlos. Die Änderungen in \autoref{lst:tentative} sind gering, haben aber einen enormen Einfluss auf die \textit{Execution accuracy}. Erste Testläufe ohne diesen Parameter erreichten eine \textit{Execution accuracy} von ungefähr $EX=30$. Diese fehlerhaften Testläufe haben wir verworfen und nur jene mit gesetztem Parameter in diese Arbeit übernommen.
+
+\input{assets/tentative}
+
+% TODO - E: repo aufräumen, verlinken
+% Notiz: https://www.acm.org/publications/policies/artifact-review-and-badging-current ACM badges für die Zukunft
+
+\subsection{Aufbau der Experimente}
+%\minisec{Experimental setup}
+%\enquote{Erklären sie, wie sie ihre Experimente durchgeführt haben. Was für Ressourcen haben sie verwendet, z.B. GPU/CPU-Ressourcen. Verlinken sie ihren Code und Notebooks. }
+Die Experimente führen wir mit der $CHESS_{(IR,SS,CG)}$ Variante durch, welche mithilfe einer yaml-Datei konfiguriert wird. Dort haben wir die zu verwendenden Agenten, deren Tools, sowie die verwendeten LLMs und deren Parameter angegeben. Hier wird unter anderem auch die Anzahl der Kandidaten und Revisionen festgelegt. In allen Experimenten generieren wir nur einen Kandidaten. Zur Überprüfung von \hyperref[txt:beh1bird]{Behauptung 1} und \hyperref[txt:beh3spider]{Behauptung 3} lassen wir wie in \cite{Talaei2024} drei Revisionen durchführen.
+
+Für die verschiedenen Experimente benötigen wir die folgenden Konfigurationen der\linebreak $CHESS_{(IR,SS,CG)}$ Variante, welche in unserem Repository unter \texttt{\$Re-CHESS/CHESS/run/configs} zur Verfügung stehen:
+\begin{itemize}
+ \item \texttt{CHESS\_IR\_SS\_CG\_BIRD\_OSS.yaml} - BIRD-Datensatz mit quelloffenen LLMs
+ \item \texttt{CHESS\_IR\_SS\_CG\_SPIDER\_OSS.yaml} - Spider-Datensatz mit quelloffenen LLMs
+\end{itemize}
+
+Die Durchführung der Experimente erfolgt auf einem GPU-Server, welcher in zwei verschiedene Knoten unterteilt ist. Für die Ausführung von \textit{Ollama} und \textit{vLLM} wurde jeweils eine NVIDIA A100-SMX4-80GB Grafikkarte auf einem der Knoten reserviert. Dieser Knoten des GPU-Servers hat weiterhin zwei AMD Epyc 7662 Prozessoren mit je 64 physischen und 128 logischen Kernen, Grundtaktfrequenz von 2 GHz und Boostfrequenz von 3.3 GHz sowie 1024 GB Arbeitsspeicher. Davon haben wir 12 Kerne und 128 GB in unserer Job-Konfiguration mit Slurm reserviert. Der Knoten ist an ein Netzwerklaufwerk für das Cluster mit 1.8 TB Speicherplatz angebunden. Dieses Setup wurde für alle Experimente dieser Replikation verwendet.
+
+Die Durchführung steuern wir mithilfe selbst geschriebener Skripte, welche unter\linebreak \texttt{\$Re-CHESS/scripts} ebenfalls zur Verfügung stehen. Dabei stellt \texttt{copyrepo.sh} den Einstiegspunkt für einen Durchlauf dar. Dieses Skript downloaded und entpackt sowohl \textit{Ollama}, als auch die verwendeten Datensätze. Anschließend wird das \texttt{runchess.sh} Skript aufgerufen, welches zunächst die Vorverarbeitung und im Anschluss die angegebene Konfiguration startet.
+
+% TODO - E: Ollama, vLLM für finetuned, je eine, embed noch mit reingequetscht bei Ollama
+% F: Ich weiß nicht genau was ich davon hier noch schreiben soll, dass wir diese verwenden wird in
+% 3.4 schon geschrieben. Hier müsstest du evtl. noch mal ergänzen wenn dir da noch was fehlt.
+% F: Ich habe versucht die wesentliche Funktion der Skripte wiederzugeben. Wenn ich etwas wichtiges vergessen habe
+% müsstest du das noch ergänzen.
+
+\subsection{Ressourcen für Berechnungen}
+%\minisec{Computational requirements}
+Das verwendete Modell \textit{Llama-3-70B} benötigt mit der genutzten Kontextlänge von 8192 Token etwa 40 GB Grafikspeicher, während \textit{NL2SQL\_DeepSeek\_33B} etwa 70 GB benötigt. Die Embedding-Modelle werden von \textit{Ollama} gleichzeitig im Grafikspeicher gehalten, damit das Laden und Entladen die Ausführung nicht beeinflusst. Mit einer Größe von ca. 300 MB ist dies für \textit{nomic-embed-text} kein Problem, das Embedding Modell aus der Vorberechnung \textit{mxbai-embed-large} benötigt ebenfalls nur etwa 600 MB. Die Verwendung einer kleineren Grafikkarte für \textit{Llama-3-70B} ist mit \textit{Ollama} möglich, jedoch sind kleinere Grafikkarten nicht auf demselben Knoten des Clusters verfügbar. Daher haben wir uns dafür entschieden, den Kommunikationsoverhead zu reduzieren und die zwei Grafikkarten mit 80GB auf demselben Knoten zu nutzen.
+
+Im Vorfeld der Experimente haben wir damit gerechnet, dass die Laufzeit pro Durchlauf wenige Stunden beträgt, da wir kein \textit{fine tuning} betreiben und auch kein aufwendiges Training durchführen. Jedoch stellten wir fest, dass die Kommunikation zwischen den verschiedenen LLMs und der Einsatz der vielen verschiedenen Agenten zu einer deutlich höheren Laufzeit führen, als ursprünglich von uns angenommen. Für die benötigten CPU/GPU-Stunden bei den verschiedenen Experimenten ergeben sich die folgenden Werte:
+
+\textbf{Experiment zu \hyperref[txt:beh1bird]{Behauptung 1}:}
+% 18:26:42 Laufzeit komplett
+% 9 Tage 05:20:24 Laufzeit auf den CPU's
+% 1 Kandidat u. 3 Rev.
+Bei diesem Experiment wird, wie zuvor beschrieben, der SDS-Datensatz genutzt. Dabei wird pro Anfrage immer ein Kandidat generiert und sollte dieser nicht korrekt sein, drei Revisionen durchgeführt. Die totale Laufzeit betrug hier 18:26:42. Die akkumulierte Laufzeit über alle CPUs betrug bei diesem Experiment 9 Tage 05:20:24. Damit lag die für dieses Experiment benötigte Laufzeit deutlich über der im Vorfeld erwarteten Laufzeit.
+
+\textbf{Experiment zu \hyperref[txt:beh2revision]{Behauptung 2}:}
+% 18:19:26 Laufzeit komplett
+% 9 Tage 03:53:12 Laufzeit auf den CPU's
+% 1 Kandidat u. 1 Rev.
+% 18:22:14 Laufzeit komplett
+% 9 Tage 04:26:48 Laufzeit auf den CPU's
+% 1 Kandidat u. 0 Rev.
+Auch bei den Experimenten zu \hyperref[txt:beh2revision]{Behauptung 2} hatten wir eine große Abweichung zu der erwarteten Zeit. Das Reduzieren der Revisionen brachte keine große Zeitersparnisse. Für das Experiment mit \texttt{sampling\_count = 1} wurden eine Laufzeit von 18:19:26 benötigt. Akkumuliert über alle CPUs beträgt die Laufzeit 9 Tage 03:53:12. Dies ist etwas weniger als zuvor bei Experiment 1, jedoch immer noch deutlich über der von uns erwarteten Laufzeit. Werden keine Revisionen generiert, steigt die Laufzeit sogar wieder leicht an auf 18:22:14, was einer akkumulierten Laufzeit von 9 Tagen 04:26:48 entspricht.
+
+\textbf{Experiment zu \hyperref[txt:beh3spider]{Behauptung 3}:}
+% 09:03:21 Laufzeit komplett
+% 4 Tage 12:40:12 Laufzeit auf den CPU's
+% STS, mxbai, nomic: 1 Kandidat u. 3 Rev.
+% 09:47:04 Laufzeit komplett
+% 4 Tage 21:24:48 Laufzeit auf den CPU's
+% STS, Llama3-70B: 1 Kandidat u. 3 Rev.
+Die Experimente von \hyperref[txt:beh3spider]{Behauptung 3} haben wir zunächst auf dem Subsampled Spider Datensatz durchgeführt, welcher nochmal kleiner als der SDS-Datensatz ist. Deshalb rechneten wir auch mit einer deutlich geringeren Laufzeit als zuvor. Der Ausgang der Experimente bestätigte diese Annahme. Bei einem generierten Kandidaten und drei Revisionen, zusammen mit \textit{Llama-3-70B} als Embedding-Modell, wurde eine Laufzeit von 09:47:04 benötigt, was einer akkumulierten Laufzeit von 4 Tagen 21:24:48 entspricht. Verwendet man die Embedding-Modelle \textit{mxbai-embed-large} und \textit{nomic-embed-text} beträgt die Laufzeit 09:03:21, was einer akkumulierten Laufzeit von 4 Tagen 21:24:48 entspricht.
+
+% ? Laufzeit komplett
+% ? Laufzeit auf den CPU's
+% SPIDER, Llama3-70B: 1 Kandidat u. 3 Rev.
+Bei den Tests auf dem vollständigen Spider-Datensatz war zu erwarten, dass die Laufzeit bedeutend höher ist, als zuvor. \textbf{\{...Hier muss dann noch die Laufzeit für den Spider Datensatz hin\}}
+
+
+% TODO: Überarbeiten der Abschätzungen von benötigtem Speicher und Laufzeit vor den Experimenten
+% (Haben wir das überhaupt gemacht? Ich weiß leider nicht ganz was ich das schreiben soll.
+% zumindest bei der Laufzeit habe ich es aber mal versucht) ~ Felix
+
+
+%\enquote{Beschreiben sie die Anforderungen für die Berechnungen für jedes ihrer Experimente, z.B. die Anzahl der CPU/GPU-Stunden oder die Voraussetzungen für den Hauptspeicher und GPU-Speicher. Geben sie für Zeit und Speicher eigene Abschätzungen an, bevor die Experimente gelaufen sind und vergleichen sie diese mit den tatsächlich verbrauchten Ressourcen. Sie müssen vor den Experimenten einplanen, dass diese Informationen auch durch ihren Code gemessen und gespeichert werden.}
\ No newline at end of file
diff --git a/report/content/04Ergebnisse.tex b/report/content/04Ergebnisse.tex
new file mode 100644
index 0000000000000000000000000000000000000000..7b43f16fb34dad4e3c450b81f1700f42c7fa32ae
--- /dev/null
+++ b/report/content/04Ergebnisse.tex
@@ -0,0 +1,86 @@
+\section{Ergebnisse}
+\label{sec:ergebnisse}
+In diesem Abschnitt beschreiben wir die Ergebnisse unserer experimentellen Untersuchungen. Diese überprüfen die in \autoref{sec:Scope} aufgestellten Behauptungen über den replizierten Artikel.
+
+%\enquote{Starten sie mit einem Überblick über die Ergebnisse. Bestätigen ihre Ergebnisse die aufgeführten Behauptungen? Dieser Abschnitt sollte hauptsächlich Fakten nennen und so präzise wie möglich geschrieben werden.}
+Unsere erste Untersuchung repliziert ein Experiment aus \cite{Talaei2024}, bei dem das CHESS-Framework auf dem BIRD-Datensatz mit quelloffenen LLMs getestet wurde. Wir nutzen dabei die gleiche $CHESS_{(IR,SS,CG)}$ Variante. Während in \cite{Talaei2024} eine \textit{Execution Accuracy} von $EX=61.5$ erreicht wurde, können wir nur einen Wert von $EX=54.42$ erreichen. Folglich kann mit diesem Experiment die \hyperref[txt:beh1bird]{Behauptung 1} nicht bestätigt werden.
+
+\begin{table}[!tb]
+ \centering
+ \begin{tabular}{c|c}
+ \texttt{sampling\_count} & $EX_{SDS}$\\
+ \hline
+ 0 & 53.74\\
+ 1 & 54.42\\
+ \end{tabular}
+ \caption{\textit{Execution Accuracy} für unterschiedliche Werte des $sampling\_count$ im revise-Tools}
+ \label{tab:resExp2}
+\end{table}
+
+Mit dem zweiten Experiment wurde der Einfluss des revise-Tools untersucht. Dafür wurde das CHESS-Framework in der Konfiguration $CHESS_{(IR,SS,CG)}$ mit quelloffenen LLMs auf dem SDS-Datensatz getestet, wobei das revise-Tool mit $sampling\_count \in \{0,1\}$ konfiguriert wurde. Die Ergebnisse sind in \autoref{tab:resExp2} aufgelistet. Die absoluten Werte der $EX$ weichen, wie auch schon im ersten Experiment, von denen aus \cite{Talaei2024} ab. Tatsächlich können wir aber auch einen Anstieg der \textit{Execution Accuracy} bei Verwendung des revise-Tools feststellen. Jedoch ist der Einfluss des Tools mit einer Änderung von $\Delta EX = 0.68$ nicht signifikant, weshalb wir \hyperref[txt:beh2revision]{Behauptung 2} ebenfalls nicht bestätigen können.
+
+Das dritte Experiment liefert einen Wert für die \textit{Execution Accuracy} des CHESS-Frameworks mit quelloffenen LLMs auf dem Spider-Datensatz. Da die ersten Experimente bereits eine deutlich höhere Laufzeit hatten, als zuvor erwartet, haben wir zunächst nur den Subsampled Spider Datensatz genutzt und zusätzlich zu den von uns gewählten Embedding-Modellen, auch \textit{Llama-3-70B} als Embedding-Modell getestet. Die Ergebnisse auf dem Subsampled Spider Datensatz mit den verschiedenen Embedding-Modellen sind in \autoref{tab:sts} aufgeführt. Im weitere Verlauf konnten wir dann aber auch den vollständigen Spider-Datensatz testen und einen Wert von $EX=???$ ermitteln. Die Differenz zu der \textit{Execution Accuracy} von $CHESS_{(IR,SS,CG)}$ mit proprietären LLMs auf dem Spider-Datensatz beträgt $\Delta EX = 87.2 - ??? = ???$. Diese Abweichung ist deutlich größer, als von uns erwartet. Mit diesem Ergebnis liefern wir aber einen Wert für \autoref{tab:performance2}, bei dem $CHESS_{(IR,SS,CG)}$ mit quelloffenen LLMs auf dem Spider-Datensatz getestet wurde.
+
+\begin{table}[!tb]
+ \centering
+ \begin{tabular}{c|c}
+ Embedding-Modelle & $EX_{SubSpider}$ \\
+ \hline
+ LLama-3-70B & 62.88\\
+ mxbai-embed-large \& nomic-embed-text & 60.70\\
+ \end{tabular}
+ \caption{\textit{Execution Accuracy} mit unterschiedlichen Embedding-Modellen auf dem Subsampled Spider Datensatz}
+ \label{tab:sts}
+\end{table}
+
+\begin{table}[!tb]
+ \centering
+ \begin{tabular}{l|c|c|c}
+ % width must be set manually bc this cell is not the biggest cell
+ \diagbox[width=16em,trim=l]{Methode}{Datensätze} & BIRD test & BIRD dev & \textbf{Spider}\\
+ \hline
+ Beste Methode (Stand 03/2025) & 77.14 \cite{bird} & 75.36 \cite{bird} & 91.2 \cite{spider1} \\
+ \hline
+ $CHESS_{(IR,CG,UT)}$ & 68.31 & 71.10 & -\\
+ $CHESS_{(IR,SS,CG)}$ + proprietär & 66.69 & 65.00 & 87.2 \\
+ \textbf{$CHESS_{(IR,SS,CG)}$ + Open LLMs} & - & 61.5 & \textbf{???}\\
+ \hline
+ $\Delta EX$ = $EX_{\text{proprietär}}$ - $EX_{\text{OpenLLM}}$ & - & 3.5 & \textbf{???} \\
+ \end{tabular}
+ \caption{Überblick verschiedener CHESS-Konfigurationen auf unterschiedlichen Benchmarks}
+ \label{tab:performance2}
+\end{table}
+
+%\enquote{Beschreiben sie dann detailliert jedes einzelne Ergebnis, das sie haben. Zeigen sie wie es mit einer oder mehreren Behauptungen in Beziehung steht. Erklären sie konkret was der Kern ihres Ergebnis ist. Gruppieren sie die Ergebnisse in logische Abschnitte. Beschreiben sie klar, wo sie über den Originalartikel hinausgegangen sind, wo sie zusätzliche Experimente durchgeführt haben und wie diese mit den ursprünglichen Behauptungen in Beziehung stehen.} Oft kann man nicht die exakt gleiche numerische Zahl als Ergebnis bekommen. Deshalb müssen sie das Ergebnis bewerten, um zu entscheiden, ob ihr Ergebnis die Behauptung der Originalartikels unterstützt.
+
+Die Ergebnisse unserer Experimente zeigen, dass keine unserer formulierten Behauptungen zutrifft. Jedoch sehen wir verschiedene Hinweise, die für die geringere \textit{Execution Accuracy} verantwortlich sein können. Daher werden wir im Folgenden näher auf die Ergebnisse der Experimente eingehen.
+
+%\textbf{Behauptung 1:}
+%\textit{Das CHESS-Framework in der Konfiguration $CHESS_{(IR,SS,CG)}$ erzielt mit quelloffenen LLMs eine $EX$ auf dem SDS-Datensatz von annähernd $EX=61.5$.} \label{txt:beh1bird}
+\paragraph{Ergebnisse zu Behauptung 1} Das erste Experiment sollte die allgemeine Leistungsfähigkeit des CHESS-Frameworks zum Bearbeiten von Text-To-SQL-Aufgaben bestätigen. Dazu wurde ein Experiment aus \cite{Talaei2024} replizierten, bei dem die $CHESS_{(IR,SS,CG)}$ Variante mit quelloffenen LLMs getestet wurde. In \cite{Talaei2024} wurde mit dieser Variante auf dem vollständigen BIRD-dev Datensatz ein Wert von $EX=61.5$ erreicht. Mit \hyperref[txt:beh1bird]{Behauptung 1} sollte dieser Wert für den SDS-Datensatz, einer Teilmenge des BIRD-dev Datensatzes, bestätigt werden. Jedoch konnten wir nur einen Wert von $EX=54.42$ erreichen. Die Abweichung führen wir auf die genutzten Embedding-Modellen zurück. Diese werden in der Arbeit für die Experimente mit quelloffenen LLMs nicht genauer benannt. Im Quelltext werden für die Embedding-Modelle nur proprietäre LLMs genutzt. Mit \textit{mxbai-embed-large} und \textit{nomic-embed-text} haben wir versucht ähnliche Modelle zu wählen. Nichtsdestotrotz könnten diese aber für die geringere \textit{Execution Accuracy} verantwortlich sein.
+
+%\textbf{Behauptung 2:}
+%\textit{Das CHESS-Framework in der Konfiguration $CHESS_{(IR,SS,CG)}$ mit quelloffenen LLMs wird durch das revise-Tool signifikant beeinflusst und erzielt auf dem SDS-Datensatz eine Differenz in der Execution Accuracy ($\Delta EX$) zwischen einmalige Revision und keiner Revision von annähernd $\Delta EX = 61.22 - 57.82 = 3.40$.}
+\paragraph{Ergebnisse zu Behauptung 2} In \cite{Talaei2024} wird dem revise-Tool des CG-Agenten ein signifikanter Einfluss auf die \textit{Execution Accuracy} zugeschrieben. In diesem Experiment wurde der Einfluss dieses Tools genauer untersucht. Die Ergebnisse sind in \autoref{tab:resExp2} aufgelistet. Aus den ermittelten Werten kann geschlussfolgert werden, dass der Einsatz des revise-Tools zu einer höheren \textit{Execution Accuracy} führt. Jedoch konnten nicht der gleiche signifikante Einfluss feststellen werden, wie in \cite{Talaei2024}. Auch hier sehen wir den Einfluss der Embedding-Modelle als mögliche Fehlerquelle.
+
+Eine weitere interessante Beobachtung bei diesem Experiment ist die Verteilung der korrekten, inkorrekten und fehlerhaften SQL-Anfragen, wie sie in \autoref{tab:scPortion} dargestellt sind. Anhand der absoluten Werte kann festgestellt werden, dass nur eine inkorrekte Anfrage in eine korrekte Anfrage umgewandelt werden konnte und die anderen zu fehlerhafter Anfragen umgewandelt wurden. Das zeigt, dass der Einfluss des revise-Tools wirklich nicht signifikant ist. Andererseits bedeutet das Ergebnis auch, dass durch die Revision neue Syntaxfehler entstehen. Eine Erklärung dieses Phänomens sehen wir in der Auswahl der finalen Anfrage, bei der stets die kürzeste Anfrage ausgewählt wird. Dieses Verfahren erscheint bei komplexen Datenbank-Anfragen nicht besonders erfolgversprechend zu sein. Da bei den Ablation-Studies in \cite{Talaei2024} aber das gleiche Verfahren verwendet wurde, haben wir hier keine Änderungen vorgenommen.
+
+\begin{table}[tb]
+ \centering
+ \begin{tabular}{c|c|c}
+ & $sc=0$ & $sc=1$ \\
+ \hline
+ correct & 79 & 80\\
+ incorrect & 65 & 56\\
+ error & 3 & 11\\
+ \end{tabular}
+ \caption{Anteil der korrekten, inkorrekten und fehlerhaften SQL-Anfragen}
+ \label{tab:scPortion}
+\end{table}
+
+%\textbf{Behauptung 3:}
+%\textit{Das CHESS-Framework in der Konfiguration $CHESS_{(IR,SS,CG)}$ erzielt mit quelloffenen LLMs eine Differenz in der Execution Accuracy ($\Delta EX$) zwischen dem BIRD-dev und Spider-Datensatz von annähernd $\Delta EX = 65.00 - 61.5 = 3.50$, wie mit proprietären Modellen.}
+\paragraph{Ergebnisse zu Behauptung 3} Zusätzlich zu den in \cite{Talaei2024} durchgeführten Experimenten wurde das CHESS-Framework auf dem Spider-Datensatz getestet. Für die $CHESS_{(IR,SS,CG)}$ Variante gibt es bereits einen Wert für proprietär LLMs. Mit diesem Experiment wird zusätzlich einen Wert für quelloffene LLMs bereitgestellt. Aufgrund von Ressourcenbeschränkungen und Rücksicht auf andere Nutzer des GPU-Servers haben wir zunächst nicht den kompletten Spider-Datensatz getestet, da wir andernfalls den GPU-Server für mehrere Tage blockieren würden. Zudem haben wir aufgrund der Ergebnisse von Experiment 1 und 2 die genutzten Embedding-Modelle hinterfragt und zusätzliche \textit{Llama-3-70B} als Embedding-Modell getestet. Die Ergebnisse in \autoref{tab:sts} zeigen, dass mit \textit{Llama-3-70B} ein leicht höherer $EX$ Wert erreicht werden konnte. Abseits der Arbeit durchgeführte Tests mit \textit{Llama-3-70B} als Embedding-Modell für Experimente auf dem BIRD-Datensatz haben aber keine Verbesserungen ergeben.
+
+Später konnte dann aber doch der vollständige Spider-Datensatz getestet werden, wobei eine \textit{Execution Accuracy} von $???$ erreicht werden konnte. Die Differenz zu der \textit{Execution Accuracy} von $CHESS_{(IR,SS,CG)}$ mit proprietären LLMs auf dem Spider-Datensatz beträgt $\Delta EX = 87.2 - ??? = ???$. Diese Abweichung ist deutlich größer, als von uns erwartet. Mit den vorangegangenen Tests auf dem Subsampled Spider Datensatz mit unterschiedlichen Embedding-Modellen können wir sicher behaupten, dass die Wahl der Embedding-Modelle einen großen Einfluss auf die ermittelte \textit{Execution Accuracy} hat. Wir gehen davon aus, dass mit einem anderen Embedding-Modell auch noch bessere $EX$ Werte möglich sind.
+%\enquote{Beschreiben sie alle zusätzlichen Experimente, die über den Originalartikel hinausgehen. Dies können Experimente zu weiteren Datenmengen sein oder sie probieren andere Methoden bzw. weitere Vereinfachungen des Modells aus oder passen die Hyperparameter an. Beschreiben sie für jedes zusätzliche Experiment, was sie genau durchgeführt haben, was die Ergebnisse sind und diskutieren sie was diese Ergebnisse zeigen. }
\ No newline at end of file
diff --git a/report/content/05Diskussion.tex b/report/content/05Diskussion.tex
new file mode 100644
index 0000000000000000000000000000000000000000..f27722bebfad9a508b950e783cbe8281d6f52dec
--- /dev/null
+++ b/report/content/05Diskussion.tex
@@ -0,0 +1,44 @@
+\section{Diskussion}
+\label{sec:diskussion}
+%\enquote{Beschreiben sie die weiterführenden Implikationen der experimentellen Ergebnisse. War der Originalartikel replizierbar bzw. reproduzierbar. Falls nicht, welche Faktoren haben dazu geführt, dass die Experimente nicht reproduziert werden konnten. }
+Aus unseren experimentellen Untersuchungen können wir eine Reihe von Schlussfolgerungen über den in \cite{Talaei2024} präsentierten Text-To-SQL-Ansatz im Allgemeinen und die Replizierbarkeit dessen im Speziellen ziehen.
+
+Zunächst möchten wir festhalten, dass der Artikel mit Einschränkungen replizierbar ist. Einerseits werden in dem Artikel ausführliche Erklärungen über die Funktionsweise des Frameworks und den Ablauf der Experimente gegeben. Außerdem ist das Repository gut strukturiert, der Code kommentiert und aussagekräftige Bezeichner verwendet. Andererseits mussten wir aber feststellen, das wichtige Informationen und Parameter zur Replikation der Experimente fehlen und das revise-Tool anders implementiert wurde, als im Artikel beschrieben. Einen Grund für die geringeren $EX$ Werte sehen wir in der Wahl der Embedding-Modelle, welche in \cite{Talaei2024} nicht beschrieben werden. Dies erschwert die Replikation des Artikels deutlich.
+
+%\enquote{Bewerten sie, ob sie die Evidenz, die sie durch das Durchführen der Experimente erhalten haben, auch überzeugt, dass die Behauptungen des Originalartikels dadurch gestützt werden. Diskutieren sie die Stärken und Schwächen ihres Ansatzes, vielleicht haben sie aus Zeitgründen nicht alle Experimente durchführen können, oder vielleicht haben zusätzliche Experimente durchgeführt, die den Originalartikel weiter stärken.}
+
+Mithilfe unserer Experimente können wir jedoch die Behauptungen in \cite{Talaei2024} größtenteils stützen. Bessere Replikationen wären durch eine ausführlichere Dokumentation der Experimente möglich. In \cite{Talaei2024} wird nicht darauf eingegangen, wie die einzelnen Ergebnisse ermittelt werden. Zudem stehen nur für ein Experiment die Rohdaten zur Verfügung. Wichtige Informationen wie zum Beispiel die genutzten Embedding-Modelle müssen geraten werden.
+
+Aufgrund der deutlich geringeren $EX$ Werte unserer Experimente stellen wir die hervorgehobene Adaptivität des Frameworks an ressourcenbeschränkte Umgebungen in Frage. Jedes unserer Experimente zeigt einen qualitativen Unterschied zwischen quelloffenen Modellen und den leistungsstarken proprietären Modellen aus \cite{Talaei2024}. Daher können wir nicht bestätigen, dass das Framework mit limitierten Ressourcen die gleichen Ergebnisse erzielen kann.
+
+\subsection{Was war einfach?}
+%\enquote{Beschreiben sie welche Teile der Replikation/Reproduktion sich leicht umsetzen ließen. Lief der Code der Autoren problemlos? War es aufgrund der Beschreibung im Originalartikel nicht aufwändig die Methoden zu reimplementieren? Dieser Abschnitt soll den Lesenden zeigen, welche Teile des Originalartikels sich leicht für eigene Ansätze verwenden lässt. Tipp: Keine pauschalen Verallgemeinerungen. Kontext und Erklärungen angeben}
+
+Zu Beginn unserer Arbeit mussten wir zunächst den Artikel erfassen, dessen Kernaussage ermitteln und die Experimente nachvollziehen. All dies war durch die ausführlichen Erklärungen und den übersichtlichen Code gewährleistet. Die Beschreibung der Experimente ermöglichte einen schnellen Überblick über dessen Schwerpunkt und Ergebnisse.
+
+Bis auf wenige Ausnahmen stellen die Autoren alle nötigen Informationen bereit, um eine Reproduktion der Experimente durchzuführen. Alle genutzten Datensätze sind online verfügbar, oder werden bereitgestellt, wie es bei dem SDS-Datensatz der Fall ist. Eine Setup-Anleitung wird mitgeliefert und der Code ist ausführbar. Die verwendeten Konfigurationen sind ebenfalls im Repository enthalten.
+
+Da wir in unseren Experimenten andere Modelle genutzt haben, mussten wir die Konfigurationen anpassen. Die entsprechende Schnittstelle ist gut dokumentiert, sodass wir die LLMs schnell einbinden und die Parameter setzen konnten.
+
+\subsection{Was war schwer?}
+%\enquote{Beschreiben sie welche Teile ihrer Replikation/Reproduktion aufwändig oder schwierig waren oder viel mehr Zeit in Anspruch genommen haben, als sie erwarteten. Vielleicht waren Daten nicht verfügbar, so dass sie einige Experimente nicht verifizieren konnten, oder der Code der Autoren funktionierte nicht und musste erst debugged werden. Vielleicht dauerten auch einige Experimente zu lange und sie konnten sie deshalb nicht verifizieren. Dieser Abschnitt soll den Lesenden zeigen, welche Teile des Originalartikels schwer wiederverwendbar sind, bzw. signifikante Zusatzarbeiten und Ressourcen erfordern.}
+
+Die Experimente in \cite{Talaei2024} wurden bis auf eine Ausnahme ausschließlich auf proprietären LLMs durchgeführt. Für die Reproduktion dieser Arbeit werden also in jedem Fall leistungsstarke LLMs und monetäre Ressourcen benötigt. Dies schränkt die Reproduzierbarkeit im akademischem Umfeld sehr stark ein und hat auch unsere Arbeit nachteilig beeinflusst. Zudem werden nur die Experimente mit proprietären LLMs detailliert beschrieben. Für unsere Replikation mit quelloffenen LLMs fehlten uns wichtige Informationen und Parameter, welche wir deshalb raten mussten. Konkrete Fragen haben sich zu den genutzten Embedding-Modellen ergeben, welche nicht weiter benannt werden. Im Repository konnten wir nur proprietäre Embedding-Modelle finden. Daher stellt sich für uns die Frage, welches leistungsstärkere Embedding-Modell in \cite{Talaei2024} für das Experiment mit den quelloffenen LLMs genutzt wurde, da die Ergebnisse mit unserer Wahl deutlich schlechter ausgefallen sind.
+
+Bei der genaueren Untersuchung des revise-Tools haben wir gravierende Unterschiede zwischen der Beschreibung des Tools in \cite{Talaei2024} und der Implementierung im Repository entdeckt. Während in dem Artikel beschrieben wird, dass \textit{\enquote{For each faulty candidate, the agent repeatedly attempts to revise the query, until the issue is resolved or a maximum number of allowed revisions is reached.}} \cite{Talaei2024}, stellten wir fest, dass die Implementierung eine parallele Revision, statt einer Wiederholten durchführt. Wir sehen die Autoren in der Pflicht diese Inkonsistenz zu beheben und gegebenenfalls die Experimente neu durchzuführen, da dieses Tools einen signifikanten Einfluss auf die \textit{Execution Accuracy} hat. Zudem ist die Anzahl der durchgeführten Revisionen nicht konfigurierbar, obwohl sie es laut \cite{Talaei2024} sein sollte. Dies führte dazu, dass wir zur Überprüfung von \hyperref[txt:beh2revision]{Behauptung 2} zunächst die Implementierung entsprechend erweitern mussten.
+
+Bei der Untersuchung von \hyperref[txt:beh3spider]{Behauptung 3} haben wir den Spider-Datensatz verwendet, welcher für Experimente in \cite{Talaei2024} bereits genutzt wurde. Jedoch mussten wir auch hier wieder feststellen, dass dieser nicht ad-hoc verwendet werden kann, da Spider eine andere Schnittstelle als die BIRD-Datensätzen nutzt und die passende Implementierung im Code nicht enthalten ist. Die entsprechenden Anpassungen im Code sind zwar trivial, aber gerade aus diesem Grund sehen wir hier die Autoren in der Pflicht, die Implementierung der Schnittstelle so zu gestalten, dass auch andere Datensätze, wie zum Beispiel die neue Version des Spider-Datensatz \cite{spider2}, nutzbar sind.
+
+% Ich sehe irgendwie immer noch kein Problem bei den Namen
+% Candidate Generator = der Agent
+% Generate_candidate_query = dem Tool
+% Es wird doch gut getrennt zwischen den beiden Werkzeugen ...
+% -Stephan
+
+% Während die meisten Bezeichner klar formuliert wurden, sind wir in der Diskussion mehrfach über die Bezeichnung des Agenten Candidate Generator und des Tools generate\_candidate gestolpert.
+
+\subsection{Empfehlungen für die Replizierbarkeit / Reproduzierbarkeit}
+%\enquote{Geben sie Empfehlungen, wie die Autoren des Originalartikels oder andere Forschende in diesem Feld die Replizierbarkeit / Reproduzierbarkeit verbessern können.}
+Replikationen werden typischerweise im akademischem Umfeld erstellt, in dem häufig nur limitierte Ressourcen zur Verfügung stehen. Zudem können proprietäre Modelle aufgrund von Lizenzrechten nur selten verwendet werden. In \cite{Talaei2024} wird zwar die Adaptivität an ressourcenbeschränkte Umgebungen hervorgehoben und auch ein Experiment mit quelloffenen LLMs durchgeführt, jedoch hat unsere Replikation gezeigt, dass es trotzdem qualitative Unterschiede gibt. Aus diesem Grund sollten Experimente auch mit schwächeren LLMs durchführbar sein.
+
+Text-To-SQL Ansätze stehen im ständigen Wettbewerb untereinander und eine gute Performance in anerkannten Benchmarks ist entscheidend für deren Verwendung. Aus diesem Grund sollte die Schnittstelle zum Nutzen der Benchmarks mehr Beachtung finden und für verschiedenste Benchmarks genutzt werden können.
\ No newline at end of file
diff --git a/report/content/06Kommunikation.tex b/report/content/06Kommunikation.tex
new file mode 100644
index 0000000000000000000000000000000000000000..468aa065b4038a9d0750dddb7960031bd19ea59b
--- /dev/null
+++ b/report/content/06Kommunikation.tex
@@ -0,0 +1,14 @@
+\section{Kommunikation mit den Autoren}
+%\minisec{Communication with original authors}
+%\enquote{Dokumentieren sie das Ausmaß (oder das Fehlen) der Kommunikation mit Autoren. Stellen sie sicher, dass der Bericht eine faire Beurteilung der Forschungsarbeiten ist. Versuchen sie deshalb mit den Autoren Kontakt aufzunehmen. Sie können ihnen konkrete Fragen stellen oder falls sie keine Fragen haben, den Bericht zusenden und um Feedback bitten.}
+
+Es gab den Versuch der Kontaktaufnahme mit den Autoren der Originalarbeit, um einen guten Fortschritt, sowie eine hohe Qualität für die Replikation zu erreichen. Dabei wurde versucht, offene Fragen, welche sich weder mithilfe der Originalarbeit noch der dazugehörigen Dokumentation beantworten ließen, zu klären. Die dafür verfasste E-Mail fokussierte sich auf 3 Fragestellungen, welche das Projekt maßgeblich vorangebracht hätten.
+
+Zum Einen ist an keiner Stelle dokumentiert, welche \textit{temperatures} für die LLMs bei den Open-Source-Experimenten verwendet wurden. Es gibt lediglich die in der standardmäßigen Konfiguration angegebenen \textit{temperatures}, an denen man sich orientieren kann. Aus diesem Grund wurden die Autoren gefragt, ob sie für ihre Open-Source-Experimente von dem Standard abweichende \textit{temperatures} verwendet haben. Sollte dies der Fall gewesen sein, haben wir die Autoren der Originalarbeit darum gebeten, uns diese weiterzugeben.
+
+Die zweite Fragestellung bezieht sich auf die in den Open-Source-Experimenten der Originalarbeit verwendeten Embedding-Modelle. Aus \cite{Talaei2024} geht nicht eindeutig hervor, welche Embedding-Modelle für die Experimente der Originalarbeit verwendet wurden. Aus diesem Grund entschieden wir uns dazu, noch einmal nachzufragen, ob tatsächlich \textit{Llama-3-70B} für das Embedding-Modell verwendet wurde, oder doch andere Modelle zum Einsatz kamen.
+
+Des Weiteren gab es bei den Experimenten zu den Ablation-Studies Probleme, das Framework ohne Revisionen zu nutzen. Dies ist für die Experimente zu den Ablation-Studies zwingend notwendig, weshalb wir die Autoren nach ihrer Lösung für dieses Problem befragten. Leider gab es bis zum aktuellen Zeitpunkt zu keiner gestellten Frage keine Rückmeldung, weshalb unserer Lösungen für die beschriebenen Probleme mit dem Vorgehen aus der Originalarbeit abweichen können.
+
+% E-Mail als Anhang?
+% Würde die Mail bei der Abgabe mit anhängen wenn das geht. ~ F
\ No newline at end of file