Die versteckte Technical Debt von Generativer KI bewältigen

Eine gut verwaltete semantische Schicht gibt Ihrer Organisation ein Fundament, dem sie vertrauen kann. Doch sobald Sie beginnen, GenAI-Anwendungen auf diesem Fundament aufzubauen – Konversationsschnittstellen, KI-gestützte Datenassistenten, autonome Agenten –, entsteht eine neue Kategorie technischer Herausforderungen. Generative KI bringt Formen Technical Debt mit sich, die leicht übersehen werden und sich schnell aufsummieren: Agenten-Tools, die über das hinauswachsen, was ein Modell zuverlässig navigieren kann, Prompts, die zu unüberschaubaren Geflechten anschwellen, Pipelines, die undurchsichtig versagen und sich dem Debugging widersetzen, sowie Feedback-Schleifen, die zwar prinzipiell existieren, aber nie tatsächlich implementiert werden. Zu verstehen, woher dieser Technical Debt stammt und wie man ihn abbaut, ist heute eine Kernkompetenz für jedes Team, das GenAI-Systeme ausliefert.

Wo die Zeit hingeht

Der Lebenszyklus eines Generative-AI-Projekts sieht dem eines klassischen Machine-Learning-Projekts täuschend ähnlich, doch die Verteilung des Aufwands unterscheidet sich. Die Datensammlung ist oft der einfache Teil. Statt akribisch bereinigter Trainingsdatensätze benötigen GenAI-Anwendungen in der Regel ausreichend Kontext für das Modell – meist unstrukturierte Wissensdokumente oder Handbücher –, und dieses Material erfordert selten eine umfangreiche Bereinigung.

Die Evaluierung ist eine ganz andere Angelegenheit. Sie ist deutlich subjektiver, komplexer und dementsprechend zeitaufwändiger. Ein anfänglicher Satz an Evaluierungsfragen deckt selten das gesamte Spektrum der Anfragen ab, die ein realer Nutzer stellen könnte, weshalb der Evaluierungsdatensatz mit der Zeit wachsen muss. Da die Antwortqualität stark von den Erwartungen der Endnutzer abhängt, verbringen Ingenieure erheblich mehr Zeit damit, sich mit Fachbereichen und Produktverantwortlichen abzustimmen, Anforderungen zu sammeln, zu priorisieren und auf Basis von Feedback zu iterieren.

Auch Monitoring beansprucht einen großen Teil des Aufwands. Viele GenAI-Anwendungen sind Echtzeitsysteme – virtuelle Support-Agenten, Live-Transkriptionsagenten, Coding-Assistenten – und diese erfordern Echtzeit-Monitoring: Endpoint-Überwachung, Analyse-Pipelines für Inferenzen und Alerting. Da Evaluierungen von Natur aus subjektiv sind, müssen Deployment-Ingenieure herausfinden, wie sie das Einsammeln subjektiven Feedbacks innerhalb ihrer Inferenz-Pipelines operationalisieren. In der Praxis bedeutet das oft, LLM-als-Richter-Evaluierungen auf Antworten laufen zu lassen oder eine Teilmenge der Antworten Fachexperten zur Überprüfung vorzulegen. Bei proprietären Modellen kommt eine weitere Komplikation hinzu: Anbieter optimieren ihre Modelle fortlaufend, wodurch ein „Modell" faktisch zu einem Dienst wird, der anfällig für Regressionen ist. Die Evaluierungskriterien müssen berücksichtigen, dass die Gewichte nicht eingefroren sind, wie es bei einem selbst trainierten Modell der Fall wäre.

Testen ist generell schwieriger geworden. GenAI-Anwendungen sind enorm komplex, und unsere Evaluierungs- und Test-Frameworks haben damit noch nicht Schritt gehalten. Lange Multi-Turn-Konversationen, SQL-Ausgaben, die den organisatorischen Kontext eines Unternehmens erfassen müssen oder auch nicht, sowie die Überprüfung, ob innerhalb einer Kette die richtigen Tools aufgerufen werden – all das lässt sich derzeit noch nicht zuverlässig testen.

Neue Formen von Technical Debt

Über die Verschiebung des Arbeitsaufwands hinaus bringt Generative KI Kategorien Technical Debt mit sich, die nicht immer offensichtlich sind, bis sie zum Problem werden.

Tool-Wildwuchs

Tools sind ein mächtiges Mittel, um die Fähigkeiten eines LLM zu erweitern, doch mit wachsender Anzahl werden sie zunehmend schwerer zu verwalten. Tool-Wildwuchs ist mehr als ein Problem der Auffindbarkeit und Wiederverwendbarkeit – er kann die Qualität des Systems aktiv verschlechtern. Das Modell muss das richtige Tool aus einer potenziell großen Menge auswählen, und wenn mehrere Tools ähnliche Funktionen erfüllen, wird diese Auswahl fehleranfällig. Selbst nachdem das richtige Tool identifiziert wurde, muss das Modell die Nutzerfrage noch in die richtigen Parameter übersetzen, was besonders schwierig ist, wenn mehrere Tools ähnliche Parameterstrukturen teilen. Die sauberste Abwehr ist Disziplin: Seien Sie strategisch und sparsam bei der Auswahl der Tools, die ein Team einsetzt.

Prompt-Komplexität

State-of-the-Art-Modelle können seitenlange Anweisungen verarbeiten, doch übermäßig komplexe Prompts laden Probleme wie widersprüchliche Anweisungen und veraltete Informationen geradezu ein. Das kommt besonders häufig vor, wenn Prompts nie überarbeitet, sondern von verschiedenen Entwicklern und Fachexperten im Laufe der Zeit nur ergänzt werden. Wenn neue Fehlermodi auftauchen oder sich das Spektrum der Anfragen erweitert, liegt die Versuchung nahe, immer mehr Anweisungen anzuhängen. Ein besserer Ansatz besteht darin, Inhalte in mehrere kleinere, fokussierte Prompts aufzuteilen statt einen einzigen, ausufernden Prompt zu pflegen – Klarheit, Genauigkeit und Fehlerbehebung verbessern sich dadurch alle gleichermaßen. Frameworks, die Prompt-Versionen nachverfolgen und erwartete Ein- und Ausgaben erzwingen, helfen dabei, die Übersicht zu bewahren.

Undurchsichtige Pipelines

Wenn eine Antwort falsch zurückkommt, ist die Untersuchung der Ein- und Ausgaben zwischengeschalteter LLM-Aufrufe entscheidend, um die Ursache zu finden – und die relevanten Aufrufe zu identifizieren, kann zeitaufwändig sein. Tracing zu aktivieren reicht allein nicht aus. Eine Anwendung mithilfe eines strukturierten Frameworks ordentlich mit Observability-Tooling zu instrumentieren, ist ein notwendiger erster Schritt, um Agenten-Interaktionen transparent zu machen. Ohne das wird Debugging zum Rätselraten, und Rätselraten summiert sich zu Technical Debt.

Das Data Flywheel

Wird Nutzerfeedback vernachlässigt, baut sich Qualitäts-Debt schnell auf. Ein Team, das ausliefert, ohne den Erfolg zu messen, betreibt ein hoffnungsgetriebenes Deployment – eines, das so lange hält, bis sich das Modell darunter verändert oder sich das Nutzerverhalten verschiebt. Ein Data Flywheel bietet einen strukturierten Weg, dem zu begegnen: eine geschlossene Feedback-Schleife, die Systemausgaben in Systemverbesserungen verwandelt und eine ausgelieferte GenAI-Anwendung von einem statischen Artefakt zu einem lernenden System macht. Was andere Frameworks als Learning Loop bezeichnen – den Zyklus aus dem Messen von Ergebnissen und deren Rückführung in das System – operationalisiert das Data Flywheel in drei konkreten Schritten: Erfolgskennzahlen definieren, deren Messung automatisieren und Prompts oder Pipelines iterativ anpassen, um sie zu verbessern.

Schritt eins: Erfolgskennzahlen definieren

Dieser Schritt umfasst zwei Phasen: klare Erfolgskriterien festlegen und anschließend den richtigen Weg finden, sie umzusetzen. Wirksame Kriterien lassen sich nicht rein durch das Theoretisieren über mögliche Fehlermodi ableiten – die tatsächlichen Daten müssen untersucht werden, um zu verstehen, was man wirklich von den Ausgaben des Modells erwartet.

Die Umsetzung kann auf codebasierten oder LLM-basierten Kennzahlen beruhen. Einfache Funktionen eignen sich gut zur Bewertung von Heuristiken. Für subjektivere oder komplexere Beurteilungen kann LLM-als-Richter eine definierte Kennzahl direkt bewerten. Die Ausgabe des Richters mit dem eigenen Urteil in Einklang zu bringen, ist der schwierige Teil, aber das Bereitstellen einiger Beispiele verbessert die Übereinstimmung erheblich. Als Faustregel gilt: Binäre Kennzahlen lassen sich deutlich leichter abgleichen und nachvollziehen als abgestufte. Die Validierung von Eingabedaten ist ebenso wichtig wie die Validierung von Ausgabedaten. Eine nützliche Leitlinie hierfür ist Postels Gesetz: Sei konservativ in dem, was du sendest, und großzügig in dem, was du akzeptierst.

Es lohnt sich, einen Schritt zurückzutreten und Evaluierung im größeren Zusammenhang zu betrachten. Erfolg mit KI hängt, ähnlich wie in der Softwareentwicklung, von einer engen dreistufigen Schleife ab: Qualität bewerten, Probleme debuggen und das Verhalten des Systems ändern. Ist der Evaluierungsprozess erst einmal gestrafft, werden alle anderen Aktivitäten einfacher. Das ähnelt stark der Art, wie Tests in der Softwareentwicklung sich langfristig enorm auszahlen, obwohl sie zunächst erhebliche Vorabinvestitionen erfordern.

Schritt zwei: Messung automatisieren

Der zweite Schritt hält die definierten Kennzahlen im Einklang mit den Produktionsdaten und sollte so weit wie möglich automatisiert sein. Entscheidend ist, dass regelmäßig neu bewertet wird, ob die gewählten Kennzahlen noch mit den eigenen Zielen übereinstimmen, denn LLM-APIs verändern sich im Hintergrund und das ideale Systemverhalten entwickelt sich mit der Zeit weiter. Ein Agent, der regelmäßig eine Stichprobe gelabelter Produktionsdaten analysiert, kann signalisieren, wann der Kennzahlensatz aktualisiert werden muss. Auch Produktionsdaten driften, weshalb die Abstimmung fortlaufend neu bewertet werden muss. Die größte Herausforderung besteht darin, eine regelmäßige menschliche Kennzeichnung der Daten für jede Kennzahl sicherzustellen – so wichtig wie aufwändig.

Schritt drei: Iterativ verbessern

Der letzte Schritt verbindet manuelle menschliche Einsicht mit automatisierten Techniken, um die Leistung basierend auf der realen Nutzung zu verbessern. Prompts und Pipelines sollten von Hand iteriert werden, um die Kennzahlen zu verbessern. Sind die ersten beiden Schritte einmal etabliert, wird leicht ersichtlich, was in der Produktion gut funktioniert und was nicht – und diese Erkenntnisse fließen direkt in bessere Prompts zurück. Kennzahlen sollten regelmäßig überprüft werden, um Muster oder Häufungen schwach performender Fälle zu erkennen, und die Verteilung der Eingabe- und Anfragedaten sollte analysiert werden, um Verschiebungen im Nutzerverhalten zu erkennen. Wo möglich, sollte sich die Pipeline auch automatisch als Reaktion auf die Kennzahlen verbessern.

Die menschliche Seite des Flywheels

Menschliches Feedback einzuholen ist unschätzbar wertvoll – und zeitaufwändig. Ingenieure müssen Zeit mit Fachexperten koordinieren, Bewertungsraster erstellen, um Unterschiede in deren Einschätzungen auszugleichen, und das Feedback anschließend auf umsetzbare Verbesserungen hin auswerten. Die Gestaltung dieser Bewertungsraster sowie die Entwicklung unterschiedlicher Kennzahlen und Richter für verschiedene Szenarien gehört zu den mühsamsten Arbeiten im gesamten Prozess. Persönliche Gespräche und Workshops sind in der Regel erforderlich, um ein gemeinsames Bewertungsraster für das erwartete Verhalten des Agenten zu etablieren, und erst wenn menschliche Bewerter aufeinander abgestimmt sind, können ihre Einschätzungen zuverlässig in LLM-basierte Richter einfließen.

Regelmäßige Rücksprache mit Endnutzern, Geschäftssponsoren und angrenzenden Teams ist essenziell. Häufige Berührungspunkte helfen Stakeholdern, sich in die Qualität der Anwendung eingebunden zu fühlen, und verwandeln sie so von Kritikern in Mitgestalter. Nicht jedes Feedback hat das gleiche Gewicht – manche Stakeholder fordern Funktionen, die für ein MVP verfrüht sind oder schlicht jenseits dessen liegen, was aktuelle LLMs leisten können. Prioritäten auszuhandeln und alle Beteiligten darüber aufzuklären, was machbar ist und was nicht, gehört zur Aufgabe dazu, denn sowohl technische als auch nicht-technische Personen haben nicht immer ein zutreffendes mentales Modell davon, was ein LLM bewältigen kann. GenAI-Entwicklung als eine gemeinsame Lernreise zu behandeln, verankert in regelmäßigen Berührungspunkten, ist ein praktischer Weg, alle Beteiligten informiert und aufeinander abgestimmt zu halten.

Fazit

Die Technical Debt generativer KI ist real, aber beherrschbar. Halten Sie Ihr Tool-Set schlank, Ihre Prompts fokussiert und versioniert, und Ihre Pipelines beobachtbar. Bauen Sie ein Flywheel, das Erfolg definiert, ihn automatisch misst und die Ergebnisse in kontinuierliche Verbesserung zurückführt. Und vor allem: Behandeln Sie die Menschen, die Ihre Anwendung nutzen und fördern, als Partner in dieser Arbeit. Die Teams, die diesen Technical Debt bewusst abbauen, statt ihn im Stillen anwachsen zu lassen, werden diejenigen sein, deren GenAI-Systeme auch in einem Jahr noch vertrauenswürdig sind.

Das hier beschriebene Data Flywheel ist ein allgemeines Prinzip. Im dritten Teil dieser Serie setzen wir es in die Praxis um: ein konkretes Evaluierungs-Framework für Databricks-Genie-Agenten, das die vollständige Schleife implementiert – automatisierte Frageausführung, LLM-als-Richter-Bewertung, MLflow-Tracking – und das Flywheel von einer Idee in ein funktionierendes technisches System verwandelt.