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.

Kaum ein Softwareproblem ist so alltäglich und gleichzeitig so kostspielig wie Null-Referenzen. Sie gehören zu den am häufigsten auftretenden Ursachen für Systemabstürze, undefinierte Zustände und Sicherheitslücken. Jede Entwicklerin und jeder Entwickler hat schon einmal eine Fehlermeldung wie „NullPointerException“, „Object reference not set to an instance of an object“ oder „Segmentation fault“ gesehen.

Muster 7: Null-Referenzen und leere Werte: Der „Billion-Dollar Mistake“

Tony Hoare, einer der Väter moderner Programmiersprachen, bezeichnete die Einführung der Null-Referenz in den 1960er-Jahren später als seinen Billion-Dollar Mistake. 1965 entwickelte er die Programmiersprache ALGOL W, und um sie flexibler zu machen, erlaubte er Referenzen, die entweder auf ein Objekt zeigen oder „nichts“ bedeuten konnten. Damals erschien das praktisch: Man sparte sich komplexere Typ-Konstrukte und konnte einfach prüfen, ob ein Wert „da“ war.

Was Hoare damals nicht ahnte: Diese scheinbar harmlose Entscheidung würde in den folgenden Jahrzehnten unzählige Fehler, Sicherheitsprobleme und wirtschaftliche Schäden verursachen. Denn Null-Referenzen führen in der Praxis zu zwei typischen Mustern:

1. Fehler treten spät auf – oft erst zur Laufzeit, manchmal unter seltenen Bedingungen.
2. Die Ursache ist häufig schwer zurückzuverfolgen, weil der Nullwert meist weit entfernt von der eigentlichen Nutzung entsteht.

Im Alltag äußern sich Null-Fehler als sporadische Abstürze oder fehlerhafte Funktionen. In Unternehmenssystemen kann das bedeuten, dass einzelne Transaktionen fehlschlagen oder Daten inkonsistent werden. In kritischen Systemen können Null-Referenzen besonders ernste Folgen haben:

• Sicherheitslücken: Fehlende Null-Checks führen manchmal zu Zugriffen auf Speicherbereiche, die Angreifer ausnutzen können.
• Betriebsunterbrechungen: Webserver oder Microservices stürzen ab, weil ein Feld unerwartet null ist.
• Kaskadierende Effekte: In verteilten Systemen kann ein einziger Null-Fehler einen Dominoeffekt auslösen, wenn zum Beispiel Message Queues oder API-Aufrufe blockieren.

Besonders gefährlich sind dabei stille Null-Fehler: Wenn der Code versucht, auf ein Objekt zuzugreifen, das null ist, und die Sprache diesen Zugriff einfach ignoriert oder einen Standardwert liefert. Das kann zu Datenkorruption führen, die unter Umständen lange unentdeckt bleibt.

Die moderne Softwareentwicklung hat aus diesem Fehler gelernt. Statt überall Null-Checks zu schreiben, gilt heute:

1. Non-Null-by-Default: Viele moderne Sprachen wie Kotlin, Swift oder TypeScript setzen mit strictNullChecks den Standard auf „nicht null“. Ein Wert muss explizit als optional deklariert werden, wenn er fehlen kann.
2. Option- oder Maybe-Typen: Statt null zu verwenden, geben Funktionen zum Beispiel Option oder Maybe zurück. Der Compiler zwingt dann dazu, den Fall „kein Wert vorhanden“ explizit zu behandeln.
3. Invarianten im Konstruktor erzwingen: Objekte sollten niemals in einem halbinitialisierten Zustand existieren. Pflichtfelder werden direkt beim Erzeugen gesetzt und bleiben während der gesamten Lebensdauer gültig.
4. Explizite Domänenrepräsentation von „nicht vorhanden“: Statt einfach null zu verwenden, sollte das Fehlen eines Wertes in der Domäne abgebildet werden, zum Beispiel als NotApplicable, Unknown oder Empty.
5. Statische Analyse und Linter nutzen: Werkzeuge wie SonarQube, ESLint oder FindBugs erkennen viele Null-Risiken schon vor dem Build.

Null-Referenzen sind jedoch nicht nur ein technisches Problem, sondern auch ein mentales Muster: Sie sind oftmals der schnelle Ausweg, um etwas provisorisch zu lösen. Doch jede Null ist ein schwebender Systemzustand, der sich potenziell erst Monate später rächt. Teams, die diese Einstellung verinnerlichen, reduzieren Null-Fehler drastisch.

Tony Hoares Billion-Dollar Mistake erinnert daran, dass Designentscheidungen langfristige Kosten verursachen. Wer heute neue Software entwickelt, sollte Null-Werte konsequent vermeiden, wo immer es geht. Explizite Typen, Compiler-Checks und klare Domänenmodelle verhindern nicht nur sporadische Abstürze, sondern auch teure und schwer zu diagnostizierende Betriebsfehler.

(who)