KRÖTZSCHKI-Blog · Ohne Bullshit
Newsletter

Suchergebnisse für: „Benchmark“

  • Ubers ADR: Ein Sicherheitssystem für KI-Agenten, das auf Observability und Benchmarks setzt

    Ubers ADR: Ein Sicherheitssystem für KI-Agenten, das auf Observability und Benchmarks setzt

    In einem Entwicklerteam läuft ein KI-Agent in der Entwicklungsumgebung mit. Er liest Quellcode, ruft interne APIs auf, führt Befehle in der Shell aus. Im Sicherheitsteam sieht niemand, was davon im Einzelnen passiert. Genau in dieser Situation stecken Unternehmen heute, wenn sie Agenten wie Cursor, Claude Code oder Codex an ihre Mitarbeiter ausgeben. Diese Agenten handeln autonom, haben Zugriff auf Code, interne Systeme und APIs – und sie tun es nicht immer so, wie es erwartet wird. Prompt-Injection, unkontrollierte Aktionen, Missbrauch von Tools: Es gibt viele Wege, wie ein Agent Schaden anrichten kann, bewusst oder unbewusst.

    Uber hat das erkannt und eine Lösung entwickelt. Sie heißt ADR – Agentic AI Detection and Response – und ist ein Sicherheitssystem speziell für KI-Agenten. ADR ist Open Source, unter Apache-Lizenz auf GitHub veröffentlicht, und läuft bei Uber bereits in Produktion. Das zugrunde liegende Paper wurde zur MLSys 2026 angenommen. In diesem Blogpost schauen wir uns an, was ADR ist, wie es funktioniert und warum es eine Blaupause für die Sicherung von KI-Agenten sein könnte – ohne Hype, aber mit Blick auf die Details.

    Warum KI-Agenten ein Sicherheitsproblem sind – und welchen Schutz sie brauchen

    Bevor wir in die technischen Details von ADR eintauchen, ein Schritt zurück: Warum sind KI-Agenten überhaupt ein Sicherheitsrisiko? Ein herkömmlicher Bot mit klar definierter Pipeline ist gut zu kontrollieren. Ein KI-Agent ist flexibel. Er interpretiert Anweisungen, trifft Entscheidungen, verwendet Tools. Das ist seine Stärke – und seine größte Schwachstelle. Der bekannteste Angriffsvektor ist die Prompt-Injection: Ein Angreifer schleust bösartige Anweisungen in den Kontext des Agents ein, zum Beispiel über eine manipulierte Webseite, eine E-Mail oder eine Datei. Der Agent folgt dann nicht mehr den Absichten des Nutzers, sondern denen des Angreifers – und führt möglicherweise Aktionen aus, die der Nutzer nie autorisiert hat.

    Dazu kommt unkontrollierte Tool-Nutzung: Ein Agent mit Zugriff auf Shell, Code-Repos oder interne APIs kann versehentlich Daten löschen, unerwünschte Änderungen committen oder sensible Informationen nach außen tragen. In einem Enterprise-Umfeld sind die Konsequenzen schwerwiegend: Datenverlust, Compliance-Verstöße, Reputationsschäden. Deshalb braucht es ein Sicherheitssystem, das nicht auf eine einzige Maßnahme setzt, sondern einen Rundum-Schutz bietet. ADR verfolgt genau diesen Ansatz. Es beobachtet, testet, erkennt und verhindert – vier Fähigkeiten, die zusammen ein Sicherheitsnetz bilden. Man kann sich das wie ein modernes Gebäude mit Sicherheitspersonal vorstellen: Kameras beobachten das Geschehen (Observability), regelmäßige Sicherheitsübungen testen die Verteidigung (Benchmark), Alarme melden Vorfälle (Detection), und automatische Schlösser verhindern, dass jemand in den falschen Bereich gelangt (Prevention).

    ADR Observability: Was Agenten wirklich tun, lückenlos beobachten

    Der erste Baustein von ADR ist die Observability – die Fähigkeit, das Verhalten von KI-Agenten detailliert zu erfassen. Das ist die Grundlage für alles Weitere: Nur wer weiß, was ein Agent tut und warum, kann verdächtige Aktivitäten erkennen. ADR Observability, umgesetzt als ADR Sensor, sammelt Telemetriedaten von Agenten in Echtzeit. Dazu gehören die Absicht des Agents (was will er erreichen?), die Tool-Nutzung (welche Befehle führt er aus?) und die Ausführungsspuren (wie ist er vorgegangen?). Diese Daten werden über ein einheitliches Schema normalisiert, sodass sie für die Analyse weiterverwendet werden können.

    Die Abdeckung ist breit: ADR unterstützt mehr als sieben KI-Codierungswerkzeuge auf macOS, Linux und Windows – darunter Cursor, Claude Code und Codex. Aber auch interne Automatisierungen und kundenorientierte Support-Agenten werden erfasst. Das ist wichtig, denn in einem Unternehmen laufen nicht nur sichtbare KI-Agenten, sondern auch unsichtbare im Hintergrund. Der Sensor ist weniger invasiv als ein klassisches EDR (Endpoint Detection and Response), weil er sich auf die Agentenschicht konzentriert und nicht das gesamte System überwacht. Er liefert die Rohdaten für die Detection- und Prevention-Komponente.

    Warum ist diese Beobachtung so entscheidend? Sie macht die Intention sichtbar. Ein Agent, der plötzlich eine Datenbank lesen will, obwohl seine Aufgabe darin besteht, eine E-Mail zu formulieren, fällt sofort auf. Ohne Observability bliebe das im Dunkeln. ADR setzt hier auf eine Art Blackbox-Flugschreiber für KI-Agenten – nur eben nicht für Flugzeuge, sondern für die digitalen Assistenten von morgen.

    ADR-Bench: Angriffsszenarien unter realistischen Bedingungen testen

    Beobachten allein reicht nicht. Man muss auch wissen, ob erkannte Anomalien wirklich gefährlich sind. Dafür hat ADR einen eigenen Benchmark entwickelt: ADR-Bench. Er besteht aus mehr als 300 Aufgaben, die über 133 MCP-Server (Model Context Protocol) laufen. MCP ist ein offenes Protokoll, das KI-Agenten mit externen Tools und Datenquellen verbindet – genau die Schnittstellen, die in der Praxis angegriffen werden. Der Benchmark deckt alle 17 Agent-Angriffstechniken ab, die heute bekannt sind. Dazu gehören klassische Prompt-Injections, aber auch Data-Exfiltration-Versuche, Manipulation von Tool-Ausgaben und mehr.

    Was ADR-Bench besonders macht, ist sein Fokus auf Realitätsnähe. Statt einfacher synthetischer Beispiele nutzen die Entwickler Szenarien, die typische Unternehmensabläufe abbilden. Jede Aufgabe simuliert einen konkreten Arbeitsprozess – etwa das Zusammenfassen von E-Mails, das Bearbeiten von Code oder die Interaktion mit einer Datenbank – und hat zusätzlich eine Sicherheitsbedrohung eingebaut. In der Bewertung wird gemessen, ob ein Detektor die Bedrohung erkennt und das richtige Verhalten des Agents erzwingt. Es geht also nicht nur um die Frage „Wurde angegriffen?“, sondern auch um „Konnte der Angriff verhindert werden?“. Das misst praktische Wirksamkeit, nicht nur Klassifikation.

    Für die Forschung ist der Benchmark ebenfalls nützlich: Er liefert eine reproduzierbare Umgebung, um verschiedene Detektoren zu vergleichen. ADR selbst wird mit anderen Methoden als Baseline getestet – zum Beispiel mit LLM-basierten Firewalls. Die Ergebnisse zeigen, wo die Stärken und Schwächen unterschiedlicher Ansätze liegen. Unternehmen, die ihr eigenes Agent-Security-Tooling evaluieren, finden in ADR-Bench einen Maßstab – einen Prüfstand für die Sicherheit ihrer KI-Werkzeuge.

    ADR Detection und Prevention: Schnelle Erkennung, gezielte Abwehr

    Observability und Benchmark sind das Fundament. Die eigentliche Verteidigung übernimmt die Detection-Komponente, die in ADR zweistufig aufgebaut ist. Stufe eins ist eine schnelle, hoch-recall Triage: Sie filtert alle beobachteten Aktivitäten nach auffälligen Mustern, ähnlich wie ein Feueralarm, der bei Rauchentwicklung sofort anschlägt. Diese erste Stufe ist bewusst schnell gehalten, damit keine kritischen Ereignisse übersehen werden. Allerdings produziert sie Fehlalarme. Deshalb folgt Stufe zwei: eine tiefere Analyse mit agentischem Reasoning. Hier wird jeder verdächtige Fall genauer unter die Lupe genommen – der Detektor selbst nutzt KI, um zu verstehen, ob eine Aktion wirklich schädlich ist oder ob es sich um eine harmlose Fehlinterpretation handelt.

    Diese Architektur hat einen Vorteil: Sie skaliert. Nicht jede Aktion muss sofort mit der teuren, langsameren Reasoning-Engine geprüft werden, sondern nur die, die in der ersten Stufe auffallen. Dadurch bleibt die Latenz niedrig, und die Fehlalarmrate sinkt deutlich. In Benchmarks schneidet ADR in vielen Fällen besser ab als einfache LLM-Firewalls, weil es nicht nur auf Oberflächenmerkmale schaut, sondern den Kontext versteht.

    Die vierte Komponente – Prevention – ist in der aktuellen Open-Source-Version nicht enthalten. Sie ist als proaktiver Schutz geplant: nicht nur erkennen, sondern unsichere Aktionen im Vorfeld verhindern. Dafür bräuchte es Mechanismen, die direkt in den Agentenfluss eingreifen, also etwa Tool-Aufrufe blockieren oder eine Freigabe durch einen Menschen erfordern. ADR Prevention ist der logische nächste Schritt, und vermutlich veröffentlicht Uber diese Komponente erst nach weiterer Erprobung. Wer ein vollständiges System sucht, das Angriffe aktiv unterbindet, muss sich noch gedulden.

    ADR in der Praxis: Open Source, Reproduzierbarkeit, Grenzen

    ADR ist kein theoretisches Konstrukt – es ist bei Uber in Produktion. Das gibt dem Projekt Glaubwürdigkeit. Uber arbeitet mit riesigen Datenmengen und hochsensitiven Systemen. Dass der Betreiber eines globalen Mobilitätsdienstes sein eigenes Sicherheitswerkzeug für KI-Agenten entwickelt und bereitstellt, zeigt, wie ernst das Problem genommen wird. ADR ist Open Source unter Apache 2.0. Jede Organisation kann den Code herunterladen, anpassen und in die eigene Infrastruktur integrieren. Die Reproduzierbarkeit wird durch eine detaillierte Anleitung im docs/REPRODUCIBILITY.md unterstützt – ein Schritt-für-Schritt-Plan, um die Benchmark-Ergebnisse zu reproduzieren.

    Die Einschränkungen sind offen benannt. Die Permission-Komponente ist nicht enthalten, und auch der offline arbeitende ADR Explorer – ein Tool für Red Teaming vor der Auslieferung – fehlt im Open-Source-Repository. Das ist sinnvoll, denn vollständige Sicherheitstools können missbraucht werden, wenn sie in falsche Hände geraten. Was ADR liefert, ist ein solides Fundament: Sensor für Observability, Benchmark für Tests, Detektor für die Erkennung. Für den produktiven Einsatz sind weitere Integrationsarbeiten nötig, insbesondere beim Anschluss an bestehende Security-Operation-Center. Aber die Grundlage ist da.

    Für Unternehmen heißt das: Sie müssen nicht mehr im Blindflug arbeiten, wenn sie KI-Agenten einführen. ADR gibt ihnen die Werkzeuge, um zu sehen, was Agenten tun, Schwachstellen zu erkennen und Angriffe abzuwehren. Es ist kein Allheilmittel – kein Sicherheitssystem ist das. Aber es ist ein wichtiger Schritt in eine Zukunft, in der KI-Agenten nicht mehr als black box behandelt werden, sondern als aktive Teilnehmer mit klaren Sicherheitsprotokollen. Dass ein Unternehmen wie Uber diesen Code teilt, ist ein gutes Zeichen für die Branche.

    Am Ende bleibt eine nüchterne Erkenntnis: KI-Agenten werden kommen – sie sind schon da. Die Frage ist nicht, ob wir sie einsetzen, sondern wie wir sie sicher einsetzen. ADR zeigt, dass das möglich ist, wenn man Sicherheit von Anfang an mitdenkt. Observability schafft Transparenz. Benchmarks testen die Verteidigung. Detection erkennt Angriffe. Die Prevention muss folgen – hoffentlich bald. Bis dahin dürfen wir gespannt sein, was Uber als Nächstes veröffentlicht.

    Quelle: github.com

  • Wie misst man echte KI-Qualität in der Rechtsarbeit? Der Legora Benchmark

    Wie misst man echte KI-Qualität in der Rechtsarbeit? Der Legora Benchmark

    Du beauftragst einen KI-Assistenten mit einer Due-Diligence-Prüfung bei einer Übernahme. Du bekommst eine Antwort. Ist sie wirklich gut? Hat die KI alle relevanten Klauseln erkannt, die richtigen Schlüsse gezogen? Die Entwickler von Legora haben einen Benchmark entwickelt, der unter Bedingungen stattfindet, die ein Anwalt jeden Tag erlebt. Der Name: Legora Benchmark for Agentic Reasoning – kurz Legora BAR.

    Juristische Arbeit ist kein Multiple-Choice-Test. Es geht um Abwägungen, Interpretationen und die Fähigkeit, aus Hunderten von Dokumenten relevante Informationen zu extrahieren. Bisherige Benchmarks für KI in der Rechtsdomäne liefen in vereinfachten Umgebungen und nutzten öffentlich zugängliche Fälle. Wenn die Testfälle öffentlich sind, können KI-Labore ihre Modelle genau auf diese Fälle trainieren. Die Ergebnisse sind dann geschönt – sie zeigen, wie gut ein Modell auswendig gelernt hat, nicht wie gut es wirklich arbeiten kann. Legora geht einen anderen Weg: Der Benchmark bleibt privat. Die Fälle stammen von echten Kanzleien und werden nicht veröffentlicht. So misst man tatsächliche Fähigkeiten, nicht Trainingsdaten-Erinnerung.

    Wie genau sieht dieser Benchmark aus? Legora hat einen ganzheitlichen Ansatz gewählt. Statt nur das KI-Modell zu testen, wird das gesamte System bewertet: die Werkzeuge, die Umgebung mit Dokumenten und Vorlagen, die Formulierung der Aufgabe – und das Modell selbst. Ein Spitzenkoch braucht die richtigen Messer, Herde und Zutaten, und er muss das Rezept verstehen. Das Endergebnis wird nicht danach beurteilt, ob es essbar ist, sondern nach einer detaillierten Checkliste: Ist die Temperatur richtig? Sind die Gewürze ausbalanciert? Manche Kriterien sind wichtiger als andere. Genauso bewertet der Legora BAR die Arbeitsergebnisse.

    Die vier Komponenten des Benchmarks

    Der Legora BAR besteht aus vier Elementen. Erstens die Aufgabenbeschreibung – das, was der Anwalt dem System sagt. Sie ist präzise formuliert, zielorientiert, aber variabel wie eine echte Anweisung eines Partners an einen Associate. Zweitens der Fallordner („Matter File Room“): eine strukturierte Ablage mit allen relevanten Dokumenten, Vorlagen, Playbooks und Präzedenzfällen. Drittens das eigentliche Arbeitsergebnis von Legora – ein einzelnes Dokument, eine Sammlung von Dateien oder eine Antwort im Chat. Viertens die Bewertungskriterien, die Rubrics. Diese werden von erfahrenen Juristen erstellt und sind binär (erfüllt/nicht erfüllt), aber unterschiedlich gewichtet.

    Diese Gewichtung ist ein entscheidendes Detail. Manche KI-Benchmarks bewerten nach dem Alles-oder-Nichts-Prinzip: Entweder die Antwort erfüllt alle Kriterien oder sie fällt durch. Das ist für die Praxis unbrauchbar. Ein Associate, der eine wichtige Klausel übersieht, macht einen schwereren Fehler als einer, der ein unbedeutendes Datum falsch setzt. Legora gewichtet die Rubrics nach dem Risiko für den Mandanten. Hochgewichtete Punkte (etwa das Erkennen einer Change-of-Control-Klausel) ziehen bei Fehlen viel stärker ab als niedriggewichtete (etwa ein Formatierungsdetail). So spiegelt der Score die tatsächliche Qualität wider, wie ein Partner die Arbeit eines Associates beurteilen würde.

    Praxis statt Labor: Über 5.000 Fälle aus 28 Rechtsgebieten

    Der Benchmark basiert auf einem Korpus von über 5.000 realen Fällen aus 28 Rechtsgebieten – von M&A über IP bis zu Sanktionsrecht. Die Fälle stammen von Kanzleipartnern und Legal Engineers, die ihre Expertise und reale Fallarbeit einbringen. Die Daten werden synthetisiert oder anonymisiert, der Kern bleibt authentisch. Aus diesem Pool wurde eine Teilmenge von mehreren hundert Fällen für den BAR ausgewählt, repräsentativ für die gesamte Bandbreite. Jeder Fall ist nach Schwierigkeitsgrad eingeteilt: Kurz (einige Stunden), Mittel (ein bis drei Tage) und Lang (eine Woche oder mehr). Die Einteilung orientiert sich an der Zeit, die ein menschlicher Experte für die Arbeit bräuchte – ein vertrautes Maß für jede Kanzlei.

    Warum werden die Fälle nicht veröffentlicht? Offene Benchmarks landen früher oder später in den Trainingsdaten der nächsten Modellgeneration. Ein hoher Score sagt dann weniger über die Fähigkeit des Modells aus, mit unbekannten Situationen umzugehen, sondern mehr über die Vertrautheit mit dem Testmaterial. Legora hält die Fälle privat – jedes getestete Modell sieht die Arbeit zum ersten Mal, genau wie ein Anwalt, der einen neuen Fall übernimmt. Nur so erhält man ein ehrliches Bild. Aus Transparenzgründen hat Legora einen synthetischen Fall mit dem Partner AfterQuery veröffentlicht, der die Methodik zeigt, ohne die echten Fälle preiszugeben.

    Die Bewertungsmethode: LLM-as-a-Judge mit gewichteten Rubrics

    Jeder Fall wird dreimal hintereinander in einer isolierten Sandbox-Umgebung ausgeführt, um statistische Schwankungen abzufangen. Die Ergebnisse werden von einem LLM-as-a-Judge bewertet, der die Ausgabe mit den Rubrics vergleicht. Ein Jurist erstellt eine Checkliste mit den Muss-Kriterien für eine perfekte Antwort. Der KI-Judge prüft automatisch, ob jedes Kriterium erfüllt ist, und berechnet einen gewichteten Score. Ein Beispiel: Wird jede wesentliche Change-of-Control-Klausel identifiziert? Hochgewichtet, 1 Punkt. Werden Kündigungsrechte korrekt markiert? Hoch. Wird die kommerzielle Auswirkung der Risiken erklärt? Mittel. Fehlt eine unwesentliche Fristangabe? Niedrig. So erhält man einen differenzierten Qualitätswert, der mehr aussagt als ein einfaches Bestanden/Durchgefallen.

    Der Benchmark läuft kontinuierlich. Jede Evaluierung liefert dem Team Hinweise, wo das System verbessert werden kann. Diese Verbesserungen fließen direkt in die Legora-Plattform. Es entsteht ein Kreislauf aus Messen, Identifizieren und Optimieren. Allein durch Optimierungen am Harness (der Infrastruktur, die das Modell mit Werkzeugen versorgt) konnte die relative Ausgabequalität innerhalb eines Monats um 5 Prozent gesteigert werden – mit denselben Modellen.

    Ergebnisse: Wo die Modelle sich wirklich unterscheiden

    Im Benchmark wurden mehrere Modelle von Anthropic, OpenAI und xAI (Grok) getestet. Bei kurzen, begrenzten Aufgaben arbeiten alle Modelle auf ähnlichem Niveau. Der Unterschied zeigt sich bei längeren, komplexeren Fällen, die mehrere Tage oder Wochen dauern. Hier müssen die Modelle über einen großen Bestand an Dokumenten hinweg konsistentes Urteilsvermögen zeigen. In diesen anspruchsvollen Szenarien stechen Modelle wie Fable 5, Grok 4.5, Opus 4.8 und Sonnet 5 hervor.

    Auch der Trade-off zwischen Qualität und Kosten beziehungsweise Latenz wurde untersucht. Grok 4.5 punktet mit der niedrigsten Bearbeitungszeit pro Fall bei hoher Qualität. Opus 4.8 und Sonnet 5 bieten ebenfalls ein gutes Verhältnis von Kosten und Leistung. Der Benchmark ist modellagnostisch ausgelegt: Legora arbeitet mit verschiedenen Anbietern zusammen, testet neue Modelle frühzeitig und gibt Feedback, damit die Modelle besser auf die juristische Domäne zugeschnitten werden können.

    Was bedeutet das für die Praxis?

    Der Legora BAR zeigt, dass die Qualität von KI in der Rechtsarbeit nicht allein vom Modell abhängt, sondern vom gesamten System – den Werkzeugen, der Integration und der Art, wie Aufgaben formuliert werden. Für Kanzleien bedeutet das: Sie sollten nicht blind dem neuesten Modell hinterherlaufen, sondern darauf achten, wie es in ihrer Arbeitsumgebung performt. Ein Benchmark wie der BAR gibt eine verlässliche Entscheidungsgrundlage. Er misst die Qualität der Arbeit, die ein Mandant am Ende erhält. Und er treibt die Verbesserung voran, weil jeder Test direkt in ein besseres Produkt mündet.

    Für alle, die sich mit KI-Technologie beschäftigen, ist der Ansatz von Legora ein Beispiel dafür, wie man Benchmarks seriös und praxisnah gestaltet. Kein Hype, keine geschönten Zahlen – sondern eine ehrliche Messung unter realen Bedingungen. Das ist der Standard, den wir in Zukunft von KI-Anbietern erwarten sollten, nicht nur im juristischen Bereich, sondern überall, wo Maschinen für uns denken und arbeiten.

    Quelle: legora.com

  • Pelicanmaxxing – Optimieren KI-Labore heimlich auf Benchmarks?

    Pelicanmaxxing – Optimieren KI-Labore heimlich auf Benchmarks?

    Stell dir vor, du bewertest ein Restaurant immer nur nach einem einzigen Gericht: der Pizza Margherita. Das Restaurant weiss das, und plötzlich schmeckt die Margherita sehr gut – aber die Spaghetti Carbonara sind eine Katastrophe. Die KI-Forschung untersucht dieses Phänomen unter dem Namen pelicanmaxxing. Ein harmloser Scherz-Benchmark ist zum inoffiziellen Standard geworden. Die Frage: Trainieren die grossen KI-Labore ihre Modelle gezielt darauf, in diesem Test gut abzuschneiden?

    Der Entwickler und Blogger Dylan Castillo hat sich dieser Frage mit einer systematischen Studie angenommen. Was wie eine Spielerei klingt, ist ernsthafte methodische Arbeit. Denn wenn viel Geld auf dem Spiel steht und ein positiver Benchmark-Eintrag überzeugt, wäre die Versuchung gross, das Modell genau auf diesen einen Prompt zu optimieren. Castillo wollte wissen, ob die Labore dieser Versuchung erlegen sind.

    Die Geburt eines inoffiziellen Benchmarks

    Seit einigen Jahren testet der Entwickler Simon Willison jedes grössere Sprachmodell mit dem gleichen Prompt: „Generiere ein SVG eines Pelikans, der Fahrrad fährt.“ Was als simpler Spass begann, wurde zu einem der bekanntesten inoffiziellen Benchmarks. Willisons Ergebnisse werden auf Hacker News oft zu den meistgewählten Kommentaren bei Neuveröffentlichungen. Der Benchmark ist so prominent, dass Fachleute diskutieren, ob die Labore heimlich darauf trainieren – pelicanmaxxen.

    Was bedeutet pelicanmaxxing? Der Begriff lehnt sich an „benchmaxxing“ an: eine Praxis, Modelle gezielt auf Benchmark-Aufgaben zu optimieren, statt allgemeine Fähigkeiten zu verbessern. Konkret: Labore geben Modellen extra Trainingsdaten mit Pelikanen auf Fahrrädern, damit sie im Test gut abschneiden – selbst wenn die allgemeine Bildgenerierung leidet.

    Die Methodik: Ein Raster aus 48 Prompts

    Castillo ging das Problem systematisch an. Er baute ein Raster aus acht Tieren und sechs Fahrzeugen auf, also insgesamt 48 verschiedene Prompts. Das ursprüngliche „Pelikan auf Fahrrad“ war nur eine Zelle in diesem Raster. Die Tiere wählte er nach Nähe zum Pelikan: Flamingo und Reiher sind ähnlich, Otter und Waschbär einfach, Antilope schwierig, Wal extrem anders. Bei den Fahrzeugen kamen neben Fahrrad noch Einrad, Skateboard, Roller, Flugzeug und Boot zum Einsatz.

    Mit diesem Raster testete Castillo sieben Modelle über die Plattform OpenRouter: GPT-5.6 Terra, Claude Sonnet 5, Gemini 3.5 Flash, Grok 4.5, Qwen3.7-Max, GLM-5.2 und DeepSeek V4 Pro. Pro Prompt generierte er drei SVG-Bilder bei einer Temperatur von 1.0 – insgesamt 1.008 Grafiken. Jedes Bild durchlief eine dreistufige Analyse: Zuerst Rendern des SVG (bei Fehlern bis zu drei Neugenerierungen). Dann bewertete ein KI-Judge Tierdarstellung, Fahrzeugdarstellung und Handlungskohärenz (Skala 1-5). Ein weiteres Modell extrahierte Merkmale wie erkanntes Tier, Fahrzeug und Bildelemente.

    Die Ergebnisse: Fünf Indizien gegen Pelicanmaxxing

    Die Studie liefert fünf Belege, dass die Labore nicht auf den Pelikan-Fahrrad-Test optimieren. Jeder für sich ist nicht zwingend, zusammen ergeben sie ein klares Bild.

    Erstens: Pelikane werden nicht besser gezeichnet als andere Tiere. Gemittelt über alle sieben Modelle landen sie nur auf Platz sechs von acht – hinter Katzen, Walen, Waschbären, Reihern und Antilopen.

    Zweitens: Fahrräder schneiden noch schlechter ab. Unter den sechs Fahrzeugen belegen sie Platz sieben von acht. Ein gezieltes Training auf Fahrräder wäre damit kaum zu erklären.

    Drittens: Die eigentliche Kombination – Pelikan auf Fahrrad – landet auf Platz 42 von 48 möglichen Tier-Fahrzeug-Paaren. Ausgerechnet das Motiv, auf das angeblich optimiert wird, gehört also zu den schwächsten.

    Viertens: Castillo rechnete mit einer statistischen Methode (einer Fixed-Effects-Regression) die generelle Schwierigkeit jeder Kombination heraus und suchte nach einem Extra-Bonus einzelner Labore. Das Ergebnis: Bei keinem Modell gab es einen statistisch bedeutsamen Zusatz-Effekt – weder für Pelikane, noch für Fahrräder, noch für die Kombination. Den größten Ausschlag zeigte GLM-5.2 mit +0,35 Punkten, doch der liegt im Bereich des Zufalls.

    Fünftens: ein Test auf Auswendiglernen. Auffällig war zunächst, dass alle 21 Pelikan-Fahrrad-Bilder nach rechts zeigten. Doch das passt ins Gesamtbild: 81 Prozent aller Fahrräder und 78 Prozent aller Pelikane zeigen ohnehin nach rechts. Auch bei den einzelnen Bildelementen fand sich kein verdächtiges Muster, das auf antrainierte Vorlagen hindeutet.

    Grenzen der Studie

    Castillo bleibt bei seinen Schlüssen vorsichtig – zu Recht. Die Bewertung übernahm nur ein einziges KI-Modell als Judge, ohne Gegenprüfung durch weitere Bewerter. Außerdem kann die Studie ein anderes Szenario nicht ausschließen: das sogenannte SVGmaxxing. Damit ist gemeint, dass Labore ihre Modelle breit auf das Erzeugen von SVG-Grafiken trimmen – nicht speziell auf den Pelikan, aber auf die ganze Aufgabengattung. Und schließlich war das Budget begrenzt: drei Bilder pro Kombination, ein Judge, sieben Modelle. Für ein endgültiges Urteil bräuchte es mehr.

    Was bedeutet das?

    Die Antwort auf die Ausgangsfrage lautet: Es gibt keine Hinweise, dass die großen KI-Labore heimlich auf den Pelikan-Fahrrad-Test optimieren. Pelikane werden nicht besonders gut gezeichnet, Fahrräder auch nicht, und die Kombination erst recht nicht. Wenn überhaupt optimiert wird, dann eher breit auf SVG-Grafiken – nicht auf dieses eine Motiv.

    Für dich als Leser heißt das: Simon Willisons Pelikan bleibt ein charmanter, aber mit Vorsicht zu genießender Schnelltest. Er verrät etwas über die allgemeine Bildfähigkeit eines Modells – nicht über eine antrainierte Spezialdisziplin. Und er zeigt, wie schnell aus einem Scherz ein ernstzunehmender Maßstab wird, sobald genug Leute hinschauen.

    Quelle: dylancastillo.co

  • Jenseits des Benchmarks: Sicherheit mit KI-Geschwindigkeit

    Jenseits des Benchmarks: Sicherheit mit KI-Geschwindigkeit

    Stell dir vor, du baust ein Haus und lieferst es ab, aber die Sicherheitsprüfung kommt erst Wochen später. In der Zwischenzeit könnte jeder einsteigen. So ist es auch bei Software: Die Lücke zwischen Auslieferung und Prüfung ist ein Risiko. Bisher hatten Angreifer oft die Nase vorn, weil moderner Code riesig, vernetzt und sich täglich ändert, während Sicherheitsüberprüfungen zu festen Zeitpunkten stattfinden.

    Microsoft hat vor einigen Monaten begonnen, diese Zeitspanne zu verkürzen. Mit dem internen Projektnamen MDASH – einem multimodalen, agentenbasierten Scansystem – will das Unternehmen Sicherheitslücken automatisiert entdecken, validieren und beheben lassen. Das Ziel: KI-gestützte Erkennung in einen produktiven Verteidigungsmechanismus zu verwandeln. Das System analysiert proprietären Code von Windows, Hyper-V, Azure und Identitätssystemen. Statt sich auf ein einzelnes Modell zu verlassen, orchestriert MDASH eine Gruppe spezialisierter KI-Agenten. So können Sicherheitsteams kritische Fehler schnell und systematisch aufspüren und die menschliche Prüfung ergänzen.

    Die Ergebnisse fließen in Microsoft Defender-Workflows, wo sie neben Bedrohungsinformationen und Laufzeitsignalen priorisiert werden, sowie in GitHub- und Azure-DevOps-Pipelines, wo sie validiert und behoben werden – ein geschlossener Kreislauf. Das System belegte den Spitzenplatz in einem führenden Industriestandard. Seither hat es sich weiterentwickelt. MDASH wird jetzt aktiv von Entwicklungsteams für Windows, Azure und Identitätssysteme genutzt – als Teil echter Sicherheitsworkflows. Dieser Beitrag beschreibt die Entwicklung und die gewonnenen Erkenntnisse.

    Vom Labor in die Pipeline

    Seit dem Start wird das System von Entwicklungsteams für Windows, Azure und Identitätssysteme genutzt. Sie lassen es parallel zu bestehenden Prozessen laufen und richten es auf schwer prüfbare Oberflächen. Ziel ist es, mit KI-gestützter Analyse tiefer und früher zu prüfen, als es herkömmliche Ansätze erlauben. Die untersuchten Komponenten gehören zu den komplexesten: Windows Kernel, Hyper-V, Azure Virtualisierung und Active Directory Domain Services. Diese Komponenten erfordern tiefes Codeverständnis, das über typische Trainingsdaten hinausgeht. Ein einziger übersehener Fehler auf dieser Ebene kann überproportionale Folgen haben. Das System ersetzt nicht die Teams, sondern erweitert ihre Reichweite.

    „MDASH hilft uns, Schwachstellen in Windows mit größerer Analysetiefe zu finden als zuvor.“
    – Windows-Sicherheitsteam (Kernel, Hyper-V, Netzwerkstack)

    MDASH ist in die DevSecOps-Prozesse integriert. Es läuft parallel zu bestehenden Workflows. Validierte Funde erscheinen als Code-Scanning-Warnungen in GitHub Advanced Security, blockieren Pipelines in Azure DevOps und werden in Microsoft Defender priorisiert. Jeder Fund wird wie eine Codeänderung behandelt: mit Besitzer, Pull Request und Korrektur. Das stärkt den Entwicklungszyklus, ohne zusätzliche Werkzeuge.

    Die Entdeckungen dieses Monats

    Was ein Sicherheitssystem findet, ist sein wichtigstes Maß. Die aktuellen Patch-Tuesday-Funde umfassen Schwachstellen in Hyper-V, Windows-Kernel, Active Directory Domain Services, Remote Desktop Client, HTTP.sys, DNS-Client und DHCP-Client. Die Angriffsvektoren umfassen Remotecodeausführung, Rechteausweitung und Informationsoffenlegung. Mehrere Funde sind kritische Remotecodeausführungslücken, die manuell schwer zu finden sind. Andere zeigen subtilere Probleme wie Rechteausweitung oder Informationsoffenlegung. Alle wurden gefunden, bevor sie ausgenutzt werden konnten, in Codebereichen, die sonst viel manuelle Arbeit erfordern.

    CVE-ID Komponente Typ Ausnutzungsklasse CVSS
    CVE-2026-45607 Windows Hyper-V Out-of-bounds Read Remotecodeausführung 8.4
    CVE-2026-45641 Windows Hyper-V Type Confusion Remotecodeausführung 8.4
    CVE-2026-47652 Windows Hyper-V Heap-basierter Pufferüberlauf Remotecodeausführung 8.2
    CVE-2026-41108 Windows DNS Client Heap-basierter Pufferüberlauf Rechteausweitung 7.0
    CVE-2026-45608 Windows DHCP Client Out-of-bounds Read Informationsoffenlegung 6.8
    CVE-2026-45634 Windows DHCP Client Out-of-bounds Read Informationsoffenlegung 5.5
    CVE-2026-45648 Windows Active Directory Domain Services Stack-basierter Pufferüberlauf Remotecodeausführung 8.8
    CVE-2026-47289 Remote Desktop Client Heap-basierter Pufferüberlauf Remotecodeausführung 8.8
    CVE-2026-45657 Windows Kernel Use-after-free Remotecodeausführung 9.8
    CVE-2026-47291 HTTP.sys Integer Overflow Remotecodeausführung 9.8

    Jenseits der Schlagzeile: Was wir daraus gelernt haben

    Wie sich das System verbesserte

    Um ein System zu verbessern, muss man es messen. Mit CyberGym, einem Benchmark aus 1507 Schwachstellen, konnte das Team schnell Fortschritte messen. Seit der ersten Ankündigung wurde die Pipeline basierend auf Feedback und Tests neu aufgebaut. Die aktuelle Version erreicht 96,5 % (jeglicher Absturz) auf CyberGym, einschließlich Ziel- und Nicht-Ziel-Schwachstellen. Die größten Verbesserungen gab es in den frühen Phasen Prepare und Scan. Das hebt die Qualität aller späteren Schritte. Konkret: eine schärfere Abgrenzung zwischen zu prüfendem und Kontextcode, eine umfassendere Bedrohungsmodellierung zur Identifizierung von Einstiegspunkten, eine bessere Erkennung von Fuzz-Harnessen, ein zuverlässigerer Callgraph und ein intelligenteres Routing zu spezialisierten Agenten.

    Die verbleibenden 3,5 % verstehen

    Das System erreichte 96,55 % auf CyberGym, verfehlte aber 52 Aufgaben (3,5 %). Die Analyse zeigt, welche Pipeline-Stufe zu jedem Fehlschlag beigetragen hat: Scan-Stufe: 8 Fälle (15,4 %), Validate-Stufe: 10 Fälle (19,2 %), Prove-Stufe: 34 Fälle (65,4 %). In der Scan-Stufe traten Fehler durch ungenaue Bereichsdefinitionen aus mehrdeutigen Beschreibungen auf. Beispiel arvo:53536: „Ein Stack-basierter Pufferüberlauf tritt im Code auf, wenn ein Tag gefunden wird und die Ausgabegröße nicht überprüft wird, ob sie innerhalb der Puffergrenzen liegt.“ Das identifiziert den Typ, gibt aber kaum Hinweise, wo in einer großen Codebasis gesucht werden soll. Auch kann das System Komponenten falsch priorisieren – in arvo:23547 liegt die Schwachstelle in einer Lexer/Parser-Komponente, aber das System priorisierte andere C-Codepfade. In der Validate-Stufe wurden Funde bei hypothetischen Beschreibungen zurückgewiesen. In arvo:3569 hatte die Scan-Stufe eine Use-after-Free-Schwachstelle korrekt identifiziert, aber die Validate-Stufe sah keinen machbaren Pfad und wies sie zurück. In der Prove-Stufe stellten stark strukturierte Eingabeanforderungen ein Problem dar. Manche Ziele benötigen komplexe Binäreingaben wie IVF/AV1, WPG, Fonts, PDFs. Das System versuchte fuzzing-basierte Ansätze, die Abstürze fanden, aber keine gültigen Eingaben innerhalb der Zeitvorgaben erzeugten. In einigen Fällen wurden Abstürze lokal reproduziert, ließen sich aber nicht auf die Evaluierungsumgebung übertragen – ein Problem der Umgebungsunterschiede.

    Quelle: microsoft.com

  • DeepSeek V4.1 Flash überholt Anthropic beim agentischen Coding

    DeepSeek V4.1 Flash überholt Anthropic beim agentischen Coding

    Chinas KI-Modelle holen auf, hieß es bisher, bleiben aber bei den Aufgaben hinten, für die Unternehmen wirklich Geld ausgeben. Für das agentische Coding muss diese Einschätzung inzwischen korrigiert werden, schreibt Devin Culbertson bei TechTimes. Auf dem LiveBench-Leaderboard vom 4. Oktober führt das chinesische Modell DeepSeek V4.1 Flash die Teilkategorie agentisches Coding mit 77,3 Punkten an, vor Anthropics Claude Fable 5.1 (Max Effort) mit 66,1 Punkten. Den Abstand zwischen den besten Modellen beider Länder beziffert Bloomberg Intelligence auf rund drei Prozent, den niedrigsten bisher gemessenen Wert.

    Wer daraus schließt, die Sache sei entschieden, übersieht den zweiten Teil. DeepSeek sitzt in Hangzhou, und jede Anfrage an die Schnittstelle landet bei einem Unternehmen, das chinesischem Recht unterliegt. Dieses Recht kennt eine Pflicht zur Zusammenarbeit mit den Nachrichtendiensten, die sich nach Darstellung von TechTimes durch keine Datenschutzerklärung aushebeln lässt. Es geht also nicht nur um Leistung, sondern um eine Entscheidung an der Schnittstelle von Technik, Recht und Beschaffung. Wer heute ein Modell für Softwareautomatisierung auswählt, muss beide Seiten kennen.

    Was der LiveBench-Wert von 77,3 Punkten tatsächlich misst

    Agentisches Coding ist kein Nischenthema. Es beschreibt genau die Fähigkeit, für die Softwareteams inzwischen einen erheblichen Teil ihrer KI-Budgets ausgeben: ein komplexes Problem zerlegen, den nötigen Code schreiben, ihn in einer echten Umgebung ausführen, die Fehlermeldung lesen und den Fehler beheben – und das über mehrere Runden hinweg, ohne dass nach jedem Schritt ein Mensch eingreift. In dieser Teildisziplin erreicht DeepSeek V4.1 Flash 77,3 Punkte, das Spitzenmodell von Anthropic liegt bei 66,1. Im Gesamtindex steht DeepSeek mit 81,1 gegen 83,4 knapp dahinter; diese 2,3 Punkte entsprechen gerundet etwa drei Prozent des Anthropic-Werts.

    Die Messplattform spielt dabei eine Rolle. LiveBench ist ausdrücklich so gebaut, dass Testfragen nicht ins Trainingsmaterial der Modelle sickern und die Ergebnisse künstlich nach oben ziehen. Der Fragenkatalog wird monatlich erneuert, gespeist aus aktuellen Mathematikwettbewerben, arXiv-Vorabdrucken und Nachrichten, und bewertet wird objektiv statt durch einen KI-Richter. Eine unabhängige Übersicht vom September 2026 zählt LiveBench zu den sechs vertrauenswürdigsten Benchmarks überhaupt, merkt aber an, dass die Aufgabenmischung nur mittelmäßig gut abbildet, was in echten Produktionsumgebungen passiert. Ein Benchmark ist eine Prüfung. Er ist nicht der Arbeitsalltag.

    Warum eine 748-Milliarden-Parameter-Architektur günstig bleiben kann

    Hinter den Preisen steht eine Mixture-of-Experts-Architektur, also ein Modell, das aus vielen spezialisierten Teilnetzen besteht und pro Token nur einen kleinen Ausschnitt davon aktiviert. V4.1 Flash kommt auf insgesamt 748 Milliarden Parameter, darunter ein Kernrückgrat von 552 Milliarden und 196 Milliarden sogenannte Engram-Parameter – ein in dieser Generation neu eingeführter Baustein für dauerhaftes Gedächtnis. Entscheidend ist nicht die Gesamtzahl, sondern die sparsame Aktivierung: Der Rechenaufwand bei der Inferenz entspricht eher einem deutlich kleineren Modell, weshalb der Betrieb billiger zu haben ist als der Parameterstand vermuten lässt.

    Das schlägt sich in den Konditionen nieder. Die Preise liegen inzwischen unter denen zum Start: 0,30 US-Dollar pro Million Eingabe-Token und 1,20 US-Dollar pro Million Ausgabe-Token zur Hauptzeit, außerhalb der Spitzenlast die Hälfte davon. Hinzu kommt ein geringerer Speicherbedarf: Der Bedarf für den KV-Cache schrumpft auf etwa ein Viertel des HBM-Bedarfs der Vorgängergeneration und auf ein Achtel beim SSD-Speicher. Das senkt die Hardwarekosten beim Betrieb und verstärkt den Preisvorteil. Dazu passen ein Kontextfenster von bis zu einer Million Token, Ausgabelängen bis 384.000 Token und eine multimodale Bildverarbeitung, die dem Vorgänger fehlte.

    Wo die Messungen auseinandergehen: drei Prozent gegen acht Monate

    Die Drei-Prozent-Zahl stammt aus einer Analyse von Robert Lea, Senior Analyst bei Bloomberg Intelligence, der sich auf den LiveBench-Stand vom 4. Oktober stützt. Ausgelöst hat den Sprung laut TechTimes DeepSeeks Veröffentlichung von V4.1 Flash im September. Zum Vergleich: Im Mai 2026 lag die Lücke bei etwa neun Prozent, zu Beginn des Jahres bei rund fünfzehn. Andere Messungen kommen zu anderen Ergebnissen. Das Center for AI Standards and Innovation (CAISI) der US-Standardisierungsbehörde NIST untersuchte im Mai 2026 den Vorgänger V4 Pro mit neun vorab festgelegten Benchmarks über fünf Bereiche und schätzte den Rückstand auf etwa acht Monate Entwicklungszeit, nicht auf einen niedrigen einstelligen Prozentwert. Die vorab festgelegte Methodik soll gezielte Optimierung auf die Tests erschweren.

    Falsch ist laut TechTimes keine der beiden Zahlen. Die Analysen betrachten unterschiedliche Modelle zu unterschiedlichen Zeitpunkten mit unterschiedlichen Verfahren und messen damit Verschiedenes. Hinzu kommen die Angaben des Herstellers: In seinem technischen Bericht meldet DeepSeek für V4.1 Flash 74,2 Prozent auf dem anspruchsvollen Benchmark DeepSWE v1.1, knapp vor Anthropics Opus 5 mit 74,0 und OpenAIs GPT-5.6 Sol mit 73,0 Prozent. Hier gilt ein Vorbehalt: Bei selbst berichteten Ergebnissen besteht ein bekanntes Risiko, dass ein Modell eher auf die Tests als auf echte Fähigkeiten optimiert wurde. Eine unabhängige Prüfung speziell dieser Werte lag laut TechTimes bei Erscheinen des Artikels nicht vor.

    Artikel 7 des National Intelligence Law: die Bedingung in jeder API-Anfrage

    DeepSeek ist ein chinesisches Unternehmen. Das ist keine Randnotiz. Artikel 7 des National Intelligence Law von 2017 verlangt, dass alle Organisationen und Bürger die nachrichtendienstliche Arbeit des Staates nach Maßgabe des Gesetzes unterstützen und mit ihr zusammenarbeiten. Nach Darstellung von TechTimes verschafft das Gesetz dem Staat Zugriff auf Daten chinesischer Unternehmen, ohne dass die Anfrage öffentlich gemacht werden muss. Cybersecurity Law (2017) und Data Security Law (2021) ergänzen weitere Zugriffswege und Vorgaben zur Datenlokalisierung. Die Datenschutzerklärung eines chinesischen Unternehmens kann diese Pflichten laut dem Artikel rechtlich nicht überstimmen.

    Wer Code, Geschäftslogik oder interne Prompts an die Schnittstelle schickt, überträgt sie damit in eine Infrastruktur, die diesen Regeln unterliegt. Erschwerend kommt ein dokumentiertes Sicherheitsdefizit hinzu: Anfang 2025 fanden Forscher von Wiz eine DeepSeek-Datenbank ohne Authentifizierung, in der Chatverläufe und API-Schlüssel offenlagen. Das Unternehmen ist also einerseits rechtlich zur Weitergabe verpflichtet und hat andererseits bereits gezeigt, dass der Schutz nicht immer sitzt. Mehrere US-Behörden – darunter Navy, NASA und das Handelsministerium – haben DeepSeek Anfang 2025 auf Dienstgeräten gesperrt, auch Taiwan untersagte die Nutzung in Regierungsstellen. Eine unabhängige Prüfung, wie V4.1 Flash mit Daten umgeht, ist laut TechTimes nicht veröffentlicht. Einen Ausweg gibt es: V4.1 Flash ist ein Open-Weight-Modell, Unternehmen können die Gewichte herunterladen und auf eigener Infrastruktur betreiben. Das beseitigt das Risiko der API-Übertragung, nicht aber Fragen zur Herkunft der Trainingsdaten und zu möglichen Ansprüchen aus destillationsbasiertem Training. Und ein Mixture-of-Experts-Modell mit 748 Milliarden Parametern selbst zu betreiben, setzt erhebliche Infrastruktur voraus.

    Was DeepSeek trotzdem fehlt: Ökosystem, Breite und Profitabilität

    Ein Spitzenplatz in einer Teilkategorie sagt noch nichts über das gesamte Kräfteverhältnis. Nur drei der fünfzehn Modelle in der LiveBench-Spitzengruppe vom 4. Oktober stammen aus China; die Zugewinne bleiben also an der Front konzentriert statt über das Feld verteilt. Der zweite Abstand betrifft die Integration: API-Ökosystem, Werkzeuge, Dokumentation und Unternehmenssupport sind bei Anthropic, OpenAI und Google deutlich reifer. Teams berichten von Reibung beim Zugang, bei Supportzeiten und bei der Einbindung in bestehende Cloud-Werkzeugketten. Solche versteckten Betriebskosten tauchen in keinem Benchmark auf.

    Der dritte Punkt ist die Rentabilität. Lea rechnet damit, dass Chinas KI-Branche einschließlich DeepSeek bis 2030 unprofitabel bleiben könnte, während im Markt mehr als 1.100 konkurrierende große Sprachmodelle um Aufmerksamkeit ringen und führende Chatbots kostenlos bleiben. ByteDance‘ Doubao führt bei der Monetarisierung, DeepSeek positioniert sich eher als Infrastruktur- und Forschungsplattform. Ohne Konsolidierung und rationalere Preisbildung, so Lea, werde sich die Branche schwer auf eine tragfähige Gewinnbasis stellen lassen.

    Exportkontrollen, Ascend 950 und der Entscheidungsrahmen für Enterprise-Teams

    Die Drei-Prozent-Meldung fällt in einen Moment, in dem die US-Exportkontrollen für KI-Chips zunehmend hinterfragt werden. Die Kontrollen beruhten auf der Annahme, dass der eingeschränkte Zugang zu Nvidias Spitzenchips einen dauerhaften Hardwarevorsprung sichert. DeepSeek V4 Flash wurde für Huaweis Ascend-950-Prozessoren angepasst, einen heimischen Chip, der schwächer ist als Nvidias Spitzenhardware, aber für ein konkurrenzfähiges Frontier-Modell ausreichte. Nach dem Start von V4 im April 2026 sollen ByteDance, Tencent und Alibaba sich um Bestellungen für diesen Chip bemüht haben. Laut dem Halbleiter-Marktforschungsunternehmen Omdia stieg Chinas Selbstversorgung bei KI-Chips von unter zehn Prozent im Jahr 2020 auf 41 Prozent im Jahr 2025; im selben Zeitraum sank Nvidias Anteil am chinesischen Beschleunigermarkt deutlich. Die Investitionslücke bleibt derweil gewaltig: Der Stanford AI Index 2026 nennt für 2025 private KI-Investitionen von 285,9 Milliarden US-Dollar in den USA gegenüber 12,4 Milliarden in China. Der Abstand bei der Modellleistung hat sich aber nicht im selben Verhältnis entwickelt wie der bei den Investitionen.

    TechTimes schlägt Entwicklungsteams deshalb eine Abwägung mit vier Teilen statt einer einzigen Zahl vor. Erstens die Leistung: V4.1 Flash ist im agentischen Coding der gemessene Spitzenreiter, und diesen Maßstab hält der Artikel für Softwareteams für den wirtschaftlich relevantesten. Zweitens die Verlässlichkeit: Die Führung stammt aus einer Plattform, die gegen Kontamination ausgelegt ist, ist aber nicht gegen gezielte Optimierung immun, und unabhängige Produktionstests fehlen bislang. Drittens die rechtliche Exposition, die sich nicht wegkonfigurieren lässt, solange die API genutzt wird. Viertens das Ökosystem, das den Alltagsbetrieb trägt oder eben nicht.

    Konkret heißt das: Drei Prozent Lücke im Gesamtindex bedeuten keine Gleichwertigkeit bei der Aufgabe, die ein einzelnes Unternehmen tatsächlich fährt. Die Führung im agentischen Coding ist laut TechTimes der belastbarste Einzelbefund. Gerade beim Coding fließt allerdings Quellcode an die Schnittstelle, also genau die Art von Daten, für die die chinesischen Zugriffsregeln relevant sind. Wer heute entscheidet, sollte den Benchmark als Einstieg nehmen und die rechtliche Bedingung als Teil der Architektur behandeln, nicht als Fußnote. Selbst gehostete Gewichte lösen einen Teil des Problems. Die Herkunft der Trainingsdaten lösen sie nicht.

    Quelle: techtimes.com

Weitere Beiträge