LexRank versus TextRank: Zwei Algorithmen, fast gleichzeitig, fast gleich

Zwei Papers, ein Sommer

Im Juli 2004 reicht das Team um Rada Mihalcea und Paul Tarau ein Paper bei der Conference on Empirical Methods in Natural Language Processing (EMNLP) in Barcelona ein. Titel: TextRank: Bringing Order into Texts. Kernidee: PageRank, der Algorithmus, mit dem Brin und Page 1998 Google starteten, lässt sich auf Sätze in einem Text anwenden. Statt Webseiten als Knoten und Hyperlinks als Kanten benutzt man Sätze als Knoten und Wort-Ähnlichkeiten als Kanten.

Im gleichen Sommer reichen Güneş Erkan und Dragomir Radev von der University of Michigan ein anderes Paper beim Journal of Artificial Intelligence Research (JAIR) ein. Titel: LexRank: Graph-based Lexical Centrality as Salience in Text Summarization. Kernidee: PageRank, der Algorithmus, mit dem Brin und Page 1998 Google starteten, lässt sich auf Sätze in einem Text anwenden.

Die beiden Teams hatten unabhängig voneinander dieselbe Grundidee. In der Wissenschaftsgeschichte nennt man das Multiple Independent Discovery. Es ist nicht selten, oft passiert es, wenn ein Forschungsfeld reif für einen bestimmten Schritt ist. 2004 war das Feld der Summarization reif: PageRank war 6 Jahre alt, gut verstanden und in der Anwendung bewährt. Sumy gab es noch nicht, Information Retrieval kämpfte mit klassischen TF-IDF-Verfahren. Der Sprung zur Graph-Repräsentation lag in der Luft.

Gemeinsame Grundlage: PageRank-Iteration

Beide Algorithmen nutzen das gleiche mathematische Framework. Sätze werden Knoten in einem Graph, Ähnlichkeiten werden Kanten. Die PageRank-Iteration wird auf den Graph angewendet:

Score(V_i) = (1 - d) + d * Summe(w_ji / Summe(w_jk) * Score(V_j))

Damping-Faktor d = 0.85 (von Brin und Page übernommen), Iteration bis zur Konvergenz (typisch 30-50 Schritte). Nach der Konvergenz hat jeder Satz einen Score, die Top-N werden ausgewählt.

Bis zu diesem Punkt sind TextRank und LexRank identisch. Der Unterschied liegt in zwei Detailfragen: Wie wird die Similarity berechnet, und wie werden Kanten in den Graph aufgenommen?

Unterschied 1: Die Similarity-Formel

TextRank nutzt eine eigene Formel, die Mihalcea und Tarau im Paper definieren:

sim_TR(S_i, S_j) = |gemeinsame Wörter| / (log|S_i| + log|S_j|)

Diese Formel zählt einfach die gemeinsamen Wörter zwischen zwei Sätzen (nach Stopwort-Filter) und normalisiert mit dem Logarithmus der Satzlängen. Kein TF-IDF, kein Korpus-Wissen, kein Vokabular nötig. Das macht TextRank besonders attraktiv für Single-Document-Anwendungen.

LexRank nutzt Cosine-Similarity über TF-IDF-Vektoren:

sim_LR(S_i, S_j) = (V_i mal V_j) / (|V_i| mal |V_j|)

wobei V_i und V_j TF-IDF-gewichtete Vektoren sind. TF (Termfrequenz) ist trivial zu berechnen, IDF (inverse Dokumentfrequenz) braucht aber Wissen über andere Dokumente. Bei Multi-Document-Summarization, wofür LexRank eigentlich entworfen wurde, ist das selbstverständlich. Bei Single-Document muss man das IDF aus dem einen Dokument hochrechnen, was die Aussagekraft schwächt.

Unterschied 2: Threshold-basierte vs. gewichtete Kanten

TextRank baut den Graph dicht: Jedes Satzpaar bekommt eine Kante, deren Gewicht der Similarity-Wert ist. Selbst sehr schwache Ähnlichkeiten werden als Kanten beibehalten und fließen mit ihrem Gewicht in die PageRank-Iteration ein.

LexRank definiert einen Schwellenwert (im Paper standardmäßig 0.1). Liegt die Cosine-Similarity zwischen zwei Sätzen darunter, wird keine Kante gezogen. Liegt sie darüber, wird eine Kante mit Gewicht 1 oder dem Similarity-Wert gezogen (das Paper diskutiert beide Varianten). Diese Threshold-Methode macht den Graph sparser, was zwei Effekte hat: Erstens läuft die PageRank-Iteration schneller, weil weniger Kanten zu verarbeiten sind. Zweitens werden schwache, aber statistisch signifikante Verbindungen zwischen Sätzen ignoriert.

Performance auf DUC-Daten

Die Document Understanding Conference von NIST bot in den frühen 2000ern Standard-Datasets, an denen Summarization-Verfahren verglichen wurden. Beide Papers (TextRank-EMNLP-2004, LexRank-JAIR-22) zeigen Ergebnisse auf DUC-2002 oder DUC-2003.

Auf DUC-2003 erreicht TextRank ROUGE-1-Werte um 0.36, LexRank erreicht 0.35 bis 0.38, je nach Threshold. Der Unterschied liegt im statistischen Rauschen. Beide Algorithmen sind den damaligen extraktiven Baselines (Luhn, Edmundson) deutlich überlegen.

Spätere Vergleichsstudien (etwa Tixier et al, EMNLP 2016) zeigten: Bei kurzen Texten unter 30 Sätzen unterscheiden sich TextRank und LexRank praktisch nicht. Bei längeren Texten oder Multi-Document-Settings zeigt LexRank durch die Threshold-Filterung leicht bessere Cluster-Identifikation, TextRank durch die volle Graph-Information eine glattere Auswahl.

Welcher Algorithmus heute?

Wer 2026 entscheiden muss, sollte sich drei Fragen stellen.

1. Single-Document oder Multi-Document? Bei einem einzelnen Text (klassischer Artikel, Studie, Blog-Post) ist TextRank natürlicher. Multi-Document (mehrere Quellen zu einem Thema) braucht ein Korpus-Konzept, hier ist LexRank im Vorteil.

2. Korpus verfügbar? Wenn ja, kann LexRank seine TF-IDF-Stärke ausspielen. Wenn nein (Single-Page-Browser-Tool), ist TextRank pragmatischer.

3. Implementierungsaufwand? TextRank ist in etwa 200 Zeilen Code zu implementieren, LexRank braucht 300 bis 400 Zeilen wegen der TF-IDF-Berechnung. Für ein Browser-Tool wie text-zusammenfassen.de ist TextRank die offensichtliche Wahl.

Fußnote: Sumy und gensim

Wer keinen eigenen Algorithmus implementieren will, findet beide in Open-Source-Bibliotheken. Die Python-Bibliothek sumy (Miso Belica seit 2013) bietet sowohl TextRank als auch LexRank, plus Luhn und Edmundson. Die Bibliothek gensim (Radim Rehurek seit 2010) hatte bis Version 4.0 eine eigene TextRank-Implementierung, ab 4.0 wurde sie entfernt, weil das Maintenance-Team sich auf Topic-Modeling konzentrierte. In JavaScript gibt es node-summarizer und text-rank-js, beide nutzen TextRank.

Wo die Algorithmen in der Praxis eingesetzt werden

TextRank ist 2026 der dominante Algorithmus in zwei Bereichen. Erstens in Browser-basierten Tools wie text-zusammenfassen.de, weil die Mihalcea-Tarau-Similarity ohne externe Daten auskommt. Zweitens in Open-Source-Bibliotheken für rapide Prototyping, wo Forscher in Python schnell eine Baseline aufsetzen wollen. Die Mehrheit der akademischen Papers, die extraktive Verfahren als Baseline verwenden, nutzt TextRank über sumy oder gensim.

LexRank findet sich vor allem in zwei anderen Kontexten. Erstens in akademischen Multi-Document-Systemen, wo die TF-IDF-Komponente ihre Stärke ausspielt. Das DUC-2004-Multi-Document-Dataset wird in den meisten Papers mit LexRank-Baseline berichtet. Zweitens in spezialisierten Recherche-Tools für Wissenschaftler, etwa in Bibliographie-Management-Systemen, die mehrere Paper zu einem Thema durchgehen und eine kombinierte Zusammenfassung erstellen.

In kommerziellen Produkten dominieren mittlerweile abstraktive Verfahren auf Basis von GPT, Claude oder Gemini. Aber unter der Haube vieler “AI-powered” Summarization-Features arbeiten oft auch noch extraktive Vorfilter. Die Architektur ist dann: TextRank wählt 30 Prozent der relevantesten Sätze, GPT formuliert daraus eine Zusammenfassung. Vorteil: 70 Prozent API-Kosten gespart, weniger Halluzinationen.

Konkrete Implementierungs-Hürden im Vergleich

Wer beide Algorithmen selbst implementiert, merkt schnell, wo die Unterschiede liegen.

TextRank-Implementierung in JavaScript braucht etwa 180 bis 220 Zeilen Code. Die Phasen sind: Tokenisierung (40 Zeilen), Stopwort-Filterung (10 Zeilen), Similarity-Matrix-Aufbau (50 Zeilen), PageRank-Iteration (60 Zeilen), Top-N-Auswahl mit Original-Reihenfolge (30 Zeilen). Externe Dependencies: nur eine Stopwortliste, die als statische Datei eingebunden wird. Bundle-Größe-Einfluss: unter 10 KB.

LexRank-Implementierung in JavaScript braucht etwa 280 bis 350 Zeilen. Die zusätzlichen Phasen sind: TF-IDF-Berechnung über das Korpus (80 Zeilen), Vektor-Konstruktion (40 Zeilen), Threshold-Logik im Graph-Aufbau (20 Zeilen). Externe Dependencies: eine TF-IDF-Bibliothek wird oft eingebunden, was den Bundle um 30 bis 50 KB vergrößert.

Für Server-basierte Anwendungen ist der Unterschied vernachlässigbar. Für Browser-Tools, wo jedes Kilobyte zählt, ist TextRank die offensichtlich pragmatischere Wahl.

Mihalcea und Radev: Die Forscher hinter den Algorithmen

Rada Mihalcea ist heute Professorin an der University of Michigan, also genau an der Universität, an der LexRank entwickelt wurde. Sie wechselte 2008 von der University of North Texas nach Michigan und arbeitet seitdem mit Dragomir Radev, dem Erfinder von LexRank, im selben Department. Beide haben TextRank und LexRank nie als konkurrierende Systeme verstanden, sondern als parallele Beiträge. In gemeinsamen Vorträgen und Tutorials erklären sie die beiden Algorithmen heute oft zusammen.

Paul Tarau, Mihalceas Mit-Autor des TextRank-Papers, ist Professor für Computer Science an der University of North Texas mit Schwerpunkt Logikprogrammierung. Er hat nach 2004 vergleichsweise wenig zu Summarization veröffentlicht, war aber an der konzeptionellen Sauberkeit des Original-Papers entscheidend beteiligt.

Güneş Erkan, LexRank-Erstautor, hat nach seiner Promotion bei Radev die akademische Welt verlassen und arbeitet seit 2010 in der Industrie, zuletzt bei Microsoft Research. Dragomir Radev ist 2024 leider verstorben, was die NLP-Community schwer getroffen hat. Sein Lebenswerk umfasst weit mehr als LexRank, aber das JAIR-22-Paper ist eines seiner meistzitierten.

Was sich seit 2004 bei Bewertung und Daten geändert hat

Als TextRank und LexRank 2004 veröffentlicht wurden, war ROUGE die einzige ernsthafte Bewertungs-Metrik und DUC die einzige große Test-Sammlung. Heute gibt es eine Vielzahl von Datasets (CNN/DailyMail, XSum, PubMed, arXiv, BillSum, WikiHow) und Metriken (ROUGE, BERTScore, BLEURT, MoverScore). Die Algorithmen wurden auf diesen neuen Daten getestet, mit gemischten Ergebnissen.

Auf CNN/DailyMail-Daten erreicht TextRank ROUGE-1 um 0.30, auf XSum (kürzere Zusammenfassungen) nur 0.16 bis 0.20. LexRank performt ähnlich. Beide werden von neueren Modellen wie BART und PEGASUS deutlich übertroffen (ROUGE-1 0.40 bis 0.45 auf denselben Daten). Das heißt aber nicht, dass extraktive Verfahren obsolet sind. Auf nicht-trainings-ähnlichen Daten (rechtliche Texte, technische Dokumentation, deutsche wissenschaftliche Texte) liefern sie oft zuverlässigere Ergebnisse als die ML-Modelle, weil sie nicht über das Trainings-Set hinaus generalisieren müssen.

Andere graphbasierte Verfahren nach TextRank/LexRank

Nach 2004 entstanden mehrere Varianten und Erweiterungen, die die Grundidee aufnahmen und ausbauten. SumBasic (Nenkova und Vanderwende, 2005) verzichtet auf Graphen und nutzt Wahrscheinlichkeits-Maximierung, ist aber konzeptionell ein Nachfolger im selben extraktiven Lager. KLSum (Haghighi und Vanderwende, 2009) nutzt Kullback-Leibler-Divergenz zur Auswahl, ebenfalls eine extraktive Variante. ILP-basierte Verfahren (Berg-Kirkpatrick et al, 2011) formulieren die Satz-Auswahl als Integer Linear Programming-Problem, was theoretisch optimal ist, aber rechenintensiv.

Trotz dieser Alternativen sind TextRank und LexRank die meistgenutzten extraktiven Verfahren geblieben. Der Grund ist Einfachheit: Beide passen in 300 Zeilen Code, brauchen keine externen Bibliotheken (TextRank) oder nur minimal (LexRank), und liefern reproduzierbare Ergebnisse ohne ML-Black-Box. In einer Welt, in der “AI Explainability” zunehmend gefordert wird, ist diese Transparenz ein wichtiges Argument.

Was hängenbleibt

TextRank und LexRank wurden 2004 unabhängig veröffentlicht, beide adaptieren PageRank auf Sätze. Unterschiede liegen in der Similarity-Berechnung (Mihalcea-Tarau vs. Cosine TF-IDF) und der Kantenstruktur (volle Gewichte vs. Threshold-Filter). In der Praxis ist TextRank populärer, weil einfacher und korpus-frei. LexRank glänzt bei Multi-Document. Auf typischen Web-Texten sind die Ergebnisse statistisch ähnlich.