Kein Verifier,kein KI-Loop.
KI-Loops sind das Thema, auf das 2026 alle zeigen. Die wichtigste Regel dazu klingt wie Praxiserfahrung — sie steht aber seit zehn Jahren in der Forschungsliteratur.
Was ist ein KI-Loop?
Ein Prompt ist eine Anweisung: Sie tippen, die KI antwortet, Sie tippen wieder. Ein KI-Loop ist ein Ziel: Sie legen fest, wann etwas „fertig“ ist, und das System arbeitet darauf hin — ohne dass jemand bei jedem Schritt zuschaut. Unter Begriffen wie Agentic AI, autonome Agenten oder KI-Schleifen ist das gerade das meistdiskutierte Thema der Branche.
Dieser Artikel prüft eine einzelne Behauptung dazu: dass eine solche Schleife eine unabhängige Prüfinstanz braucht, um überhaupt zu funktionieren. Wir haben dafür 602.340 wissenschaftliche Arbeiten daraufhin abgefragt, seit wann und wie oft die dazugehörigen Konzepte in der Forschung auftauchen — und was dort tatsächlich belegt ist.
So lesen Sie diesen Text · vier Belegarten
Die Regel ist zehn Jahre alt.
Das Risiko, das KI-Loops scheitern lässt, ist seit 2016 benannt. Die bekannteste Gegenmaßnahme stammt aus 2021 — und ist das meistzitierte Papier innerhalb unserer Auswertung.
Die Schlagzeile ist die Kurzform. Präzise lautet die belegte Aussage: Ohne ein Bewertungssignal, das das erzeugende System nicht selbst verändern kann, ist ein autonomer Loop nicht belastbar. Das ist etwas anderes als „Selbstprüfung ist wertlos“ — dazu gleich mehr.
Wer 2026 über KI-Loops liest, bekommt den Eindruck eines frischen Themas. Das ist es nicht. Wir haben unseren Bestand von 602.340 arXiv-Papieren ✓ nach den drei Begriffen abgefragt, die dieses Feld tragen: Verifier, Reward Hacking und LLM-as-a-Judge. Alle drei existieren länger, als die aktuelle Debatte vermuten lässt.
arXiv:1606.06565
Okt 2021 · arXiv:2110.14168
Drei Begriffe, drei Startpunkte.
Balkenbreite = 1 px je Papier. 2026-H2 ist unvollständig (Datenstand 23.07.2026) und deshalb nicht abgebildet. Volltextsuche über Titel und Abstract, Tokengrenzen — keine Teilwort-Treffer. Abfrage: 26.07.2026.
Der Verlauf erzählt eine klare Geschichte. Reward Hacking ist der älteste Begriff ✓ — 2016 benannt, dann zehn Jahre lang ein Nischenthema mit ein bis zwei Papieren pro Halbjahr. Das Prüfer-Prinzip folgt 2021 ✓. LLM-as-a-Judge ist der jüngste ✓, aber der am schnellsten wachsende.
Und dann, ab 2025, gehen alle drei gleichzeitig steil. Das zeitgleiche Wachstum spricht dafür, dass diese Themen mit der operativen Nutzung autonomer Systeme gemeinsam an Bedeutung gewonnen haben ○. Ein Beweis für Ursache und Wirkung ist es nicht — der allgemeine Sprachmodell-Boom und neue Bewertungsverfahren erklären einen Teil des Anstiegs ebenfalls.
Wer erzeugt, darf nicht benoten.
Der Kern jeder autonomen Schleife ist nicht das Modell, das arbeitet. Es ist die Instanz, die die Arbeit zurückweist.
Bereits 2016 beschreibt „Concrete Problems in AI Safety“ das Muster ✓: Ein System, das seine eigene Belohnung beeinflussen kann, optimiert irgendwann die Belohnung statt die Aufgabe. Der Fachbegriff dafür ist Reward Hacking. Das Papier hat in unserem Bestand 833 Zitationen ✓.
Fünf Jahre später liefert „Training Verifiers to Solve Math Word Problems“ die Gegenmaßnahme ✓: ein separat trainierter Prüfer, der Lösungen bewertet, statt sie zu erzeugen. Mit 7.051 Zitationen ist es das meistzitierte Papier in unserer gesamten Auswertung zu diesem Thema — und es stammt aus dem Oktober 2021.
Drei Begriffe, die oft verwechselt werden
An dieser Stelle wird in der Debatte viel durcheinandergeworfen. Die drei Konzepte hängen zusammen, sind aber nicht dasselbe — und nur wer sie trennt, trifft die richtige Architekturentscheidung:
Reward Hacking ist das Risiko: Ein System nutzt Schwächen im Bewertungssignal aus. Verifier ist eine mögliche Antwort darauf — und der kann regelbasiert, deterministisch oder gelernt sein. Ein bestandener Test zählt genauso wie ein trainiertes Prüfmodell. LLM-as-a-Judge ist wiederum nur eine Bauform des Prüfers, bei der ein Sprachmodell bewertet.
Wichtig ist die Unterscheidung, die häufig untergeht: MT-Bench untersucht 2023 systematisch, wie gut Sprachmodelle als Bewerter taugen ✓, ein Übersichtsartikel von Ende 2024 fasst den Forschungsstand zusammen ✓ — zusammen über 2.600 Zitationen. Das betrifft aber ein Modell, das fremde Ergebnisse bewertet. Ein Modell, das seine eigene Arbeit benotet, ist ein anderer Fall.
Und auch der ist nicht pauschal wertlos: Self-Refine zeigt 2023, dass Selbstkritik messbar hilft ✓. Die belegte Grenze verläuft nicht bei „Selbstprüfung ja oder nein“, sondern dort, wo das erzeugende System das Bewertungssignal verändern kann.
Wenn Sie eine KI-Schleife im Betrieb einsetzen wollen, ist die erste Frage nicht, welches Modell arbeitet. Sie lautet: Was weist schlechte Arbeit automatisch zurück — und kann das Modell diese Instanz beeinflussen? Wo die Antwort „nichts“ oder „ja“ lautet, haben Sie keine Schleife, sondern einen Kostenposten.
- Angewandte Regel
- Ein Optimierer, der sein eigenes Bewertungssignal verändern kann, optimiert früher oder später das Signal statt die Aufgabe.
- Belegt durch
- arXiv:1606.06565 (833 Zit.) · arXiv:2110.14168 (7.051 Zit.)
Viele messen. Wenige liefern den Code mit.
Diese Zahl ist für eine Investitionsentscheidung wichtiger als jede Wachstumskurve. Wir haben für alle drei Begriffe geprüft, wie viele Papiere ihren Code veröffentlichen — also überhaupt nachvollziehbar machen, wie das Ergebnis zustande kam.
95,8 % als empirisch geführt
90,7 % als empirisch geführt
97,9 % als empirisch geführt
Warum hier eine Spanne steht und keine Zahl
Die naheliegende Aussage wäre: „Vier von fünf Arbeiten messen, ohne Code zu liefern.“ Sie lässt sich aus diesen Zahlen nicht ableiten. Wir kennen zwei Randwerte — wie viele als empirisch klassifiziert sind und wie viele einen Code-Verweis führen — aber nicht ihre Schnittmenge. Möglich wäre, dass alle 145 Code-Arbeiten empirisch sind. Möglich wäre auch das Gegenteil.
Was sich exakt bestimmen lässt, sind die Grenzen. Bei 742 Treffern, davon 711 empirisch und 145 mit Code, liegt die Zahl der Arbeiten, die empirisch sind und keinen Code führen, zwischen 566 und 597:
Obergrenze 711 − max(0; 711 + 145 − 742) = 711 − 114 = 597
Untergrenze 711 − min(711; 145) = 711 − 145 = 566
Zwischen 76 und 80 Prozent der Verifier-Treffer sind als empirisch klassifiziert und führen keinen Code-Verweis ✓. Für Reward Hacking liegt die Spanne bei 75 bis 84 Prozent, für LLM-as-a-Judge bei 78 bis 80. Den exakten Wert liefern wir nach, sobald die Kreuzabfrage läuft: —
Das ist kein Vorwurf an die Forschung — Veröffentlichung ist aufwendig, und viele Teams haben gute Gründe. Es heißt auch nicht, dass diese Ergebnisse falsch oder nie überprüft wurden: Andere Gruppen können eine Methode aus der Beschreibung nachgebaut haben, und Code kann außerhalb der von uns erfassten Felder liegen.
Wenn ein Anbieter Ihnen eine Zahl aus einem Papier zeigt, können Sie aus der Veröffentlichung allein meist nicht erkennen, ob dieses Ergebnis außerhalb des Autorenteams jemals reproduziert wurde. Fragen Sie nach dem Repository, nicht nach dem Papier. Und verlangen Sie einen Testlauf auf Ihren eigenen Daten, bevor Budget fließt.
- Angewandte Regel
- Ohne veröffentlichten Code ist eine unabhängige Reproduktion erheblich aufwendiger — und für einen Entscheider nicht unmittelbar prüfbar. Das sagt nichts darüber aus, ob das Ergebnis stimmt.
- Belegt durch
- Eigene Auswertung, 2.181 Treffer in drei Abfragen · Datenstand 23.07.2026
Wie diese Zahlen entstanden sind.
Wer Belege verlangt, muss sein eigenes Verfahren offenlegen. Das gilt auch für die Stellen, an denen wir unsere eigene Methodik nicht vollständig belegen können.
- Datenbasis
- 602.340 arXiv-Arbeiten aus cs.AI, cs.LG, cs.CL, cs.CV, cs.RO · 01.04.2007 bis 23.07.2026 · 11,6 Mio. Referenzkanten
- Suchverfahren
- Begriffssuche in Titel und Abstract — nicht im Volltext der Arbeiten. FTS5 mit Tokengrenzen (unicode61), daher keine Teilwort-Treffer. Abfrage vom 26.07.2026.
- Überschneidungen
- 742 + 518 + 921 = 2.181 Treffer in drei Abfragen, nicht 2.181 verschiedene Arbeiten. Eine Arbeit kann in mehreren Gruppen vorkommen. Anteil der Mehrfachtreffer: —
- Zitationen
- Referenzkanten innerhalb dieses Bestands. Zitate aus Arbeiten außerhalb des Bestands fehlen — die tatsächliche Zitationszahl liegt höher. Kein Google-Scholar-Wert.
- Code-Erkennung
- Feld llm_has_code, befüllt durch eine LLM-gestützte Auswertung von Abstract und Metadaten. Nicht manuell validiert. Erwartete Fehlerquote: — · Die Quote misst damit auch die Erkennungsmethode, nicht nur das Publikationsverhalten.
- Klassifikation „empirisch“
- Feld llm_is_empirical, gleiches Verfahren, gleiche Einschränkung. Erwartete Fehlerquote: —
Die Code-Quote trägt als Größenordnung, nicht als Punktwert ○. Ob 19,5 oder 24 Prozent — die Aussage bleibt: Die Mehrheit der Arbeiten macht ihre Ergebnisse nicht ohne Weiteres nachvollziehbar. Auf die zweite Nachkommastelle würden wir uns nicht verlassen, und Sie sollten es auch nicht.
Fünf Fragen, bevor Budget fließt.
Wenn Ihnen jemand einen autonomen KI-Loop vorschlägt, klären diese fünf Fragen den Großteil des Risikos. Sie folgen direkt aus den Belegen oben.
- 01 Gibt es ein messbares Annahme- oder Ablehnungskriterium — oder entscheidet am Ende doch ein Mensch per Augenmaß?
- 02 Kann das erzeugende System dieses Kriterium verändern? Wenn ja, ist Reward Hacking nur eine Frage der Zeit.
- 03 Was passiert bei Unsicherheit — Abbruch, Rückfrage oder einfach die nächste Runde?
- 04 Gibt es harte Kosten-, Zeit- und Wiederholungslimits? Loops lesen Kontext neu und versuchen erneut — mit oder ohne Ergebnis.
- 05 Wird gegen echte Unternehmensdaten getestet, nicht gegen ein Demo-Set?
- Angewandte Regel
- Die Fragen 01 und 02 folgen aus den Belegen dieses Artikels. 03 bis 05 sind Betriebserfahrung — sie stehen so nicht in der ausgewerteten Literatur.
Vier Antworten, die wir nicht geben.
Diese Fragen sind für eine Entscheidung wichtig. Unsere Daten beantworten sie nicht — deshalb stehen sie hier offen statt gefüllt.
Leerstellen
- Wie viele deutsche Mittelständler setzen autonome Schleifen produktiv ein?
- — Kein Datensatz vorhanden. arXiv erfasst Forschung, nicht Betriebspraxis.
- Was kostet ein solcher Loop im Monat, realistisch?
- — Hängt an Modell, Kontextlänge und Abbruchkriterium. Keine belastbare Spanne aus unseren Quellen.
- Ab welcher Betriebsgröße lohnt sich das?
- — Keine Studie in unserem Bestand untersucht das nach Unternehmensgröße.
- Gibt es das Papier, das eine Verfünffachung durch eine Meta-Schleife berichtet?
- — In der Fachdiskussion kursiert diese Zahl für März 2026. Wir konnten sie im Bestand bisher keiner eindeutigen Arbeit zuordnen. Bis dahin: kein Beleg, keine Behauptung.
Genau diese vier Fragen entscheiden in der Praxis über Erfolg oder Fehlinvestition ○ — und sie lassen sich nur mit Blick auf einen konkreten Betrieb beantworten, nicht aus einem Datensatz.
Diese Fragen für Ihren Betrieb klären DoWell UG · Hamburg
Alle Quellen dieses Artikels.
| arXiv-ID | Titel | Datum | Art | Zit. |
|---|---|---|---|---|
| 2110.14168 | Training Verifiers to Solve Math Word Problems | 2021-10-27 | Primär · Forschung | 7.051 |
| 2201.11903 | Chain-of-Thought Prompting Elicits Reasoning in Large Language Models | 2022-01-28 | Primär · Forschung | 2.483 |
| 2212.08073 | Constitutional AI: Harmlessness from AI Feedback | 2022-12-15 | Primär · Forschung | 2.394 |
| 2306.05685 | Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena | 2023-06-09 | Primär · Forschung | 1.821 |
| 2408.03314 | Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters | 2024-08-06 | Primär · Forschung | 1.340 |
| 2411.15594 | A Survey on LLM-as-a-Judge | 2024-11-23 | Primär · Forschung | 837 |
| 1606.06565 | Concrete Problems in AI Safety | 2016-06-21 | Primär · Forschung | 833 |
| 2303.17651 | Self-Refine: Iterative Refinement with Self-Feedback | 2023-03-30 | Primär · Forschung | 781 |
| 2408.06292 | The AI Scientist: Towards Fully Automated Open-Ended Scientific Discovery | 2024-08-12 | Primär · Forschung | 640 |
| 2401.10020 | Self-Rewarding Language Models | 2024-01-18 | Primär · Forschung | 466 |
| 2408.15240 | Generative Verifiers: Reward Modeling as Next-Token Prediction | 2024-08-27 | Primär · Forschung | 249 |
| BrunoSan arXiv | Eigene Auswertung über 602.340 Papiere · Volltextsuche mit Tokengrenzen · Zitationen aus 11,6 Mio. aufgelösten Referenzkanten | 2026-07-26 | Primär · Eigene Erhebung | — |
Zitationszahlen sind Referenzkanten innerhalb des BrunoSan-arXiv-Bestands, nicht Google-Scholar-Werte. Sie zählen ausschließlich Zitate aus Papieren, die selbst im Bestand liegen — die tatsächliche Zitationszahl liegt damit höher.
Was Leser dazu meistens fragen.
Heißt „Substanz“, dass ich jetzt Loops bauen sollte?
Was genau ist ein Verifier?
Warum sind nur 19,5 Prozent mit Code ein Problem?
Wie aktuell sind diese Zahlen?
Ist dieser Text mit KI erstellt?
Diese Zahlen stammen nicht aus einer Suchmaschine. Sie stammen aus 602.340 wissenschaftlichen Arbeiten, die bei uns als einzelne Objekte vorliegen — jedes mit eigener ID, verknüpft über 11,6 Millionen Referenzkanten. Deshalb können wir sagen, wann ein Begriff zum ersten Mal auftauchte und wer wen zitiert. Ein reiner Stichwortindex ohne Objekt- und Zitationsgraph kann das nicht.
Dieselbe Technik, angewandt auf Ihre Dokumente: Atomizer macht Verträge, Rechnungen und Protokolle über Nacht zu abfragbaren Objekten. BrunoSan Assistant beantwortet Fragen darauf — mit Quelle zur Originalstelle, nicht mit einer plausiblen Formulierung. Den arXiv-Bestand selbst gibt es als MCP-Server für eigene Agenten.