Kategorie: Tool-Tests

Flavio Copes installiert die Coding-Anwendung ZCode auf seinem Mac. Er weist den Agenten an, das Repository seiner Website mit mehr als 1.700 Blogbeiträgen zu analysieren. Schon der erste Durchlauf liefert brauchbare Vorschläge: tote Links, ein langer Abschnitt ohne Inhaltsverzeichnis und eine uneinheitliche Zeitzone. Der Test zeigt, was ein moderner KI-Programmierassistent leistet.

ZCode stammt von Z.ai, dem internationalen Namen des chinesischen KI-Labors Zhipu AI. Das Tool bezeichnet sich selbst als Agentic Development Environment, kurz ADE. Die Idee: Du gibst ein Ziel vor, und der Agent plant die Arbeit, bearbeitet Dateien, führt Kommandos aus und kontrolliert das Ergebnis. Kein klassischer Code-Editor, sondern eine Aufgabenumgebung, die alles zusammenhalten soll.

Dieser Artikel fasst die ZCode-Erfahrungen zusammen: Technik hinter GLM-5.3, Preise, Limits und Sicherheit.

Was ist ZCode? Ein Agentic Development Environment

ZCode gibt es für macOS, Windows und Linux. Es ist kein Fork von Visual Studio Code und hat wenig mit klassischen Editoren gemeinsam. Stattdessen organisiert eine Aufgabenliste das gesamte Projekt: dein Ziel, geänderte Dateien, Terminalausgaben, Browser-Kontext und den Git-Zustand. Du kannst mehrere Aufgaben parallel starten, wiederkehrende Arbeiten planen und die Anwendung per Smartphone fernsteuern. Anders als Claude Code, das in der Terminal-Umgebung lebt, bringt ZCode eine eigene grafische Oberfläche mit.

Der Kern sind einzelne Tasks. Eine Aufgabe hält alle Informationen zusammen, die der Agent braucht. Du startest mit einer simplen Frage und arbeitest dich zu größeren Zielen vor. Für komplexe Projekte gibt es Goals: Der Agent läuft in einer Schleife aus Planen, Ausführen und Prüfen, aktualisiert dabei seinen Plan und stoppt nicht bei der ersten Antwort.

Der ZCode Coding Agent ist also kein Texteditor mit KI-Funktion, sondern ein eigenständiges Werkzeug. Das zeigt sich auch im Plugin-Marketplace, der Skills, Befehle und MCP-Server bündelt. Browser-Automatisierung, Android-Emulation, Videowerkzeuge und Dokumenten-Export sind nur einige Beispiele.

GLM-5.3: Das Modell hinter dem Agenten

ZCode ist fest auf das hauseigene Modell GLM-5.3 abgestimmt. Es wurde am 14. August 2026 veröffentlicht und basiert auf GLM-5.2 – ohne neue Vortrainingsphase. Die Verbesserungen stammen aus einer intensiven Nachbearbeitung mit längeren Engineering-Aufgaben. Das Modell bietet einen Kontext von einer Million Token, bis zu 128.000 Token Ausgabe und drei Denkstufen: low, high und max. Das Denken ist immer aktiv, du kannst es reduzieren, aber nicht abschalten. Höhere Stufen verbrauchen mehr Punkte aus deinem Abo.

Die Trainingsumgebung unterscheidet Z.ai von anderen Anbietern. GLM-5.3 erhält in simulierten Task-Umgebungen ein Ziel, Werkzeuge und eine Verifikationsmöglichkeit. Es schreibt Code, führt ihn aus und lernt aus dem Ergebnis. Manche dieser Umgebungen bilden mehrere Tage Arbeit ab. Forschungsagenten sammeln dabei echte Entwicklungsmuster und verwandeln sie in lauffähige Aufgaben. Ein weiterer Agent prüft, ob eine Aufgabe lösbar ist – ohne die Referenzlösung zu sehen. So lernt das Modell, lange Aufgaben ohne ständige Rücksprache durchzuziehen.

Die GLM-5.3 Benchmark-Ergebnisse bestätigen diesen Effekt. Im Terminal Bench 3.0 steigt die Punktzahl von 4,6 auf 28,3, im DeepSWE v1.1 von 46,2 auf 66,9. Auch in Sicherheitsfragen legt das Modell deutlich zu. Im Vergleich mit den besten geschlossenen Modellen liegt es nicht immer vorn, nutzt aber deutlich weniger Ausgabetoken. Im Code Bench erreicht GLM-5.3 bei hoher Denkstufe 31,4 Prozent mit etwa 50.000 Token pro Aufgabe; Claude Opus 4.8 kommt auf 29,5 Prozent, verbraucht aber 120.000 Token. Für Projekte mit hohem Token-Verbrauch ist das ein klarer Vorteil.

Installation, Zugang und ZCode Preise und Limits

Die Installation von ZCode ist unkompliziert. Auf einem Apple-Silicon-Mac lädst du eine DMG-Datei von zcode.z.ai herunter und ziehst die Anwendung in den Programme-Ordner. Windows-Installationsprogramme gibt es, Linux-Builds sind noch Beta. Beim ersten Start verbindest du ein Konto: Z.ai für den globalen Dienst, BigModel für das chinesische Festland oder deinen eigenen API-Schlüssel. Neue Nutzer erhalten ein fünftägiges Testangebot mit täglichen Kontingenten für GLM-5.3 und GLM-5-Turbo.

Nach dem Test brauchst du einen GLM Coding Plan. Der günstigste Tarif heißt Lite und kostet 18 Dollar im Monat. Der Pro-Tarif mit der sechsfachen Nutzungsmenge kostet 80 Dollar, der Max-Tarif mit der vierzehnfachen Menge 168 Dollar. Zum Zeitpunkt des Tests wurden alle Pläne mit 30 Prozent Rabatt angezeigt. Das Punktesystem macht die Kosten flexibel: Anrufe außerhalb der Spitzenzeiten und an Wochenenden kosten nur die Hälfte. Der API-Zugang von Z.ai funktioniert außerdem in mehr als 20 Coding-Agenten, nicht nur in ZCode.

Vor dem ersten Einsatz solltest du die Datenschutzhinweise prüfen. ZCode überträgt deine Prompts und relevanten Code-Abschnitte an die Server von Z.ai, solange du den offiziellen Plan nutzt. Z.ai ist ein chinesisches Unternehmen. Für öffentliche Projekte und persönliche Experimente ist das laut Autor unbedenklich, für vertrauliche Kundendaten kann es ein Ausschlusskriterium sein. Wer die Kontrolle behalten will, hostet die offenen Gewichte selbst – das erfordert aber ernsthafte Hardware.

Praxistest: Aufgaben, Ziele und Automatisierung

Der Autor setzte ZCode auf dem Repository seines Blogs ein. Er wählte die Berechtigungsstufe „Ask before changes“. Damit fragt der Agent vor jeder Dateiänderung nach. ZCode analysierte das Repository und hielt vor einem Shell-Kommando an. In einem Dialog ließ sich das Kommando einmalig erlauben, dauerhaft für das Projekt freigeben oder ablehnen. So gewinnst du Vertrauen, ohne dem Agenten sofort alle Freiheiten zu geben.

Die erste Aufgabe brachte vier konkrete Ergebnisse: tote Links, einen langen Textabschnitt ohne Inhaltsverzeichnis und eine Zeitzonen-Inkonsistenz. Das zeigt, dass der Agent über Codebearbeitung hinausgeht. Die Qualität der Antworten hängt stark von der Formulierung ab. Der Autor empfiehlt, pro Aufgabe ein Ziel zu setzen, mit @ auf relevante Dateien zu verweisen und klar zu sagen, wie der Erfolg gemessen wird. „Sorge dafür, dass die Tests laufen“ ist ein prüfbares Ziel – „verbessere die App“ nicht.

Für umfangreichere Arbeiten gibt es Goals. Der Agent arbeitet kontinuierlich an einem Ergebnis, plant, führt aus, prüft und korrigiert den Kurs. Darauf wurde GLM-5.3 trainiert. Auch Automatisierung und API sind nützlich: Im Bereich Automations lassen sich wiederkehrende Aufgaben einplanen, etwa ein täglicher Sicherheits-Scan oder ein Wochenrückblick. Die mitgelieferten Vorlagen zeigen, wie das funktioniert. Da Off-Peak-Aufrufe nur halb so viele Punkte kosten, lohnt sich die nächtliche Ausführung.

Sicherheit, Lizenzen und offene Gewichte

GLM-5.3 ist auffällig gut darin, Sicherheitsprobleme zu finden. Im CyberGym-Benchmark erreicht es 84,5 Prozent – der beste veröffentlichte Wert. Z.ai meldet 2.436 gefundene Schwachstellen in 269 Projekten, darunter mehr als tausend mittlere und schwere Fehler. Einige davon waren jahrzehntelang unentdeckt. Die Ergebnisse sind in einem öffentlichen Security Disclosure Ledger festgehalten. Wegen dieses Potenzials verzögerte sich die Veröffentlichung der offenen Gewichte um eine zweiwöchige Risikoprüfung.

Die Gewichte von GLM-5.3 liegen seit dem 28. August 2026 auf Hugging Face. Die Lizenz ist aber nicht mehr MIT, sondern eine eigene Lizenz. Du darfst das Modell nutzen, verändern, verteilen, verkaufen und feinjustieren. Zusätzlich gilt eine Bedingung für Hosting-Anbieter mit mehr als zehn Milliarden Dollar Jahresumsatz: Sie brauchen eine Sicherheitsfreigabe von Z.ai. Für die meisten Entwickler ändert sich nichts, aber ein Blick in die Lizenz ist Pflicht, bevor du ein Produkt darauf aufbaust.

Ganz anders ist GLM-5.3-Flash. Diese Variante erschien zwei Tage früher und bleibt unter der MIT-Lizenz. Flash ist das erste nativ multimodale Modell der GLM-5-Serie. Es kann Bilder und Screenshots auswerten, was ZCode für die visuelle Kontrolle nutzt. Das Modell hat 320 Milliarden Parameter, aktiviert aber nur 18 Milliarden pro Token – das senkt die Kosten für lange Kontexte. Flash kostet etwa ein Zehntel von GLM-5.3 und bringt im Coding Plan das Dreifache an Nutzung.

ZCode ist kein Spielzeug. Der ZCode Coding Agent übernimmt komplexe Aufgaben, findet Schwachstellen und arbeitet dabei mit einem schlanken Token-Budget. Du solltest die Sicherheits- und Datenschutzregeln kennen, bevor du ihn auf sensible Projekte loslässt. Starte mit der strengsten Berechtigungsstufe und arbeite dich hoch. Dann schreibt ZCode nicht nur Code, er verbessert auch deinen Arbeitsablauf.

Quelle: flaviocopes.com

Ein Punktwert zeigt, ob deine Website für KI-Agenten nutzbar ist. Er entsteht aus einem automatisierten Scan öffentlicher Seiten. Der Test des Anbieters Ora ist kostenlos und ohne Anmeldung nutzbar.

Deine Website ist für Menschen optimiert: klare Menüs, ansprechendes Design, schnelle Ladezeiten. Ein KI-Agent – Chatbot oder Recherche-Tool – sieht das anders. Er liest HTML-Code, folgt Links, prüft Statuscodes. Findet er keine verwertbaren Inhalte, bricht er ab. Hier setzt der AI Agent Readiness Score an.

Ein Geschäftshaus kann einen schönen Eingang haben und eine versperrte Laderampe. KI-Agenten sind wie Lieferanten: Sie brauchen einen eigenen, klar beschriebenen Zugang. Der Score prüft, ob dieser Zugang existiert und ohne Hindernisse nutzbar ist.

Warum KI-Agenten andere Maßstäbe setzen

Ein Mensch sieht eine Webseite als Ganzes. Ein KI-Agent sieht Dateien, HTTP-Antworten, strukturierte Daten. Er extrahiert den Inhalt aus dem Rohmaterial, interpretiert ihn und ordnet ihn ein. Dafür braucht er server-gerenderte Inhalte, die auch ohne JavaScript ausgeliefert werden.

Viele moderne Websites rendern im Client. Der Browser lädt ein leeres Gerüst und JavaScript füllt es. Ein KI-Agent, der keine Skripte ausführt, sieht eine leere Seite. Menschen merken das nicht. Agenten brechen ab. Der AI Agent Readiness Score erkennt solche Probleme, weil er die Seite betrachtet, wie ein Agent sie vorfindet.

Dazu kommen HTTP-Verhalten und Dokumentstruktur. Ein falscher Statuscode, eine fehlende canonical URL oder ein kaputter Anker kann einen Agenten aus dem Konzept bringen. Die Prüfung erfasst grundlegende Signale: korrekte Antworten, eine logische Überschriftenhierarchie, erreichbare Formulare. Das ist die Basis für jede weitere Interaktion.

Essential Checks: Das Fundament der Agentenfreundlichkeit

Essential Checks machen den größten Teil des Scores aus. Jede Website sollte sie bestehen, egal in welcher Branche. Sie decken fünf Bereiche ab: server-gerenderte Inhalte, korrektes HTTP-Verhalten, klare Dokumentstruktur, behebbare Fehler, bedienbare Steuerelemente.

Server-gerenderte Inhalte: Die wesentlichen Informationen stehen bereits im initialen HTML. Ein Agent wartet nicht, bis ein Browser Skripte ausführt. HTTP-Verhalten betrifft Statuscodes wie 200, 404 oder 301 – und ihren sinnvollen Einsatz. Eine alte URL sollte auf die neue umleiten, keinen Fehler liefern.

Die Dokumentstruktur zeigt dem Agenten, was wichtig ist. Überschriften in der richtigen Reihenfolge, aussagekräftige Link-Texte, semantische HTML-Elemente. Fehler sollte man nicht verschlucken. Wenn eine Ressource fehlt, muss der Agent das nachvollziehen können. Schaltflächen und Formulare brauchen klare Labels oder stabile IDs.

Diese Checks tragen am stärksten zum Score bei. Sie entscheiden, ob eine Webseite wie ein offenes Buch wirkt oder wie ein Paket ohne Adressfeld. Ohne diese Grundlagen helfen weiterführende Optimierungen nicht.

Recommended Checks und optionale Verbesserungen

Daneben gibt es Recommended Checks. Sie fließen nur dann in die Bewertung ein, wenn der Scan Hinweise auf bestimmte Schnittstellen findet: APIs, OAuth-Logins, GraphQL-Endpunkte, MCP-Server, Entwickler-Portale oder Commerce-Funktionen.

Nicht zutreffende Prüfungen zählen nicht als Fehler. Eine Unternehmenswebsite ohne Shop und API wird nicht bestraft. Sie wird nur nach den Kriterien gemessen, die für sie relevant sind.

Bietet deine Website eine API oder OAuth-Fläche, müssen Agenten diese finden und verstehen können. Eine API-Dokumentation als PDF hilft weniger als eine maschinenlesbare OpenAPI-Beschreibung. Der Score prüft, ob solche Formate vorhanden und zugänglich sind.

Bonus-Punkte gibt es für emergente Formate wie MCP-Server oder strukturierte Daten nach Schema.org. Fehlen sie, senkt das den Score nicht. Ein optionales Upgrade also.

So liest du einen Score-Bericht richtig

Der Bericht ist klar sortiert. Zuerst kommen die fehlgeschlagenen Essential Checks, dann die empfohlenen Verbesserungen, die zu den Funktionen Ihrer Website passen.

Jeder Befund nennt die beobachteten Beweise: einen HTTP-Statuscode, ein HTML-Element oder die Antwortzeit einer Ressource. Wo möglich gibt es eine konkrete Empfehlung, oft formuliert für Ticket-System oder Entwickleraufgabe.

Nach einer Verbesserung lässt du dieselbe URL neu scannen. Der Bericht wird ersetzt, die URL bleibt stabil. So siehst du, ob die Änderung etwas bewirkt hat.

Der Bericht enthält außerdem eine beobachtete Agentenreise. Ein einzelner Agent wird durch die Website geschickt, seine Schritte werden dokumentiert. Das ist eine illustrative Ergänzung, nicht Teil des Scores. Eine einzelne Aufgabe kann nicht alle Ziele von KI-Agenten abbilden.

Schnittstellen für Maschinen: API, Markdown und MCP

Berichte lassen sich nicht nur im Browser lesen. Die öffentliche Berichts-URL liefert den neuesten Score im initialen HTML-Antwortkörper. Kein JavaScript nötig, um die Informationen zu bekommen. Der Agent ruft die URL ab und erhält strukturierte Ausgabe.

Fordert ein Agent die Seite mit dem HTTP-Header text/markdown an, erhält er eine kompakte Markdown-Version. Software-Integrationen nutzen die JSON-API für maschinenlesbare Daten. Der Vary-Header verhindert, dass der Browser-Cache die falsche Variante ausliefert.

Hosts mit MCP-Protokoll können einen MCP-Server nutzen. Er stellt denselben Bericht als lesbares Werkzeug bereit, mit deklarierten Eingabe-Schemas und strukturierten Ergebnissen. Keine der Schnittstellen startet einen Scan oder verändert die Zielwebsite. Eine Anmeldung ist nicht nötig.

Existiert noch kein Bericht, startest du über die Browser-URL einen neuen Scan. Sobald er abgeschlossen ist, stehen alle maschinenlesbaren Varianten automatisch bereit.

Die Grenzen eines automatisierten Tests

Der Score bleibt eine Momentaufnahme. Er beschreibt, was zu einem bestimmten Zeitpunkt von einer öffentlichen URL aus erreichbar war. Statuscodes, Crawler-Regeln, Inhalte, Dokumentationen und API-Beschreibungen ändern sich. Ein Bericht ist eine technische Überprüfung, keine Garantie.

Der Scan sieht keine privaten Seiten oder authentifizierten Arbeitsabläufe. Geografische Unterschiede, Bot-Abwehr oder vorübergehende Störungen können das Verhalten beeinflussen. Inhalte hinter einem Login bleiben unsichtbar. Diese Einschränkungen sind systembedingt.

Der Score ist keine allgemeine Qualitätsmessung. Sicherheit, Barrierefreiheit, Datenschutz, rechtliche Konformität und fachliche Inhaltsgüte prüft er nicht. Dafür gibt es eigene Verfahren. Der AI Agent Readiness Score ist ein Werkzeug, nicht das einzige.

Konkret: Nutze den Score, um deine Website gezielt für KI-Agenten vorzubereiten. Er zeigt, wo die größten Reibungspunkte liegen. Behebe zuerst die Essential Checks, danach die Recommended Checks, die zu deinem Angebot passen.

Quelle: is-agentic.com

„A language model can perform well on a clean benchmark and still struggle with the cases that matter in production.“ Das Zitat beschreibt das Kernproblem der LLM-Evaluierung. Ein Benchmark ist eine kontrollierte Umgebung mit sauberen Daten und klaren Erwartungen. Die Produktion ist das nicht. Dort treffen unvollständige Kontexte, uneindeutige Eingaben und widersprüchliche Labels aufeinander. Wer LLM-Systeme ernsthaft einsetzen will, braucht eine Evaluierungsstrategie, die näher an der Realität liegt als ein kuratiertes Testset.

Der Erfahrungsbericht, der diesem Beitrag zugrunde liegt, beschreibt ein LLM-basiertes System, das False Positives beim GitHub Secret Scanning reduzieren soll. Secret Scanning erkennt Zugangsdaten wie Tokens und Schlüssel, die versehentlich in ein Repository gelangt sind. Ein Teil dieser Funde sieht zwar wie echte Zugangsdaten aus, ist aber harmlos. Entwickler verlieren dann Zeit mit der Prüfung solcher Alerts, obwohl keine Maßnahme nötig ist. Das Team stand vor einer typischen Produktionsfrage: Kann ein LLM die Spreu vom Weizen trennen, ohne relevante Alerts zu übersehen? Eine reine Benchmark-Aufgabe wäre gewesen, Strings korrekt zu klassifizieren. Die eigentliche Herausforderung war eine andere: die Fehlalarmrate senken, ohne die Sicherheit zu gefährden.

Am Anfang steht die Produktentscheidung, nicht das Modell

Für die Entwicklung dieses Systems war die Frage entscheidend: Kann die Lösung Fehlalarme reduzieren, ohne die Erkennungsrate realistischer Bedrohungen zu senken? Das klingt naheliegend, ist es aber nicht. Ohne eine klare Produktentscheidung verliert man sich in Prompt-Optimierung und Modellvergleichen, ohne zu wissen, was erreicht werden soll. Die Autoren raten, zuerst festzulegen, welche Fehler vermeidbar sein müssen und welche Kennzahlen die Entscheidung tragen.

Das Team entschied: Ein übersehener echter Credential ist schwerwiegender als ein zusätzlicher Fehlalarm. Precision und Recall wurden nicht gleich behandelt. Precision war das primäre Ziel, denn sie misst, wie viele der gemeldeten Alarme wirklich relevant sind. Recall diente als Sicherheitskriterium. Ein Experiment durfte nur weiterlaufen, wenn der Rückgang echter Erkennung innerhalb eines vorher festgelegten Rahmens blieb. Dazu kamen operative Rahmenbedingungen wie Latenz, Kosten, Zuverlässigkeit und die Kompatibilität mit der bestehenden Pipeline.

Ein Beispiel verdeutlicht das: Experiment A verbessert Precision stark, fällt aber unter den Recall-Schwellenwert. Experiment B bringt eine moderate Verbesserung, bleibt aber im erlaubten Bereich. Nur Experiment B ist aus Produktsicht ein Fortschritt. Diese Unterscheidung fehlt oft, wenn Teams nur einen Modellwechsel testen. Die Evaluierung von LLM-Systemen im Produktionsumfeld verlangt mehr als einen sauberen Testlauf. Sie verlangt eine klare Vorstellung davon, was das System verbessern soll.

Offline-Evaluation wie einen Integrationstest behandeln

Eine einmalige Evaluierung reicht nicht. Ändern sich Prompt, Modell, Eingabekonstruktion oder die Logik im Umfeld, verschiebt sich das Verhalten. Deshalb haben die Entwickler die Offline-Evaluation wie einen Integrationstest behandelt. Bei jeder relevanten Änderung lief sie erneut. Auch die Reproduzierbarkeit war wichtig. Zu jedem Lauf gehörten Prompt-Version, Modellversion, Datensatzversion und Systemkonfiguration. Nur so lässt sich beantworten, ob eine Änderung wirklich geholfen hat oder ob sich Fehler nur verschoben haben.

Ein Grundsatz war: eine große Variable pro Experiment. Eine Prompt-Änderung wurde getrennt von einem Modell-Upgrade getestet, bevor beide zusammenkamen. Wenn zwei Dinge gleichzeitig wechseln, weiß man am Ende nicht, was die Verbesserung oder Regression verursacht hat. Der Beitrag empfiehlt, Prompts wie Code zu behandeln – versioniert, dokumentiert und jederzeit zurückrollbar. Wer diese Disziplin nicht einhält, vergleicht Äpfel mit Birnen und schreibt einem Prompt eine Verbesserung zu, die eigentlich vom Modell stammt.

Modell-Upgrades sind ein eigenes Thema. Wenn ein System nicht gut funktioniert, neigen viele dazu, den Prompt mit immer mehr Anweisungen zu füllen. Manche Probleme verschwinden, andere entstehen neu. Ein stärkeres Modell arbeitet mit einem einfacheren Prompt oft besser als das alte Modell mit viel Feintuning. Ein simpler Prompt ist leichter zu verstehen, zu testen und zu warten. Aber auch der Wechsel des Modells muss durch die Offline-Evaluation, weil er Qualität, Latenz und Kosten verändern kann.

Die Offline-Evaluation so nah wie möglich an der Produktion halten

Ein Offline-Test ist nur so gut wie seine Ähnlichkeit zum Produktionseinsatz. Das Modell bewertet selten einen einzelnen, sauber isolierten Wert. Es sieht einen Kandidaten, umgebenden Code und weitere Hinweise, die relevant, unvollständig oder irreführend sein können. Bereits kleine Unterschiede verzerren das Ergebnis. Ein bereinigtes Testset, das alle mehrdeutigen Fälle entfernt und immer vollständigen Kontext liefert, misst ein einfacheres Problem als das, was später in Produktion auftritt.

Der Beitrag nennt ein Beispiel: Eine Variable heißt candidate_value und soll bewertet werden. Daneben steht eine Variable example_token, deren Name nach einem Sicherheitswert klingt. Das Modell könnte sich auf example_token stürzen und eine plausible Erklärung für den falschen Wert liefern. In einem sauberen Evaluierungsdatensatz mit nur einem offensichtlichen Kandidaten fällt das nicht auf. In der realen Secret-Scanning-Umgebung passiert genau das. Wer ein LLM für solche Aufgaben baut, sollte die Offline-Pipeline der Produktionspipeline so ähnlich wie möglich gestalten. Sonst zeigt eine gute Offline-Bewertung nur, dass das System ein einfacheres Problem gut löst.

Produktionslabels sind Signale, keine absolute Wahrheit

Produktionsdaten sind wertvoll, aber ihre Labels entstehen oft aus Workflow-Abläufen. Ein als „dismissed“ markierter Secret-Scanning-Alert ist nicht automatisch ein False Positive. Die Entwickler nennen mehrere Gründe: Der Credential wurde rotiert, das Risiko wurde akzeptiert, der Alert musste für einen Workflow verschwinden, oder die Klassifikation war schlicht falsch. Diese Fälle können im selben Datenfeld landen, obwohl sie unterschiedliche Wahrheiten repräsentieren. Wer ein Korpus aus Produktionsdaten baut, sollte sich fragen: Wie wurde das Label erzeugt? Beantwortet es dieselbe Frage, die die Evaluierung stellen soll? Werden verschiedene Workflow-Ausgänge in einer Kategorie zusammengefasst?

Ein manueller Review ist für wichtige oder mehrdeutige Teilmengen notwendig. Ziel ist nicht, jedes unvollständige Label zu eliminieren, sondern die Datengrundlage präzise genug für die Entscheidung zu machen. Wer diese Genauigkeit ignoriert, evaluiert auf einer Statistik, die mit der echten Welt wenig zu tun hat. Bei LLM-Modellen vor dem Produktionseinsatz hängt viel davon ab, ob die Labels die tatsächliche Produktlogik abbilden oder nur eine Annäherung.

Synthetische Daten und offene Datensätze als Ergänzung nutzen

Gute produktionsnahe Daten sind nicht immer verfügbar. Am Anfang fehlen repräsentative Beispiele, oder die Daten sind sensibel. Dann helfen synthetische Daten, akademische Benchmarks und offene Datensätze. Sie füllen Lücken – etwa bei seltenen Eingabeformaten, fehlendem Kontext oder ungewöhnlichen Fehlermustern. Sie sollten die produktionsnahen Daten ergänzen, nicht ersetzen. Eine Liste von Credential-Strings zeigt, ob das Modell Formate erkennt. Sie zeigt nicht, wie es mit einem Kandidaten in echtem Code umgeht.

Die Entwickler haben externe Beispiele an ihre Aufgabe angepasst und geprüft, ob die Labels zur eigenen Produktdefinition passen. Aus real aufgetretenen Fehlermustern haben sie gezielt synthetische Fälle erzeugt. Das sagt mehr aus als ein generischer Corpus. Dass ein Modell Benchmarks kann, ist noch kein Produktionsargument. Erst wenn die Testfälle die typischen Fallstricke des eigenen Einsatzbereichs abdecken, wird daraus ein belastbares Ergebnis.

Was die LLM-Evaluierung vor dem Produktionseinsatz bedeutet

Der Erfahrungsbericht zeigt: Die Evaluierung von Large Language Models vor dem Produktionseinsatz ist kein einmaliger Check, sondern ein Prozess. Sie beginnt mit der Produktentscheidung, läuft durch eine reproduzierbare Offline-Phase und endet idealerweise in einem Online-Experiment. Im beschriebenen Fall diente die Offline-Evaluation als Filter. Erst wenn die Ergebnisse den Produktkriterien standhielten, kam es zu einem kontrollierten Test in der echten Umgebung. So verhindert man, dass ein Modell nur auf Papier gut aussieht und in Produktion unerwartet versagt.

Für dein eigenes Projekt bedeutet das: Definiere zuerst das erwünschte Verhalten, nicht die Modellarchitektur. Entscheide, welche Fehler akzeptabel sind und welche nicht. Baue die Offline-Evaluation so auf, dass sie die Produktionsrealität abbildet – inklusive Unschärfen. Versioniere deine Prompts und Modelle, damit jede Verbesserung zugeordnet werden kann. Hinterfrage Labels, bevor du sie als Ground Truth akzeptierst. Und nutze synthetische Daten, um Lücken zu schließen, ohne dich von ihnen blenden zu lassen. Wer diese Punkte beachtet, hat eine belastbare Grundlage, um LLM-Modelle vor dem Produktionseinsatz zu bewerten – jenseits von Benchmark-Zahlen, mit Blick auf False Positives, Recall und Produktionsrealität.

Quelle: github.blog

„Ein einziger KI-Output ist ein Beispiel, keine Bewertung.“ Dieser Satz klingt banal, wird in der Praxis aber oft ignoriert. Wer mit KI-Systemen arbeitet, kennt das: ein Testinput, ein plausibles Ergebnis, und schon wirkt das System zuverlässig. Doch ein einzelner Durchlauf sagt nichts darüber, ob das System auch bei anderen Eingaben und Wiederholungen diese Leistung bringt. Der Artikel argumentiert dagegen: Teams sollen nicht länger von einem einzelnen Output auf die Qualität eines KI-Systems schließen.

Stattdessen schlägt der Beitrag vor, KI-Systeme wie in einer quantitativen UX-Studie zu evaluieren: viele repräsentative Testeingaben, mehrere Wiederholungen pro Eingabe, dazu eine statistische Zusammenfassung mit Mittelwerten und Konfidenzintervallen. Das kennt man aus der Marktforschung. Genau darum geht es: keine neue Wissenschaft der KI-Messung, sondern bewährte experimentelle Prinzipien anwenden.

Wieso ein einzelner Testlauf unzuverlässig ist

Warum ein einzelner Output nicht reicht: KI-Sprachmodelle arbeiten nichtdeterministisch. Gleiche Eingabe, unterschiedliche Ausgaben. Für jedes nächste Token berechnen sie eine Wahrscheinlichkeitsverteilung und wählen daraus, oft per Zufallsstichprobe. Dieselbe Frage kann also zweimal gestellt ganz unterschiedliche Antworten liefern – im Wortlaut und in der Qualität.

Das ist kein Randphänomen. Wiederholte Generationen desselben Modells zeigen messbare Leistungsunterschiede, und Evaluationsergebnisse hängen von der Art der Ausgabeerzeugung ab. Wer klassische Software gewohnt ist, kennt das nicht: Ein deterministisches Programm, das einmal korrekt läuft, läuft unter denselben Bedingungen immer korrekt. Diese Erwartung überträgt man unbewusst auf KI-Systeme – zu Unrecht. Ein einzelner guter Output beweist nur, dass das System die Aufgabe prinzipiell kann. Nicht, wie oft es das unter realen Bedingungen tut.

KI-Evaluation wie eine UX-Studie

Ein Vergleich macht das deutlich: Wer die Usability eines Checkout-Prozesses misst, lässt nicht eine Person eine Aufgabe erledigen und schließt daraus, der Prozess sei perfekt. Man definiert repräsentative Aufgaben, die verschiedene Produkttypen und Käufersituationen abdecken, beobachtet viele Teilnehmer und berechnet für Metriken wie Aufgabenerfolg oder Bearbeitungszeit einen Durchschnittswert. Dazu kommt ein Konfidenzintervall, also der Bereich, in dem der wahre Wert der Grundgesamtheit mit hoher Wahrscheinlichkeit liegt. Dieses Vorgehen lässt sich auf KI-Evaluationen übertragen.

Die Analogie ist nicht perfekt. Ein KI-Lauf ist kein menschlicher Teilnehmer, eine Testeingabe keine Aufgabe mit allen situativen Feinheiten. Aber die Grundlogik ist dieselbe: Man sammelt mehrere Beobachtungen, um die Leistung des Systems zu schätzen. Die UX-Forschung fasst Ergebnisse über Aufgaben und Teilnehmer hinweg zusammen. KI-Evaluationen sollten das auch tun – mit repräsentativen Eingaben, genügend Wiederholungen und einer Auswertung, die Mittelwert, Streuung und Unsicherheit ausweist.

Ein Beispiel: Kundenservice-Fragen fünfmal stellen

Ein Beispiel zeigt, wie das aussehen kann. Ein KI-gestützter Kundenservice beantwortet Fragen zu Unternehmensrichtlinien. Man wählt zehn repräsentative Fragen aus, die unterschiedliche Themen, Komplexitätsgrade und Kundensituationen abdecken: Rückgaben, Stornierungen, Schäden, Abonnements, Garantien. Jede Frage wird fünfmal eingereicht, insgesamt also 50 Antworten. Die Zahlen sind nur illustrativ. Je nach Variabilität des Systems und Tragweite der Entscheidungen braucht es in der Praxis mehr Fragen oder mehr Wiederholungen.

Vor der Datenerhebung muss klar sein, was eine akzeptable Antwort ist. Der Artikel nennt vier Kriterien: Sie muss die Frage korrekt beantworten, alle wichtigen Bedingungen und Ausnahmen enthalten, mit den Unternehmensrichtlinien übereinstimmen und dem Kunden bei Bedarf einen nächsten Schritt nennen. Fehlt ein Kriterium, gilt sie als nicht akzeptabel. Aus den 50 Antworten lässt sich der Anteil akzeptabler Antworten berechnen, dazu ein Konfidenzintervall. Ebenso wichtig: Wie stark schwankt die Qualität zwischen den zehn Fragen? Wie konsistent antwortet das System auf dieselbe Frage?

Eine Evaluation ist immer nur eine Momentaufnahme. Modellversion, Prompt, Einstellungen, Tools und Kontext gehören sorgfältig dokumentiert. Ändert sich eine dieser Komponenten, muss die Evaluation unter Umständen wiederholt werden. Nur so sind Ergebnisse nachvollziehbar und vergleichbar.

Zwei Formen von Variabilität: Testeingaben und Wiederholungen

Das Beispiel zeigt: Eine KI-Evaluation muss zwei getrennte Fragen beantworten. Erstens: Wie gut funktioniert das System über die Bandbreite an Eingaben, die Nutzer real stellen? Das ist die Testeingaben-Variabilität. Ein Kundenservice-System kann bei kurzen, klaren Fragen wie „Wo ist meine Bestellung?“ hervorragend arbeiten, aber bei komplexen Ausnahmefällen versagen. Enthält die Evaluation überwiegend einfache Fragen, überschätzt sie die reale Leistung. Die Testeingaben müssen also repräsentativ für die tatsächliche Nutzung sein. Quantität allein genügt nicht – viele einfache Fragen liefern ein präzises Ergebnis für die falsche Frage.

Die zweite Frage betrifft die Wiederholungs-Variabilität: Wie konsistent antwortet das System auf dieselbe Eingabe? Da es nichtdeterministisch ist, kann die Qualität variieren. Ohne wiederholte Läufe bleibt unklar, ob eine Aufgabe zuverlässig gemeistert wird oder nur gelegentlich gelingt. Mehr Testeingaben verbessern die Schätzung der Leistung über den Eingabenraum, mehr Wiederholungen die Schätzung der Konsistenz für eine bestimmte Eingabe. Beide Maßnahmen betreffen unterschiedliche Risiken. Das eine ersetzt das andere nicht.

Derselbe Score kann auf unterschiedliche Schwächen hinweisen

Dazu ein Beispiel: Zwei Kundenservice-Systeme werden mit zehn Fragen und fünf Wiederholungen getestet. Beide erreichen 80 Prozent akzeptabler Antworten – auf den ersten Blick gleich gut. Doch die Fehler verteilen sich völlig unterschiedlich. Das erste System antwortet auf acht Fragen in jedem Lauf korrekt und scheitert bei zwei Fragen konsequent. Das zweite System antwortet auf jede Frage in vier von fünf Läufen korrekt und versagt unregelmäßig über alle Fragen. Die identische Quote verdeckt zwei sehr verschiedene Probleme.

Dieser Unterschied ist in der Praxis entscheidend. Ein System, das immer an denselben Stellen scheitert, lässt sich gezielt verbessern – mit besseren Trainingsdaten oder angepassten Prompts für diese Frageklassen. Ein System, das unregelmäßig mal gut, mal schlecht antwortet, hat ein grundsätzlicheres Zuverlässigkeitsproblem. Wer nur den Gesamtscore betrachtet, sieht das nicht. Erst die Auswertung auf Ebene einzelner Fragen und Läufe zeigt, wo man ansetzen muss.

Konfidenzintervalle und Variabilität auszuwerten ist aufwendiger als ein einzelner Testlauf. Dafür bekommt man eine realistischere Einschätzung der Zuverlässigkeit von KI-Systemen. Wenn KI zunehmend Entscheidungen unterstützt oder übernimmt, ist das kein Luxus, sondern notwendig. Ein einzelnes gutes Beispiel ist schön. Es sagt nur nichts darüber, was im nächsten Moment passiert, wenn der Kunde dieselbe Frage stellt.

Quelle: nngroup.com

Ein 10-Millionen-Dokument-Korpus, der als Float32-Vektoren 31 Gigabyte Arbeitsspeicher belegt, passt mit turbovec in 4 Gigabyte. Die Suche in diesem komprimierten Index dauert weniger lang als mit FAISS, dem etablierten Standardwerkzeug für Vektorsuche. Möglich macht das eine Kombination aus einem neuen Quantisierungsverfahren und handoptimierten SIMD-Kernels.

Speicherfresser Vektorsuche: Das Problem

Vektorsuche steckt in vielen modernen Anwendungen, von Empfehlungssystemen bis zu Retrieval-Augmented Generation. Die zugrunde liegenden Einbettungen haben ihren Preis: Ein Vektor mit 1536 Dimensionen belegt als Float32 knapp 6 Kilobyte. Bei Millionen von Dokumenten summiert sich das auf mehrere hundert Gigabyte RAM. Zu teuer und oft unpraktikabel.

Dazu kommt die Geschwindigkeit. Eine lineare Suche über alle Vektoren ist bei dieser Größenordnung zu langsam. Klassische Indizes wie FAISS oder HNSW benötigen oft eine Trainingsphase, bevor sie Daten aufnehmen können. FAISS muss erst mit einer Stichprobe trainieren, um Codebücher zu lernen. Bei sich ständig ändernden Daten wird das zum Problem.

turbovec umgeht das: weniger Speicher durch Quantisierung, schnellere Suche durch SIMD-Optimierung und ein Online-Ingest ohne Trainingsschritt. Der Index eignet sich für Szenarien mit kontinuierlich neuen Daten, etwa bei RAG-Systemen für Dokumentenanalyse.

TurboQuant: Quantisierung ohne Trainingsphase

Um Vektoren kompakt abzulegen, nutzt turbovec die Produktquantisierung. Dabei wird ein Vektor in mehrere Untervektoren zerlegt, die jeweils durch einen Index aus einem Codebuch repräsentiert werden. Üblicherweise muss dieses Codebuch mit einem Trainingslauf auf den eigenen Daten erstellt werden. Genau das macht TurboQuant überflüssig.

Der Algorithmus von Google Research ist ein daten-agnostischer Quantisierer. Er erzeugt ein Codebuch, das für beliebige Datenverteilungen nahezu optimale Verzerrung bietet. Statt vollständiger Vektoren werden nur Codebuch-Indizes gespeichert. Das spart Platz, kostet aber etwas Genauigkeit.

turbovec unterstützt zwei Bit-Breiten: 2-Bit und 4-Bit pro Komponente. Je niedriger die Bit-Breite, desto stärker die Kompression, aber desto größer der potenzielle Qualitätsverlust. In den Benchmarks zeigt sich, dass die 4-Bit-Variante kaum an Recall einbüßt, während sie den Speicherbedarf drastisch senkt. Die 2-Bit-Variante ist für extrem speicherhungrige Systeme gedacht.

Rust, SIMD und Python: Die technische Basis

Rust als Implementierungssprache hat Vorteile. Sie garantiert Speichersicherheit ohne Garbage Collector und erlaubt feingranulare Optimierungen. Entwickler Ryan Codrai hat die Such-Kernels von turbovec von Hand geschrieben und nutzt SIMD-Instruktionen. SIMD steht für Single Instruction Multiple Data – eine CPU verarbeitet damit mehrere Vektoren parallel. Das beschleunigt die Suche erheblich.

Konkret kommen auf ARM-Prozessoren NEON SDOT/SMMLA zum Einsatz, auf x86 AVX-512 VNNI und vpermb. Ältere CPUs nutzen AVX2 oder skalare Fallbacks. In den Messungen des Autors übertrifft turbovec damit FAISS IndexPQFastScan in fast jeder Konfiguration. Bei 4-Bit-Quantisierung liegt der Vorsprung durchschnittlich beim Faktor 3,4, bei 2-Bit bei 20 bis 30 Prozent.

Die Python-Bindings machen die Bibliothek direkt nutzbar. Du installierst turbovec per Pip und kannst sofort einen Index anlegen, Vektoren hinzufügen und durchsuchen. Die API ist bewusst schlank: TurboQuantIndex für den einfachen Fall, IdMapIndex für stabile IDs. Wer in Python arbeitet, profitiert damit von der Leistung einer nativen Rust-Bibliothek.

Quelle: github.com