Dieser Beitrag ist eine Übersetzung des englischen Originals. Bei Abweichungen gilt das englische Original.
ArtifactNet-Forschung · Teil 7 · Juli 2026
Die Genre-Lücke und die Fehlalarmrate schließen, die wir zu beheben versprochen hatten
Ein Forschungsprotokoll für den Juli 2026. Teil 6 hinterließ uns ein Versprechen: Das nächste Quartal sollte der Hard-Real-Fehlalarmrate gehören, statt einem weiteren Benchmark-Rekord hinterherzujagen. Dies ist die Aufzeichnung, wie wir dieses Versprechen gehalten haben — dazu ein Genre, auf dessen Scannen wir stillschweigend verzichtet hatten, ein Retraining von Grund auf mit dem größten Datensatz, den wir je zusammengestellt haben, und ein Deployment-Fehler, den wir nur fanden, weil wir nach einem gesucht haben.
Willst du das aktuelle Modell in Aktion sehen? Schicke einen beliebigen Track durch die kostenlose Demo — dieselbe forensische Pipeline, die unten beschrieben wird, ohne Konto.
Teil 6 endete mit einem konkreten, engen Ziel. Die „Udio-Schwäche“, der wir im Juni nachgejagt waren, entpuppte sich als Trugbild durch Leakage in der Evaluation — auf einem sauberen zurückgehaltenen Datensatz war die Udio-Erkennung mit 97,8 % in Ordnung. Die eigentliche, übrig gebliebene Schwäche waren Fehlalarme bei echten Aufnahmen: Amateur-Uploads auf SoundCloud, FMA, Lo-fi. Auf unserem Hard-Real-Benchmark mit 9 Quellen lag unser bester Kandidat noch bei 15,57 % FPR, nach 32,25 % zuvor, aber weit von produktionsreif entfernt.
Wir hatten gesagt, dass wir uns im nächsten Quartal direkt diese Zahl vornehmen würden, statt den nächsten Benchmark-Sieg einzusammeln. Dieser Beitrag zeigt, wie dieses Quartal aussah.
Der erste Schritt war kein größeres Modell, sondern eine zweite Meinung. Die meisten Fehlalarme, die wir jagten, waren nicht mit großer Sicherheit falsch, sondern grenzwertig: Sie lagen nahe an der Entscheidungsgrenze, wo der einzelne Durchlauf des Haupt-CNN am wenigsten verlässlich ist. Also haben wir ein kleines Zweitmodell trainiert — intern rescue-gate genannt, ein LGBM-Head mit 28 Merkmalen (verdict28) —, dessen einzige Aufgabe es ist, sich Entscheidungen, bei denen sich das Hauptnetz nicht sicher ist, noch einmal anzusehen und sie zu überstimmen, wenn die Belege in die andere Richtung weisen.
Anfang Juli haben wir es in den Serving-Pfad integriert und einen Betriebsschwellenwert (τ) festgelegt. Allein, ohne das CNN überhaupt anzufassen, senkte rescue-gate die Hard-Real-Fehlalarme spürbar — ein Beleg dafür, dass ein Teil unseres FPR-Problems gar kein Repräsentationsproblem war, sondern nur ein Problem der Entscheidungsgrenze.
Eine Regel setzen wir inzwischen strikt durch: rescue-gate muss auf derselben CNN-Generation neu trainiert werden, die es kontrolliert. Generationen zu mischen — ein altes rescue-gate hinter einem neuen CNN oder umgekehrt — ist keine kleine Abweichung. Wir haben einen dokumentierten Vorfall vom April, bei dem genau dieses Mismatch die Fehlalarme auf 52 % hochschnellen ließ. Deshalb wird jede Überführung eines CNN in Produktion in diesem Beitrag mit einem passenden rescue-gate-Retraining ausgeliefert, nie mit einem wiederverwendeten.
Mitte Juli haben wir eine kleinere Nebenuntersuchung durchgeführt: Hinterlässt jeder KI-Generator einen unterscheidbaren „Fingerabdruck“ im Embedding-Raum, getrennt vom allgemeinen Signal KI gegen Mensch? Die Antwort war ein eingeschränktes Ja. Von Menschen gemachte Musik liegt unabhängig vom Generator in einer klar abgegrenzten Region gegenüber KI-Ausgaben, und die Trennung hält recht gut stand, selbst bei Generator-Architekturen, die das Modell nie gesehen hat — wenn auch nicht perfekt. Es ist ein Nebenergebnis, kein ausgeliefertes Feature, aber ein weiterer Beleg dafür, dass das Modell etwas Strukturelles an Codec-Rückständen liest, statt oberflächliche Merkmale einzelner Generatoren auswendig zu lernen (dieselbe Schlussfolgerung, auf die auch die gescheiterten Experimente aus Teil 6 hindeuteten).
Etwa zur selben Zeit haben wir begonnen, teilweise KI-generierte Tracks zu erkennen — Songs, in denen nur ein Teil des Materials KI-generiert ist (zum Beispiel ein KI-Gesang über einem von Menschen gespielten Instrumental). Beim Bau dieses Detektors mussten wir das Verhalten auf Genre-Ebene viel genauer ansehen, und dabei trat ein Problem zutage, das wir bis dahin stillschweigend umgangen statt gelöst hatten: Elektronische Musik hatte eine ungewöhnlich hohe Fehlalarmrate, so hoch, dass wir aufgehört hatten, sie mit irgendeiner Zuversicht zu scannen.
Die damalige Notlösung war eine bedingte Anhebung des Schwellenwerts für elektronisch geprägte Quellen — keine Lösung, nur ein Weg, den Schaden zu begrenzen, während wir die eigentliche Ursache suchten. Abschnitt 6 weiter unten ist diese Ursache.
In der dritten Juliwoche war klar, dass Schwellenwert-Tuning und ein rescue-gate-Durchgang, so nützlich sie waren, die Genre-Lücke nicht schließen und die Hard-Real-FPR nicht vollends senken würden. Beide Probleme hatten dieselbe Ursache: Die Trainingsverteilung des CNN enthielt nicht genug elektronische Musik und nicht genug praxisnahes, neu kodiertes Material im SoundCloud-Stil, um eines von beiden gut abzubilden.
Also haben wir das größte Retraining in der Geschichte des Projekts durchgeführt — 27.476 Tracks aus 22 Quellen, aufgebaut aus einem Leakage-freien Manifest (geprüft gegen jedes Trainingslog jeder früheren Generation, nicht nur der unmittelbar vorhergehenden). Den entstandenen Checkpoint nennen wir bigset.
Dabei haben wir endlich isoliert, was die Fehlalarme im SoundCloud-Stil tatsächlich verursachte. Es war nicht die Plattform und auch nicht „Amateur-Produktion“ als vage Kategorie — es war wiederholte MP3-Rekomprimierung. Tracks, die mehrfach als MP3 neu kodiert wurden (Upload → erneuter Download → erneuter Upload, üblich auf Aggregator- und Remix-Kultur-Plattformen), sammeln Kompressions-Artefakte an, die den Codec-Rückständen ähneln, auf deren Erkennung wir trainiert sind. Sobald wir den Mechanismus verstanden hatten, konnten wir ihn direkt im Training abbilden, statt ihn mit einem Schwellenwert zu überdecken.
rescue-gate wurde auf derselben bigset-Generation neu trainiert (gemäß der Regel aus Abschnitt 2), und wir haben einen vollständigen 2D-Sweep über die Schwellenwerte von CNN und rescue-gate gemeinsam gefahren, um einen Arbeitspunkt festzulegen — er landete bei τ=0,225, gegenüber 0,5 bei der vorherigen Generation.
Wir haben ArtifactBench von Grund auf neu laufen lassen — nicht inkrementell, sondern das vollständige Harness — auf 5.458 Tracks (das 2,6-Fache unseres bisherigen Testsets mit 2.103 Tracks), die alle 22 von uns verfolgten KI-Generatoren abdecken.
| Kennzahl | Vorherige Generation | bigset |
|---|---|---|
| ArtifactBench F1 | 0.984 | 0.9921 |
| Als KI markierte echte Musik | 4.2% | 0.38% |
| Erkennung bei festem FPR-Budget von 1,5 % | 97.38% | 98.59% |
Bei festem Fehlalarm-Budget trotzdem 1,2 Punkte bei der Erkennung zu gewinnen, ist das Indiz dafür, dass es sich um eine echte Modellverbesserung handelt und nicht um eine verschobene Schwelle, die nur so aussieht. Speziell bei τ=0,02 lauteten die Rohzahlen: 4.334 richtig Positive, 4 falsch Positive, 65 falsch Negative und 1.053 richtig Negative bei 5.458 Tracks — TPR 98,52 %, FPR 0,378 %.
Die Aufschlüsselung nach Genre ist die Zahl, die wir eigentlich erreichen wollten:
| Genre | F1 |
|---|---|
| Pop | 0.995 |
| Rock | 0.993 |
| Elektronisch (bisher unser Schwachpunkt) | 0.988 |
| Lo-fi | 0.987 |
| Hip-Hop | 0.987 |
| Akustik | 0.987 |
Jedes Genre, das wir testen, erreicht jetzt mindestens F1 0,986. Vor bigset war elektronische Musik das einzige Genre, das das nicht schaffte — das ist die „Genre-Wand“, nach der dieser Beitrag benannt ist, und es ist das erste Mal, dass wir sagen können, dass alle gleichzeitig über der Linie liegen.
Auf dem zurückgehaltenen Datensatz mit echter Musik, den wir seit Teil 6 verfolgen (ohne SoundCloud, um den Effekt gezielt von der Rekomprimierungs-Korrektur zu trennen), sanken die Fehlalarme von 5,98 % auf 1,48 %. Das ist dieselbe Benchmark-Familie, aus der die ~15 % stammen, die wir beim letzten Mal offengelegt haben — also keine einzelne, direkt vergleichbare Zahl, da rescue-gate und die Arbeit am Schwellenwert sie zwischenzeitlich schon abgetragen hatten, aber der Verlauf ist dieselbe Linie, und er liegt jetzt unter 1,5 % statt im zweistelligen Bereich.
Die Überführung von bigset in Produktion brachte genau den Fehlermodus ans Licht, vor dem Abschnitt 2 warnt — nur in unserer eigenen Infrastruktur statt in einem kundenseitigen Modell. Unsere Demo-App lud rescue-gate unabhängig von der Haupt-Inferenz-Pipeline und zeigte während der Überführung weiter auf den rescue-gate-Checkpoint der vorherigen Generation, während das Haupt-CNN schon auf bigset umgestellt war. Dieselbe Mismatch-Klasse wie beim Vorfall im April, diesmal entdeckt durch die Disziplin aus Abschnitt 2 und nicht durch einen FPR-Anstieg in der Produktion. Wir haben die Demo-App so korrigiert, dass sie rescue-gate genauso lädt wie die Haupt-Pipeline, aus einer einzigen Quelle der Wahrheit.
Eine zweite, kleinere Lücke: Unser Forschungs-Demo-Server und der eigentliche kundenseitige Inferenzdienst sind zwei verschiedene Systeme auf zwei verschiedenen Maschinen, und eine Deployment-Prüfung ging kurzzeitig davon aus, sie seien synchron, obwohl sie es nicht waren. Wir haben das bei der abschließenden Verifikation am selben Tag bemerkt und korrigiert — aber es erinnert daran, dass „Das Modell ist in Produktion überführt“ und „Das Modell bedient Traffic“ zwei getrennte Aussagen sind, die beide jedes Mal geprüft werden müssen. Sowohl die kostenlose Demo als auch der kontenbasierte Batch-Dienst laufen jetzt nachweislich mit bigset. Unser serverloser RunPod-Batch-Endpoint ist von dieser Überführung ausgenommen und liefert weiterhin die vorherige Generation aus — dieses Overlay ist separat eingeplant.
Außerdem haben wir unseren monatlichen In-the-Wild-Scan — die Methodik des AI Music Index, die wir früher in diesem Monat festgelegt haben — mit bigset neu laufen lassen. Die Mainstream- und SoundCloud-Ausschnitte, die wir bereits abgehakt hatten, kamen erwartungsgemäß wieder sauber zurück. Interessant war die Änderung bei Beatport, einem Katalog elektronischer Musik, den wir faktisch vom Scannen ausgeschlossen hatten, weil die Fehlalarmrate der vorherigen Generation dort unbrauchbar war (ein Median der KI-Wahrscheinlichkeit von 0,955 über die gesamte Stichprobe — die „Fehlalarm-Explosion“, die Abschnitt 4 motiviert hat). Mit bigset fiel dieser Wert auf eine korrigierte Schätzung von 0,07 %, wobei das Konfidenzintervall null einschließt. Kataloge elektronischer Genres sind damit zum ersten Mal ein Bereich, den wir mit gutem Gewissen scannen können.
Zwei Ambient-/Schlafmusik-Tracks, die in einem früheren Index-Lauf markiert worden waren, wurden mit einer völlig anderen Modellgeneration neu bewertet und kamen sicherer markiert zurück (0,842→0,892 und 0,633→0,759, nicht weniger sicher) — ein Beleg dafür, dass dieses Signal echt war und kein Artefakt der bekannten Schwächen des alten Modells. Wir sagen es offen: Die Stichprobengröße des Katalogs elektronischer Musik (43 Tracks) ist noch zu klein, als dass unser stratifiziertes Rogan-Gladen-Konfidenzintervall null ausschließen könnte, daher erreicht diese Teilmenge unsere Veröffentlichungsschwelle noch nicht. Wir halten sie lieber zurück, als aufzurunden.
Eine zweite Meinung ist billiger als ein größeres Modell. rescue-gate hat die Hard-Real-FPR bewegt, ohne das CNN überhaupt anzufassen — bleibt aber nur sicher, wenn es im Gleichschritt mit dem Modell versioniert wird, das es kontrolliert; diese Regel setzen wir nach einem dokumentierten Vorfall jetzt als Richtlinie durch statt als Konvention.
Schwellenwert-Anhebungen sind eine Notlösung, keine Diagnose. Die bedingte Anpassung, die wir Mitte Juli für elektronische Musik ausgeliefert haben, verschaffte uns Zeit; sie erklärte nichts. Die eigentliche Lösung kam erst, als wir den Mechanismus (wiederholte MP3-Rekomprimierung) zurückverfolgt und im Training abgebildet hatten.
„In Produktion überführt“ und „bedient Traffic“ sind verschiedene Aussagen. Wir haben im selben Rollout einen Generationen-Mismatch in der Demo-App und eine Verwechslung von Demo- und Produktionsserver entdeckt — beide geringfügig, beide entdeckt, bevor sie ins Gewicht fielen, beide eine Erinnerung daran, den gesamten Pfad zu prüfen und nicht nur das Modell-Artefakt.
Was noch offen ist: das RunPod-Batch-Overlay für Kunden auf diesem Pfad und der Ausbau der Index-Stichprobe für elektronische Kataloge auf eine Größe, die tatsächlich die Veröffentlichung einer Zahl erlaubt, statt eine zurückzuhalten.
ArtifactNet-Forschungsteam · Juli 2026
Lade eine beliebige Datei hoch — dieselbe forensische Pipeline, die in dieser Serie beschrieben wird.