Bot-Erkennung bei X: BotMaker, Scarecrow und BDSM im Inneren

Veröffentlicht

16. August 2026

Autor

Faizan Nadeem

Die Grundlagen

Was diese Pipeline tatsächlich abdeckt

Xs Repository x-algorithm teilt sich in zwei Pfade, die fast vollständig unabhängig voneinander laufen. Der Request Path verarbeitet in Echtzeit eine einzelne Feed-Anfrage: Kandidaten abrufen, ranken, filtern, eine Timeline zurückgeben. Der Labeling Path läuft kontinuierlich im Hintergrund, vollständig getrennt von der Anfrage eines einzelnen Nutzers — Accounts und Beiträge werden Tag und Nacht gescort und gelabelt, unabhängig davon, wer gerade scrollt. Bot- und unauthentische-Account-Erkennung leben fast vollständig im Labeling Path, und das ist die erste wichtige Erkenntnis: Das System, das entscheidet, dass ein Account wie ein Bot aussieht, wird nicht dadurch ausgelöst, dass du deine Timeline lädst. Es lief bereits Tage oder Wochen früher und liest einfach eine gespeicherte Antwort zurück, wenn dein Feed zusammengestellt wird.

Innerhalb des Labeling Path stammt das Account-Scoring konkret aus drei Modellen, die auf völlig unterschiedlichen Signalen arbeiten: agatha liest, wie andere Menschen auf die Beiträge eines Accounts reagieren, bdsm liest das eigene Verhalten des Accounts über die Zeit, und user-cred-v2 liest die Position des Accounts im Follow- und Engagement-Graphen. Keines davon allein ist „der Bot-Detektor“. Zusammen speisen sie eine Rule Engine, die entscheidet, welches Label ein Account oder Beitrag gegebenenfalls erhält.

Warum diese Architektur ein wichtiges Problem richtig lösen muss

Die Einsätze wirken in beide Richtungen. Ein False Positive bringt einen echten Account zum Schweigen; ein False Negative erlaubt es einem koordinierten Netzwerk, zu manipulieren, was Hunderte Millionen Menschen sehen. Keiner dieser Fehlermodi ist in dieser Größenordnung akzeptabel — genau deshalb trägt kein einzelnes Modell die gesamte Entscheidung.
Das ist jetzt das am besten inspizierbare System seiner Art in der Branche. Meta, TikTok und YouTube haben Papers und hochrangige Beschreibungen ihrer Ranking-Systeme veröffentlicht; keines davon hat eine funktionierende, baubare Codebasis auf GitHub gestellt, die sowohl Ranking als auch Sicherheit abdeckt. Das verändert, was „Vertraut uns“ für eine Plattform dieser Größe bedeutet.
Die Designentscheidungen hier sind eine wirklich nützliche Referenz, unabhängig von X im Speziellen, für alle, die Trust-&-Safety-Systeme bauen: wie man mehrere schwache Signale kombiniert, wo man die Grenze zwischen Echtzeit- und Hintergrundverarbeitung zieht und wie viel der eigenen Erkennungslogik man öffentlich machen sollte, ohne Angreifern eine Anleitung zu geben.

Die vollständige Architektur

LABELING PATH (continuous, background)
Content Understanding (agatha, bdsm, user-cred-v2, grox, ...)
      │
      ▼
Labeling Rules (scarecrow + botmaker, abuse-enforcement-service)
      │
      ▼
Storage
      │
      ▼
REQUEST PATH (per feed request)
Candidate Sources → Scoring/Ranking → Visibility Filtering (reads Storage) → Post-Selection Filters
      │
      ▼
Ranked For You Timeline

Das Leitprinzip, in Xs eigenen Designnotizen ausdrücklich formuliert: Ranking und Sichtbarkeit sind getrennte Systeme, die getrennte Eingaben lesen und getrennte Entscheidungen treffen. Ranking entscheidet über die Reihenfolge, in der Beiträge erscheinen; Visibility Filtering entscheidet, ob ein Beitrag überhaupt erscheinen kann. Beides zu vermischen — also einen Relevanzscore zugleich als Sicherheitsscore zu verwenden — ist genau der Fehlmodus, den diese Architektur vermeiden soll.

Die Kernschichten erklärt

1. `agatha` — Einen Account danach bewerten, wie andere reagieren

Was es ist: Ein Offline-Batch-Prozess, der einen Account danach labelt, wie andere Menschen auf seine Beiträge reagieren — Blocks, Reports und Spam-Reports, gemessen relativ zu Favorites — plus abgeleitete Labels für Spam-Suspendierungsrisiko und Adult Content.

Warum es wichtig ist: Das ist ein reaktionsbasiertes Signal — es betrachtet, wie echte Menschen reagieren, die mit den Inhalten eines Accounts in Kontakt kommen, nicht, was der Account selbst tut. Ein Beitrag, der zuverlässig Blocks und Reports relativ zu Favorites auslöst, ist ein starkes, von Menschen stammendes Signal, unabhängig von allem, was das Modell allein aus dem Inhalt ableiten könnte.

Production-Tipp: Reaktionsbasierte Signale brauchen echte Reichweite und echte menschliche Reaktionen, bevor ein Muster entsteht, was bedeutet, dass agatha allein einen schlechten Account nicht schon beim ersten Beitrag erwischen kann.

2. `bdsm` — Einen Account nach seinem eigenen Verhalten über die Zeit bewerten

Was es ist: Ein Modell, das die Folge von Aktionen liest, die ein Account über die Zeit ausführt — nicht irgendeine einzelne Aktion isoliert — um Anzeichen unauthentischen oder missbräuchlichen Verhaltens zu erkennen.

Warum es wichtig ist: Das erfasst genau das, was reaktions- und inhaltsbasierte Signale strukturell nicht erfassen können. Ein einzelner Beitrag kann, für sich genommen, völlig gewöhnlich wirken. Eine Sequenz von Aktionen — Posting-Kadenz, Zeitmuster, der Rhythmus von Follows und Engagements — kann überhaupt nicht so aussehen, wie eine Person die Plattform nutzt, selbst wenn jede einzelne Aktion einen Inhaltscheck besteht. Genau deshalb ist das ein eigenes separates System, statt in einen Pro-Beitrag-Klassifikator eingearbeitet zu werden: Pro-Beitrag-Modelle sind blind für Muster, und Muster sind oft das stärkste Signal, das ein automatisierter Account hinterlässt.

Production-Tipp: Weil es hier um Tempo und Muster statt um Inhalt geht, kann es einen Account markieren, bevor er überhaupt etwas postet, das individuell gegen Regeln verstößt — wertvoll, aber es bedeutet, dass der Schwellenwert mit Sorgfalt gewählt werden muss, weil legitime Power-User ebenfalls ungewöhnlich hochfrequente, gemusterte Nutzung haben können.

3. `user-cred-v2` — Einen Account nach seiner Position im Graphen bewerten

Was es ist: Führt PageRank über den Follow-Graphen und Engagement-Kanten aus und wandelt die resultierende Masse in einen Pro-Account-Glaubwürdigkeitswert um.

Warum es wichtig ist: Das ist ein strukturelles Signal, unabhängig davon, was ein Account postet oder wie er sich von Moment zu Moment verhält. Ein Account, der tatsächlich in echte, wechselseitig engagierte Beziehungen eingebettet ist, sammelt graphbasierte Glaubwürdigkeit an, die teuer zu fälschen ist — Beiträge zu skripten ist einfach, aber eine überzeugende Position innerhalb eines echten sozialen Graphen herzustellen, ist im großen Maßstab deutlich schwerer zu fälschen.

Production-Tipp: Graphbasierte Vertrauenssignale sind hervorragend darin, Netzwerke zu erkennen, die sich überwiegend gegenseitig engagieren und von echten Clustern abgekoppelt bleiben — aber sie aktualisieren sich langsam für einen brandneuen, legitimen Account. Genau deshalb ist es eines von drei Signalen und nicht die ganze Geschichte.

4. `scarecrow` und `botmaker` — Scores in Echtzeit in Labels verwandeln

Was es ist: scarecrow reagiert auf Ereignisse, während sie passieren, und verwendet botmaker als eingebettete Rule Engine — eine speziell entwickelte Sprache, einen Compiler und eine Runtime für Regeln nach dem Muster: Bei diesem Ereignis, wenn diese Bedingungen gelten, wende dieses Label an. Die Regeln selbst liegen in einem separaten Verzeichnis botmaker-rules, das scarecrow lädt.

Warum es wichtig ist: Das ist die Schicht, die den Modellausgang mit Konsequenzen verbindet. agatha, bdsm und user-cred-v2 erzeugen jeweils Scores; scarecrow beobachtet Live-Ereignisse und entscheidet mithilfe von Regeln, die gegen diese Scores geschrieben sind, ob ein Label tatsächlich genau jetzt angewendet wird.

Production-Tipp: Eine dedizierte Regelsprache statt hartkodierter Bedingungen bedeutet, dass Regeländerungen kein vollständiges Redeploy erfordern — ein echter Vorteil, wenn Regeln sich schnell an neue Umgehungsmuster anpassen müssen.

5. `abuse-enforcement-service` — Direkt auf Scores reagieren

Was es ist: Ein separates System, das Modellscores über einen Account liest — nicht Live-Ereignisse — und den Account oder seine Beiträge labelt, eine Challenge ausgibt oder ihn suspendiert.

Warum es wichtig ist: Es läuft parallel zu scarecrow, auf denselben Modellausgaben, aber über einen anderen Mechanismus: score-getrieben statt ereignis-getrieben. Zwei unabhängige Pfade, die auf dieselben Signale reagieren, sind bewusst eingebaute Redundanz — eine Lücke in der Abdeckung eines Systems wird nicht automatisch zu einer Lücke in der Durchsetzung.

6. Visibility Filtering — Das eigentliche Gate

Was es ist: Für jede Kombination aus Beitrag und Betrachter gibt visibility-filtering eine von drei Antworten zurück: ALLOW, INTERSTITIAL (ein Zwischenschritt zum Antippen, verwendet für Adult oder Graphic Media) oder DROP. Es liest die von allem oben erzeugten Labels sowie die eigenen Blocks, Mutes und Einstellungen des Betrachters.

Warum es wichtig ist: Das ist das einzige System, das entscheidet, ob ein Beitrag überhaupt in einem Feed existiert. Hier laufen zwei Regelsätze: allgemeine Regeln für alle und ein zweiter Satz, der nur gilt, wenn ein Beitrag jemandem empfohlen wird, der dem Autor nicht folgt — diese nur-außerhalb-des-Netzwerks-Regeln können nur verwerfen und sind bewusst auf hohen Recall getrimmt, gerade weil derselbe Beitrag für einen tatsächlichen Follower sichtbar bleibt.

Production-Tipp: Die Auswertung stoppt bei der ersten Regel, die drop zurückgibt — es lohnt sich, die sichersten Bedingungen zuerst anzuordnen, sowohl aus Korrektheitsgründen als auch um keine Rechenleistung für Regeln zu verschwenden, die nie erreicht werden.

7. Unter der Haube — Den Kreis mit Transparenz schließen

Was es ist: Ein Reporting-Tool pro Account, das zusammen mit diesem Release erscheint und die sichtbarkeitsrelevanten Labels aggregiert, die im Zeitverlauf auf den eigenen Account und die eigenen Beiträge einer Person angewendet wurden.

Warum es wichtig ist: Code zu veröffentlichen beantwortet „wie funktioniert dieses System allgemein“, nicht „hat es meinem Account etwas angetan“. Under the Hood schließt diese Lücke — jemand kann sehen, welche Labels auf seinem Account gelandet sind, und da der Labeling-Code öffentlich ist, ein Label ungefähr bis zu dem System zurückverfolgen, das es erzeugt hat.

End-to-End-Durchlauf

Verfolgen wir einen einzelnen Account im Zeitverlauf durch die vollständige Pipeline:

Ein Account wird erstellt und beginnt normal zu posten und zu interagieren, ohne besondere Aufmerksamkeit auf sich zu ziehen.
Content Understanding läuft kontinuierlich im Hintergrund, außerhalb des Request Path. bdsm beginnt, die Aktionssequenz des Accounts zu erfassen, user-cred-v2 berechnet seinen graphbasierten Score neu, während Kanten hinzukommen, und die Batch-Jobs von agatha verfolgen, wie Menschen auf seine Beiträge reagieren.
Die Posting-Kadenz beginnt automatisiert zu wirken — schnell, repetitiv, gemustert auf eine Weise, wie es die Nutzung einer Person typischerweise nicht ist. Die Sequenzanalyse von bdsm überschreitet die Schwelle in Richtung unauthentisches Verhalten.
scarecrow, das Live-Ereignisse beobachtet, matched eine botmaker-Regel, die sich auf diesen steigenden Score bezieht, und wendet ein Label an.
Parallel dazu überschreitet abuse-enforcement-service, das denselben Modellscore statt des auslösenden Ereignisses liest, unabhängig seinen eigenen Schwellenwert und gibt eine Challenge oder Suspendierung aus.
Die resultierenden Labels werden in den Storage geschrieben.
Beim nächsten Zusammenstellen des Feeds irgendeines Betrachters liest visibility-filtering diese Labels und wertet seine Regeln der Reihe nach aus — das erste drop beendet die Auswertung, und der Beitrag erreicht die Kandidaten dieses Betrachters nie.
Das Ranking ist bereits unabhängig von dieser Entscheidung erfolgt. Der Beitrag kann in Bezug auf Relevanz gut gescort haben; Visibility Filtering legt trotzdem sein Veto ein, weil die beiden Systeme unterschiedliche Fragen auf Basis unterschiedlicher Eingaben beantworten.
Wenn der Account glaubt, dass das ein Fehler war, zeigt Under the Hood genau an, welche Labels angewendet wurden — und weil der Labeling-Code öffentlich ist, kann jeder ein Label ungefähr bis zu dem System zurückverfolgen, das es erzeugt hat.

Sonderfälle

Nur-außerhalb-des-Netzwerks-Drop-Regeln. Manche Regeln gelten nur für Beiträge, die einem Betrachter empfohlen werden, der dem Autor nicht folgt — ein bewusst auf hohen Recall ausgelegtes Netz auf der Discovery-Oberfläche, wo ein False Positive einen Fremden nur einen verpassten Beitrag kostet, statt einen Account für sein echtes Publikum zum Schweigen zu bringen. Der identische Beitrag erreicht Follower unverändert.

Regeln, die dem öffentlichen Repository absichtlich vorenthalten werden. X war dazu direkt: Einige botmaker-Regeln und die spezifischen LLM-Prompts, die von grox verwendet werden, werden nicht veröffentlicht, um das Risiko zu verringern, dass der Code als Anleitung zur Umgehung des Systems genutzt wird. Vollständige Transparenz und wirksame Durchsetzung ziehen an den Rändern in entgegengesetzte Richtungen — und hier hat X die Grenze gezogen.

Interstitial versus Drop aus derselben Pipeline. Dieselbe Labeling-Maschinerie speist beide Ergebnisse — der Unterschied liegt darin, welche Regel feuert und an welche Kategorie sie gebunden ist. Adult oder Graphic Content tendiert zu Interstitial; Labels für unauthentisches Verhalten tendieren zu Drop.

Skalierungs- und Produktionsherausforderungen

Teure Analysen vom Request Path fernhalten. Sequenzmodellierung, Graph-PageRank und Batch-Reaktionsanalyse sind allesamt wirklich teure Operationen — alle drei für jeden Account bei jeder Feed-Anfrage auszuführen, wäre in dieser Größenordnung untragbar. Sie kontinuierlich im Hintergrund auszuführen und zur Anfragezeit ein gecachtes, gespeichertes Ergebnis zu lesen, ist das, was die Ökonomie tragfähig macht; Berichte deuten darauf hin, dass sich allein der Kandidatenpool von mehreren hundert Millionen täglichen Beiträgen auf grob einige Tausend pro Nutzer verengt, noch bevor das Ranking überhaupt beginnt.

Kandidatenisolierung hält Scores cachebar. Eine bewusste Entscheidung in der Ranking-Schicht stellt sicher, dass der Score eines Kandidaten nicht davon abhängt, welche anderen Kandidaten im selben Batch sind — dasselbe Prinzip gilt für Account-Labels, die unabhängig davon dasselbe bedeuten müssen, welche Anfrage sie zurückliest.

Zwei unabhängige Durchsetzungspfade auf denselben Signalen. scarecrow (ereignis-getrieben) und abuse-enforcement-service (score-getrieben) parallel auf denselben Modellausgaben laufen zu lassen, kostet echte Engineering-Komplexität — aber es bedeutet, dass eine Timing-Lücke in einem Pfad nicht stillschweigend zu einer Lücke in der Durchsetzung insgesamt wird.

Recall je nach Oberfläche unterschiedlich ausbalancieren. Strengere Regeln mit höherem Recall gelten nur für Empfehlungen außerhalb des Netzwerks, während die Auslieferung innerhalb des Netzwerks an Follower unberührt bleibt — dadurch konzentriert sich die aggressivste Filterung auf die Oberfläche, auf der eine Plattform aktiv die Inhalte eines Fremden einführt, statt sie überall gleichmäßig anzuwenden.

Codebeispiele

Die folgenden Beispiele sind illustrative Rekonstruktionen der oben beschriebenen Konzepte, keine wortgetreuen Quelltexte aus dem Repository — ein Teil der tatsächlichen Regellogik ist, wie oben erwähnt, bewusst unveröffentlicht.

Eine vereinfachte Veranschaulichung dessen, was ein sequenzbasierter Account-Scorer konzeptionell auswertet:

def score_action_sequence(actions: list[dict], window_hours: int = 24) -> float:
    recent = [a for a in actions if a["hours_ago"] <= window_hours]
    if len(recent) < 5:
        return 0.0
    intervals = [b["ts"] - a["ts"] for a, b in zip(recent, recent[1:])]
    regularity = 1.0 - (stdev(intervals) / (mean(intervals) + 1e-6))
    return min(regularity * len(recent) / 100, 1.0)

Eine konzeptionelle Regel im botmaker-Stil, ausgedrückt als Pseudocode statt in der tatsächlichen Regelsprache:

ON post_published
IF account.bdsm_score > 0.85 AND account.user_cred_score < 0.2
THEN apply_label(account, "likely_inauthentic")

Eine vereinfachte Veranschaulichung der Auswertungsreihenfolge „first drop wins“ im Visibility Filtering:

def evaluate_visibility(post, viewer, rules: list[callable]) -> str:
    for rule in rules:
        result = rule(post, viewer)
        if result == "DROP":
            return "DROP"
    return "ALLOW"

Häufige Fallstricke

Fehler: Bot-Erkennung als ein Modell mit einem Score behandeln. Ein einzelner Klassifikator, der Reaktionsmuster, Verhaltenssequenzen und Graphposition auf einmal erfassen soll, verwischt Signale, die tatsächlich unabhängig sind. Lösung: Jede Dimension separat scoren und sie downstream in der Regelschicht kombinieren, nicht upstream im Modell.

Fehler: Einen Relevanzscore zugleich als Sicherheitsscore verwenden. Es ist verlockend, „ist das guter Inhalt“ und „ist das ein schlechter Akteur“ in einer Zahl zusammenzufassen. Lösung: Ranking und Sichtbarkeit als wirklich getrennte Systeme halten, die getrennte Eingaben lesen.

Fehler: Teure Analyse auf Account-Ebene auf dem Request Path ausführen. Das ist der schnellste Weg, ein Erkennungssystem zu langsam für den Einsatz im großen Maßstab zu machen. Lösung: Die schwere Analyse kontinuierlich im Hintergrund ausführen und den Read zur Anfragezeit günstig halten.

Fehler: Jede Regel zu veröffentlichen, um maximale Transparenz zu erreichen. Das klingt vertrauenswürdig, gibt aber auch jedem Motivierten eine präzise Karte dessen, was er vermeiden muss auszulösen. Lösung: Explizit benennen, was zurückgehalten wird und warum, statt Vollständigkeit zu suggerieren, die man nicht hat.

Fehler: Jede einzelne markierte Aktion als hinreichenden Beleg zu behandeln. Ein einzelner ungewöhnlicher Beitrag ist für sich genommen ein schwacher Beweis für irgendetwas. Lösung: Auf Muster über die Zeit bauen — genau deshalb existiert ein sequenzbasiertes Modell als eigenes System.

Best Practices für den Produktiveinsatz

Trenne deine Signale, bevor du sie kombinierst. Reaktionsbasierte, verhaltensbasierte und graphbasierte Signale erfassen unterschiedliche Fehlermodi — wenn man sie zu früh zusammenklappt, verliert man Informationen, die eine nachgelagerte Regelschicht nutzen könnte.
Halte Sicherheit und Ranking als getrennte Systeme. Sie beantworten unterschiedliche Fragen und sollten einander widersprechen dürfen — ein hochrelevanter Beitrag kann trotzdem einer sein, den du nicht anzeigen willst.
Führe teures Scoring kontinuierlich aus, nicht auf dem Request Path. Hintergrundberechnung plus ein günstiger, gecachter Read ist das, was ein mehrschichtiges Erkennungssystem im großen Maßstab tragfähig hält.
Baue redundante Durchsetzungspfade dort, wo viel auf dem Spiel steht. Unabhängige Systeme, die über unterschiedliche Mechanismen auf dieselben Signale reagieren, fangen die blinden Flecken des jeweils anderen auf.
Sei ehrlich darüber, was du zurückhältst, und warum. Eine glaubwürdige Transparenzinitiative benennt ihre Grenzen ausdrücklich, statt Vollständigkeit zu suggerieren, die sie nicht besitzt.

Zum Schluss

Die Schlagzeilenfassung — „X hat seine Ranking-Gewichte veröffentlicht“ — verkauft unter Wert, was hier tatsächlich ausgeliefert wurde. Der wirklich bemerkenswerte Teil ist eine vollständige, inspizierbare Account-Scoring- und Durchsetzungs-Pipeline: unabhängige Modelle, die Reaktionen, Verhaltenssequenzen und Graphposition lesen, eine speziell entwickelte Rule Engine, die diese Scores in Labels umwandelt, und eine Visibility-Schicht, die die Sicherheitsentscheidung vollständig von der Relevanzentscheidung trennt. Was auch immer man von der Plattform hält, für die das gebaut wurde — die Architektur selbst ist eine wirklich nützliche Referenz für alle, die eigene Trust-&-Safety-Systeme entwickeln.

Wenn du das tatsächliche Repository selbst gelesen hast: Welcher Teil der Pipeline hat dich am meisten überrascht — die Modelle auf Account-Ebene oder wie viel von der Regellogik absichtlich ausgelassen wurde?