Daniel Auferbauer schreibt Blogbeiträge

Creative Commons Signals: Fairness im Zeitalter der generativen KI?

2025-07-15T00:00:00Z

Creative Commons (CC) hat am 26. Juni 2025 das CC Signals-Projekt öffentlich angekündigt. Signals wird als "ein großer Schritt nach vorne beim Aufbau eines gerechteren, nachhaltigeren Ökosystems für KI, das sich auf gemeinsame Vorteile stützt" vorgestellt. Signals befindet sich derzeit in einer Pre-Alpha-Phase, in der CC Feedback erbittet. Die eigentliche Alpha-Phase ist für November 2025 geplant. Ich war neugierig, wie sich CC ein nachhaltiges KI-Ökosystem vorstellen könnte und habe mich etwas mit dem Dokument auseinandergesetzt, das dem Vorschlag von Signals zugrunde liegt.

Einleitung

CC hat sich immer darum bemüht, einen Mittelweg für AutorInnen zu finden, zwischen "alle Rechte vorbehalten" und dem vollständigen Kontrollverlust bezüglich der eigenen Inhalte. Die Idee ist, dass jeder, der die Commons nutzt, im Gegenzug auch zu den Commons beitragen soll, indem er oder sie geteilte Inhalte entsprechend den Angaben des Autors bzw. der Autorin behandelt. Signals scheint nach einem Weg zu suchen, diese Idee an die neue Allgegenwärtigkeit der generativen KI (GenAI) anzupassen.

Zugleich kommt es zu einer erneuten Diskussion betreffend die Regulierung von Web-Crawlern und Web-Scraping. Die Regulierung der automatischen Verarbeitung von Web-Inhalten begleitet das Web seit seinen Anfängen. Die heute allgegenwärtige robots.txt wurde bereits 1994 eingeführt, um die übermäßige Belastung von Servern durch Web-Crawler zu regulieren. Die Diskussion um die Ethik und Regulierung von Web-Crawlern und Web-Scraping rückte mit dem Aufkommen von Internetsuchmaschinen in den 2000er Jahren vermehrt ins Rampenlicht. Die weitreichende Wiederverwendung von gesammelten Inhalten lenkte die Aufmerksamkeit außerdem auf Urheberrechtsfragen. Zum Beispiel wurde Google in einem prominenten Fall aus dem Jahr 2006 verklagt, weil ihr Seiten-Caching angeblich das Urheberrecht verletzt.

Im Laufe der Zeit hat man sich auf ein pragmatisches Übereinkommen verständigt, das keine explizite Rechtsgrundlage aufweist: Web-Crawler sind akzeptabel, solange sie eine Gegenleistung in Form von Website-Besuchern liefern. Mit anderen Worten, es ist in Ordnung, dass Google meine Seite mit einem Web-Crawler abruft, weil ich dadurch Besucher erhalte. Mit der Akzeptanz dieses impliziten sozialen Übereinkommens beruhigte sich die Diskussion um die Regulierung von Web-Crawlern.

Das zeitgenössische Problem

Der Aufstieg von GenAI und Large Language Models (LLM) hat das oben beschriebene soziale Übereinkommen untergraben. GenAI und LLMs verdanken ihr Dasein enormen Datenmengen, welche durch Web-Crawler und Web-Scraping beschafft werden. Diese Daten finden bei GenAI bzw. LLMs auf zwei Arten Verwendung:

als Trainingsdaten für das Modell selbst (d.h., die Daten sind in das LLM "eingebettet").
als Erweiterung nach dem Training, als Reaktion auf eine Benutzereingabe, z.B. bei Retrieval Augmented Generation (RAG).

GenAI wird selten, wenn überhaupt, unaufgefordert Quellen aus den eigenen Trainingsdaten referenzieren. Das ist unter zwei Gesichtspunkten relevant: 1) aus der Sicht von CC bedeutet dies, dass es keine "Attribution" gegeben wird, während es 2) im Hinblick auf das beschriebene soziale Übereinkommen bedeutet, dass keine Website-Besucher weitergeleitet werden.

Bei RAG sieht die Sache ähnlich aus: wenn GenAI in Echtzeit Daten aus dem Web abruft, zitiert sie meiner Erfahrung nach mittlerweile oft. Während das dem Autor bzw. der Autorin Webseitenbesucher oder Anerkennung bringen könnte, wird in der Realität durch die Aggregation und Zusammenfassung von Informationen der Anreiz für den Benutzer, die Website tatsächlich zu besuchen, stark reduziert.

CC Signals

Im Dokument From Human Content to Machine Data argumentiert CC, dass die Untergrabung des sozialen Übereinkommens rund um die Web-Crawler zu einer Abschottung von Informationen führen wird, was nicht im Sinne des öffentlichen Interesses wäre.

Um den öffentlichen Zugang zu Wissen aufrechtzuerhalten fordert CC für die Commons wechselseitige Beiträge von AutorInnen und KI-Modellen ein. CC schlägt sogenannte Signals vor. Signals sind eine Reihe von Angaben, die KI-Modellen anzeigen sollen, welchen Beitrag sie zu den Commons leisten müssen.

Signals können aus einer Kombination von vier Kernelementen bestehen. Diese Kernelemente sind derzeit noch sehr vage formuliert, sodass ich bestenfalls die Absicht dahinter verstehen kann, ohne Details zur Implementierung.

Credit: Tut, was der Name sagt: dieses Signal erfordert "Attribution" im Sinne der CC, d.h. der Autor bzw. die Autorin muss klar ersichtlich sein. Das Signal bedingt mindestens eine Referenz auf den Trainingsdatensatz. Im Fall von RAG und ähnlichen Techniken muss ein Output die Quelle(n) mit Link zitieren.
Direct Contribution: Dieses Element scheint darauf abzuzielen, die Kosten für die Bereitstellung von Daten zu erstatten. Ich interpretiere das folgendermaßen: wenn Sie beispielsweise eine Content-Plattform betreiben, verlangt die Verwendung dieses Signals eine gewisse Gegenleistung von KI-Betreibern, damit Sie nicht alleine auf den erhöhten Kosten durch Web-Crawler sitzen bleiben.
Ecosystem Contribution: Dieses Signal erscheint noch eher nebulös und wird wohl erst im Laufe der Alpha-Phase Gestalt annehmen. Augenscheinlich zielt es darauf ab, Gegenleistungen an ein breiteres System zu verlangen, als bei "Direct Contribution". Derzeit fehlt mir die Fantasie, um daraus ein konkretes Beispiel abzuleiten.
Open: Ein präziser formuliertes Signal, das die Offenheit der KI-Modelle selbst als Gegenseitigkeit zu interpretieren scheint. Meiner Meinung nach wäre dieses Signal erfüllt, wenn ein KI-Betreiber die Gewichtung, Trainingsverfahren, Code usw. seines KI-Modells veröffentlicht. Im Wesentlichen also ist die Aussage: "Sie dürfen meinen Datensatz nur verwenden, wenn Ihr Modell vollkommen Open Source ist".

CC schlägt vier Kombinationen von Signalen vor, die sie derzeit als sich gegenseitig ausschließend betrachten: Credit, Credit + Direct Contribution, Credit + Ecosystem Contribution und Credit + Open. (Ich bin mir nicht sicher, warum das Open-Signal die Verwendung von "Contribution" Signalen ausschließen sollte.)

Gemischte Signale

Beim Lesen von From Human Content to Machine Data, erhalte ich gemischte Signale über Zweck und Zielgruppe (und bitte um Verzeihung ob des schlechten Witzes). CC legt ihrer Argumentation die Aushöhlung des sozialen Übereinkommens zwischen AutorInnen und KI-Betreibern zugrunde. Das hat mich ursprünglich glauben lassen, dass ErstellerInnen von Blogs, Nachrichtenwebsites, Bildgalerien und ähnlichen Seiten Signale anwenden würden und dass solche AutorInnen anzeigen könnten, welche Form von Beitrag KI-Betreiber zu den Commons leisten sollen. Dass ich beispielsweise Signale an diesen Blog anhängen könnte, um anzuzeigen, dass ein LLM meine Seite referenzieren muss, wenn meine Inhalte in den Trainingsdaten verwendet wurden.

Später im Dokument (S. 29) stellt CC klar, dass Signale dazu gedacht sind, "an großen Sammlungen von Inhalten verwendet zu werden" (Betonung von mir hinzugefügt). Die Beschreibungen der Signale selbst legen nahe, dass Anbieter von großen Datensätzen, welche speziell für das KI-Training gedacht sind, die Zielgruppe darstellen.

Dadurch entsteht in meinen Augen eine Lücke in der von CC geforderten Wechselseitigkeit: KI-Betreiber geben etwas an die Anbieter großer Datensätze zurück, aber nicht unbedingt an die Ersteller der Inhalte, die solche Datensätze ausmachen. CC selbst bringt im Rahmen ihrer Argumentation die Beispiele von StackOverflow und Reddit, wobei die jeweiligen Nutzer heftigst dagegen protestierten, dass die von ihnen erstellten Inhalte als Trainingsdaten für KI verwendet werden. Mir ist nicht klar, wie die beschriebenen Signale solches Ungemach lindern sollen, wenn sie nur die Plattform als Ganzes ansprechen.

Optimistische Wechselseitigkeit

CC ist der Meinung, dass Wechselseitigkeit "ein entscheidender Bestandteil für breite Akzeptanz" ist (From Human Content to Machine Data, S.19). Ich teile diese Ansicht. Ich bin mir nicht sicher, ob große Akteure in der GenAI-Branche diese Ansicht ebenfalls teilen werden, nachdem ich mir folgende Fragen stelle:

Würden GenAI-Unternehmen bereits Trainingsdaten ihrer Modelle referenzieren, wenn dies einfach und ohne negative Folgen möglich wäre?
Gibt es eine zuverlässige Möglichkeit zu beweisen, dass ein Modell mit einem Datensatz trainiert wurde, welcher mit Signals behaftet ist?
Wurden aktuelle Modelle mit Material trainiert, das unter restriktiverem Urheberrecht als CC Signals steht?

CC scheint sich zudem gewisser technischer Hürden bewusst zu sein und hält fest, dass sie "Normen für das, was möglich ist, etablieren möchten, ohne das Perfekte zum Feind des Guten zu machen" (Hervorhebung aus dem Original, From Human Content to Machine Data, S.26). Im "Credit" Signal findet sich ein Schlupfloch, das sich vermutlich darauf bezieht. In der Beschreibung des Signals wird eine Referenz im Falle von RAG verlangt, "wo es technisch möglich ist, Inhalte mit bestimmten Ausgaben in Verbindung zu bringen" (ebenfalls S.26). Das ist eine ziemlich große Ausstiegsmöglichkeit.

Abschließende Gedanken

Am Ende bleibt mir unklar, wie CC Signals dazu beitragen wird, das soziale Übereinkommen zwischen AutorInnen und KI-Betreibern wiederherzustellen. Wechselseitigkeit mit Datensatzanbietern und Plattformen bedeutet nicht unbedingt Wechselseitigkeit mit einzelnen AutorInnen, welche Inhalte für diese Plattformen erstellen. Ich bin gespannt darauf, wie die Alpha-Version von Signals im November aussehen wird.

Nichtsdestotrotz gibt es kaum einen Zweifel an der Notwendigkeit einer Initiative wie Signals. Eine Woche nachdem CC mit Signals an die Öffentlichkeit gegangen ist, kündigte Cloudflare an, dass sie beginnen werden, AI-Webcrawler standardmäßig zu blockieren. Cloudflare erklärt den 1. Juli zum "Tag der Inhaltsunabhängigkeit". Während die Argumente von Cloudflare jenen von CC ähneln, scheint das Ziel ein rein monetäres Kompensationsmodell zu sein. Solcher Druck durch große Infrastrukturbetreiber könnte am Ende ausreichend sein, um große Akteure im GenAI-Bereich zu wechselseitigen Beiträgen zu den Commons zu bewegen.

Die Aktion von Cloudflare zeigt ein zunehmendes Bewusstsein dafür, dass KI die etablierte Übereinkunft zwischen AutorInnen und Web-Scrapern gestört hat. Ich bin der Meinung, CC hat richtig erkannt, dass den AutorInnen der Commons eine Möglichkeit gegeben werden muss, ein Gleichgewicht zwischen Produzent und Konsument herzustellen. Es ist noch zu früh, um zu sagen, ob Signals das erreichen kann. Der Versuch und das zugrundeliegende Motiv sind sicherlich zeitgemäß.

Auf der Suche nach der geschätzten Lesezeit, Teil 2: Implementierung und Überprüfung.

2025-06-11T00:00:00Z

Zusammenfassung

Ziel: Anzeige einer Lesezeitschätzungen in meinen Blogbeiträgen, deren Berechnung über die einfache Division der Wortanzahl durch eine pauschale Lesegeschwindigkeit hinausgeht.
Hypothese: Die Anpassung der Lesegeschwindigkeit basierend auf der durchschnittlichen Wortlänge führt zu genaueren Lesezeitschätzungen als die Verwendung einer pauschalen Lesegeschwindigkeit.
Überprüfung: Experimente mit einer JavaScript-Implementierung der angepassten Lesegeschwindigkeit und der pauschalen Lesegeschwindigkeit widerlegen die Hypothese.
Diskussion: Die Verwendung einer pauschalen Lesegeschwindigkeit in Wörtern pro Minute führt zu genaueren Schätzungen, die einfachere Berechnung ist daher zu bevorzugen.

Einführung & Wiederholung

Da ich mit dem Stand der Technik zur Schätzung von Lesezeiten online nicht zufrieden war, habe ich mich auf die Suche nach einem besseren Algorithmus gemacht. Basierend auf einer Literaturanalyse und einer Abwägung von Genauigkeit gegen Praktikabilität entschied ich mich für Formeln, welche die durchschnittliche Wortlänge als Indikator für die Textkomplexität berücksichtigen:

lesegeschwindigkeit_en = 238 * 4.6 / durchschnittliche_wortlaenge_des_textes

lesegeschwindigkeit_de = 185 * 5.97 / durchschnittliche_wortlaenge_des_textes

Beide Formeln basieren auf der Arbeit von Brysbaert (Brysbaert 2019). Eine viel zu detaillierte Erklärung, warum ich diese Formeln gewählt habe, steht im vorherigen Beitrag. Meine Erwartung war, dass die Verwendung einer derart angepassten Lesegeschwindigkeit genauere Schätzungen für die Lesezeit liefert.

In diesem Beitrag beschreibe ich meine Implementierung dieser Theorie und meine Erkenntnisse aus der kritischen Prüfung der Implementierung. Die Ergebnisse sind etwas ernüchternd.

Implementierung

Ich habe die Formeln in reinem JavaScript implementiert, weil das die Sprache des statischen Site-Generators ist, den ich verwende. Die Schätzung erfolgt zur Kompilierzeit und verwendet die kompilierten Blogbeiträge (d.h. HTML als String) als Eingabe.

Da die Eingabe HTML enthalten wird, benötigt die Implementierung zwei Teile: 1) Bereinigung der Eingabe und 2) Berechnung der Lesezeit.

Eingabebereinigung

Ich muss vermeiden, dass HTML-Markierungen die Wortzählung beeinflussen, daher filtere ich zuerst alle HTML-Tags aus dem Eingabestring. Außerdem nehme ich alle Satzzeichen aus dem Text. Ich verwendete dazu Textparsing basierend auf regulären Ausdrücken. Hier passiert also keine Magie.

/** Remove any HTML tags, linebreaks, punctuation or hyphens from a string
 * 
 * For the purpose of later calculating reading rate and reading time of
 * the input text.
 * 
 * Regex used for matching HTML tags is taken from the `insane` npm library:
 * https://github.com/bevacqua/insane/blob/master/parser.js#L7
 * 
 * @param {string} inputText text to sanitize
 * @returns {string} input text sans any HTML tags, linebreaks, punctuation or hyphens
 */
const sanitizeMarkup = (inputText) => {
    const regexStartTag = /<\s*([\w:-]+)((?:\s+[\w:-]+(?:\s*=\s*(?:(?:"[^"]*")|(?:'[^']*')|[^>\s]+))?)*)\s*(\/?)\s*>/gi;
    const regexEndTag = /<\s*\/\s*([\w:-]+)[^>]*>/gi;
    const regexNewLine = /[\n\r]/g;
    const regexPunctuation = /[\.|\?|;|,|:|!|"|'] /g;
    const regexHyphens = / - /g;

    return inputText.replaceAll(regexStartTag, '')
        .replaceAll(regexEndTag, '')
        .replaceAll(regexNewLine, ' ')
        .replaceAll(regexPunctuation, ' ')
        .replaceAll(regexHyphens, ' ');
}

Berechnung der Lesezeit

Unter der Annahme, wir haben einen bereinigten Eingabestring, können wir diesen unter Verwendung von Leerzeichen als Trennzeichen aufteilen und das resultierende Array für alle weiteren Berechnungen verwenden (Wortanzahl, durchschnittliche Wortlänge usw.). Die Funktion zur Berechnung der Lesezeitschätzung akzeptiert einen optionalen Parameter, der angibt, ob die angepasste oder die pauschale Lesegeschwindigkeit verwendet werden soll. Das ist vor allem dem Umstand geschuldet, dass ich beide Berechnungsarten in meinen Tests vergleichen will.

/** Takes a text and estimates the reading time based on average reading speed of the given language.
 * 
 * Reading speeds are taken from academic literature. You can find out more about choice of reading speeds
 * here: https://auferbauer.net/en/blog/2025-04-29-2025-04-29_reading_time_estimate_part_1/
 * 
 * You may opt to use an adjusted reading rate that takes average word length of the text vis-à-vis average
 * word length of that language into account. Refer to https://doi.org/10.1016/j.jml.2019.104047
 * 
 * @param {string} text the text for which you want to estimate reading time.
 * @param {string} language the language of the text (influences assumed reading speed in words per minute); takes either 'en' or 'de', defaults to 'en'.
 * @param {boolean} useAdjustedReadingRate whether you want to use an adjusted reading rate that takes average word length into account.
 * @returns {number} Estimated reading time of the text in seconds.
 */
const estimateTime = (text, language, useAdjustedReadingRate) => {
    if(!text || typeof text !== 'string') {
        throw new Error('Text was not provided as string.');
    }

    let languageReadingRate = 0;
    let languageAvgWordLength = 0;
    switch (language) {
        case 'de':
            languageReadingRate = 185;
            languageAvgWordLength = 5.97;
            break;
    
        case 'en':
        default:
            languageReadingRate = 238;
            languageAvgWordLength = 4.6;
            break;
    }

    const words = text.split(' ').filter((word) => {
        let trimmed = word.trim();
        return trimmed.length > 0;
    });
    
    const wordCount = words.length;
    const characterTotal = words.reduce(
        (characterTotal, word) => characterTotal + word.length,
        0
    );

    const documentAvgWordLength = characterTotal / wordCount;
    const adjustedReadingRate = languageReadingRate * languageAvgWordLength / documentAvgWordLength;
    const readingTimeSec = (wordCount / (useAdjustedReadingRate ? adjustedReadingRate : languageReadingRate))*60;

    if (process.env.NODE_ENV === 'development') {
        console.debug(`Total characters: ${characterTotal}`);
        console.debug(`Word count: ${wordCount}`);
        console.debug(`Average word length: ${documentAvgWordLength}`);
        console.debug(`Adjusted reading rate (${language}): ${adjustedReadingRate}`);
        console.debug(`Estimated reading time (${language}): ${readingTimeSec} sec`);
    }
    
    return readingTimeSec;
}

Überprüfung

Meine ursprüngliche Hypothese war, dass die eingangs beschriebenen Formeln eine präzisere Schätzung der Lesezeit liefern würde. Um diese Hypothese zu testen, benötige ich eine empirische Grundlage. Die Literatur bietet einige Textsammlungen, für welche die Lesezeit gemessen wurde. Aus der englischen Literatur habe ich die folgenden verwendet:

Frank et al. bieten Eyetracking-Daten und selbstbestimmte Lesezeiten (48 bzw. 117 Probanden) für einen Korpus englischer Sätze. Ich habe neun Sätze (insgesamt 70 Wörter) zufällig für die Auswertung ausgewählt.
Trauzettel-Klosinski und Dietz präsentieren eine einzelne Passage aus einem standardisierten internationalen Leseverständnistest (156 Wörter) einschließlich Lesezeitstatistiken für 436 Teilnehmer.
Siegelman et al. bieten Eyetracking-Daten aus einem internationalisierten Korpus von Textpassagen. Ich habe willkürlich Passage #9 (200 Wörter) ausgewählt und die durchschnittliche Lesezeit von 42 Teilnehmern aus den öffentlich verfügbaren Daten berechnet.

Folgendermaßen hat die von meinem Code berechnete geschätzte Lesezeit im Vergleich zu den empirischen Messungen abgeschnitten:

Korpus	Messung	Schätzung	Abweichung
1.	55.02s	51.57s	6%
2.	40.4s	37.04s	8%
3.	48.15s	53.49s	11%

Das ist ein anständiges Ergebnis. Die Abweichungen liegen innerhalb akzeptabler Grenzen (für meinen Zweck). Interessanterweise liefert die nicht angepasste, pauschale Lesegeschwindigkeit sogar noch bessere Ergebnisse:

Korpus	Messung	Schätzung	Abweichung
1.	55.02s	53.95s	2%
2.	40.4s	39.33s	3%
3.	48.15s	50.17s	4%

Das ist ein erfreuliches Ergebnis, insofern als es Funktionalität meines Codes bestätigt. Allerdings bedeutet es auch, dass mein Versuch, ein besseres Maß für die Lesgeschwindigkeit zu finden, vergeblich war.

Wie sieht es mit Lesezeitschätzungen für Deutsch aus? Es war deutlich schwieriger, Texte zu finden, die ich als empirische Grundlage für Deutsch verwenden kann. Es gibt nur zwei Quellen, für die sowohl der Text als auch die Messungen der Lesgeschwindigkeit verfügbar sind:

Das Potsdam Text Corpus (PoTeC) enthält Eyetracking-Daten für zwölf wissenschaftliche Texte auf Deutsch (Jakobi et al., 2024).
Der internationale Korpus von Siegelman et al., den ich bereits für die Überprüfung auf Englisch verwendet habe, bietet auch deutsche Versionen.

Ich konnte PoTeC nicht als empirische Grundlage in Betracht ziehen, da die von mir aus den Rohdaten berechneten Leseraten deutlich unter jenen lagen, die in der übrigen Literatur berichtet wurden (40 Wörter pro Minuten für manche Teilnehmer). Das ist vermutlich darauf zurückzuführen, dass ich falsch mit den Daten umgegangen bin. Unabhängig von der Ursache liegen die Werte so weit außerhalb der erwarteten Parameter, dass ich mich entschieden habe, PoTeC nicht zu verwenden.

Damit bleibt mir der Text von Siegelman et al. als einziger Datenpunkt für eine Überprüfung:

Messung	Schätzung	Abweichung
51.78s	60.46s	16%

Nicht schlecht, nicht großartig. Allerdings: wie auch schon im Englischen lieferte die Verwendung einer pauschalen Leserate bessere Ergebnisse, im diesem Fall sogar noch eindeutiger:

Messung	Schätzung	Abweichung
51.78s	54.81s	5%

Diskussion

Zu Beginn meiner Suche nach einer besseren Lesezeitschätzung stand die Hypothese, dass Berechnungen aufgrund einer pauschalen Lesegeschwindigkeit zu ungenauen Ergebnissen führen würden und dass es eine angepasste Lesegeschwindigkeit braucht, welche die Textkomplexität modeliert.

Überraschenderweise war dies nicht der Fall. Für alle Textkorpora, für die Lesezeitmessungen verfügbar sind, liefern Berechnungen mit einer pauschalen Lesegeschwindigkeit exaktere Ergebnisse, als unter der Verwendung der angepassten Lesegeschwindigkeit. Während die Schätzungen basierend auf der angepassten Lesegeschwindigkeit um 6%-16% von den empirischen Messungen abweichen, weichen die Schätzungen aufgrund pauschaler Lesegeschwindigkeit nur um 2%-5% ab.

Ich sehe keine Notwendigkeit, andere Ansätze zu untersuchen oder die Angelegenheit noch weiter unnötig kompliziert zu machen. Die pauschale Lesegeschwindigkeit basierend auf Wörtern pro Minute ist das robustere Werkzeug zur Schätzung der Lesezeit und funktioniert mehr als zufriedenstellend.

Der Code, den ich verwendet habe, um meine Hypothese zu überprüfen, ist daher nicht besser oder schlechter als der meiste andere Code zur Schätzung der Lesezeit, den man im Internet findet. Zum Zeitpunkt der Veröffentlichung dieses Beitrages verwende ich meinen Code, um die Lesezeiten auf diesem Blog zu schätzen. Damit kommt meine Suche nach der Schätzung der Lesezeit zu einem Ende. Letztendlich trifft das KISS-Prinzip wieder einmal zu.

Wir lesen uns im nächsten Beitrag!

Auf der Suche nach der geschätzten Lesezeit, Teil 1: Die richtige Formel.

2025-04-29T00:00:00Z

Auf meinem Blog möchte ich eine Lesezeit-Schätzung zu jedem Artikel hinzufügen.

Das Problem scheint auf den ersten Blick gelöst zu sein: es gibt genug How-To-Artikel und Tutorials dafür. Allerdings gehen die meisten Beiträge zu dem Thema von einer universellen und fixen Lesegeschwindigkeit in Wörtern pro Minute aus. Dann wird einfach die Gesamtzahl der Wörter im Artikel durch diese Lesegeschwindigkeit geteilt und das war es dann.

Das Problem ist also nicht wirklich gelöst. Zumindest bin ich mit diesem Ansatz nicht zufrieden. Er scheint mir zu simpel. Hat die Beschaffenheit des Textes keine Auswirkung auf die Lesegeschwindigkeit? Sicherlich hat ein technischer Artikel eine andere Lesegeschwindigkeit als ein Boulevard-Artikel. Und gilt diese magische universelle Lesegeschwindigkeit sowohl für Deutsch als auch für Englisch?

Faktoren, welche die Lesegeschwindigkeit beeinflussen

Wie sich herausstellt, gibt es viele Faktoren, welche die Lesegeschwindigkeit beeinflussen. Diese lassen sich grob in drei Kategorien einteilen, je nachdem, wo sie ihren Ursprung haben:

Es gibt Komplexität, die dem Text selbst innewohnt. Je höher diese Komplexität ist, desto langsamer wird die Lesegeschwindigkeit sein. Der Anteil langer Wörter (Miller and Coleman 1971; Radner et al. 2002) sowie die Satzstruktur (Gibson 2001; Pauly and Nottbusch 2020) korrelieren mit dieser Komplexität.
Manche Faktoren, welche die Lesegeschwindigkeit beeinflussen, gehen vom Leser selbst aus. Das sind z.B. Lesefertigkeit (Radner et al. 2002; Trauzettel-Klosinski and Dietz 2012) und Alter (Trauzettel-Klosinski and Dietz 2012; Brysbaert, Keuleers, and Mandera 2019).
Einige Faktoren hängen davon ab, wie der Text dargestellt wird und in welchem Umfeld der Inhalt konsumiert wird. Kontrast (Legge et al. 1990), Schriftgröße (Bailey, Clear, and Berman 1993) und Schriftart (Mansfield, Legge, and Bane 1996) gehören dieser Kategorie an.

Sowohl die zweite als auch die dritte Kategorie sind für mich praktisch nicht zu bestimmen, weil ich keine Gewissheit habe, wie mein Blog dargestellt wird oder wer ihn liest. Daher bleibt mir nur die Komplexität als Einflussfaktor, den ich a priori bestimmen kann.

Textkomplexität als Bestimmungsfaktor der Lesegeschwindigkeit

Weil die Textkomplexität der einzige bestimmbare Faktor für eine Schätzung der Lesegeschwindigkeit ist, muss ich ihren Einfluss modellieren können. Es gibt mehrere Theorien dazu, wie man Textkomplexität modellieren kann. Zwei populäre Beispiele aus der Literatur sind:

Dependency local theory (DLT) basiert auf der Hypothese, dass während dem Lesen kognitive Ressourcen für 1) die Speicherung der bisherigen Satzstruktur und 2) die Integration des aktuell gelesenen Wortes in diese Struktur aufgewendet werden. Die Hypothese besagt weiter, dass die Komplexität von der Entfernung der beiden zu integrierenden Elemente abhängt (Gibson 2001). Vereinfacht gesagt: Je länger und verschachtelter ein Satz ist, desto höher ist seine Komplexität.
Surprisal modelliert Komplexität als ein informationstheoretisches Konzept, welches die Erwartbarkeit jedes Wortes im gegebenen Kontext widerspiegelt (Henderson et al. 2016). Das bedeutet: Je unwahrscheinlicher ein Wort in einem bestimmten Kontext erscheint, desto höher ist seine Komplexität.

Eine vollständige Theorie der Komplexität wird wahrscheinlich beide dieser Maßnahmen integrieren müssen, da es Hinweise darauf gibt, dass DLT und Surprisal keine Korrelation aufweisen (Demberg and Keller 2008).

Obwohl diese Theorien von einem akademischen Standpunkt aus interessant sind, scheint ihre Anwendung für meinen Zweck wenig praktikabel. Der erwartete Zugewinn an Genauigkeit beim Schätzen der Lesegeschwindigkeit wird wahrscheinlich den Implementierungsaufwand nicht rechtfertigen. Ich suche letzten Endes nach einer Möglichkeit, die Lesezeiten für einen Blog zu schätzen, dessen Leserschaft optimistisch betrachtet aus fünf Leuten und einem LLM besteht.

Praktischer Ansatz: Lesbarkeitsbewertungen

Die direkte Anwendung der akademischen Theorien zur Textkomplexität erscheint mir für meinen Zweck übertrieben. Es gibt allerdings eine verwandte Art der Modellierung, die praktischer veranlagt ist: Lesbarkeitsbewertungen.

Der bekannteste Lesbarkeitswert ist der Flesch Reading-Ease Index, soweit ich das nach meiner Internet-Recherche beurteilen kann. Weitere Beispiele sind der SMOG-Grad oder der Coleman-Liau-Index. All diese Bewertungen sind auf die englische Sprache abgestimmt. Im Gegensatz dazu sind die Wiener Sachtextformel und der Lesbarkeitsindex (LIX) gut auf Deutsch anwendbar (https://barrierefreies.design/werkzeuge/lesbarkeit-analysieren).

Die meisten Lesbarkeitsbewertungen basieren auf der Berechnung der Länge von Sätzen und Wörtern, definiert durch die Anzahl der Silben, die sie enthalten. Daraus ergibt sich auch die Verbindung von Lesbarkeitsbewertungen zu den rein akademischen Theorien über Textkomplexität. Leider ist das auch ihr Nachteil in Bezug auf meine Problemstellung.

Die Berechnung der Satzlänge an und für sich ist bereits nicht trivial. Denken Sie an Satzzeichen, die mitten im Satz stehen - wie z.B. in dem Satz, den Sie gerade lesen. Eine robuste Berechnung der Silbenanzahl scheint ebenfalls außer Reichweite. Es gibt vorschläge zur Berechnung, die allerdings von den Autoren selbst als ungenau bezeichnet werden (siehe dieses Beispiel, dieses Beispiel oder auch dieses hier).

Geht es noch einfacher?

Lesbarkeitsbewertungen sind einfacher zu implementieren als die rein akademischen Theorien zur Textkomplexität. Dennoch stützen sich die meisten immer noch auf Metriken, die ich mit vertretbarem Aufwand nicht zuverlässig berechnen kann: Textlänge und Silbenanzahl.

Muss ich mich also am Ende doch auf Wörter pro Minute verlassen? Die Antwort ist: "Nein, muss ich nicht." Denn zum Glück hat jemand eine einfache Formel entwickelt, welche trotzdem auch die Komplexität berücksichtigt.

2019 hat Brysbaert eine Meta-Überprüfung der Literatur zu Lesegeschwindigkeiten durchgeführt (Brysbaert 2019). Auch er hat Wörter pro Minute als Metrik für Lesegeschwindigkeiten gewählt (aufgrund deren hoher Akzeptanz). Er schlägt jedoch eine korrigierte Formel zur Berechnung der erwarteten Lesegeschwindigkeit vor: 238 * 4.6 / durchschnittliche Wortlänge. 238 ist in diesem Fall der beste verfügbare Schätzwert für die Lesegeschwindigkeit in Wörtern pro Minute. 4.6 ist die durchschnittliche Wortlänge in Sachtexten. Die Formel verwendet also Wörter pro Minute als Basis, berücksichtigt aber die Wortlänge zur Abbildung der Komplexität.

Das scheint ein vielversprechender Ansatz zu sein. Eine pragmatische Formel ohne fehleranfällige Berechnung der Satzlänge oder Silbenanzahl. Auch wenn ein gewisses Risiko der übermäßigen Vereinfachung besteht, korreliert die Wortlänge gut mit dem Schwierigkeitsgrad des Textes (Miller and Coleman 1971). Dies wird auch von Radner et al. bestätigt, die feststellten, dass längere Wörter mit einer Verringerung der Lesegeschwindigkeit korrelieren (Radner et al. 2002). Daher werde ich die Wortlänge vorläufig als vernünftigen Indikator für die Komplexität betrachten.

Anpassungen für Deutsch

Da ich auch auf Deutsch schreibe, muss ich die Formel von Brysbaert noch an die durchschnittliche deutsche Lesegeschwindigkeit und Wortlänge anpassen. Leider gibt es keine Meta-Überprüfung für deutsche Lesegeschwindigkeiten, die diese Werte leicht zugänglich macht.

Duden gibt eine durchschnittliche Länge von 5.97 Buchstaben pro Wort an. Wenn die oberste Instanz für den deutschen Sprachkorpus das so sagt, darf man es schonmal einfach hinnehmen. Wenn es um die durchschnittliche Lesegeschwindigkeit geht, wird die Sache etwas weniger eindeutig.

Radner et al. berichten von einer Lesegeschwindigkeit von 209 Wörtern pro Minute für kurze Sätze und 170 Wörtern pro Minute für lange Sätze (Radner et al. 2002). Trauzettel-Klosinski und Dietz haben 179 Wörter pro Minute in einem internationalen standardisierten Test gemessen (Trauzettel-Klosinski and Dietz 2012). Pauly und Nottbusch berichten von einer durchschnittlichen Lesegeschwindigkeit zwischen 184 und 210 Wörtern pro Minute, je nach syntaktischer Satzstruktur (Pauly and Nottbusch 2020).

Aufgrund der referenzierten Literatur werde ich eine durchschnittliche Lesegeschwindigkeit von 185 Wörtern pro Minute für deutsche Leser annehmen. Die Überlegung dahinter ist, dass ich über technische Themen schreiben werde; daher ein Wert aus dem unteren Bereich. Allerdings bemühe ich mich normalerweise, die Komplexität meiner Texte zu verringern. Daher habe ich nicht die absolut niedrigste beobachtete Lesegeschwindigkeit gewählt. Ich werde diesen Wert bei Bedarf anpassen, sobald ich ein paar empirische Daten habe.

Das Ergebnis

Zusammengefasst lauten die Formeln, die ich vorläufig zur Berechnung der Lesegeschwindigkeit verwenden werde:

lesegeschwindigkeit_en = 238 * 4.6 / [durchschnittliche_wortlänge_des_beitrags]

und

lesegeschwindigkeit_de = 185 * 5.97 / [durchschnittliche_wortlänge_des_beitrags]

für Englisch bzw. Deutsch. Unter Berücksichtigung aller mir bekannten Literatur scheint dies der beste Kompromiss zwischen Pragmatismus und Berücksichtigung von Textkomplexität zu sein. Gemäß der Literatur (Brysbaert 2019; Miller and Coleman 1971; Radner et al. 2002) erwarte ich, dass die Wortlänge eine vernünftige Annäherung an die Gesamtkomplexität darstellt.

Schließlich lautet die Formel zur Schätzung der Lesezeit eines bestimmten Blogbeitrags in Minuten:

lesezeit_minuten = [wörter_im_beitrag] / lesegeschwindigkeit

Einschränkungen

Ich habe mir einige Freiheiten genommen, was die Zahlen aus der Literatur betrifft. Ich habe die Schriftsetzung, mit der die durchschnittlichen Lesegeschwindigkeiten ermittelt wurden, völlig außer Acht gelassen. Viele Faktoren abseits der Textkomplexität, die ich selbst (möglicherweise suboptimal) gewählt habe, könnten die durchschnittliche Lesegeschwindigkeit auf meiner Website beeinflussen: Kontrast, Schriftart, Schriftgröße, Zeilenlänge usw.

Natürlich ist jede Herleitung von Formeln in meinem Beitrag als hypothetisch zu betrachten. Es fehlt bisher jegliche kritische Prüfung. Eine solche kritische Prüfung würde den Rahmen eines einzelnen Blogbeitrags überschreiten.

Was nun?

Im nächsten Beitrag werde ich eine Implementierung der vorgeschlagenen Formel beschreiben. Ich werde JavaScript verwenden, um die Lesezeit von Blogbeiträgen im Markdown- bzw. HTML-Format zu schätzen. Sobald das implementiert ist, werde ich einige empirische Tests der berechneten Lesezeiten durchführen. Bleiben Sie dran!