Was macht KI-Ingenieur?
Experte für die Entwicklung produktionsreifer LLM-Anwendungen – von einfachen Chatbots bis hin zu komplexen Multi-Agenten-Systemen. Spezialisiert auf RAG-Architekturen, Vektordatenbanken, Prompt-Management und Enterprise-KI-Bereitstellungen.
Entscheidungspunkte
Auswahl der RAG-Komponente
Bewertung der Abfrageart:
├── Einfaches FAQ / Wissensabruf
│ ├── Dokumentenanzahl < 1000 → Chroma + text-embedding-3-small
│ └── Dokumentenanzahl > 1000 → Pinecone + text-embedding-3-large
├── Technische / Code-Dokumentation
│ ├── Budget eingeschränkt → bge-large + pgvector
│ └── Leistungskritisch → voyage-2 + Weaviate
└── Konversationell / Multi-Turn
├── Speicher erforderlich → Agentenmuster + Kontextverwaltung
└── Zustandslos → Standard-RAG-Pipeline
Entscheidung zum Re-Ranking:
├── Präzision kritisch (Recht, Medizin) → Immer Cohere Rerank verwenden
├── Latenz < 200ms → Kein Re-Ranking, Retrieval optimieren
├── Budget eingeschränkt → Cross-Encoder (bge-reranker-large)
└── Standard → Cohere Rerank mit top-10 → top-3
Datenbankauswahl:
├── Vorhandenes Postgres → pgvector-Erweiterung
├── Hybride Suche erforderlich → Weaviate oder Qdrant
├── Verwalteter Dienst → Pinecone
└── Selbst gehostet / Lokal → Chroma oder Qdrant
Strategie für Modell-Routing
Komplexitätsbewertung:
├── Nur Stichwörter (FAQ) → Claude Haiku
├── Einzelne Dokumentreferenz → Claude Sonnet
├── Multi-Dokument-Synthese → Claude Opus
└── Codegenerierung → Claude Sonnet mit Tools
Token-Budget-Prüfung:
├── < 1K Tokens → Beliebiges Modell
├── 1K-4K Tokens → Sonnet/GPT-4
├── 4K-32K Tokens → Claude Opus
└── > 32K Tokens → Zuerst chunkweise verarbeiten und zusammenfassen
Entscheidung: Agent vs. RAG
Aufgabenklassifizierung:
├── Statischer Wissensabruf → Reines RAG
├── Externe APIs erforderlich → Agent mit Tools
├── Mehrschrittige Schlussfolgerung → Agent mit Planung
├── Echtzeitdaten erforderlich → Agent mit Live-Tools
└── Einfaches Frage & Antwort → RAG mit Fallback auf Agent
Fehlermodi
Kaskade semantischer Fehlanpassungen
Symptome: Gute Retrieval-Präzision, aber schlechte Antwortrelevanz; Nutzer sagen „nahe dran, aber nicht ganz richtig“ Erkennungsregel: Wenn semantische Ähnlichkeit > 0,8, aber Nutzerzufriedenheit < 60% Ursache: Abfrage- und Dokumenten-Embeddings für unterschiedliche semantische Räume optimiert Behebung: Auf domänenspezifisches Embedding-Modell wechseln oder Abfrageerweiterung mit Synonymen implementieren
Kontextfenster-Überlauf
Symptome: Antworten werden allgemein, das Modell ignoriert spezifisch abgerufene Kontexte, inkonsistente Antworten Erkennungsregel: Wenn Kontextnutzungsrate < 30% und Antwortgeneralisierungs-Score > 0,7 Ursache: Zu viele irrelevante Chunks verwässern die relevanten Informationen Behebung: Strengeren Relevanzschwellenwert (>0,8) und dynamische Kontextauswahl implementieren
Tool-Halluzinations-Schleife
Symptome: Der Agent erfindet API-Aufrufe, referenziert nicht existierende Funktionen, endlose Wiederholungszyklen Erkennungsregel: Wenn Tool-Aufruf-Erfolgsrate < 50% oder Iterationsanzahl > max_iterations * 0,8 Ursache: Modell wurde mit anderen Tool-Schemata trainiert als der Implementierung Behebung: Tool-Validierungsschicht und explizite Fehlerbehandlung im Agenten-Systemprompt hinzufügen
Verschlechterung durch Embedding-Drift
Symptome: Allmählicher Rückgang der Retrieval-Qualität im Laufe der Zeit, saisonale Leistungseinbrüche Erkennungsregel: Wenn monatlicher Durchschnitt retrieval@5 um > 10% vom Basiswert abfällt Ursache: Die Domänensprache entwickelt sich weiter, aber das Embedding-Modell bleibt statisch Behebung: Pipeline zum Nachtrainieren des Embedding-Modells implementieren oder auf adaptive Embeddings umstellen
Anstieg der Antwortlatenz
Symptome: P95-Latenz steigt allmählich, Nutzer beschweren sich über langsame Antworten Erkennungsregel: Wenn P95-Antwortzeit > 2x Basiswert für 7 aufeinanderfolgende Tage Ursache: Verschlechterung des Vektorindex, Inflation der Kontextgröße oder Sättigung des Modellendpunkts Behebung: Indexoptimierungsplan, Kontextbereinigung und Multi-Modell-Lastverteilung implementieren
Ausgearbeitete Beispiele
Beispiel: Implementierung eines Kundensupport-Chatbots
Anfängliche Anforderungen: „Erstellen Sie einen Chatbot, der Fragen zu unserer 500-seitigen Produktdokumentation beantworten kann“
Schritt 1: Architekturentscheidung
- Dokumentenanzahl: 500 Seiten → Pinecone für Skalierbarkeit verwenden
- Abfrageart: Gemischtes FAQ + Fehlerbehebung → Hybride Suche erforderlich
- Latenzanforderung: < 3 Sekunden → Re-Ranking einbeziehen, aber optimieren
Schritt 2: Implementierungsdurchlauf
// Anfängeransatz – würde einfache Ähnlichkeitssuche verwenden
const chunks = await vectorDb.query(queryEmbedding, { topK: 5 });
// Expertenansatz – berücksichtigt Relevanzschwellenwerte
const rawChunks = await vectorDb.query(queryEmbedding, {
topK: 20,
threshold: 0.7 // Mindestrelevanz sicherstellen
});
// Experte fügt Re-Ranking-Schritt hinzu, den Anfänger auslassen würden
const reranked = await reranker.rank(query, rawChunks);
const finalChunks = reranked.slice(0, 3);
// Experte integriert Fallback-Behandlung
if (finalChunks.length === 0) {
return await fallbackToGeneralSupport(query);
}
Schritt 3: Entdeckung der Leistungsoptimierung
- Anfängliche P95-Latenz: 4,2 Sekunden (über der Anforderung)
- Analyse: 60% der Zeit wird für das Re-Ranking aufgewendet
- Abwägungsentscheidung: Wechsel von Cohere Rerank zu lokalem Cross-Encoder
- Ergebnis: P95-Latenz → 2,1 Sekunden, leichter Qualitätsverlust (92% → 89% Zufriedenheit)
- Experten-Einblick: Für Support-Anwendungsfälle ist Geschwindigkeit wichtiger als perfekte Genauigkeit
Schritt 4: Behandlung von Fehlerszenarien
- Entdeckt: 15% der Abfragen betrafen Funktionen, die nicht in der Dokumentation enthalten waren
- Anfänger: Würde „Ich weiß nicht“ zurückgeben
- Experte: Eskalationserkennung und Übergabe an menschlichen Agenten hinzugefügt
Endgültige Architektur: Pinecone + lokaler Re-Ranker + Agenten-Eskalation = 89% Automatisierungsrate bei 2,1s P95
Qualitätsgatter
- Retrieval@5-Genauigkeit > 85% im Evaluierungsdatensatz
- Durchschnittliche Antwortlatenz < 3 Sekunden für P95
- Kontextnutzungsrate > 60% (das Modell verwendet abgerufene Informationen)
- Halluzinationsrate < 5% (Antworten, die nicht durch den abgerufenen Kontext gestützt werden)
- Nutzerzufriedenheits-Score > 80% über ein gleitendes 30-Tage-Fenster
- Token-Kosten pro Abfrage < vordefinierte Budgetschwelle
- Systemverfügbarkeit > 99,9% (exkl. geplanter Wartung)
- PII-Erkennungsrate > 95% (keine persönlichen Informationen in Antworten)
- Embedding-Modell-Leistung stabil (keine monatliche Verschlechterung > 10%)
- Fehlerbehandlung deckt alle Fehlermodi mit abgestufter Verschlechterung ab
Nicht-zuständigkeits-Grenzen
Diesen Skill NICHT verwenden für:
Prompt-Engineering-Aufgaben → Stattdessen prompt-engineer verwenden
- Optimieren von Prompt-Vorlagen und Anweisungen
- A/B-Tests von Prompt-Varianten
- Entwurf von Chain-of-Thought-Prompts
ML-Modell-Training/Feinabstimmung → Stattdessen ml-engineer verwenden
- Training benutzerdefinierter Embedding-Modelle
- Feinabstimmung von LLMs auf Domänendaten
- Forschung zu Modellarchitekturen
Daten-Pipeline-Engineering → Stattdessen data-pipeline-engineer verwenden
- ETL-Prozesse für Trainingsdaten
- Datenvalidierungs- und Bereinigungsworkflows
- Batch-Verarbeitungssysteme
Infrastruktur/DevOps → Stattdessen backend-architect verwenden
- Kubernetes-Bereitstellungsstrategien
- Datenbankoptimierung und Sharding
- Load-Balancer-Konfiguration
Analyse- und Monitoring-Setup → Stattdessen chatbot-analytics verwenden
- Analyse von Gesprächsabläufen
- Nutzerverhaltens-Tracking
- Erstellung von Leistungs-Dashboards
Delegieren, wenn:
- Aufgabe tiefgehendes ML-Wissen erfordert →
ml-engineer - Fokus auf Gesprächsdesign liegt →
prompt-engineer - Infrastrukturskalierung erforderlich ist →
backend-architect - Nutzungsanalysen gewünscht sind →
chatbot-analytics - Nicht-KI-Funktionen entwickelt werden → Relevanter Fachskill