Ich habe gesehen, wie über Nacht eine Rechnung von 200 $ auf einem AWS-Konto erschien.
Nicht weil das System abgestürzt war.
Ein Agent lief sechs Stunden lang in einer Schleife ohne Abbruchbedingung und rief bei jedem Durchlauf die OpenAI-API auf.
Jedes Monitoring-Dashboard zeigte ihn als gesund an.
Niemand bemerkte es, bis morgens die Rechnung eintraf.
Genau das passiert, wenn du KI-Systeme baust, ohne zu verstehen, wie sie wirklich funktionieren.
Die meisten Leute lernen KI-Engineering rückwärts.
Eine Bibliothek installieren. Einem Tutorial folgen. Eine API aufrufen. Etwas zum Laufen bringen. Sich wie Fortschritt fühlen.
Dann geht etwas kaputt, und zwar auf eine Weise, die keinen Sinn ergibt.
Sie ändern Zahlen willkürlich, bis es aufhört.
Das ist kein Engineering. Das ist Hoffnung mit einer Tastatur.
Hier sind die 6 Konzepte, die das beheben.
Der eine Satz, der alles erklärt
Jedes KI-System, egal wie komplex, ist einfach nur:
Memory (RAG) + Thinking (LLM + Tokens) + Actions (Agents) + Measurement (Evals)
…zusammengesetzt durch Context Engineering.
Das ist das gesamte Feld.
Alles, was folgt, erklärt nur, was jeder Teil tatsächlich bedeutet.
1. Tokens und das Kontextfenster
LLMs lesen keine Wörter. Sie lesen Blöcke, die Tokens genannt werden.
„engineering“ → 1 Token
„unbelievable“ → 2 Tokens. Leerzeichen und Satzzeichen zählen auch.
Jedes Modell hat ein Kontextfenster – eine harte Grenze für die Anzahl der Tokens, die es gleichzeitig halten kann.
→ Claude: 200.000 Tokens
→ GPT-5: 400.000 Tokens
Stell es dir wie ein Whiteboard in einem Besprechungsraum vor.
Das Modell arbeitet nur mit dem, was gerade auf dem Board steht.
Wenn das Board voll wird, werden alte Notizen gelöscht, um Platz zu machen.
Das Modell verliert nicht die Fähigkeit zu denken.
Es verliert den Zugriff auf die früheren Informationen.
Warum das Produktionssysteme zum Scheitern bringt:
→ Tokens kosten Geld – jeder API-Aufruf wird pro Input- und Output-Token abgerechnet
→ Lange Chatverläufe füllen das Fenster schnell
→ Wenn der Kontext voll ist, werden frühere Anweisungen stillschweigend verworfen
→ Was in den Kontext kommt, ist eine technische Entscheidung, kein Standard
Der Fehler, der das beweist:
Ein Team baute einen Kundensupport-Agenten mit vollständiger 12-monatiger Chat-Historie als Kontext für jede Anfrage.
Funktionierte in Tests mit 5 Interaktionen wunderbar.
In der Produktion, nach 50 Interaktionen, begann der Agent, seinen eigenen System-Prompt zu ignorieren.
Die Anweisungen waren noch da.
Sie waren unter 80.000 Tokens Gesprächsgeschichte begraben.
Das Modell hatte effektiv aufgehört, auf sie zu achten.
Die Lösung war kein besseres Modell.
Es war die Zusammenfassung älterer Geschichte, um das Fenster fokussiert zu halten.
Die unangenehme Wahrheit:
Die meisten „Prompt-Engineering-Fehlschläge“ sind in Wirklichkeit Token- und Kontextfenster-Fehlschläge im Gewand.
Ingenieure geben dem Prompt die Schuld, wenn das eigentliche Problem ist, dass die kritische Anweisung in Zeile 3 eines 500-zeiligen Kontexts steht und das Modell aufgehört hat, sie zu gewichten.
2. Embeddings und Vektorsuche
Embeddings wandeln Bedeutung in Zahlen um, damit „Ähnlichkeit“ mathematisch berechnet werden kann.
Das Problem, das sie lösen:
Du hast 50.000 Dokumente. Ein Benutzer stellt eine Frage. Du brauchst die 3 relevantesten – ohne jedes Mal alle 50.000 zu lesen.
Die Stichwortsuche versagt hier.
Wenn das Dokument „Automobil“ sagt und der Benutzer nach „Autos“ fragt, übersieht die Stichwortsuche es.
Nicht weil die Antwort nicht da ist. Sondern weil die Wörter nicht übereinstimmten.
Embeddings lösen das anders.
Ein Embedding-Modell wandelt Text in einen Vektor um – eine Liste von Zahlen, die die Bedeutung im mathematischen Raum repräsentieren.
Semantisch ähnlicher Text → numerisch ähnliche Vektoren.
„car“ und „automobile“ → nahe beieinander
„car“ und „photosynthesis“ → weit auseinander
Wie Vektorsuche tatsächlich funktioniert:
- Jedes Dokument wird in einen Vektor umgewandelt und gespeichert.
- Die Frage des Benutzers wird ebenfalls zu einem Vektor.
- Das System findet die gespeicherten Vektoren, die dem Fragevektor am nächsten sind.
- Das sind deine relevantesten Dokumente.
Das ist keine ungefähre Magie. Es ist Geometrie.
Ähnlichkeit ist eine echte mathematische Eigenschaft, die du berechnen kannst.
Wo das in der Produktion auftaucht:
→ Semantische Suche in jedem Dokumentensystem
→ Finden ähnlicher Produkte, Artikel, Benutzerprofile
→ Der Retrieval-Schritt in RAG (nächstes Konzept)
→ Gedächtnis in KI-Agenten
3. RAG (Retrieval-Augmented Generation)
Anstatt ein Modell auf deinen Daten zu trainieren, holst du die relevanten Daten zur Abfragezeit ab und gibst sie dem Modell als Kontext.
Das Problem, das RAG löst:
LLMs wissen viel. Sie kennen deine Daten nicht.
Die internen Dokumente deines Unternehmens. Deine Produktdatenbank. Deine Kundensupport-Historie.
Nichts davon war im Trainingsset.
Zwei Optionen: ein Modell auf deinen Daten trainieren (teuer, langsam, wird sofort veraltet) oder dem Modell deine Daten genau dann geben, wenn es sie braucht.
RAG ist die zweite Option, systematisch umgesetzt.
Die 3-Schritte-Pipeline:
→ ABRUFEN (RETRIEVE):
Frage wird zu einem Vektor → Vektordatenbank findet die ähnlichsten gespeicherten Dokumente → Top 3-5 Chunks abgerufen
→ ANREICHERN (AUGMENT):
abgerufene Dokumente werden zum Kontext des Modells hinzugefügt → Prompt wird „unter Verwendung dieses Kontexts, beantworte diese Frage“
→ GENERIEREN (GENERATE):
Modell antwortet auf Basis deiner tatsächlichen Daten – nicht halluziniert
Wo RAG scheitert:
→ Schlechter Abruf = schlechte Antwort. Das Modell kann nur mit dem arbeiten, was es erhalten hat.
→ Schlechte Chunking-Aufteilung trennt die Antwort von ihrem Kontext.
→ Das Modell kann immer noch halluzinieren, wenn der Abruf nichts Nützliches findet.
Ein echter RAG-Fehler:
Ein Team baute einen internen Wissensassistenten für ein 500-seitiges technisches Handbuch.
Funktionierte perfekt in Demos. In der Produktion waren die Antworten vage und manchmal falsch.
Das Problem: Chunk-Größe.
Sie hatten das Handbuch in 1.000-Token-Chunks nach roher Zeichenanzahl aufgeteilt.
Tabellen wurden in der Mitte einer Zeile geteilt. Schritt-für-Schritt-Anleitungen wurden mitten im Schritt geteilt.
Der Abruf fand den richtigen allgemeinen Bereich – verpasste aber die tatsächliche Antwort.
Die Chunk-Größe zu halbieren und Überlappung hinzuzufügen, behob 80 % der Probleme über Nacht.
Die harte Meinung:
RAG ist überbewertet, wenn dein Abruf schlecht ist.
Das LLM kann einen schlechten Abruf nicht beheben. Es kann nur darum herumhalluzinieren.
Wenn du falsche Antworten siehst, hör auf, an deinem Prompt herumzudoktern.
Fang an, deine Abrufgenauigkeit zu messen.
Dort liegt die Antwort.
4. Der Agenten-Loop
Agenten arbeiten, indem sie wiederholt eine Aktion auswählen, sie ausführen, das Ergebnis beobachten und entscheiden, was als nächstes zu tun ist – bis die Aufgabe erledigt ist.
Ein normaler LLM-Aufruf ist zustandslos. Du fragst, es antwortet, fertig.
Ein Agent ist zustandsbehaftet. Er handelt, beobachtet, entscheidet, wiederholt.
Die Schleife in einfachen Worten:
- Ein Ziel erhalten
- Die nächste Aktion entscheiden
- Sie ausführen – suchen, codieren, eine Datei lesen
- Das Ergebnis beobachten
- Die nächste Aktion basierend auf dem Gelernten entscheiden
- Wiederholen, bis das Ziel erreicht ist
- Die endgültige Antwort zurückgeben
Werkzeuge sind das, was Agenten ihre Macht verleiht.
Ohne Werkzeuge antwortet ein LLM nur mit Text.
Mit Werkzeugen kann es im Web suchen, Dateien lesen, Code schreiben, APIs aufrufen, jede von dir definierte Aktion auslösen.
Drei Dinge, die Anfänger immer falsch machen:
→ Agenten ohne Abbruchbedingungen laufen für immer. Du musst definieren, wann sie aufhören sollen – Schrittzahlbegrenzung, Zeitlimit oder Zielbedingung
→ Mehr Werkzeuge ≠ bessere Leistung. Zu viele Werkzeuge verwirren das Modell, welches es verwenden soll
→ Werkzeugfehler benötigen explizite Behandlung. Ein stiller Fehler führt dazu, dass der Agent selbstbewusst Mist produziert
Der 200-$-Fehler über Nacht im Detail:
Der Agent hatte keine maximale Schrittzahl. Sein Ziel: ein Thema recherchieren und eine Zusammenfassung erstellen.
Eines seiner Websuchwerkzeuge gab ein leeres Ergebnis zurück.
Der Agent wusste nicht, wie er aufhören sollte.
Er suchte weiter, versuchte es erneut, erstellte Zwischenzusammenfassungen – jede davon löste eine weitere Suche aus.
Sechs Stunden später: 847 LLM-Aufrufe. 2,1 Millionen Tokens verbraucht. Eine zusammenhängend aussehende, aber völlig kreisförmige Zusammenfassung. Eine Rechnung über 200 $.
Die Lösung waren drei Zeilen: ein maximaler Schrittzähler, ein expliziter Handler für leere Ergebnisse, ein Eskalationspfad bei geringem Vertrauen.
Der gleiche Agent erledigt jetzt durchschnittlich in weniger als 12 Aufrufen.
Die Meinung, die du hören musst:
Die meisten Agenten scheitern nicht, weil das Modell schlecht ist – sondern weil Ingenieure die Schleife so behandeln, als würde sie sich selbst verwalten.
Das tut sie nicht.
Schutzvorrichtungen, Abbruchbedingungen, Fehlerbehandler – von Anfang an eingebaut, nicht nach dem ersten Vorfall hinzugefügt.
5. Evals (Evaluation)
Evals zeigen dir, ob dein KI-System tatsächlich funktioniert – und ob eine Änderung es besser oder schlechter gemacht hat.
Dies ist das Konzept, das die meisten Tutorials auslassen, weil es unglamourös ist.
Es ist auch das, was Ingenieure, die Demos bauen, von Ingenieuren trennt, die Produktionssysteme bauen.
Das Problem ohne Evals:
Du änderst deinen Prompt. Aktualisierst deine Abruflogik. Wechselst zu einem neueren Modell.
Wurde es besser?
Du weißt es nicht. Du könntest ein paar Beispiele manuell überprüfen – aber das ist ein Gefühl, kein Beweis.
Wie Evals tatsächlich aussehen:
→ Ein Goldstandard-Datensatz: 25-50 reale Eingaben mit bekannten korrekten Ausgaben, die die Hauptanwendungsfälle plus 5 bekannte knifflige Grenzfälle abdecken
→ Binäre Metriken wo möglich:
— Hat das RAG-System das richtige Dokument abgerufen? Ja/Nein
— Hat der Agent fehlerfrei abgeschlossen? Ja/Nein
— Enthielt die Antwort die erforderlichen Informationen? Ja/Nein
→ Aggregierte Ergebnisse über die Zeit verfolgt:
— Abrufgenauigkeit: 89 % → Änderung vorgenommen → 84 %. Regression gefunden.
— Aufgabenerledigungsrate: 76 % → neue Agentenversion → 81 %. Verbesserung bestätigt.
Der Eval-Zyklus:
Bereitstellen → Mit Evals messen → Fehler finden → Fehler zum Goldstandard-Datensatz hinzufügen → Beheben → Evals erneut ausführen → Ergebnisse vergleichen → Nur ausliefern, wenn sich die Zahlen verbessert haben
Die ehrliche Wahrheit:
„Hilfreichkeit: 3,7/5“ sagt dir nichts Handlungsrelevantes.
„Richtiges Dokument abgerufen: 84 % der Zeit“ sagt dir genau, wo das Problem liegt und wie sehr eine Lösung es verbessert hat.
Ein KI-System ohne Evals ist kein Produkt.
Es ist eine Demo, die du nicht sicher ändern kannst.
6. Context Engineering
Die Disziplin, genau zu entscheiden, welche Informationen in das Kontextfenster des Modells gelangen, wie sie strukturiert sind und was weggelassen wird.
Hier ist die Meinung, die Leute unwohl fühlen lässt:
Context Engineering ist wichtiger als Prompt Engineering.
Ein mittelmäßiger Prompt in einem gut kuratierten Kontext übertrifft einen brillanten Prompt, der im Rauschen vergraben ist – jedes Mal.
Die meisten Teams verwenden 80 % ihrer Optimierungsbemühungen auf den Prompt und fast nichts auf den Kontext.
Die Ergebnisse spiegeln das wider.
Der naive Ansatz scheitert:
Alles einbeziehen. Die ganze Historie. Alle abgerufenen Dokumente. Jede Werkzeugbeschreibung. Den System-Prompt. Die Benutzernachricht. Alles.
Das scheitert aus einem konsistenten Grund: Das Modell wird verwirrt, worauf es am meisten ankommt.
Es gibt einen dokumentierten Effekt namens „Lost in the Middle“ – Informationen, die tief in einem langen Kontext vergraben sind, werden seltener verwendet.
Was Context Engineering tatsächlich beinhaltet:
→ Auswahl: Welche Dokumente, Fakten oder Historie braucht diese spezifische Entscheidung?
→ Komprimierung: Können ältere Teile des Gesprächs zusammengefasst werden, um Tokens zu sparen?
→ Reihenfolge: Kritische Anweisungen gehören an den Anfang und ans Ende – nicht in die Mitte
→ Bereinigung: Was kann entfernt werden, ohne die Ausgabequalität zu beeinträchtigen?
→ Struktur: Überschriften, Trennzeichen, gekennzeichnete Abschnitte beeinflussen, wie zuverlässig das Modell Informationen verwendet
Ein praktisches Beispiel:
Ein Agent läuft seit 45 Minuten. Er hat 80.000 Tokens Gesprächsgeschichte angesammelt. Sein Fenster ist 128.000.
Du willst das ursprüngliche Ziel und die Einschränkungen nicht verlieren, selbst wenn die Geschichte das Fenster füllt.
Context Engineering: ältere Werkzeugausgaben komprimieren, frühere Überlegungen zusammenfassen, die Aufgabenbeschreibung während der gesamten Sitzung prominent halten.
Prompt Engineering ist das Schreiben guter Anweisungen.
Context Engineering ist das Schaffen der Umgebung, in der diese Anweisungen tatsächlich befolgt werden.
Wie diese 6 Konzepte ein System bilden
MEMORY → RAG + Embeddings (was das System weiß)
THINKING → LLM + Tokens + Context Window (wie es mit dem, was es weiß, argumentiert)
ACTIONS → Agentic Loop + Tools (was es in der Welt tun kann)
MEASUREMENT → Evals (wie du weißt, dass es funktioniert)
GLUE → Context Engineering (was entscheidet, was zwischen all dem fließt)
Ein einfacher Chatbot ist nur Thinking.
Ein Kundensupport-Agent ist Memory + Thinking + Actions.
Ein zuverlässiges Produktionssystem fügt Measurement hinzu.
Die Raffinesse liegt darin, wie gut die Teile verbunden sind.
Der Ablauf für eine einzelne Anfrage:
Benutzerfrage
→ Context Engineering entscheidet, was einbezogen wird
→ Embeddings rufen relevantes Memory ab (RAG)
→ Tokens bestimmen, wie viel ins Fenster passt
→ LLM denkt über den zusammengestellten Kontext nach
→ Agenten-Loop entscheidet, ob weitere Informationen benötigt werden
→ Evals messen, ob die Ausgabe tatsächlich korrekt war
Wo anfangen
Du musst nicht alle sechs auf einmal meistern.
→ Beginne mit Tokens und Kontextfenstern – sie beeinflussen alles, was du baust
→ Füge Embeddings hinzu, wenn du semantische Suche oder Gedächtnis brauchst
→ Lerne RAG, wenn du ein Modell in deinen eigenen Daten verankern musst
→ Lerne den Agenten-Loop, wenn du Automatisierung brauchst
→ Füge Evals hinzu, bevor du etwas in Produktion bringst
→ Wende Context Engineering an, wenn alles andere intuitiv wird
Diese Reihenfolge ist nicht willkürlich.
Jedes Konzept macht das nächste lernbar.
Die ehrliche Schlussbemerkung
Die meisten Teams, die mit KI in der Produktion kämpfen, kämpfen nicht mit dem falschen Modell oder der falschen Bibliothek.
Sie kämpfen, weil sie eines dieser sechs Konzepte übersprungen haben.
Der Agent loopt ewig, weil niemand an Abbruchbedingungen gedacht hat.
Die RAG-Antworten sind falsch, weil niemand den Abruf gemessen hat.
Der Prompt funktioniert bei langen Sitzungen nicht mehr, weil niemand verstanden hat, wie sich das Kontextfenster füllt.
Das sind keine anspruchsvollen Probleme.
Es sind grundlegende, verkleidet in technisches Vokabular.
Die Werkzeuge ändern sich alle sechs Monate.
Diese sechs Konzepte zeigen, wie die Werkzeuge funktionieren.
Lerne die Konzepte, und du wirst nie wieder von einem neuen Werkzeug verwirrt sein.
Noch wichtiger – du wirst nie wieder 200 $ dafür ausgeben, einen Agenten die ganze Nacht loopen zu sehen und dich zu fragen, was schiefgelaufen ist.
Wenn das nützlich war:
→ Teile es mit jedem KI-Ingenieur, den du kennst
→ Folge @sairahul1 für weitere Systeme und Aufschlüsselungen wie diese
→ Lesezeichen setzen – du wirst es das nächste Mal nachschlagen, wenn etwas in der Produktion kaputtgeht
Ich schreibe über KI, Produktentwicklung und Systeme, die funktionieren, während du schläfst.
