diff --git a/report/Bericht.tex b/report/Bericht.tex
index 90ed827d029522948874a40069cfc014c97c267b..9d26f22ff9d72e3c06e7dd541b15e5e127a02113 100644
--- a/report/Bericht.tex
+++ b/report/Bericht.tex
@@ -73,9 +73,12 @@
\input{content/06Kommunikation}
\printbibliography
+
+\input{content/07Anhang} % -> falls die Email noch mit im Anhang stehen soll, noch einkommentieren
% 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
+% -> Regex \.\s*\cite findet keine mehr, umgesetzt
+% - von IEEE citestyle & bibstyle zu numeric-comp citestyle & numeric bibstyle wechseln -> umgesetzt
% - Begriffhervorhebungen einheitlich: kursiv oder fett? ggf. Höchstens Überschriften
-% - \paragraph und \minisec sinnvoll einsetzen, nicht zu sehr mischen
+% - \paragraph und \minisec sinnvoll einsetzen, nicht zu sehr mischen -> umgesetzt
\end{document}
diff --git a/report/Bericht_preRelease.pdf b/report/Bericht_preRelease.pdf
deleted file mode 100644
index 9482c05dfc9433efe10d09960eb5586849ce42e0..0000000000000000000000000000000000000000
Binary files a/report/Bericht_preRelease.pdf and /dev/null differ
diff --git a/report/DMML_Bericht_Feist_Hartnick_Mitte.pdf b/report/DMML_Bericht_Feist_Hartnick_Mitte.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..50ea2cc7f30267c668942843c9400197d233fa94
Binary files /dev/null and b/report/DMML_Bericht_Feist_Hartnick_Mitte.pdf differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Black.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Black.ttf
deleted file mode 100644
index 3ff0a7ea51a57970179a16df0a8c254e78304ef9..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Black.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-BlackItalic.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-BlackItalic.ttf
deleted file mode 100644
index bbc0f04bc949ec5bc35fb18279b5820f21eabe5a..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-BlackItalic.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Bold.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Bold.ttf
deleted file mode 100644
index d275b85bd195fa5bce2a5ca598349ad18aff05bc..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Bold.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-BoldItalic.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-BoldItalic.ttf
deleted file mode 100644
index 03ea9656f43c327787a91e66ffa8b67d52fb204d..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-BoldItalic.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraBold.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraBold.ttf
deleted file mode 100644
index 1d2f902741a170045d563203913f86ade1687a5c..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraBold.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraBoldItalic.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraBoldItalic.ttf
deleted file mode 100644
index 12f4d249e1bed56ca5e341cc65a2b6dfe0f10838..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraBoldItalic.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraLight.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraLight.ttf
deleted file mode 100644
index 2de522a79c4e7759e6467a76d50ee648c0424cb8..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraLight.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraLightItalic.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraLightItalic.ttf
deleted file mode 100644
index b65074d7c0bcfec97a065ff6f54d851afcf3a992..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ExtraLightItalic.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Italic.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Italic.ttf
deleted file mode 100644
index 6376ad2bf4a356c80bc6985b2fcee9bde4e44f97..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Italic.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Light.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Light.ttf
deleted file mode 100644
index ceb773776c0c3411901989404e2a3571e0fd035e..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Light.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-LightItalic.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-LightItalic.ttf
deleted file mode 100644
index 9cfb1fcdd134701e8a5e7fa2fb97df5a64eb4b8b..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-LightItalic.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Medium.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Medium.ttf
deleted file mode 100644
index 13643599bde33e4889aac5c31136cc60d4322e89..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Medium.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-MediumItalic.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-MediumItalic.ttf
deleted file mode 100644
index 4c5fb43a69dbdaec5f170100871f547caf1c5464..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-MediumItalic.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Regular.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Regular.ttf
deleted file mode 100644
index eae1d9b40963e90b395a980a2093b9d263004a6c..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Regular.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-SemiBold.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-SemiBold.ttf
deleted file mode 100644
index ac2a0a97b7b1a365155f1055849bcbeebed41452..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-SemiBold.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-SemiBoldItalic.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-SemiBoldItalic.ttf
deleted file mode 100644
index 733973778ef3ed81e7ff6432d71b78a31be02be7..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-SemiBoldItalic.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Thin.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Thin.ttf
deleted file mode 100644
index 184ca80ddeb692b1b42f6608f608283d4307ef9a..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-Thin.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ThinItalic.ttf b/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ThinItalic.ttf
deleted file mode 100644
index 2e936952d780021906429e2a0121b3706050539d..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/epilogueFont/Epilogue-ThinItalic.ttf and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/logos/LogoShapeDarkRotated.png b/report/Vortrag/AICStyleData/logos/LogoShapeDarkRotated.png
deleted file mode 100644
index 4848d8ff2bcbdbd20c22a918e7431e099fa0a3a5..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/logos/LogoShapeDarkRotated.png and /dev/null differ
diff --git a/report/Vortrag/AICStyleData/logos/LogoShapeLightRotated.png b/report/Vortrag/AICStyleData/logos/LogoShapeLightRotated.png
deleted file mode 100644
index 9e2762cde4f4278647da91d8daae1c448f63bc4c..0000000000000000000000000000000000000000
Binary files a/report/Vortrag/AICStyleData/logos/LogoShapeLightRotated.png and /dev/null differ
diff --git a/report/Vortrag/beamercolorthemeModernBeamer.sty b/report/Vortrag/beamercolorthemeModernBeamer.sty
deleted file mode 100644
index c8f19879c4a18de709bfdb3e55c6f7428999d367..0000000000000000000000000000000000000000
--- a/report/Vortrag/beamercolorthemeModernBeamer.sty
+++ /dev/null
@@ -1,34 +0,0 @@
-% define colors
-\definecolor{VeryPaleOrange}{rgb}{1, 0.933, 0.867}
-\definecolor{LightGrayishCyan}{rgb}{0.922, 0.98, 0.976}
-\definecolor{LightGrayishBlue}{rgb}{0.929, 0.914, 1}
-\definecolor{Solitude}{rgb}{0.953, 0.965, 0.976}
-
-\definecolor{mediumturquoise}{rgb}{0.28, 0.82, 0.8}
-\definecolor{NeonCarrot}{rgb}{ 1, 0.49, 0.192}
-\definecolor{NeonBlue}{rgb}{0.455, 0.325, 0.984}
-\definecolor{Astronaut}{rgb}{0.243, 0.318, 0.416}
-
-
-\definecolor{PrussianBlue}{rgb}{0.0, 0.19, 0.33}
-
-% set color usage
-\usecolortheme[named=PrussianBlue]{structure}
-\setbeamercolor{titlelike}{parent=structure}
-\setbeamercolor{}{}
-\setbeamercolor{block title}{bg=NeonBlue}
-\setbeamercolor{block body}{bg=LightGrayishBlue}
-\setbeamercolor{block title example}{bg=Astronaut}
-\setbeamercolor{block body example}{bg=Solitude}
-\setbeamercolor{block title alerted}{bg=NeonCarrot}
-\setbeamercolor{block body alerted}{bg=VeryPaleOrange}
-\setbeamercolor{footlinecolor}{fg=PrussianBlue}
-\setbeamercolor{alerted text}{fg=NeonCarrot}
-\setbeamercolor{background canvas}{bg=Solitude}
-
-
-% for title page and final page
-\setbeamercolor{title}{fg=Solitude}
-\setbeamercolor{subtitle}{fg=Solitude}
-\setbeamercolor{author}{fg=Solitude}
-\setbeamercolor{institute}{fg=Solitude}
\ No newline at end of file
diff --git a/report/Vortrag/beamerfontthemeModernBeamer.sty b/report/Vortrag/beamerfontthemeModernBeamer.sty
deleted file mode 100644
index bcd8f0ed3bdca4f921260515fc25310d78002c94..0000000000000000000000000000000000000000
--- a/report/Vortrag/beamerfontthemeModernBeamer.sty
+++ /dev/null
@@ -1,26 +0,0 @@
-\mode<presentation>
-
-%%%%%%%%%%%% fonts
-
-\setbeamerfont{structure}{family=\sffamily,series=\mdseries}
-
-\setbeamerfont{title}{size=\huge,series=\bfseries,parent=structure}
-\setbeamerfont{subtitle}{size=\normalsize,parent=title}
-
-\setbeamerfont{date}{size=\scriptsize,series=\mdseries,parent=structure}
-\setbeamerfont{author}{size=\normalsize,parent=title}
-\setbeamerfont{institute}{size=\scriptsize,series=\mdseries,parent=structure}
-
-\setbeamerfont{section in toc}{size=\Large,series=\bfseries,parent=structure}
-\setbeamerfont{section in head/foot}{size=\tiny,parent=structure}
-\setbeamerfont{subsection in toc}{size=\small,series=\mdseries,parent={section in toc}}
-
-\setbeamerfont{frametitle}{size=\LARGE,series=\bfseries,parent=structure}
-\setbeamerfont{framesubtitle}{parent=frametitle,size=\Large}
-
-\setbeamerfont{caption}{size=\footnotesize}
-\setbeamerfont{item}{parent=structure,series=\mdseries}
-\setbeamerfont{block title}{size=\large,series=\mdseries,parent={structure,block body}}
-
-\mode
-<all>
diff --git a/report/Vortrag/beamerinnerthemeModernBeamer.sty b/report/Vortrag/beamerinnerthemeModernBeamer.sty
deleted file mode 100644
index 0f668a2f7023bf518d32aac8e66ae83d2fef338a..0000000000000000000000000000000000000000
--- a/report/Vortrag/beamerinnerthemeModernBeamer.sty
+++ /dev/null
@@ -1,203 +0,0 @@
-\pgfdeclareverticalshading[lower.bg,upper.bg]{bmb@transition}{200cm}{%
- color(0pt)=(lower.bg); color(2pt)=(lower.bg); color(4pt)=(lower.bg)}
-
-\setbeamersize{text margin left=2em,text margin right=2em}
-
-% table of contents (overview)
-\setbeamertemplate{section in toc}[sections numbered]
-\setbeamertemplate{subsection in toc}{\leavevmode\leftskip=3.2em\rlap{\hskip-2em\inserttocsectionnumber.\inserttocsubsectionnumber}\inserttocsubsection\par}
-
-\setbeamertemplate{navigation symbols}{}
-\setbeamertemplate{blocks}[default]
-\setbeamertemplate{enumerate items}[default]
-\setbeamertemplate{date}[default]
-
-% General frames
-\setbeamertemplate{frametitle}{\vspace*{1em}\bfseries\insertframetitle\par\vskip-6pt
- %-------------------------
- {\usebeamercolor[fg]{titlegraphic}\insertlogo\par}
-}
-
-% Footline
-\setbeamertemplate{footline}{%
- \begin{beamercolorbox}[ht=3em,sep=0.75em,wd=\paperwidth,leftskip=0.5cm,rightskip=0.5cm]{footlinecolor}
- \scriptsize{\insertshortinstitute}
- \hspace{1cm}
- \hfill
- \scriptsize{\insertframenumber/\inserttotalframenumber}
- \end{beamercolorbox}%
-}
-
-% Template for headings in multicolumn layout
-\setbeamertemplate{column_heading}{
- \begin{beamercolorbox}{NeonBlue}
- \end{beamercolorbox}
-}
-
-% Template for the final page of the presentation
-\setbeamertemplate{endpage}{\vspace{8em}
-
- \begingroup
- \centering
- % ------------------------
- \begin{beamercolorbox}[sep=8pt,left]{title}
- \setbeamercolor{normal text}{fg=red}
- \vskip2.5em\par
- \usebeamerfont{title}\finalpage \par%
- \end{beamercolorbox}%
- \vskip 2.5em\par
- % ------------------------
- \begin{beamercolorbox}[sep=8pt,left]{author}
- \usebeamerfont{author}\insertauthor
- \end{beamercolorbox}
- \vskip-2em
- % ------------------------
- \vskip1.5em\par
- \begin{beamercolorbox}[sep=8pt,left]{institute}
- \usebeamerfont{institute}\insertinstitute
- \hspace*{0.45\linewidth}
- \usebeamerfont{date}\insertdate
- \end{beamercolorbox}
- % ------------------------
- {\usebeamercolor[fg]{titlegraphic}\inserttitlegraphic\par}
- \endgroup
- \vfill
-
-}
-
-% Title page
-\setbeamertemplate{title page}{
- \vspace{8em}
- \begingroup
- \centering
- % ------------------------
- \begin{beamercolorbox}[sep=8pt,left]{title}
- \usebeamerfont{title}\inserttitle\par%
- \ifx\insertsubtitle\@empty%
- \else%
- \vskip0.25em%
- {\usebeamerfont{subtitle}\usebeamercolor[fg]{subtitle}\insertsubtitle\par}%
- \fi%
- \end{beamercolorbox}%
- \vskip4em\par
- % ------------------------
- \begin{beamercolorbox}[sep=8pt,left]{author}
- \usebeamerfont{author}\insertauthor
- \end{beamercolorbox}
- \vskip-2em
- % ------------------------
- \vskip1.5em\par
- \begin{beamercolorbox}[sep=8pt,left]{institute}
- \usebeamerfont{institute}\insertinstitute
- \hspace*{0.45\linewidth}
- \usebeamerfont{date}\insertdate
- \end{beamercolorbox}
-
- % Logo on the title page
- \titlegraphic{
- \begin{tikzpicture}[overlay,remember picture]
- \node[anchor=north west, outer xsep=26pt, outer ysep=20pt] at (current page.north west){
- %\includegraphics[width=12em]{AICStyleData/logos/Logo_AIC_FEECTU_Holo_white.png}
- };
- \end{tikzpicture}
- }
- {\usebeamercolor[fg]{titlegraphic}\inserttitlegraphic\par}
- \endgroup
- \vfill
-}
-
-% Section divider
-\setbeamertemplate{section divider}{
-\logo {
- \begin{tikzpicture}[overlay,remember picture]
- \node[left=0.2cm] at (current page.24){
- %\includegraphics[width=1.5cm]{AICStyleData/logos/Symbol_AIC_Neon_Blue.png}
- };
- \end{tikzpicture}
- }
- \vspace{14em}
- \begin{beamercolorbox}[sep=0pt,left]{frametitle}
- \usebeamerfont{frametitle}
- \insertsectionhead\par%
- \end{beamercolorbox}%
- \gradientline\par
- \vspace{6em}
- \begin{beamercolorbox}[ht=1em,sep=8pt,wd=\paperwidth,leftskip=0.5cm,rightskip=0.5cm]{footlinecolor}
- \scriptsize{\insertshortinstitute}
- \hspace{1cm}
- \hfill
- \end{beamercolorbox}%
- %-------------------------
- {\usebeamercolor[fg]{titlegraphic}\insertlogo\par}
-
-}
-
-
-%Select the Epilogue font (requires luaLatex or XeLaTex compilers)
-\setsansfont{Epilogue}[
- Path=./AICStyleData/epilogueFont/,
- Scale=0.9,
- Extension = .ttf,
- UprightFont=*-Regular,
- BoldFont=*-Bold,
- ItalicFont=*-Italic,
- BoldItalicFont=*-BoldItalic
- ]
-
-%----------------------------------------------------------------------------------------
-% Custom commands
-%----------------------------------------------------------------------------------------
-% Section divider
-% gradient color line for the section separation
-\newcommand{\gradientline}{\noindent%
- \begin{tikzpicture}
- \node [rectangle, left color=NeonBlue, right color=NeonBlue, middle color=mediumturquoise, anchor=north, minimum width=\linewidth, inner sep=0pt, minimum height=1.5pt] (box) at (current page.north){};
- \end{tikzpicture}
-}
-
-\newcommand \makesection[1]{
-{
-\usebackgroundtemplate{
-\includegraphics[width=\paperwidth]{Vortrag/AICStyleData/logos/LogoShapeLightRotated.png}
-}
-\begin{frame}[plain, noframenumbering]
- \section{#1}
- \usebeamertemplate{section divider}
-\end{frame}
-}
-}
-% ----------------------------------------------------------
-
-% command for building the last slide of the presentation
-\newcommand\finalpage{} % Empty by default.
-\newcommand\finalpagetext[1]{\renewcommand\finalpage{#1}}
-
-\newcommand \makefinalpage{
- {
- \usebackgroundtemplate{
- \includegraphics[width=\paperwidth]{Vortrag/AICStyleData/logos/LogoShapeDarkRotated.png}
- }
- \begin{frame}[plain]
- \usebeamertemplate{endpage}
- \end{frame}
- }
-}
-% ----------------------------------------------------------
-
-% command for building the first slide of the presentation
-\newcommand \maketitlepage{
- {
- \usebackgroundtemplate{
- \includegraphics[width=\paperwidth]{Vortrag/AICStyleData/logos/LogoShapeDarkRotated.png}
- }
-\begin{frame}[plain]
- % Print the title page as the first slide
- \titlepage
-\end{frame}
-}
-}
-% ----------------------------------------------------------
-
-% 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
deleted file mode 100644
index a2b8dea16cbccba854ba86d3d3f2c5856fbec35b..0000000000000000000000000000000000000000
--- a/report/Vortrag/beamerthemeModernBeamer.sty
+++ /dev/null
@@ -1,11 +0,0 @@
-\mode<presentation>
-
-% Settings
-\usetheme{Madrid}
-\useinnertheme{circles}
-
-\usefonttheme{ModernBeamer}
-\usecolortheme{ModernBeamer}
-\useinnertheme{ModernBeamer}
-
-\mode<all>
\ No newline at end of file
diff --git a/report/Vortrag/main.tex b/report/Vortrag/main.tex
deleted file mode 100644
index 932c28db51bd0cf47d1a862f5d51a8b229230c57..0000000000000000000000000000000000000000
--- a/report/Vortrag/main.tex
+++ /dev/null
@@ -1,425 +0,0 @@
-%------------------------------------------------
-% PACKAGES AND THEMES
-%------------------------------------------------
-\documentclass[aspectratio=169,xcolor=dvipsnames, t]{beamer}
-\usepackage{fontspec} % Allows using custom font. MUST be before loading the theme!
-\usetheme{ModernBeamer}
-\usepackage{hyperref}
-\usepackage{graphicx} % Allows including images
-\usepackage{booktabs} % Allows the use of \toprule, \midrule and \bottomrule in tables
-\usepackage{svg} %allows using svg figures
-\usepackage{tikz}
-\usetikzlibrary{positioning, shapes.misc}
-\usepackage{makecell}
-\usepackage{wrapfig}
-% ADD YOUR PACKAGES BELOW
-% ...
-\usepackage[
- backend=biber,
- bibstyle=ieee, % bibstyle verdeckt von Theme
- citestyle=ieee % alphabetic für Autorenkürzel
-]{biblatex}
-\addbibresource{../chessbibliography.bib}
-
-%------------------------------------------------
-% TITLE PAGE CONFIGURATION
-%------------------------------------------------
-
-% \title[short title]{Zwischenbericht Replikation - CHESS}
-\title[short title]{Interim report on our replication - CHESS}
-% \subtitle{Data Mining und Maschinelles Lernen}
-\subtitle{Data Mining and Machine Learning}
-% \author{Felix Feist, Erik Jonas Hartnick und Stephan Mitte}
-\author{Felix Feist, Erik Jonas Hartnick and Stephan Mitte}
-% \institute[]{Institut für Informatik \newline Naturwissenschaftliche Fakultät III\newline Martin-Luther-Universität Halle-Wittenberg}
-\institute[]{Institute of computer science \newline Naturwissenschaftliche Fakultät III\newline Martin-Luther-University Halle-Wittenberg}
-\date{29.01.2025}
-
-%------------------------------------------------
-% PRESENTATION SLIDES
-%------------------------------------------------
-
-\begin{document}
-
-\maketitlepage
-
-\begin{frame}[t]{Agenda}
- \tableofcontents
-\end{frame}
-
-%------------------------------------------------
-\makesection{Presentation of the paper}
-%------------------------------------------------
-\begin{frame}{Overview}
- \begin{itemize}
- \item CHESS: Contextual Harnessing for Efficient SQL Synthesis
- %\item Shayan Talaei, Mohammadreza Pourreza, Yu-Chen Chang, Azalia Mirhoseini, Amin Saberi
- \item Stanford University/USA and University of Alberta/Canada
- \item Submitted 27th Mai 2024
- \end{itemize}
- \vfill
- \textbf{Problem:}
- \begin{itemize}
- \item Translating natural language questions into SQL queries (Text-To-SQL)
- \item Accuracy gap for complex databases with large schemas, catalogs, content
- \end{itemize}
- \vfill
- \textbf{Contribution:}
- \begin{itemize}
- \item Novel multi-agent framework based on Large Language Models (LLMs)
- \item Improved generation of SQL queries in complex database
- \end{itemize}
-\end{frame}
-
-\begin{frame}{Challenges}
- \begin{itemize}
- \item<1-> navigating the ambiguities of natural language questions
- \begin{itemize}
- \item[\rightarrow]<2> Information Retriever (IR)
- \end{itemize}
- \vfill
- \item<1-> extensive size of database catalogs and values
- \begin{itemize}
- \item[\rightarrow]<2> Information Retriever (IR) \& Schema Selector (SS)
- \end{itemize}
- \vfill
- \item<1-> reasoning over large database schemas
- \begin{itemize}
- \item[\rightarrow]<2> Schema Selector (SS) \& Candidate Generator (CG)
- \end{itemize}
- \vfill
- \item<1-> ensuring the functional validity of the generated queries
- \begin{itemize}
- \item[\rightarrow]<2> Unit Tester (UT)
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-\begin{frame}[t]{Multi-Agent-Framework}
- \begin{minipage}[t]{0.70\textwidth}
- \vspace{0pt}
- \textbf{Information Retriever (IR)}
- \begin{itemize}
- \item gather relevant data related to user's input
- \item extract keywords using LLM calls
- \item searching for syntactic and semantic similarities using
- \begin{itemize}
- \item locality-sensitive hashing index of values (LSH)
- \item vector database to measure semantic similarity
- \end{itemize}
- \end{itemize}
- \end{minipage}
- \hfill
- \begin{minipage}[t]{0.15\textwidth}
- \vspace{0pt}
- \begin{tikzpicture}[
- thick,
- every node/.style = {draw, minimum width=1cm, minimum height=1cm},
- transform shape,
- scale=0.70
- ]
- \node[minimum height = 3.8cm, minimum width = 2.8cm] (surround) at (0,-0.2) {};
- \node[draw=none, minimum width=2.2cm, rounded rectangle] (chess) at (0,1) {\textbf{CHESS}};
- \node<1-1>[white, fill=green!45!black] (ir) at (-0.6,0) {\textbf{IR}};
- \node<2-2>[white, fill=green!45!black!30] (ir2) at (-0.6,0) {\textbf{IR}};
- \node<1-1>[white, fill=blue!45!black!30] (ss) at (0.6,0) {\textbf{SS}};
- \node<2-2>[white, fill=blue!45!black] (ss2) at (0.6,0) {\textbf{SS}};
- \node[white, fill=red!45!black!30] (cg) at (-0.6,-1.2) {\textbf{CG}};
- \node[white, fill=yellow!45!black!30] (ut) at (0.6,-1.2) {\textbf{UT}};
- \end{tikzpicture}
- \end{minipage}
- \pause
- \vfill
- \textbf{Schema Selector (SS)}
- \begin{itemize}
- \item[\rightarrow] redundant information reduce performance of LLM
- \item therefore prune large db schemas into manageable sub-schemas
- % --> allowing more efficient reasoning
- \item select necessary tables and columns through LLM prompting
- \item scalable performance even with more than 4000 columns
- \end{itemize}
-\end{frame}
-
-\begin{frame}[t]{Multi-Agent-Framework (Cont.)}
- \begin{minipage}[t]{0.75\textwidth}
- \vspace{0pt}
- \textbf{Candidate Generator (CG)}
- \begin{itemize}
- \item generates SQL queries with LLM prompt\\
- (using question, selected schema, tables and content)
- \item executes and revises generated candidates as needed\\
- (identify faulty queries e.g. syntax errors)
- \end{itemize}
- \end{minipage}
- \hfill
- \begin{minipage}[t]{0.15\textwidth}
- \vspace{0pt}
- \begin{tikzpicture}[
- thick,
- every node/.style = {draw, minimum width=1cm, minimum height=1cm},
- transform shape,
- scale=0.70
- ]
- \node[minimum height = 3.8cm, minimum width = 2.8cm] (surround) at (0,-0.2) {};
- \node[draw=none, minimum width=2.2cm, rounded rectangle] (chess) at (0,1) {\textbf{CHESS}};
- \node[white, fill=green!45!black!30] (ir) at (-0.6,0) {\textbf{IR}};
- \node[white, fill=blue!45!black!30] (ss) at (0.6,0) {\textbf{SS}};
- \node<1-1>[white, fill=red!45!black] (cg) at (-0.6,-1.2) {\textbf{CG}};
- \node<2-2>[white, fill=red!45!black!30] (cg2) at (-0.6,-1.2) {\textbf{CG}};
- \node<1-1>[white, fill=yellow!45!black!30] (ut) at (0.6,-1.2) {\textbf{UT}};
- \node<2-2>[white, fill=yellow!45!black] (ut) at (0.6,-1.2) {\textbf{UT}};
- \end{tikzpicture}
- \end{minipage}
- \vfill
- \pause
- \textbf{Unit Tester (UT)}
- \begin{itemize}
- \item assesses quality of final candidates
- \item validates queries through LLM-based natural language unit tests
- \item generating multiple tests and evaluate queries against them
- \item select most accurate query
- \end{itemize}
-\end{frame}
-
-\begin{frame}{Adaptivity for Deployment Constraints}
- \begin{itemize}
- \item adapt to different deployment scenarios (budgets and capabilities of LLMs)
- \item Narrows down industrial-scale db schemas into manageable sub-schemas
- \item[\Rightarrow]boosting system accuracy and reducing the number of LLM token
- \item Privacy-preserving performance using open-source model
- \end{itemize}
- \vfill
- \textbf{Deployment scenarios:}
- \begin{itemize}
- \item Maximize accuracy (higher comp. budget and powerful LLMs)\\
- labeled as $CHESS_{(IR,CG,UT)}$ with Unit Tester
- \item Maximize efficiency (limited comp. resources, weaker/smaller LLMs)\\
- labeled as $CHESS_{(IR,SS,CG)}$ with one candidate
- \end{itemize}
-\end{frame}
-
-%------------------------------------------------
-\makesection{Ressources}
-\begin{frame}{Used Ressources in the main paper}
- The Datasets used for experiments are:
- \begin{itemize}
- \item \href{https://yale-lily.github.io/spider}{Spider}
- \item \href{https://bird-bench.github.io/}{BIRD}
- \item Subsampled Development Set (SDS)
- \item Synthetic Industrial-scale Database Schema
- \end{itemize}
- Where SDS is a simplified variant of the BIRD dataset and the synthetic industrial-scale dataset is a combination of different databases from BIRD.
-
- SDS is given in the repository but the industrial scaled dataset could be difficult to reproduce.
-
- \textbf{Metrics}: Execution accuracy is used as the metric for comparison. Report both the total number of tokens and the number of LLM calls required by approach.
-\end{frame}
-%------------------------------------------------
-% Die Text-to-SQL-Gruppen sollen sich auf den Spider-Datensatz beschränken
-% Als LLM soll Hilfsmittel OLLAMA verwendet werden, das startet dann einen Webservice
-% Anfragen sind dann nur HTTP-requests mit einem JSON-Objekt
-% Zugriff auf LLMs ???
-% OLlama -> Llama 3.2-3B braucht (nur) 2 GB VRAM, Llama 3.3-20B braucht 43 GB VRAM, siehe https://github.com/ollama/ollama
-% ist nur runterladen:
-% curl -L https://ollama.com/download/ollama-linux-amd64.tgz -o ollama-linux-amd64.tgz
-% Entpacken:
-% tar -xzf ollama-linux-amd64.tgz
-% Service starten:
-% ollama serve
-% gewünschtes Modell/CLI-Chat starten, eine Weile warten, bis Modell geladen, z. B.
-% ollama run llama-3.2
-% API mit POST-Request an http://localhost:port/api/generate befeuern, mit JSON-Objekt im Request-Body, siehe:
-% https://github.com/ollama/ollama/blob/main/docs/api.md
-% Antwort ist base64-codiert, sollte leicht dekodierbar sein
-% Datensatz Spider, ggf. noch Spider 2.0 light, Bird geht zu weit (auch vom inhaltlichen Niveau her, das wäre wohl eher DBP, Ziel ist aber EDB)
-% Notiz: eine Anfrage BIRD mit Llama3.2 auf Quadro P4000 mit zu kleiner context-length ca. 1.5 Stunde, über 1500 Fragen
-%------------------------------------------------
-% Darauf eingehen, welche Experimente gemacht wurden und zu welchem Ergebnis die gekommen sind
-
-\begin{frame}{Experiments in the main paper}
- %The experiments in the main study are categorised as follows: --Redundant
- Experiments are categorised as follows:
- \begin{enumerate}
- \item Computing-intensive tests on Bird with IR, CG and UT
- \item Industrial-scale experiments
- \item Scenarios with limited computational budgets
- \begin{itemize}
- \item Open-Source LLMs (Llama-3-70B and fine-tuned DeepSeek model)
- \item Proprietary models (GPT-3.5/4-turbo)
- \end{itemize}
- %\item Ablation studies (to assess the contribution of each component) --kürzer
- \item Ablation studies (assess contribution of each agent)
- \end{enumerate}
- \vfill
- For the industrial-scaled dataset, it is not specified how this is formed and it is not made available either.
-\end{frame}
-%------------------------------------------------
-\makesection{Our goals}
-%------------------------------------------------
-% Unsere eigene Zielstellung formulieren
-
-%\begin{frame}{Our goals for the replication}
- %Für $CHESS_{(IR,CG,UT)}$ wurde Gemini 1.5-pro verwendet\\ % $CHEES_{(IR,CG,UT)}$
- % Da gibt es auch eine kostenlose Version müsste aber noch mal einer genauer nachschauen wie das geregelt ist. Ich weiß nicht wie man die API bedient und wie das mit den Zahlungen geregelt ist
- %Replikation der Ergebnisse über Reihenfolge von Unit Test und SQL-Canidates (EX=68.31 vs EX=66.78)
-
- %Für $CHESS_{(IR,SS,CG)}$ experiments using older proprietary models such as GPT-3.5/4-turbo (niedriger Dollar Bereich), as well as open-source models like \textbf{Llama-3-70B} and a \textbf{fine-tuned DeepSeek} model. % $CHEES_{(IR,SS,CG)}$
- %Hier können wir würde ich vorschlagen die Open-Source Varianten zu reproduzieren.
-
- %Wenn eines der beiden steht kann man am besten die einzelnen Funktionen vom SS weglassen und versuchen die Ergebnisse zu replizieren auch den Entity und Kontext Retriver weglassen ist eine Option. Hier wird das SDS verwendet was im repository hinterlegt ist.
- %Aber leider keine Angaben zum verwendeten LLM.
-
- %Technische Anforderungen fallen bei uns bis auf API Verfügbarkeit weg. Zu Open Source leider keine Angaben gefunden.
-%\end{frame}
-
-\begin{frame}{Our goals for the replication}
- % Stephans Ideen, überschneidungen mit obiger Folie
- \begin{itemize}
- \item Testing implementation and check proposed execution accuracy with $CHESS_{(IR,SS,CG)}$ (with Llama-3-70B) on the SDS
-
- %Testing implementation and check proposed execution accuracy with $CHESS_{(IR,CG,UT)}$ (with ???LLM) on the bird dataset
-
- % ------------------------------------------------
- % gemini-2.0-flash-exp ist aktuell noch kostenlos wegen exp.-version --> https://aistudio.google.com/prompts/new_chat
- % ------------------------------------------------
-
- \item Additionally testing $CHESS_{(IR,SS,CG)}$ (low power) with different number of revisions in the CG because of the tremendous accuracy drop of 6.80\% without revision tools (see tab. 4 in \cite{Talaei2024})
-
- % ------------------------------------------------
- % Laut paper wurde die schwache konfiguration mit 1 und 3 Kandidaten getestet und der/diese mussten dann das richtige Ergebnis haben. Aber die Revision hat laut Tab. 4 eine extremen einfluss, daher sollten wir diesen Untersuchen, denke ich. vermutlich machen ein paar mehr schon eine großen Unterschied aus, aber ab einem bestimmten Wert verbessert sich nichts mehr.
- % ------------------------------------------------
-
- \item Maybe we also could test a different kind of unit tests where $1$ candidate is evaluated against $M$ UTs (instead of $N$ candidates against $1$ UT) examine claimed accuracy drop of 68.31 down to 66.78 (see 4.2.1)
-
- \item We want to carry out additional experiments, where we want to test the $CHESS_{(IR,SS,CG)}$ configuration with the Spider2.0 Dataset
- \end{itemize}
-\end{frame}
-
-\begin{frame}{Expected results}
- \begin{itemize}
- \item For the tests with the $CHESS_{(IR,SS,CG)}$ configuration and Llama-3-70B we hope for very similar results compared to the paper
- % --> Gleiches Dataset und gleiche Umgebung, nur die Hardware ist vermutlich anders.
- \item The ablation studies and the different way of Unit-Testing will probably differ from the original work because we can't use Gemini and the $CHESS(IR,CG,UT)$ configuration. But we hope for similar proportions as in the original work
- \item The tests with the Spider2.0 dataset should be good but not as good as with the Spider dataset used in the original work
- \end{itemize}
-\end{frame}
-
-%------------------------------------------------
-\makesection{Code provided by the authors}
-%------------------------------------------------
-\begin{frame}{First impression of provided code}
- \begin{itemize}
- \item available on GitHub: \url{https://github.com/ShayanTalaei/CHESS}
- \item 3 main run scripts, configured for OpenAI API (GPT, \$\$ required)
- \item config files and python code for different models
- \item directory for datasets (fits BIRD best)
- \item directory with source code
- \item very short customization instructions for other models in README.md
- \item Ollama: webservice (localhost), very easy to set up
- \end{itemize}
-\end{frame}
-%------------------------------------------------
-% \makesection{Latex Examples}
-% Das ist nur für uns, um zu sehen, welche Highlights dieses Packet bereit stellt
-% Schlage vor, das wieder einzukommentieren, wenn wir nochmal nachschauen wollen, was es gab - Erik
-%------------------------------------------------
-
-
-
-%------------------------------------------------
-% Highlight boxes
-% \begin{frame}{Blocks of Highlighted Text}
-% In this slide, some important text will be \alert{highlighted} because it's important. Please, don't abuse it.
-
-% \begin{block}{Block}
-% Sample text
-% \end{block}
-
-% \begin{alertblock}{Alertblock}
-% Sample text in red box
-% \end{alertblock}
-
-% \begin{examples}
-% Sample text in green box. The title of the block is ``Examples".
-% \end{examples}
-% \end{frame}
-
-%------------------------------------------------
-% Double columns
-% \begin{frame}{Multiple Columns}
-% \begin{columns}
-% \begin{column}{0.45\textwidth}
-% \colheader{Heading}
-% \begin{enumerate}
-% \item Statement
-% \item Explanation
-% \item Example
-% \end{enumerate}
-% \end{column}
-% \begin{column}{0.45\textwidth} %%<--- here
-% \colheader{Heading}
-% Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer lectus nisl, ultricies in feugiat rutrum, porttitor sit amet augue. Aliquam ut tortor mauris. Sed volutpat ante purus, quis accumsan dolor.
-% \end{column}
-% \end{columns}
-% \end{frame}
-
-%------------------------------------------------
-% Theoerm (in highlighted box) and Equation in text
-% \begin{frame}{Theorem}
-% \begin{theorem}[Mass--energy equivalence]
-% $E = mc^2$
-% \end{theorem}
-% Equation in text
-% \begin{equation}
-% c^{2} = a^{2} + b^{2}
-% \end{equation}
-% \end{frame}
-
-%------------------------------------------------
-% Citations
-% \begin{frame}[fragile] % Need to use the fragile option when verbatim is used in the slide
-% \frametitle{Citation}
-% An example of the \verb|\cite| command to cite within the presentation:\\~
-
-% This statement requires citation \cite{Talaei2024}.
-% \end{frame}
-
-%------------------------------------------------
-% Referenced
-%\begin{frame}{References}
- % Beamer does not support BibTeX so references must be inserted manually as below
- % Vielleicht? Es unterstützt aber biblatex mit biber backend...
- % keine Ahnung, warum laut templatebibtex nicht gehen soll...
- % biblatex und ../chessbibliography.bib hinzugefügt, siehe unten für nocite
-% \footnotesize{
-% \begin{thebibliography}{99}
-% \bibitem[Smith, 2012]{p1} John Smith (2012)
-% \newblock Title of the publication
-% \newblock \emph{Journal Name} 12(3), 45 -- 678.
-
-% \bibitem[Doe, 2012]{p1} Joe Doe (2012)
-% \newblock Title of the publication
-% \newblock \emph{Journal Name} 12(3), 45 -- 678.
-% \bibitem[Doe, 2013]{p} Jane Doe (2012)
-% \newblock Title of the publication
-% \newblock \emph{Journal Name} 12(3), 45 -- 678.
-% \end{thebibliography}
-% }
-% \end{frame}
-
-% nicht mit \cite referenzierte Einträge, die auch unter Literatur erscheinen sollen
-% mit Komma trennen, ohne Leerzeichen
-\nocite{Talaei2024}
-\begin{frame}%[allowframebreaks]
- % Literatur kommt in ../chessbibliography.bib, bitte als biblatex formatieren
- \frametitle{References}
- \printbibliography
-\end{frame}
-%-----------------------------------------------
-% Final PAGE
-% \finalpagetext{Vielen Dank für Ihre Aufmerksamkeit}
-\finalpagetext{Thank you for your Attention!}
-%-----------------------------------------------
-\makefinalpage
-%-----------------------------------------------
-\end{document}
\ No newline at end of file
diff --git a/report/bericht-vorlage_24.tex b/report/bericht-vorlage_24.tex
deleted file mode 100644
index 63f14f3130395ce6b145c815e054d93df1d0bfb5..0000000000000000000000000000000000000000
--- a/report/bericht-vorlage_24.tex
+++ /dev/null
@@ -1,203 +0,0 @@
-\documentclass[DIV=13,fontsize=11pt]{scrartcl}
-\usepackage[ngerman]{babel}
-\usepackage[utf8]{inputenc}
-\usepackage{hyperref}
-\usepackage{amsmath}
-\usepackage{amssymb}
-
-
-\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/).}}
-%\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}
-
-\begin{document}
-\maketitle
-\section{Einleitung}
-\textbf{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.
-
-% 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}
-\textbf{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}
- ``This paper introduces a new activation function X that outperforms a similar activation function Y on tasks Z,V,W.'' oder
-
- ``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}
- ``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
-
- ``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}
-``Finetuning pretrained BERT on SST-2 will have higher accuracy than an LSTM trained with GloVe embeddings.'' oder
-
-``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}
-\textbf{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}
-\textbf{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}
-\textbf{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}
-\textbf{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}
-\textbf{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}
-\textbf{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}
-\textbf{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}
-\textbf{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 ``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 ``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}
- ``we reproduced the accuracy to within 1\% of reported value, that upholds the paper's conclusion that it performs much better than baselines.'' oder
-
- ``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}
-\textbf{Result 1}\\
-
-\subsection{Ergebnis 2}
-\textbf{Result 2}\\
-
-\subsection{Zusätzliche Ergebnisse, die nicht im Originalartikel enthalten waren}
-\textbf{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}
-\textbf{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?}
-\textbf{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?}
-\textbf{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 `` die Mathematik war schwer verständlich'' sondern sagen sie `` 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 ``the math was difficult to follow,'' say ``the math requires advanced knowledge of calculus to follow.''
-
-\subsection{Empfehlungen für die Replizierbarkeit / Reproduzierbarkeit}
-\textbf{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}
-\textbf{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.
-
-\end{document}
diff --git a/report/chessbibliography.bib b/report/chessbibliography.bib
index 8f98870d38841241fff5d31058372e53d12a648d..a94d6751a14cfcaf18f2032e3c70266054f11102 100644
--- a/report/chessbibliography.bib
+++ b/report/chessbibliography.bib
@@ -12,7 +12,7 @@
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},
+ urldate={2025-03-31},
volume={36},
year={2023}
}
@@ -38,7 +38,7 @@
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}
+ urldate = {2025-03-31}
}
@Article{Nussbaum2024,
@@ -82,7 +82,7 @@
title = {AI4DS/NL2SQL\_DeepSeek\_33B},
date = {2024-05-06},
url = {https://huggingface.co/AI4DS/NL2SQL_DeepSeek_33B},
- urldate = {2025-02-27}
+ urldate = {2025-03-31}
}
@Online{ChessRepo2024,
@@ -91,7 +91,7 @@
subtitle = {README -- CHESS: Contextual Harnessing for Efficient SQL Synthesis},
date = {2024-11-13},
url = {https://github.com/ShayanTalaei/CHESS},
- urldate = {2025-02-27}
+ urldate = {2025-03-31}
}
@online{SpiderLeaderbord,
@@ -99,7 +99,7 @@
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}
+ urldate = {2025-03-31}
}
@article{seq2sql,
diff --git a/report/content/01Einleitung.tex b/report/content/01Einleitung.tex
index ebc272ca1e7ab6c6810e8d95daa0109966b2559e..234bf527636ebfac73db7cbf950f5535c0f5c2d9 100644
--- a/report/content/01Einleitung.tex
+++ b/report/content/01Einleitung.tex
@@ -18,10 +18,7 @@ Aufgrund monetärer Beschränkungen ist es uns nicht möglich, Experimente mit p
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)
+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}. In \autoref{sec:kommunikation} gehen wir auf die Kommunikation mit den Autoren ein.
%%% 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.
diff --git a/report/content/02Umfang.tex b/report/content/02Umfang.tex
index 9598eec1db843c4e6a89f274464628b5d6d0d644..311696d6753bc5ce57c7dbf17f08d77bb1376272 100644
--- a/report/content/02Umfang.tex
+++ b/report/content/02Umfang.tex
@@ -52,9 +52,9 @@ Die Bewertung der erzielten Ergebnisse auf unterschiedlichen Text-To-SQL Benchma
% 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.
+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.
+In den Ablation-Studies des replizierten Artikels wird zudem ein signifikanter Einfluss des revise-Tools beschrieben \cite[siehe][Tabelle 4]{Talaei2024}, welches fehlerhaft generierte 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.
@@ -62,17 +62,17 @@ Für den Spider-Datensatz wird in \cite{Talaei2024} nur ein Ergebnis mit proprie
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 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 keine 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 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.
+\paragraph{Zu Behauptung 2:} In den Ablation-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.
+\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 sie 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}
diff --git a/report/content/03Methoden.tex b/report/content/03Methoden.tex
index c4cfa3e13bc0b83800df250b998a7e93131b322b..2dfa21efd1c1217cb245e69ac468bdba82856ab2 100644
--- a/report/content/03Methoden.tex
+++ b/report/content/03Methoden.tex
@@ -8,22 +8,28 @@ In diesem Abschnitt beschreiben wir den Aufbau unserer Experimente und die genut
\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.
+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.
+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.
+Der CG kann auch mehrere mögliche SQL-Anfragen 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.
+Ü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 Effektivität 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.
+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, das revise-Tool nur drei Revisionen. Aus der generierten SQL-Anfrage und der konsistentesten Revision wird dann eine finale SQL-Anfrage ausgewählt.
+% welcher dann auch als finale SQL-Anfrage genutzt wird. Das revise-Tool innerhalb des CGs wird aber trotzdem verwendet.
+% Ich hab mir das noch einmal angeschaut. generate_candidate erzeugt ggf. mehrere SQL-Anfragen mit dem Tool-Klassennamen als Schlüssel. Das Revise-Tool erzeugt eben seine geclusterten Revisions, und speichert die entsprechend mit dem Tool-Call als Schlüssel (falls das Agent-LLM mehrfach revise aufruft):
+% SQL_Meta_Infos = {"GenerateCandidate": [{"SQL": "..."}, {"SQL": "..."}, ...], "Revise_1": [{"SQL": "..."}, ...], "Revise_2": ...}
+% In Revise werden die geclustert (gleiche Hashwerte der Anfrage-Ergebnisse aus der DB) und aus dem größten Cluster, die kürzeste Anfrage ausgewählt. Nur dieses Ergebnis wird als Ergebnis für die "target_meta_info", also die hinterlegten Tool-Calls in dem aktuellen Revise gespeichert. Wenn also Revise 3-Mal aufgerufen wird und jeweils sind alle bisherigen Tool-Calls als wird als need_fixing markiert, dann bezieht der auch jeweils die SQL-Anfragen alle wieder mit ein. Also würden dann bis zu 3 SQL-Anfragen (bzw. SQL_Meta_Info-Objekte mit je einer Anfrage) zur Liste von "Revise_3" in state.SQL_Meta_Infos hinzugefügt.
+% Das "evaluation-Tool" (evaluation.py in Ordner Agents) geht dann über die Keys, also "GenerateCandidate", "Revise_1", ggf. "Revise_2", etc. und wählt *für jeden Key* das erste Element aus der Liste aus, schaut ob der syntaktisch richtig ist, und wenn ja, wird die finale SQL-Anfrage damit überschrieben, sodass effektiv die letzte syntaktisch korrekte SQL-Anfrage in der Liste der Keys die finale wird. Insbesondere bezieht das aber trotzdem sowohl "GenerateCandidate", als auch "Revise_1" ein. - E
+% PS: Es ist trotzdem problemlos möglich, mehrere generierte Kandidaten zu haben und in die Revisions zu stecken, das gibt dann mehr Auswahl für die Cluster. Ich vermute, dass 3 = 1*3 < 10*3 = 30 bei 10 Kandidaten einen Einfluss auf die Ergebnisse haben könnte, der erklärt, warum wir zwischen 0 und 1 bzw. 3 nicht annähernd/umgekehrt verlaufende Werte haben... (Statt 0, 10 und 30)
\paragraph{LLM Modelle}
In unserer Konfiguration nutzen wir analog zu \cite{Talaei2024} \textit{Llama-3-70B} \cite{Grattafiori2024} für:
@@ -33,9 +39,9 @@ In unserer Konfiguration nutzen wir analog zu \cite{Talaei2024} \textit{Llama-3-
\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}.
+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}.
+Zusätzlich werden in der Vorberechnung 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}
@@ -50,24 +56,18 @@ Zusätzlich werden in der Vorberchnung und im Tool \textit{retrieve\_entity} des
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.
+\paragraph{Subsampled Spider Test Set}
+Bei der Durchführung unserer Experimente mussten wir feststellen, dass wir mit dem kompletten Spider-\textit{test}-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 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.
+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. In der Vorberechnung werden für die LSH-Berechnung die vorhandenen Werte mit Signaturlänge von 100, $n$-Gramm-Länge von 3 und Schwellwert von 0.01 verwendet.
-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
+Als Datentyp für \textit{NL2SQL\_DeepSeek\_33B} haben wir das im Quellcode gegebene \textit{bfloat16} genutzt \cite{ChessRepo2024}, während für Llama3-70B die Instruct-Variante mit 4-Bit Quantisierung genutzt wurde. Sonstige Hyperparameter haben wir auf den Standardwerten von \textit{Ollama} und \textit{vLLM} belassen, sofern diese nicht ebenfalls durch den Quellcode zu \cite{Talaei2024} beeinflusst werden.
\subsection{Implementierung}
%\minisec{Implementation}
@@ -78,7 +78,7 @@ Das von den Autoren bereitgestellte GitHub-Repository \cite{ChessRepo2024} wurde
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.
+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, sofern die Überarbeitung syntaktisch korrekt ist. 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 nach gleichen Anfrage-Ergebnissen clustert und vom größten Cluster die kürzeste Anfrage auswählt. Dies war in einer älteren Version des CHESS-Frameworks so umgesetzt.
\input{assets/implRevise}
@@ -86,11 +86,12 @@ Eine weitere Änderung betrifft die Schnittstelle zum Laden der Datensätze der
\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.
+Schließlich haben wir aus den geschlossenen Issues des Original-Repository erfahren, dass es einer Änderung am GC Agenten bedarf, damit dieser das reduzierte Datenbankschema nutzt und nicht auf das ursprüngliche, gesamte Schema zurück greift. Andernfalls wären die Berechnungen des Information Retrievers und Schema Selectors nutzlos gewesen. 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
+% TODO:
+% - repo aufräumen, Doku schreiben
% Notiz: https://www.acm.org/publications/policies/artifact-review-and-badging-current ACM badges für die Zukunft
\subsection{Aufbau der Experimente}
@@ -104,55 +105,92 @@ Für die verschiedenen Experimente benötigen wir die folgenden Konfigurationen
\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 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 (81920 MiB VRAM) auf einem der Knoten reserviert. \textit{Llama-3-70B} wird daher gemeinsam mit den Embedding-Modellen von \textit{Ollama} in eine Grafikkarte geladen, währen \textit{vLLM} \textit{NL2SQL-DeepSeek-33B} in die andere Grafikkarte lädt. Der verwendete 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 wird mithilfe selbst geschriebener Skripte gesteuert, die 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. Die von CHESS generierten Resultate werden nach dem Abschluss von \texttt{runchess.sh} in eine zip-Datei gepackt und in das Verzeichnis kopiert, aus dem \texttt{copyrepo.sh} mit dem \texttt{sbatch}-Befehl gestartet wurde, um danach den Speicherplatz auf dem GPU-Server wieder freigegeben zu können. Die Laufzeiten wurden mit dem Accounting-Befehl \texttt{sacct} von Slurm bestimmt.
-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.
+Auf dem GPU-Server ist \texttt{Debian GNU/Linux 12 (bookworm)} mit den Grafikkarten-Treiber und dem \textit{CUDA}-Toolkit des Grafikkarten-Herstellers \textit{NVIDIA} in der Version 570.124.06 installiert. Zur Ausführung wurde die installierte Python-Version 3.11.2 verwendet.
-% 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.
+% Hab noch ergänzt, wie wir zu Resultaten und Zeiten kommen, welche OS, CUDA und Python-Versionen ergänzt, das etwas kryptische TODO bezog sich auf die Embeds, die hab ich auch noch ergänzt, sonst denke ich, war das schon gut schon - E
\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:
+Das verwendete Modell \textit{Llama-3-70B} benötigt mit der genutzten Kontextlänge von 8192 Token einen Grafikspeicher von 53685 MiB, während \textit{NL2SQL\_DeepSeek\_33B} 72640 MiB 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 960 MiB 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 1066 MiB. Diese prozessbasierten Messwerte wurden als prozessbasierte Werte mit \texttt{nvidia-smi} zu mehreren Zeitpunkten während eines Testlaufs erhoben und waren über meherere Testläufe und die Messzeitpunkte konstant. Die Gesamtauslastung der Grafikkarte mit den von \textit{Ollama} verwalteten Modellen lag bei unseren Messungen zwischen 23 MiB und 71 MiB höher (55707 MiB bis 55775 MiB), die Gesamtauslastung der Grafikkarte mit dem durch \textit{vLLM} verwalteten Modell zwischen 21 MiB und 27 MiB (72667 MiB bis 72673 MiB). Damit ließen sich kleinere Grafikkarten nur mit höherer Quantisierung oder mit CPU-Offloading und sehr viel größerer Laufzeit verwenden.
+% 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.
+
+%
+% +-----------------------------------------------------------------------------------------+
+% | Processes: |
+% | GPU GI CI PID Type Process name GPU Memory |
+% | ID ID Usage |
+% |=========================================================================================|
+% | 0 N/A N/A 948846 C python3.11 64478MiB | -> vllm (vor Ausführung)
+% | 1 N/A N/A 949439 C ...ku/re-chess/ollama/bin/ollama 1066MiB | -> mxbai
+% +-----------------------------------------------------------------------------------------+
+% +-----------------------------------------------------------------------------------------+
+% | Processes: |
+% | GPU GI CI PID Type Process name GPU Memory |
+% | ID ID Usage |
+% |=========================================================================================|
+% | 0 N/A N/A 1167003 C python3.11 72640MiB | -> vllm (während Ausführung)
+% | 1 N/A N/A 1170578 C ...ku/re-chess/ollama/bin/ollama 1066MiB | -> mxbai
+% | 1 N/A N/A 1177589 C ...ku/re-chess/ollama/bin/ollama 53658MiB | -> Llama3-70B
+% | 1 N/A N/A 1177671 C ...ku/re-chess/ollama/bin/ollama 960MiB | -> nomic embed text
+% +-----------------------------------------------------------------------------------------+
+% -> Werte sind konstant, da reservierter/persistenter Speicher
+% -> tatsächlicher Speicher (managed Memory) kann höher sein, sieht so aus, als gäbe es 1 MiB für Treiber-Overhead
+% -> die GPUs sind reserviert, heißt wir sind die einzigen neben dem Treiber, den Grafikspeicher "nimmt uns keiner weg", bevor wir messen können, daher ist das immer der Maximalwert.
+% -> auch über mehrere Läufe und Messzeitpunkte konstant
+
+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 bei einem zweistündigen und zehnstündigen Testlauf 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. Nach 10 Stunden waren 83 der 147 Instanzen des Subsampled Development Set berechnet, was einer durchschnittlichen Laufzeit von etwa sieben Minuten pro Instanz oder etwa 17 Stunden und 15 Minuten für den Datensatz entspricht. Daher wurden die Zeitlimits für die Slurm-Jobs der Subsampled-Datensätze auf je zwei Tage und zwei Stunden gesetzt, für den gesamten Spider-Datensatz auf 12 Tage, wobei davon auszugehen war, dass diese Zeitlimits in der Regel weit unterschritten werden würden. Für die benötigten CPU/GPU-Stunden bei den verschiedenen Experimenten ergeben sich die folgenden Werte:
+
+% Job-Zeitlimits ergänzt, und dass ich erstmal mit 2 Stunden getestet hab, um eine Idee für die Laufzeit zu bekommen
\textbf{Experiment zu \hyperref[txt:beh1bird]{Behauptung 1}:}
% 18:26:42 Laufzeit komplett
-% 9 Tage 05:20:24 Laufzeit auf den CPU's
+% 9 Tage 05:20:24 Laufzeit auf den CPUs
% 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
+% 9 Tage 03:53:12 Laufzeit auf den CPUs
% 1 Kandidat u. 1 Rev.
% 18:22:14 Laufzeit komplett
-% 9 Tage 04:26:48 Laufzeit auf den CPU's
+% 9 Tage 04:26:48 Laufzeit auf den CPUs
% 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.
+Auch bei den Experimenten zu \hyperref[txt:beh2revision]{Behauptung 2} ergab sich eine große Abweichung zu der erwarteten Zeit. Das Reduzieren der Revisionen brachte keine großen Zeitersparnisse. Für das Experiment mit \texttt{sampling\_count = 1} wurde 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
+% 4 Tage 12:40:12 Laufzeit auf den CPUs
% STS, mxbai, nomic: 1 Kandidat u. 3 Rev.
% 09:47:04 Laufzeit komplett
-% 4 Tage 21:24:48 Laufzeit auf den CPU's
+% 4 Tage 21:24:48 Laufzeit auf den CPUs
% 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.
+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 12:40:12 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\}}
+% 1 Tag 11:20:26 Laufzeit komplett
+% 17 Tage 16:05:12 Laufzeit auf den CPUs
+% SPIDER, Llama3-70B: 1 Kandidat u. 3 Rev. Teil 1
+% 2 Tage 01:48:48 Laufzeit komplett
+% 24 Tage 21:45:36 Laufzeit auf den CPU's
+% SPIDER, Llama3-70B: 1 Kandidat u. 3 Rev. Teil 2
+% 3 Tage 13:09:14 Gesamt-Laufzeit komplett
+% 42 Tage 13:50:48 Gesamt-Laufzeit auf den CPU's
+% SPIDER, Llama3-70B: 1 Kandidat u. 3 Rev. Gesamt
+% 2025-03-26T21:12:32 - 2025-03-26T21:12:32 = 02:22:19
+Bei den Tests auf dem vollständigen Spider-Datensatz war zu erwarten, dass die Laufzeit bedeutend höher ist, als zuvor, da dieser aus 2147 Frage-Anfrage-Paaren besteht. Während die Tool-Calls für alle anderen Läufe problemlos gelaufen waren, kam es nach 787 Frage-Anfrage-Paaren zu einem Absturz durch ein falsch aufgerufenes generate\_candidate, da dieser Fehler nicht durch das CHESS-Framework abgefangen wurde. Der Datensatz wurde daher geteilt in die bereits abgeschlossenen 787 Instanzen und die übrigen 1360 Instanzen, mit denen die Ausführung ohne weitere Unterbrechung bis zum Ende geführt wurde. Der erste Teil benötigte eine Laufzeit von 1 Tag 11:20:26 und eine CPU-Zeit von 17 Tage 16:05:12. Der zweite Teil wurde nach einer Unterbrechung von 02:22:19 gestartet und benötigte eine Laufzeit von 2 Tagen 01:48:48 und eine CPU-Zeit von 24 Tagen 21:45:36. Die Laufzeit für den gesamten Spider Test Datensatz ohne Unterbrechung beträgt 3 Tage 13:09:14, die CPU-Zeit 42 Tage 13:50:48. % \textbf{\{...Hier muss dann noch die Laufzeit für den Spider Datensatz hin\}} - ergänzt, E
% 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
-
+% Ich hab da Mal noch ein bisschen was ergänzt, was diesbezüglich vielleicht sinnvoll sein könnte.
+% Zeiten für Spider ergänzt - E
%\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
index 7b43f16fb34dad4e3c450b81f1700f42c7fa32ae..0257dc6a9fce1554ddc55e7b7281cf57ca1dae35 100644
--- a/report/content/04Ergebnisse.tex
+++ b/report/content/04Ergebnisse.tex
@@ -1,9 +1,9 @@
\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.
+In diesem Abschnitt beschreiben wir die Ergebnisse unserer experimentellen Untersuchungen. Diese überprüfen die in \autoref{sec:Scope} aufgestellten Behauptungen über den replizierten Artikel. Die Rohdaten aller Experimente stehen über einen Link im Repository zur Verfügung.
%\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.
+Unsere erste Untersuchung repliziert ein Experiment aus \cite{Talaei2024}, bei dem das CHESS-Framework auf dem BIRD-Datensatz mit quelloffenen LLMs getestet wurde. Wir nutzten 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 für 3 Revisionen nur einen Wert von $EX=50.34$ erreichen. Folglich kann mit diesem Experiment die \hyperref[txt:beh1bird]{Behauptung 1} nicht bestätigt werden. % 54.42 ist der Wert hier, ich würde diese Dissonanz bewusst aufnehmen und unten dann "diskutieren", also sagen, das wir nicht herausfinden konnten, woran das lag...
\begin{table}[!tb]
\centering
@@ -19,7 +19,7 @@ Unsere erste Untersuchung repliziert ein Experiment aus \cite{Talaei2024}, bei d
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.
+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 weiteren Verlauf konnten wir dann aber auch den vollständigen Spider-Datensatz testen und einen Wert von $EX=60.64$ 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 - 60.64 = 26.56$. 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
@@ -43,9 +43,9 @@ Das dritte Experiment liefert einen Wert für die \textit{Execution Accuracy} de
\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{???}\\
+ \textbf{$CHESS_{(IR,SS,CG)}$ + Open LLMs} & - & 61.5 & \textbf{60.64}\\
\hline
- $\Delta EX$ = $EX_{\text{proprietär}}$ - $EX_{\text{OpenLLM}}$ & - & 3.5 & \textbf{???} \\
+ $\Delta EX$ = $EX_{\text{proprietär}}$ - $EX_{\text{OpenLLM}}$ & - & 3.5 & \textbf{26.56} \\
\end{tabular}
\caption{Überblick verschiedener CHESS-Konfigurationen auf unterschiedlichen Benchmarks}
\label{tab:performance2}
@@ -57,13 +57,15 @@ Die Ergebnisse unserer Experimente zeigen, dass keine unserer formulierten Behau
%\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.
+\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=50.34$ erreichen. Die Abweichung führen wir auf die genutzten Embedding-Modelle und Hyperparameter 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 und deren Hyperparameter nicht näher beschrieben. 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. % Hier auch nochmal den Wert korrigiert - E
%\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.
+\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 an sich zu einer höheren \textit{Execution Accuracy} führt. Jedoch konnte nicht der gleiche signifikante Einfluss festgestellt werden, wie in \cite{Talaei2024} und sogar einen negativen Einfluss bei Erhöhung der Revisionen auf drei, wie in Experiment 1 gezeigt. 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.
+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 einzige 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 Anzahl der generierten Kandidaten. Da diese für die Ablationsstudien in \cite{Talaei2024} nicht dokumentiert ist, gehen wird davon aus, dass sie auf 10 Kandidaten belassen wurden, wie es in einer der Beispiel-Konfigurationen im Quelltext angegeben ist. Da wir aber aufgrund der Konfiguration mit quelloffenen Modelle nur einen Kandidat generieren, würden sich statt bis zu zehn Revisionen bei einem \texttt{sampling\_count} von 1 oder bis zu 30 Revisionen bei einem \texttt{sampling\_count} von 3 für die quelloffenen Modelle nur 1 und 3 Revisionen respektive ergeben, sodass hier beim Clustering für die finale Anfrage vermutlich der Zufall überwiegen könnte. Da bei den Ablation-Studies in \cite{Talaei2024} für Clustering und Wahl der finalen SQL-Anfrage aber das gleiche Verfahren verwendet wurde, haben wir hier auch keine Änderungen vorgenommen.
+% Eine Erklärung dieses Phänomens sehen wir in der Wahl 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.
+% Die Wahl der kürzesten Anfrage basiert aber auf dem Clustering nach gleichen Ergebnissen beim schicken der generierten Anfragen an die DB (bzw. genauer gleichen Hashwert auf den Anfrage-Ergebnissen), die Länge der Anfrage macht also für das Ergebnis nachher keinen Unterschied. Ich hab nochmal drüber nachgedacht und glaube eher, dass das Clustering bei 3 Anfragen mit Llama3 einen negativen Effekt hervorrufen kann, vielleicht weil Llama sich gern auch 2 Mal gleich auf dieselbe Art und Weise irrt oder vielleicht 3 Mal je unterschiedliche Ergebnisse erzeugt, die je eine Clustergröße von 1 bedeuten oder so und damit wird es Random. Es wird ja immer die letzte syntaktisch korrekte Variante zwischen GenerateCandidate und Revise gewählt. Vielleicht ist Llama3-70B auch einfach schlecht geworden bei den Revisionen oder die haben noch irgendwo einen Fehler drin, den wir nicht finden können. Spannend finde ich ja immer noch das verworfene Ergebnis, wo ich mit dem falsch definierten complete-Schema in generate_candidate schon 44.90 % hatte, als ich das Revise-Modell und den Agenten CG auf das finetuned DeepSeek-Coder gesetzt hatte, eben statt so um die 30 %. Dann wäre aber die Konfiguration im Anhang mit den Model Ablations bzw. der gesamte Anhang B gelogen, das wird es also eher auch nicht sein... - E
\begin{table}[tb]
\centering
@@ -80,7 +82,9 @@ Eine weitere interessante Beobachtung bei diesem Experiment ist die Verteilung d
%\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.
+\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 einen Teil des GPU-Server für eine ganze Woche blockieren würden. Zudem haben wir aufgrund der Ergebnisse von Experiment 1 und 2 hinterfragt, ob sich die Formulierung \enquote{In the second case, we used our fine-tuned DeepSeek Coder model for candidate generation, with all other LLM calls handled by Llama-3-70B} \cite[9]{Talaei2024} nicht auch auf die genutzten Embedding-Modelle bezieht und haben zusätzlich \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 $60.64$ 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 - 60.64 = 26.56$. Diese Abweichung ist deutlich größer, als von uns erwartet. Mit den vorangegangenen Tests auf dem Subsampled Spider Datensatz mit unterschiedlichen Embedding-Modellen behaupten wir, dass die Wahl der Embedding-Modelle einen 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, da wir aber keinen Zugriff auf die proprietären Embedding-Modelle in \cite{Talaei2024} haben, können wir diese Behauptung nicht selbst überprüfen. Auch die Wahl weiterer Hyperparameter sowie die Verwendung von neueren OpenSource-Modellen mit größeren Kontextlängen müssen wir durch die zeitliche Ressourcenbeschränkung auf zukünftige Arbeiten verschieben.
+% 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. -> Können wir das sicher behaupten? Wir gehen davon aus, weil das der einzige offensichtliche Parameter ist, an dem wir noch dran rum schrauben können, abgesehen von den Hyperparametern. Die Wahl der Embedding-Modelle macht aber nur einen Unterschied von 2.18 aus. In den Gesprächen hat sich Hinneburg da skeptisch gezeigt, ich würde das hier etwas weicher formulieren und das mit der Kontextlänge noch mit auflisten, dann ist er Happy, auch wenn wir vielleicht erstmal anderer Meinung sind...
-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
index f27722bebfad9a508b950e783cbe8281d6f52dec..afab8c42d5f11393a76f20d1603b5fcc61d0c981 100644
--- a/report/content/05Diskussion.tex
+++ b/report/content/05Diskussion.tex
@@ -7,7 +7,7 @@ Zunächst möchten wir festhalten, dass der Artikel mit Einschränkungen replizi
%\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.
+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 generierten Rohdaten zur Verfügung. Wichtige Informationen wie zum Beispiel die genutzten Embedding-Modelle oder Hyperparameter 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.
@@ -16,26 +16,38 @@ Aufgrund der deutlich geringeren $EX$ Werte unserer Experimente stellen wir die
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.
+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. Zwei verwendete Beispiel-Konfigurationen sind ebenfalls im Repository enthalten.
+% Die verwendeten Konfigurationen sind ebenfalls im Repository enthalten.
+% Finde ich so treffender formuliert. Eigentlich wäre eine Auflistung von: Experiment 15 -> Konfiguration 2.4 das, was man in einer vollständigen Beschreibung erwarten würde, also zumindest in Physik und Chemie...
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.
+Die Experimente in \cite{Talaei2024} wurden bis auf zwei Ausnahmen ausschließlich auf proprietären LLMs durchgeführt, wobei die eine Ausnahme auch nur im Anhang erwähnt wird. 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 für die quelloffene Variante nicht genannt 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.
+% Zwei Ausnahmen, siehe Anhang D.2 Model Ablations, Table 8, sie haben auch noch komplett nur Llama3-70B verwendet... Und kommen auf EX = 54.42 %, unseren 1-Revisions Wert mit DeepSeek :')
-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 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 heben hervor, dass sich diese Inkonsistenz gegebenenfalls durch eine erneute Durchführung der Experimente passend zur Formulierung, oder durch eine Anpassung im Sinne der zitierten \enquote{Self-Consistency} beheben lässt, da in \cite{Talaei2024} ein signifikanter Einfluss auf die \textit{Execution Accuracy} behauptet wird. Zudem ist die Anzahl der durchgeführten Revisionen nicht (mehr) 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.
+% Wir sehen die Autoren in der Pflicht diese Inkonsistenz zu beheben und gegebenenfalls die Experimente neu durchzuführen, da sie behaupten, dass dieses Tools einen signifikanten Einfluss auf die \textit{Execution Accuracy} hat.
+% Ich weiß nicht, ob das nicht zu direkt ist... Hinneburg hat sich ja schon beschwert, dass ihm das wir nicht unpersönlich genug ist.
+% ... Nicht, dass ich die Ansicht nicht teilen würde, aber ist vielleicht nicht ganz passend für eine wissenschaftliche Arbeit...
+% oder diese Formulierung im Sinne der zitierten \enquote{Self-Consistency} anzupassen, -> ergänzt - E
-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.
+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ätze nutzt und die passende Implementierung im Code nicht enthalten ist. Die entsprechenden Anpassungen im Code sind zwar trivial, aber gerade aus diesem Grund wäre es im Sinne der Anpassbarkeit an unterschiedliche Datensätze gut, wenn die Schnittstelle konfigurierbar gestaltet ist. Damit wären auch andere Datensätze, wie zum Beispiel die neue Version des Spider-Datensatz \cite{spider2}, leicht nutzbar.
+% 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.
+% auch hier, gebe ich euch Recht, aber die Formulierung könnte Hinneburg sauer aufstoßen.
% 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.
+% - Im Code heißt das Tool generate_candidate -> ohne _query, aber auch erst seit der neuen Version.
+% - Im Prinzip lässt sich das auf die Formulierung "In the second case, we used our fine-tuned DeepSeek Coder model for *candidate generation*, with all other LLM calls handled by Llama-3-70B." runterbrechen, die mich so sehr stört.
+% Im Revise Tool werden ja genau genommen auch Kandidaten generiert und der Agent heißt nunmal Candidate Generator. Das Problem ist, wenn man die Arbeit von vorn liest und den Anhang erstmal ignoriert (was ja bei den Review-Runden für Konferenzen nicht unüblich ist, dass Reviewer nicht verpflichtet sind, den Anhang zu lesen), dann geht dieser Kontext aus dem Anhang verloren. Jetzt kann man sagen, gut, E kann nicht lesen, für die Replikation gehört der Anhang schon dazu, man kann aber durchaus auch sagen, im Fließtext, ohne den Kontext im Anhang ist das zu ungenau und kann zu Missverständnissen bei den Reviewern führen. Es hätte nicht wehgetan, da einfach "for the generate_candidate_query Tool" zu schreiben, wenn ich das richtig sehe, dann noch nicht mal vom Platz auf der Zeile oder so, das wäre einfach in die nächste am Absatzende nachgerückt...
+% Vielleicht kumuliert da auch etwas meine angestaute Frustration in diesem einen Punkt und alleine genommen ist das nicht ganz so tragisch, aber das wäre was, was ich in eine Review mit einbeziehen würde. Ich bin jedenfalls deutlich drüber gestolpert, in dem Sinne, dass wir da einen Run von 19:03:58 verloren haben, der zumindest deutlich bessere Ergebnisse liefert, als alles das, was wir danach bis zur Korrektur vom tentative-Schema hatten (44.9 %). Wegen mir können wir das auch raus lassen, wenn ihr sagt, wir nörgeln schon genug und eine saubere Review können andere schreiben. - E
+% Die Formulierung \enquote{In the second case, we used our fine-tuned DeepSeek Coder model for \textit{candidate generation}, [...]} \cite[9]{Talaei2024} ist ohne die Berücksichtigung des Kontexts in \cite[Anhang B und D.2]{Talaei2024} unpräzise, darauf sind wir bei der Konfiguration des Candidate Generators aufmerksam geworden. Eine konkrete Nennung des Tools \textit{generate\_candidate\_query} in der Version der Arbeit bzw. \textit{generate_candidate} im Quelltext wäre hier präziser und beugt Missverständnissen vor, da auch das Revise-Tool verbesserte Kandiadaten generiert und der gesamte Agent Candidate Generator die Aufgabe der Generierung übernimmt.
\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.}
diff --git a/report/content/06Kommunikation.tex b/report/content/06Kommunikation.tex
index 468aa065b4038a9d0750dddb7960031bd19ea59b..146f8d60c316b795ca4590a39f78b69700d9ca47 100644
--- a/report/content/06Kommunikation.tex
+++ b/report/content/06Kommunikation.tex
@@ -1,14 +1,14 @@
-\section{Kommunikation mit den Autoren}
+\section{Kommunikation mit den Autoren}\label{sec:kommunikation}
%\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.
+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. Die vollständige E-Mail ist in \autoref{app:email} beigefügt.
-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.
+Es 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.
+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 eine 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
diff --git a/report/content/07Anhang.tex b/report/content/07Anhang.tex
new file mode 100644
index 0000000000000000000000000000000000000000..ee84f335b1f899056197d031a34eb4021e20fd9b
--- /dev/null
+++ b/report/content/07Anhang.tex
@@ -0,0 +1,43 @@
+\appendix
+\label{app:email}
+\section{E-Mail an die Autoren}
+In \autoref{sec:kommunikation} wurden in der Kommunikation mit den Autoren die Fragen der E-Mail beschrieben. Diese wurde am 13. März 2025 um 12:59 Uhr an die für Korrespondenz angegebene E-Mail-Adresse versendet und ist im Folgenden beigefügt.
+
+\begin{lstlisting}
+Dear authors of the CHESS paper, dear Mr. Talaei,
+
+We hope this message finds you well. We are students at Martin-Luther-University Halle-Wittenberg in Germany and are currently working on a replication of your paper "CHESS: Contextual Harnessing for Efficient SQL Synthesis" that we would like to use as the basis for a term paper.
+In doing so, we have encountered some problems that we could not resolve with the available sources.
+We are therefore addressing this email directly to you in the hope that you might be able to provide us with some additional insights that could lead to a resolution.
+
+First of all, we must mention that we are focusing on the open source experiments of your work, as we only have very limited computing resources at our disposal.
+Unfortunately, we have not yet been able to achieve similar EX values to the ones you achieved in your work.
+So far, our results are in the low 30% range with Llama3-70B on the BIRD-SDS with sampling counts of both one and three for the revisions.
+We use the fine-tuned NL2SQL_DeepSeek_33B model for the generate_candidate function as specified and Llama3-70B for all other queries.
+For this reason, we would like to ask you the following three questions.
+
+1. Selected temperatures in the OpenSource version:
+
+Did you use the default temperatures given in the example configuration on your GitHub repository for the OpenSource experiments or did you use other values for these experiments?
+If you happened to have used other temperatures, we would be grateful if you could kindly share them with us.
+Even if you cannot provide the values, it would already be very helpful to know whether you used the default temperatures or not.
+
+2. Embedding models used:
+
+Which embedding models did you use for the configuration with the open source models, both during preprocessing and the retrieve entity tool calls?
+It is not directly clear from the paper which models were used for embedding. While the use of Llama3-70B is implied, we tried both a variant with Llama3-70B as well as a variant with OpenSource embedding models that claim to deliver comparable results to the proprietary embedding models given in your code.
+Unfortunately, both approaches were unsuccessful, resulting in the EX range mentioned above.
+
+3. Disabling the revisions:
+
+In addition to the experiments on the BIRD-SDS with Llama3-70B, we also wanted to replicate part of the ablation studies.
+We decided to investigate the influence of revisions on the EX. However, we had difficulty completely deactivating the revisions without unwanted side effects.
+Could you kindly share how you achieved a deactivation without such side effects?
+Did you set the sampling count to 0, comment out the tool entirely or use another method to avoid the tool calls to revise?
+
+We greatly appreciate your time and assistance and we are thankful for any guidance you can provide.
+
+Yours sincerely,
+
+Erik Hartnick, Felix Feist and Stephan Mitte
+\end{lstlisting}
\ No newline at end of file