Die erste stabile Version von Googles Open-Source-Werkzeugs Magika zur KI-gestützten Dateityp-Erkennung liegt vor. Die Anwendung wurde für Version 1.0 in Rust neu entwickelt und unterstützt mehr als 200 verschiedene Dateitypen – doppelt so viele wie in der Alpha-Version vom vergangenen Jahr.

Die Neuentwicklung in Rust sorgt laut Google für deutliche Performance-Verbesserungen. Auf einem MacBook Pro mit M4-Chip verarbeite Magika knapp 1000 Dateien pro Sekunde. Das Tool nutzt die ONNX Runtime für schnelle KI-Inferenz und Tokio für asynchrone Parallelverarbeitung. Neben dem neuen nativen Client für die Kommandozeile stehen außerdem Module für Python und TypeScript zur Verfügung.

Von Jupyter Notebooks bis WebAssembly

Die erweiterte Typerkennung deckt auch spezialisierte Formate aus verschiedenen Bereichen ab: Data-Science-Formate wie Jupyter Notebooks, NumPy-Arrays oder PyTorch-Modelle gehören ebenso dazu wie moderne Programmiersprachen (Swift, Kotlin, TypeScript, Dart, Solidity, Zig) und DevOps-Konfigurationsdateien (Dockerfiles, TOML, HashiCorp HCL). Magika kann zudem genauer zwischen ähnlichen Formaten unterscheiden – etwa zwischen JSON und JSONL oder zwischen C- und C++-Code.

Für das Training des erweiterten Modells musste Google nach eigenen Angaben zwei Herausforderungen bewältigen: Der Trainingsdatensatz wuchs auf über 3 Terabyte an, was den Einsatz der hauseigenen SedPack-Bibliothek zum effizienten Streaming erforderte. Für seltene oder spezialisierte Dateitypen, von denen nicht genügend reale Beispiele verfügbar waren, setzte das Unternehmen auf generative KI: Googles Gemini-Modell erzeugte synthetische Trainingsdaten durch Übersetzung von Code und strukturierten Dateien zwischen verschiedenen Formaten.

Magika lässt sich auf Linux, macOS und Windows einrichten. Ferner können Entwickler das Tool als Bibliothek in Python-, TypeScript- oder Rust-Projekte integrieren. Laut Google verzeichnet das Projekt seit der Alpha-Version über eine Million Downloads pro Monat.

(fo)

Mit dem Python-Paket any-llm veröffentlicht Mozilla eine einheitliche API für viele LLMs in Version 1, die bereits stabil für den produktiven Einsatz sein soll. Das entlastet Entwicklerinnen und Entwickler bei der Verwendung der Modelle, da sie nicht mehr für jedes einzelne LLM einen eigenen Adapter pflegen müssen.

Die angebundenen Modelle können in der Cloud oder lokal vorliegen und lassen sich über die asynchrone API leicht wechseln. Um die Performance zu verbessern, sind Client-Verbindungen wiederverwendbar. Das Tool liefert auch für das Reasoning eine standardisierte Ausgabe. Außerdem teilt any-llm den Anwenderinnen und Anwendern mit, wenn sich API-Modi oder -Endpunkte ändern.

Ein optionales LLM-Gateway dient dem Budget- und Key-Management und ist mandantenfähig. So kann er als LLM-Schnittstelle für Unternehmen dienen.

Die Liste der angebundenen Provider auf der GitHub-Seite ist bereits lang und umfasst Anthropic, Azure, Databricks, Deepseek, Gemini, Groq, Hugging Face, Llama, Mistral, Ollama, Perplexity, Watsonx und weitere. Zudem findet sich dort eine Tabelle, welche Funktionen any-llm jeweils unterstützt: Response, Reasoning, Image und so weiter.

Um das Tool zu nutzen, sind Python 3.11 und die jeweiligen API-Keys erforderlich, die das Tool in einer Umgebungsvariablen speichert. Geplant hat Mozilla für die nächsten Versionen eine Batch-Funktion sowie die Anbindung weiterer LLMs und zusätzlicher Bibliotheken wie den MCP-Daemon.

(who)

Willkommen zur vierzehnten Ausgabe der KI-Navigator-Kolumne der DOAG KI Community!

Geschichte wiederholt sich

Die EU-KI-Regulierung erinnert uns Physiker an eine berühmte Debatte aus der Geschichte der Wissenschaft: Ende des 19. Jahrhunderts standen sich zwei Giganten der Physik gegenüber: Ludwig Boltzmann und Ernst Mach. Der einflussreiche Positivist Mach weigerte sich, Boltzmanns statistische Mechanik zu akzeptieren. „Ham’s aans g’sehn?“ (Haben Sie eins gesehen?), rief er provokant aus dem Publikum während einer von Boltzmanns Vorlesungen über Atome. Doch Boltzmann zeigte: Auch wenn jedes einzelne Molekül real ist und chaotisch wirkt, entstehen makroskopische Eigenschaften wie Temperatur und Druck aus statistischen Gesetzmäßigkeiten – ohne dass wir jeden einzelnen Molekülstoß verfolgen müssen.

Die EU verlangt von KI-Systemen eine transparente Nachvollziehbarkeit – aber was heißt das konkret? Es geht nicht darum, die Berechnung jedes einzelnen Tokens offenzulegen, sondern die Regulierung fordert, dass wir die Ergebnisse von KI-Systemen nachvollziehen und interpretieren können – so wie ein Physiker nicht die Bahn jedes einzelnen Gasmoleküls kennt, aber über Druck, Temperatur und Volumen das Verhalten des Gases zuverlässig beschreiben und steuern kann. Nicht mikroskopische Durchleuchtung, sondern makroskopisches Verständnis und Kontrolle sind das Ziel.

Die historische Parallele ist verblüffend: Damals wie heute geht es um dieselbe methodische Einsicht. In der Thermodynamik lehrt Boltzmann, dass man komplexe Systeme durch emergente statistische Eigenschaften verstehen und ihr Verhalten kontrollieren kann, ohne jeden Einzelprozess zu verfolgen. Bei der KI müssen wir ebenso akzeptieren, dass wir nicht jeden einzelnen Verarbeitungsschritt erklären müssen, sondern das Gesamtverhalten eines KI-Systems anhand der statistischen Gesetzmäßigkeiten und emergenten Eigenschaften überwachen und kontrollieren können.

LLMs verstehen: Von der Theorie zur Praxis

Die Kernfrage ist: Wie schaffen wir Vertrauen in Systeme, deren inneres Verhalten wir nicht vollständig verstehen und kontrollieren können? Dabei liegt die Antwort nicht in der unmöglichen Aufgabe, jeden Schritt zu erklären, sondern in der intelligenten Überwachung des Gesamtsystems – genau wie bei einem Motor, wo wir nicht jede Molekülbewegung im Brennraum verfolgen, aber sehr wohl die kritischen Parameter überwachen. Die Lösung liegt nicht in der Rückkehr zu deterministischen Ansätzen, sondern in der Entwicklung neuer Methoden für die Überwachung probabilistischer KI-Systeme.

Large Language Models (LLMs) sind probabilistische Systeme, deren Ausgabe nie deterministisch ist. LLMs verhalten sich wie ein komplexes Gas aus vielen Teilchen: Einzelne Token sind unvorhersehbar, aber das Gesamtverhalten lässt sich durch makroskopische Größen beschreiben und kontrollieren.

Die Kontrollgrößen der KI

Statt jeden einzelnen Schritt zu prüfen, überwachen moderne KI-Systeme makroskopische Metriken:

• Lösungsqualität: Wie gut löst das System die anvertrauten Aufgaben faktisch korrekt und relevant über Zeit und Anwendungsbereiche?
• Zuverlässigkeit: Wie konsistent sind die Antworten bei wiederholter Ausführung und unter gleichen Bedingungen?
• Durchsatz: Wie viele Aufgaben kann das System pro Zeiteinheit bearbeiten?
• Effizienz: Wie viel Rechenleistung und Kosten verursacht das System für nützliche Ergebnisse?
• Quellentreue (Faithfulness): Wie treu bleibt die generierte Antwort den bereitgestellten Quelldokumenten, ohne unbelegte Informationen hinzuzufügen?

Diese exemplarischen Metriken erklären nicht jeden einzelnen Prozess, geben aber ein klares Bild vom Gesamtzustand des Systems. Zusätzliche Metriken lassen sich je nach Anwendungsfall heranziehen, etwa Fairness bei verschiedenen Nutzergruppen, Latenz bei Echtzeitanwendungen oder Robustheit gegen Angriffe bei sicherheitskritischen Systemen.

Messung makroskopischer Metriken in der Praxis

In der Praxis werden makroskopische KI-Metriken durch eine Kombination bewährter Methoden erfasst, die drei zentrale Säulen umfassen:

• stichprobenartige Bewertung mit menschlichen Experten
• LLM-as-a-Judge
• Distributed Tracing

Stichprobenartige Bewertung mit menschlichen Experten: Statt jeden einzelnen Output zu prüfen, bewerten Fachexpertinnen und -experten repräsentative Stichproben in Testsystemen. Moderne Plattformen wie LangSmith oder Langfuse bieten Annotation Queues – strukturierte Warteschlangen, in denen Experten systematisch KI-Ausgaben nach vordefinierten Kriterien bewerten können. Diese Bewertungen schaffen Referenzdatensätze, um automatische Systeme zu kalibrieren.

LLM-as-a-Judge: skalierbare automatische Bewertung. Bei dieser Methode werden vordefinierte Testszenarien mit bekannten Sollergebnissen (Ground Truth) durch das zu testende System verarbeitet. Ein KI-System in der Richterrolle vergleicht dann die tatsächlichen Ausgaben mit den erwarteten Ergebnissen anhand festgelegter Bewertungskriterien wie Faktentreue und Relevanz. Dies ermöglicht eine konsistente und skalierbare Bewertung großer Datenmengen. Entscheidend ist die sorgfältige Auswahl und kontinuierliche Verfeinerung der Judge-Szenarien.

Distributed Tracing: Systemverhalten sichtbar machen. Moderne KI-Systeme nutzen OpenTelemetry und ähnliche Frameworks für Distributed Tracing. Wie ein Thermometer die Temperatur misst, ohne jedes Molekül zu erfassen, tracken diese Systeme Anfragen durch komplexe KI-Pipelines und sammeln dabei makroskopische Metriken wie Latenz, Durchsatz, Fehlerrate und Ressourcenverbrauch. Sie erfassen jeden Schritt im KI-System – vom Prompt über die Toolauswahl bis hin zur Modellausführung und Antwort – als „Span“ und verknüpfen sie zu einem „Trace“.

Dabei gilt die Unterscheidung zwischen Test- und Produktivsystem: Ein Mensch könnte im Prinzip jeden Pfad nachvollziehen, den ein KI-System genommen hat – das ist jedoch in Produktivsystemen weder praktikabel noch erwünscht. Aus Kostengründen wäre die manuelle Prüfung von Millionen von Traces unwirtschaftlich, und aus Datenschutzgründen ist es verboten, persönliche Nutzerdaten in den Traces für manuelle Inspektion zu speichern.

Stattdessen werden diese Trace-Daten automatisch zu makroskopischen Kennzahlen aggregiert: durchschnittliche Antwortzeiten, Fehlerquoten pro Zeitraum oder Ressourcenverbrauch nach Systemkomponenten. KI-Monitoring konzentriert sich auf datenschutzkonforme Aggregatdaten statt auf individuelle Nutzerinteraktionen.

Die drei Methoden ergänzen einander: Menschliche Bewertungen schaffen den Sollzustand während der Entwicklung in kontrollierten Testsystemen, LLM-Judges stellen sicher, dass die Qualität mit der Zeit nicht schlechter wird und Tracing-Systeme überwachen das laufende Systemverhalten in Produktivsystemen.

Differenzierte Sicht auf Regulierung

Das globale Regulierungsumfeld für KI zeigt klare prinzipielle Unterschiede zwischen den Regionen. Während die EU im Rahmen des ersten weltweiten KI-Gesetzes (EU AI Act Regulation) auf explizite Erklärbarkeit setzt, bevorzugen die USA, Australien, aber auch internationale Standards, System-Level Assurance – einen Ansatz, der makroskopische Metriken über mikroskopische Erklärbarkeit stellt und die Erklärung emergenter Eigenschaften des Gesamtsystems ohne detaillierte Kenntnis einzelner Entscheidungen zum Ziel hat.

Makroskopische Metriken für stochastische KI-Systeme sind technisch umsetzbar und bewährt. Beispiele hierfür sind durch die Standards und Methoden wie Assurance of AI-Enabled Systems und Artificial Intelligence Risk Management Framework (AI RMF 1.0) gegeben und zeigen insbesondere, dass System-Level Assurance auch im Bereich von KI-Systemen funktioniert.

Der EU-Weg ist technisch herausfordernder, aber nicht unmöglich, solange keine lückenlose mathematische Erklärung aller mikroskopischen Entscheidungen vorliegen muss – er erfordert jedoch andere technische Lösungen, die über makroskopische Metriken hinausgehen und möglicherweise höhere Entwicklungskosten zur Folge haben. Insbesondere lässt der EU-Weg aber auch viel Interpretationsspielraum für die Bedeutung einer transparenten und erklärbaren KI zu.

Darüber hinaus ist davon auszugehen, dass eine zweifelsfreie Klassifizierung eines KI-Systems als Hochrisiko-System (EU AI Act Art. 6) in der Praxis oft auf Schwierigkeiten stoßen wird. Folglich könnte die EU-Regulierung Innovation behindern oder zu alternativen technischen Entwicklungspfaden führen, in denen der KI-Einsatz im Bereich von Hochrisiko-Systemen auf grundlegende klassische ML-Verfahren beschränkt bleibt und somit die Erklärbarkeit von rückgekoppelten, nicht-linearen und tiefen neuronalen Netzen vermieden wird.

Hier ist davon auszugehen, dass sich solch eine Entwicklung zu einem enormen Wettbewerbsnachteil bspw. im Energiesektor entwickeln wird, der längerfristig in einer wiederholten Abhängigkeit von den führenden Tech-Giganten, vorwiegend aus den USA, resultieren wird, wie wir es auch schon im Bereich des Cloud-Computing erlebt haben.

Der Paradigmenwechsel: Von Code zu Systemen

Der Übergang von traditioneller zur AI-First-Entwicklung greift tiefer, als neue Tools einzuführen. In der traditionellen Entwicklung schreiben Developer den Code, führen manuelle Code-Reviews durch und pflegen separate Dokumentationen. AI-First-Entwicklung hingegen basiert auf natürlicher Sprache, automatisierten Abnahmetests, Everything-as-Code (inklusive Dokumentation) und autonomer Fehlerbehebung.

Die zentrale Frage lautet: Wie baut man Vertrauen in autonome KI-Systeme auf, damit sie sicher autonom arbeiten können? Die Antwort liegt in Quality Gates und makroskopischen Metriken, die emergente Eigenschaften des Gesamtsystems messen. Autonome Fehlererkennung und ausgeklügelte Quality Gates helfen dem KI-System, Fehler zu identifizieren und zu beheben.

Developer entwickeln sich zu KI-Kuratoren – eine zukunftsweisende Rolle, die weit über traditionelle Programmierung hinausgeht. Statt Code Zeile für Zeile zu schreiben, orchestrieren KI-Kuratoren intelligente Systeme: Sie definieren Architektur, etablieren Qualitätsstandards und schaffen adaptive Frameworks, während KI-Systeme die eigentliche Codegenerierung übernehmen.

KI-Kuratoren befähigen ihre Systeme zur selbstständigen Weiterentwicklung: Sie implementieren Lernmechanismen, die es dem System ermöglichen, aus Fehlern zu lernen, neue Technologien zu integrieren, sich an veränderte Anforderungen anzupassen und eigenständig Fähigkeiten zu erweitern. Durch kontinuierliche Validierung und strategische Führung entstehen Systeme, die nicht nur funktionieren, sondern sich proaktiv verbessern und mit dem Puls der Zeit entwickeln.

Als Beispiel für AI-First-Arbeitsweise: Das Recruiting-Startup Mercor erzielte mit 30 Mitarbeitern 100 Millionen US-Dollar jährliche Umsatzrate. Dieses technologienahe Startup ist ein Sonderfall und als AI-natives Unternehmen besonders früh dran – das Beispiel illustriert jedoch, in welche Richtung sich Automatisierungsgrade entwickeln könnten, auch wenn solche Ergebnisse noch nicht branchenübergreifend Standard sind.