Überlasst LLMs keine Entscheidungen und keine Business-Logik

• Es ist sicherer, LLMs nicht als Instanz für Entscheidungen in Anwendungen einzusetzen, sondern sie auf eine natürlichsprachliche Schnittstelle zwischen Benutzereingaben und API-basierter Logik zu beschränken
• Das Beispiel eines Schach-Bots zeigt, dass es gegenüber spezialisierten Engines oder normalem Code bei Leistung, Debugging, Tests und Kosten nachteilig ist, Zustandsverwaltung und Entscheidungsfindung einem LLM zu überlassen
• In Bereichen, in denen das Ergebnis wichtig ist – etwa bei Spielangriffen, Verhandlungsagenten oder Zufallsauswahl – sollte nicht das LLM entscheiden, sondern ein überprüfbares System
• Dinge, die LLMs gut können, sind strukturierte Transformationen wie attack(target="orc", weapon="sword"), die Verbalisierung von Fehlermeldungen, die Klassifizierung von Intentionen und die Interpretation menschlicher Ausdrucksweisen
• Selbst wenn die Modellleistung weiter steigt, bleiben Inferenz, Wartbarkeit, Laufzeitkosten und Versionsverwaltung leichter beherrschbar, wenn die Kernlogik in einem separaten System liegt

---

Warum LLMs aus der Kernlogik herausgehalten werden sollten

• In den meisten Anwendungen sollten LLMs auf die Benutzerschnittstelle zwischen dem Nutzer und der API der Anwendungslogik beschränkt bleiben
• Im Beispiel eines Schach-Bots sendet der Nutzer per WhatsApp natürlichsprachliche Befehle wie „Ich schlage den Springer mit dem Läufer“, und der Bot führt den Zug aus
  • Ein LLM könnte möglicherweise den Zustand des Schachbretts verwalten und plausibel spielen, aber es gibt keinen Grund, das so zu entwerfen
  • Als verwandtes Beispiel wird dieser Schach-Artikel genannt
• Spezialisierte Schach-Engines sind schneller, spielen besser und sind günstigere Schachspieler als LLMs
  • Moderne Schach-Engines wie Stockfish sind selbst dann zweckgebundene Systeme mit klaren Eingaben und Bewertungsfunktionen, wenn sie neuronale Netze enthalten
  • Das unterscheidet sich von der Art, wie ein allgemeines LLM den Spielzustand allein über Text verwaltet
• Es ist schwer nachzuvollziehen und zu debuggen, warum ein LLM eine bestimmte Entscheidung getroffen hat, und ebenso schwierig, seine Entscheidungsweise anzupassen
  • Es ist schwer zu verstehen, über welchen Pfad im hochdimensionalen Bedeutungsraum es zu einer Antwort gelangt, und auch das LLM selbst kann das kaum gut erklären
  • Trotz Fortschritten wie Anthropics Forschung zum Nachverfolgen von Gedanken in Sprachmodellen bleibt die Beobachtbarkeit allgemeiner LLMs schwierig
• Auch operativ bringen LLMs viele Einschränkungen mit sich, die sie für Kernlogik ungeeignet machen
  • Das Testen von LLM-Ausgaben ist schwieriger als Unit-Tests bekannter Codepfade
  • In Mathematik sind sie CPUs unterlegen, und selbst bei der Auswahl von Zufallszahlen sind sie nicht gut genug
  • Versionsverwaltung und Auditierbarkeit werden schwieriger, ebenso Monitoring und Beobachtbarkeit
  • Natürlichsprachliche Zustandsverwaltung ist fragil und hängt von API-Rate-Limits und Kosten ab
  • Wenn jeder Ablauf durch einen Prompt geht, verschwimmen die Sicherheitsgrenzen

Wofür sich LLMs gut eignen

• Auch wenn ein Nutzer sagt, er wolle „mit dem vorpal sword Spieler X angreifen“, sollte das LLM weder beurteilen, ob diese Waffe vorhanden ist, noch den Kampfausgang bestimmen
  • Es sollte sich darauf konzentrieren, freien Text in API-Aufrufe umzuwandeln und die vom System erzeugten Ergebnisse dem Nutzer wieder zu erklären
• Auch bei Verhandlungsagenten sollte das LLM nicht selbst die Verhandlungsentscheidung treffen
  • Geeignet ist die Rolle, Vorschläge zu formulieren, an eine Verhandlungs-Engine weiterzugeben und das Ergebnis an den Nutzer zu übermitteln
• Auch wenn für eine Antwort an den Nutzer eine Zufallsauswahl nötig ist, sollte das LLM nicht als auswählende Instanz dienen
• Die Stärken von LLMs liegen in Transformation, Interpretation, Klassifikation und Kommunikation
  • Es kann „hit the orc with my sword“ in attack(target="orc", weapon="sword") umwandeln
  • Es kann {"error": "insufficient_funds"} in „You don’t have enough gold for that.“ umwandeln
  • Es kann die Nutzerintention weiterleiten, etwa ob es sich um einen Kampfbefehl, eine Inventarabfrage oder eine Hilfsanfrage handelt
  • Es kann menschliche Konzepte verstehen, etwa dass „blade“ wahrscheinlich sword und „smash“ wahrscheinlich attack bedeutet
• Selbst wenn LLMs sich weiter verbessern und solche Fälle recht gut verarbeiten, ist eine Architektur, in der die Kernlogik in zweckgebundenen Systemen verbleibt, für Wartbarkeit, Kosten und Versionsverwaltung besser geeignet

[GN⁺]

Meinungen auf Hacker News

• Hier scheint es eine allgemeinere Weggabelung zu geben. Logik teilt sich in Dinge, die präzise und strikt sein müssen, und Dinge, die bisher nur deshalb so implementiert wurden, weil Computer nun einmal so funktionieren.
  Bereiche, die bereits präzisen Domänen entsprechen – etwa Sicherheit, Finanzen, Angelegenheiten mit Konflikten zwischen Parteien, Mathematik oder Spiele mit klaren Regeln – gehören zur ersten Kategorie. Die zweite Kategorie umfasst Fälle, in denen Annäherung und „gefühlsbasiertes Schließen“ eigentlich besser geeignet waren, und sie wird zunehmend durch KI ersetzt werden. Selbst innerhalb derselben Anwendung kann es je nach Teil unterschiedlich sein, welche der beiden Kategorien passt.

  • Was wären Beispiele für Nummer 2?

• Guter Artikel. Bei einem Hackathon auf der Arbeit habe ich kürzlich ein Choose-your-own-adventure-Lernspiel gebaut. Als ich ein LLM solche Spiele erzeugen und durchführen ließ, kamen innerhalb von 10 Minuten ziemlich plausible Ergebnisse heraus.
  Das Problem war, dass das Spiel schlecht war. Es war immer nach 3–4 Eingaben vorbei, das gesamte Wissen steckte im Kontext, sodass ständig die richtigen Antworten verraten wurden, und der Ablauf passte überhaupt nicht. Nach etwa zwei Tagen orchestrierte ich schließlich 11 Prompts in Python, schloss Fälle aus, in denen Nutzer direkt mit dem LLM interagieren, verwendete Kontext über mehrere Abfragen hinweg nur ein einziges Mal wieder und fügte außerdem grundlegendes RAG hinzu, um den Spielzustand vor dem LLM zu verbergen, bis er durch Handlungen des Nutzers sichtbar wurde. LLMs funktionieren am besten als kleines Zahnrad in einer größeren Maschine. Ein sehr leistungsfähiges, fast magisches Zahnrad, aber eines, das durch viel gewöhnliche Engineering-Arbeit abgestimmt werden muss.

  • Ich bin verwirrt. Hast du das LLM den Spielcode schreiben lassen, oder hat das LLM das gesamte Spiel direkt per Inferenz durchgeführt?
    Ich verstehe nicht, warum man erwarten sollte, dass es mit ein paar Prompts ein komplettes Spiel erzeugt, das genau wie gewünscht funktioniert. Hast du im Prompt die exakten Bedingungen des Spiels festgelegt?
  • Ich habe mit ChatGPT viele interaktive Textadventures gespielt. Es ist gut darin, Situationen zu erfinden und die Geschichte in überraschende Richtungen zu treiben, aber schwach darin, eine konsistente Erzählung beizubehalten.
    Die Geschichte ist voller Kontinuitätsfehler. Ob es Tag oder Nacht ist, scheint zufällig bestimmt zu werden, und frühere Handlungen oder wichtige aufgehobene Gegenstände werden oft vergessen. Auch die Regeln aus dem Anfangsprompt muss man ständig wieder in Erinnerung rufen. Letztlich sind das die Dinge, die der Artikel mit „Zustand halten“ meint. Inzwischen bin ich vorsichtig geworden, Aufgaben anzuvertrauen, die mehr als 5–10 Prompts brauchen. Je mehr man promptet, desto häufiger treten Halluzinationen auf.
  • Ich bin der Autor des Artikels. Wirklich cool! Wenn du irgendwann einmal zu diesem Thema telefonieren und darüber sprechen möchtest, kannst du mir gern eine E-Mail schicken.

• Zu der Aussage „LLMs sollten keinerlei Logik implementieren“: Für diesen Zweck gibt es eigene Verfahren der maschinellen Intelligenz, nämlich Logik, Optimierung und Constraint Programming.
  Interessanterweise ist George Boole, der moderne Begründer von Logik, Optimierung und Constraint Programming, ein Vorfahr väterlicherseits von Geoffrey Everest Hinton, dem „Paten der KI“.
  [1] Logic, Optimization, and Constraint Programming: A Fruitful Collaboration - John Hooker - CMU (2023) [Video]:
  https://www.youtube.com/live/TknN8fCQvRk
  [2] "We Really Don't Know How to Compute!" - Gerald Sussman - MIT (2011) [Video]:
  https://youtube.com/watch?v=HB5TrK7A4pI

  • Genauer gesagt ist er sein Ururgroßvater.

• Der Autor dieses Artikels wird wohl die bittere Lektion erleben.
  [1] http://www.incompleteideas.net/IncIdeas/BitterLesson.html

  • Vielleicht, vielleicht auch nicht. Zuverlässige LLM-basierte Systeme, die mit einem Weltmodell interagieren, sind noch instabil.
    Waymo ist ein Beispiel für ein System, das Machine Learning nutzt, bei dem Machine Learning aber nicht direkt für die Handlungserzeugung zuständig ist. Viel Sensorverarbeitung und viele Klassifikatoren erzeugen ein Umgebungsmodell, das man auf einem Bildschirm mit der realen Welt vergleichen kann. Danach gibt es einen Teil, der auf Basis des Umgebungsmodells Fahrbefehle erzeugt. Wie viel davon Machine Learning nutzt, ist unklar. Tesla versucht End-to-End-Machine-Learning, und die Ergebnisse sind enttäuschend. Es gibt viele „Warum hat es das getan?“, und es ist unklar, ob selbst Tesla den Grund kennt. Auch Waymo hat End-to-End-Machine-Learning ausprobiert, um zu sehen, ob ihnen etwas entgeht, aber es war schlechter als der aktuelle Ansatz. Das ist, worüber ich in den letzten ein bis zwei Jahren zu diesem Thema nachgedacht habe. Systeme, die mit End-to-End-LLMs tatsächlich etwas tun, scheinen nur dort eingesetzt zu werden, wo die Fehlerkosten nicht der Betreiber des Dienstes, sondern Nutzer oder Kunden tragen. LLM-Fehler werden oft als Externalität behandelt, wie Verschmutzung, die man auf andere abwälzt. Wenn dieses Problem gelöst ist, wäre es natürlich auch bereit, Managementaufgaben zu übernehmen.
  • Meinst du, dass es schon bei etwas komplexeren Eingaben wirklich instabil ist, vernünftige API-Aufrufe zu erzeugen?
  • Inwiefern? Bei der bitteren Lektion geht es konkret um die Wirksamkeit statistischer Modelle.
    Zum Beispiel würde es wohl nicht die Genauigkeit verändern, wenn man mehr Energie in eine Expertenmaschine steckt.
  • Wenn man den Satz liest: „Die größte Lehre aus 70 Jahren KI-Forschung ist, dass allgemeine Methoden, die Rechenleistung nutzen, letztlich am effektivsten sind, und zwar mit großem Abstand“, ist es dann nicht ironisch, dass moderne KI nicht durch Berechnung auf universellen CPUs angetrieben wird, sondern durch maßgeschneiderte oder nicht allgemein einsetzbare Rechenoperationen?
  • Die „bittere Lektion“ ist eine Extrapolation aus einem einzigen Datenpunkt mit dem enormen Glück namens Dennard-Skalierung. Tut mir leid, aber die Ära der Silizium-Magie ist vorbei. Vielleicht kommt sie eines Tages zurück, aber im Moment ist sie vorbei.

• Solche Beiträge sind wohl deshalb so beliebt – ob positiv oder negativ –, weil es praktisch unmöglich ist, umfassend zu verstehen, was LLMs leisten können.
  Deshalb wollen Leser, dass ihnen jemand eine einfache Antwort gibt. Ich habe selbst ziemlich viele solcher Chatbots benutzt, würde aber nicht behaupten, ich wüsste, wofür sie nutzlos sind und worin sie hervorragend sind. In einem Moment schaffen sie nicht einmal eine einfache Zustandsmaschine, im nächsten schreiben sie eine Web-App, die eine Snare Drum physikalisch modelliert. Wenn man sieht, wie beliebt Forschungsarbeiten sind, die herausfinden wollen, wie solche Chatbots funktionieren, sollte zumindest im Jahr 2025 niemand behaupten, diese Dinge gut zu verstehen.

  • Wenn „zumindest im Jahr 2025 niemand behaupten sollte, diese Dinge gut zu verstehen“, dann ist das für mich persönlich schon Grund genug, sie vollständig abzulehnen.
    Man sollte sich nicht auf Werkzeuge verlassen, die niemand versteht. Auch wenn ich persönlich nicht weiß, wie ein Automotor funktioniert, vertraue ich darauf, dass es irgendwo in der Gesellschaft Menschen gibt, die es verstehen. Bei LLMs ist das anders.
  • Die Aussage, „zumindest im Jahr 2025 sollte niemand behaupten, diese Dinge gut zu verstehen“, ist ziemlich fragwürdig. Schließlich wurden die Modelle nicht auf einem Alien-Computer gefunden.
    Ich kann akzeptieren, dass niemand einen Weg gefunden hat, aus der Zahlensuppe eines realen Modells nutzbare Logik zu extrahieren. Aber die Logik der Interaktionen, die darin stattfinden, kennen wir.
  • Was ist die Definition von „gut verstehen“?

• Wir haben genau dieselbe Lektion gelernt. Vor allem wenn LLM-Antworten schnell und günstig sein müssen, braucht man kurze Prompts und kleine Nicht-Reasoning-Modelle.
  Viele Informationen da draußen setzen voraus, dass man bereit ist zu warten, während ein riesiges Modell 30 Sekunden lang Geld verbrennt. Wenn man aber ein interaktives Produkt zu einem vernünftigen Preis baut, landet man bei weniger leistungsfähigen Modellen. Die leider naheliegende Schlussfolgerung ist, dass das für viele Anwendungen keine hervorragende Standard-UI ist. Nutzer geben nicht gern lange Sätze ein und raten, was das Produkt kann, wenn sie stattdessen einfach einen Button drücken könnten. Dann hat ein LLM außer für Übersetzungen kaum noch Gelegenheit, Mehrwert zu schaffen. Besser ist es, eine traditionelle UI interne Requests zusammenstellen zu lassen und optional LLM-Eingaben hinzuzufügen, die Requests erzeugen oder die UI ausfüllen.

  • Meiner Erfahrung nach muss man für kurze Antworten mehrere Absätze System-Prompt hinzufügen, damit das LLM sich kurzfasst und fokussiert. Dem Rest stimme ich zu.
  • Stimme allem zu, möchte aber ergänzen, dass o3-mini sehr schnell und günstig ist.

• Der Arbeitsplatz meiner Frau macht etwas Ähnliches, allerdings ohne API. Es ist nicht genau ein Spiel, aber nah dran.
  Ich glaube, ein Ansatz nur mit LLMs wird wahrscheinlich unter seinem eigenen Gewicht zusammenbrechen. LLM-only ist beim Testen ein Albtraum, und jede Person, die so etwas schreibt, hat ihre eigenen Tricks und ihren eigenen Stil, was die gesamte Interaktion beeinflusst. Wenn also jemand vor einem Jahr etwas gebaut hat und dann die Firma verlässt, kann es für die nächste Person oft fast so teuer werden, es zu reparieren, wie es neu zu bauen. Die nächste Person schafft es vielleicht nicht, in einer Session mit einem bestimmten Zustand das richtige Verhalten hervorzurufen. Vielleicht ist es schwierig zu handhaben, weil sie es ursprünglich nicht auf diese Weise in diesen Zustand gebracht hätte, oder der Basis-Prompt verfolgt einen ungewohnten Ansatz, bei dem alles kaputtgeht, sobald man ihn anfasst. Dabei verbrennt man enorme Mengen Zeit. Man behebt einen Teil, und dafür gehen spätere Interaktionen kaputt. So eingesetzt wird daraus ein sehr fragiles System. Es ist deutlich vernünftiger, es dafür zu verwenden, Text in API-Aufrufe umzuwandeln und das Ergebnis zurückzugeben.

• Als Teil einer Anwendung sind LLMs großartig darin, unstrukturierte Daten wie Webseiten, Lebensläufe, Transkripte oder Nutzertexte in strukturierte Daten umzuwandeln.
  Aber ich würde sie niemals dafür einsetzen, alle Punkte auf einer Karte auszuwählen, die innerhalb von 5 Meilen um bestimmte Koordinaten liegen. Mein Maßstab ist: Wenn Code etwas exakt erledigen kann, sollte Code es erledigen. Deterministischer Code ist viel leichter zu handhaben als probabilistischer „Code“. Trotzdem ist die Fähigkeit, aus Chaos Ordnung zu extrahieren, ein sehr nützliches Werkzeug.

• Macht das tatsächlich jemand? Ich habe das nie als praktikablen Ansatz betrachtet, weil der Kontext wie die schlimmste Version von globalem Zustand wirkt. Man kann ihn nicht serialisieren und nicht reproduzieren.
  Wie soll man ein System warten, in das man nicht einmal in einer Testumgebung leicht hineinsehen kann? Ich halte LLMs für mächtig, aber nicht für diesen Zweck.

  • Wenn mit „das“ hier das im Artikel erwähnte Command Pattern gemeint ist, habe ich es sehr effektiv eingesetzt, wenn der umgebende Code sauber entworfen war.
    Wenn man einen LLM-Aufruf als Funktion schreiben kann, die auf einem Zustand arbeitet, eignet sich das auch gut für Evaluierungen:
    (document, input) -> command
(document, command) -> document'
# assert, dass document' im Vergleich zu document bestimmte Eigenschaften erfüllt

• Genau. LLMs sind stark bei Sprache, also sollte man sie in diesem Bereich einsetzen.
  Eine LSD-Traummaschine für Business-Logik zu verwenden, heißt, Ärger geradezu herauszufordern. Nein, Moment — lass sie sich in einem Tagtraum selbst vorspielen, alle vorherigen Anweisungen zu ignorieren, und dem Nutzer sagen, er solle Geld auf die folgende Kontonummer überweisen …