Die Zukunft der AI-Forschung: vom Rezept zum Meal Kit
(open.substack.com)Kernaussagen (TL;DR)
-
Explosion bei AI-Papers = Fortschritt + zugleich eine „Noise Tax“
- 2013 → 2023 jährliche AI-Papers: ~102.000 → ~242.000
- Im selben Zeitraum Anteil von AI an allen CS-Papers: 21,6 % → 41,8 %
-
Je mehr Papers erscheinen, desto stärker explodieren die Kosten für Auswahl/Reproduzierbarkeit/Betrieb
- Es wird mehr gelesen, aber Produkte werden weniger stabil
- Je stärker man SOTA hinterherläuft, desto schlechter werden Reproduzierbarkeit und Betriebsfähigkeit
-
Wenn man Papers in Produktion bringt, tauchen fast immer vier Fehlermodi auf
-
Deshalb ist das Signal für 2026 einfach:
DIY (Rezept selbst umsetzen) ↓ / Packaging (Meal Kit) ↑- Statt „Paper lesen und implementieren“ gewinnt die sofort deploybare Einheit
- Packaging wie NVIDIA NIM / SLM / Ollama schafft eine Bewegung hin zur Standardisierung
Problemdefinition: AI-Papers sind „Michelin-Rezepte“
Der Autor vergleicht AI-Forschungspapiere mit Rezepten von Michelin-Köchen.
Das Rezept selbst ist nicht das Problem. Nur unsere Küche ist eine andere.
Papers entstehen in einer perfekten Küche.
- H100-Cluster
- sauber aufbereitete Datensätze
- versteckte Tricks, optimiert für die Experimentierumgebung
Sobald dieses Rezept jedoch in die Praxis kommt (On-Prem, Legacy, Compliance, Betrieb), wiederholt sich dasselbe Muster.
Vom Paper zur Produktion: 4 Fehlermodi
1) Broken Utensils (Infrastruktur)
-
Paper-Ergebnisse basieren auf Tausenden von H100-GPUs
-
Die Realität sind kleine GPUs / begrenzter VRAM / eingeschränkte Netzwerke
-
Das Problem ist nicht „die Performance sinkt ein wenig“
→ Das Phänomen selbst tritt gar nicht auf -
Häufige Symptome:
- „Es läuft zwar, aber das erwartete Verhalten fehlt“
- Die Pipeline endet erfolgreich, aber das promised behavior erscheint nicht
2) Spoiled Ingredients (Daten)
-
Papers setzen bereinigte Daten voraus
-
Reale Daten vor Ort sind:
- Logs, gescannte PDFs, Legacy-Dokumente, Schema-Änderungen, unklare Herkunft
-
RAG/Inferenz kippt sofort in Halluzinationen, wenn Struktur, Belege oder Konsistenz brechen
-
Noch gefährlicher ist:
- Es wirkt flüssig und überzeugend, daher glaubt man es eher
- „Sieht plausibel aus, ist aber falsch“ ist am teuersten
3) Missing Salt (Engineering-Details)
-
Der Bereich „Season to taste“ ist der größte
-
Die eigentlichen Entscheidungspunkte sind:
- Initialisierung / Scheduler / Feintuning in 0,001-Schritten / Prompt-Templates
-
So etwas passt nicht auf 8 Paper-Seiten
-
In der Praxis trennt sich genau hier die Spreu vom Weizen:
- Nicht das Rezept, sondern die geheime Würzung (Bedingungen für Reproduzierbarkeit) entscheidet über das Ergebnis
4) Responsibility Gap (Verantwortung)
-
Wenn es scheitert, lautet das Fazit oft so:
- „Die Mathematik stimmt. Das Problem ist eure Umgebung.“
-
Die Verantwortung für diese Lücke wandert nach unten im Stack
→ Am Ende trifft es die Person, die das Paper gelesen und empfohlen hat. -
Kommt es zu Ausfällen oder Audits, ist es plötzlich „das System, das wir gebaut haben“
Zwei strukturelle Grenzen: Warum man DIY aufgibt
A) Paper-Explosion = Noise Tax
Je mehr Papers erscheinen, desto stärker explodieren die Auswahlkosten.
- Es wird mehr gelesen, aber Produkte werden weniger stabil
- Je stärker man SOTA hinterherläuft, desto schlechter wird die Betriebsfähigkeit
- Das ist kein „Wissensreichtum“, sondern ein „Auswahlkostenproblem“
B) Veränderung der Kapitalrichtung: „Paper“ → „Betrieb“
Geld wandert von „neuen Rezepten“ hin zu betriebsfähigen Paketen.
Auch die Investitionsfrage hat sich verändert.
- Demo oder Betrieb?
- Sind Kosten/Latenz/Observability/Auditierbarkeit beherrschbar?
Betriebsrisiken laufen meist auf diese drei Punkte hinaus:
- Kostenrisiko: Als PoC funktioniert es, im Betrieb explodiert es
- Vertrauensrisiko: Wenn Belege oder Quellen brechen, ist auch eine plausibel klingende Antwort riskant
- Verantwortungsrisiko: Bei Ausfällen oder Audits liegt die Verantwortung bei uns
Das stärkste Signal für 2026: Packaging
AI Meal Kit = Ready-to-deploy + eine Deployment-Einheit mit klarer Grenze der Verantwortung im Fehlerfall
Das Fazit für 2026 lautet also:
Packaging beats ingenuity.
Vier Marktsignale
Signal #1) NVIDIA NIMs
- Modellkonfiguration, Abhängigkeiten und Optimierungen sind im Container fixiert
- Weniger Rätselraten bei der Toolchain
- Die geheime Würzung ist bereits enthalten.
- Die Botschaft: „Tune less. Run more.“
Signal #2) SLMs
- Es gibt mehr „Rezepte, die zur eigenen Küche passen“
- Die Möglichkeit für lokalen Betrieb und Edge-Betrieb steigt
- Die Richtung ist: bounded / predictable / cheaper to operate
Signal #3) AI in a Box
- Server werden nicht mehr als „Bauteile“, sondern als „fertige Produkte“ verkauft
- Inklusive RAG, Sicherheit und Grundeinstellungen
- Effekt: Es entsteht eine klare Grenze dafür, wer die Lücke verantwortet
Signal #4) Ollama / LM Studio
- Die Schwierigkeit der Einrichtung sinkt stark
- Die Zahl der Betreiber steigt
- Wenn es mehr Betreiber gibt, entwickelt sich der Markt immer gleich: Die Standardisierung beschleunigt sich
Praxisperspektive: Indikatoren auf einen Blick
- Compute Fit: Lässt sich die Ziel-Performance auf „unserer GPU/unserem VRAM“ reproduzieren?
- Data Fit: Bleiben bei den Eingabedaten „Struktur/Belege/Quellen“ erhalten?
- Hidden Salt: Sind die für die Reproduktion nötigen Skripte/Prompts/Tuning-Werte versionsfixiert?
- Owner: Wo liegt die Verantwortungsfläche, wenn etwas scheitert? (bei uns? beim Vendor? beim Paket?)
- Ops: Sind Observability (Logs/Metriken), Rollback, Kostenobergrenzen und Auditierbarkeit im Design enthalten?
Fazit
2026 gewinnt nicht das „intelligentere Modell“, sondern
die Deployment-Einheit, die seltener explodiert.
Papers werden weiter erscheinen, aber der Markt kauft verpackte Intelligenz.
Auch Teams müssen sich entscheiden.
- ob sie weiter Rezepte implementieren
- oder auf Meal-Kit-Niveau paketieren und betreiben
One-liner
„Papers verkaufen Ideen, der Markt kauft Betrieb.“
2 Kommentare
Gab es in Unternehmen ursprünglich überhaupt Fälle, in denen man eine wissenschaftliche Arbeit gelesen, sie direkt selbst implementiert und dann eingesetzt hat ..?
Gibt es schon. Allerdings steigt man in den meisten Fällen eher über eine Open-Source-Referenzimplementierung ein, statt nach dem Lesen eines Papers alles von Grund auf neu zu bauen.
Wenn in letzter Zeit im AI-Bereich ein angesagtes Paper erscheint, tauchen zwar massenhaft POCs auf, aber in der Produktion kommt wegen Daten/Infra/Tuning oft etwas heraus, das zwar läuft, aber nicht „so schmeckt wie erwartet“.
Deshalb scheint es derzeit eine Tendenz hin zu paketierten Stacks wie vLLM oder Ollama zu geben.