Geschrieben von Computational and Data Science Student Joël Barandun im Rahmen seiner Bachelorarbeit, betreut von Prof. Dr. Martin Bünner und Stefano Balestra.
46 oder 770? Auf die Frage, wie viele Trainingseinheiten zweier Athletinnen im ersten Quartal auf die 50-Meter-Distanz entfielen, lieferte ein und derselbe Datensatz zwei verschiedene Antworten. Richtig war 46. Die 770 umfasste sämtliche Trainingseinheiten des Quartals: Das Sprachmodell hatte beim Verarbeiten der Frage die Einschränkung auf die Distanz fallen gelassen — und der Antwort war dieser Bedeutungsverlust nicht anzusehen. Gerechnet wurde in beiden Fällen korrekt.
Genau dieses Spannungsfeld untersucht meine Bachelor Thesis: Grosse Sprachmodelle verstehen Fragen in Alltagssprache erstaunlich gut — aber darf man den Zahlen trauen, die am Ende herauskommen?
Viele Daten, schwerer Zugang
Praxispartner der Arbeit sind Force8, der Anbieter der gleichnamigen Datenplattform, und der Schweizer Schiesssportverband Swiss Shooting, der die Plattform nutzt. Dort fallen laufend strukturierte Daten an: Trainingsbelastungen, Wettkampfresultate bis zum einzelnen Schuss, dazu tägliche Werte wie Schlaf oder wahrgenommene Anstrengung. Für die Trainingssteuerung wären diese Daten wertvoll — der Zugang läuft aber über Dashboards und Exporte. Die Leitfrage der Arbeit: Kann eine Trainerin einfach fragen, «Wie viele offizielle Wettkampfschüsse hatte diese Athletin dieses Jahr bisher?», und sich auf die Antwort verlassen?
Warum das Sprachmodell nicht rechnen darf
Der naheliegende Weg wäre, dem Sprachmodell die Daten zu geben und es antworten zu lassen. Ein Kontrollexperiment der Arbeit zeigt, warum das keine gute Idee ist: Erhält das Modell die fertig gefilterte Datentabelle und soll die Zielzahl selbst berechnen, trifft es sie in keinem von 15 Vergleichsläufen — es liefert plausibel aussehende, aber falsche Werte. Leitet es dagegen nur die Rechenregel ab und überlässt das Rechnen dem Programmcode, stimmt das Ergebnis in allen zehn Läufen.
Daraus folgt das Kernprinzip des entwickelten Systems, des «Data-Butlers»: die strikte Trennung von Interpretation und Ausführung. Das Sprachmodell interpretiert die Frage genau einmal und übersetzt sie in einen strukturierten Auftrag — den Request Contract mit Personen, Kennzahl, Zeitraum und Filtern. Alles Weitere erledigt deterministischer Code: Quellenwahl, Datenzugriffe, Verknüpfungen, Zählung, Validierung. Das Modell erzeugt, berechnet oder verändert keine Datenwerte.
Echte Personendaten brauchen Regeln im Code
Weil es um reale Athletinnen und Athleten geht, regelt eine zentrale Policy im Code — nicht eine Bitte im Prompt — wie viel Datenkontext ein Modellaufruf überhaupt sehen darf. Der Hintergrund ist Datenschutz: Modellaufrufe gehen an einen externen Anbieter, und dorthin soll so wenig wie möglich von den echten Daten fliessen. Vier abgestufte Zugriffsstufen reichen vom reinen Fragetext bis zu einzelnen Datenzeilen; die zeilengenaue Stufe öffnet sich im Standardmodus erst nach ausdrücklicher Zustimmung der Nutzerin.
Belegen statt behaupten
Ob die Trennung hält, wurde gemessen statt versprochen. In zwei Messkampagnen liefen 371 Durchläufe gegen die produktive Live-API, jede Frage mehrfach wiederholt. Das Muster über alle Wiederholungen: Unterschiede entstehen nur in der sprachlichen Interpretation — welche Lesart einer mehrdeutigen Frage das Modell wählt, ob es zurückfragt — und nie im Rechnen. Den härtesten Beleg liefert ein Replay-Verfahren: Zwölf aufgezeichnete Fälle wurden je zwölfmal offline abgespielt, mit eingefrorenen Aufträgen und Datenantworten. Die Ergebnisse waren über alle Wiederholungen byte-identisch. Das heisst: Ab dem fertigen Auftrag ist der Rechenweg deterministisch — gleiche Eingaben liefern nachweislich dasselbe Ergebnis.
Die ehrliche Grenze
Die Trennung beseitigt die Unsicherheit nicht — sie verschiebt sie an eine prüfbare Stelle. Der Datenpfad garantiert, dass genau das berechnet wird, was im Auftrag steht. Ob der Auftrag die Frage richtig erfasst hat, garantiert er nicht: Das ist der Fall «richtig für den falschen Auftrag», und die 46-oder-770-Frage vom Anfang ist sein Musterbeispiel. Als Gegenmittel fragt das System bei unklaren Eingaben nach, statt zu raten — eine Frage ohne Zeitraum, mit ungültigem Datum oder unbekannter Person endet in einer Rückfrage, nicht in einer erfundenen Zahl.
Was bleibt
Die Arbeit zeigt, dass sich Sprachverständnis und verlässliches Rechnen verbinden lassen, wenn die Architektur die Rollen sauber trennt: Das Modell darf interpretieren, die Zahlen kommen aus prüfbarem Code. Das trägt auch über mehrere Gesprächsschritte.
Bleibt die Frage der Übertragbarkeit: Wie viel Aufwand kostet eine neue Datenquelle? Gut dokumentierte Quellen liessen sich über reine Konfiguration anbinden — bei zwei öffentlichen Demo-Schnittstellen ohne eine Zeile quellenspezifischen Code —, während die gewachsene reale Plattform einen eigens kuratierten Adapter brauchte. Diese Spannung zwischen Verlässlichkeit und Übertragbarkeit sauber auszuloten war am Ende der spannendste Teil der Arbeit: Je mehr fachliches Wissen fest im Code steht, desto verlässlicher wird das System — und desto mehr Arbeit steckt in jeder neuen Quelle.
Der zentrale Beitrag liegt deshalb nicht in der Behauptung, ein Sprachmodell vollständig kontrollierbar gemacht zu haben. Er liegt in einer Architektur, die seine Unsicherheit dort sichtbar macht, wo sie entsteht — und die Berechnung der Zahlen davon trennt.