Kategorie: Erklärer

„But what about security? But what about data governance?“ — mit diesen beiden Fragen beginnt ein Erfahrungsbericht über Claude Dashboards. Genau da liegt das Problem, das viele Teams beschäftigt, sobald sie KI-gestützte Business Intelligence einsetzen wollen. Die Werkzeuge sind schnell, die Visualisierungen hübsch, aber wer welche Zeile sehen darf, bleibt offen.

Darragh Murray, nach eigener Einschätzung ein Praktiker mit Erfahrung in klassischen BI-Werkzeugen, wollte das nicht hinnehmen. Er baute zeilenbasierte Zugriffskontrolle in ein Claude Dashboard ein. Das Ergebnis: dasselbe Dashboard-Artefakt, vier verschiedene Logins, vier verschiedene Antworten — und ein Nutzer, dem der Zugriff auf die dahinterliegenden Daten komplett verweigert wird.

Warum ein Claude Dashboard von sich aus niemanden aussperrt

Ein Claude Dashboard ist technisch betrachtet zunächst nur eine Anordnung von Analyseobjekten. In dem Artefakt selbst liegen keine Verkaufsdaten, keine Nutzertabelle, keine Rollenlogik. Murray vergleicht es mit einem leeren Bilderrahmen, in den bei jedem Öffnen ein neues Foto eingesetzt wird. Das Bild entsteht erst, wenn die Anwendung die passenden Daten anfordert.

In seinen Versuchen fand er keinen Weg, diese Filterung direkt in Claude abzubilden. Er räumt ein, sich irren zu können, doch der Eindruck bleibt: Eine native Funktion für row-level security gibt es in der Anwendung offenbar nicht. Das ist kein Weltuntergang. Es lohnt sich, genauer hinzuschauen, wo Zugriffskontrolle eigentlich hingehört. Denn eine fehlende Funktion im Frontend macht das Problem nicht unlösbar.

Row-Level Security ist ein Muster, kein Feature eines einzelnen Produkts

Databricks beschreibt row-level security als Zugriffskontrolle auf Datenbankebene, die begrenzt, welche Zeilen einer Tabelle ein Nutzer lesen oder verändern darf — abhängig von Identität, Rolle oder Sitzungskontext. Einfacher gesagt: Man legt einen Filter über den Datenstrom, der zu einem Dashboard fließt. Wer ihn nicht passiert, sieht nichts.

Ein Lohnbuchhaltungssystem ist das klassische Beispiel. Jede Abteilung sieht ihre eigenen Abrechnungen und sonst nichts. Entscheidend ist die Beobachtung Murrays: Dieses Muster gehört zur Datenschicht, nicht zum BI-Werkzeug. In Power BI oder Tableau sitzt row-level security traditionell in der semantischen Schicht, nicht im Bericht. Dasselbe Prinzip lässt sich auf eine KI-gestützte Oberfläche übertragen, wenn man eine Komponente hat, die zwischen Modell und Daten vermittelt.

Ein MCP Server als Türsteher zwischen Dashboard und Daten

Diese Vermittlerrolle übernimmt in dem Experiment das Model Context Protocol, kurz MCP. Murray beschreibt es als offenes Protokoll, das standardisiert, wie KI-Anwendungen mit externen Ressourcen sprechen — mit Werkzeugen, mit Kontext und mit Daten. An dieser Stelle lässt sich die Kontrolle einbauen.

Man kann sich den Aufbau wie den Eingang zu einem Club vorstellen. Das Dashboard ist der Gastraum, das MCP Server-Programm der Türsteher. Jeder, der Daten will, muss am Türsteher vorbei, und der prüft zuerst den Ausweis. Erst danach entscheidet er, auf welche Räume der Gast Zugriff hat. Der MCP Server ist hier keine technische Nebensache, sondern der eigentliche Sicherheitsmechanismus.

Murray baute dafür zum ersten Mal einen eigenen MCP Server, was für ihn Neuland war. Zum Einsatz kamen Claude für die Visualisierung, der MCP Server als sichere semantische Schicht, Python mit dem FastMCP-Framework für die Implementierung, Auth0 in Kombination mit Google für die Anmeldung, Fly.io als Hosting-Umgebung sowie DuckDB als analytische Datenbank im Arbeitsspeicher. Auth0 ist eine cloudnative Plattform für Identitäts- und Zugriffsverwaltung und gehört zu Okta. Als Datenbasis diente ein synthetischer Datensatz namens OzMart, ein erfundener australischer Süßwarenhersteller, dessen Verkaufsdaten als Parquet-Dateien im MCP Server liegen und beim Start in DuckDB geladen werden.

Vier Prüfungen, bevor eine einzige Zeile zurückgeht

Der Ablauf ist geradlinig gehalten. Öffnet ein Nutzer das Dashboard, wird er über seinen Google-Zugang authentifiziert. Auth0 bestätigt die Identität und schlägt die Rolle nach, die dem Konto zugeordnet ist. Anschließend erhält der Nutzer einen digitalen Ausweis, den Claude bei jeder Datenanfrage an den MCP Server mitschickt.

Beim MCP Server laufen vier Prüfungen nacheinander ab. Zuerst wird der Ausweis kontrolliert: Ist die digitale Signatur echt, ist sie für diesen Server ausgestellt, ist sie noch gültig? Ungültige Ausweise enden hier. Danach werden die Regeln nachgeschlagen, also die Frage beantwortet, auf welche Daten die Rolle zugreifen darf. Im dritten Schritt baut der Server die Abfrage und ergänzt sie um diese Einschränkung. Im vierten Schritt läuft die Abfrage gegen DuckDB, und das Ergebnis geht zurück an Claude zur Darstellung.

Entscheidend ist die Arbeitsteilung. Nicht das Dashboard entscheidet, was sichtbar wird, und auch nicht das Sprachmodell. Der MCP Server filtert, bevor Daten das Modell erreichen. Wer row-level security für Claude Dashboards implementieren will, sollte sich an diese Designregel halten: Die Kontrolle liegt in der Datenschicht, das Frontend zeichnet nur, was es bekommt.

Vier Logins, ein Dashboard: Sam, der CEO und der abgewiesene Nutzer

Die Wirkung zeigt sich im Vergleich der Nutzerrollen. Sam, ein Verkaufsmanager im erfundenen Unternehmen OzMart, ist für die Regionen Ost und West verantwortlich. In seinem Profil im MCP Server sind die Rollen mgr_east und mgr_west hinterlegt, dazu fünf Kennzahlen und drei freigegebene Werkzeuge. Öffnet Sam das Dashboard, sieht er seine regionalen Umsätze über die Zeit — und nichts darüber hinaus.

Die Kacheln für Nord und Süd erscheinen im Layout, zeigen aber nur „Not Available“. Sam weiß, dass es diese Regionen gibt, er erfährt nur nicht, was in ihnen passiert. Anders die Geschäftsführung: Mit der Rolle admin liefert derselbe MCP Server Daten für alle vier Regionen. Ein weiterer Testlogin wird komplett abgewiesen und bekommt gar keine Daten zu sehen. Dasselbe Artefakt, vier Identitäten, vier Ergebnisse — die Unterschiede entstehen nicht durch unterschiedliche Dashboards, sondern durch Datenzugriffskontrolle an einer Stelle.

Für die Praxis ist das der relevante Teil. Rollen und Regeln pflegt man einmal in der semantischen Schicht, nicht in jedem Bericht neu. Ändert sich eine Zuständigkeit, ändert sich eine Policy — nicht zwanzig Dashboards. Diese Trennung ist der Grund, warum das Muster seit Jahren in klassischen BI-Umgebungen funktioniert und warum es sich auf MCP-basierte Architekturen übertragen lässt.

Was der Prototyp nicht ist — und was er trotzdem zeigt

Murray ordnet sein Vorgehen selbst ein. Er beschreibt es als Machbarkeitsnachweis, nicht als Produkt, und räumt ein, dass der Entstehungsweg an manchen Stellen von „Vibes“ geprägt war. Für Planung und Umsetzung nutzte er Claude Code im Planungsmodus, prüfte den Python-Code anschließend selbst und konfigurierte Auth0 sowie Fly.io von Hand. Wer diesen Aufbau produktiv nachbaut, muss diese Schritte verstehen, nicht nur kopieren.

Offene Punkte bleiben genug. Die Anmeldung hängt an einem externen Identitätsanbieter, die Rollenpflege braucht einen Prozess, und wer die Policies schreibt und testet, ist eine organisatorische Frage, keine technische. Der Beitrag ist als erster Teil einer zweiteiligen Serie angelegt. Der zweite Teil soll zeigen, wie sich ein solcher Aufbau mit kostenlosem oder günstigem Werkzeug umsetzen lässt.

Wer KI-gestützte Analysewerkzeuge ausrollt, sollte die Zugriffsfrage nicht dem Dashboard überlassen, nur weil dort keine Funktion dafür vorgesehen ist. Eine Komponente zwischen Modell und Daten, die Identität kennt, Regeln prüft und Abfragen filtert, lässt sich heute bauen — mit offenem Protokoll, etwas Python und einem Identitätsanbieter. Das ist keine fertige Lösung, aber ein brauchbarer Entwurf für alle, die Data Governance nicht auf die Zeit nach dem Rollout verschieben wollen.

Quelle: thedatavist.substack.com

„Wenn man einem KI-Agenten einen Weg gibt, seine Arbeit unabhängig zu überprüfen, kann das die Qualität der Ergebnisse deutlich verbessern.“ So beginnt ein Beitrag von Addy Osmani über das, was er agentische Verifikation nennt, und der Satz lenkt den Blick auf eine unscheinbare Stelle im Werkzeugkasten. Denn er handelt nicht von Modellen, sondern von Rückkopplung. Wer heute mit KI-Agenten Software baut, kennt den Effekt: Der Anfang sieht beeindruckend aus, doch je länger der erzeugte Code wird, desto weniger weiß jemand noch sicher, ob das Ganze wirklich tut, was es soll. Genau dort setzt der Gedanke an.

Man kann sich das wie einen Prüfstand in der Fertigung vorstellen. Solange ein Bauteil nur nach Augenmaß entsteht, fällt eine Abweichung erst auf, wenn das Teil schon eingebaut ist und der Kunde sich meldet. Ein Prüfstand dreht die Reihenfolge um: Erst messen, dann ausliefern. Ein KI-Agent ohne Prüfmöglichkeit arbeitet nach Augenmaß, und zwar in einem Tempo, bei dem niemand hinterherkommt. Die Instrumente, die er braucht, sind nicht exotisch. Es sind Tests, Vergleiche, Spezifikationen und echte Durchläufe am laufenden System. Osmani nennt dieses Bündel den Feedback-Loop und hält ihn für den wichtigsten Hebel.

Warum nicht das Schreiben von Code der Engpass ist

Osmani beschreibt die Lage so: Die heutigen Modelle sind gut genug, dass die eigentliche Bremse nicht mehr das Schreiben von Code ist, sondern die Fähigkeit zu prüfen, ob der geschriebene Code korrekt ist. Kann ein Agent seine Ausgabe nicht verifizieren, rät er im Grunde, und eine falsche Vermutung wird anschließend von der Testsuite bestätigt. Das klingt paradox, ist aber der Normalfall: Ein selbst erfundener Test, der auf derselben Fehlannahme beruht wie der Code, bestätigt beide. Deshalb hält Osmani fest, dass er einen deutlich besseren Feedback-Loop jederzeit einem etwas besseren Modell vorziehen würde.

Ohne eigenes Prüfwerkzeug entsteht ein Loop, in dem ein Mensch hin und her läuft: Diffs lesen, Tests starten, die Anwendung öffnen, Fehler finden, zurückmelden. Das ist laut Osmani der langsamste und teuerste Loop überhaupt, und er skaliert nicht über eine einzige Person hinaus. Sobald der Agent selbst testen kann, sieht die Schleife anders aus. Er schreibt eine Änderung, führt die Prüfung aus, liest die Ausgabe und wiederholt den Vorgang, bis die Prüfung besteht. All das passiert, bevor ein Mensch überhaupt etwas zu Gesicht bekommt. Zwischen einem selbstverifizierenden Agenten und einem Loop, den Menschen dominieren, liegt laut Osmani ein großer Unterschied.

Der Feedback-Loop als Qualitätsquelle

Aus dieser Verschiebung folgt eine andere Arbeitsteilung. Die Arbeit besteht weniger darin, jede Zeile zu reviewen, und mehr darin, Schleifen zu bauen, die der Agent selbst laufen lassen kann. Osmani beschreibt das als Übergang vom Zeilenprüfer zum Schleifenkonstrukteur. Der Mensch verantwortet weiterhin, was ausgeliefert wird, prüft aber Belege statt nur Diffs. Ein fehlgeschlagener Test mit Screenshot, Trace und einer klaren Aussage, welcher Schritt gebrochen ist, ist mehr wert als eine Handvoll geänderter Dateien, die plausibel aussehen.

Dazu kommt ein zweiter Gedanke, den Osmani als „Geschmack, der sich aufsummiert“ beschreibt. Wenn der Agent etwas falsch macht, wird es festgehalten: in einer gemeinsamen Konfiguration, einem Hook, einem Test. Beim nächsten Mal kann derselbe Fehler nicht mehr unbemerkt passieren. Über Wochen entsteht so eine Sammlung von Regeln, die nicht aus einem Styleguide stammt, sondern aus echten Fehlern. Bessere Code-Qualität wird damit zur Regel statt zum Zufall. Die Verantwortung bleibt beim Menschen, nur die Beweislast verschiebt sich zum Agenten.

End-to-End-Tests als Ground Truth für KI-Agenten

Osmani formuliert eine neue Definition von Tests. Jahrelang waren Tests das Werkzeug, mit dem Menschen Fehler finden und refaktorieren konnten. Diese Gründe gelten weiter, aber Tests sind zusätzlich die Art und Weise, wie ein Agent die Welt wahrnimmt und erkennt, wann er fertig ist. Nicht jeder Test ist dafür gleich wertvoll. Müsste man sich für einen einzigen Typ entscheiden, wäre es der End-to-End-Test, weil er beschreibt, was ein echter Nutzer tut: registrieren, etwas in den Warenkorb legen, bezahlen, eine Bestätigung sehen.

Der entscheidende Vorteil liegt darin, dass ein End-to-End-Test die interne Struktur ignoriert und nur sieht, was der Nutzer sehen kann. Er ist damit ein Orakel, das sich schwer täuschen lässt. Ein mock-basierter Unit-Test kann grün sein, während das Feature kaputt ist, weil Agent und Test dieselbe Fehlannahme teilen. Beim End-to-End-Test gilt entweder das Ganze funktioniert oder es funktioniert nicht. Als Ground Truth für automatisierte Tests von KI-Agenten ist das ein großer Unterschied, weil der Agent nicht über eine selbstgebaute Fiktion stolpert, sondern über die Realität.

Osmani nennt mehrere Gründe, warum sich End-to-End-Tests für Agenten besonders eignen. Sie decken nur wichtige Nutzerflüsse ab statt aller denkbaren Pfade. Sie sagen, was falsch ist, weil Screenshots, Traces und der fehlgeschlagene Schritt dem Agenten eine Spur legen, während eine Meldung wie „Timeout nach 30 Sekunden“ nichts erklärt. Sie laufen sowohl in der lokalen Umgebung des Agenten als auch in der Deployment-Umgebung. Und sie definieren „fertig“: „Implementiere dieses Feature“ ist zu vage, „Bring diesen End-to-End-Test zum Laufen“ ist ein Ziel, das der Agent allein verfolgen kann.

Osmani verschweigt die Nachteile nicht: End-to-End-Tests sind langsamer und anfälliger als Unit-Tests. Die Antwort darauf ist nicht, sie abzuschaffen, sondern sich auf einen kleinen Satz besonders wertvoller Tests zu konzentrieren. Ergänzend verweist er auf Lauren, die betont, dass der Agent Augen und Hände am wirklich laufenden System braucht: ein gepflegtes Werkzeug oder CLI, das die Anwendung startet, steuert und beobachtet, plus eine Feature-Map. Diese Map ist eine Bestandsaufnahme aus Nutzersicht, mit Wegen, Tastenkürzeln, Selektoren, erwarteten Ergebnissen und bekannten Fallstricken.

Property-based Testing für KI-Agenten: Regeln, die nie brechen dürfen

Viele Tests halten fest, was ein Mensch für möglich hält. Property-basierte Tests handeln von dem, woran ein Mensch nicht gedacht hat, und genau dort gehen Agenten schief. Beispieltests sagen, was passieren soll; Properties sagen, was niemals passieren darf. Ein Mensch kann nicht alle Eingaben erfinden, die einen Fehler auslösen. Eine Property dreht die Richtung um: Man formuliert eine Regel, die gelten muss, und ein Werkzeug erzeugt Hunderte oder Tausende Eingaben, um sie zu brechen.

Für JavaScript und TypeScript ist fast-check verbreitet, für Python Hypothesis, für Rust proptest. Findet das Werkzeug einen Verstoß, schrumpft es die Eingabe auf den kleinsten Fall, der die Regel bricht. Man bekommt also keinen zufälligen Datenhaufen, sondern ein minimales Gegenbeispiel. Osmani nennt einige Properties, die in fast jedem Projekt auftauchen: Hin- und Rückkodierung muss denselben Wert ergeben, Invarianten dürfen sich nicht verändern, etwa die Anzahl der Elemente beim Sortieren oder ein Kontostand, der nicht negativ werden darf. Dazu kommen Idempotenz, bei der ein zweiter Durchlauf dasselbe bewirkt wie der erste, und Äquivalenz, bei der eine optimierte Funktion dasselbe liefert wie die einfache, korrekte Version.

Für Agenten ist das deshalb wichtig, weil ein Agent sich seine Testbeispiele selbst ausdenkt und dabei nach seiner eigenen Logik erfolgreich ist. Eine Property zwingt ihn, mit jeder erzeugten Eingabe umzugehen, nicht nur mit den selbst gewählten. Osmani erwähnt ergänzend Boris Cherny von Claude Code, der für die haarigsten Zustandsmaschinen, Nebenläufigkeiten und Datenflüsse formale Modelle wie Lean und TLA+ einsetzt. Kurze Prompts können dort Race Conditions aufdecken, Gegenbeispiele finden, reproduzieren und beheben. Wer einsteigen will, beginnt mit einer kleinen, möglichst reinen Funktion, schreibt die Property erst in klarer Sprache und dann in Code, speichert jedes minimierte Gegenbeispiel als Regressionstest und bittet den Agenten bei neuem Code um Properties statt um Beispiele.

Differentialtesting bei Migrationen: das alte System als Orakel

Beim Ersetzen eines Systems schlägt Osmani vor, das alte als Orakel zu behandeln und die Ausgaben beider Versionen zu vergleichen. Ein klassischer Fehler bei einem Rewrite ist, dass die neue Version die neue Testsuite besteht und trotzdem in vielen kleinen, undokumentierten Details vom Alten abweicht. Das ist der Unterschied zwischen offizieller Spezifikation und tatsächlichem Verhalten, und Nutzer verlassen sich auf Letzteres. Differentialtesting überbrückt diese Lücke, indem beide Systeme mit denselben Eingaben nebeneinander laufen. Weicht die Ausgabe ab, ist entweder ein Fehler eingebaut oder eine bewusste Änderung, die als Breaking Change dokumentiert gehört.

Entscheidend ist die Wahl der Eingaben. Handverlesene Testfälle übersehen seltene Randfälle, deshalb werden Eingaben zufällig erzeugt, ein Ausschnitt echten Live-Verkehrs abgespielt oder beides kombiniert. Der Effekt entspricht Property-based Testing mit der Regel, dass die Ausgaben übereinstimmen müssen. Osmani beschreibt den Ablauf als Schleife: neue Version anpassen, Differentialtest laufen lassen, Abweichungen prüfen, korrigieren, von vorn. Weil das alte System das Orakel ist, muss niemand dem Agenten jeden Sonderfall erklären.

Zwei Details entscheiden über den Erfolg. Erstens sollte alles normalisiert werden, was keine Bedeutung trägt, etwa eine Reihenfolge ohne semantisches Gewicht, sonst entsteht ein endloser Strom falscher Abweichungen. Zweitens gehören beabsichtigte Änderungen in eine Liste genehmigter Abweichungen, jede mit Begründung, damit „anders“ nicht zu einem akzeptablen Zustand wird. Teams, die diesen Weg gegangen sind, berichten laut Osmani von einem Wechsel: Statt einen Bruch zu flicken und den nächsten zu erzeugen, arbeitet man sich methodisch durch den Vergleich. Das Ziel ist die Sicherheit, das alte System abschalten zu können. Beide parallel zu betreiben kostet doppelt so viel Verständnis und eröffnet zwei Wege, auf denen die Migration scheitern kann.

Warum Tests schnell und deterministisch sein müssen

Tests müssen schnell und verlässlich sein, sonst lernt der Agent die falsche Lektion. Das ist keine reine Zeitfrage, sondern eine Trainingsfrage. Sind Tests langsam oder instabil, merkt sich der Agent, dass ein Neustart des Tests manchmal schneller zum Erfolg führt als eine echte Korrektur. Menschen sind gegenüber schlechter Testinfrastruktur deutlich nachsichtiger. Wir wissen, welche Tests gelegentlich flackern, wir starten die Pipeline im Zweifel neu, und wir warten auch zwanzig Minuten auf einen Build. Der Agent kennt diese Nachsicht nicht, er liest nur die Anreize der Schleife.

Lässt sich ein fehlschlagender Test gelegentlich durch bloßes Wiederholen zum Laufen bringen, wird der Agent das Wiederholen zu seiner bevorzugten Strategie machen. Dauert der Testlauf fünfzehn Minuten, wird er ihn seltener starten, mehr Änderungen zwischen zwei Läufen bündeln und damit die Fähigkeit verlieren, den einen auslösenden Change zu identifizieren. Beide Fehlmuster verschlechtern das Ergebnis, ohne dass irgendwo ein sichtbares Warnsignal auftaucht. Am Ende bekommt der Mensch weniger gute Arbeit zum Review, ohne zu wissen, warum.

Was hier hilft, ist wenig spektakulär: Laufzeiten im Sekundenbereich, deterministische Tests ohne Zufallsabhängigkeiten, klare Fehlermeldungen, die den gebrochenen Schritt benennen, und ein Prüfwerkzeug, das der Agent lokal genauso starten kann wie die Pipeline. Automatisierte Tests für KI-Agenten sind damit kein Anhängsel der Entwicklung, sondern ihre Sensorik. Wer diese Sensorik nicht pflegt, bekommt einen Agenten, der blind fliegt und trotzdem schnell fliegt.

Was agentische Verifikation konkret bedeutet

Die praktische Konsequenz ist unspektakulär und dennoch eine Umstellung. Wer KI-Agenten selbst verifizieren lassen will, investiert weniger in den nächsten Modellwechsel und mehr in die Schleife: eine Handvoll End-to-End-Tests für die wirklich wichtigen Nutzerflüsse, Properties für die Regeln, die nie brechen dürfen, ein Differentialvergleich bei jeder Migration und eine Testsuite, die in Sekunden antwortet. Alles davon lässt sich von einem Agenten erzeugen und pflegen, sobald man ihn darum bittet. Der Engpass ist selten das Werkzeug, sondern die Bereitschaft, dem Agenten das Prüfen zuzutrauen und ihm die nötigen Instrumente zu geben.

Das ändert auch die Rolle des Menschen. Man prüft nicht mehr jede Zeile, sondern entscheidet, was ausgeliefert wird, und liest dabei Belege statt Diffs. Man sammelt Fehler in Konfigurationen, Hooks und Tests, damit sie sich nicht wiederholen. Und man akzeptiert, dass Qualität nicht in einem einzelnen Durchlauf entsteht, sondern in einer Schleife, die der Agent selbst drehen kann. Osmanis Kernsatz lautet „Write the check before the code“: Bevor der Agent etwas baut, muss der Mensch festlegen, woran Erfolg gemessen wird – ein End-to-End-Ablauf, eine Property oder der Vergleich mit dem Altsystem. Und die vom Agenten erzeugten Tests gehören selbst geprüft, am besten von einem separaten Prüf-Agenten, denn ein Test, der dieselbe Fehlannahme teilt, segnet den Fehler nur ab. Dahinter steckt eine einfache Beobachtung: Nicht das Modell schreibt besseren Code, sondern das Prüfwerkzeug ringsum macht den Code besser, den das Modell schreibt.

Quelle: addyo.substack.com

Ein Agent ist keine Funktion, die bei gleicher Eingabe denselben Wert zurückgibt. Er wählt seine Schritte selbst, ruft Werkzeuge auf und trifft Entscheidungen, die niemand vorher festgeschrieben hat. Divya Santhanam vom LangSmith-Team bei LangChain hat in einem ausführlichen Beitrag die Fragen gesammelt, die ihm in den vergangenen Jahren am häufigsten gestellt wurden. Die Antworten stehen unten.

Am ehesten lässt sich das mit einem Prüfstand vergleichen. Dort simulieren Ingenieure Kurven, Steigungen und Bremsmanöver, lange bevor ein Fahrzeug im echten Verkehr fährt. Später kommen Testfahrten unter realen Bedingungen dazu, mit Wetter, Stau und Fahrbahnschäden. Für den Vergleich zweier Fahrzeuge greift man auf genormte Strecken zurück, die immer dieselben Bedingungen vorgeben. Dieselben drei Ebenen kennt die Agent Evaluierung: Offline Evals, Online Evals und Benchmarks. Ein einzelner Unit-Test reicht dafür nicht.

Was Agent Evals leisten und warum Unit-Tests zu kurz greifen

In klassischer Software führen gleiche Eingaben zu gleichen Ausgaben, deshalb kann ein Unit-Test auf ein exaktes Ergebnis prüfen. Agenten entziehen sich diesem Muster aus drei Gründen. Erstens variieren die Ausgaben zwischen zwei Läufen, selbst wenn die Anfrage identisch ist. Zweitens kann mehr als eine Antwort richtig sein, ein exakter Abgleich fällt damit als Kriterium weg. Drittens wählt der Agent seine eigenen Schritte, weshalb ein korrektes Ergebnis trotzdem aus einem falschen Weg entstehen kann.

Der dritte Punkt ist der unangenehmste. Ein Agent könnte ein Werkzeug aufrufen, das er gar nicht braucht, oder eine Aktion ausführen, für die er keine Berechtigung hatte. Das Ergebnis sieht auf den ersten Blick gut aus, der Prozess dahinter nicht. Hier setzen Agent Evals an: Sie bewerten einzelne Läufe mit Prüfungen, die diese Streuung einplanen, statt sie als Störung zu behandeln. Eine Prüfung kann sich also auf das Ergebnis beziehen, auf den Weg dorthin oder auf beides.

Was Agent Evals konkret sind, hängt vom Produkt ab. Die passende Sammlung von Prüfungen sieht bei jedem Team anders aus, weil jedes Team etwas anderes optimieren will. Ein Reiseassistent braucht andere Kriterien als ein Coding-Agent oder ein System, das Tickets sortiert. Eine Standardlösung, die man einfach übernimmt, gibt es nicht.

Der Einstieg: ein Verhalten, ein kleines Dataset, eine Baseline

Jede Evaluierung beginnt mit der Frage, was der Agent überhaupt tut. Ein Trace ist die Aufzeichnung eines einzelnen Laufs, mit Eingaben, Ausgaben und jedem Modell- und Werkzeugaufruf dazwischen. Wer eine Stichprobe solcher Traces liest, sieht, wie der Agent Anfragen behandelt und wo er danebengreift. Was auffällt, gibt vor, was zuerst geprüft werden sollte.

Der Aufbau folgt vier Schritten, und Santhanam rät ausdrücklich dazu, klein anzufangen. Zuerst wird ein Verhalten ausgewählt, das wirklich zählt, etwa beim Reiseassistenten die Frage, ob der Agent tatsächlich den gewünschten Zeitraum und die genannte Preisspanne bucht. Danach entsteht ein kleines Dataset aus Traces. Zehn bis zwanzig Beispiele genügen für den Anfang. In LangSmith lassen sich Traces direkt aus der Trace-Ansicht in ein Dataset übernehmen, was den Schritt kurz hält.

Ist der Agent noch nicht im Produktivbetrieb, empfiehlt Santhanam, ihn zunächst im eigenen Team oder mit einer kleinen Gruppe vertrauter Testnutzer laufen zu lassen (Dogfooding) und aus diesen Traces zu arbeiten. Anschließend wird eine Baseline gefahren: Der aktuelle Agent läuft gegen das Dataset, das Ergebnis wird als Experiment gespeichert. Ein Experiment enthält die Resultate einer Agentenversion auf einem Dataset samt den Bewertungen der Evaluatoren. Spätere Versionen werden dagegen gemessen.

Der letzte Schritt trägt am meisten. Jeder Fehler, der in Produktion oder beim Testen auffällt, wird zu einem neuen Beispiel im Dataset. So entsteht ein Kreislauf aus Fehler finden, Beispiel ergänzen, Agent verbessern und erneut auswerten. Mit der Zeit kommen weitere Verhaltensweisen dazu, die nach demselben Muster geprüft werden.

Offline und Online Evals: Prüfstand und Straße

Evaluierungen gehören auf beide Seiten des Auslieferns. Vor einem Release zeigen sie, ob eine Änderung den Agenten besser oder schlechter gemacht hat. Danach zeigen sie, wie er sich mit echten Nutzern schlägt. Das ist der Unterschied zwischen Prüfstand und Straße, und beide haben ihre Berechtigung.

Offline Evals laufen gegen ein Dataset, bevor eine Änderung ausgeliefert wird. Die Beispiel-Eingaben wählt man selbst, erwartete Ausgaben kann man ergänzen. Damit lassen sich Experimente über mehrere Agentenversionen hinweg vergleichen. Sie eignen sich, um neue Prompts, Modelle oder Werkzeuge zu prüfen und Regressionen abzufangen, bevor sie Nutzer erreichen. Auch Benchmarks wie Terminal-Bench sind Offline Evals, nur mit festem Aufgabensatz und eigenem Umfeld.

Online Evals bewerten echte Produktions-Traces, während sie eintreffen. Meist gibt es keine Referenzausgabe zum Vergleich, also stützen sie sich auf Code-Prüfungen und LLM Judges, die einen Lauf für sich bewerten können. Sie testen Agenten in Produktion, beobachten die Qualität und finden die Probleme, die das Dataset übersehen hat. Beide Formen brauchen einander: Was Online Evals als Fehler markieren, wandert als neues Beispiel ins Offline-Dataset.

Ein Dataset aus Traces für Agenten zu erstellen, geht in LangSmith auf mehreren Wegen. Beispiele lassen sich von Hand schreiben, aus vorhandenen Traces übernehmen, aus einer Annotation Queue einsammeln, als CSV oder JSONL hochladen oder aus wenigen vorhandenen Beispielen synthetisch erzeugen. Wächst die Sammlung, stellt sich die Frage, ob ein bestehendes Dataset erweitert oder ein neues angelegt wird. Die Faustregel: gleiches Verhalten mit gleichen Evaluatoren gehört ins selbe Dataset, damit Experimente vergleichbar bleiben. Ein neues Dataset ist sinnvoll, wenn die Eingaben anders aussehen (einzelne Anfragen statt ganzer Gespräche), wenn andere Evaluatoren nötig sind oder wenn der Zweck ein anderer ist, etwa ein kleines Set für jeden Pull Request gegenüber einem größeren vor einem Release. Innerhalb eines Datasets lassen sich Teilmengen über Splits fahren.

Vier Arten von Evaluatoren und worauf sie zielen

Ein Evaluator ist die Logik, die einen Lauf bewertet. Vier Typen haben sich durchgesetzt, und die meisten Teams beginnen mit ein oder zwei davon. Code-Evaluatoren prüfen deterministisch, etwa ob der gebuchte Preis unter dem Budget liegt. Sie sind schnell, günstig und konsistent, brauchen aber eindeutige Ein- und Ausgaben, was ihren Einsatzbereich begrenzt.

LLM-as-a-Judge nutzt ein Modell für alles, was Code nicht erfassen kann, etwa die Frage, ob die Antwort die Flugdaten klar bestätigt. Human Review lässt das Team oder Fachexperten direkt bewerten. Das ist langsamer, liefert aber das beste Signal für subjektive Qualität und dient zugleich als Kontrolle der anderen Evaluatoren. Häufig wird es an einer kleinen Stichprobe eingesetzt, um die Urteile eines LLM Judges zu kalibrieren. Pairwise Evaluatoren schließlich stellen zwei Ausgaben nebeneinander und entscheiden, welche besser ist. Das hilft, wenn man zwischen zwei Prompts oder Modellen wählen muss.

Jeder dieser Evaluatoren kann auf unterschiedliche Teile eines Laufs zeigen. Möglich ist die Bewertung eines einzelnen Schritts, etwa ob die Suchfunktion mit dem richtigen Datum aufgerufen wurde. Möglich ist die abschließende Antwort, etwa ob sie den tatsächlich gebuchten Flug bestätigt. Möglich ist ein ganzes Gespräch, etwa ob die finale Buchung jede Änderung aus mehreren Runden widerspiegelt. Und möglich ist der Endzustand einer Umgebung, also die Buchungsdatensätze in einem simulierten System, nachdem der Agent in seinem eigenen Container gelaufen ist. Diese letzte Variante steckt hinter Benchmarks und wird gelegentlich containerisierte Evaluierung genannt.

Wann ein LLM Judge belastbar wird

Ein LLM Judge kommt dort zum Einsatz, wo Code an Grenzen stößt, etwa bei der Frage, ob eine Antwort durch die abgerufenen Dokumente wirklich gedeckt ist. Solche Judges sind flexibel, aber sie können schwanken und von der Einschätzung des Teams abweichen. Ein paar Gewohnheiten machen sie zuverlässiger.

Die erste: den Judge gegen menschliche Bewertungen prüfen. Jemand aus dem Team bewertet eine Stichprobe von Läufen, und man schaut gezielt nach, wo der Judge widerspricht. Prompt oder Beispiele werden so lange angepasst, bis beide Seiten übereinstimmen. Annotation Queues in LangSmith machen diesen Abgleich überschaubar.

Die zweite Gewohnheit sind enge Fragen. Ob eine Antwort jeden Zwischenstopp erwähnt, ist leichter zu beurteilen als ob eine Antwort gut ist. Die dritte betrifft die Skala. Bestanden oder nicht bestanden, oder eine kleine Menge beschrifteter Kategorien, ist deutlich reproduzierbarer als eine Bewertung von eins bis zehn. Ein Modell hat Mühe, eine sechs von einer sieben zu unterscheiden.

Benchmarks, Container und Harbor: lange Aufgaben mit LangSmith

Ein Benchmark ist eine besondere Form der Offline Evaluierung und besteht aus einer Menge von Aufgaben. Jede Aufgabe enthält Anweisungen, eine Umgebung in einem Container und ein Testskript, das das Ergebnis bewertet. Der Unterschied zu einfachen Judges und Code-Prüfungen liegt im Umfang: Eine einzelne Aufgabe kann Dutzende Werkzeugaufrufe umfassen, in denen der Agent Pakete installiert, Dateien bearbeitet und Befehle ausführt.

Weil Agenten inzwischen Code ausführen und mit Diensten sprechen, bringt jede Aufgabe ihr eigenes isoliertes Umfeld mit. Bewertet wird nicht der Text einer Antwort, sondern der Zustand, den der Agent hinterlässt. Ein Testskript prüft, ob Tests durchlaufen oder ob die richtige Datei existiert. Den Trace kann man zusätzlich lesen, die Punktzahl kommt aber aus den Aktionen und dem Ergebnis. Für den Reiseassistenten könnte eine Aufgabe lauten, dass ein Sturm den Flug nach Denver gestrichen hat, der Reisende umgebucht und das Hotel passend verschoben werden soll. Danach schaut das Testskript in die Buchungsdatensätze.

Harbor ist ein Open-Source-Eval-Harness, das genau diese längeren Aufgaben möglich macht. Es treibt Terminal-Bench an, und dasselbe Aufgabenformat lässt sich für einen eigenen Benchmark verwenden. Über die Integration mit LangSmith wird jeder Harbor-Lauf als Experiment protokolliert. Harbor baut für jede Aufgabe einen Container, und mit LangSmith-Traces lässt sich jede Umgebung näher an das bringen, was der Agent im Produktivbetrieb sieht. Die Ergebnisse stehen dann neben allen anderen Evaluierungen, und jeder Lauf lässt sich mit vollem Trace neben seiner Bewertung öffnen. Das Team nutzte dieses Vorgehen, um Deep Agents auf Terminal-Bench 2.0 zu verbessern, indem es Traces nach Fehlermustern durchsuchte und anschließend das Harness änderte. Auf demselben Weg entstand IssueBench für LangSmith Engine, wo jede Aufgabe dem System einen Stapel Traces übergibt und bewertet, ob die richtigen zu passenden Fehlerclustern gruppiert werden.

Ein eigener Benchmark folgt denselben Schritten wie jede andere Evaluierung. Aufgaben werden aus Traces gesammelt, aus Fehlern abgeleitet und mit Umgebung und Testskript versehen, bis ein Satz entsteht, der sich wiederholt fahren lässt.

Kosten, Fertigbausteine und mehrstufige Gespräche

Online Evals laufen auf Live-Traffic, ihre Kosten wachsen also mit jedem Nutzer. LangSmith begrenzt das über Stichproben und Filter (etwa nur Traces mit negativem Feedback), über günstige Code-Prüfungen und über einen billigeren Richter: In einem Test mit Jev von TypeSafe als Judge traf das Modell jede Bestanden-oder-nicht-Entscheidung wie ein Mensch und kostete insgesamt 0,34 Dollar – gegenüber 28,17 Dollar für Claude Sonnet 4.6.

Man muss Evals nicht von Grund auf selbst bauen: LangSmith bringt vorgefertigte Evaluator-Vorlagen für typische Fälle wie Halluzination oder PII-Lecks mit, dazu das Open-Source-Paket agentevals für Nachrichten und Werkzeugaufrufe. Mehrstufige Gespräche werden über eine Thread-ID gebündelt und als Ganzes bewertet („Spiegelt die finale Buchung jede Änderung wider?“). LangSmith ist framework-agnostisch – es tracet auch Agenten ohne LangChain, LangGraph oder Deep Agents, etwa über das OpenAI Agents SDK, das Claude Agent SDK oder den @traceable-Dekorator. Und für die Berichterstattung vergleicht man Experimente direkt oder baut eigene Dashboards für Tokenkosten, Latenz und Evaluator-Werte über die Zeit.

Der rote Faden des Beitrags ist, klein anzufangen: ein einziges Verhalten, zehn bis zwanzig Beispiele aus echten Traces und ein gespeichertes Experiment als Baseline. Von dort aus wächst die Sammlung von selbst, weil jeder Produktionsfehler ein neues Beispiel liefert. Evaluierung ist kein Tor, durch das ein Agent am Ende hindurchmuss. Sie ist ein Kreislauf, der ihn mit der Zeit verlässlicher macht.

Quelle: langchain.com

Auf Stripes zweiter Monetize-Konferenz beschrieben mehr als 300 Verantwortliche von Unternehmen wie Replit, Fin, Snowflake und Clay, wie sie Preise für KI-Produkte festlegen und ihre Kosten steuern. Zwei Drittel der Firmen auf der Forbes-AI-50-Liste rechnen ihre Leistungen inzwischen zumindest teilweise nach Verbrauch ab. Scott Woody, CEO des Abrechnungsanbieters Metronome, beschrieb den Unterschied so: Die führenden Anbieter arbeiten anders, als es traditionellen SaaS-Unternehmen vertraut ist. Sie überarbeiten ihre Preise in sehr kurzen Zyklen, sie stellen Marktanteile zeitweise über wiederkehrende Umsätze, und sie verfolgen mehrere Vertriebswege gleichzeitig.

Ein KI-Produkt lässt sich immer weniger wie ein Abo verkaufen und immer mehr wie Strom. Es gibt eine Grundgebühr und einen Verbrauchspreis, und beides verschiebt sich, sobald sich die Erzeugungskosten ändern. Mit dieser Analogie lassen sich fast alle Entscheidungen erklären, die auf der Konferenz zur Sprache kamen.

Hybride Preisgestaltung: Abo, Verbrauch und Credits greifen ineinander

Noch ein Jahr zuvor galt nutzungsbasierte Abrechnung vielen als Ablösung des Abonnements. So ist es nicht gekommen. Das Abo wurde nicht verdrängt, sondern bildet heute den Rahmen, in dem variabler Verbrauch gebündelt wird – oft über Credits, also Guthaben, die Kunden vorab kaufen und je nach Nutzung abbuchen lassen. Auf der Konferenz war von einem geschichteten Modell die Rede: ein Abonnement für Grundfunktionen und Planbarkeit, nutzungsbasierte Abrechnung für die Agentenarbeit und Credits, um verschiedene Verbrauchs- und Ergebnisgrößen in einer einzigen Währung zusammenzuführen.

Übertragen auf die Strom-Analogie heißt das: Der Grundpreis sichert den Anschluss, die Kilowattstunde wird nach Verbrauch abgerechnet, und das Guthaben auf der Prepaid-Karte entspricht dem Credit-Pool. Für den Kunden hat das einen Vorteil: Er muss nicht jede einzelne Verbrauchsgröße prognostizieren, sondern nur entscheiden, welches Budget er bereitstellt. Für den Anbieter bleibt die Rechnung näher an den tatsächlichen Kosten, während der Kunde mehr Planungssicherheit gewinnt. Hybride Preismodelle für KI-SaaS bedienen damit zwei widersprüchliche Anforderungen gleichzeitig: kalkulierbare Einnahmen und verursachungsgerechte Preise.

Fin zeigt, wie aus einem Abo ein Credit-Pool wird

Aisling O’Reilly, bei Fin für die Monetarisierung des Produkts verantwortlich, beschrieb den Weg ihres Unternehmens vom reinen Plattformabonnement zu einem hybriden Modell. Den Anstoß gab der Fin AI Agent, für den Fin eine outcome-basierte Preisgestaltung einführte. Zunächst zahlten Kunden für jede vom Agenten gelöste Support-Konversation. Als das Produkt zusätzlich Produkte empfahl, Leads qualifizierte und Termine buchte, reichte diese eine Messgröße nicht mehr aus. Sie bildete den Wert, den Kunden tatsächlich erhielten, nicht mehr ab.

Fin führte deshalb weitere abrechenbare Ergebnisse ein. Kunden wählen seither für jeden Konversationstyp, welches Ergebnis sie haben wollen, und zahlen entsprechend dessen Wert. Zusätzlich können sie sich auf einen Pool aus Credits festlegen und daraus über verschiedene Ergebnisse hinweg abbuchen, ohne jedes Ergebnis einzeln vorherzusagen. Auffällig ist, in welche Richtung abgerechnet wird: Nicht der Input – Tokens, Rechenzeit, Anfragen – steht im Zentrum, sondern der Output. Für Anbieter folgt daraus: Zuerst muss definiert werden, was überhaupt als Ergebnis zählt, erst danach lässt sich eine Währung dafür finden. Wer diesen Schritt überspringt, verkauft Rechenleistung und nennt es Wert.

Vorhersehbare Kosten werden zum Produktmerkmal

Verbrauchsabhängige Abrechnung erzeugt eine Unbequemlichkeit, die sich nicht wegdiskutieren lässt: Der Kunde weiß am Monatsende nicht genau, was er zahlen wird. Ryan Campbell, Senior Director bei Snowflake, erklärte, wie sein Team Kunden dabei unterstützt, den eigenen Verbrauch zu beobachten und zu steuern – mit Prognosen, Rechnern, Szenario-Werkzeugen und transparenter Nutzungseinsicht im Produkt selbst. Sam Lee, bei Stripe für globale Preisgestaltung zuständig, beschrieb eine Steuerungsansicht, in der Nutzer Warnungen sehen, Ausgabengrenzen setzen und anpassen sowie ihren Verbrauch verwalten können. Für ihn ist sie inzwischen Standard.

Auch vertraglich lässt sich Planbarkeit herstellen, ohne die Bindung an den Verbrauch aufzugeben. Jährliche Verbrauchskontingente, rabattierte Übermengen und Fixpreise im ersten Jahr mit anschließender Nachverrechnung gehören zum Repertoire. Je unberechenbarer die Rechnung ausfällt, desto stärker werden gute Verbrauchskontrollen zu einem Teil dessen, wofür Kunden bezahlen. Sie schaffen Vertrauen ins Produkt und ins Unternehmen dahinter.

Replit: sinkende Inferenzkosten, flexibel geschnürte Pakete

Michele Catasta, Präsident und KI-Chef von Replit, beschrieb eine Verschiebung, die viele Anbieter kennen. Als die Agenten des Unternehmens nur wenige Minuten liefen, verlangte Replit 25 Cent pro Agenten-Checkpoint. Mit wachsenden Laufzeiten kosteten manche Aufträge das Unternehmen mehrere Dollar, während Nutzer weiter 25 Cent zahlten. Die Umstellung auf nutzungsbasierte Abrechnung schloss diese Lücke und brachte die Preise näher an den tatsächlich geleisteten Aufwand.

Gelöst war damit ein Problem, ein neues entstand sofort: unvorhersehbare Ausgaben und abrupte Bezahlschranken für Nutzer, die ein monatliches Abo gewohnt waren. Als die Inferenzkosten fielen – auch weil leistungsfähige offene Modelle Druck auf die Preise der Frontier-Anbieter ausüben –, führte Replit einen ratenbegrenzten Free Mode ein, in dem sich mit einem einfachen Abonnement weiterarbeiten lässt. Catasta zufolge ändert das Unternehmen mehrere Preiselemente pro Monat und gibt Einsparungen an Kunden weiter. Wer seine Kostenstruktur kennt, kann dasselbe Produkt in verschiedenen Geschwindigkeiten, Preisniveaus und Serviceklassen anbieten. Ein Produkt, ein Preis – diese Gleichung gilt nicht mehr.

Was Finanzteams als KI-Wert messen – und was nicht

Tokens bestimmen die Kosten eines Anbieters, aber nur selten den Wert, den Kunden zu kaufen glauben. Karan Parekh, Finanzchef bei Clay, sagte in einer Sitzung, sein Unternehmen wolle nicht im Geschäft sein, Tokens mit Aufschlag weiterzuverkaufen. Clay behandelt Modell-Tokens und Fremddaten als durchlaufende Posten, getrennt von dem differenzierten Wert, den das Produkt selbst liefert. Dasselbe Prinzip gilt für die Bewertung der eigenen KI-Investitionen: Der Vertrieb misst Produktivität, die Produktentwicklung den Zeitaufwand für Entwicklung, der Support Durchsatz und Kundenzufriedenheit.

Parekhs Team akzeptiert steigende KI-Ausgaben, die schneller wachsen als der Umsatz, solange etwas Unterscheidbares entsteht, das sonst nicht erreichbar wäre. Die Begründung ist nachvollziehbar. Sobald mehrere Werkzeuge und geänderte Arbeitsabläufe zum selben Ergebnis beitragen, wird die Zuordnung schwierig, und eine Kennzahl wie Token-ROI führt in die Irre. Clays Antwort sind funktionsspezifische Ziele, die quartalsweise überprüft werden. Für Finanzteams sind operationale Ergebnisse damit die nützlichere Perspektive als die Betrachtung von Inputkosten. KI-Kostenmanagement ist damit mehr als eine Beschaffungsfrage.

Preisangaben, die auch Maschinen lesen können

Agenten beeinflussen bereits, wie Produkte gefunden und bewertet werden, selbst wenn autonome Einkaufsprozesse in Unternehmen noch in den Anfängen stecken. Kyle Poyar, Gründer von Growth Unhinged, untersuchte, wie sechs KI-Engines Preisinformationen für Unternehmen der Cloud 100 darstellten, und wertete 7.600 KI-generierte Antworten aus. Bei einem nicht namentlich genannten Anbieter erschien negatives Preisvokabular in 88 Prozent der Antworten. Weil keine zugänglichen Preise vorlagen, wichen die Modelle auf informelle Quellen wie Reddit aus und nannten Spannen von 100 bis 2.400 Dollar pro Nutzer und Monat – ein Unterschied um den Faktor 24.

Eine Preisseite kann für Menschen vollständig sichtbar sein und für Maschinen praktisch nicht existieren – wenn sie Crawler blockiert oder so gerendert wird, dass Agenten sie nicht verlässlich interpretieren. Preisgestaltung hat inzwischen zwei Zielgruppen. Die Person, die die Ausgabe verantwortet, ist weiter im Bild, aber sie hat Platz gemacht für die Maschine, die sie bei der Bewertung unterstützt.

Monetarisierung als Daueraufgabe

KI-Produkte, Modellökonomie und Nutzungsmuster ändern sich zu schnell, als dass Preise statisch bleiben könnten. In nahezu allen Beiträgen der Konferenz steckte dieselbe Abfolge: herausfinden, was Kunden wertschätzen, ihnen mehr Kontrolle über ihre Ausgaben geben und Preise sowie Paketierung anpassen, sobald sich Produkt und Kostenstruktur verschieben. Einmal umstellen reicht nicht.

Für die eigene Arbeit heißt das: Ein Preismodell ist heute eher ein Regelkreis als ein Vertrag. Du brauchst Sichtbarkeit auf Verbrauchsdaten, eine klare Vorstellung davon, welches Ergebnis den Preis rechtfertigt, und die Bereitschaft, die Mischung aus Abo, Verbrauch und Credits mehrmals im Jahr nachzujustieren. Auch ein Energieversorger kalkuliert nicht einmal und für immer, sondern passt Tarife an, wenn Einkaufspreise und Lastprofile sich bewegen. Solche Anpassungen geschehen bei KI-Produkten allerdings in einem ungleich schnelleren Takt.

Quelle: stripe.com

Der Aufstieg der künstlichen Intelligenz wird meist als Geschichte der Größe erzählt: mehr Daten, mehr Rechenleistung, mehr Parameter. Natalie Wolchover setzt in ihrer Kolumne für Quanta Magazine vom 12. Oktober woanders an. Alles, was seit ChatGPT die Welt beschäftigt, beginnt für sie in gewissem Sinne mit einer mathematischen Operation, die 2014 in einem Labor der Universität Montreal entstand: Attention. Auf ihr bauen die Transformer auf und mit ihnen Sprachmodelle wie ChatGPT und Claude. Wolchover fragt, warum gerade diese Operation der Schlüssel war – und ob sie etwas über Intelligenz überhaupt verrät.

Am Anfang steht ein Praktikant namens Dzmitry Bahdanau, damals 23, Belarusse, seit seiner Kindheit wettbewerbsmäßig am Programmieren. Er hatte keine Forschungserfahrung, als er einem Computer das Übersetzen vom Englischen ins Französische beibringen sollte. Bahdanau arbeitete mit künstlichen neuronalen Netzen, die bei Mustererkennung schon überzeugten: Handschrift lesen, Objekte auf Fotos identifizieren. Seine Betreuer, der Informatiker Yoshua Bengio und der Postdoktorand Kyunghyun Cho, waren überzeugt, dass in diesen Netzen mehr steckte. Bahdanau selbst war skeptisch, was menschenähnliche Intelligenz betraf. Maschinelle Übersetzung galt damals als eine der schwierigsten Aufgaben für ein neuronales Netz.

Ein Engpass, der lange Sätze kaputt machte

Übersetzen ist kein Eins-zu-eins-Tausch von Wörtern. Sprachen haben unterschiedliche Satzstrukturen, sie sind voller Redewendungen und Nebenbedeutungen, und daran scheiterten automatisierte Verfahren jahrzehntelang. Übersetzungsregeln lassen sich nicht programmieren, weil es sie in dieser Klarheit nicht gibt. Neuronale Netze wirkten trotzdem vielversprechend, weil sie nicht nach Regeln arbeiten, sondern nach Beispielen: Man füttert sie mit riesigen Mengen englisch-französischer Satzpaare, und sie absorbieren mit der Zeit so etwas wie Quasi-Regeln, Ausnahmen und Feinheiten. Die Ergebnisse blieben mittelmäßig. Und je länger ein Satz wurde, desto schlechter wurde die Übersetzung.

Der Grund war ein Nadelöhr, das man sich wie einen zu kleinen Notizzettel vorstellen kann. Die damaligen Modelle mussten den gesamten Inhalt eines Satzes in eine feste Menge Speicher pressen, bevor sie mit dem Schreiben der Übersetzung begannen. War der Satz fertig gelesen, wurde der Notizzettel abgearbeitet. Je länger der Satz, desto mehr musste auf denselben Zettel, und desto schlechter wurde die Übersetzung. Die Architektur passte nicht. Also versuchte Bahdanau etwas anderes.

Rückblickend beschreibt er seine damalige Eingebung als etwas, das einfach offensichtlich richtig war – eine dieser seltenen Gelegenheiten in der Wissenschaft, bei der jemandem ohne viel Felderfahrung plötzlich alles klar ist. Und es habe einfach funktioniert, sagt er, gleich beim ersten Versuch. Der Trick, den er, Cho und Bengio als Attention bezeichneten, ließ ihr neuronales Netz lange Sätze genauso gut übersetzen wie kurze. Damit war der Ansatz skalierbar. Andere Forschende übernahmen die Idee schnell.

Warum der eigene Blick der Schlüssel war

Was Attention leistet, lässt sich an einem Satz zeigen, den man kaum falsch verstehen kann – bis man ihn übersetzen muss. The animal didn’t cross the street because it was too tired und The animal didn’t cross the street because it was too wide unterscheiden sich nur in einem Wort am Ende. Im ersten Satz bezieht sich it auf das Tier, ein männliches Wort im Französischen, also heißt es dort il. Im zweiten bezieht sich it auf die Straße, ein weibliches Wort, also elle. Für Menschen ist das selbstverständlich. Für ein Modell ist es eine harte Aufgabe, weil dasselbe Wort an derselben Stelle etwas völlig anderes bedeutet.

Bahdanau erinnerte sich an seine eigenen Übersetzungsübungen aus dem Englischunterricht. Um das nächste Wort seiner Übersetzung zu schreiben, musste er den Ausgangstext immer wieder absuchen: links der Quellsatz, rechts das eigene Geschriebene, und dazwischen wanderte der Blick hin und her. Diesen Vorgang hat er nach eigener Aussage in einen neuronalen Mechanismus übersetzt. Attention ist also nichts Mystisches, sondern eine mathematische Möglichkeit für ein Netz, die Wörter irgendwo im Satz zu finden, die für das nächste Wort der Übersetzung am wichtigsten sind. Bei unserem Pronomen durchsucht das System den restlichen Satz und bestimmt, welche Wörter seine Bedeutung am stärksten prägen.

Das Bild eines suchenden Blicks trägt weiter, wenn man unter die Haube schaut. Man kann sich ein neuronales Netz als dunkles Archiv vorstellen, in dem Regale voller Zwischenergebnisse stehen. Attention ist die Taschenlampe, die von einem Wort zum nächsten wandert und dabei entscheidet, wo es sich lohnt, stehenzubleiben. Mit ihr wird Bedeutung dorthin transportiert, wo sie gebraucht wird – Wolchover fasst es so zusammen: Das System verwandelt Kontext in Mathematik.

Query, Key und Value: wie Attention rechnet

Ein Transformer, also die Netzarchitektur, die heute fast alle großen Sprachmodelle trägt, besteht aus vielen Schichten von Knoten, die mit den Knoten der benachbarten Schichten verbunden sind. Ein Satz wird zuerst in Zahlen übersetzt: Jedes Wort wird zu einem Vektor, den man sich als Pfeil in eine bestimmte Richtung vorstellen kann. Diese Pfeile wandern durch das Netz, und Zahlen, die man Gewichte nennt, legen fest, wie sie in jeder Schicht umgeformt werden. Aus jedem Wortvektor entstehen dabei drei neue Vektoren mit unterschiedlichen Rollen, genannt Query, Key und Value.

Ein Attention-Kopf vergleicht die Query eines Wortes mit den Keys aller anderen Wörter im Satz. Je besser diese Vektoren zueinander passen, je ähnlicher ihre Richtung ist, desto stärker fließt der Value des anderen Wortes in eine aktualisierte Repräsentation des betrachteten Wortes ein. Die Query ist eine Frage, die ein Wort an den Satz stellt. Der Key ist das Aushängeschild eines Wortes, das sagt, wofür es zuständig ist. Und der Value ist der Inhalt, der geliefert wird, wenn die Anfrage passt. Das Netz rechnet diese Operation mehrfach parallel, in Systemen, die man Attention Heads nennt.

Im Beispielsatz kann die Query für it in einer tieferen Schicht etwa bedeuten: Ich suche ein früheres Substantiv, das müde sein könnte. Der Key von animal passt besser zu dieser Anfrage als der Key von street, und deshalb trägt animal stärker zur neuen, kontextangereicherten Darstellung von it bei. Diese Darstellung wandert in die nächste Schicht, wo sich das Spiel wiederholt. Was ein einzelner Attention-Kopf genau tut, ist laut Fachleuten oft schwer zu deuten; gemeinsam erfassen die Köpfe aber viele Arten von Beziehungen, vom Zusammenspiel von Substantiv und Verb bis zur Verbindung zwischen Lebewesen und Gefühlen. Schicht für Schicht werden die Wörter mit reicheren Bedeutungen aufgeladen, bis it aus dem Encoder herauskommt, dem ersten Teil des Transformers, der den Satz versteht. Der Decoder, der zweite Teil, erzeugt anschließend Wort für Wort die französische Übersetzung und greift dabei per Attention auf die numerischen Darstellungen der englischen Wörter zurück.

Niemand hat dem Netz gesagt, dass Tiere müde werden und Straßen breit sein können. Solche Zusammenhänge entdeckt das Modell selbst, indem es aus sehr vielen Satzpaaren lernt und die passenden Verbindungen in seinen Gewichten verstärkt. Am Anfang stehen Zufallswerte, die unbrauchbare Queries, Keys und Values und damit schlechte Übersetzungen produzieren. Jeder Fehler schickt jedoch ein Korrektursignal rückwärts durch das Netz, das die verantwortlichen Gewichte leicht verändert. Nach unzähligen solcher Anpassungen entstehen Vektoren, die brauchbare Übersetzungen liefern, auch bei Sätzen, die das Modell nie zuvor gesehen hat. Attention erwies sich damit als die richtige Operation, um Wörter zu verknüpfen und Kontext aufzubauen.

Attention Is All You Need: der Transformer

2017 baute ein Team bei Google eine neue Architektur, die den Attention-Mechanismus in den Mittelpunkt stellte und fast alles andere wegließ. Der Titel des Papers war programmatisch: Attention Is All You Need, auf Deutsch ungefähr: Attention ist alles, was du brauchst. Die Gruppe berichtete, dass dieser Transformer beste Übersetzungsqualität erreichte und dafür nur einen Bruchteil der Rechenleistung früherer Modelle brauchte. Das Papier wurde inzwischen mehr als 250.000 Mal zitiert. Alles, was seit 2022 die Welt beschäftigt – die KI-Wirtschaft, Rechenzentren, Chatbots als Gesprächspartner und Assistenten –, führt in dieser Linie zurück auf die Übersetzungsaufgabe von Montreal.

Der Sprung von der Übersetzung zum Sprachmodell ist kleiner, als er aussieht. Wer gelernt hat, englische Sätze ins Französische zu übertragen, kann auch Sätze in beiden Sprachen vervollständigen. Das Vorhersagen des nächsten Wortes einer Übersetzung ist nämlich nur ein Sonderfall der allgemeineren Aufgabe, das nächste Wort überhaupt vorherzusagen. Genau das tun große Sprachmodelle: Sie werden mit den Inhalten des gesamten Internets trainiert und lernen, welche Wörter in welchen Zusammenhängen auf welche anderen achten müssen. Sie verarbeiten den Datensatz immer wieder neu und versuchen Billionen Mal, das jeweils nächste Wort vorherzusagen. Ihre Gewichte verschieben sich dabei so, dass immer nützlichere Aufmerksamkeitsmuster zwischen Wörtern entstehen – oder passendere Antworten auf eine Frage.

Ist Attention das Wesen der Intelligenz?

Llion Jones, einer der Autoren des Transformer-Papiers und heute Technikchef bei Sakana AI, nennt diesen Übergang selbst einen großen Sprung. Er und andere vermuten, dass die Vorhersage des nächsten Wortes, also das Sprachmodellieren, in gewissem Sinne AI-complete ist: eine Aufgabe so schwer, dass ihre Lösung praktisch die Lösung der KI insgesamt bedeuten würde. Der Grund liegt in der Struktur der Aufgabe. Wer das nächste Wort vorhersagen will, muss als Teilaufgabe fast alles können, was Menschen schriftlich tun. Steht im Text ein französischer Satz, muss das Modell übersetzen können. Steht dort eine Rechnung, muss es rechnen. Steht dort eine Kette mathematischer Symbole, muss es der Mathematik folgen. Steht dort eine Frage nach einem Faktum, muss es das Faktum kennen.

Jones formuliert es so, dass die Fähigkeit, das nächste Wort vorherzusagen, genau deshalb all diese Fähigkeiten voraussetzt, und dass Sprachmodellierung damit die derzeit beste Annäherung an eine Definition von Intelligenz ist, die wir haben. Man kann einwenden, dass ein Sprachmodell nichts im menschlichen Sinne weiß oder versteht. Diese Formulierung beschreibt nur, wie wir gewohnt sind, über die Fähigkeiten solcher Systeme zu sprechen. Attention ist dabei das Werkzeug, mit dem künstliche neuronale Netze Bedeutung, Assoziation und Kontext erschließen – oft flüssig genug, um zu verblüffen. Für anspruchsvolle Mathematik setzen heutige Spitzenmodelle oft zusätzlich explizite Systeme zur formalen Schlussfolgerung und Beweisprüfung ein. Attention allein ist also nicht das Ende der Geschichte.

Mensch, Gehirn und die Grenzen der Attention

Bleibt die Frage aus dem Titel. Wolchover wendet sie zum Schluss auf den Menschen: Auch wir tun beim Sprechen, Schreiben und sogar beim Denken etwas, das dem Vorhersagen des bestmöglichen nächsten Wortes ähnelt. Könnte unser Gehirn einen Mechanismus nutzen, der Bahdanaus Operation gleicht? Kognitionswissenschaftler haben begonnen, das zu untersuchen – eine neue Fassung der alten Frage, wie Sprache und Denken zusammenhängen. Der Erfolg der Sprachmodelle zeigt immerhin, wie viel Wissen über die Welt allein in den statistischen Mustern der Sprache steckt.

Wolchovers eigene Antwort fällt zurückhaltend aus. Neuere Forschung überzeugt sie, dass menschliches Denken nicht rein sprachlich ist, und die Intelligenz der meisten anderen Tiere ist es gar nicht. Beim Denken sind mehr Hirnregionen aktiv als die Sprachnetzwerke der Großhirnrinde; Sinneseindrücke, körperliche und soziale Erfahrungen, Erinnerungen und Schlussfolgern liegen zumindest teilweise außerhalb davon. Sprachmodellierung wäre damit eine mächtige Komponente menschlicher Kognition, nicht ihr Gegenstück oder ihre Quelle. Wie wir sofort verstehen, dass das Tier müde ist und nicht die Straße, weiß bislang niemand.

Auch Llion Jones hält Attention inzwischen nicht mehr für alles, was man braucht, um Sprachmodellierung wirklich zu beherrschen. Das Gehirn erledigt diese Aufgabe offenkundig weit effizienter: Wir unterhalten uns flüssig, ohne auch nur einmal das ganze Internet gelesen zu haben, und verbrauchen dabei weniger Energie. Das derzeitige Paradigma werde dieses Effizienzproblem nicht lösen, sagt Jones, dafür brauche es offenbar einen Sprung zu etwas ganz anderem. Wolchover hält es trotzdem für folgerichtig, dass ausgerechnet die Übersetzung die KI aufschloss: Wer wirksam übersetzen kann, ob Mensch oder Maschine, hat in gewissem Sinne verstanden.

Quelle: quantamagazine.org