LLM-Coding-Experiment: Personalkostenkalkulator mit hybrider Architektur#

Zusammenfassung#

Dieses Experiment untersuchte die Machbarkeit eines Tools zur Personalkostenkalkulation, das natürlichsprachliche Eingaben mit präzisen Berechnungen verbindet. Die zentrale Frage: Wie lassen sich LLMs sinnvoll einsetzen, wenn exakte Zahlen gefordert sind? Die entwickelte Lösung demonstriert eine hybride Architektur, bei der das LLM ausschließlich für die Parameterextraktion zuständig ist, während sämtliche Berechnungen deterministisch erfolgen. Das Experiment liefert übertragbare Erkenntnisse zur Verbindung von Sprachverarbeitung und klassischer Programmierung.

1. Ausgangslage und Motivation#

1.1 Der Anlass#

Eine Anfrage aus einem Fachbereich der Humboldt-Universität Berlin gab den Anstoß: Die manuelle Kalkulation von Personalkosten für Drittmittelprojekte erwies sich als zeitaufwändig und fehleranfällig. Mehrere Kalkulationsgrundlagen, manuelle Eingabefehler bei Stellenanteilen und Tarifsteigerungen sowie die Notwendigkeit, Jahresscheiben korrekt zu berechnen, machten den Prozess komplex.

Die Frage war: Lässt sich ein Tool entwickeln, das diese Berechnungen automatisiert und dabei natürlichsprachliche Eingaben akzeptiert?

1.2 Die Herausforderung#

LLMs und präzise Berechnungen gelten als problematische Kombination. Sprachmodelle neigen zu Approximationen und können bei mathematischen Operationen unzuverlässig sein. Gleichzeitig bieten sie erhebliche Vorteile bei der Interpretation unstrukturierter Eingaben.

Das Experiment sollte erkunden, ob und wie sich beide Welten verbinden lassen – nicht durch Kompromisse bei der Genauigkeit, sondern durch eine Architektur, die die Stärken beider Ansätze gezielt nutzt.

1.3 Anforderungserfassung#

Vor der eigentlichen Entwicklung wurde ein systematischer Anforderungsprozess durchgeführt. Ein speziell entwickelter Prompt führte den Fachbereich durch strukturierte Fragen zu Problemverständnis, Funktionsanforderungen, Anwendungsfällen und technischen Rahmenbedingungen.

Die erfassten Kernanforderungen:

• Kalkulationen für alle TV-L-Entgeltgruppen (E9-E15, SHK)
• Berücksichtigung von Stellenanteilen, Stufenaufstiegen und Tarifsteigerungen
• Ausgabe in Jahresscheiben mit Excel-Export
• Genauigkeitsanforderung: Abweichung unter 3% (tatsächlich erreicht: exakte Übereinstimmung)
• Primäre Nutzergruppe: Forschungsreferent:innen und Sachbearbeiter:innen

2. Das Tool im Überblick#

2.1 Funktionsweise#

Der Personalkostenkalkulator ermöglicht die Eingabe von Projektanforderungen in natürlicher Sprache:

“Wir brauchen 2 Doktoranden E13/2 auf 67% und einen PostDoc E14/4, Laufzeit April 2026 bis März 2029”

Das System verarbeitet diese Eingabe in mehreren Schritten:

1. Parameterextraktion: Ein lokales LLM analysiert die Eingabe und extrahiert strukturierte Parameter – Entgeltgruppen, Stufen, Stellenanteile, Zeiträume, Anzahl der Stellen.

2. Validierung: Die extrahierten Parameter werden gegen definierte Schemas validiert (gültige Entgeltgruppen, plausible Zeiträume, korrekte Stufenbereiche).

3. Rückfragen: Bei fehlenden oder unklaren Angaben generiert das System gezielte Nachfragen.

4. Berechnung: Die deterministische Berechnungskomponente kalkuliert Monatskosten, Jahresscheiben, Tarifsteigerungen und Stufenaufstiege.

5. Ausgabe: Das Ergebnis wird als strukturierte Tabelle mit Zusammenfassung angezeigt und kann als Excel-Datei exportiert werden.

2.2 Unterstützte Eingabeformate#

Das System interpretiert verschiedene sprachliche Formulierungen:

2.3 Berechnungsgrundlagen#

Die Kalkulation basiert auf:

• TV-L 2025 Entgelttabelle (Tarifgebiet Ost)
• Arbeitgeber-Brutto-Faktor: 1,2849 (28,49% AG-Anteile)
• Zuwendungssätze: 74,35% (E9-E11), 46,47% (E12-E13), 32,53% (E14-E15)
• Tarifsteigerung: 3% jährlich ab 2026
• SHK-Stundensatz 2025: 14,32 €

3. Technische Architektur#

3.1 Die zentrale Designentscheidung#

Die Architektur basiert auf einer strikten Trennung: Das LLM ist ausschließlich für die Sprachverarbeitung zuständig, sämtliche Berechnungen erfolgen deterministisch ohne LLM-Beteiligung.

Diese Entscheidung fiel während der Spezifikationsphase. Erste Überlegungen, das LLM auch für Berechnungen einzusetzen, wurden verworfen – die Anforderung an exakte Ergebnisse war nicht verhandelbar.

3.2 Komponentenstruktur#

personalkostenkalkulator/
├── app.py                    # Gradio Web-Anwendung
├── config/                   # Statische Konfiguration
│   ├── entgelttabelle.py     # TV-L 2025 Entgelte
│   ├── zuwendungen.py        # Jahressonderzahlung
│   ├── arbeitgeber.py        # AG-Anteile
│   ├── shk.py                # SHK-Stundensätze
│   └── settings.py           # Anwendungseinstellungen
├── parser/                   # LLM-Integration
│   ├── llm_client.py         # API-Anbindung
│   ├── prompt_templates.py   # System-Prompts
│   ├── extractor.py          # Parameterextraktion
│   └── validator.py          # Pydantic-Modelle
├── calculator/               # Deterministische Berechnung
│   ├── core.py               # Hauptberechnungslogik
│   ├── zeitraum.py           # Monats-/Jahresberechnungen
│   └── stufenaufstieg.py     # Aufstiegslogik
├── session/                  # Dialogsteuerung
│   ├── manager.py            # Session-Verwaltung
│   └── state.py              # State Machine
├── output/                   # Ausgabegenerierung
│   ├── tables.py             # Tabellenformatierung
│   ├── summary.py            # Zusammenfassungen
│   └── excel_export.py       # Excel-Export
└── tools/
    └── excel_importer.py     # Tarifdaten-Import

3.3 Datenfluss#

Der Datenfluss illustriert die Trennung der Verantwortlichkeiten:

1. Nutzereingabe (natürliche Sprache) →
2. LLM-Parser (extrahiert JSON mit Parametern) →
3. Pydantic-Validierung (typsichere Prüfung) →
4. Calculator (deterministische Berechnung mit Decimal) →
5. Output-Generator (Formatierung, Excel-Export)

Das LLM hat keinen Zugriff auf die Berechnungslogik oder die Tarifdaten. Es liefert ausschließlich strukturierte Parameter, die dann von klassischem Code verarbeitet werden.

3.4 State Machine für Dialogführung#

Die Dialogsteuerung erfolgt über eine State Machine mit definierten Zuständen:

• INITIAL: Warte auf erste Eingabe
• PARSING: LLM analysiert Eingabe
• CLARIFYING: Rückfragen werden gestellt
• CALCULATING: Berechnung läuft
• COMPLETE: Ergebnis bereit
• FALLBACK: Manuelles Formular aktiv
• ERROR: Fehler aufgetreten

Die State Machine stellt sicher, dass der Dialog konsistent bleibt und definierte Übergänge einhält.

3.5 Fallback-Mechanismus#

Von Beginn an war ein Fallback-Mechanismus eingeplant: Nach drei fehlgeschlagenen Parse-Versuchen wird automatisch ein manuelles Eingabeformular eingeblendet. Bereits erfolgreich geparste Parameter werden vorausgefüllt.

Diese Entscheidung reflektierte die Unsicherheit über die Zuverlässigkeit der LLM-Extraktion. In der Praxis erwies sich das Parsing als robust, der Fallback bietet dennoch eine wichtige Absicherung.

3.6 Technologie-Stack#

• Frontend: Gradio (gewählt aufgrund vorhandener Erfahrung)
• Backend: Python 3.10+
• LLM: Lokales Modell mit OpenAI-kompatibler API
• Validierung: Pydantic für typsichere Datenmodelle
• Berechnung: Python Decimal für exakte Arithmetik
• Export: openpyxl für Excel-Generierung

4. Entwicklungsprozess#

4.1 Phasenmodell#

Der Entwicklungsprozess folgte einem klaren Phasenmodell:

Phase 1: Anforderungserfassung (vorgelagert) Ein speziell entwickelter Prompt führte den Fachbereich durch strukturierte Fragen. Das Ergebnis war eine detaillierte Beschreibung von Problemstellung, Anforderungen und Rahmenbedingungen.

Phase 2: Spezifikationsdiskussion (50 Minuten) Intensive Abstimmung aller Aspekte der Lösung:

• Architekturentscheidung (hybride Trennung LLM/Berechnung)
• Datenflüsse und Schnittstellen
• Workflows und Zustandsübergänge
• UI-Konzept und Fallback-Strategie

Der Fokus lag bewusst auf der Architektur, nicht auf der Umsetzung. Overengineering wurde verhindert, indem jede Komponente gegen die tatsächlichen Anforderungen geprüft wurde.

Phase 3: Spezifikation Die vollständige technische Spezifikation umfasste:

• Funktionale Anforderungen mit Beispielen
• Datenmodelle und Validierungsregeln
• System-Prompts für das LLM
• Berechnungsformeln und Konfigurationsdaten
• Komponentenstruktur und Schnittstellen

Phase 4: Umsetzung (ca. 40 Minuten) Das LLM generierte den gesamten Code in einer Runde. Die Qualität der Spezifikation ermöglichte diese effiziente Umsetzung.

Phase 5: Nachbesserung Eine Iteration war erforderlich, um Detailanpassungen vorzunehmen.

4.2 Zeitaufwand#

4.3 Ergebnis#

Das Resultat: 5700 Zeilen Code in 29 Python-Dateien, ein funktionsfähiges Tool mit Web-Interface, Dialogführung, deterministischer Berechnung und Excel-Export.

5. Methodische Erkenntnisse#

5.1 Spezifikation als Erfolgsfaktor#

Die wichtigste Erkenntnis: Die Qualität der Spezifikation bestimmt den Erfolg der LLM-gestützten Entwicklung. Eine gründliche Vorarbeit – Architektur, Datenflüsse, Workflows, UI – muss abgeschlossen sein, bevor Code generiert wird.

Die 50 Minuten Spezifikationsdiskussion ermöglichten die 40-minütige Umsetzung. Ohne diese Vorarbeit wären multiple Iterationen und Umbauten erforderlich gewesen.

Konkrete Aspekte der Spezifikation:

• Klare Komponentengrenzen und Verantwortlichkeiten
• Definierte Schnittstellen zwischen Modulen
• Explizite Datenmodelle mit Validierungsregeln
• Beispiele für Ein- und Ausgaben
• Festgelegte Fehlerbehandlung und Fallback-Strategien

5.2 Hybride Architektur als Pattern#

Das Experiment etabliert ein übertragbares Architektur-Pattern: LLM als intelligente Schnittstelle zu klassischem Code.

Nicht alles muss vom LLM erledigt werden. Für viele Aufgaben – insbesondere präzise Berechnungen – bleiben klassische Programmiertechniken überlegen. Das LLM fungiert als Brücke zwischen unstrukturierter menschlicher Eingabe und strukturierter maschineller Verarbeitung.

Dieses Pattern eignet sich für Anwendungen mit folgenden Charakteristiken:

• Flexible, natürlichsprachliche Eingabe gewünscht
• Exakte, reproduzierbare Ergebnisse erforderlich
• Klar definierte Berechnungslogik vorhanden
• Domänenspezifisches Vokabular zu interpretieren

5.3 JSON als Schnittstellenformat#

Die strukturierte Ausgabe des LLM als JSON mit anschließender Pydantic-Validierung erwies sich als robuste Lösung. Das LLM generiert ausschließlich Datenstrukturen, keine Berechnungen oder Logik.

Vorteile dieses Ansatzes:

• Klare Vertragsdefinition zwischen LLM und Backend
• Typsichere Validierung vor Verarbeitung
• Einfache Fehlerbehandlung bei ungültigem Output
• Testbarkeit der Komponenten unabhängig voneinander

5.4 Robustheit durch Fallback#

Der von Anfang an eingeplante Fallback-Mechanismus reflektiert eine wichtige Erkenntnis: Bei ungewisser LLM-Zuverlässigkeit sind alternative Eingabewege erforderlich.

Das manuelle Formular ist keine Notlösung, sondern integraler Bestandteil des Konzepts. Es stellt sicher, dass das Tool auch bei LLM-Ausfällen oder schwierigen Eingaben nutzbar bleibt.

5.5 Grenzen der LLM-Nutzung#

Das Experiment machte Grenzen sichtbar:

• Berechnungen: LLMs sind für exakte Arithmetik ungeeignet – die strikte Trennung war notwendig.
• JSON-Extraktion: Die zuverlässige Generierung valider JSON-Strukturen erfordert präzise Prompts und Nachverarbeitung.
• Konsistenz: Das LLM muss konsistent entweder vollständige Parameter oder sinnvolle Rückfragen liefern – dies erforderte sorgfältiges Prompt-Design.

6. Validierung und Status#

6.1 Aktueller Stand#

Das Tool ist funktionsfähig und befindet sich in der Evaluationsphase. Erste Tests zeigen, dass die Anwendung wie geplant funktioniert:

• Parameterextraktion arbeitet zuverlässig
• Berechnungen stimmen mit Referenzwerten überein
• Dialogführung verhält sich konsistent
• Fallback-Mechanismus ist einsatzbereit, wurde aber selten benötigt

6.2 Validierungsansatz#

Die Validierung erfolgt durch:

• Vergleich mit manuellen Excel-Berechnungen
• Testfälle gegen Referenzwerte aus der offiziellen Tarifdaten-Excel
• Nutzertests mit dem Fachbereich

6.3 Ausblick#

Die Frage, ob LLMs und exakte Berechnungen zusammenpassen, lässt sich differenziert beantworten: Ja – wenn die Architektur die Stärken beider Welten gezielt kombiniert und ihre jeweiligen Grenzen respektiert.

Das Experiment ist Teil einer Reihe von Untersuchungen zur Verbindung von LLMs und numerischen Anwendungen. Weitere Experimente (u.a. zu Diagramm- und Chart-Generierung) erkunden zusätzliche Ansätze.

7. Metriken#

8. Fazit#

Das Experiment demonstriert, dass LLM-gestützte Entwicklung auch für Anwendungen mit hohen Genauigkeitsanforderungen geeignet ist – vorausgesetzt, die Architektur respektiert die Grenzen der Technologie.

Die zentralen Erfolgsfaktoren:

1. Gründliche Spezifikation vor der Implementierung
2. Hybride Architektur mit klarer Aufgabentrennung
3. LLM als Schnittstelle, nicht als Universallösung
4. Robustheit durch Fallback-Mechanismen
5. Fokus auf Architektur statt vorschneller Umsetzung

Das resultierende Tool löst ein reales Problem effizient und demonstriert gleichzeitig ein übertragbares Pattern für ähnliche Anwendungsfälle.

Dieser Beitrag ist Teil einer Serie zur Dokumentation methodischer Erkenntnisse aus LLM-gestützten Entwicklungsprojekten.