LLM-Anwendungsentwicklung gestaltet ein Softwareprodukt, in dem ein Sprachmodell Informationen innerhalb klarer fachlicher, sicherheitstechnischer und betrieblicher Grenzen interpretiert, sucht, transformiert oder erzeugt. Zum Produkt gehören Daten, Workflows, Oberflächen, Evaluation, Autorisierung und Laufzeitkontrollen, nicht nur Modell und Prompt.
Ein Prototyp wirkt stark, weil ein Mensch saubere Beispiele auswählt, Kontext repariert und Fehler toleriert. In Produktion kommen mehrdeutige Anfragen, manipulierte Dokumente, fehlende Evidenz, widersprüchliche Anweisungen, lange Eingaben, gleichzeitige Nutzer, Modelländerungen und ausgefallene Abhängigkeiten. Kann das Team korrektes Verhalten nicht beschreiben, einen Fehler nicht wiederholen oder einen Tool-Aufruf nicht begrenzen, schafft weiteres Prompt-Tuning keine zuverlässige Anwendung.
Beginnen Sie mit einem begrenzten Nutzerentscheid und einem beobachtbaren Abnahmevertrag. Bauen Sie deterministische Software um probabilistische Inferenz. Das Modell darf Klassifikationen, Antworten und Pläne vorschlagen; Anwendungscode erzwingt Identität, Autorisierung, Datenbereich, Schemas, Zustände, Aktionsgrenzen und Freigaben. Evaluieren Sie das Gesamtsystem vor dem Launch und nach jeder Änderung. Flexibilität ist nur wertvoll, wenn Fehler sichtbar, begrenzbar und behebbar sind.
Produktumfang
Definieren Sie den Entscheid vor der Modellinteraktion
„Einen Chatbot bauen“ ist kein Produktvertrag. Ein nützlicher Scope sagt, wer mit welchem Material welches Ergebnis erreicht und was danach passiert. Eine Policy explorativ zusammenzufassen unterscheidet sich von einem Compliance-Entscheid. Eine E-Mail zu entwerfen unterscheidet sich vom Senden. Dieselbe Modellfähigkeit braucht je nach Folgewirkung völlig andere Kontrollen.
Schreiben Sie Abnahmebeispiele in Produktsprache. Ein Evidenzassistent muss jede wesentliche Aussage mit einer zugänglichen Quelle verbinden und bei Widerspruch einen Konflikt zeigen. Ein Extraktionsprodukt braucht kanonisches Schema, Herkunft und einen erlaubten Unknown-Zustand. Ergänzen Sie Verweigerungsfälle. So bleibt die Modellwahl dem Nutzerwert untergeordnet und alle Disziplinen prüfen dasselbe Verhalten.
- Nutzer, Entscheid, Eingabe, Ausgabe und Folgesystem benennen.
- Generierten Vorschlag von autorisierter Aktion trennen.
- Unknown-, Konflikt- und Eskalationsverhalten festlegen.
- Irreversible Aktionen als eigene Gates gestalten.
- Jede Launch-Aussage mit Evaluation belegen.
Qualitätssystem
Der Evaluationskorpus ist Produktbestandteil
Modellbenchmarks sagen wenig über den eigenen Workflow. Bauen Sie den Korpus aus den erwarteten Verteilungen. Normale Fälle verhindern, dass nur spektakuläre Ränder optimiert werden. Schwierige Fälle decken Dokumentqualität, Mehrdeutigkeit, langen Kontext, mehrsprachige Begriffe, fehlende Quellen und feindliche Anweisungen ab. Bewerten Sie relevante Eigenschaften statt eines vagen Gesamtscores.
Prüfen Sie Komponenten und End-to-End. Retrieval zeigt verfügbare Evidenz, Antworttests Beleg und Vollständigkeit, Tool-Simulation Autorisierung und Parameter, Nutzerreview den tatsächlichen Abschluss. Speichern Sie Modell-, Prompt-, Index-, Tool- und Policy-Version. Ein Produktionsvorfall wird reproduziert, die Kontrolle korrigiert und als minimierter Regressionstest aufgenommen.
| Schicht | Frage | Mass |
|---|---|---|
| Retrieval | Wurde nutzbare Evidenz gefunden? | Recall und zugriffskorrekte Relevanz |
| Generierung | Ist die Ausgabe belegt und vollständig? | Aussagenbeleg und Rubrik |
| Struktur | Kann Software sie sicher nutzen? | Schema- und Invariantenquote |
| Aktion | Ist die vorgeschlagene Operation erlaubt? | Autorisierung und Argumente |
| Ergebnis | Hat der Nutzer den Job beendet? | Erfolg, Korrektur und Eskalation |
Sicherheit
Modellanweisungen beeinflussen, sie erzwingen nicht
OWASP führt Prompt Injection als zentrales Risiko auf und betont, dass Retrieval oder Fine-Tuning es nicht beseitigt. Jeder gelesene Text kann konkurrierende Anweisungen enthalten, auch ein Dokument aus einer vertrauenswürdigen Ablage. Trennzeichen und Prompts reduzieren Verwechslung, sind aber keine Autorisierung. Die Anwendung muss annehmen, dass das Modell etwas ausserhalb der Policy vorschlagen kann.
Deterministische Schichten erzwingen Grenzen. Filtern Sie Retrieval nach authentifiziertem Nutzer. Validieren Sie Ausgabe vor Anzeige oder Ausführung. Binden Sie Tools an enge serverseitige Identitäten und prüfen Sie jeden Aufruf. Credentials gehören nicht in Prompts. Trennen Sie Vorschlag und Ausführung und verlangen Sie für wesentliche Wirkungen eine Bestätigung. Testen Sie direkte Angriffe und versteckte Instruktionen in Dokumenten, Bildern und Tool-Ergebnissen.
- Geladene und abgerufene Inhalte als nicht vertrauenswürdig behandeln.
- Identität und Autorisierung ausserhalb des Modells lösen.
- Task-spezifische Minimalrechte für Tools verwenden.
- Argumente und Ergebnisse an jeder Grenze validieren.
- Menschliches Gate für folgenreiche Aktionen erhalten.
Betrieb
Für Änderung, Teilausfall und Replay entwerfen
LLM-Anwendungen hängen von Modellendpunkten, Indizes, Speicher, Policies und Tools ab. Alles kann langsam werden, ausfallen oder Form ändern. Definieren Sie Timeouts, begrenzte Wiederholungen, Idempotenz und Fallbacks pro Operation. Eine Read-only-Zusammenfassung lässt sich oft wiederholen; Zahlung oder Nachricht nicht blind. Geben Sie Pending oder Failed aus, statt dass das Modell einen unbestätigten Erfolg erzählt.
Observability soll Verhalten rekonstruieren, aber keinen unkontrollierten Datensee schaffen. Erfassen Sie Versionen, Zeiten, Token, Retrieval-Referenzen, Validierung, Tool-Status und Nutzerergebnis. Reduzieren oder redigieren Sie sensible Payloads nach legitimem Debugging-Bedarf. Canary-Releases vergleichen Qualität, Latenz und Kosten. Ein verlässliches Team kann Version, Quellenauswahl und tatsächlichen externen Status jeder Ausführung erklären.
- Prompts, Modelle, Indizes, Schemas, Tools und Policies versionieren.
- Seiteneffekte idempotent und separat bestätigt machen.
- Modellabschluss vom Geschäftsabschluss unterscheiden.
- Latenz- und Kostenbudget pro Ergebnis festlegen.
- Rollback und Replay für jeden Release erhalten.
Woran gute Arbeit erkennbar ist
Konkrete Ergebnisse für LLM-Anwendungsentwicklung
- Der erste Release löst einen benannten Job für einen benannten Nutzer mit Nicht-Zielen und Eskalation.
- Ein versionierter Evaluationssatz enthält normale, schwierige, mehrdeutige, mehrsprachige und adversariale Fälle.
- Abgerufener Kontext trägt Quelle, Zugriffsbereich, Aktualität und nutzbare Zitate.
- Strukturierte Ausgaben werden vor Datenbank, Oberfläche oder Folgesystem validiert.
- Tools arbeiten mit Minimalrechten, serverseitiger Autorisierung, begrenzten Parametern und menschlicher Freigabe bei wesentlichen Aktionen.
- Traces verbinden Eingabe, Kontext, Prompt, Modell, Ausgabe, Validierung, Tool und Ergebnis ohne unnötige sensible Daten.
- Modell-, Prompt- oder Retrieval-Änderungen werden vor Rollout nach Qualität, Latenz, Kosten und Risiko verglichen.
- Bei unzureichender Evidenz, Unsicherheit oder Abhängigkeit erhält der Nutzer Abstention oder Übergabe.
Betriebsmodell
So wird die Arbeit ausgeführt
- 01
Job und Abnahmevertrag definieren
Beschreiben Sie Nutzer, Auslöser, Eingabe, erwartete Ausgabe, Folgeentscheid und Fehlerkosten. Listen Sie Nicht-Ziele, verbotene Aktionen und Fälle für Menschen auf. Wandeln Sie Wunschverhalten vor der Architekturwahl in Beispiele und messbare Kriterien um.
- 02
Zuerst den Evaluationskorpus bauen
Sammeln Sie sichere repräsentative Fälle aus Normalverkehr, Randfällen, schlechten Dokumenten, mehreren Sprachen, fehlender Evidenz und feindlichen Anweisungen. Beschriften Sie Fakten, Zitate, Formate, Entscheide und Zurückhaltung. Versionieren Sie die Daten und schützen Sie einen Holdout.
- 03
Kontext und Vertrauensgrenzen gestalten
Bestimmen Sie Quellen von Nutzer, System, Retrieval, Memory und Tools. Behandeln Sie externen Text als nicht vertrauenswürdige Daten. Erzwingen Sie Zugriff vor Retrieval, minimieren Sie Kontext, markieren Sie Herkunft und trennen Sie Instruktion von Inhalt. Definieren Sie Aufbewahrung und Löschung.
- 04
Ausgaben und Aktionen absichern
Nutzen Sie begrenzte Schemas und validieren Sie Typen, Werte, Referenzen und Fachregeln. Lösen Sie Autorisierung im Code. Tools erhalten enge Credentials, Idempotenz und Limits. Senden, Kaufen, Löschen, Signieren und wesentliche Änderungen benötigen ausdrückliche Zustimmung.
- 05
Über gemessene Releases betreiben
Führen Sie Offline-Evaluation, Security-, Last- und Human-Tests vor einem Canary durch. Beobachten Sie Qualität, Latenz, Kosten, Abstention, Overrides und Vorfälle je Version. Halten Sie Fälle reproduzierbar, rollen Sie Regressionen zurück und ergänzen Sie sichere Produktionsfehler.
Bewertung
Fragen, die den Entscheid verändern
- Braucht der variable Teil wirklich ein LLM oder sind Regeln, Suche oder klassische Modelle verlässlicher?
- Welches kleinste Nutzerergebnis lässt sich unabhängig evaluieren?
- Welche Quellen dürfen Kontext werden und wie gelten Zugriff, Aktualität und Herkunft?
- Welche Ausgaben beraten, welche ändern Zustand und welche brauchen verantwortliche Freigabe?
- Braucht das System Retrieval, Fine-Tuning, Tools oder eine Kombination?
- Welche Latenz-, Verfügbarkeits-, Kosten- und Datenanforderungen bestimmen Modell und Betrieb?
- Wie kann ein Nutzer Ergebnis prüfen, korrigieren, anfechten oder rückgängig machen?
- Welche Evidenz erlaubt die Beförderung einer neuen Modell-, Prompt-, Index- oder Tool-Version?
Fehlermuster
Wo Teams die Kontrolle verlieren
Eine flüssige Antwort kann falsch, unbelegt oder am tatsächlichen Entscheid vorbei sein.
Direkte und indirekte Prompt Injection kann über Nutzer, Dateien, Webseiten oder Tool-Ergebnisse wirken.
Retrieval ohne Zugriffsfilter kann Inhalte offenlegen, die der Nutzer an der Quelle nicht öffnen darf.
Secrets oder Autorisierungslogik im Systemprompt verwechseln Instruktion mit Sicherheitsgrenze.
Unvalidierte Ausgabe kann als Code, Query, Markup oder Aktion klassische Injection verursachen.
Breite Agenten-Tools können einen kleinen Deutungsfehler in eine irreversible Aktion verstärken.
Modell- oder Provider-Updates können Verhalten ohne Codeänderung verschieben.
Observability kann sensible Prompts, Dokumente und Ausgaben über Bedarf hinaus sammeln.
Durchschnittsgenauigkeit kann schwere Fehler in einer Sprache oder Risikogruppe verdecken.
Unbegrenzter Kontext und Retries erzeugen instabile Latenz und Kosten.
Messung
Das fertige Ergebnis messen
Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.
- Task-Erfolg auf versioniertem Evaluationssatz und geschütztem Holdout
- Belegabdeckung und Zitatkorrektheit für evidenzpflichtige Aussagen
- kritische Fehlerrate nach Fall, Sprache und Risikokategorie
- angemessene Zurückhaltung und Eskalation bei Lücken oder Mehrdeutigkeit
- Schemafehler und reparierte strukturierte Antworten
- vor Ausführung gestoppte unautorisierte oder zu breite Tool-Aufrufe
- Nutzerkorrekturen, Overrides und wieder geöffnete Ergebnisse
- End-to-End-Latenz nach Perzentil und erfolgreichem Pfad
- Modell-, Retrieval-, Speicher- und Trace-Kosten pro Ergebnis
- vor Rollout erkannte Regressionen und Zeit bis zum sicheren Rollback
Fragen
Häufige Fragen
Was gehört zur Entwicklung einer LLM-Anwendung?
Dazu gehören Produktscope, Daten und Kontext, Modellintegration, Retrieval, Evaluation, Oberfläche, strukturierte Ausgaben, Sicherheit, Tool-Autorisierung, Observability, Deployment und Betrieb. Der Prompt ist eine versionierte Komponente.
Sollten wir RAG oder Fine-Tuning nutzen?
Retrieval eignet sich für aktuelles, zitierbares und zugriffsgesteuertes Wissen. Fine-Tuning kann Verhalten und wiederkehrende Muster spezialisieren. Keines löst automatisch Autorisierung, Injection, Faktenbeleg oder Evaluation; manche Aufgaben brauchen beides nicht.
Wie testet man eine LLM-Anwendung?
Mit einem repräsentativen versionierten Korpus aus Fakten, Quellen, Formaten, Aktionen und Abstentions. Testen Sie Retrieval, Generierung, Schemas, Tools und Nutzerergebnis einzeln und zusammen, auch mehrsprachig, mehrdeutig und adversarial.
Darf eine LLM-Anwendung autonom handeln?
Sie kann begrenzte Aktionen vorschlagen und ausführen, aber Autorisierung gehört in den Code. Nutzen Sie Minimalrechte, validierte Parameter, Idempotenz, Audit und ausdrückliche menschliche Freigabe für folgenreiche oder externe Aktionen.
Quellen
Primärquellen
- Ressourcen zum AI Risk Management Framework National Institute of Standards and Technology
- LLM01:2025 Prompt Injection OWASP GenAI Security Project
- Cheat Sheet zur Vermeidung von Prompt Injection OWASP Foundation
Über den Autor
Tony Kim
Tony schreibt über angewandte AI, verlässliches Product Engineering und Systeme, die komplexe Response-Arbeit kontrollierbar machen.
Zeke
AI Product Engineering, das aus einem Software-Briefing ein zuverlässiges Produkt im Betrieb macht.
Produktverantwortliche, Gründungsteams und Software-Engineering-Teams. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.
Zeke ansehen→