// KÜNSTLICHE INTELLIGENZ
Warum scheitern KI-Pilotprojekte vor der Produktion?
7 Min. Lesezeitnijitech
Der Unterschied zwischen einem funktionierenden Pilotprojekt und einem System, das im Produktivbetrieb besteht, liegt nicht im Modell, sondern in der Schicht darum herum. Vier konkrete Bruchstellen.
Ganzer Beitrag
Ein KI-Pilotprojekt gilt schnell als erfolgreich: Auf einem ausgewählten Datensatz, mit ausgewählten Beispielen, unter den Augen der Entwicklung funktioniert es. Dass dasselbe System im Produktivbetrieb besteht, ist eine ganz andere Aufgabe. Der Unterschied hat meist nichts mit dem Modell zu tun — er liegt in der Schicht, die um das Modell herum nicht gebaut wurde.
1. Die Eingabe ist im Pilot sauber, in der Produktion nicht
Pilotdaten werden meist von Hand ausgewählt: lesbare Dokumente, saubere Tonaufnahmen, vollständige Felder. In der Produktion kommt das schiefe Foto einer eingescannten Rechnung, eine Besprechungsaufnahme mit drei Sprechern im Hintergrund, ein halb leer gelassenes Formular. Das Modell ist dasselbe; die Eingabeverteilung hat sich verändert.
Typische Eingabeprobleme im Produktivbetrieb
- Dieselbe Information kommt bei jedem Lieferanten in anderer Form
- Fehlende oder widersprüchliche Felder
- Unerwartete Sprache, Format oder Kodierung
- Mit der Zeit driftende Datenverteilung — die Regel von letztem Jahr trägt dieses Jahr nicht mehr
Die Antwort darauf ist kein stärkeres Modell, sondern eine Schicht, die die Eingabe in eine gemeinsame Repräsentation überführt. Die nachfolgenden Schritte müssen dann nicht mehr wissen, woher die Daten kamen.
2. Unverifizierte Ausgabe ist im Produktivbetrieb keine Ausgabe
Im Pilot schaut ein Mensch auf die Ausgabe. In der Produktion entstehen täglich Tausende Ausgaben, und keine einzelne wird geprüft. Deshalb muss das System seine eigene Ausgabe verifizieren können — und sagen können, wenn es sich nicht sicher ist. Ohne Verifikationsschicht ist ein Fehler längst nach unten durchgelaufen, wenn er auffällt.
3. Kosten sind im Pilot unsichtbar, im Volumen sichtbar
Die Kosten eines Modellaufrufs pro Vorgang sind klein und fallen im Pilot nicht auf. In einem System mit zehntausend Aufrufen am Tag bestimmt dieselbe Zahl die gesamte Rechnung. Jede Aufgabe an das stärkste Modell zu schicken, ist wie einen Bagger zu mieten, um einen Nagel einzuschlagen: Es funktioniert, aber es lohnt nicht.
Einen Teil der Aufgaben an kleinere Modelle zu leiten, senkt nicht nur die Rechnung, sondern auch die Latenz. Dafür braucht es eine Routing-Schicht, die entscheidet, welche Aufgabe zu welchem Modell geht — diese Entscheidung in den Anwendungscode zu schreiben, macht jede Änderung zu einer Entwicklungsaufgabe.
4. Eine Entscheidung ohne Verantwortlichen ist der teuerste Fehler
Wenn ein autonomes System falsch entscheidet, lautet die erste Frage: Wer hat das entschieden, und worauf gestützt? Installationen ohne Antwort darauf werden nach dem ersten ernsten Fehler meist abgeschaltet. An kritischen Schwellen menschliche Freigabe zu verlangen, bremst das System nicht — es hält es am Leben.
Zusammenfassung
Vier Fragen für den Weg vom Pilot in die Produktion
- Was passiert, wenn die Eingabe nicht jedes Mal gleich aussieht?
- Wer verifiziert die Ausgabe, und kann er ihre Quelle zeigen?
- Was passiert mit Kosten und Latenz beim zehnfachen Volumen?
- Wem gehört eine Fehlentscheidung, und ab welcher Schwelle wird ein Mensch gefragt?
Die Antworten auf diese vier Fragen liegen nicht in einem Modell, sondern in der Strecke um das Modell herum. Deshalb laufen alle nijitech-Produkte auf demselben Rückgrat.
Aus dem Glossar: Menschlich freigegebene Entscheidung (Human-in-the-Loop) · Bewertungssatz (Eval)