Warum KI-Projekte zwischen Demo und Produktion stecken bleiben
Keiner dieser Gründe ist ein Modellproblem. Alle tauchen in dem Moment auf, in dem man die Demodaten gegen echte Daten tauscht.
In diesem Artikel6 sections
- Die Demo ist der einfache Teil
- Zehn Demodokumente sagen nichts über zehntausend echte
- Mit echten Daten arbeiten heisst, mit Personendaten arbeiten
- KI repariert keine unordentlichen Daten, sie stellt sie ins Rampenlicht
- Der Preis eines KI-Projekts ist nicht, was sein Bau kostet
- Ohne vorher festgehaltenes Erfolgskriterium kann ein Projekt weder gelingen noch aufhören
Die Demo ist der einfache Teil
Bei ein paar gut gewählten Fällen funktioniert fast alles, und alle gehen begeistert nach Hause.
Der Rest: die verzwickten Fälle, die echte Last, die Zugriffsrechte, die Leute, die ihre Arbeitsweise ändern müssen: Dort hakt es, und dort versiegen die Budgets. Fast die Hälfte der Machbarkeitsnachweise geht nie in Betrieb: Die Rechnung ist real, der Nutzen ist es nie geworden.
Das Gegenmittel ist eine Bau-Gewohnheit: schon beim Prototyp berücksichtigen, was der Schritt in die Produktion verlangt. Zugriffsrechte, Grenzfälle, Kosten pro Nutzung, was überwacht werden muss und wer das tun wird.
Zehn Demodokumente sagen nichts über zehntausend echte
Eine Demo bereitet man mit dem vor, was zur Hand ist: ein Dutzend saubere PDFs von ein paar Seiten, ausgewählt, weil sie sich gut lesen lassen. In der Produktion sind es Abrechnungen von mehreren hundert Seiten, schiefe Scans, Dateien, die jeden Morgen stapelweise eintreffen.
Dieser Massstabswechsel erfordert nicht nur mehr Geduld: Er bringt Einschränkungen ans Licht, die der Prototyp nicht kannte. Serverspeicher, Verarbeitungszeit, Zeitüberschreitungen, Kosten pro Seite. Bei einem unserer Extraktionsprojekte genügte ein einziges Dokument von fast 500 Seiten, um die Maschine zu blockieren, die die Testdateien mühelos verarbeitete. Bei einem anderen brauchte ein 190-seitiges Dokument über zwei Stunden.
Einfach zu prototypisieren bleibt der richtige Ansatz: Es ist der schnellste Weg zu zeigen, was möglich ist. Aber man muss sehr schnell eine Stichprobe echter Daten bekommen: die grössten Dateien, die am schlechtesten gescannten, die ältesten, und das Volumen eines normalen Monats. Diese Stichprobe sagt, was die Produktion verlangen wird, nicht die Demo.
Mit echten Daten arbeiten heisst, mit Personendaten arbeiten
Sobald man die Demodaten verlässt, hantiert man mit Namen, Adressen, Kunden- oder Patientendossiers. Sie unverändert an ein anderswo gehostetes Modell zu senden heisst, sie einem Dritten anzuvertrauen, mit allem, was das Datenschutzgesetz dann verlangt.
Die solideste Antwort ist, vor dem Versand zu anonymisieren: Namen und Kennungen durch Platzhalter ersetzen, das Modell am neutralisierten Text arbeiten lassen und die echten Werte bei der Rückkehr wieder einsetzen. Bei einem medizinischen Projekt haben wir die Anforderung vor dem Bau festgelegt: Kein Patientenname darf durchgehen. Die Prüfung umfasste über zweihundert echte Fälle, alle erkannt. Und wenn die Erkennung versagt, stoppt das Tool, statt den Text im Klartext zu senden.
Ein Prototyp kann auf all das verzichten. Ein System in Produktion nie. Und echte Daten bleiben gern dort, wo sie verwendet wurden: in einem Testdatensatz, einem Code-Repository, einem nie gelöschten Demokonto. Sie werden ab dem ersten Tag, an dem sie ins Projekt kommen, nach den Regeln der Produktion behandelt.
KI repariert keine unordentlichen Daten, sie stellt sie ins Rampenlicht
An dem Tag, an dem man ein Modell aus der eigenen Historie lernen lässt, entdeckt man die Duplikate, die halb ausgefüllten Felder, die drei Namenskonventionen, die seit zehn Jahren nebeneinander bestehen.
Das ist kein technisches Problem: Es ist die Realität aller Unternehmen, und niemand hatte ihr ins Auge geschaut, weil die Menschen es stillschweigend ausglichen.
Ein Projekt, das diese Arbeit nicht einplant, plant die Hälfte seines Budgets nicht ein. Deshalb lohnt es sich, die Daten zu öffnen, bevor man ein Modell verspricht: das tatsächliche Volumen, die tatsächliche Qualität, was nutzbar ist und was nicht. Dieser Schritt zeigt oft, dass man zuerst aufräumen muss oder dass eine einfachere Verarbeitung genügt.
Der Preis eines KI-Projekts ist nicht, was sein Bau kostet
Was ins Gewicht fällt, kommt danach: die Kosten jedes Aufrufs, die Überwachung, Modelle, die sich unter einem verändern, neue Fälle, die zu behandeln sind.
Viele Projekte werden mit einem Entwicklungsbudget bewilligt und achtzehn Monate später wegen Betriebskosten aufgegeben, die niemand beziffert hatte.
Ein System, dessen Betrieb man sich nicht leisten kann, wurde nie wirklich geliefert. Diese Kosten schätzt man vor dem Bau, nicht danach.
Ohne vorher festgehaltenes Erfolgskriterium kann ein Projekt weder gelingen noch aufhören
«Schauen, was KI für uns tun kann» ist kein Ziel: Es ist eine Ausgabe ohne Ziellinie.
Ohne zu Beginn festgelegte Schwelle kann niemand sagen, ob das Ergebnis gut ist, also startet man eine weitere Runde, dann noch eine, bis jemand das Budget aus Überdruss streicht. Das ist der häufigste Abbruchgrund, weit vor technischen Schwierigkeiten.
Diese Schwelle zu Beginn festzuhalten ist unbequem: eine Frist, eine Fehlerquote, ein verarbeitetes Volumen und was den Abbruch auslöst. Dort ist es viel günstiger als am Ende.
Ein KI-Projekt beurteilt man schlecht an seiner Demo und gut an seinen Betriebskosten. Alle Punkte oben laufen auf dieselbe Frage hinaus, gestellt vor dem Start: Woran werden wir in sechs Monaten erkennen, dass es sich gelohnt hat oder dass wir aufhören sollten?
Ce sujet touche à notre expertise Massgeschneidertes KI-Projekt.
Wir beginnen mit einem Gespräch, nicht mit einer Offerte.
Voir l'expertiseWeiterlesen
