Ein Modell läuft schnell, ein Dienst muss tragen
Der Prototyp überzeugt nach zwei Tagen, und danach entscheidet sich an Evaluation, Kosten und Fehlerverhalten, ob daraus etwas wird, das im Haus bleibt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Prototyp überzeugt, die Abnahme scheitert am Betrieb
Ein Assistent, der auf firmeneigene Dokumente antwortet, steht in wenigen Tagen. Die Vorführung läuft gut, weil die Fragen aus dem Kopf der Person stammen, die ihn gebaut hat. Sobald zwanzig Leute aus dem Fachbereich ihre eigenen Fragen stellen, bricht die Trefferquote ein, und niemand kann sagen, ob das am Modell, an der Suche oder am Zuschnitt der Dokumente liegt, weil vorher nichts gemessen wurde.
Dann beginnt das Ändern nach Gefühl. Ein anderer Prompt, ein anderes Modell, andere Größe der Dokumentabschnitte, und jede Änderung wird an drei Beispielfragen beurteilt. Dass eine Änderung an anderer Stelle etwas kaputt gemacht hat, fällt erst auf, wenn sich jemand beschwert. Ohne festes Prüfset ist jede Verbesserung eine Behauptung.
Zum Schluss kommen die Fragen, die den Betrieb betreffen: Was kostet das im Monat bei dieser Nutzung, wie lange wartet jemand auf die erste Zeile, was passiert bei einem Ausfall der Schnittstelle, wer sieht die Eingaben, und darf der Dienst eigenständig etwas auslösen. Wer darauf keine Antwort hat, bekommt keine Freigabe, und das Vorhaben endet als Machbarkeitsnachweis.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Sieben Schritte vom Python-Grundgerüst zum Dienst im Betrieb
Der Weg ist kürzer, als er wirkt, wenn du aus der Softwareentwicklung kommst, und länger, wenn dir der Betrieb fremd ist. Entscheidend ist, dass Messung und Betrieb nicht am Ende stehen, sondern ab dem dritten Schritt mitlaufen.
- 1
Python so beherrschen, dass andere damit arbeiten können
Typangaben, Tests, eine saubere Paketstruktur, Umgang mit Abhängigkeiten und Umgebungsvariablen. Das klingt unspektakulär und ist der Unterschied zwischen einem Notebook und etwas, das ein zweiter Mensch weiterentwickeln kann. Dazu HTTP-Schnittstellen und Container, denn ausgeliefert wird am Ende ein Dienst.
Geschafft, wenn: Dein Code läuft auf einem fremden Rechner, ohne dass du danebensitzt.
- 2
Die Grundlagen des maschinellen Lernens verstehen, ohne dort zu bleiben
Du musst wissen, was Trainings- und Testdaten unterscheidet, warum ein Modell auswendig lernen kann und wie Güte gemessen wird. Selbst trainieren wirst du in dieser Rolle selten, aber ohne diese Begriffe kannst du weder Ergebnisse einordnen noch mit Data Scientists reden.
Geschafft, wenn: Du kannst eine Gütezahl lesen und sagen, wogegen sie gemessen wurde.
- 3
Mit Sprachmodellen arbeiten und ihre Grenzen kennenlernen
Kontextfenster, Zerlegung in Textbausteine, Temperatur, strukturierte Ausgaben, Aufruf von Werkzeugen. Wichtig ist die Erfahrung, dass dieselbe Eingabe zweimal verschiedene Ausgaben liefern kann und dass sich daraus keine Prüfung mit rotem oder grünem Balken bauen lässt.
Geschafft, wenn: Du erkennst, welche Aufgaben ein Sprachmodell zuverlässig löst und welche nicht.
- 4
Einen Dienst auf eigenen Dokumenten bauen
Dokumente zerlegen, einbetten, in einer Vektorsuche ablegen, Treffer abrufen und mit der Frage zusammen an das Modell geben. Der Lerneffekt steckt in den Details: Wie zerschneidest du eine Tabelle, wie gehst du mit Überschriften um, und was passiert bei Dokumenten in zwei Sprachen.
Geschafft, wenn: Der Dienst antwortet mit Belegstellen, die man nachschlagen kann.
- 5
Ein Prüfset bauen und ab jetzt jede Änderung dagegen messen
Sammle echte Fragen aus dem Fachbereich und halte zu jeder fest, in welchem Dokument die Antwort steht. Miss getrennt, ob der Abruf die Stelle liefert und ob die Antwort sie korrekt verwendet. Ab diesem Punkt hört das Ändern nach Gefühl auf, und das ist der Übergang vom Bastler zum Engineer.
Geschafft, wenn: Du kannst zwei Varianten mit Zahlen vergleichen statt mit Eindrücken.
- 6
Kosten, Antwortzeit und Fehlerverhalten in den Griff bekommen
Miss, was eine Anfrage kostet und wie lange sie dauert, und leg beides auf ein Übersichtsblatt. Bau Zwischenspeicher für wiederkehrende Anteile, schick nur die nötigen Treffer mit, leite einfache Fälle auf ein kleineres Modell und definier, was bei Zeitüberschreitung oder Begrenzung durch den Anbieter passiert.
Geschafft, wenn: Du kannst die monatlichen Kosten bei doppelter Nutzung vorhersagen.
- 7
Absichern und ausrollen
Prüf, was passiert, wenn in einem abgerufenen Dokument eine versteckte Anweisung steht, begrenz die Rechte der Werkzeuge, und protokolliere Ein- und Ausgaben so, dass der Datenschutz mitgeht. Dann leg die Auslieferung in dieselbe Kette wie andere Software, mit Versionsständen für Prompt, Modell und Datenbestand.
Geschafft, wenn: Du kannst benennen, welche Version an einem beliebigen Tag im Einsatz war.
Sechs Fragen, die ein KI-Dienst beantworten muss
- 01 Findet der Abruf die richtige Stelle, unabhängig von der späteren Antwort?
- 02 Was kostet eine Anfrage, und woran hängt dieser Preis im Betrieb?
- 03 Wie lange wartet jemand, bis das erste Zeichen erscheint?
- 04 Was passiert, wenn das Modell ausfällt oder erkennbar Unsinn liefert?
- 05 Welche Werkzeuge darf der Dienst auslösen, und mit welchen Rechten?
- 06 Woran merkst du, dass ein Modellwechsel etwas verschlechtert hat?
Was du danach beantworten kannst, ohne zu raten
Die Rolle besteht aus einer Handvoll Fähigkeiten, die alle darauf hinauslaufen, Behauptungen durch Messungen zu ersetzen. Wer sie hat, führt Diskussionen über Modelle nicht mehr nach Geschmack.
Abruf und Antwort getrennt messen
Bei einem Dienst, der auf Dokumente antwortet, entscheidet sich fast alles im Abruf. Prüf zuerst, ob die richtige Textstelle überhaupt unter den gelieferten Treffern war. Erst wenn das stimmt, ist die Antwortqualität ein Modellthema. Diese Trennung erspart wochenlanges Optimieren am falschen Ende.
Ein Prüfset aufbauen, das bei jeder Änderung durchläuft
Fünfzig bis hundert echte Fragen aus dem Fachbereich, jede mit der Textstelle, in der die Antwort steht. Das ist Handarbeit und der wertvollste Teil des Vorhabens, denn danach ist jede Änderung an Prompt, Zerlegung oder Modell eine Messung statt einer Meinung.
Kosten und Antwortzeit an ihren Ursachen festmachen
Beides hängt vor allem an der Menge Text, die du in jede Anfrage packst. Wer den halben Dokumentbestand mitschickt, zahlt dafür bei jeder einzelnen Anfrage. Zwischenspeicher für wiederkehrende Anteile, kürzere Kontexte und ein kleineres Modell für die einfachen Fälle sind die Hebel, die zuerst greifen.
Eine Rückfallebene einbauen, bevor du sie brauchst
Zeitüberschreitung, Begrenzung durch den Anbieter, ein Modell, das abgekündigt wird: Das sind Betriebsfälle, keine Ausnahmen. Der Dienst braucht ein definiertes Verhalten dafür, und im Zweifel ist eine ehrliche Fehlermeldung besser als eine erfundene Antwort.
Werkzeugrechte eng schneiden
Sobald ein Dienst Werkzeuge aufrufen darf, wird aus einem Textproblem ein Sicherheitsproblem. Die OWASP führt in ihrer Liste zu Sprachmodellanwendungen sowohl das Einschleusen von Anweisungen als auch zu weit gefasste Handlungsvollmachten als eigene Punkte. Praktisch heißt das: lesende Rechte als Vorgabe, schreibende nur mit Bestätigung.
Einen Modellwechsel wie eine Rückschrittsprüfung behandeln
Ein neueres Modell ist nicht in jedem Fall besser für deine Aufgabe. Ohne Prüfset merkst du eine Verschlechterung erst an Beschwerden. Mit Prüfset ist der Wechsel eine Entscheidung mit Zahlen und dauert eine Stunde.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was die Rolle vom Data Scientist und vom DevOps Engineer trennt
Der Data Scientist beantwortet, ob sich etwas aus Daten überhaupt vorhersagen lässt und wie gut. Er arbeitet mit einem festen Datenbestand, misst gegen eine Grundlinie und liefert eine Aussage über Güte und Unsicherheit. Der KI-Engineer beginnt dort, wo diese Aussage vorliegt: Aus dem Modell wird ein Dienst mit Schnittstelle, Kosten, Antwortzeit, Protokoll und einem definierten Verhalten im Fehlerfall.
Vom DevOps Engineer unterscheidet ihn eine Eigenheit, die Auslieferung und Betrieb schwerer macht als bei normaler Software: Dieselbe Eingabe kann verschiedene Ausgaben erzeugen. Es gibt keine Prüfung, die grün oder rot ist, sondern eine Verteilung von Ergebnissen, und ein Modellwechsel beim Anbieter verändert das Verhalten, ohne dass du eine Zeile Code angefasst hast. Wer aus dem Betrieb kommt, muss vor allem diese Umstellung mitmachen.
In kleinen Teams macht dieselbe Person alles davon, und das ist in Ordnung. Der Unterschied bleibt trotzdem wichtig, weil du nach unterschiedlichen Dingen gefragt wirst. Beim Data Scientist lautet die Frage, ob das Ergebnis stimmt. Beim KI-Engineer lautet sie, ob der Dienst am Montagmorgen noch antwortet und was er im Monat gekostet hat.
Der Weg hinein hängt davon ab, was dir fehlt
Aus der Softwareentwicklung ist der Weg am kürzesten. Code, Tests, Schnittstellen und Auslieferung sitzen, es fehlen die Begriffe des maschinellen Lernens und die Erfahrung mit nicht deterministischem Verhalten. Wer aus der Data Science kommt, bringt genau das mit und muss den Betrieb nachholen: Container, Zugriffsverwaltung, Beobachtbarkeit, Umgang mit Ausfällen. Aus dem DevOps-Bereich fehlt beides nicht, aber die Bewertung von Qualität ist ungewohnt, weil sie sich nicht in einen bestehenden Prüflauf einhängen lässt.
Beim Nachweis zählt in dieser Rolle etwas Bestimmtes: ein Dienst, den du gebaut hast, samt Zahlen dazu. Trefferquote des Abrufs vorher und nachher, Kosten pro Anfrage, Antwortzeit, und eine kurze Erklärung, welche Änderung welchen Effekt hatte. Das schlägt jedes Zertifikat, weil es genau die Arbeitsweise zeigt, die im Betrieb gebraucht wird.
Was du dagegen nicht brauchst, ist tiefe Mathematik. Ein Verständnis dafür, was ein Vektor ist und warum sich Ähnlichkeit messen lässt, reicht für den größten Teil der Arbeit. Wer eigene Verfahren entwickeln will, landet in der Forschung, und das ist eine andere Rolle mit anderen Anforderungen.
Der Teil, an dem die meisten Vorhaben hängen bleiben
Bei Diensten, die auf eigene Dokumente antworten, liegt der Fehler fast nie im Modell. Er liegt darin, wie die Dokumente zerlegt wurden, und darin, dass die Suche die richtige Stelle nicht liefert. Eine Tabelle, mitten im Satz zerschnitten, ergibt zwei nutzlose Bausteine. Eine Überschrift, die vom zugehörigen Absatz getrennt wird, nimmt dem Abschnitt den Zusammenhang. Wer hier misst, findet die Ursache in Stunden statt in Wochen.
Der zweite Dauerbrenner sind die Kosten. Sie hängen an der Textmenge je Anfrage, und die wächst schleichend, weil jedes zusätzliche Dokument im Kontext die Antwort ein wenig verbessert. Nach vier Wochen ist der Dienst teuer und niemand weiß genau, wodurch. Ein Übersichtsblatt mit Kosten je Anfrage, Anzahl mitgeschickter Treffer und Antwortzeit gehört deshalb an den Anfang und nicht ans Ende.
Der dritte Punkt ist Sicherheit, und er wird regelmäßig unterschätzt. Anweisungen können nicht nur von Nutzern kommen, sondern auch in Inhalten stecken, die dein Dienst selbst abruft. Die OWASP führt für Anwendungen mit Sprachmodellen unter anderem das Einschleusen von Anweisungen, das Abfließen des Systemprompts und zu weit gefasste Handlungsvollmachten als eigene Punkte auf. Die wirksamste Gegenmaßnahme ist unspektakulär: Rechte klein halten und alles, was etwas verändert, bestätigen lassen.
Woran du wächst und wohin es geht
Zwei Leute mit gleicher Berufsdauer unterscheiden sich daran, ob sie den Fachbereich dazu gebracht haben, Abnahme messbar zu machen. Wer die Frage stellt, welche Antwortqualität ausreicht und woran ihr sie erkennt, hat danach ein Prüfset und eine klare Grenze. Wer sie nicht stellt, verhandelt bis zum Projektende über Eindrücke, und das Vorhaben wird irgendwann leise eingestellt.
Fachlich verzweigt sich die Rolle in mehrere Richtungen. Der Abruf selbst ist ein eigenes Feld geworden, von der Wahl der Einbettungen über hybride Suche bis zur Nachsortierung von Treffern. Daneben stehen Dienste, die selbstständig mehrere Schritte ausführen, wo Zuverlässigkeit und Rechteverwaltung die eigentliche Arbeit sind. Und der Eigenbetrieb von Modellen ist ein Thema für sich, sobald Datenabfluss ausgeschlossen werden muss oder eine dauerhafte Grundlast entsteht.
Der nächste Schritt jenseits einzelner Anwendungen ist die Plattformrolle: gemeinsame Bausteine, Zugriffsverwaltung, Kostenverfolgung und Leitplanken für mehrere Teams. Von dort geht es entweder in die technische Führung eines Teams oder in eine beratende Rolle, in der du entscheidest, welche Vorhaben gar nicht erst gestartet werden. Für die fachliche Steuerung des KI-Einsatzes gibt es dagegen eigene Rollen, die weniger mit Technik und mehr mit Verantwortung zu tun haben.
Warum auf dieser Seite keine Gehaltszahl steht
Die Klassifikation der Berufe, auf der die amtliche Verdienststatistik aufsetzt, hat ihre Systematik aus dem Jahr 2010. Rollen rund um den Betrieb von KI-Diensten gab es zu diesem Zeitpunkt in dieser Form nicht, und eine eigene Berufsgattung ist dafür bis heute nicht vorgesehen. Jede Zahl, die wir dieser Rolle zuordnen würden, wäre die Zuordnung zu einer benachbarten Zelle und damit unsere Entscheidung.
Bei kaum einer anderen Rolle klaffen die kursierenden Angaben so weit auseinander. Sie stammen aus Stellenanzeigen und Selbstauskünften, und in beiden Quellen steckt derselbe Titel für sehr verschiedene Aufgaben, von der Betreuung eines eingekauften Assistenten bis zur Entwicklung einer eigenen Plattform. Ein Mittelwert über solche Fälle ist keine Information.
Belegbar ist die Branchenebene. Das Statistische Bundesamt weist für Information und Kommunikation den durchschnittlichen Bruttojahresverdienst Vollzeitbeschäftigter einschließlich Sonderzahlungen aus. Diese Größe ordnet die Branche ein, nicht die Rolle. Wer für sich selbst eine Einschätzung braucht, kommt weiter, wenn er von seiner heutigen Rolle ausgeht und fragt, was der Wechsel an Verantwortung mit sich bringt, statt eine Zahl aus dem Netz zu übernehmen.
Dazu passende Kurse
Wie Abruf, Evaluation und Auslieferung ineinandergreifen, zeigen die Kurse zum Bau eigener Dienste mit Sprachmodellen an einem Aufbau, der auch unter Last hält.
Wenn dir noch unklar ist, wie tief du einsteigen willst, sortiert die Themenübersicht für technische KI-Rollen das Feld von den Grundlagen bis zum Betrieb.
Warum es zu dieser Rolle keine amtliche Zahl gibt
Für den KI-Engineer gibt es keine amtliche Zahl, weil die Klassifikation der Berufe für KI-Rollen keine eigene Gattung vorsieht und ihre Systematik aus einer Zeit stammt, in der es diese Aufgaben so nicht gab. Alle im Umlauf befindlichen Angaben zu diesem Titel stammen aus Stellenanzeigen oder Selbstauskünften, deren Grundgesamtheit niemand kennt, und derselbe Titel steht dort für sehr verschiedene Aufgabenzuschnitte. Belegbar ist die Branchenebene, also der durchschnittliche Bruttojahresverdienst Vollzeitbeschäftigter in Information und Kommunikation einschließlich Sonderzahlungen. Er ordnet die Branche ein und sagt nichts über diese Rolle.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Brauche ich viel Mathematik, um KI-Engineer zu werden?
Muss ich selbst Modelle trainieren?
Lohnt sich der Eigenbetrieb eines Modells?
Was unterscheidet den KI-Engineer vom Data Scientist?
Passt thematisch dazu
Der Unterschied zum Prototyp steckt in Verpackung, Versionierung und einem erprobten Weg zurück, und was zwischen dem trainierten Modell und einem belastbaren Betrieb liegt , ist im KI-Bereich der Reihe nach beschrieben.
Damit ein Modellwechsel keine Behauptung bleibt, brauchst du eine Zahl pro Durchlauf, und dafür zeigt der KI-Bereich, wie ein Prüfset aus echten Fragen und Sollantworten entsteht .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Vom vorführbaren Prototyp zum abnahmefähigen Dienst
Abruf, Evaluation, Kosten und Absicherung hängen zusammen, und genau diese Kette gehst du bei cmt an einem Aufbau durch, der auch dann noch antwortet, wenn zwanzig Leute gleichzeitig fragen.