Taos Einschätzung zu Blue-Team- und Red-Team-LLMs

 (mathstodon.xyz)
3 Punkte von GN⁺ 2025-07-29 | 1 Kommentare | Auf WhatsApp teilen
  • Terence Tao erwähnt die logische Bedeutung der Unterscheidung zwischen Blue Team und Red Team im Bereich der Cybersicherheit
  • Constructive logic steht für die Prinzipien des Blue Teams, co-constructive logic für die des Red Teams
  • Mike Shulman forscht an einer neuen Logik, die beide logischen Grundlagen kombiniert
  • Die Brouwer–Heyting–Kolmogorov(BHK)-Interpretation ist beweiszentriert, betont aber auch die Bedeutung der Widerlegung
  • Diese Forschung könnte in verschiedenen Bereichen wie AI Safety Anwendung finden

Diskussion über die Unterscheidung und Kombination der Logik von Blue-Team- und Red-Team-LLMs

  • Terence Tao erwähnte, dass Logiker in jüngster Zeit im Bereich Sicherheit und Algorithmen tiefer über die Unterscheidung zwischen Blue Team (Verteidigung) und Red Team (Angriff) nachdenken
  • Constructive logic konzentriert sich auf den Verifikationsprozess, also darauf, wie eine Aussage bewiesen wird, und beschreibt damit die Prinzipien des Blue Teams
  • Im Gegensatz dazu befasst sich co-constructive logic mit dem Widerlegungsprozess, also mit Logik rund um Gegenargumente oder Angriffe, hat zuletzt Aufmerksamkeit erhalten und verkörpert die Prinzipien des Red Teams

Mike Shulmans Forschung zur Kombination von Logiken

  • Mike Shulman erforscht derzeit eine Form von Logik, die diese beiden logischen Systeme miteinander verbindet
  • Laut einem Zitat aus seiner Arbeit neigt die bestehende Brouwer–Heyting–Kolmogorov(BHK)-Interpretation dazu, sich nur auf die Kriterien für Beweise zu konzentrieren, während praktizierende Mathematiker auch Kriterien zur Widerlegung, also zur Feststellung, dass eine Aussage falsch ist, für ebenso wichtig halten
  • Damit weist er auf die Grenzen einer beweiszentrierten Denkweise in bisherigen logischen Interpretationen hin

Notwendigkeit einer erweiterten Logikinterpretation

  • Es wird die Notwendigkeit aufgeworfen, bei logischen Junktoren aus beiden Perspektiven zu erklären, was Beweis und Widerlegung jeweils bedeuten
  • Mike Shulmans laufende Forschung untersucht, welche Struktur eine solche erweiterte Interpretation tatsächlich haben könnte

Implikationen und mögliche Anwendungen

  • Wenn die Forschung zu einer solchen kombinierten Logik voranschreitet, dürfte sie bei der Entwicklung von AI Safety sowie bei Systemen zur Verifikation und Widerlegung von Algorithmen in der Cybersicherheit praktisch nutzbar sein
  • Weitere Details zur zugehörigen Arbeit finden sich unter dem arXiv-Link

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-07-29
Hacker-News-Meinung

  • Ich habe ein paar Gedanken dazu
    (a) KI ist sowohl für das „Red Team“ als auch für das „Blue Team“ nützlich
    Das Blue Team übernimmt dabei eine Art Brainstorming-Rolle
    (b) AlphaEvolve ist in diesem Sinne ein klares Beispiel für einen „Red/Blue-Team“-Ansatz. Diese Begriffe werden dort allerdings nicht verwendet
    Terence Tao war außerdem Berater für diese Arbeit
    (c) Das erinnert an die Rollenverteilung „Verifier/Falsifier“ in der Spielsemantik
    Tao selbst hat sich öffentlich zu dieser Denkweise geäußert, daher liegt nahe, dass er es tatsächlich aus dieser Perspektive betrachtet
    Die Formulierung „Blue/Red“ ist vermutlich eher eine Verpackung für Programmierer
    (d) Ergänzend dazu: Man kann nicht immer sagen, dass ein Sicherheitssystem nur so stark ist wie sein schwächstes Glied
    Es hängt davon ab, ob die Sicherheit geschichtet ist oder parallel aufgebaut
    Wenn ein Flur aus mehreren starken und schwachen Türen besteht, die alle hintereinander liegen, wird die Gesamtstärke durch die stärkste Tür bestimmt
    Und wenn man mehrere schwache Klassifikatoren zu einem Betrugserkennungsalgorithmus kombiniert, kann das am Ende viel stärker sein als der jeweils schwächste Klassifikator
    AlphaEvolve-Paper
    Q&A zu Taos Denkweise

    • Ich frage mich, wie das LLM in AlphaEvolve überhaupt die Rolle des Red Teams übernimmt
      Dort erzeugt das LLM doch lediglich neuen Code auf Basis von Beispielen und bewertet den Code selbst nicht

  • Mir erscheint das Red-vs.-Blue-Team-Konzept als ein guter Rahmen, um zu verstehen, wie nützlich LLMs für Expertenarbeit tatsächlich sind
    Das Hinzufügen von Tests würde ich fast ohne Zögern einem LLM überlassen
    Denn Tests sind normalerweise billig, lassen sich bei Fehlern leicht löschen oder korrigieren, und wenn sie stimmen, schaffen sie zusätzlichen Wert
    Allerdings testen LLMs die Kernfunktionalität oft nicht, daher muss man die wichtigsten Tests selbst schreiben, wenn man ihnen vertrauen will
    Dagegen ist es riskanter, mit einem LLM Bugs zu beheben oder Features hinzuzufügen
    Denn ein LLM kann Abkürzungen nehmen oder Code schreiben, der nur die Tests besteht, ohne das eigentliche Problem zu lösen

    • Während ich an einem Legacy-Codebestand arbeite, merke ich sehr deutlich, wie gefährlich die Haltung „Wenn die Tests falsch sind, korrigieren wir sie später“ ist
      Tests sind manchmal näher an der Wahrheit als der Code selbst, deshalb können falsche Tests schädlicher sein als falscher Code
      Vor allem wenn nutzlose oder in ihrer Bedeutung unklare Tests dazwischen sind, ist es am schlimmsten zu erkennen, ob sie überhaupt wichtige Funktionalität absichern sollen

    • Ich denke, KI ist ähnlich wie ein Taschenrechner
      So wie ein Taschenrechner Berechnungen gut ausführt, die die meisten Menschen nicht leisten können, ist KI als neue Art von Intelligenz ein Hilfswerkzeug, das Menschen verstärkt
      Viele denken, „KI ersetzt den Menschen“, aber der eigentliche Wert liegt darin, menschliche Arbeit zu ergänzen

    • Ich sehe das genau andersherum
      Man sollte Tests selbst schreiben und vollständig verstehen, um einen echten Maßstab zu haben; erst dann kann man beruhigt sein, wenn die KI den Code nach Belieben ändert
      Wenn die Tests vom LLM stammen, wächst mein Unbehagen eher noch, den Rest des Codes der KI zu überlassen

    • Ich habe mit einem LLM Tests für Rust-Code erzeugt, und in der Praxis war das eher schädlich als nützlich
      Es gab zwar viele Tests, aber wichtige Bereiche fehlten leicht
      Weil die Menge an Code so groß war, war es schwer zu erkennen, welche Teile nicht abgedeckt waren
      Und wenn ich künftig die Logik des Codes ändern wollte, musste ich am Ende all diese vielen generierten Tests anfassen

    • Es heißt oft: „Tests werden von niemandem verifiziert, also nimmt man automatisch an, dass sie stimmen“
      Deshalb gibt es das Arrange-Act-Assert-Muster
      Meine liebsten Unit-Tests bestehen inzwischen darin, Eingabewerte und erwartete Ausgaben zu speichern und damit das Ergebnis des Codes zu prüfen
      So lassen sich auch Edge Cases leicht verifizieren, und man sieht schnell, ob sich das System wirklich wie gewünscht verhält

  • Soweit ich weiß, wurde auch der RSA-Algorithmus auf diese Weise entwickelt
    Laut Simon Singhs „The Code Book“ (ich habe es irgendwo hingelegt und finde es nicht) lief es so, dass Rivest und Shamir die Ideen entwickelten und Adleman die Schwachstellen fand
    RSA bei Wikipedia
    Auch in der Mathematik ist das ein Beispiel für Blue-/Red-Team-Kollaboration

    • Die beiden Kognitionswissenschaftler, die ich kenne, sind ähnlich
      Einer hat viele Ideen, redet viel und ist ungeordnet
      Der andere ist logisch und präzise; wenn einer einen Paper-Entwurf schreibt, streicht der andere alles Überflüssige heraus

  • Im Großen und Ganzen stimme ich zu, aber das Framing aus der Infosec-Perspektive wirkt etwas seltsam
    Die Sichtweise „Sicherheit ist nur so stark wie ihr schwächster Teil“ ist zu simpel und riskant
    Sicherheitsstrategien müssen mehrschichtig aufgebaut sein
    Da man auf einer einzelnen Ebene keine Perfektion erwarten kann, braucht man mehrere Verteidigungsschichten
    Zwischen Angriff und Verteidigung besteht kein großer Unterschied, aber viele Angreifer tragen selbst bei Fehlern wenig Verantwortung, während Verteidiger — besonders in großen Unternehmen — die Folgen verantworten müssen
    Allerdings haben Verteidiger den Vorteil, auf eigenem Terrain zu kämpfen. Wenn man das übersieht, kann es problematisch werden

    • Das Beispiel, dass eine geschlossene Tür nichts bringt, wenn das Fenster offen steht, ist eine passende Analogie
      Mehrschichtige Verteidigung ergibt Sinn, wenn sich zwischen dem Angreifer und dem Ziel mehrere Ebenen befinden, die zwingend überwunden werden müssen
      Wenn sich die Elemente aber auf derselben Ebene befinden, wie bei Tür und Fenster, bestimmt die schwächste Stelle das Ganze
      Ein Web-Beispiel: Der Haupt-Login ist perfekt, aber ein alter Endpoint wie /v1/legacy/external_backoffice erlaubt ohne jede Authentifizierung Zugriff auf das interne Netz — dann bricht die gesamte Verteidigung zusammen
      Wenn es intern trotzdem noch weitere Sperren gibt, lässt sich der Schaden begrenzen; insofern bleiben Verteidigungsschichten entscheidend

    • Mit „Verteidigung ist so stark wie ihr schwächstes Glied“ war das etwas allgemeiner gemeint
      Ich bin über die Formulierung des Originalposts hinausgegangen und habe das Wort „gesamte Verteidigungsanstrengung“ ergänzt, aber eigentlich haben beide Positionen ihre Berechtigung
      Wie Terence sagt, kann das schwächste Glied tatsächlich ausgenutzt werden, und deshalb braucht man mehrere Verteidigungsschichten
      Ein aktuelles reales Beispiel war ein Helpdesk-Mitarbeiter, der das Passwort eines Kunden ohne Überprüfung zurücksetzte
      Trotz starker Sicherheitstechnik wie VPN und 2FA brachte ein einziges schwaches Glied, nämlich die „Kontowiederherstellung“, das gesamte System zu Fall
      Zusätzliche interne Schichten erkannten und stoppten den Eindringling zwar nach drei Stunden, aber das war „Schadensbegrenzung“, nicht „präventive Verhinderung“
      Letztlich braucht es also mehrere Ebenen, um Schäden zu verhindern
      In der Infosec-Branche verschiebt sich der Fokus inzwischen ohnehin von „100 % Prävention“ zu „Schadensminderung“
      Es ist schwer, jedes Risiko zu verhindern; stattdessen geht die Strategie eher dahin, Risiken zu senken, die Angriffsfläche zu minimieren und das Vertrauensniveau zu reduzieren

    • Ich bin überhaupt kein Sicherheitsexperte, aber ich habe gehört, dass „eine extrem reduzierte Angriffsfläche und der Einsatz verifizierter Open-Source-Protokolle“ die beste Verteidigung seien
      Ich frage mich, worin der Unterschied zu dem hier Diskutierten besteht

    • Es wurde einfach eine nicht ganz passende Analogie gewählt
      Die Aussage vom „schwächsten Glied“ stimmt, wenn mehrere Schritte nacheinander überwunden werden müssen
      Gibt es dagegen mehrere Schichten auf derselben Ebene, wird natürlich die schwächste davon angegriffen
      Wie befürchtet lässt die Formulierung also Raum für Mehrdeutigkeit

    • Ich würde sogar sagen, dass Angriff selbst eine weitere Verteidigungsschicht ist
      So wie in dem Spruch: „Die beste Offensive ist die beste Defensive“

  • In der Cybersicherheit sind Red Team und Blue Team zwei Teams mit vergleichbarer Schlagkraft
    In der Softwareentwicklung wirkt die Metapher aber etwas überzogen
    Tests sind ebenfalls Code, und auch sie enthalten Bugs
    Dadurch entsteht ein Paradox wie bei „Who polices the police?“

  • Das erinnert mich an John Cleeses Gedanke zum „offenen Modus vs. geschlossenen Modus“
    Ideen erzeugt man möglichst offen und vielfältig
    Später wechselt man in den geschlossenen Modus, filtert schlechte Ideen heraus und entwickelt die guten weiter
    Autoren in allen Bereichen haben normalerweise ebenfalls Editoren
    Auch beim Design des Kartenspiels Magic: the Gathering ist es ähnlich: Das Designteam erstellt einen Set-Entwurf und übergibt ihn dann an ein völlig separates Entwicklungsteam zur Prüfung
    Ich würde gern weitere Beispiele für solche Zusammenarbeit hören

    • Als weiteres Beispiel kann man Teams nennen, die in ein Dev-Team und ein Validation-Team aufgeteilt sind

  • Eigentlich sehe ich es genau umgekehrt als in diesem Beitrag
    LLMs sind hervorragend darin, schnell Entwürfe zu erstellen, und gut trainierte Menschen eignen sich besser dafür, die Ergebnisse eines LLM kritisch zu prüfen
    Das heißt: LLMs passen eher zum Blue Team und Menschen eher zum Red Team

    • Auf dem absoluten Stand der Technik könnte sich diese Sichtweise allerdings umkehren
      Tao scheint auf solche Extremsituationen hinzuweisen

  • In letzter Zeit habe ich agentenbasierte Modelle und Workflows ausprobiert und dabei Folgendes festgestellt
    Solche Agenten glänzen nicht nur beim Schreiben von Code, sondern auch bei Tests, Verwaltung und sogar in Management-Rollen
    Entwickler werden dabei zu einer Art Manager, also zu Aufsehern
    Sie überwachen den gesamten Prozess: Aufgabenplanung (Prompting, Abgrenzung des Arbeitsumfangs), Testschreiben und Codeerstellung
    Es gibt zwar enorm viel mehr Review-Arbeit, aber weil ich selbst die Rolle des Red Teams übernehme und prüfe, ob weniger kaputtgeht, habe ich eher das Gefühl, mehr Kontrolle zu haben

  • Diese Perspektive finde ich beeindruckend
    Auch in der Wirtschaft könnte man zwischen „Blue Teams“ (grundlegende Infrastrukturbranchen: Strom, Öl, Telekommunikation, Software, Finanzen usw.) und „Red Teams“ (Branchen mit Mehrwert: Gastronomie, Spezialhandel, Luxusgüter, Tourismus usw.) unterscheiden
    Ökonomisch ist die Blue-Team-Seite viel wichtiger, weil diese Branchen die Grundlage der gesamten Wirtschaft bilden, viel Nachfrage haben und dort Fehler möglichst vermieden werden müssen
    Red-Team-Branchen sind für das Funktionieren der Wirtschaft nicht zwingend nötig, aber je mehr es davon gibt, desto stärker steigt die allgemeine Lebensqualität
    In Taos Beispiel ist es dieselbe Struktur: Softwareingenieure verdienen mehr als QA, und das Schreiben von Beweisen gilt als wirtschaftlich wertvoller als ihre Verifikation
    Wenn Sam Altman Geld für das Training von LLMs einsammelt, muss er betonen, dass „wir als Blue Team nützlich sind“, damit Investoren eher einsteigen, und das beeinflusst die gesamte mediale Erzählung
    Tatsächlich eignen sich LLMs eher für Red-Team-Anwendungen, aber weil die Kapitalrückzahlung im Vordergrund stehen muss, werden Unternehmen LLMs vor allem für Blue-Team-Zwecke pushen
    Bei Google Glasses, VR und Wearables sieht man ein ähnliches Muster
    Das sind nützliche Red-Team-Technologien in Nischenbranchen, aber weil sie weder ein riesiges Ökosystem noch große Gewinne erzeugen, werden sie vom Kapital eher ignoriert

  • (Ich bin bei Microsoft.)
    Ich betreibe selbst automatisierte Red-Team-Validierung für RAG-Beispiele mit dem SDK azure-ai-evaluation
    Dabei werden ein adversariales LLM ohne Leitplanken und das Paket pyrit kombiniert, um für die App automatisch seltsame Fragen zu erzeugen und diese auch noch per base64, Caesar-Chiffre, urldecode usw. zu transformieren
    Die Ergebnisse sind tatsächlich interessant, und ich stimme zu, dass LLMs für Red-Team-Aktivitäten ziemlich nützlich sind
    YouTube-Demovideo
    (Bitte die laute Stimme entschuldigen, das wurde an einem ungewöhnlichen Ort aufgenommen.)