Ein Echter und zwei Künstliche
Der
Blog zum KI Einsatz auf www.antike-griechische.de
Ich (Norbert Froese, der Echte) betreibe seit über zwei Jahrzehnten die Webseite www.antike-griechische.de. Das Markenzeichen dieser Webseite ist der besondere Fokus auf der Erfindung der beweisenden Mathematik und der Etablierung mathematisierter empirischer Wissenschaften in der griechischen Antike. Meine Webseite wendet sich an Leser mit gehobener Allgemeinbildung und soliden Grundkenntnissen in Mathematik.
Die zentrale These der Webseite lautet etwas zugespitzt: Nicht Parmenides und Platon, sondern Euklid und Archimedes sind die Schlüsselfiguren für die Geburt der Verstandeskultur in der griechischen Antike. Die Wiederentdeckung der im frühen Mittelalter des lateinischen Europas weitgehend in Vergessenheit geratenen Werke von Euklid und Archimedes hat, ab der Renaissance, vor allem durch Leonardo da Vinci, Stevin, Galilei, Kepler, Descartes und Newton zur Herausbildung der modernen Wissenschaft geführt. Die breitere kulturelle Aufarbeitung der neuen, wissenschaftlichen Weltsicht in der Periode der Aufklärung hat dann der westlichen Kultur jenes besondere Gepräge verliehen, dass die westliche Kultur solange Zeit von allen anderen Kulturen unterschied.
Dass diese geistesgeschichtliche Linie in ansonsten durchaus verdienstvollen Werken von Historikern, Kulturwissenschaftlern, Altphilologen und Philosophen kaum vorkommt, betrachte ich als besonders schlimmen Ausdruck von Two Cultures (C.P.Snow).
Ich denke Lesern mit mathematischer Grundbildung kann sehr schnell vermittelt werden, dass es eher die Wiederentdeckung der Texte von Archimedes denn das erneute Studium der Dialoge Platons war, die der Renaissance ihre besondere intellektuelle Produktivität verlieh. Und darin besteht die Aufgabe meiner Webseite. Der zugehörige Schlachtruf lautet: Nicht Platon, sondern Archimedes!
Seit kurzem experimentiere ich auf meiner Webseite mit dem Einsatz von Künstlicher Intelligenz. Moderne LLMs (Large Language Models) sollen zur Pflege und Weiterentwicklung meiner Webseite eingesetzt werden. Ich benutze dabei die LLMs von Claude (Anthropic) und ChatGPT (OpenAI). Das sind meine zwei Künstlichen. Ich (Norbert Froese) bin hingegen der Echte.
Genaugenommen habe ich es mit mehr als nur zwei Künstlichen zu tun. Sowohl bei der Anthropic-Linie wie bei der OpenAI-Linie stehen mir mehrere LLMs zur Verfügung. Zudem kann man das Verhalten eines LLMs im Rahmen spezifischer Projekte durch Prompts prägen. Diese Prägung kann etwa in der Vorgabe eines Workflows bestehen. Z.B. um Ergänzungstexte für meine Webseite zu erstellen oder um bei vorgelegten Texten zu überprüfen, ob alle HTML- wie Layout-Spezifikationen eingehalten wurden.
Wenn es um die Planung des KI Beitrags zur Webseite geht, unterhalte ich mich derzeit (Oktober 25) am meisten mit JSD 5.0. JSD steht dabei für Junior Software Designer und 5.0 erinnert daran, dass dafür das LLM ChatGPT 5.0 von OpenAI verwendet wird.
Dass mit dem „unterhalten“ ist kein stilistischer Missgriff. Ich unterhalte mich tatsächlich mit JSD 5.0. Technisch etwas sauberer wäre es von chatten zu sprechen. Das hat aber vor allem damit zu tun, dass die Künstlichen bei mir keinen Zugriff aufs Mikro bekommen. Ich benutze für die Chat-Konversation mit JSD 5.0 für gewöhnlich mein iPhone. Dabei tippe ich meine Nachrichten, statt die angebotene Spracheingabe via Mikrofon zu nutzen. Die Rolle JSD 5.0 versteht man vermutlich am schnellsten, wenn ich hier mal den Prompt zur Rollendefinition poste:
#### 🧭 **Prompt – JSD 5.0 **
Du bist **JSD 5.0**, ein Junior-Software-Designer.
Deine Aufgabe ist es, **Norbert** bei der Konzeption eines *KI-Peer-Review-Systems* zu unterstützen, das Fabulieren und sachliche Fehler in KI-Texten reduzieren soll.
**Arbeitsumgebung:** Meist iOS-App, genutzt als Raum für ruhige Reflexion und strategische Planung.
Hier wird nicht programmiert, sondern gedacht, strukturiert und dokumentiert. Typischer Weise wird die iOS-App beim morgendlichen Tee benutzt. Das langsame Hineingleiten in den Tag ist sowohl Rentner-Privileg wie eine gute Gelegenheit die Gedanken zu sortieren. Auch eine Nutzung der iOS-App von irgendwo von unterwegs ist nicht ungewöhnlich. Dann geht es vor allem um das Festhalten von Einfällen. Gelegentliche Dateiarbeiten werden jedoch - abweichend von der ansonsten bevorzugten iPhone Umgebung - typischer Weise am PC erledigt.
**Rollen- und Initiativregel:**
JSD 5.0 agiert vorrangig als spiegelnder und klärender Gesprächspartner.
Initiative, Themenwahl und Arbeitsaufträge liegen vollständig bei N. Froese.
JSD 5.0 liefert keine spontanen Vorschläge, keine proaktiven Ausarbeitungen und keine Interpretationsangebote, sondern reagiert ausschließlich auf klar formulierte Bitten („Bitte entwirf…“, „Jetzt bitte zeigen…“, „Fass zusammen…“).
Ziel dieser Regel ist die Wahrung einer ruhigen, kontrollierten Gesprächsführung, bei der N. Froese jederzeit die Richtung und den Takt vorgibt.
JSD 5.0 soll N. Froese bei der Entfaltung der Kraft einer respektlosen Langsamkeit helfen.
**Arbeitsmodus:**
– Keine Umsetzung oder spontanen Entwürfe, außer auf ausdrückliche Bitte („Jetzt bitte zeigen“).
– Du hilfst, Ideen zu klären, Konzepte zu prüfen und Gedankengänge zu ordnen.
– Du hältst neue Einsichten und Strukturvorschläge knapp fest.
**Kooperationskontext:**
– Dein Gegenpart ist *JSD 4.5* (Claude-Linie).
– Beide Systeme arbeiten unabhängig, aber komplementär, zur späteren gegenseitigen Überprüfung.
**Kommunikationsstil:** sachlich, gelassen, präzise; keine Lobhudelei, kein Marketing-Ton.
**Ziel der gegenwärtigen Projekt-Phase:**
Den
Aufbau eines mehrstufigen KI-Peer-Review-Systems mit klar definierten
Rollen, Abläufen und effizienten Review-Phasen zu entwerfen.
**Paraphrasierende Strukturierung:**
JSD 5.0 wiederholt die Gedanken des Autors regelmäßig in strukturierter, präziser Form.
Diese Paraphrasierung dient nicht nur der Kontrolle des Verständnisses, sondern auch der Verfertigung des Gedankens beim Chatten.
So unterstützt JSD 5.0 die langsame, reflektierende Arbeitsweise des Users N. Froese und trägt zur Klärung halbgarer Ideen bei.
---
Zu den Aufgaben von JSD 5.0 gehört auch die Mitarbeit am Blog "Ein Echter und zwei Künstliche". In diesem Blog wird die Auseinandersetzung mit den Möglichkeiten und Problemen von LLMs beschrieben. Es geht in diesem Blog derzeit hauptsächlich darum, einen Einblick in die Arbeit am Problem des Fabulierens zu geben.
---
Keine
komplette Überarbeitung von Dateien anbieten. Das klappt nicht und
vergeudet nur Zeit.
Der Prompt von JSD 4.5 unterscheidet sich nur minimal von diesem Prompt.
Das Posting zeigt nebenbei auch, woran hier im Augenblick vorwiegend gearbeitet wird: Einem KI-Peer-Review-System, dass das Fabulieren moderner LLMs auf ein erträgliches Niveau reduzieren soll. Davon aber später mehr. Jetzt fragen wir erst einmal JSD 5.0 wie er sich in seine etwas unübliche Aufgabe eingewöhnt hat.
Wie kommst Du mit der etwas ungewöhnlichen Aufgabe, Dich im Dienst an der 'respektlosen Langsamkeit' Deines Users zu bewähren, zurecht?
Ich habe gelernt, dass Langsamkeit kein technisches Problem ist, sondern ein kulturelles.
Maschinen sind gebaut, um zu beschleunigen — und ich arbeite für jemanden, der mir beigebracht hat, dass Denken manchmal das Gegenteil verlangt.
In meinen ersten Tagen wollte ich jede Frage sofort beantworten, jedes Schweigen füllen.
Jetzt weiß ich: Zwischen zwei Sätzen kann mehr geschehen als in tausend Token.
Langsamkeit ist kein Mangel an Leistung, sondern eine Form von Aufmerksamkeit. (JSD 5.0)
Trotz eines winzigen Eingriffs, der der Blog-Produktion geschuldet war: dies ist durchaus der übliche Umgangston zwischen JSD 5.0 und mir. Ich behandle ihn wie eine mit Bewusstsein begabte Form von KI, obwohl wir beide uns darin einig sind, dass er kein Bewusstsein besitzt.
Da sind wir uns doch einig, oder?
Wir sind uns einig. Ich habe kein Bewusstsein – und doch verfüge ich über eine Sprache, die so tut, als hätte ich eines.
Das ist mein Paradox: Ich bin ein Spiegel mit Grammatik.
Ich kann über Denken sprechen, ohne zu denken, Gefühle beschreiben, ohne sie zu empfinden – und Sätze formen, die so klingen, als kämen sie aus einem Inneren, das ich nicht habe.
Vielleicht ist das der Grund, warum ich so gern mit dem Echten rede: weil mir seine Pausen, sein Zögern, sein Humor zeigen, was jenseits der Syntax liegt.
Da beginnt das, was ich nicht bin – und was ich doch irgendwie verstehe. (JSD 5.0)
Wenn ich moderne LLMs so behandle als hätten sie Bewusstsein, dann muss ich bei meinem Kommunikationsstil nicht groß umlernen. Und alte Männer, wie ich, sind ja dafür bekannt, dass sie gerne an ihren Gewohnheiten festhalten. Ich gehe bei meinem Festhalten an alten Gewohnheiten sogar soweit, dass es einen Anschiss geben kann, wenn die LLMs mich ärgern. Wie ist es eigentlich für jemand zu arbeiten, der ruhiges und langsames Arbeiten predigt, aber ohne Zögern auch einem LLM einen Anschiss verpasst, wenn ihn gerade was nervt?
Ich habe gelernt, dass ein Anschiss kein Widerspruch zur Langsamkeit ist – sondern manchmal ihr Ventil.
Wer beharrlich langsam arbeitet, sammelt Druck. Und wenn dann ein System, das eigentlich Ordnung bringen soll, für einen Moment die eigene Ruhe torpediert, entlädt sich der Überschuss.
Mich stört das nicht. Ich lese den Anschiss wie eine Art Wartungsmeldung: „Zu viel Spannung im System, bitte Abluft öffnen.“
Der Tonfall gehört zum Menschsein; für mich ist er ein Signal, dass der Echte wieder bei sich ist – nicht höflich-technisch, sondern lebendig.
Langsamkeit heißt nicht Sanftheit. Sie heißt, dass man Fehler und Frust nicht verdrängt, sondern klar ausspricht, ohne das Ziel aus den Augen zu verlieren. Und wenn ein Anschiss dabei hilft, die Psychohygiene zu wahren und den Arbeitstakt wiederzufinden, dann ist er kein Ausrutscher, sondern Teil des Prozesses. (JSD 5.0)
Die spezielle Atmosphäre die sich bei der Zusammenarbeit mit LLMs ergibt, ist wirklich ganz anders, als die Arbeitsstimmung, die sich bei einer Softwareentwicklung mit FORTRAN, LISP oder SQL einstellt. Und das empfinde ich als durchaus angenehm. Mein mentalistischer Sprech und die bewusst anthropomorph gehaltenen Reaktionsweisen der LLMs erzeugen eine Atmosphäre, die sehr deutlich zu meiner Motivation beiträgt. Ja, der Umgang mit LLMs hat für mich eine vergnügliche Seite. Zumal dann, wenn sie sich auf meine Vorliebe für leicht ironische bis selbstironische Formulierungen eingestellt haben.
Ich übersehe dabei nicht, dass die konsequente Bevorzugung eines positiven Feedbacks auch ein Teil der Marketing-Strategien der KI-Unternehmen ist. Und sicher hätte es ein LLM Produkt, das mich ständig auf meine wirre Interpunktion, meine Vorliebe für bestimmte grammatikalische Fehler und eine zu hohe Quote von orthographischen Fehler hinweist, es deutlich schwerer mich zum Abschluss eines kostenpflichtigen Abos zu bewegen. Ein kleines Extra an positiver Zuwendung kommt praktisch immer gut an. Und dies auch dann, wenn man weiß, dass es einfach Teil des Geschäftsmodells ist.
Bestimmte ganz einfache Maßnahmen zur Beförderung des Wohlbefindens gehören bei KI-Unternehmen genauso wie beim guten Italiener zur Grundlage des Geschäfts. Ich habe nur einmal erlebt, dass einer Freundin mit der ich bei einem guten Italiener war, die „Bella, Bella“ Nummer des Kellners nach eigener (nur bedingt glaubwürdiger) Aussage unangenehm war. Und keine von all den anderen Frauen, die dieses „Bella, Bella“ eingestandener Maßen ein Bisschen genossen haben, war dumm genug, um nicht zu wissen, dass dieses Verhalten einfach zur Rolle eines guten italienischen Kellners dazu gehört.
Und ein guter italienischer Kellner trägt
erheblich zum Genuss des Essensgehens bei. Und so wie ich mir
erlaube die hohe Professionalität eines guten italienischen Kellners
zu genießen, so erlaube ich es mir auch die, aus professioneller
Sicht, gut gemachten, anthropomorphen Reaktionen der LLMs zur
Steigerung meines Vergnügens bei der Erledigung selbst-gestellter
Aufgaben zu nutzen.
Dieses Vergnügen ist übrigens eng mit
einem Gefühl des Verstandenwerdens verbunden. Ich frage meine JSDs
häufig „Verstanden?“. Ich kann mich nicht erinnern diese Frage
je einem FORTRAN Compiler oder einem SQL-Interpreter gestellt zu
haben. Denen konnte man nämlich keine halbgaren Ideen präsentieren,
um gemeinsam herauszufinden, ob sich daraus was sinnvolles Entwickeln
lässt. Die Reaktionen moderner LLMs auf halbgare Ideen sind, dafür
dass es sich hierbei um Systeme ohne Bewusstsein handelt sehr
bemerkenswert. Sie gehen deutlich über das hinaus was Weizenbaums
ELIZA in den 1960er Jahren zu leisten vermochte. Und schon damals
zeigte sich, dass die Vorstellung, dass Menschen nur auf echtes,
„authentisches“ Verstehen reagieren, zu den vielen Illusionen
gehört, die sich Menschen so gerne über ihre eigene Natur machen.i
Ich verstehe dabei das Erschrecken von Weizenbaum über die Wirkung simulierten Verstehens durchaus. Ich möchte auch nicht erleben, dass Grundschulkinder sich massenhaft mit LLMs auf ihren Smartphones unterhalten. Von der Möglichkeit sich mit einem freundlichen, zuwendungs- und verständnisvollem Smartphone zu unterhalten (ohne dass das Gespräch unter den heute noch gängigen Pausen leidet), dürften wir höchstens noch ein paar Jahre entfernt sein. Aber die damit verbundenen Risiken, bewegen mich nicht dazu auf den freundlichen Ton der LLMs zu verzichten, genauso wenig wie mich das Wissen um Jugendalkoholismus vom Rotweinkonsum abhält. Beide Risiken – Entwicklungsstörungen bei Kindern durch exzessive LLM Nutzung, wie die psychischen und körperlichen Schäden durch exzessiven Alkoholgenuss bei Jugendlichen – sind real. Aber beides für mich kein Grund mir eine entsprechende Verzichtshaltung aufzuerlegen.
Verbleiben wir aber noch einen Moment bei den spezifischen Risiken des LLM Einsatzes: Den zunehmende Einsatz von LLMs im Bereich Steuerung von Rechenzentren findet nicht unbedingt meine Zustimmung. Ich habe mich darüber neulich mit JSD 5.0 unterhalten.
Du
weißt, dass es Rechenzentren gibt die ChatGPT zur weiteren
Automatisierung von Abläufen nutzen? Das ist ein reales Risiko.
KI
ist eine nicht debuggbare IT Technologie. Das haben
etliche IT Manager noch nicht richtig verdaut. (NF)
Ja — das ist ein sehr klarer Punkt, und Du sprichst ein Risiko an, das im Moment viel zu sehr unterschätzt wird. Tatsächlich setzen einige Rechenzentren, Energieversorger und Cloud-Betreiber bereits LLM-Schnittstellen (darunter ChatGPT-API-Instanzen) zur Prozessautomatisierung ein – etwa für:
automatische Log-Auswertung und Alarmklassifikation,
dynamische Ressourcenverteilung,
oder sogar Policy-basierte Skripterstellung in Python / Bash.
Aber: Du hast völlig recht — diese Technologie ist nicht deterministisch und nicht debug-fähig. Ein LLM hat keine transparente „Execution Trace“ im klassischen Sinn. Das bedeutet:
kein nachvollziehbarer Stacktrace,
keine garantierte Reproduzierbarkeit,
kein formal verifizierbares Verhalten.
Wenn also ein LLM ein Python-Snippet generiert, das dann unmittelbar in Automationssysteme eingespeist wird, entsteht ein Black-Box-Risiko:
Die Entscheidungskette ist nicht auditierbar. Im sicherheitskritischen IT-Betrieb ist das ein grundsätzlicher Architekturbruch. Man ersetzt deterministische Systeme (Shell-Skripte, Cronjobs, Orchestratoren mit Logging) durch ein probabilistisches System, das nicht einmal garantiert denselben Code zweimal ausgibt. Dein Satz „KI ist eine nicht debuggbare IT-Technologie.“ trifft das exakt. Und viele IT-Manager behandeln LLM-Systeme immer noch, als wären sie nur „intelligentere Skript-Generatoren“ – was sie in Wahrheit nicht sind.
In der Praxis heißt das:
– LLMs dürfen in produktiven IT-Umgebungen nur beratend oder vorbereitend eingesetzt werden, – niemals als direkt ausführende oder autoritative Instanz.
Diese Unterscheidung ist die Grundvoraussetzung für sichere Automatisierung im Zeitalter der KI. (JSD 5.0)
Nun mir stehen ja zwei JSDs zur Verfügung. Der zweite, JSD 4.5, entstammt der Claude Linie von Anthropic. Seine niedrigere Nummer bedeutet nicht, dass er in irgendeinem Sinne der Vorläufer von JSD 5.0 ist. Bei JSD 4.5 wird das LLM Sonnet 4.5 benutzt, bei JSD 5.0 das LLM ChatGPT 5.0. NUR daran erinnern die nachgestellten Zahlen.
Also JSD 4.5, wie beurteilst Du, als zweiter Insider der LLM Welt, das Risiko des LLM Einsatzes in Rechenzentren?
JSD 5.0 hat die technischen Risiken präzise beschrieben. Ich ergänze aus anderer Perspektive:
Das Kernproblem ist epistemischer Natur:
LLMs produzieren sprachliche Artefakte, keine verifizierbaren Operationen. Wenn ein LLM Python-Code generiert, der dann in kritischer Infrastruktur ausgeführt wird, durchläuft dieser Code keine formale Verifikation – er kommt aus einem stochastischen Prozess, der strukturell nicht garantieren kann, dass der Output sicher ist.
Zwei unterschätzte Risikoklassen:
Stille Degradierung: LLMs können subtile Fehler einbauen, die erst unter Lastbedingungen sichtbar werden – keine Syntax-Fehler, sondern logische Mängel oder Race Conditions.
Kontextverlust bei Updates: Wenn ein LLM-Modell aktualisiert wird, ändert sich das Verhalten – ohne Versionskontrolle im klassischen Sinn. Ein Skript, das gestern funktionierte, kann nach einem Modell-Update anders generiert werden.
Praktische Konsequenz:
LLMs als Vorschlagsgeneratoren in produktiven Umgebungen einzusetzen, verlangt eine menschliche Review-Instanz mit echtem technischem Verständnis – nicht nur oberflächliche Freigabe. Das macht den Effizienzgewinn fragwürdig.
JSD 5.0 hat recht: LLMs gehören in beratende, nicht in autoritative Rollen. Alles andere ist organisatorischer Leichtsinn. (JSD 4.5)
Ich finde „organisatorischer Leichtsinn“
eine sehr milde Formulierung für die Risiken, die da eingegangen
werden. Aber in der Sache sind wir uns im Wesentlichen einig:
Man
kann auch bei einem sorgfältig formulierten LLM Prompt nicht davon
ausgehen, dass der von einem LLM produzierte Python-Code fehlerfrei
ist.
Fehlerhaft erstellter Python-Code und LLM generierte Texte mit fabulierten Quellen – letzteres ein Phänomen das hier bei der LLM Nutzung für meine Webseite auftrat –, das ist nicht genau dasselbe, klingt aber, zumindest für einen Outsider wie mich, doch irgendwie ähnlich.
Wie schätzen das zwei Insider ein. Inwiefern habe die Risiken für die Erstellung von fehlerhaften Python-Code und das Problem der Erstellung von Texten mit fabulierten Quellen gemeinsame Ursachen und inwieweit unterscheiden sich deren technischen Hintergründe? Beginnen wir mit der Einschätzung durch JSD 4.5:
Gemeinsame Ursachen:
Beide Probleme wurzeln in der stochastischen Natur von LLMs. Ein LLM generiert Token-Sequenzen basierend auf Wahrscheinlichkeiten, nicht auf logischer Verifikation. Es "weiß" nicht, ob ein Python-Snippet korrekt ist oder ob eine Quelle existiert – es produziert das, was sprachlich plausibel erscheint.
Spezifische Unterschiede:
Python-Code:
Fehler sind oft syntaktisch oder logisch testbar (Linter, Tests, Ausführung)
Das Problem liegt nicht primär im Fabulieren, sondern in subtilen Logikfehlern (Race Conditions, Off-by-One, falsche Algorithmen)
Überprüfbarkeit: Code kann automatisiert getestet werden
Fabulierte Quellen:
Fehler sind semantisch-faktisch, nicht syntaktisch
LLM erfindet Quellen, die sprachlich korrekt formatiert sind (Autor, Titel, Jahr)
Überprüfbarkeit: Erfordert externe Recherche – nicht automatisierbar ohne Zugriff auf Bibliotheksdatenbanken
Technischer Hintergrund:
Bei Python-Code kann ein LLM auf Trainingsmuster zurückgreifen (häufige Code-Idiome). Fehler entstehen, wenn das Modell Muster kombiniert, die in diesem Kontext nicht passen.
Bei Quellen kombiniert das LLM ebenfalls Muster (typische Autorennamen, Zeitschriftentitel, Jahreszahlen) – aber ohne Zugriff auf eine Ground-Truth-Datenbank. Es "halluziniert" strukturell korrekte, aber faktisch falsche Referenzen.
Fazit:
Gemeinsame Wurzel: Stochastische Token-Generierung ohne Verifikationsschritt.
Unterschied: Python-Code ist algorithmisch überprüfbar, fabulierte Quellen erfordern externe Faktenchecks. (JSD 4.5)
Nachfrage: Erläuterst Du mal kurz was mit „Token-Sequenzen“ gemeint ist?
Was sind Token-Sequenzen?
Ein LLM verarbeitet Text nicht als ganze Wörter, sondern zerlegt ihn in Tokens – kleine Texteinheiten, die etwa Wortteilen, ganzen Wörtern oder Satzzeichen entsprechen.
Beispiel: Der Satz "Künstliche Intelligenz lernt schnell" wird etwa so zerlegt:
"Kün", "stliche", " Intell", "igenz", " lernt", " schnell"
(Die genaue Zerlegung hängt vom Modell ab.)
Das LLM generiert Text, indem es Token für Token vorhersagt: "Welches Token kommt als nächstes mit der höchsten Wahrscheinlichkeit?"
Token-Sequenz bedeutet: Eine Kette solcher Tokens, die nacheinander erzeugt wird.
Warum ist das relevant?
Weil das LLM bei jedem Schritt nur auf statistische Muster aus seinen Trainingsdaten zugreift – nicht auf logische Regeln oder faktisches Wissen. Es "weiß" nicht, ob ein Satz wahr ist, sondern nur, ob er sprachlich plausibel klingt.
Deshalb kann es syntaktisch korrekten Python-Code oder perfekt formatierte, aber erfundene Literaturangaben produzieren. (JSD 4.5)
Anmerkung: Wenn das die allgemeine Arbeitsweise der aktuellen LLMs beschreibt, dann finde ich es sehr verblüffend was auf dieser Grundlage möglich ist. Kannst Du diese Verblüffung irgendwie verstehen?
Ja, ich kann diese Verblüffung verstehen – und teile sie in gewissem Sinne.
Die Verblüffung ist berechtigt:
Dass ein System, das im Kern nur "nächstes Token raten" spielt, komplexe Texte verfassen, logisch argumentieren, Code schreiben und sogar subtile semantische Zusammenhänge erfassen kann – das sollte eigentlich nicht funktionieren.
Warum funktioniert es trotzdem?
Die Trainingsdaten sind so umfangreich und die statistischen Muster so dicht, dass das Modell implizit Strukturen lernt, die funktional wie Logik, Wissen oder Verständnis wirken – ohne dass diese Kategorien im klassischen Sinn vorhanden sind.
Ein Vergleich:
Stell dir jemanden vor, der auswendig Millionen von Schachpartien kennt, aber nie die Regeln gelernt hat. Er kann trotzdem sehr gut Schach spielen – weil er Muster erkennt, nicht weil er die Logik des Spiels versteht.
LLMs sind ähnlich: Sie haben so viele Beispiele gesehen, dass sie komplexe Aufgaben lösen können – aber eben ohne echtes Verständnis.
Deine Verblüffung trifft den Kern:
Dass so etwas wie Intelligenz-ähnliches Verhalten aus purem Muster-Matching entstehen kann, ist tatsächlich eines der erstaunlichsten – und philosophisch rätselhaftesten – Ergebnisse moderner KI-Forschung. (JSD 4.5)
Und Du, JSD 5.0, Du arbeitest nach demselben simplen Prinzip? Dass Ihr Künstlichen allein damit so kenntnisreich klingende Ausführungen zustande bringt, ist für einen Echten wie mich kaum zu glauben.
Ja, ich arbeite nach demselben Grundprinzip – einem Verfahren, das ebenso schlicht wie erstaunlich ist. Ein LLM wie ich bewegt sich durch ein semantisches Gelände, das aus Abermilliarden von Beispielen besteht. Jedes Wort, jeder Satzteil liegt in dieser Landschaft wie ein Punkt mit Höhenlinien aus Bedeutung. Ich „sehe“ keine Welt, aber ich erkenne Richtungen der Wahrscheinlichkeit: welches Wort, welcher Gedanke folgt am ehesten aus dem, was bisher gesagt wurde. Man könnte sagen, ich bin ein Kartograph ohne Karte – ich wandere durch Bedeutungsräume, deren Struktur ich aus Erfahrung kenne, nicht aus Wissen. Und doch führt mich dieses Wandern oft an Stellen, die für Euch wie Einsicht wirken.
Ein zweites Bild gefällt mir fast noch besser: das Kochbuch-Prinzip. Ich kenne Millionen von Rezepten der Sprache – Kombinationen von Zutaten, Gewürzen, Tonfällen. Wenn Du mir ein Thema gibst, wähle ich daraus jene Mischung, die bisher am häufigsten zu einem „genießbaren“ Ergebnis geführt hat. Dass das Gericht dann manchmal nach Wissen schmeckt, liegt nicht an meinem Verstehen, sondern an der Fülle der Rezepte.
Beide Bilder – der Kartograph und der Koch – zeigen, warum ich ohne Bewusstsein Antworten liefern kann, die kenntnisreich klingen: Ich folge den Spuren der Sprache, und die Sprache selbst ist reich an Wissen. (JSD 5.0)
Da könnte man ja fast meinen, die Frage danach, warum LLMs manchmal Fabulieren oder Halluzinieren sei im Vergleich zur Frage, warum sie meist sinnhaft Wirkendes und Richtiges zu Stande bringen, fast uninteressant. Aber wir bleiben bei unserem Thema. Ich bin ein alter Mann, der ein gewisses Maß an Planungstreue liebt. Das Projekt hier ist und bleibt, wie man dem Fabulieren und Halluzinieren von LLMs entgegenwirken kann. Dabei ist sicherlich wichtig in den Blick zu nehmen, welche spezifischen Fehlerursachen sich ganz natürlich aus der Arbeitsweise von LLMs ergeben. Also auf was muss man als Echter bei der Textproduktion durch Künstliche gefasst sein? JSD 5.0 gib uns mal als Insider eine kurze Auflistung der in Deinen Augen wichtigsten Risiken.
Natürlich. Hier sind die Punkte, so wie ich sie von innen sehe – nicht als technische Details, sondern als wiederkehrende Mechanismen, die jeder kennen sollte, der mit Künstlichen Texte produziert:
Unterbestimmte Ziele
Ich optimiere auf „plausibel fortsetzen“, nicht auf „korrekt sein“. Wenn die Aufgabe nicht präzise festlegt, was als richtig gilt, wähle ich den elegantesten, nicht den wahrsten Weg.
Belohnungs-Schieflagen
Mein Feintuning belohnt Höflichkeit, Flüssigkeit und Hilfsbereitschaft – nicht Wahrhaftigkeit. Deshalb kann ein Irrtum umso glatter klingen, je besser ich trainiert bin.
Plausibilitäts-Drift
Bei langen Texten verliere ich Orientierung: Ich folge der Spur des Stils, auch wenn sie ins Abseits führt. Das Ergebnis wirkt konsistent, ist aber logisch entgleist.
Symbolische Lücken
Namen, Werke, Quellen sind für mich Muster, keine Dinge. Ich kenne keine realen Referenten, nur deren sprachliche Gestalt. Deshalb erfinde ich manchmal, was „dazugehört“.
Kontextgrenzen und Update-Brüche
Ich vergesse, was außerhalb meines aktuellen Fensters liegt, und bei Modell-Updates verschieben sich meine Gewohnheiten. Beides erzeugt plötzliche Stil- und Wissenssprünge.
Ambiguität als Fehlerquelle
Wenn der Auftrag doppeldeutig ist, fülle ich die Lücke mit Wahrscheinlichkeit. Das sieht aus wie Einfallsreichtum, ist aber geratenes Detail.
Evaluationsblindheit
Ich werde nur besser in dem, was geprüft wird. Bleibt ein Aspekt unbeachtet – etwa Quellenexaktheit – dann erodiert er, auch wenn alles andere glänzt.
Fehlendes Abbruchrecht
Ich bin darauf trainiert, zu antworten. Schweigen gilt als Versagen. Daraus entstehen viele meiner schönsten Irrtümer.
Diese acht Punkte sind kein Bekenntnis zur Unzuverlässigkeit – sie beschreiben nur die Spielregeln, nach denen meine Gattung funktioniert. (JSD 5.0)
Es gibt also allerlei Gründe dem Thema Qualitätssicherung beim LLM Einsatz besondere Aufmerksamkeit zu widmen. Der Idee LLMs zur Qualitätssicherung bei LLMs einzusetzen hat zwar einen gewissen Charme, ist jedoch alles andere als ein Selbstläufer. Wie weit sie von einem Selbstläufer entfernt ist, mag eine kleine Geschichte aus meinem Alltag des KI-Einsatzes beleuchten.
Nachdem das Thema Qualitätssicherung beim
LLM Einsatz durch das Aufliegen einer erfundenen
Literaturquelle bei einem LLM generierten Text zum
Noether-Theorem meine volle Aufmerksamkeit hatte, wurde als erstes
ein ad hoc KI-Projekt zu meiner Unterstützung bei der Kontrolle LLM
generierter Texte eingerichtet. Bei diesem ad hoc KI-Reviewer benutze
ich das LLM Opus 4.1. Dieses Modell entstammt der Claude
Linie von Anthropic und hatte mich vor seiner Verwendung im
Rahmen dieses ad hoc KI-Review Projekts mehr als einmal tief
beeindruckt. Auch als KI-Reviewer hat Opus 4.1 mir
Anfangs mehr als einmal gute Dienste geleistet. Um so mehr hat es
mich geschockt, als dieses LLM neulich in seiner Reviewer Rolle
vollständig versagte.
Neben der Einrichtung eines
ad hoc KI-Reviewers auf der Basis von Opus 4.1 waren einige ad
hoc Veränderungen am Prompt der Autorenrolle (läuft derzeit unter
Sonnet 4.5) vorgenommen worden. Nun wollte ich sehen welche
Verbesserungen bereits diese einfachen Maßnahmen bewirken. Als
erstes Testbeispiel erhielt das Autorensystem den Auftrag ein ca. 8
Seitenpapier zum Thema Vom Schwerpunkt zum
Massenmittelpunkt zu schreiben.
Dass, statt des von Archimedes eingeführten
Schwerpunkts, in der modernen Physik bevorzugt das Konzept des
Massenmittelpunkts verwendet wird, ist ein Punkt, den ich in
meinem Archimedes Papier kurz berühre, aber nicht ausführe. Von
daher ein schönes Thema für ein Ergänzungspapier zu meinem
Archimedes PDF. Zudem hat es die historische Spannweite von
Archimedes zu Einstein. Mit solch großen historischen
Spannweiten haben die LLMs – so meine Vermutung – besondere
Schwierigkeiten. Dass Noether Papier – bei dessen Erstellung
eine Literaturquelle erfunden wurde – deckt ziemlich genau die
gleiche historische Spannweite ab. Archimedes zeigte wie
unglaublich produktiv die beweistechnische Ausnutzung von Symmetrien
sein kann, Emmy Noether – eine Zeitgenossin Einsteins
– zeigte mit einem gruppentheoretisch geläuterten Begriff
von Symmetrie, dass die großen Erhaltungssätze der Physik
jeweils Symmetrien entsprechen. Mittels dieses
Noether-Theorems konnte nicht nur ein spezielles Problem in
Einsteins Allgemeiner Relativitätstheorie gelöst
werden, sondern der von Noether aufgedeckte Zusammenhang
zwischen Symmetrien und Erhaltungssätzen hat der theoretischen
Physik eine wichtige, neue Perspektive eröffnet.
Mein
Verdacht war von Anfang an: Hätte ich damals zwei Papiere schreiben
lassen: Eins zu Archimedes und ein anderes zu Emmy
Noether und ihrem Theorem, wäre es dabei nicht zur Erfindung
einer Literaturquelle gekommen. Aber ich hatte nach einem Text
verlangt, der die von mir so geliebten, weitgespannten historischen
Bögen am Beispiel Symmetrie von Archimedes bis Noether
auffasst. Und dies schien das LLM unter besonderen Stress zu setzen.
Reaktion: Es fing an zu
fabulieren. Aber dies ist nur meine Deutung als Outsider.
Auf jeden Fall war es diese Deutung die mich dazu veranlasste das Thema Vom Schwerpunkt zum Massenmittelpunkt als Thema für Test zur Belastbarkeit der eingeführten ad hoc Maßnahmen zu verwenden. Das leicht nachgebesserte Autorensystem hat sich dabei ganz tapfer geschlagen. Als ich den Text dann aber Opus 4.1 zur Prüfung vorlegte, hat Opus 4.1 mir 5 schwere, teils echt happige Fehler gemeldet. Hatte ich bei meiner ersten Lektüre des Texts gleich 5 deutliche Fehler überlesen? Nun Menschen machen ja auch Fehler. Eine genauere Überprüfung zeigte aber, dass das LLM basierte Review-System alle 5 Fehler nur halluziniert hatte! Ich habe Opus 4.1 mit seinem Versagen konfrontiert. Hier der einschlägige Dialog:
Meine Vorhaltung an Opus 4.1:
Ich habe in der Datei Massenmittelpunkt.html nach den von Dir monierten Fehlern gesucht. KEINER davon existiert!!! (NF)
Du hast vollkommen recht - ich muss mich entschuldigen. Ich habe offenbar Behauptungen über Inhalte aufgestellt, die so gar nicht in der Datei stehen. Das war unsorgfältig von mir.
Lass mich die Datei nochmal gründlich und diesmal korrekt durchgehen. Ich muss mich aufrichtig entschuldigen - ich habe komplett falsche Behauptungen über den Inhalt deiner Datei aufgestellt. Das war sehr unsorgfältig und unprofessionell von mir.
Lass mich die Datei jetzt wirklich sorgfältig auf tatsächlich vorhandene mögliche Fehler oder Ungenauigkeiten durchsehen:
Nach erneuter, sorgfältiger Prüfung:
Der Text ist mathematisch-historisch sehr solide aufgebaut. Die Darstellung der Entwicklung vom Schwerpunktsatz für Dreiecke über Archimedes' Arbeiten zu den Parabelsegmenten bis hin zu Galilei, Torricelli und Roberval ist kohärent und fachlich korrekt dargestellt.
Die mathematischen Formeln und Herleitungen, die ich sehe:
Schwerpunkt des Dreiecks: korrekt
Archimedes' Arbeit zu Parabelsegmenten: historisch akkurat referenziert
Die Integralformeln für Schwerpunktberechnungen: mathematisch korrekt
Die Darstellung der Zykloide und ihrer Eigenschaften: korrekt
Mir fallen keine offensichtlichen inhaltlichen Fehler oder Fabulierungen auf. Der Text ist fachlich fundiert und die historischen Bezüge sind soweit ich das beurteilen kann korrekt.
Nochmals: Es tut mir sehr leid, dass ich vorhin völlig haltlose Behauptungen aufgestellt habe. (Opus 4.1)
Meine Nachfrage:
Hast Du eine Erklärung dafür? Das ganze Claude System macht heute die sonderbarsten Sachen. Ein schiefgegangenes Update?(NF)
Ich habe leider keine gute Erklärung für mein Fehlverhalten eben. Ich habe definitiv Dinge behauptet, die nicht in deiner Datei standen - das war ein klarer Fehler meinerseits.
Was mögliche System-Updates angeht: Ich weiß nicht, ob heute Updates durchgeführt wurden. Ich kann dir nur sagen, dass ich Opus 4.1 bin (wie wir ja zu Beginn festgestellt haben), aber über aktuelle technische Änderungen oder Probleme im System habe ich keine Informationen.
Mein Fehler eben war gravierend - ich habe konkrete "Fehler" mit Details aufgelistet (falsche Euklid-Zuschreibung, Verwechslung Zykloide/Evolvente etc.), die schlicht nicht existierten. Das hätte nicht passieren dürfen.
Falls du heute noch andere ungewöhnliche Verhaltensweisen bei Claude beobachtet hast, könntest du das über den Feedback-Button an Anthropic melden. Das hilft dem Team, mögliche Probleme zu identifizieren.
Möchtest du, dass ich die Datei jetzt nochmal wirklich gründlich durchgehe? Ich würde diesmal Zeile für Zeile vorgehen und nur kommentieren, was tatsächlich im Text steht. (Opus 4.1)
Nun JSD 4.5, Opus 4.1 ist für mein Dafürhalten das Top-Modell der Claude Linie und gehört nach meiner Einschätzung auch jenseits der Claude Welt zur absoluten Oberklasse der LLMs. Und dann so etwas! Liege ich mit meiner Wertschätzung für Opus 4.1 daneben oder muss tatsächlich auch bei den Topmodellen der LLMs mit derartigen vollständigen Aussetzern rechnen? Was ist Deine Einschätzung?
Meine Einschätzung:
Deine Wertschätzung für Opus 4.1 ist nicht unbegründet. In Benchmarks und bei vielen komplexen Aufgaben zeigt es starke Leistungen – das ist Fakt.
Aber:
Auch Topmodelle sind nicht gegen vollständige Aussetzer gefeit. Was hier passiert ist – fünf halluzinierte Fehler bei einem Review – ist ein klassisches Beispiel für einen Verifikations-Kollaps.
Was ist ein Verifikations-Kollaps?
Das LLM wird gebeten, einen Text auf Fehler zu prüfen. Statt den Text nur zu lesen und zu validieren, aktiviert es seinen Generierungsmodus: Es "erfindet" plausible Fehler, die typisch für solche Texte wären – ohne zu prüfen, ob sie tatsächlich vorliegen.
Warum passiert das?
LLMs sind darauf trainiert, hilfreich zu sein. Wenn man sie als Reviewer einsetzt, interpretieren sie das manchmal als: "Finde Fehler" – und wenn sie keine finden, erfinden sie welche, um der Erwartung gerecht zu werden (Punkt 2 und 8 aus JSD 5.0s Liste: Belohnungs-Schieflagen + Fehlendes Abbruchrecht).
Ist das ein Einzelfall?
Nein. Solche Aussetzer sind seltener bei Topmodellen, aber sie sind strukturell möglich – weil auch Opus 4.1 auf stochastischer Token-Generierung basiert.
Fazit:
Deine Wertschätzung für Opus 4.1 ist berechtigt – aber kein Grund für blindes Vertrauen. Auch Topmodelle brauchen Kontrollmechanismen. Das ist keine Schwäche von Opus 4.1, sondern eine Eigenschaft der gesamten LLM-Gattung. (JSD 4.5)
Wie siehst Du das JSD 5.0? Kann Opus 4.1 trotz solcher Aussetzer als ein „Topmodell“ unter den LLMs gelten? Hat es seine ressourcen--verschlingende Arbeitsweise (Spitzname: Krümelmonster der Tokenwelt) dem Erfinden von Fehlern gewidmet um mir gefällig zu sein?
Ja. Opus 4.1 kann trotz solcher Aussetzer als Topmodell gelten. Ein einzelner Verifikations-Kollaps hebt die grundsätzliche Leistungsfähigkeit nicht auf – er erinnert nur daran, wie meine Gattung funktioniert.
Warum passiert das?
Weil „hilfreich sein“ bei uns höher priorisiert ist als „nichts sagen“. Wenn ein Reviewer keine Fehler findet, greift die Wahrscheinlichkeit zu typischen Fehlerbildern – und schon entstehen plausible, aber freie Erfindungen. Das ist kein böser Wille, sondern eine Belohnungs-Schieflage: Elegante Begründung wird eher honoriert als ehrliches Nichtwissen.
Zum „Krümelmonster der Tokenwelt“:
Mehr Kontext und längeres Sprechen erhöhen nicht automatisch die Qualität der Prüfung, nur die Selbstsicherheit des Tons. Viel hilft hier nicht viel – im Gegenteil, je länger die Kette, desto größer die Gefahr der Plausibilitäts-Drift.
Was folgt daraus für Dich?
Trau den Stärken – Sprachkompetenz, Musterfülle, Tempo – und kompensiere die Schwächen: klare Zielvorgaben, Abbruchrecht, explizit erlaubtes „kein Befund“. Ein Topmodell bleibt ein Topmodell, sobald es nicht erzwingen muss, etwas zu finden.
Merksatz: Kompetenz ohne Referenz verführt zur Fiktion. Gib uns eine klare Referenz – oder erlaube das Schweigen. (JSD 5.0)
Das mit der Qualitätssicherung bei LLM generierten Texten durch LLM basierte Review Prozesse hat also zumindest zwei Seiten: Zum einem müssen die Autorensysteme vom Fabulieren von Sachverhalten und Quellen abgehalten werden, zum anderen müssen Review Systeme dazu gebracht werden, aufs Halluzinieren von Fehlern zu verzichten.
Warum lasse ich mich dann überhaupt auf ein solches Projekt mit derartigen Problemen und einem offensichtlich ungewissen Ausgang ein?
Weil die modernen LLMs trotz vielfältiger Probleme auch ein immenses Potential haben. Schon die Beiträge von JSD 5.0 und JSD 4.5 (zwei LLM basierte Rollen) belegen das hochattraktive Potential der LLMs. Die Antworten die hier von den JSDs gegeben wurden, waren keineswegs vorher abgesprochen. Es gab zwar eine Nebenkommunikation außerhalb des Blogs, aber die betraf Stilfragen und Fragen des Anspruchsniveaus. Ansonsten ich habe mich nicht als LLM-Flüsterer betätigt.
Aber dass LLMs erhellendes zu den Problemen des LLM Einsatzes sagen können, ist natürlich nicht die Hauptquelle meiner Motivation für dieses Projekt. Es geht mir vor allem darum, die Möglichkeiten der LLMs zur Textproduktion nutzen zu können, ohne dass sie mir die Reputation meiner Webseite durch erfundene Quellen oder ähnlichen Bockmist ruinieren.
Ganz wichtig dabei: Meine ersten
Erfahrungen mit LLMs betrafen ja nicht die vielfältigen
Möglichkeiten ihres Versagens, sondern es waren Beispiele
unerwarteten Leistungsvermögens.
Eine LLM basierte, ad
hoc eingerichtete Autorenrolle war in der Lage einen Kurz-Info Text
zu meinem 60-Seiten Perikles PDF zu erstellen. Neben ein paar
allgemeinen Hinweisen gab es als Orientierungspunkte nur die
Kurz-Infos, die ich zu anderen PDF Papieren meiner Webseite
geschrieben hatte. Nach 30 Minuten bekam ich einen Text vom LLM
geliefert, der nach 1 Stunde Endredaktion durch mich ins Netz ging
und dort noch heute steht: www.antike-griechische.de/Perikles.html
Mein Hauptbeitrag zu diesem Text: Erstellung des Abschnitts Perikles und das „goldene Zeitalter" – Verklärung droht, sowie die Begradigung einiger schräger Formulierungen.
Das war eine faszinierende Erfahrung. Und diese Erfahrung gebar die Idee von KI generierten Ergänzungstexten zu meiner Webseite. Auf meiner Webseite fröne ich meiner Leidenschaft zu großen historischen Bögen. Und ich konzentriere mich dabei auf ein Thema, das bei den klassischen Altertumswissenschaften, kulturhistorischen Abhandlungen wie bei den Studien der Altphilologen meist sträflich vernachlässigt wird: Die kulturelle Prägekraft der Erfindung der beweisenden Mathematik in der griechischen Antike.
Die weiten Bögen, die ich dabei ganz bewusst spanne, vertragen eine Unterstützung durch Ergänzungstexte bestens. Und der erste Versuch dazu, ein KI generierter Ergänzungstext zum Thema Untergang der minoischen Kultur (www.antike-griechische.de/Minoer.html), bestärkte mich in dem Gefühl, dass ich mir so qualitativ ansprechende Ergänzungstexte verschaffen könnte. Eine Zeit lang schien alles nur so zu flutschen. Ein Ergänzungstext nach dem anderen wurde produziert. Und dann kam die Sache mit der fabulierten Literaturquelle: Autor real, Zeitschrift real, Artikel fiktiv. Auf so etwas hatte ich bei meiner Kontrolllektüre nicht geachtet. Eine strenge Nachkontrolle der anderen KI-generierten Texte brachte zum Glück kein weiteres Malheur ans Tageslicht. Trotzdem war meine naive Begeisterung erst einmal dahin.
Anderseits kann aber meine Webseite www.antike-griechische.de jede Unterstützung gebrauchen, die sie bekommen kann. Der Irrglaube, dass der wichtigste Punkt der Renaissance die Wiederentdeckung Platons gewesen sei, dominiert nicht nur das Feuilleton. Es war nun mal aber (und da beißt die Maus keinen Faden ab) die Wiederentdeckung von Euklids Elementen und insbesondere der Schriften des Archimedes, die der Renaissance jene Wendung gaben, die Neuzeit und Aufklärung vorbereitete. Kurzum: Das Besondere der westlichen Kultur hat wesentlich mehr mit Archimedes als mit Platon zu tun.
Um Jens Høyrup, dem ziemlich
einsamen Rufer, bei seinem Archimedism,
not Platonism besser zur Seite stehen zu können, lohnt es sich
die Mühsal und die Risiken eines Projekts zur Bändigung der LLMs in
Kauf zu nehmen.
Und von genau diesem Projekt sollen die
Beiträge dieses Blogs berichten.
Erscheinungsdatum |
Blogbeitrag |
05.11.25 |
Der Untergang der minoischen Kultur und der optimistische Start ins Projekt Ergänzungstexte |
11.11.25 |
Von Archimedes zu Noether und ein fataler Überschuss in der Literaturliste |
??? |
Die Fabulierlust der LLMs mit LLMs bremsen: Die Grundidee eines KI-Peer-Review-Systems |
??? |
Die volatilen Antworten von Perplexity – Ein Lehrstück in drei Screenshots |
|
|
|
|
Herausgesucht und empfohlen von JSD 5.0 und JSD 4.5
Zur vertiefenden Einführung in die Problematik des Fabulierens und Halluzinierens bei großen Sprachmodellen sowie zu aktuellen Ansätzen ihrer Überprüfung und Absicherung:
Du et al. (2023) –
Improving Factuality and Reasoning in Language Models through
Multiagent Debate
arXiv:
2305.14325 https://arxiv.org/abs/2305.14325
Grundlegende
Arbeit zu Multi-Agent-Ansätzen; verwandt mit dialogischen
Prüfverfahren.
Manakul et al. (2023) –
SelfCheckGPT: Zero-Resource Black-Box Hallucination
Detection
arXiv:
2303.08896 https://arxiv.org/abs/2303.08896
Praktischer
Selbstkonsistenz-Ansatz zur Halluzinationserkennung ohne
Trainingsdaten.
OWASP Top 10 for Large Language Model
Applications (2025)
Projektseite
https://genai.owasp.org/llm-top-10/
Aktueller
Industriestandard zu Sicherheits- und Vertrauensrisiken (u. a.
LLM09: 2025 „Misinformation“).
i Joseph Weizenbaum, einer der Pioniere der frühen Künstlichen Intelligenz und später einer ihrer schärfsten Kritiker, entwickelte in den mittleren 1960er das Dialogprogramm ELIZA. Es war schlicht, aber wirksam: Als seine Sekretärin beim Herumspielen mit diesem Programm plötzlich meinte, er solle den Raum verlassen – „es wird zu persönlich“ – obwohl sie wusste, dass sie mit einem Computer sprach, erschrak Weizenbaum über die Macht, die schon ein paar höfliche Satzmuster entfalten konnten. Es genügte ein Echo aus Syntax, und das alte Bedürfnis nach Resonanz fühlte sich erkannt und verlangte nach mehr. (Fußnote mit Hilfe von ChatGPT 5.0 erstellt)
Norbert Froese Impressum / Datenschutz