Wenn das Sprachmodell nicht entscheiden darf

Sobald eine Regel verbindlich ist, sollte deshalb genau geprüft werden, ob sie überhaupt in ein Sprachmodell gehört. Sprache darf variabel sein. Geschäftslogik sollte es in vielen Fällen nicht sein.

Variabilität ist nur dort ein Vorteil, wo sie erwünscht ist

Sprachmodelle erzeugen Antworten probabilistisch. Das ist hilfreich, wenn mehrere Formulierungen möglich sind oder Inhalte an einen Nutzer angepasst werden sollen. Bei festen Regeln kann dieselbe Eigenschaft zum Problem werden.

Eine Rabattregel soll nicht davon abhängen, wie eine Anfrage formuliert wurde. Eine Frist sollte nicht anders berechnet werden, weil sich der Kontext leicht verändert hat. Solche Regeln lassen sich in deterministischem Code eindeutig abbilden und mit festen Testfällen prüfen.

Diese Trennung ist praktisch, weil das Sprachmodell weiterhin dort eingesetzt wird, wo seine Stärke liegt, ohne dass es die verbindliche Entscheidung selbst treffen muss.

In einer Lernanwendung lässt sich die Grenze gut zeigen

In einer Lern-App kann die Anwendung fest programmieren, welcher Schritt als Nächstes folgt, welche Regeln für eine Aufgabe gelten und wann eine Antwort als richtig gewertet wird. Das Sprachmodell übernimmt dann einen begrenzten Auftrag: Es kann eine Erklärung formulieren, ein zusätzliches Beispiel liefern oder eine Hilfestellung verständlicher machen.

Der Lernweg bleibt damit reproduzierbar, während die Kommunikation flexibel sein darf. Dasselbe Prinzip lässt sich auf andere Anwendungen übertragen. Preise, Fristen, Eskalationen, Freigaben oder Berechtigungen lassen sich fest im System abbilden; das Modell kann anschließend erklären, was passiert ist und warum.

Ein guter Prompt ersetzt keine feste Regel

Je mehr Geschäftslogik in einem Prompt steckt, desto schwieriger wird das System zu testen. Dann muss nicht mehr nur eine Regel geprüft werden, sondern gleichzeitig auch Prompt, Kontext, Modellverhalten und Formulierung. Schon eine Änderung am Modell oder an der Eingabe kann beeinflussen, wie eine Regel interpretiert wird.

Bei deterministischem Code ist die Prüfung deutlich einfacher: Für eine bekannte Eingabe gibt es ein erwartetes Ergebnis. Das ist besonders dort wichtig, wo ein Fehler eine konkrete Folge auslöst, etwa bei einem Preis, einer Freigabe oder einem Statuswechsel.

Das Sprachmodell kann die Entscheidung erklären, ohne die Entscheidung selbst zu berechnen. Diese Trennung macht Systeme meist leichter testbar und ihr Verhalten im Betrieb besser nachvollziehbar.

Auch Datentrennung sollte nicht nur von einem Modell oder Filter abhängen

Ein ähnliches Architekturprinzip gilt bei Multi-Tenant-Systemen. Wenn mehrere Organisationen dieselbe Plattform nutzen, sollte die Trennung ihrer Daten möglichst tief im System verankert sein. Sie sollte nicht allein darauf beruhen, dass die Oberfläche oder ein einzelner Anwendungsschritt immer den richtigen Filter setzt.

Eine zusätzliche Grenze auf Datenbankebene reduziert die Abhängigkeit von einzelnen Teilen der Anwendung. Selbst wenn an einer Stelle ein Fehler entsteht, bleibt eine weitere technische Trennung bestehen.

Das ist für Bildungsträger ebenso relevant wie für Verwaltungen, Verbände oder andere Plattformen, auf denen mehrere Organisationen mit demselben System arbeiten.

Das Modell sollte nur Aufgaben übernehmen, die zu ihm passen

Bei Anwendungen mit Sprachmodellen entsteht schnell der Wunsch, möglichst viele Schritte „intelligent“ zu machen. Für die Architektur ist es sinnvoller, die Aufgaben nach ihren Anforderungen zu trennen.

Gut geeignet für Sprachmodelle sind unter anderem:

• unstrukturierte Eingaben verstehen
• Texte zusammenfassen
• Erklärungen formulieren
• Inhalte an einen Nutzer anpassen

Besser in normalem Code aufgehoben sind häufig:

• Berechnungen
• feste Prüfregeln
• Berechtigungen
• Statuswechsel und verbindliche Prozesslogik

Das Ergebnis ist kein weniger intelligentes System. Es nutzt lediglich unterschiedliche Werkzeuge für unterschiedliche Aufgaben und hält jene Teile deterministisch, bei denen Vorhersehbarkeit wichtiger ist als sprachliche Flexibilität.

Häufige Fragen

Welche Aufgaben sollte ein Sprachmodell in meiner Anwendung übernehmen?

Aufgaben, bei denen sprachliche Flexibilität hilft, etwa unstrukturierte Eingaben verstehen, Texte zusammenfassen oder Erklärungen formulieren. Verbindliche Entscheidungen wie Preise, Fristen oder Berechtigungen gehören in normalen Code.

Kann ich Geschäftsregeln einfach in den Prompt schreiben?

Das ist möglich, macht das System aber schwer testbar. Das Ergebnis hängt dann auch von Formulierung, Kontext und Modellversion ab. In deterministischem Code führt dieselbe Eingabe immer zum selben Ergebnis und lässt sich mit festen Testfällen prüfen.

Wie werden die Daten mehrerer Organisationen auf einer Plattform getrennt?

Die Trennung sollte möglichst tief im System verankert sein, zusätzlich auf Datenbankebene. Dann bleibt sie auch bestehen, wenn an einer Stelle der Anwendung ein Filter fehlt.

Du möchtest wissen, welche Teile deiner Anwendung ein Sprachmodell übernehmen kann und welche fest programmiert sein sollten? Wir gehen das mit dir an deinem konkreten Ablauf durch. Sprich mit uns.