Zum Inhalt springen
Kontakt

Algorithmen · Sprachmodelle · Hybride Systeme

Algorithmus oder Sprachmodell? Beides, jedes an seinem Platz.

Ein Algorithmus liefert zur gleichen Eingabe jedes Mal dasselbe Ergebnis. Ein Sprachmodell berechnet eine Verteilung über mögliche Fortsetzungen, und seine Antwort wird daraus gezogen. elsyQ baut Systeme, in denen das Modell liest und ein deterministischer Teil prüft und rechnet.

Farbcode dieser Seite

  • Deterministisch Algorithmus oder Regel: gleiche Eingabe, gleiches Ergebnis.
  • Probabilistisch Ausgabe eines Sprachmodells oder anderen Modells: ein Vorschlag.
Projekt besprechen Zum Experiment

Gleiche Eingabe, fünf Läufe

Eingabe Angebot mit 12 Positionen, gesucht ist die Summe

Positionen ansehen
  1. 1.249,00 €
  2. 386,50 €
  3. 72,90 €
  4. 918,00 €
  5. 45,60 €
  6. 212,40 €
  7. 1.030,00 €
  8. 64,80 €
  9. 157,20 €
  10. 289,00 €
  11. 118,60 €
  12. 268,40 €
Algorithmus Summe der Positionen, in Cent gerechnet
Lauf Ergebnis
1 4.812,40 € b2f4a58f
2 4.812,40 € b2f4a58f
3 4.812,40 € b2f4a58f
4 4.812,40 € b2f4a58f
5 4.812,40 € b2f4a58f
Sprachmodell Summe als Textfortsetzung, T = 1,0
Lauf Ergebnis
1 4.812,40 € gleich b2f4a58f
2 4.812,04 € gleich 4baa7475
3 4.812,40 € gleich b2f4a58f
4 4.812,00 € gleich 2a64497a
5 4.812,40 € gleich b2f4a58f

Gleiches Ergebnis wie der Algorithmus: 3 von 5 Läufen

Unter jeder Summe steht ein Fingerabdruck: die ersten acht Hex-Ziffern von SHA-256 über das Ergebnis in der Form „4812.40 EUR“.

Eine Illustration, keine Messung. Die Werte des Sprachmodells werden aus derselben Verteilung gezogen, die das Temperatur-Experiment weiter unten zeigt.

Der Unterschied

Von außen sehen beide gleich aus: Text oder Zahlen hinein, ein Ergebnis heraus. Innen arbeiten sie grundverschieden. Ein Algorithmus führt feste Rechenschritte aus. Ein Sprachmodell bewertet mögliche Fortsetzungen, und eine davon wird gezogen. Davon hängt ab, was sich testen und nachrechnen lässt.

deterministisch

Algorithmus

Ein Algorithmus ist eine feste Folge von Rechenschritten. Jeder Schritt hängt nur von der Eingabe und den Schritten davor ab, Zufall spielt keine Rolle. So arbeiten Sortieren und Summieren, ein Newton-Verfahren oder ein Schaltungssolver.

y=f⁡(x)

Das Ergebnis y ist eine Funktion der Eingabe x. Es hängt von nichts anderem ab.

x1=x2⇒f⁡(x1)=f⁡(x2)

Gleiche Eingaben, gleiche Ausgaben. Darauf bauen Tests auf, ebenso das Nachrechnen eines Ergebnisses und jedes Audit.

  • Reproduzierbar
  • Testbar gegen Spezifikation
  • Jeder Schritt nachvollziehbar
probabilistisch

Sprachmodell

Das Netz berechnet für jedes mögliche nächste Token eine Bewertung, den Logit. Diese Rechnung ist deterministisch, bis auf Effekte der Gleitkommarechnung. Zufall kommt erst ins Spiel, wenn aus diesen Bewertungen ein Token gezogen wird.

P(y|x)=∏t=1mP(yt|y<t,x)

Eine Antwort aus m Tokens entsteht Token für Token. Ihre Wahrscheinlichkeit ist das Produkt der bedingten Wahrscheinlichkeiten aller Schritte.

pi=ezi/T∑jezj/T

Softmax macht aus den Logits eine Verteilung, deren Werte sich zu eins addieren. Die Temperatur T verändert ihre Form: T > 1 macht sie flacher, T < 1 spitzer.

yt=argmaxi⁡pi

Greedy Decoding nimmt in jedem Schritt das wahrscheinlichste Token. Das ist der Grenzfall T → 0.

  • Verarbeitet freien Text
  • Kann von Lauf zu Lauf streuen
  • Richtigkeit nur statistisch messbar

Temperatur-Experiment

Das Modell soll die Summe von oben fortsetzen, es fehlen nur noch die Cent. Fünf Kandidaten stehen zur Wahl. Verschieben Sie die Temperatur und ziehen Sie Tokens.

Eingabe Summe: 4.812,

Kandidaten für das nächste Token

  1. 40 63,81 % Logit 3,2 richtig
  2. 04 17,39 % Logit 1,9
  3. 00 10,55 % Logit 1,4
  4. 14 4,74 % Logit 0,6
  5. 41 3,51 % Logit 0,3

Bei T = 1,0 bekommt „40“ 63,81 % der Wahrscheinlichkeit. Der Rest verteilt sich auf falsche Cent-Beträge.

Bei T = 0,1 liegt fast alles beim wahrscheinlichsten Token. Greedy Decoding (argmax) ist der Grenzfall T → 0 und nur so richtig wie dieses Token. Hier stimmt es, weil das Beispiel so gebaut ist.

Die Logits sind für dieses Beispiel gewählt, nicht an einem Modell gemessen. Die Rechnung dahinter ist echt: Softmax mit Temperatur, dann Ziehen nach Gewicht.

Fehler multiplizieren sich

Bei 95 % pro Schritt sind 10 Schritte nur in rund 60 % der Fälle alle richtig.

Ein Ablauf besteht selten aus einem Schritt. Bleibt irgendwo in der Kette ein Fehler unbemerkt, ist das Endergebnis falsch. Ohne Prüfung multiplizieren sich die Trefferquoten. Mit einer deterministischen Prüfung nach jedem Schritt rutscht ein Fehler nur durch, wenn Modell und Prüfung beide versagen.

Ohne Prüfung

Rn=∏k=1npk=pn

Die Kette stimmt nur, wenn alle n Schritte stimmen. Bei unabhängigen Schritten mit derselben Trefferquote p ergibt das Produkt p hoch n.

R10=0,9510≈0,599

Mit p = 0,95 und n = 10 bleiben rund 60 % der Durchläufe fehlerfrei. Im Rest steckt irgendwo ein Fehler, und niemand hat ihn bemerkt.

Mit deterministischer Prüfung

q=(1−p)⁢(1−d)

Ein Schritt geht mit der Wahrscheinlichkeit q unbemerkt schief: Er ist falsch, und die Prüfung übersieht es. Von allen falschen Ergebnissen fängt die Prüfung den Anteil d ab.

Sn=1−(1−q)n

Daraus folgt die Wahrscheinlichkeit, dass in n Schritten mindestens ein Fehler unbemerkt durchgeht.

S10=1−0,999510≈0,0050

Mit p = 0,95 und d = 0,99 ist q = 0,0005. Über 10 Schritte geht in 0,50 % der Durchläufe ein Fehler unbemerkt durch, in 99,50 % nicht. Erkannte Fehler gehen zurück an das Modell oder an einen Menschen.

Annahmen: unabhängige Schritte, ein geprüfter Versuch pro Schritt. Jeder weitere Versuch trägt wieder das Risiko q, auch einer, den eine zu strenge Prüfung ausgelöst hat. In echten Systemen misst man p und d an einem Testsatz.

Kette aus n Schritten

Jede Linie zeigt die Wahrscheinlichkeit, dass kein Fehler unbemerkt durchgeht. Ohne Prüfung (d = 0) ist das genau p hoch n. Die Linie mit Prüfung zählt erkannte Fehler als wiederholt oder eskaliert, nicht als Ausfall.

Ohne Prüfung, p = 0,99
n Kette stimmt
1 99,00 %
5 95,10 %
10 90,44 %
20 81,79 %
30 73,97 %
Ohne Prüfung, p = 0,95
n Kette stimmt
1 95,00 %
5 77,38 %
10 59,87 %
20 35,85 %
30 21,46 %
Ohne Prüfung, p = 0,90
n Kette stimmt
1 90,00 %
5 59,05 %
10 34,87 %
20 12,16 %
30 4,24 %
Mit Prüfung, p = 0,95, d = 0,99
n Kein stiller Fehler
1 99,95 %
5 99,75 %
10 99,50 %
20 99,00 %
30 98,51 %

Die hybride Architektur

Das Modell liest. Der Algorithmus prüft und rechnet.

Das Muster passt auf jeden Ablauf, der sich klar beschreiben lässt und heute viel Handarbeit kostet, in jeder Branche. Unser Beispiel ist eine Angebotsprüfung. Ein Sprachmodell liest das Angebot, weil es mit freiem Text umgehen kann. Alles danach ist gewöhnlicher Code, den man testen kann.

Ablauf einer Angebotsprüfung

  1. Eingang

    E-Mail mit einem Angebot als PDF.

  2. Sprachmodell

    Liest Positionen und Preise in ein festes Schema. Lokal oder gehostet.

  3. Prüfung

    Prüft die Ausgabe gegen feste Regeln, etwa Summen und Einheiten.

    Fehler gehen mit Begründung an das Modell zurück. Höchstens 3 Versuche.

    Nach 3 erfolglosen Versuchen entscheidet ein Mensch.

  4. Berechnung

    Rechnet Preis, Rabatt und Steuer nach festen Regeln.

  5. Ergebnis

    Geprüftes Angebot mit Protokoll jedes Schritts.

Der Kern in Pseudocode

fn quote(mut input: Input) -> Result<Price, Escalation> {for attempt in 1..=3 {let draft = llm.extract(&input, &SCHEMA)?;match rules.check(&draft) {Ok(valid) => return Ok(price(&valid)),Err(errors) => input.feedback(attempt, errors),}}Err(escalate(input))}
Nur der Aufruf llm.extract fragt das Modell (P). Alles andere ist gewöhnlicher, testbarer Code (D). Pseudocode im Stil von Rust.

Protokoll eines Durchlaufs

  1. E-Mail mit Angebot als PDF: 12 Positionen, im Dokument angegebene Summe 4.812,40 €
  2. Erster Versuch: Das Modell füllt das Schema mit 12 Positionen.
  3. Prüfung von Schema und Einheiten bestanden.
  4. Summenprüfung abgelehnt: Die Positionen ergeben 4.803,40 € statt 4.812,40 €, Differenz 9,00 €.
  5. Rückmeldung an das Modell: Die Positionen weichen um 9,00 € von der angegebenen Summe ab. Bitte erneut lesen.
  6. Zweiter Versuch: Die erste Position lautet jetzt 1.249,00 € statt 1.240,00 €.
  7. Summenprüfung bestanden: Die Positionen ergeben 4.812,40 €.
  8. Berechnung: 4.812,40 € zuzüglich 19 % Umsatzsteuer ergibt 5.726,76 €.
  9. Angebot freigegeben. Eingabe, Ausgabe und Modellversion sind protokolliert.
Ein nachgestellter Durchlauf zur Veranschaulichung, kein Kundenprojekt. Die Zahlen sind dieselben wie oben.

Dasselbe Prinzip in einem Schaltungssimulator: Circuit Forge

Reproduzierbar machen

Temperatur 0 allein reicht nicht.

Bei Temperatur 0 nimmt das Modell in jedem Schritt das wahrscheinlichste Token. Das ist Greedy Decoding, und in exakter Arithmetik ist es deterministisch: gleiche Eingabe, gleiche Antwort. Richtig wird die Antwort dadurch nicht, nur wiederholbar. Und ein Rechner arbeitet nicht mit exakter Arithmetik.

Gehostete Modelle laufen auf GPU-Servern, die Anfragen zu Batches bündeln. Größe und Zusammensetzung eines Batches hängen von der Serverlast ab, und viele Kernels addieren Gleitkommazahlen dann in anderer Reihenfolge. Die Logits können in den letzten Stellen abweichen. Liegen zwei Tokens fast gleichauf, kann die Wahl kippen, und der Text geht anders weiter.

Dazu kommt, dass Anbieter ihre Modelle weiterentwickeln. Ein Alias wie „latest“ zeigt irgendwann auf ein anderes Modell, und auch fest angegebene Versionen werden nach einer Ankündigungsfrist abgeschaltet. Wer ein Ergebnis später reproduzieren will, braucht mehr als einen Parameter.

(0.1 + 0.2) + 0.3
0.6000000000000001
0.1 + (0.2 + 0.3)
0.6

IEEE 754: Gleitkommaaddition ist nicht assoziativ. Beide Zeilen addieren dieselben drei Zahlen. Deshalb rechnet der Algorithmus oben in ganzen Cent.

Was wir dagegen tun

  • Version festhalten oder lokal betreiben

    Gehostet pinnen wir die Version. Lokal lässt sich ein Lauf wiederholbar machen, solange Gewichte, Software, Hardware und Batchgröße gleich sind. Der Wechsel zwischen lokal und OpenAI, Anthropic oder Mistral bleibt offen.

  • Greedy Decoding, wo möglich

    Wo Modell und Schnittstelle es zulassen, dekodieren wir greedy mit Temperatur 0. Das verringert die Streuung zwischen Läufen. Garantieren kann es nichts, wie oben beschrieben.

  • Strukturierte Ausgabe

    Das Modell antwortet gegen ein festes JSON-Schema. Das garantiert die Form der Antwort, also Felder und Typen. Ob die Werte darin stimmen, garantiert es nicht.

  • Deterministische Validierung

    Regeln prüfen jede Ausgabe: Summen, Einheiten, Wertebereiche, Abgleich mit Stammdaten. Was durchfällt, geht mit Begründung an das Modell zurück oder an einen Menschen.

  • Lückenloses Protokoll

    Zu jedem Lauf speichern wir Eingabe, Ausgabe, Modellversion, Prompt-Version und Parameter. So lässt sich jede Entscheidung später nachvollziehen, auch wenn das Modell längst ersetzt ist.

  • Fester Evaluationssatz

    Vor jedem Wechsel von Modell oder Prompt läuft ein fester Satz von Testfällen als Regressionstest. Jeder Fall läuft mehrmals, weil ein gehostetes Modell unterschiedlich antworten kann.

Wir versprechen nicht, dass ein gehostetes Modell zweimal dasselbe schreibt. Wir sorgen dafür, dass nichts ungeprüft in Ihr System gelangt.

Was wohin gehört

Die Tabelle zeigt, wie wir abwägen. Oft ist ein Algorithmus die bessere Wahl, und manchmal lautet die Antwort schlicht „kein Modell“. Wenn wir einen Ablauf nicht besser machen können, sagen wir das, bevor ein Projekt daraus wird.

Algorithmus

Gleiche Eingabe, gleiche Ausgabe
Ja, per Konstruktion
Unstrukturierter Text als Eingabe
Nur in festen Formaten wie CSV oder XML
Testbar gegen eine Spezifikation
Ja, Fall für Fall
Erklärbar gegenüber Prüfern
Jeder Schritt lässt sich zeigen
Kosten pro Aufruf
Rechenzeit auf eigener Hardware
Typische Aufgaben
Abrechnung, Regelung, Simulation, Solver

Sprachmodell

Gleiche Eingabe, gleiche Ausgabe
Nicht garantiert, auch nicht bei Temperatur 0
Unstrukturierter Text als Eingabe
Ja, das ist seine Stärke
Testbar gegen eine Spezifikation
Nur statistisch, über einen Evaluationssatz
Erklärbar gegenüber Prüfern
Kaum: Gewichte sind keine Begründung
Kosten pro Aufruf
Tokenpreis oder eigene GPU
Typische Aufgaben
Texte lesen, zuordnen, zusammenfassen

Hybrid

Gleiche Eingabe, gleiche Ausgabe
Prüfung und Berechnung ja, die Modellausgabe wird protokolliert
Unstrukturierter Text als Eingabe
Ja, das Modell liest, die Regeln prüfen
Testbar gegen eine Spezifikation
Regeln und Berechnung ja, das Modell statistisch
Erklärbar gegenüber Prüfern
Freigabe und Berechnung folgen Regeln, die man zeigen kann
Kosten pro Aufruf
Modellkosten für das Lesen plus Rechenzeit
Typische Aufgaben
Angebote, Bestellungen und Datenblätter prüfen

Drei Muster

Muster aus typischen Anfragen, keine Kundenprojekte.

  • Einkauf

    Angebote aus E-Mails vorprüfen

    Angebote kommen als PDF per E-Mail, jeder Lieferant mit eigenem Layout. Heute überträgt jemand die Positionen von Hand ins ERP und rechnet nach. Das System übernimmt die Vorarbeit und legt nur Abweichungen vor.

    Modell
    Ein Sprachmodell liest Positionen, Mengen und Preise aus dem PDF.
    Deterministisch
    Summen, Einheiten und Liefertermine werden geprüft und mit den Stammdaten abgeglichen.
  • Stammdaten

    Datenblätter digitalisieren

    Die Kennwerte von Bauteilen stecken in Datenblättern, und jeder Hersteller gliedert sie anders. Gebraucht werden sie als saubere Datensätze, etwa für die Bauteilauswahl, die Stückliste oder die Simulation.

    Modell
    Ein Sprachmodell liest Tabellen und Fließtext des Datenblatts.
    Deterministisch
    Einheiten werden umgerechnet, min ≤ typ ≤ max muss gelten, jeder Wert im Bereich seiner Bauteilklasse.
  • Simulation

    Schaltungssimulation beschleunigen

    Große Parameterstudien am Schaltungssimulator brauchen Zeit. Ein Surrogatmodell kann Varianten vorsortieren oder Startwerte vorschlagen, damit der Solver schneller konvergiert. Gerechnet wird weiter im Solver.

    Modell
    Ein trainiertes Surrogatmodell, kein Sprachmodell, schlägt Startwerte vor.
    Deterministisch
    Der Solver bleibt deterministisch. Konvergenz und Toleranz entscheiden, das Ergebnis kommt immer vom Solver.

Häufige Fragen

Was unterscheidet einen deterministischen Algorithmus von einem Sprachmodell?

elsyQ unterscheidet deterministische Algorithmen und Sprachmodelle danach, woher ein Ergebnis kommt: Der Algorithmus rechnet es in festen Schritten aus, beim Sprachmodell wird es aus einer Wahrscheinlichkeitsverteilung gezogen. Beim Algorithmus führt die gleiche Eingabe deshalb immer zum gleichen Ergebnis. Das Sprachmodell berechnet für jedes mögliche nächste Token eine Bewertung, den Logit, und auch das ist bis auf Gleitkommaeffekte deterministisch. Zufall kommt erst hinzu, wenn aus diesen Bewertungen ein Token gezogen wird. Deshalb kann dieselbe Frage verschiedene Antworten bekommen.

Gibt ein Sprachmodell bei Temperatur 0 immer dieselbe Antwort?

Ein gehostetes Sprachmodell kann auch bei Temperatur 0 unterschiedlich antworten, deshalb verlässt sich elsyQ nicht darauf. Temperatur 0 bedeutet Greedy Decoding, deterministisch nur in exakter Arithmetik. Der Server bündelt Anfragen zu Batches, deren Größe von der Last abhängt, und viele GPU-Kernels summieren dann in anderer Reihenfolge. Die Logits können in den letzten Stellen abweichen, und liegen zwei Tokens fast gleichauf, kann die Wahl kippen. Lokal lässt sich ein Lauf wiederholbar machen, solange Gewichte, Software, Hardware und Batchgröße gleich bleiben. Das kostet etwas Durchsatz.

Wann setzt elsyQ ein Sprachmodell ein und wann einen Algorithmus?

elsyQ setzt deterministische Algorithmen überall dort ein, wo das Ergebnis reproduzierbar sein muss, und ein Modell nur dort, wo es nachweisbar besser abschneidet. Preise und Steuern rechnet deshalb immer ein Algorithmus. Ein Sprachmodell kommt dazu, wenn die Eingabe aus freiem Text besteht, den keine feste Regel zuverlässig lesen kann, etwa ein Angebot als PDF oder eine formlose E-Mail. Ob das Modell gewinnt, zeigt ein Vergleich auf einem Testsatz, nicht der Eindruck aus einer Demo.

Was ist ein hybrides System aus Sprachmodell und Algorithmus?

Ein hybrides System, wie elsyQ es baut, teilt die Arbeit auf: Das Sprachmodell liest unstrukturierte Eingaben und schlägt ein strukturiertes Ergebnis vor, deterministischer Code prüft es und rechnet. Das Modell füllt ein festes Schema, zum Beispiel mit den Positionen eines Angebots. Regeln prüfen etwa Summen und Einheiten. Fällt ein Ergebnis durch, geht es mit Begründung an das Modell zurück, und nach einer festen Zahl von Versuchen entscheidet ein Mensch. Beträge und Steuern berechnet am Ende immer der Algorithmus, und jeder Schritt wird protokolliert.

Wie misst elsyQ, ob ein Modell gut genug ist?

elsyQ misst die Eignung eines Modells an einem festen Evaluationssatz aus echten oder realistischen Fällen Ihres Ablaufs, bevor es in Betrieb geht. Jeder Fall läuft mehrmals, weil ein gehostetes Modell unterschiedlich antworten kann, und wir zählen, wie oft das Ergebnis stimmt und wie oft die Prüfung Fehler abfängt. Unter den Modellen, die gut genug sind, entscheiden Schutzbedarf, Latenz und Kosten, ob das gewählte lokal auf Ihrer Hardware läuft oder über OpenAI, Anthropic oder Mistral. Die Architektur hält den Wechsel offen. Vor jeder Änderung an Modell oder Prompt läuft der Satz erneut.

Sprechen wir

Ein Ablauf, in dem ein Modell liest und ein Algorithmus prüft?

Beschreiben Sie in ein paar Sätzen, was heute von Hand passiert und woran man ein richtiges Ergebnis erkennt. Sie bekommen innerhalb von zwei Werktagen eine technische Einschätzung, auch wenn sie „kein Modell“ lautet.

Projekt besprechen [email protected]