Kategorie: Erklärer

Du hast eine Funktion mit einer gehosteten LLM-API gebaut. Sie funktioniert einwandfrei, bis die Rechnung der Finanzabteilung auf deinem Tisch landet. Sie hat sich innerhalb eines Quartals verdreifacht, weil jeder neue Nutzer zusätzliche Token verbraucht. Gleichzeitig weist dein Security-Team darauf hin, dass Kundendaten in jedem Prompt an den API-Anbieter übertragen werden. Im nächsten Standup kommt die Frage: Sollten wir nicht einfach unsere eigenen GPUs kaufen? Die intuitive Antwort „Own-Hardware ist immer günstiger“ ist meistens falsch. Denn das Selbsthosten von LLM-Inference bringt nicht nur Einsparungen, sondern auch versteckte Kosten und neue Verantwortung.

Drei Wege, ein Modell zu betreiben

Bevor wir über Kosten sprechen, müssen wir die drei Betriebsmodelle klar voneinander trennen. Die Hosted-API ist wie ein Restaurant: du bestellst ein Gericht, bekommst es serviert und zahlst pro Portion. Der Managed Deployment ist ein privater Koch, der in deiner Küche arbeitet und die Zutaten von dir bekommt. Das Self-Hosting ist die komplette eigene Küche mit eigenem Herd, Kühlschrank und Personal – du kontrollierst alles, musst aber auch alles selbst organisieren.

Bei einer Hosted-API sendest du Text an einen Anbieter wie OpenAI oder Anthropic und bekommst Text zurück; du zahlst pro Token, ohne dich um Infrastruktur zu kümmern. Der Managed Deployment läuft in deiner eigenen Cloud-Tenancy, aber der Anbieter betreibt GPUs und Serving-Software – deine Daten bleiben bei dir, aber du mietest weiterhin Rechenleistung. Beim Full Self-Hosting besitzt du die GPUs, betreibst die Serving-Engine und übernimmst jede Schicht des Stacks – maximale Kontrolle, aber auch maximale Verantwortung. Die Wahl zwischen diesen Optionen wird von vier Faktoren bestimmt: Volumen, Datenhoheit, verfügbarer Expertise und dem Zugang zu den Modellen selbst.

Die vier Kräfte, die deine Entscheidung bestimmen

Der erste Faktor ist das Datenvolumen. Wie viele Tokens verarbeitest du täglich? Unter einer Million Tokens pro Tag ist die API fast immer die günstigste Lösung – du zahlst nur für die tatsächliche Nutzung und musst keine teuren GPUs anschaffen. Der zweite Faktor ist die Datenhoheit. Wenn deine Daten gesetzlich nicht dein Netzwerk verlassen dürfen – etwa im Gesundheitswesen oder bei Finanzdiensten –, fällt die Hosted-API sofort aus. Dann ist entweder Managed Deployment oder Self-Hosting Pflicht, unabhängig von den Kosten. Der dritte Faktor sind deine Mitarbeiter: Hast du jemanden, der sich um GPUs kümmert, CUDA-Fehler nachts um 2 Uhr fixt und die Latenz überwacht? Ein einzelner MLOps-Ingenieur kostet laut Glassdoor im Schnitt 160.000 Dollar pro Jahr – mehr als die Hardware selbst. Der vierte Faktor ist der Modellzugang: Nur wenige Modelle werden als offene Gewichte veröffentlicht. Die stärksten Modelle wie GPT-5 oder Claude Opus sind Closed-Weights – sie existieren nur als API. Das bedeutet: Die beste Leistung, die du auf eigener Hardware erreichen kannst, ist die eines Open-Weight-Modells. Für Aufgaben, die die Intelligenz eines Frontier-Modells erfordern, wirst du also immer eine API brauchen, egal wie viel du selbst hostest.

Die vier Faktoren wirken in einer festen Reihenfolge. Zuerst prüfst du die Datenhoheit – ein Compliance-Verbot überschreibt jedes Kostenargument. Dann schaust du, ob du ein Ops-Team hast: Wenn nicht, bleibt nur Managed Deployment. Erst danach stellt sich die Volumenfrage: Ab etwa zwei Millionen Tokens pro Tag kann sich die eigene Hardware amortisieren. Zuletzt kommt die Modellzugangs-Beschränkung, die jeden Plan ändern kann. Diese Reihenfolge führt die meisten Unternehmen zu einem Kompromiss: einer hybriden Strategie.

Der Krossover-Punkt: Wann lohnt sich die eigene Hardware?

Zahlen helfen, das Bild zu konkretisieren. Unter einer Million Tokens pro Tag ist die API kostentechnisch klar überlegen. Zwischen einer und zwei Millionen ist es ein echtes Kopf-an-Kopf-Rennen. Ab zwei Millionen Tokens pro Tag beginnt sich der Kauf eigener GPUs zu rechnen – vorausgesetzt, deine Workloads benötigen tatsächlich Frontier-Modelle. Ein Beispiel: Wenn du 10 Millionen Tokens pro Tag durch die günstigste OpenAI-Stufe (!gpt-5.4-nano) jagst, landest du bei einer API-Rechnung von nur ein paar hundert Dollar pro Monat. Dagegen kostet eine ständig laufende, gemietete H100 mit vier Dollar pro Stunde fast 2.900 Dollar monatlich – plus Personalkosten. Der Krossover-Punkt von zwei Millionen gilt also nur für teure, hochwertige Modelle. Arbeitest du mit kleinen, schlanken Modellen, wird sich Self-Hosting womöglich nie amortisieren, weil die API so günstig bleibt.

Der Trick liegt oft in der Bündelung: Drei interne Anwendungen mit jeweils 700.000 Tokens pro Tag ergeben zusammen 2,1 Millionen – damit wird die eigene Hardware profitabel, obwohl keine einzelne Anwendung es wäre. Die Fixkosten der GPU werden über mehrere Abteilungen verteilt. Wer über die Zehn-Millionen-Marke kommt, amortisiert die Hardware in der Regel innerhalb von sechs bis zwölf Monaten. Aber Vorsicht: Diese Rechnung funktioniert nur, wenn du die genannten Kosten der Menschen und des Betriebs nicht vergisst.

Die versteckten Kosten: MLOps, Strom und Hardware

Die offensichtlichen Kosten sind die GPUs selbst – sagen wir 30.000 Dollar für einen H100 oder ein Paar RTX 3090er. Doch die eigentlichen Kostentreiber liegen woanders. Da ist der MLOps-Ingenieur, der das System wartet, denn selbst erfahrene Teams verbringen Monate damit, Serving-Engines wie vLLM zu konfigurieren und Latenzspitzen zu bekämpfen. Sein Gehalt übersteigt den Hardwarepreis um ein Vielfaches. Dazu kommen Stromkosten: Eine High-End-GPU zieht unter Last 450 bis 575 Watt – das macht etwa 50 bis 65 Euro pro Monat pro Karte, selbst wenn sie nur im Leerlauf läuft. Und ein Modell muss in den VRAM passen. Grob brauchst du 0,5 Gigabyte pro Milliarde Parameter bei 4-Bit-Quantisierung; ein 70B-Modell benötigt also 35 bis 40 Gigabyte – mehr, als eine Consumer-Karte bietet. Wenn das Modell auf die CPU ausweicht, wird die Generierung 10 bis 100 Mal langsamer, was wiederum die Antwortzeiten ruiniert.

Hinzu kommt die Frage der Serving-Kapazität. Ein einzelner Server mit vLLM kann laut Forschern rund 19-mal mehr Durchsatz als eine naive Einrichtung schaffen und hält dabei P99-Latenzen unter 100 Millisekunden bei 128 parallelen Anfragen. Das erfordert jedoch Fachkenntnis. Wer nur eine handvoll interner Nutzer bedient, kommt mit einfacheren Tools aus, aber das ist selten der Fall. Die meisten Teams unterschätzen, wie viel Engineering-Zeit in den Betrieb fließt – und diese Zeit ist das teuerste Gut im ganzen Projekt.

Die Hybrid-Strategie: das Beste aus beiden Welten

Wegen dieser Komplexität landen die erfolgreichsten Implementierungen fast immer auf einem Hybridmodell. Die Idee ist simpel: Jede Anfrage wird danach beurteilt, wie sensibel ihre Daten sind und wie viel Rechenleistung sie benötigt. Einfache, repetitive und datenkritische Aufgaben – Klassifikation, Datenextraktion, Verarbeitung von personenbezogenen Dokumenten – erledigt ein lokal gehostetes Open-Weight-Modell. Seltene, aber intellektuell anspruchsvolle Aufgaben, bei denen die Antwortqualität über Leben und Tod des Geschäfts entscheidet, gehen an eine Frontier-API. Diese Aufteilung spart Teams, die sie umgesetzt haben, 40 bis 70 Prozent der Kosten im Vergleich zu einem reinen API-Setup – manchmal sogar mehr.

Der Vorteil der Hybridstrategie ist, dass sie keine Entweder-oder-Entscheidung erzwingt. Du kannst mit der API starten, dann schrittweise eigene Hardware hinzufügen und die Verteilung im Laufe der Zeit optimieren. Die beiden Systeme ergänzen sich: Die API deckt die Spitzen ab, wenn das lokale System überlastet ist, und das lokale System schützt sensible Daten vor externen Zugriffen. So bleibt die Compliance gewahrt, ohne dass du auf die beste Modellqualität verzichten musst.

Einordnung: Wann welche Entscheidung richtig ist

Zusammengefasst ergibt sich eine klare Faustregel. Hosted APIs sind für den Einstieg ideal: Sie sind schnell implementiert, skalieren automatisch und bieten Zugang zu den stärksten Modellen. Managed Deployments sind die Lösung für regulierte Branchen, die Datenkontrolle brauchen, aber keine eigene Ops-Kompetenz aufbauen wollen. Full Self-Hosting lohnt sich nur, wenn dein Volumen konstant hoch ist – über zwei Millionen Tokens täglich – und du die Rechenleistung über mehrere Anwendungen verteilen kannst. Wenn du jedoch nur gelegentlich intelligente Textverarbeitung brauchst und keine strengen Datenschutzauflagen hast, wirst du mit einer API auch langfristig günstiger fahren.

Entscheidend ist, die Kosten nicht nur anhand der Rechnung zu beurteilen. Die Modelle werden immer besser, die API-Preise fallen tendenziell, und die eigene Hardware wird von Software-Updates überholt. Der Reiz des Selbsthostens liegt nicht im Sparen – es liegt in der Unabhängigkeit und Kontrolle. Aber Kontrolle hat ihren Preis, und der ist bei LLMs besonders hoch. Deshalb lautet die Empfehlung: Starte mit einer API, überwache deine Token-Nutzung, und wenn dein Volumen die zwei Millionen pro Tag überschreitet, prüfe die Hybridstrategie. So bleibst du flexibel und zahlst nie mehr als nötig – und du vermeidest die 2-Uhr-CUDA-Fehler, die dein Team unnötig beschäftigen würden.

Quelle: theaiengineer.substack.com

Ein KI-Chatbot schreibt fehlerfreien Code, löst Mathematik-Olympiaden und besteht Jurastudium-Examen. Doch wenn derselbe Agent deine Rechnungskontrolle automatisieren oder Kundentickets sortieren soll, braucht er nach zehn Schritten deine Hilfe. Das nennt man die „gezackte Grenze“ der KI – Fähigkeiten, die sich nicht gleichmäßig über alle Aufgaben verteilen. Während Coding-Agenten wie Claude Code oder Codex inzwischen echte Arbeit ohne menschliche Aufsicht erledigen, hinkt die Enterprise-Welt deutlich hinterher. Laut Stanfords KI-Index 2026 setzen nur einstellige Prozentzahlen aller Unternehmen KI-Agenten produktiv ein. Eine Studie von Stanford, Berkeley und IBM zeigt: 68 Prozent aller eingesetzten Agenten schaffen nicht mehr als zehn Schritte, bevor ein Mensch eingreifen muss. Woran liegt das? Die kurze Antwort: KI-Agenten zuverlässig zu machen, ist ein fundamental anderes Problem als die reine Fähigkeit eines Modells. Vier Faktoren erklären die Kluft: Varianz, Benchmark-Qualität, agentspezifische Fehler und Alignment. Die ersten beiden sind die größten Bremsklötze.

Das Varianz-Problem: Ein exponentielles Risiko

Stell dir vor, du baust ein Haus aus Karten. Jede Karte hat eine kleine Wahrscheinlichkeit, dass sie beim Auflegen verrutscht – sagen wir 10 Prozent. Eine einzelne Karte zu platzieren, ist kein Problem. Aber je höher der Turm wird, desto wahrscheinlicher kippt das Ganze irgendwann. Genau so funktioniert ein KI-Agent. Er führt nacheinander Schritte aus, um eine Aufgabe zu lösen: ein Dokument lesen, einen Datenbankeintrag abrufen, eine API aufrufen, eine E-Mail formulieren. Wenn jeder Schritt zu 90 Prozent klappt, gelingt eine 10-Schritte-Aufgabe nur noch zu 34 Prozent (0,9 hoch 10). Bei 20 Schritten sinkt die Erfolgsrate auf 12 Prozent, bei 30 Schritten auf 4,2 Prozent. Du kannst die Einzelschritt-Wahrscheinlichkeit auf 99 Prozent erhöhen – nach 30 Schritten bleiben nur noch 74 Prozent Gesamterfolg. Diese Rechnung vereinfacht die Realität, denn Fehler in einem Schritt verschlechtern den Kontext für alle folgenden Schritte. Andererseits können Agenten aus Fehlern lernen oder durch Absicherungen korrigiert werden. Aber das Grundprinzip bleibt: Je mehr Schritte, desto schneller bricht die Zuverlässigkeit ein. Dieses Phänomen nennt sich Intrarun-Varianz – die Unsicherheit innerhalb eines einzelnen Durchlaufs. Nun startet ein Agent eine Aufgabe nicht nur einmal, sondern hunderte Male. Die Varianz zwischen verschiedenen Durchläufen nennt sich Interrun-Varianz. Und hier zeigen Messungen ein ernüchterndes Bild.

Pass^k: Was dein Agent wirklich kann

Wie misst man Zuverlässigkeit? Zwei Kennzahlen helfen: pass@k und pass^k. Pass@k fragt: Wenn ich die Aufgabe k-mal ausführe, schafft es mindestens ein Versuch? Das ist die Obergrenze des Könnens – die beste Antwort, die ein Agent liefern kann. Pass^k fragt strenger: Wenn ich die Aufgabe k-mal ausführe, schafft sie jeder einzelne Versuch? Das ist die Untergrenze – die Zuverlässigkeit, auf die du in der Produktion zählen kannst. Ein Beispiel aus dem τ³-Benchmark (ein Branchenstandard für Kundenservice-Agenten): Das Modell gpt-5.2 erreicht pass^1 von 25,5 Prozent im Banking-Bereich. Bei pass^4 – also alle vier Versuche müssen bestehen – fällt das auf 13,4 Prozent. Teils fällt die Leistung auf die Hälfte. Und das beim modernsten Frontier-Modell. Die Grafik zeigt: Bei gpt-4o auf τ-bench liegt die Obergrenze bei etwa 95 Prozent, die Untergrenze bei etwa 30 Prozent. Der Agent könnte also fast alles lösen – aber nicht konsequent. Warum nicht einfach mehrmals laufen lassen und das beste Ergebnis nehmen? Bei Coding-Agenten funktioniert das, weil Tests dir sagen, ob der Code richtig ist. Aber bei den meisten Agentenaufgaben fehlt dieser automatische Beweis. Ein Kundenservice-Agent kann nicht viermal eine Rückerstattung veranlassen und dann die beste Lösung aussuchen – die Aktion wirkt in der Welt, und falsche Versuche haben echte Konsequenzen. Diese Varianz verzerrt auch deine Messung des Agenten. Ein einzelner Benchmark-Lauf ist wie ein einziger Wetterbericht: Er sagt dir wenig über das Klima. Damit zum nächsten Problem: den Datensätzen.

Wenn die Messlatte selbst schief ist

Scale AI wurde 2016 von Alexandr Wang und Lucy Guo gegründet – mit der Idee, dass Daten genauso wichtig sind wie Rechenleistung. Neun Jahre später ist das Unternehmen fast 30 Milliarden Dollar wert. Daten entscheiden über den Erfolg von KI-Systemen. Bei Agenten gilt das noch stärker, als man denkt. Selbst wenn du dein Modell nicht feinjustierst, trainierst du deinen Agenten durch dein Entwicklungsteam: Jede Prompt-Anpassung, jede Umstrukturierung des Workflows, jede Entscheidung, ein Experiment zu verwerfen, basiert auf dem Datensatz, den du zum Testen nutzt. Ein kaputter Datensatz führt zu kaputten Verbesserungen. Datensätze sind schwer sauber zu bekommen. Der τ-bench von Sierra – selbst ein Industriestandard – wurde zur verbesserten Version τ³ überarbeitet. Dabei mussten 53 von 164 Aufgaben korrigiert werden: über 30 Prozent wegen unmöglicher Bedingungen, widersprüchlicher Anweisungen oder falscher erwarteter Aktionen. WebArena, ein weiterer Benchmark, benötigte ähnliche Reparaturen. Nach der Korrektur sanken die Fehlalarme im Baseline-Agenten um 11 Prozent. Solche Fehler sind fatal: Wenn ein Drittel der Aufgaben falsch ist, kann ein korrekt arbeitender Agent schlechter abschneiden als einer, der zufällig die Fehler im Benchmark nachahmt. In der Praxis zeigt sich, dass Teams Monate damit verbringen, die falschen Zahlen zu optimieren – sie jagen Verbesserungen, die in der Produktion keine Wirkung zeigen.

Wie du trotzdem Zuverlässigkeit baust

Was also tun? Mess die Varianz explizit und erkenne sie an. Nutze pass^k als Kennzahl, nicht nur pass@k. Ein Agent, der eine Aufgabe in 90 Prozent der Fälle löst, ist anders zu bewerten als einer, der sie in 90 Prozent der Fälle einmal löst, wenn man ihm fünf Versuche gibt. Investiere in die Qualität deiner eigenen Evaluationsdaten. Ein Datensatz, der aus Produktionsdaten gespeist wird, muss kontinuierlich überprüft werden – nicht einmal bei der Erstellung. Implementiere Absicherungen und erlaube dem Agenten, Fehler zu erkennen und zu korrigieren. Ein Agent, der merkt, dass er eine falsche Annahme getroffen hat, und zurückfragt, ist zuverlässiger als einer, der stur weitermacht. Diese Probleme sind lösbar. Coding-Agenten zeigen den Weg: Sie haben klare, automatisch überprüfbare Ziele und Tests. Für allgemeine Aufgaben brauchen wir ähnlich klare Erfolgskriterien – und den Mut, Varianz nicht als Randerscheinung, sondern als Kernproblem zu behandeln.

Es geht nicht darum, KI-Agenten zu perfektionieren. Es geht darum, sie zuverlässig genug zu machen, um ihnen echte Verantwortung zu übertragen. Die Daten zeigen: Die Fähigkeit ist schon da – 95 Prozent der Probleme lassen sich mit dem richtigen Modell lösen. Was fehlt, ist Konsistenz. Und die erreichen wir nicht durch schlauere Modelle allein, sondern durch bessere Messung, bessere Daten und bessere Architektur. Das klingt unspektakulär – aber Vertrauen entsteht durch Nachweisbarkeit.

Quelle: jeremytian.substack.com

„Der schwierige Teil am kontinuierlichen Lernen ist nicht das Kontinuierliche, sondern das Automatische.“ Mit diesem Satz bringt der Entwickler Sean Goedecke ein Problem auf den Punkt, an dem die Branche seit Jahren arbeitet. Ein Sprachmodell bleibt für immer das, was es am Tag seiner Veröffentlichung war. Im Gespräch nimmt es zwar neue Informationen auf, aber nur so lange, wie das Kontextfenster reicht. Danach ist alles weg: keine Lernkurve, keine Erfahrung, die sich ansammelt. Sein Essay fragt, warum sich das so schwer ändern lässt.

Die Mechanik ist kein Problem

Das eigentliche Problem ist nicht die technische Umsetzung. Ein Modell während des Betriebs weiterzutrainieren ist durchaus möglich, indem man neue Daten durch die bestehende Trainingspipeline schickt. Derselbe Prozess wie beim ursprünglichen Training – nur live. Viele große Sprachmodelle werden intern ständig weiterentwickelt. Die neuesten GPT-Modelle nehmen vermutlich im Hintergrund laufend neue Daten auf und aktualisieren ihre Gewichte. Für die Öffentlichkeit stoppt dieser Prozess jedoch bei der Veröffentlichung. Die Modellgewichte sind eingefroren – aus gutem Grund. Sobald man den Lernprozess automatisiert, ohne menschliche Kontrolle, wird es gefährlich.

Lernen ohne Aufsicht führt oft in die Irre

Der Autor vergleicht das Training eines KI-Modells mit einem Glücksspiel. Trainierst du dasselbe Modell hundertmal mit denselben Daten, aber unterschiedlichen Zufallsauswahlen, erhältst du hundert verschiedene Modelle mit unterschiedlichen Fähigkeiten. Einige sind besser, einige schlechter – pure Lotterie. Man könnte meinen, mehr Daten und Rechenleistung führen automatisch zu einem schlaueren Modell. Ein Trugschluss. Training ist ein fragiler Prozess, der ständig menschlicher Eingriffe bedarf. Manchmal muss man einen Trainingslauf abbrechen, wenn er in eine Sackgasse gerät, oder Parameter anpassen, wenn das Modell in einem lokalen Minimum festhängt. Ein autonom lernendes Modell würde ohne diese Aufsicht mit der Zeit schlechter werden, nicht besser. Deshalb ist kontinuierliches Lernen im Sinne einer automatischen Gewichtsaktualisierung aktuell keine Option.

Fine-Tuning: Warum es nicht so einfach ist

Eine naheliegende Idee: ein LLM einfach auf die eigenen Daten feintunen. Wenn ich möchte, dass ein KI-Programmierer meine Codebasis versteht, könnte ich das Modell mit meinem Repository trainieren. Das funktioniert überraschend schlecht. Der Autor erinnert an den Hype um Fine-Tuning im Jahr 2023, der weitgehend verpufft ist. Selbst gezieltes Fine-Tuning auf eine spezifische Codebasis verleiht dem Modell kein echtes Verständnis für die Zusammenhänge. Warum das so ist, bleibt unklar. Vielleicht sind die Datensätze zu klein, um den riesigen Parameterraum zu verändern – wie ein paar Sandkörner, die eine Düne verschieben sollen. Oder Methoden wie LoRA dringen nicht tief genug in die internen Strukturen ein. Vielleicht müsste die Codebasis viel früher in den Trainingsprozess einfließen, bevor die Architektur des Modells festgelegt ist. So bleibt Fine-Tuning heute eine Enttäuschung – ein schlechtes Zeichen für alle, die hoffen, kontinuierliches Lernen bringe diese Fähigkeit nebenbei mit. Wenn man es nicht kontrolliert hinbekommt, kann man es nicht im Automatikmodus erwarten.

Sicherheit: Wenn der Gegner in die Gewichte schreibt

Ein weiterer Grund, warum kontinuierliches Lernen nicht als Produkt verfügbar ist, ist Sicherheit. Schon heute ist Prompt-Injection ein großes Problem: Ein bösartiger Text im Input kann ein Modell dazu bringen, unerwünschte Aktionen auszuführen. Bei kontinuierlichem Lernen würden Angreifer nicht nur den Kontext, sondern direkt die Gewichte des Modells manipulieren können. Ein Angreifer schleust über ein unscheinbares Trainingsbeispiel eine Hintertür ein, die erst Monate später aktiviert wird, wenn das Modell Zugriff auf sensible Systeme hat. Das wäre wie ein Virus, der sich in jeder neuen Version des Modells versteckt. Die großen KI-Labore haben jahrelang daran gearbeitet, ihre Modelle sicher und zuverlässig zu machen. Sie würden dieses Risiko niemals eingehen, indem sie jedem Kunden erlauben, eigene Trainingsläufe durchzuführen. Der Fall des Chatbots Tay von Microsoft, der nach wenigen Stunden durch Nutzerinteraktionen in einen rassistischen Hassbot verwandelt wurde, zeigt, wie schnell unkontrolliertes Lernen schiefgeht.

Das Upgrade-Dilemma

Auch abgesehen von Sicherheitsbedenken gibt es ein praktisches Problem: die Portabilität von Gelerntem. Trainierst du ein KI-Modell sechs Monate lang kontinuierlich an deiner Codebasis, sind alle Erkenntnisse in den Modellgewichten gespeichert. Nun erscheint die nächste Modellversion, die deutlich besser ist. Wie überträgst du das Gelernte? Du kannst die alten Gewichte nicht einfach übernehmen, denn die Architektur könnte sich geändert haben. Selbst ein LoRA-Adapter, der die Feinanpassung speichert, funktioniert nur, wenn das Basismodell kompatibel ist. Du stehst vor der Wahl: Bleibst du bei deinem alten, spezialisierten Modell, oder wechselst du zum neuen und verlierst wertvolles Wissen? Das erinnert an ein Unternehmen, das alle sechs Monate einen neuen Berater einstellt. Der neue Berater ist vielleicht smarter, aber er kennt deine Prozesse nicht. Nutzer werden sich sträuben, zu upgraden – schlecht für die Verbreitung neuer Modelle. AI-Unternehmen haben bereits heute Mühe, Nutzer zum Wechsel zu bewegen, wie die hartnäckige Anhängerschaft älterer GPT-Modelle zeigt. Kontinuierliches Lernen würde dieses Problem verschlimmern.

Warum ausgerechnet die Gewichte das Problem sind

Der Sicherheitsaspekt verdient einen genaueren Blick, weil er sich grundlegend von dem unterscheidet, was Entwickler heute kennen. Eine Prompt-Injection wirkt innerhalb einer Sitzung: Der Angreifer schmuggelt Text in den Kontext, das Modell tut etwas Unerwünschtes, und mit dem Ende der Sitzung ist der Spuk vorbei. Der Schaden bleibt begrenzt, weil er nirgends gespeichert wird.

Bei kontinuierlichem Lernen ändert sich genau das. Was ein Angreifer über präparierte Trainingsdaten in die Gewichte schreibt, bleibt dort – für jede künftige Sitzung und für jeden Nutzer desselben Modells. Eine so eingebaute Hintertür kann monatelang schlafen und erst dann auslösen, wenn ein bestimmtes Stichwort fällt und das Modell inzwischen Zugriff auf sensible Systeme hat. Der Autor hält das für deutlich beunruhigender als alles, was Prompt-Injection anrichten kann.

Das eigentlich Unangenehme daran: Es gibt keinen etablierten Weg, so etwas zu finden. Ein Modell lässt sich nicht wie eine Programmdatei auf Signaturen scannen. Man sieht Milliarden von Zahlen, denen nicht anzusehen ist, welches Verhalten in ihnen steckt. Dass selbst das kontrollierte Fine-Tuning seit den Diskussionen von 2024 nicht zuverlässig funktioniert, macht die Aussicht nicht besser: Was sich schon unter Aufsicht nicht sauber steuern lässt, gibt niemand freiwillig in den Automatikbetrieb.

Das Auto braucht weiterhin einen Fahrer

Das Ergebnis ist klar: Die eigentliche Hürde ist nicht die Kontinuität, sondern die Automatisierung. Wir wissen, wie man Modelle trainiert, aber nicht, wie man sie sicher und eigenständig trainieren lässt, ohne dass sie entgleisen. Modelltraining bleibt ein handwerklicher Prozess, der ständige Überwachung erfordert. Ein autonom lernendes System würde früher oder später in eine Sackgasse geraten und könnte sogar Schaden anrichten. Außerdem ist unklar, ob einfaches Zurückspulen von Nutzungsdaten tatsächlich zu echtem Verständnis führt – die Erfahrungen mit Fine-Tuning sprechen dagegen. Bis wir nicht lernen, Modelle automatisiert und zuverlässig zu verbessern, bleibt kontinuierliches Lernen eine Vision. Vielleicht träumen wir von einem Mitarbeiter, der aus Erfahrung klüger wird, aber im Moment haben wir nur einen eifrigen Azubi mit einem Notizblock, der jede Woche von vorne beginnt.

Quelle: seangoedecke.com

Ein Support-Chatbot versteht dein Problem und schlägt eine Lösung vor. Am nächsten Tag schreibst du wieder – und er hat alles vergessen. Du musst von vorne anfangen. Context Graphs beheben genau das.

Ein Context Graph ist ein persistentes Gedächtnis für KI-Agenten. Er verbindet langfristiges Unternehmenswissen mit dem aktuellen Gespräch und den Entscheidungen des Agents. So kann er sich an frühere Interaktionen erinnern, konsistent antworten und Entscheidungen nachvollziehbar machen. Ohne ein solches Gedächtnis bleibt der Agent auf den Moment beschränkt – er kann nicht lernen, nicht erklären, nicht über mehrere Sitzungen zuverlässig arbeiten.

Warum KI-Agenten ein Gedächtnis brauchen

Ein KI-Agent nutzt ein Sprachmodell zum Denken, Tools zum Handeln und eine Schleife, um Aufgaben zu erledigen. Er plant Schritte, ruft Funktionen auf, beobachtet Ergebnisse und iteriert, bis das Ziel erreicht ist. Doch selbst fortgeschrittene Modelle machen Fehler, wenn der Kontext fehlt. Ein Agent, der eine Rückerstattung genehmigt, muss wissen, welche Richtlinie gilt, was der Kunde bereits gesagt hat und wie ähnliche Fälle früher entschieden wurden. Diese Informationen liegen oft verstreut in Datenbanken, Logs und Prompts – aber nicht in einer gemeinsamen Struktur.

Ohne dauerhaftes Gedächtnis muss der Agent die Welt um die Aufgabe herum jedes Mal neu aufbauen. Das ist ineffizient und fehleranfällig. Ein Kundenservice-Agent könnte etwa die Rückgabefrist übersehen und eine längst abgelaufene Erstattung gewähren. Oder er vergisst, was der Kunde erklärt hat, und zwingt ihn zur Wiederholung. Beides ist inakzeptabel. Ein Context Graph löst das, indem er die drei Arten von Erinnerung – langfristig, kurzfristig und reasoning-basiert – in einem durchsuchbaren Netzwerk vereint.

Die drei Schichten des Context Graphs

Ein Context Graph speichert Wissen auf drei miteinander verbundenen Ebenen. Die erste ist das Langzeitgedächtnis. Es enthält das Unternehmenswissen, das der Agent vor der Konversation kennt: Produkte, Richtlinien, Kunden, Verträge, Systeme und Geschäftsregeln. Diese Fakten ändern sich langsam, sind aber entscheidend für richtige Entscheidungen. In einem Rückgabefall wird die Rückgaberichtlinie mit Produktkategorie, Kundentyp und Ausnahmeprozess verknüpft.

Die zweite Ebene ist das Kurzzeitgedächtnis. Es speichert den Verlauf der aktuellen Interaktion – Nachrichten, Zwischenstände, bereits ausgeführte Aktionen. Ohne diese Erinnerung würde der Agent den Kunden ständig wiederholen lassen oder den Überblick verlieren. In Multi-Agent-Systemen ist dieser gemeinsame Zustand besonders wichtig, denn mehrere Agenten müssen wissen, was schon passiert ist und was noch offen ist.

Die dritte Ebene ist das Reasoning-Gedächtnis. Es protokolliert, wie der Agent zu seiner Entscheidung kam: welche Tools er aufrief, welche Beweise er verwendete, warum er eine bestimmte Aktion wählte. Diese Spur macht das Verhalten überprüfbar und ermöglicht es, aus vergangenen Fällen zu lernen. Alle drei Ebenen sind in einem Graphen verbunden, sodass der Agent bei jeder Aufgabe den relevanten Kontext abrufen kann – sei es eine Richtlinie, eine Gesprächssequenz oder eine frühere Entscheidung.

Sieben Vorteile eines Context Graphs

Ein Context Graph bringt konkrete Vorteile für produktive KI-Workflows. Erstens führen gespeicherte Fakten und Beziehungen zu genaueren Antworten, weil der Agent auf gesicherte Informationen zurückgreift, statt zu raten. Zweitens hilft der Graph, die relevanten Informationen auszuwählen, anstatt das gesamte Wissen in den Prompt zu packen – das spart Kosten und verbessert die Präzision.

Drittens bleibt der Kontext über Prompts hinweg erhalten. Statt jede Sitzung neu zu konstruieren, greift der Agent auf frühere Zustände zurück. Viertens stärkt die Entscheidungsspur die Erklärbarkeit und Governance. Man kann zurückverfolgen, welche Fakten und Tools eine Entscheidung beeinflusst haben, und so Compliance-Anforderungen erfüllen. Fünftens unterstützt ein Context Graph langlaufende Workflows, die über mehrere Schritte, Toolaufrufe und Genehmigungen gehen – der Zustand bleibt erhalten.

Sechstens ermöglicht ein gemeinsamer Graph mehreren Agenten, denselben Wissensbestand zu nutzen und sich zu ergänzen. Jeder kann auf die aktuellen Fakten und den Verlauf zugreifen. Siebtens senkt die selektive Abfrage von Gedächtnisinhalten die Token-Kosten, weil nicht jede Nachricht den gesamten Verlauf und alle Dokumente enthält. Stattdessen werden nur die relevanten Teile in den Prompt geladen.

Context Graph vs. Knowledge Graph – wo liegt der Unterschied?

Oft werden die Begriffe verwechselt, aber sie bauen aufeinander auf. Ein einfacher Graph stellt Entitäten und Beziehungen dar – er beantwortet „Was ist verbunden?“. Ein Knowledge Graph fügt semantische Struktur und Geschäftsbedeutung hinzu – er erklärt, was die Verbindungen bedeuten. Ein Context Graph geht weiter: Er verbindet das Wissen mit der konkreten Aufgabe und dem aktuellen Kontext des Agents, einschließlich Gesprächsverlauf und Entscheidungslogik.

In einer Agent-Architektur entspricht ein Knowledge Graph dem Langzeitgedächtnis. Ein Context Graph überlagert diese Ebene mit den anderen beiden und ermöglicht es dem Agenten, Fakten, Gespräche und Entscheidungen zusammen zu sehen. So bekommt er ein vollständiges Bild der Situation – nicht nur isolierte Datenpunkte.

So baust du einen Context Graph mit Neo4j Agent Memory

Der einfachste Weg, einen Context Graph aufzubauen, ist die Nutzung von Neo4j Agent Memory. Diese Lösung verbindet die Bausteine des Agentengedächtnisses – Konversationen, Entitäten, Präferenzen, Fakten, Tool-Nutzung und Reasoning-Spuren – in einer Neo4j-Graphdatenbank. Dadurch wird das Gedächtnis durchsuchbar, statt es in Prompts, Logs und getrennten Speichern zu verstreuen.

Neo4j bietet mehrere Setup-Optionen: Du kannst den gehosteten Neo4j Agent Memory Service (NAMS) nutzen, eine verwaltete REST-API, die sich einfach in bestehende Anwendungen integrieren lässt. Alternativ gibt es lokale oder Cloud-basierte Neo4j-Instanzen, die du selbst konfigurierst. Beispiele und Demo-Anwendungen, etwa das Lenny’s Memory-Projekt, veranschaulichen die Architektur. So kannst du schnell einen Prototyp aufbauen und die Vorteile eines Context Graphs selbst testen.

Was der Ansatz noch schuldig bleibt

Bei aller Plausibilität lohnt ein nüchterner Blick auf das, was nicht belegt ist. Neo4j beschreibt das Konzept ausführlich, liefert aber keine Messwerte: keine Zahl dazu, wie stark die Token-Kosten tatsächlich sinken, keinen Vergleich der Antwortqualität gegen eine gewöhnliche Vektorsuche, kein Beispiel für eine konkrete Abfrage oder ein Schema. Der versprochene Vorteil bleibt damit ein Argument, keine Messung – und das Argument stammt vom Hersteller der Datenbank, die man dafür braucht.

Dazu kommt der Aufwand, den ein Graph mit sich bringt. Jemand muss entscheiden, welche Entitäten es gibt, wie sie zusammenhängen und was aus einem Gespräch überhaupt dauerhaft gespeichert wird. Diese Modellierungsarbeit fällt bei einem Vektorspeicher weg, in den man Dokumente einfach hineinkippt. Wer nur Dokumente durchsuchbar machen will, fährt damit weiterhin gut. Interessant wird ein Context Graph erst, wenn Entscheidungen nachvollziehbar sein müssen, mehrere Agenten denselben Stand brauchen oder ein Vorgang über Tage läuft. Das sind reale Anforderungen – aber nicht die Mehrheit der Fälle.

Wenn du einen Context Graph implementierst, sorgst du dafür, dass dein KI-Agent konsistent, erklärbar und effizient arbeitet. Das unterscheidet einen statischen Chatbot von einem Agenten, der wirklich mitdenkt und sich weiterentwickelt. Die Investition in diese Architektur zahlt sich aus, sobald du Workflows in Produktion bringst.

Quelle: neo4j.com

Ein schwieriges Projekt liegt vor dir, das du seit Jahren aufschiebst. Dann beginnst du, es systematisch anzugehen, und plötzlich findest du Lösungen, die vorher undenkbar schienen. In der Mathematik passiert genau das – nur im globalen Maßstab. Eine Liste mit tausend offenen Problemen, benannt nach dem ungarischen Mathematiker Paul Erdős, ist heute das Testfeld für künstliche Intelligenz. Seit dem Frühjahr 2026 lösen KI-Modelle Problem um Problem, und Mathematiker fragen sich, was dieser Durchbruch bedeutet.

Der ungewöhnliche Erbe: Paul Erdős und seine Fragen

Paul Erdős war eine bemerkenswerte Figur der Mathematik des 20. Jahrhunderts. Er lebte jahrzehntelang aus dem Koffer, besaß kaum etwas und reiste von Universität zu Universität, um mit Kollegen zu arbeiten. Überall hinterließ er Fragen – in Aufsätzen, Briefen und auf Tafeln. Für Lösungen versprach er Geldpreise, oft nur zehn oder 25 Dollar, bei schwierigen Problemen auch Tausende. Nach seinem Tod 1996 übernahm eine Stiftung in Iowa die Auszahlung. Erdős war ein Eigenbrötler: Er trug nur Seide, vermied jede körperliche Berührung und nannte Gott sarkastisch den „obersten Faschisten“. Trotzdem – oder gerade deshalb – inspirierte er Generationen von Mathematikern. Seine Probleme sind oft einfach zu verstehen, aber schwer zu lösen. Diese Mischung macht sie heute attraktiv für KI-Systeme.

Die Liste, die alles veränderte: Thomas Bloom und erdosproblems.com

Der englische Mathematiker Thomas Bloom arbeitet an der Universität Manchester. Er beschäftigt sich mit arithmetischer Kombinatorik, einem Gebiet zwischen Zahlentheorie und Kombinatorik. 2023 hatte er eine schlichte Idee: Er wollte alle offenen Erdős-Probleme an einem Ort sammeln, weil es bisher keine verlässliche Übersicht gab. Also erstellte er eine Website, damals mit Unterstützung von ChatGPT für den Code. Niemand rechnete damit, wie wichtig diese Plattform werden würde. Bloom kuratierte die Probleme sorgfältig: Er präzisierte Formulierungen, entfernte Doppelungen und ergänzte Kontext. Seine Liste wuchs auf fast tausend Einträge. Im Sommer 2025 fügte er eine Kommentarfunktion hinzu – ebenfalls mit KI programmiert. Das veränderte alles. Plötzlich konnte eine internationale Gemeinschaft über einzelne Probleme diskutieren, Beweisideen austauschen und gemeinsam voranschreiten. Die Website wurde zum digitalen Treffpunkt für Mathematiker und Enthusiasten.

Die ersten KI-Erfolge: Vom Gegenbeispiel zur systematischen Lösung

Am 20. Mai 2026 meldete OpenAI einen Erfolg: Ein internes KI-Modell hatte ein Gegenbeispiel zum „Unit-Distance-Problem“ gefunden, das Erdős 1946 formuliert hatte. Das Problem fragt, wie viele Einheiten eine Menge von Punkten mindestens voneinander entfernt sein kann – eine scheinbar einfache Frage mit tiefen Verästelungen. Die KI nutzte Ideen aus einem entfernten Teilgebiet der Mathematik. Menschen verbesserten das Ergebnis binnen Wochen, aber der Durchbruch war da. Wenige Tage später folgten ähnliche Erfolge. Im August 2026 verkündete OpenAI, dass ein unveröffentlichtes Modell namens Astra zehn weitere mathematische Fortschritte erzielt habe, darunter Lösungen für drei zusätzliche Erdős-Probleme. Die KI arbeitet nicht wie ein Mensch. Sie durchsucht riesige Lösungsräume, kombiniert Muster und findet oft unkonventionelle Wege. Das ähnelt einem Tüftler, der eine schwierige Aufgabe von der Seite angeht, statt frontal.

Die Rolle der Gemeinschaft: Vom Amateur zum Mitglied

Die Kommentarfunktion auf Blooms Website zog Menschen an, die nicht unbedingt Professoren sind. Ein Beispiel ist Wouter van Doorn, der im Kundenservice arbeitet, aber fast einen Master in Mathematik abgeschlossen hätte. Er nutzte 2025 eine sechsmonatige Auszeit, um an offenen Problemen zu arbeiten – ohne KI. Ende 2025 kommentierte er eine Lösung auf der Website, bekam Widerspruch und überzeugte schließlich den anderen Kommentator. Der war Terence Tao, einer der bekanntesten Mathematiker der Gegenwart. So entstehen Kollaborationen, die Hierarchien überwinden. Die KI mischt mit: Zwei junge Leute, Kevin Barreto und Liam Price, begannen im Dezember 2025, gezielt Erdős-Probleme an Sprachmodelle zu verfüttern. Sie entwickelten eine Methode: erst eine Lösung von der KI holen, dann eine frische KI-Instanz zur Kontrolle einsetzen, bis etwas Stimmiges entsteht. So lösten sie das Problem 728, das nachweislich noch niemand zuvor bewiesen hatte. Ihre Herangehensweise steht für die neue Ära: Mensch und Maschine arbeiten zusammen.

Der wunde Punkt: Wer liest die Beweise?

Mit der Geschwindigkeit wächst ein Problem, das sich nicht wegrechnen lässt. Thomas Bloom, der die Liste kuratiert, formuliert es deutlich: Ein großer Teil der Einsendungen stamme von Leuten ohne mathematischen Hintergrund, die gar nicht in der Lage seien, die Ausgabe zu prüfen. Es kursierten inzwischen Arbeiten von 100 bis 200 Seiten, die kein Mensch gelesen habe – und die auch keiner lesen werde. Ein Beweis, den niemand nachvollzieht, ist mathematisch aber wertlos, egal wie überzeugend er formatiert ist.

Um die KI-Nutzung hat sich deshalb eine eigene Handwerkskunst entwickelt. Kevin Barreto und Liam Price lassen jede Antwort von einer frischen Modellinstanz gegenprüfen, bevor sie sie ernst nehmen, und wiederholen das, bis nichts mehr wackelt. Sie arbeiten zudem mit einem Kniff, der wenig über Mathematik und viel über Sprachmodelle verrät: Sie erzählen dem Modell, die Aufgabe sei leichter als sie tatsächlich ist – dann bleibt es länger dran, statt früh aufzugeben. Formale Werkzeuge wie Aristotle vom Start-up Harmonic übernehmen die logische Verifikation dort, wo sie sich automatisieren lässt.

Auf der anderen Seite steht eine Frage, die kein Werkzeug beantwortet. Noga Alon aus Princeton, über Jahrzehnte einer der produktivsten Bearbeiter dieser Probleme, hat aufgehört: Sobald die KI anfing, sie zu lösen, habe es keinen Sinn mehr gehabt. Der Fields-Medaillen-Träger Jacob Tsimerman wechselte im Juli 2026 zu OpenAI. Die Liste selbst zeigt den Fortschritt in nüchternen Zahlen – 565 gelöste, 652 offene Probleme zum Zeitpunkt des Berichts. Google DeepMind steuerte im Januar 2026 vier Lösungen bei und fand neun weitere, die längst existierten, aber in der Literatur vergessen worden waren.

Was das für die Mathematik bedeutet: Eine Zeitenwende?

Die Fortschritte sind deutlich, aber nicht alle Probleme sind gleich wichtig. Manche Erdős-Probleme sind schwer, andere trivial – einige waren längst gelöst, nur in der Literatur versteckt. Thomas Bloom betont, dass die Liste nicht nur Abhak-Kandidaten enthält. Sein Ziel war es, die „Kernprobleme“ herauszuarbeiten, die unser Verständnis erweitern. KI kann helfen, den Berg an Aufgaben abzutragen, aber die nächste große Erkenntnis wird vermutlich von Menschen kommen – oder von KI, die Menschen überrascht. Die Frage ist, ob diese Werkzeuge langfristig zu neuen mathematischen Theorien führen oder nur zu schnelleren Lösungen bekannter Rätsel. Klar ist: Die Erdős-Probleme sind zu einem Gradmesser für KI-Fähigkeiten geworden. Jedes gelöste Problem zeigt, wo die Grenzen liegen – und wie schnell sie sich verschieben.

Das ist mehr als eine Kuriosität. KI generiert nicht nur Texte oder Bilder, sie arbeitet in der reinen Logik. Mathematik galt lange als das letzte Feld menschlichen Verstands. Wenn eine KI jetzt Probleme löst, die Generationen beschäftigt haben, verändert das unser Bild von Intelligenz. Es ist ein Anfang, aber ein deutlicher. Die Liste von Erdős wird noch viele offene Fragen haben – das ist der Reiz. Vielleicht kommen wir bald an den Punkt, an dem KI nicht mehr nur antwortet, sondern selbst Fragen stellt.

Quelle: quantamagazine.org