Stellen Sie sich vor, Sie haben gerade 50.000 Euro in die Entwicklung eines Prototyps gesteckt, der Kundenanfragen automatisch beantworten soll. In der Demo sah alles fantastisch aus. Doch kaum geht das System live, fängt es an, Halluzinationen zu produzieren, die Ihre Rechtsabteilung nachts nicht schlafen lassen. Ein Kunde fragt nach einer Erstattung, und das Modell verspricht ihm nicht nur das Geld zurück, sondern legt noch einen Gutschein oben drauf, den es gar nicht gibt. Ich habe dieses Szenario in den letzten Jahren immer wieder beobachtet. Der Fehler liegt fast nie am Modell selbst, sondern an der naiven Herangehensweise beim AI Engineering Building Applications With Foundation Models. Wer glaubt, dass ein paar geschickte Prompts ausreichen, um eine produktionsreife Software zu bauen, hat bereits verloren, bevor die erste Zeile Code überhaupt geschrieben wurde. In der Praxis geht es nicht um Magie, sondern um knallharte Ingenieursarbeit, bei der die unberechenbare Natur statistischer Sprachmodelle gezähmt werden muss.
Der Irrglaube an die Allmacht des Prompts beim AI Engineering Building Applications With Foundation Models
Viele Teams starten mit der Annahme, dass Prompt Engineering die wichtigste Disziplin sei. Sie verbringen Wochen damit, die perfekte Formulierung zu finden, hängen „Du bist ein Experte" oder „Atme tief durch" an ihre Anweisungen an und wundern sich, warum die Ergebnisse trotzdem schwanken. Das ist kein Ingenieurswesen, das ist Alchemie. In der echten Welt der Softwareentwicklung ist ein System, dessen Verhalten sich durch das Ändern eines einzigen Adjektivs massiv verändert, schlichtweg unbrauchbar. Erfahren Sie mehr zu einem verwandten Sachverhalt: diesen verwandten Artikel.
Das Problem ist die fehlende Reproduzierbarkeit. Wenn ich in meiner Laufbahn eines gelernt habe, dann das: Ein Prompt ist kein Code. Er ist eine vage Richtlinie für eine Blackbox. Wer sich zu sehr auf das Feintuning von Sätzen verlässt, baut auf Sand. Stattdessen müssen wir Strukturen schaffen, die das Modell in Leitplanken zwingen. Das bedeutet, dass wir Logik aus dem Sprachmodell herauslösen und in klassischen Code überführen müssen, wo immer es möglich ist. Ein Modell sollte niemals entscheiden müssen, wie eine mathematische Berechnung durchgeführt wird oder wie ein Datenbank-Schema aussieht. Es sollte lediglich die Absicht des Nutzers interpretieren und die Rohdaten liefern, die dann von stabilen, deterministischen Algorithmen verarbeitet werden.
Die Falle der Demo-Gläubigkeit und das Skalierungsproblem
Ein Prototyp ist in zwei Stunden zusammengeklickt. Das ist die große Gefahr dieser Technologie. Man zeigt dem Chef eine beeindruckende Interaktion, und alle denken, man sei zu 90 Prozent fertig. In Wahrheit ist man bei vielleicht 10 Prozent. Der Weg von der Demo zur Produktion ist kein kleiner Schritt, sondern ein Marathon durch ein Minenfeld. Golem.de hat dieses wichtige Sachgebiet ausführlich analysiert.
Ich erinnere mich an ein Projekt eines mittelständischen Dienstleisters. Sie hatten einen Chatbot gebaut, der interne Dokumente durchsuchte. In der Testphase mit fünf handverlesenen Dokumenten funktionierte alles tadellos. Als sie das System auf 50.000 Dokumente skalierten, brach die Genauigkeit komplett ein. Das Modell fand zwar Informationen, aber oft die falschen oder veraltete Versionen. Sie hatten die Komplexität des Information Retrieval völlig unterschätzt.
Beim Aufbau solcher Systeme ist die Qualität der Datenvorbereitung oft wichtiger als das Modell selbst. Wie man Texte schneidet, wie man sie indiziert und wie man die Relevanz bewertet, sind die eigentlichen Baustellen. Wer hier spart, zahlt später doppelt, wenn die Cloud-Rechnung für sinnlose API-Aufrufe explodiert, während die Nutzer frustriert aufgeben.
Fehlende Evaluierung ist der sicherste Weg zum Scheitern
Wie wissen Sie, dass Ihr System heute besser ist als gestern? „Es fühlt sich besser an" ist keine Antwort, mit der man ein Unternehmen führt. Dennoch ist das genau das Niveau, auf dem viele Projekte operieren. Es gibt keine automatisierten Tests, keine Benchmarks, keine Gold-Standard-Datensätze.
Warum manuelle Tests nicht ausreichen
Manuelles Testen durch Menschen ist teuer, langsam und subjektiv. Wenn Sie eine Änderung am System vornehmen, müssten Sie theoretisch hunderte von Testfragen erneut prüfen, um sicherzustellen, dass Sie an einer Stelle nichts kaputt gemacht haben, während Sie an einer anderen etwas repariert haben. Ohne eine automatisierte Evaluierungspipeline tappen Sie im Dunkeln.
Ein echter Praktiker baut zuerst die Testumgebung und erst dann die Anwendung. Das bedeutet, dass man sich einen Satz von kritischen Fragen und den dazugehörigen korrekten Antworten erstellt. Jede Änderung am System wird gegen diesen Datensatz geprüft. Erst wenn die Zahlen schwarz auf weiß zeigen, dass die Trefferquote steigt, wird der Code übernommen. Das ist mühsam, ja. Es ist weniger aufregend als mit neuen Modellen herumzuspielen. Aber es ist der einzige Weg, um nicht blind in eine Katastrophe zu steuern.
Der Irrtum beim AI Engineering Building Applications With Foundation Models bezüglich der Kosten
Es herrscht die Vorstellung, dass die Kosten mit der Zeit sinken werden. Das mag für die reine Rechenleistung stimmen, aber nicht für die Komplexität des Systems. Viele unterschätzen die laufenden Kosten für Überwachung und Wartung. Ein Modell ist kein statisches Objekt. Die Welt verändert sich, die Nutzererwartungen steigen, und die Anbieter der Schnittstellen ändern ihre Modelle im Hintergrund, oft ohne Vorwarnung.
Ein Vorher/Nachher-Vergleich macht das deutlich.
Stellen Sie sich ein Unternehmen vor, das eine KI-gestützte Analyse für Marktberichte baut.
Der falsche Ansatz sieht so aus: Man schickt den gesamten Text eines 50-seitigen Berichts an das teuerste verfügbare Modell, nutzt einen riesigen Prompt und hofft auf eine gute Zusammenfassung. Das kostet pro Bericht etwa 50 Cent an Token-Gebühren. Bei 1.000 Berichten am Tag sind das 500 Euro. Die Qualität ist schwankend, weil das Modell bei zu viel Kontext wichtige Details übersieht. Wenn das Modell aktualisiert wird, ändert sich das Format der Ausgabe, und die nachgelagerten Systeme stürzen ab.
Der richtige Ansatz: Man nutzt ein kleineres, spezialisiertes Modell, um den Bericht erst einmal in relevante Abschnitte zu unterteilen. Diese Abschnitte werden dann gezielt analysiert. Man verwendet strukturierte Ausgabeformate wie JSON, die strikt validiert werden. Die Kosten sinken auf 5 Cent pro Bericht. Das System ist schneller, die Ergebnisse sind präzise und lassen sich in einer Datenbank speichern, statt nur als Textblock zu existieren. Man hat die Kontrolle über den Prozess zurückgewonnen.
Kontextfenster sind keine Datenbanken
Ein häufiger Fehler besteht darin, das Kontextfenster der Modelle als eine Art flüchtigen Arbeitsspeicher für alles Mögliche zu missbrauchen. Nur weil ein Modell jetzt 100.000 oder mehr Wörter gleichzeitig verarbeiten kann, heißt das nicht, dass man es mit Daten füttern sollte, die man eigentlich ordentlich strukturieren müsste.
Je mehr Informationen man in den Kontext packt, desto mehr „Rauschen" erzeugt man. Modelle neigen dazu, Informationen in der Mitte eines langen Textes zu ignorieren – ein Phänomen, das als „Lost in the Middle" bekannt ist. Wer darauf setzt, dass das Modell schon irgendwie die Nadel im Heuhaufen findet, wird enttäuscht.
Erfolgreiche Anwendungen nutzen kluge Retrieval-Mechanismen. Man sucht erst außerhalb des Modells nach den relevanten Schnipseln und präsentiert dem Modell nur das, was es wirklich zur Beantwortung der Frage braucht. Das spart nicht nur Geld, sondern erhöht die Zuverlässigkeit massiv. Wer das ignoriert, baut Systeme, die zwar beeindruckend klingen, aber in kritischen Momenten versagen, weil sie den Überblick verlieren.
Sicherheit und Datenschutz sind keine optionalen Add-ons
In Deutschland und Europa haben wir strengere Regeln als im Silicon Valley. Das ist kein Hindernis, sondern eine Rahmenbedingung. Wer glaubt, er könne einfach Nutzerdaten an eine externe API in den USA schicken, ohne sich Gedanken über die DSGVO oder Geschäftsgeheimnisse zu machen, handelt grob fahrlässig.
Es geht aber nicht nur um rechtliche Fragen. Es geht um Prompt Injection und Jailbreaking. Es gibt Leute, die nichts lieber tun, als Ihren Chatbot so zu manipulieren, dass er beleidigende Dinge sagt oder interne Systemanweisungen preisgibt. Wenn Ihr System direkten Zugriff auf Datenbanken oder E-Mail-Konten hat, wird aus einem lustigen Streich schnell ein ernsthafter Sicherheitsvorfall.
In meiner Praxis habe ich gesehen, wie Firmen ganze Projekte stoppen mussten, weil sie das Thema Sicherheit erst am Ende angehen wollten. Man muss von Anfang an davon ausgehen, dass der Nutzer bösartig ist. Jede Eingabe muss gefiltert, jede Ausgabe validiert werden. Das Modell darf niemals der letzte Entscheidungsträger sein, wenn es um kritische Aktionen geht. Es braucht eine Schicht aus klassischem Code, die prüft, ob das, was die KI vorschlägt, überhaupt zulässig und sinnvoll ist.
Der ehrliche Realitätscheck
Lassen wir die Begeisterung einmal beiseite. Der Aufbau von Anwendungen auf Basis von Sprachmodellen ist derzeit eine der frustrierendsten Aufgaben in der Softwareentwicklung. Es ist eine Arbeit mit Werkzeugen, die heute funktionieren und morgen schon veraltet sein können. Wer Erfolg haben will, muss bereit sein, sich die Hände schmutzig zu machen.
Das bedeutet:
- Man muss akzeptieren, dass 80 Prozent der Arbeit aus Datenreinigung und Evaluierung bestehen.
- Man darf sich nicht von glänzenden Marketing-Demos blenden lassen.
- Man braucht Entwickler, die verstehen, wie man Wahrscheinlichkeiten bändigt, statt nur Funktionen aufzurufen.
Es gibt keine Abkürzung. Wenn Sie hoffen, dass die KI Ihnen die harte Arbeit des Softwaredesigns abnimmt, werden Sie scheitern. Die KI ist eine Komponente, ein mächtiges Werkzeug, aber sie ist nicht der Architekt. Wer das begreift und die Disziplin aufbringt, klassische Ingenieursprinzipien auf diese neue Welt anzuwenden, wird am Ende Systeme haben, die tatsächlich einen Wert liefern. Alle anderen werden weiterhin Prototypen bauen, die niemals das Licht der Welt erblicken oder im schlimmsten Fall teure Schäden anrichten.
Es ist nun mal so: Wahre Innovation entsteht nicht durch das Drücken eines Knopfs, sondern durch das Verstehen der Grenzen dessen, was man gerade baut. Hören Sie auf zu hoffen und fangen Sie an zu messen. Das ist der einzige Rat, der wirklich zählt. Wenn Ihre Tests nicht belegen, dass Ihr System funktioniert, dann funktioniert es auch nicht, egal wie toll die Antwort im Einzelfall aussieht. Das ist die unbequeme Wahrheit, die man akzeptieren muss, wenn man in diesem Feld bestehen will.
