Löwen Codex / Magazin / Artikel
KI-Systeme

Context Engineering: KI-Ergebnisse stehen und fallen mit Kontext

Zwei Unternehmen nutzen dasselbe KI-Modell. Das eine bekommt brauchbare Angebote, saubere Antworten und konsistenten Content — das andere generische Texte mit erfundenen Details. Der Unterschied liegt nicht im Modell. Er liegt im Kontext, den das Modell bekommt.

Autor Julien MarschallVeröffentlicht 2026-07-23Lesezeit 6 Min.

Die Diskussion um KI im Unternehmen dreht sich meist um Modelle: Welches ist das beste, welches das neueste, wann kommt das nächste. Dabei ist die Modellwahl in der Praxis selten der Engpass. Moderne Modelle sind austauschbar gut — was sich zwischen Unternehmen dramatisch unterscheidet, ist das Material, mit dem sie arbeiten. Ein Modell kennt weder die Preisliste noch den Tonfall der Marke, weder die Ausnahme für den A-Kunden noch die Rechtsform-Besonderheit. Alles, was es davon nicht bekommt, erfindet es oder lässt es weg. Context Engineering ist die Disziplin, genau dieses Material systematisch bereitzustellen.

Vom Prompt zur Umgebung

Prompting ist die Einzelanweisung: „Schreibe ein Angebot für Kunde X." Context Engineering ist die Umgebung, in der diese Anweisung ankommt: die Angebotsvorlage, die Preislogik, zwei gelungene Beispielangebote, die Regel, dass Rabatte über zehn Prozent zur Freigabe gehen. Der Unterschied zeigt sich, sobald mehrere Personen mit dem System arbeiten. Ein guter Prompter erzielt allein passable Ergebnisse — ein gutes Kontext-Setup sorgt dafür, dass jeder im Team dieselbe Qualität bekommt, unabhängig von der eigenen Prompt-Erfahrung.

Die vier Bausteine guten Kontexts

  • Strukturiertes Firmenwissen: Produkte, Preise, Prozesse und Positionierung als gepflegte Dokumente — nicht verstreut über Postfächer und Köpfe
  • Rollen und Policies: In wessen Namen antwortet das System, was darf es zusagen, wo muss es an einen Menschen übergeben
  • Beispiele statt Adjektive: Zwei echte Referenztexte definieren einen Tonfall präziser als zehn Stilbeschreibungen
  • Aktuelle Daten zur Laufzeit: Lagerbestand, offene Posten oder Ticketstatus, per Anbindung geholt statt hineinkopiert

„Professionell, freundlich und kompetent" kann alles bedeuten. Ein einziges Beispiel einer wirklich gelungenen Kundenantwort definiert den Standard unmissverständlich — Beispiele schlagen Adjektive immer.

Das Kontext-Budget: mehr ist nicht besser

Der verbreitetste Fehler ist der Reflex, einfach alles hineinzukippen: das ganze Handbuch, sämtliche Alt-Angebote, jede Produktbeschreibung. Kontext hat aber ein Budget. Jedes irrelevante Dokument verwässert die Aufmerksamkeit des Modells, und widersprüchliche Altbestände — die Preisliste von 2023 neben der aktuellen — erzeugen genau die Fehler, die man vermeiden wollte. Kuratieren heisst entscheiden: Was braucht diese Aufgabe wirklich, was ist die eine gültige Quelle je Thema, und was fliegt raus. Ein schlankes, gepflegtes Kontext-Set schlägt das vollgestopfte Archiv in jeder Auswertung.

RAG: Kontext zur Laufzeit statt Wissensmüllhalde

Bei grösseren Wissensbeständen übernimmt eine Wissensbasis mit Retrieval (RAG) die Auswahl: Das System sucht zur Anfrage passende Passagen und gibt nur diese dem Modell mit. Das verschiebt das Problem aber nur scheinbar — auch RAG ist nur so gut wie das, was in der Basis liegt. Veraltete, doppelte oder widersprüchliche Dokumente werden zuverlässig mitgefunden und landen im Kontext. Deshalb gehört zu jeder Wissensbasis ein Pflegeprozess: ein Verantwortlicher je Themenbereich, ein Gültig-bis-Datum an kritischen Dokumenten und ein Review, wenn sich Preise, Prozesse oder Zuständigkeiten ändern.

Typische Fehler in der Praxis

Drei Muster tauchen immer wieder auf. Erstens: alles reinkippen, nichts kuratieren — das Modell zitiert dann souverän aus dem falschen Dokument. Zweitens: Kontext einmal aufsetzen und nie aktualisieren — nach sechs Monaten antwortet das System mit dem Stand von gestern und niemand merkt es, weil es überzeugend klingt. Drittens: Kontext nur im Kopf des Power-Users — die eine Person, die „gut mit KI kann", hat ihr Setup nie dokumentiert, und mit ihr geht die Qualität. Alle drei Fehler haben dieselbe Lösung: Kontext als Unternehmens-Asset behandeln, mit Eigentümer, Versionierung und festem Pflegerhythmus.

Der Einstieg: ein Prozess, ein Kontext-Set

Der pragmatische Start ist klein: einen einzigen Prozess wählen — etwa Kundenanfragen beantworten —, das nötige Wissen auf wenigen Seiten konsolidieren, Rolle und Grenzen definieren, zwei Referenzbeispiele auswählen. Dann zwei Wochen vergleichen: Ergebnisse mit Kontext-Set gegen Ergebnisse ohne. Der Qualitätssprung ist in der Regel so deutlich, dass die Frage „Welches Modell nehmen wir?" auf ihren tatsächlichen Stellenwert schrumpft. Das Modell ist der Motor. Der Kontext ist der Treibstoff — und um dessen Qualität kümmert sich kein Anbieter, sondern nur das eigene Unternehmen.

Wer bessere KI-Ergebnisse will, braucht selten ein besseres Modell. Fast immer braucht er besseren Kontext.

Kontext, der Ergebnisse liefert

Löwen Codex strukturiert Firmenwissen, Rollen und Wissensbasis so, dass KI-Systeme verlässlich arbeiten — kuratiert statt reingekippt.

Kontakt →

Häufige Fragen

Was ist der Unterschied zwischen Prompting und Context Engineering?
Prompting formuliert die einzelne Anweisung. Context Engineering baut die Umgebung darum herum: strukturiertes Firmenwissen, Rollen, Policies und Beispiele, die bei jeder Anfrage automatisch mitgegeben werden — unabhängig davon, wer gerade promptet.
Warum liefert dasselbe Modell in zwei Firmen so unterschiedliche Qualität?
Weil das Modell nur verarbeitet, was es bekommt. Die Firma mit kuratiertem Wissen, klaren Regeln und guten Beispielen bekommt verlässliche Ergebnisse; die Firma, die nur Anweisungen tippt, bekommt generische Texte mit erfundenen Details.
Hilft mehr Kontext immer weiter?
Nein. Kontext hat ein Budget: Zu viel Irrelevantes verwässert die Aufmerksamkeit des Modells und verschlechtert Ergebnisse. Kuratiert wird nach Relevanz für die Aufgabe — nicht nach Vollständigkeit.