Informationsgewinn und Slop: So messen wir sie

Informationsgewinn

Leser kommen mit Fragen zu einem Text, bei einem Bug-Report etwa: welche Version, welcher Browser, ab wie vielen Zeilen. Der Informationsgewinn ist der Anteil dieser Fragen, den der Text beantwortet. Bei 100 % bleibt nichts mehr zu fragen; ein Formular mit leeren Feldern liegt nahe 0 %. Das Modell in Ihrem Browser schätzt diesen Anteil als Bewertung von 0 bis 10 und zeigt ihn in Schritten von 5 %.

Die Idee geht auf Claude Shannon zurück, der Information in Bit maß: Ein Bit ist die Antwort auf eine Ja-Nein-Frage (Shannon, 1948). Ein Bug-Report mit „große Exporte schlagen fehl“ lässt die Entwicklerin 12.300 Zeilen probieren, dann 11.000, eine Ja-Nein-Frage nach der anderen; „Exporte über 10.000 Zeilen schlagen fehl“ beantwortet alle auf einmal. Warren Weaver beschrieb drei Ebenen der Kommunikation: ob die Zeichen ankommen, ob sie die gemeinte Bedeutung vermitteln und ob sie das Handeln des Empfängers ändern (Weaver, 1949); Slopcheck arbeitet auf der zweiten und der dritten Ebene.

Informationsgewinn in der SEO

In der SEO steht der Begriff dafür, was eine Seite über die Seiten hinaus bietet, die ihre Leser schon gesehen haben. Google hält ein Patent auf einen solchen Wert, „Contextual estimation of link information gain“ (US 11,354,342 B2, erteilt am 7. Juni 2022). Ein Patent zeigt nicht, dass ein Wert im Ranking genutzt wird; Googles öffentliche Leitlinien fragen, ob Inhalte „neuartige Informationen, Darstellungen in Berichtsform, Forschungsergebnisse oder Analysen“ bieten (Google Search Central). Slopcheck misst den Teil, der sich an einem einzelnen Text ablesen lässt, ohne Vergleich mit anderen Seiten: den Anteil der Leserfragen, die er beantwortet, von 0 bis 100 %.

Was eine Aussage ausschließt

Rudolf Carnap und Yehoshua Bar-Hillel beschrieben die semantische Seite der Information: Eine Aussage trägt umso mehr Information, je mehr mögliche Zustände der Welt sie ausschließt (Carnap und Bar-Hillel, 1952). „Der Export bricht bei Bestellungen mit mehr als 500 Positionen in Chrome 128 ab“ schließt weit mehr aus als „der Export klappt manchmal nicht“. Eine ausdrücklich genannte Schwelle ist die stärkste Form: „3.1.4 funktioniert, 3.2.0 nicht“ sagt der Entwicklerin, in welchem Release sie suchen muss.

Ob eine Aussage wahr ist, ist eine andere Frage (Stanford Encyclopedia of Philosophy). Slopcheck prüft keine Fakten: „Bestellungen mit mehr als 500 Positionen“ zählt gleich viel, unabhängig davon, ob die tatsächliche Schwelle bei 500 oder bei 5.000 liegt.

Worauf es Lesern ankommt

Ronald Howard zeigte 1966, dass Information so viel wert ist, wie sie an einer Entscheidung ändert (Howard, 1966). Für eine Entwicklerin entscheidet „Chrome 128“, welcher von 3 Browsern getestet wird; „der Export ist wichtig“ entscheidet nichts. Auf einer Produktseite ändert „4 EUR pro Nutzer im Monat, die ersten 30 Tage gratis“ die Kaufentscheidung, „ein nahtloses Erlebnis“ nicht. Bei einem Bug-Report bestimmen Version, Schritte und Schwelle den nächsten Schritt der Entwicklerin.

Slop

Slop ist der in Wörtern gezählte Anteil des Textes, der keine Leserfrage beantwortet. Wir unterscheiden 4 Arten: leere Sätze, die in jeden Text passen, offensichtliche, die nichts ausschließen, was Leser erwogen haben, irrelevante, die keine Entscheidung ändern, und unauflösbare wie „wie besprochen“ oder „wie dort“, außerdem Wiederholungen von bereits Gesagtem; im Ergebnis ist jeder Slop-Satz markiert.

Als Gesprächsbeitrag verletzt Slop 2 der Maximen, die Paul Grice beschrieben hat: so viel sagen wie nötig, aber nicht mehr, und nur Relevantes sagen (Grice, 1975). Wiederholungen sind das, was Shannon Redundanz nannte: der Teil einer Nachricht, den Leser aus dem Rest vorhersagen können.

Stil ist kein Slop: „Wir haben den CSV-Export repariert“ und „Das Problem mit dem CSV-Export wurde behoben“ zählen gleich.

Wie die beiden Zahlen zusammenhängen

Slop trägt keine Information: Je mehr Slop ein Text enthält, desto niedriger liegt die Obergrenze für seinen Informationsgewinn. Ein Text mit 60 % Slop erreicht höchstens etwa 50 %, einer mit 95 % Slop oder mehr höchstens 10 %. Volle 100 % zeigen wir nur, wenn kein Satz Slop ist; sonst endet der Informationsgewinn bei 95 %. Länge ist nicht das Ziel: Ein Bug-Report mit 50 Wörtern kann 90 % erreichen.

Bug-Reports, Aufgaben und Produktseiten

Wir haben 27 Fragen notiert, mit denen Leser an einen Text herangehen: 7 für jeden Text, 8 für Bug-Reports, 7 für Aufgaben und 5 für Produktseiten. Ein Bug-Report beantwortet: welche Version, welche Schritte, was erwartet wurde, was passiert ist, ob immer oder manchmal und seit welchem Release. Eine Aufgabe beantwortet: was, wo, warum, wie man prüft, dass sie erledigt ist, und was nicht angefasst wird; gute Akzeptanzkriterien lesen sich wie „34 Einstellungen, 4 Tabs, Texte bleiben unverändert“. Bei einer Produktseite geht es um 5 Fragen: Zielgruppe, Funktion, Beleg, Preis und nächster Schritt. Das Modell hat diese Unterschiede aus 2.424 Beispielen gelernt, die ein Sprachmodell bewertet hat; deshalb müssen Sie vor dem Einfügen keine Textsorte wählen.

5 Versionen in 4 Tagen

Version 1 vom 19. Oktober 2026 zählte Funktionswörter, Füllwörter und konkrete Angaben pro 100 Wörter. Version 2 erfasste zusätzlich, wie selten die Wörter sind, gemessen an Häufigkeitslisten, die wir aus rund 600.000 Wörtern Wikipedia-Text pro Sprache erstellt haben. Auf 55 Webseiten, die zwei Sprachmodelle als Bewerter eingestuft hatten, erwies sich das als Rauschen (AUROC 0,45 bis 0,49), also haben wir es gestrichen. Version 3 urteilte nach Konkretheit pro 100 Wörter. Auf 37 neuen, für den Test zurückgehaltenen Seiten lag ihr Urteil „zu wenig Substanz“ in 1 von 9 Fällen richtig, also wurde daraus ein Hinweis.

Version 4 nutzte einen Katalog von rund 1.000 Mustern in 5 Sprachen und trennte auf denselben 37 Seiten aufgeblähte von dichten Seiten (AUROC 0,75; diese Ergebnisse hatten wir während der Entwicklung gesehen, der Wert ist also optimistisch). Bei echten Bug-Reports lag sie auf Zufallsniveau (0,47 bis 0,52). Dieses Scheitern führte uns vom Zählen von Wörtern zum Zählen offener Leserfragen und zu Version 5 (s2) vom 22. Oktober; am 24. Oktober haben wir sie für 12 Sprachen neu trainiert (s3).

Was uns Bugtracker gezeigt haben

Wir haben 1.355 Bug-Reports aus Mozilla Bugzilla von 2023 bis 2025 ausgewertet. Reports, die als unvollständig oder „works for me“ geschlossen wurden oder deren Autor um weitere Angaben gebeten wurde, waren länger als Reports, die ohne solche Rückfrage behoben wurden (Median 165 gegen 124 Wörter), und konkreter. Externe füllen nämlich die komplette Vorlage aus, die in 38 % der „works for me“-Reports und in 14 % der behobenen steht, während Entwickler kurze Notizen schreiben, die gemeinsamen Kontext voraussetzen. Das Ergebnis im Tracker spiegelte also wider, wer den Report geschrieben hatte; seitdem vergleichen wir Reports desselben Autors.

In Apache Jira haben wir 11.129 seit 2022 erstellte Bug-Reports aus 165 Projekten gesammelt und behobene mit solchen verglichen, die als „Cannot Reproduce“ oder „Incomplete“ geschlossen wurden. Ein Befund prägte die Methode: Ein Sprachmodell las 240 dieser Reports, 120 Paare desselben Autors, ohne Ergebnis und Autor zu kennen. Auf die Frage, ob eine Version oder Umgebung angegeben ist, fand es eine solche Angabe in den schlecht aufgenommenen Reports häufiger (63 % gegen 50 %). Auf die Frage, was einer Entwicklerin noch fehlt, nannte es bei denselben Reports häufiger Version oder Umgebung (48 % gegen 33 %). Ein Detail zu erwähnen heißt nicht, die Frage zu beantworten.

Regeln aus der manuellen Prüfung

Wir haben 35 Texte von Hand bewertet, die meisten auf einer Skala von 0 bis 10: 0 ist ein Formular ohne Inhalt, 5 bis 6 ist nach ein paar Rückfragen machbar, 9 lässt eine Frage offen, 10 lässt nichts offen. Zu 28 dieser Texte stellte unser erster Fragenkatalog 86 Fragen. 35 davon haben wir markiert: 26 als berechtigt und 9 als überflüssig. Daraus entstand ein schriftlicher Leitfaden mit 37 Regeln und 33 Testfällen.

Beispiele für Regeln: Eine Aussage ohne Einschränkung gilt immer und überall, eine fehlende Version kostet also nichts, solange der Text nicht „manchmal“ oder „nach dem Update“ sagt; ein Verbot zählt nur, wenn es einen Weg ausschließt, den die Aufgabe nahelegt; widersprüchliche Anforderungen kosten am meisten. In einem Test stieg die Bewertung derselben Fakten, neu geschrieben mit klarem Zusammenhang und benanntem Objekt, von 1 auf 9 bis 10 von 10. In einem anderen war ein von Hand mit 10 bewerteter Report als „Cannot Reproduce“ geschlossen worden: Ein Ergebnis im Tracker ist ein Signal, kein Urteil.

Sprachmodelle als Bewerter und als Lehrer

Die 37 Regeln haben wir zu einem Bewertungsleitfaden für große Sprachmodelle umgeschrieben und 5 Modelle an den 27 Texten mit Zahlenwert aus der manuellen Bewertung verglichen. Die Regeln stammen aus diesen Texten; der Vergleich zeigt also, wie genau ein Modell den Regeln folgt, nicht, wie es bei neuen Texten abschneidet. Die zwei besten lagen bei 22 von 27 Texten höchstens 1 Punkt neben der manuellen Bewertung (Rangkorrelation bis 0,94), das schwächste bei 12 von 27.

Eines der beiden bewertete danach 2.424 Texte Satz für Satz: 600 öffentliche Aufgaben und Bug-Reports aus Apache Jira, 384 Texte mit denselben Fakten, die Sprachmodelle in 4 Stilen geschrieben haben, 600 Texte, die es selbst für das Training auf Deutsch, Polnisch, Tschechisch, Kroatisch und Russisch geschrieben hat, und 840 Texte, je 120 auf Slowakisch, Slowenisch, Bulgarisch, Französisch, Italienisch, Spanisch und Niederländisch, die Sprachmodelle geschrieben haben, ohne die Regeln zu kennen. Das sind 18.420 bewertete Sätze, 21,4 % davon Slop. Das kleine Modell in Ihrem Browser hat aus diesen Bewertungen gelernt. In der Kreuzvalidierung liegt seine Rangkorrelation mit dem Lehrer bei 0,85. Bei Texten, die nicht im Training waren, findet es die Slop-Sätze des Lehrers mit einer AUROC von 0,92. Seine Rangkorrelation mit den manuellen Bewertungen von 25 Texten liegt bei 0,81, doch die Regeln, die zusätzlich zum Modell gelten, stammen aus denselben Texten. Ein faireres Maß sind deshalb die Tests mit zurückgehaltenen Daten weiter unten.

Wenn Sie einen Text prüfen, liest ihn kein Sprachmodell. Ein Modellaufruf würde den Text an Dritte schicken, könnte für denselben Text unterschiedliche Antworten liefern und würde pro Prüfung Geld kosten. Das kleine Modell läuft mit rund 350 KB festen Gewichten.

Vorhersagen vorab notiert

Vor 5 Experimenten haben wir unsere Vorhersagen in eine Datei geschrieben und sie vor dem Test gespeichert; für den Mustertest vom 20. Oktober 2026 beginnt die MD5-Prüfsumme der Datei mit ff01ce1a. Wir sagten voraus, dass die schlichte Fassung eines Textes die Assistenten-Fassung in 85 % bis 95 % der Paare schlägt; es waren 79 %. Wir sagten voraus, dass abgelehnte Bugzilla-Reports kürzer sind; sie waren länger, mit einem Median von 165 gegen 124 Wörter. Bei Jira-Paaren desselben Autors lagen 3 von 4 Vorhersagen daneben. Nach dem Fehlschlag bei Bugzilla haben wir in jedem späteren Vergleich Reports desselben Autors verwendet.

Was nicht funktioniert hat

Die Seltenheit von Wörtern (AUROC 0,45 bis 0,49). Der Anteil von Funktions- und Füllwörtern, der auf zurückgehaltenen Seiten nur eine AUROC von 0,31 erreichte, schlechter als Zufall. Ein Urteil „zu wenig Substanz“, das in 1 von 9 Fällen stimmte. Das Zählen von Bedeutungseinheiten oder eine Vollständigkeits-Checkliste mit 5 Punkten, deren Rangkorrelation mit einer Lektüre des ganzen Textes nur 0,18 bis 0,26 betrug. 8 Indikatoren nach dem Vorbild von Suchmaschinensignalen, schon im Entwurf verworfen. Der Vergleich einer Seite mit den ersten 3 bis 10 Suchergebnissen, der eine kostenpflichtige Such-API braucht. Weit gefasste Varianten der expliziten Regeln, die bei 33 Jira-Reports anschlugen; jeder geprüfte Treffer war ein Fehlalarm. Ein Sprachmodell zur Prüfzeit: Es kam den manuellen Bewertungen am nächsten, hätte Ihren Text aber an Dritte geschickt.

Wie wir die Methode testen

Wir halten 24 Briefings auf Englisch und Deutsch zurück, jedes in 4 Fassungen von Sprachmodellen geschrieben. Die schlichte Fassung erzielt in allen 24 Paaren einen höheren Wert als die aufgeblähte und in 83 % einen höheren als die Assistenten-Fassung. Für jede der 7 am 24. Oktober hinzugekommenen Sprachen halten wir 6 weitere Briefings in 4 Fassungen zurück: Die schlichte Fassung schlägt die aufgeblähte in jedem Paar und die Assistenten-Fassung in 100 % der Paare auf Slowakisch und Slowenisch, in 92 % auf Italienisch und Niederländisch, in 83 % auf Bulgarisch und Französisch und in 58 % auf Spanisch.

Bei 120 zurückgehaltenen Paaren von Jira-Reports desselben Autors liegt der behobene Report in rund 60 % der Paare vorn. Ein Sprachmodell, das dieselben 240 Reports blind liest, ohne Ergebnis und Autor zu kennen, kommt auf 64 %. Die englischen und deutschen Briefings und die Jira-Paare waren nicht im Training, aber wir haben mit ihnen zwischen Varianten der expliziten Regeln gewählt. Bei neuen Texten können die Werte daher etwas niedriger ausfallen. Ob ein Report als behoben oder als „Cannot Reproduce“ geschlossen wird, hängt auch vom Fehler selbst ab: Er kann in einer neueren Version schon behoben sein, nur in einer Umgebung auftreten oder auf einen Konfigurationsfehler zurückgehen. Deshalb sind bei diesem Test keine 100 % möglich.

Wie die Schätzung berechnet wird

Für den ganzen Text wertet das Modell 182 Signale aus, etwa Zahlen, Versionen, Bedingungen, Schwellenwerte, Namen, zitierte Meldungen, vage Wörter, unbelegte Behauptungen, Wiederholungen und leere Vorlagenüberschriften, dazu Wörter und Wortpaare, die in 16.384 Zellen gehasht werden. Für jeden Satz entscheidet ein zweites Modell mit 68 Signalen und denselben gehashten Wörtern, ob er Slop ist. Das Textmodell ist eine lineare Regression auf diesen Signalen, das Satzmodell eine logistische Regression, beide angepasst an die 2.424 bewerteten Texte. Zusätzlich zum Modell gelten 3 Regeln aus der manuellen Prüfung. Eine Startzeit nach der Frist kostet 25 Punkte. Eine Aufgabe, die mit „Aufteilen in 4 Tabs“ beginnt und nie sagt, was aufgeteilt wird, erhält höchstens 20 %. Eine Vorlage mit leeren Überschriften erhält höchstens 10 %. Die Gewichte sind etwa 350 KB groß und werden mit der Seite geladen. Ein Text mit 3.000 Zeichen ist in unter 100 Millisekunden geprüft.

Sätze und Sprachen

Wir teilen den Text an Punkten, Frage- und Ausrufezeichen, Auslassungspunkten und Zeilenumbrüchen in Sätze, aber nicht innerhalb von „v8.1“, „1.200“ oder einer Webadresse und nicht nach einem Datum wie „7. Juni“. Unterstützt werden 12 Sprachen: Deutsch, Englisch, Polnisch, Tschechisch, Slowakisch, Kroatisch, Slowenisch, Bulgarisch, Französisch, Italienisch, Spanisch und Niederländisch. Die Sprache wird automatisch erkannt: auf unseren früheren Testdaten zu 99,6 % richtig, bei kurzen Texten in den neuen Sprachen zu 97,1 %. Die Listen mit Slop-Phrasen für die 11 Sprachen außer Englisch haben wir selbst zusammengestellt; für Deutsch, Polnisch, Tschechisch und Kroatisch fanden wir keine frei verfügbaren. Die kostenlose Prüfung akzeptiert 80 bis 3.000 Zeichen. Das deckt 97,5 % der gesammelten Jira-Bug-Reports ab, Codeblöcke nicht mitgezählt. Bekannte Verzerrung: Schon die Sprache verschiebt die Schätzung um ein paar Punkte. Bei gleichen Signalen erhalten spanische, französische, tschechische und italienische Texte 5 bis 8 Punkte weniger als englische, deutsche und niederländische etwa 4 Punkte mehr; vergleichen Sie Werte deshalb innerhalb einer Sprache.

Was wir nicht messen

Nicht gemessen werden Autorschaft, Wahrheit und Ranking bei Google oder Bing. In einer Stichprobe des öffentlichen RAID-Benchmarks auf Englisch erkannten regelbasierte Textmerkmale höchstens 28 % der KI-generierten Texte bei einer Fehlalarmrate von 5 %, deshalb bieten wir keine Erkennung der Autorschaft an. Eine Notiz von 2 Zeilen kann für ein Team mit gemeinsamem Kontext genau richtig sein: Die Schätzung sieht nur den Text.

Fragen

Wie prüfe ich einen Text auf KI-Slop?

Fügen Sie ihn auf der Startseite in das Feld ein: 80 bis 3.000 Zeichen, bis zu 5 Texte pro Tag kostenlos. Sie sehen den Informationsgewinn und den Slop-Anteil; die Slop-Sätze sind im Text markiert.

Wird mein Text gespeichert oder irgendwohin gesendet?

Nein. Die Prüfung läuft in Ihrem Browser: Der Text wird nicht an uns gesendet und nicht gespeichert. Der Ergebnislink enthält den Text im Teil der Adresse nach dem #-Zeichen, den Browser nicht an Server senden.

Welche Texte kann ich prüfen?

Artikel, Produktseiten, Beiträge, Aufgaben, User Stories und Bug-Reports in 12 Sprachen: Deutsch, Englisch, Polnisch, Tschechisch, Slowakisch, Kroatisch, Slowenisch, Bulgarisch, Französisch, Italienisch, Spanisch und Niederländisch, mit 80 bis 3.000 Zeichen.

Wie schreibe ich einen guten Bug-Report?

Beschreiben Sie, wie sich das Problem nachstellen lässt: welche Schritte, welche Version, welches Gerät und ab welcher Schwelle der Fehler auftritt. In einer Studie mit 180 reproduzierbaren Android-Bug-Reports fehlte bei 92,2 % mindestens 1 Schritt (Johnson et al., 2022). „Der Export bricht bei Bestellungen mit mehr als 500 Positionen in Chrome 128 ab“ schließt weit mehr aus als „der Export klappt manchmal nicht“. Fügen Sie den Bericht in die Prüfung ein, dann sehen Sie, welche Sätze keine dieser Fragen beantworten.

Ist Slopcheck ein KI-Detektor?

Nein. Slopcheck schätzt, wie viel ein Text seinen Lesern sagt. Wer oder was ihn geschrieben hat, sagt es nicht: Ein generierter Text mit echten Fakten kann gut abschneiden, ein handgeschriebener ohne Fakten schneidet schlecht ab.

Was unterscheidet Slopcheck von Prüfern, die nach KI-Merkmalen suchen?

Werkzeuge, die Gedankenstriche, „delve“ oder „tapestry“ zählen, achten auf die Oberfläche eines Textes. Slopcheck achtet darauf, was Leser davon haben: Ein Text kann jedes Merkmal vermeiden und trotzdem keine einzige Leserfrage beantworten.

Was ist ein Textpass?

Ein Nachweis für genau einen Text: Hash, Informationsgewinn, Slop, Methodenversion und Prüfdatum, auf einer Seite mit eigenem Link. Wer den Text hat, fügt ihn dort ein und sieht, ob er übereinstimmt: Weicht auch nur 1 Zeichen ab, ändert sich der Hash. Jede Überarbeitung wird als neue Fassung mit eigenen Werten gespeichert.

Brauche ich ein Plugin oder ein SDK für die API?

Nein. Im Tarif Team ist die Prüfung ein einziger HTTP-Aufruf mit dem Text. Er passt in einen CI-Schritt, einen Hook vor dem Veröffentlichen im CMS oder ein Feld in Ihrem Ticketsystem.

Quellen

Prüfen Sie Ihren Text

Fügen Sie einen Artikel, eine Produktseite, eine Aufgabe oder einen Bug-Report ein und sehen Sie, wie hoch Informationsgewinn und Slop-Anteil sind.

Text kostenlos prüfen

So zählen wir