Der Paradigmenwechsel von 2023
Anfang 2023 hat sich etwas Fundamentales verändert. Mit GPT-4 und der rasanten Entwicklung von Frameworks wie LangChain ist Künstliche Intelligenz von einem akademischen Thema zu einem praktischen Werkzeug für die Softwareentwicklung geworden. Als Softwarearchitekten stehen wir vor der Frage: Was bedeutet das konkret für unsere Systeme?
Die Antwort ist differenzierter, als die meisten Blogposts vermuten lassen. LLMs sind weder die Lösung für alles noch eine vorübergehende Modeerscheinung. Sie sind ein neues Werkzeug in unserem Baukasten, mit klaren Stärken und ebenso klaren Grenzen.
Was Prompt Engineering wirklich bedeutet
Prompt Engineering wird oft missverstanden. Es geht nicht darum, möglichst kreative Anweisungen an ein Sprachmodell zu formulieren. Aus Architektursicht ist Prompt Engineering die systematische Gestaltung der Schnittstelle zwischen deterministischer Software und probabilistischem Sprachmodell.
In der Praxis umfasst das mehrere Aspekte:
- System Prompts definieren das Verhalten des Modells, vergleichbar mit einer Interface-Spezifikation
- Few-Shot Examples liefern dem Modell Kontext über das erwartete Ein-/Ausgabeformat
- Chain-of-Thought Prompting zerlegt komplexe Aufgaben in nachvollziehbare Schritte
- Output Parsing stellt sicher, dass die Antwort des Modells maschinell verarbeitbar ist
Der entscheidende Punkt: Prompts sind Code. Sie müssen versioniert, getestet und gewartet werden wie jede andere Schnittstelle auch.
RAG, Retrieval-Augmented Generation
Das aus Architektursicht interessanteste Pattern ist RAG (Retrieval-Augmented Generation). Statt ein LLM mit riesigen Datenmengen zu fine-tunen, kombiniert RAG ein vortrainiertes Modell mit einer externen Wissensbasis.
Der Ablauf ist klar strukturiert:
- Embedding-Erstellung, Dokumente werden in Vektoren umgewandelt und in einer Vektordatenbank gespeichert (z.B. Pinecone, Weaviate, pgvector)
- Semantische Suche, Bei einer Nutzeranfrage wird der Eingabetext ebenfalls in einen Vektor umgewandelt und die ähnlichsten Dokumente ermittelt
- Kontextanreicherung, Die gefundenen Dokumente werden als Kontext an das LLM übergeben
- Generierung, Das LLM generiert eine Antwort basierend auf dem bereitgestellten Kontext
Dieses Pattern löst ein zentrales Problem: LLMs haben einen Wissensstand, der mit dem Training endet. RAG ermöglicht aktuelle und domänenspezifische Antworten, ohne das Modell neu trainieren zu müssen.
Embedding-basierte Suche in der Praxis
Die Qualität eines RAG-Systems steht und fällt mit der Embedding-Strategie. Einige Erkenntnisse aus unseren ersten Experimenten:
- Chunk Size ist entscheidend, zu große Chunks verwässern die Semantik, zu kleine verlieren den Kontext. 500-1000 Tokens haben sich als brauchbarer Startpunkt erwiesen
- Overlap zwischen Chunks verhindert, dass relevante Informationen an Chunk-Grenzen verloren gehen
- Metadaten wie Dokumenttyp, Erstellungsdatum oder Autor verbessern die Relevanz der Suchergebnisse erheblich
Langchain als Orchestrierungsframework
Langchain hat sich 2023 als De-facto-Standard für die LLM-Integration etabliert. Das Framework abstrahiert den Zugriff auf verschiedene Modelle und bietet Bausteine für typische Patterns:
- Chains verknüpfen mehrere LLM-Aufrufe zu einer Pipeline
- Agents ermöglichen dem Modell, eigenständig Tools aufzurufen
- Memory verwaltet den Gesprächskontext über mehrere Interaktionen
- Retrievers kapseln die Anbindung an Vektordatenbanken
Aus Architektursicht ist Langchain vergleichbar mit Spring Boot für LLM-Anwendungen: Es reduziert Boilerplate und etabliert Konventionen. Gleichzeitig birgt es das Risiko einer engen Kopplung an das Framework, die gleiche Abwägung, die wir von anderen Frameworks kennen.
Architektonische Überlegungen
Bei der Integration von LLMs in bestehende Systeme gelten die gleichen Prinzipien wie bei jeder anderen externen Abhängigkeit:
Adapter Pattern für LLM-Integration
public interface TextAnalyzer {
AnalysisResult analyze(String text);
}
public class OpenAiTextAnalyzer implements TextAnalyzer {
// GPT-4 Implementierung
}
public class LocalLlmTextAnalyzer implements TextAnalyzer {
// Lokales Modell als Fallback
}
Die Geschäftslogik kennt nur das Interface. Ob dahinter GPT-4, ein lokales Modell oder ein regelbasierter Fallback steht, ist austauschbar.
Latenz und Fehlerbehandlung
LLM-Aufrufe sind langsam (Sekunden, nicht Millisekunden) und nicht deterministisch. Das erfordert:
- Timeouts und Circuit Breaker, ein nicht antwortender LLM-Service darf das Gesamtsystem nicht blockieren
- Caching, identische Anfragen sollten nicht wiederholt ans Modell gesendet werden
- Fallback-Strategien, was passiert, wenn das Modell nicht verfügbar ist?
- Idempotenz, gleiche Eingaben können unterschiedliche Ausgaben erzeugen
Kosten und Skalierung
LLM-Aufrufe kosten Geld, pro Token. Bei hohem Durchsatz summiert sich das schnell. Strategien zur Kostenkontrolle:
| Strategie | Beschreibung |
|---|---|
| Token-Budgets | Maximale Token-Anzahl pro Anfrage begrenzen |
| Modell-Routing | Einfache Anfragen an günstigere Modelle delegieren |
| Caching | Häufige Anfragen zwischenspeichern |
| Batch Processing | Anfragen bündeln statt einzeln verarbeiten |
Was LLMs nicht ersetzen
Ein Punkt, der in der aktuellen Euphorie oft untergeht: LLMs ersetzen keine Softwarearchitektur. Sie ersetzen keine Tests. Sie ersetzen kein Code Review. Sie sind ein Werkzeug, ein mächtiges, aber eines mit klaren Grenzen.
Für sicherheitskritische Entscheidungen, deterministische Geschäftslogik oder regulierte Prozesse sind LLMs ungeeignet. Sie halluzinieren. Sie sind nicht reproduzierbar. Sie haben keine Garantien.
Fazit
Prompt Engineering und LLM-Integration sind für Softwarearchitekten relevante Themen, nicht als Ersatz für bewährte Prinzipien, sondern als Ergänzung. Die Kunst liegt darin, die Stärken probabilistischer Modelle zu nutzen, ohne die Zuverlässigkeit deterministischer Systeme zu opfern. Wer die Grundprinzipien sauberer Architektur beherrscht, Entkopplung, Abstraktion, Testbarkeit, kann LLMs als ein weiteres externes System integrieren. Nicht mehr, aber auch nicht weniger.