Selten ist das Modell das Problem. Sondern das, was es bekommen hat.
Ein Agent, der selbstbewusst aus den falschen drei Absätzen antwortet, sieht genauso aus wie einer, der aus den richtigen antwortet. Kontext-Engineering ist die Arbeit daran, zu entscheiden, was das Modell erreicht — was indexiert wird, wie es aufgeteilt wird, was abgerufen wird und wann besser nichts abgerufen wird.
„Die KI hat sich geirrt“ heißt meist „Die KI hat es nie gesehen“
Wenn ein Agent eine schlechte Antwort gibt, ist der erste Reflex, den Prompt zu ändern — oder das Modell. Viel häufiger hat das Retrieval unbemerkt die falschen Passagen geliefert oder nichts Brauchbares, und das Modell hat die Lücke selbst gefüllt. Von außen sieht keiner dieser Fehler wie ein Fehler aus, denn die Antwort liest sich in beiden Fällen gleich flüssig. Genau deshalb lohnt es sich, Kontext zu entwickeln, statt ihn von Hand zusammenzustellen und zu hoffen.
Vier Entscheidungen darüber, was das Modell sieht
Keine davon betrifft das Modell. Jede ist ein Punkt, an dem Qualität leise gewonnen oder verloren wird — lange bevor ein Prompt geschrieben ist.
01 · Ingestion
Dort abholen, wo es schon liegt
Dokumente bleiben in den Systemen, die Ihre Teams bereits nutzen. Die Ingestion ist idempotent und arbeitet mit Content-Hashes: Ein erneuter Sync kostet nichts, und dieselbe Datei an zwei Orten wird einmal indexiert, nicht zweimal.
02 · Chunking
Dort trennen, wo die Bedeutung trennt
Hier wird der größte Teil der Retrieval-Qualität gewonnen oder verloren. Wir arbeiten uns durch natürliche Trennstellen und zählen echte Tokens statt Zeichen, mit bewusstem Überlappen, damit eine Passage an einer Grenze weiterhin findbar bleibt.
03 · Retrieval
Bedeutung suchen, keine Stichwörter
Vektorsuche über einen indexierten Korpus, mit Embeddings, die für Dokumente und für Anfragen getrennt typisiert sind. Eine Frage genauso zu speichern wie einen Absatz ist ein kleiner Fehler, der bei jedem Abruf Genauigkeit kostet.
04 · Assembly
Entscheiden, was den Platz verdient
Das Kontextfenster ist endlich, und jede Passage darin verdrängt eine andere. Was bleibt, wird über Score und Budget entschieden — mit Zitaten, damit jede Aussage in der Antwort auf den Text zurückführbar ist, aus dem sie kommt.
Was das Modell bekommen hat — und was nicht
Jede Antwort trägt die Passagen mit sich, auf denen sie beruht — und genauso wichtig: die, die bewusst weggelassen wurden. Eine Passage, die wegen eines zu niedrigen Scores herausfiel, und eine, die als Duplikat herausfiel, sind zwei verschiedene Probleme, und Sie sehen, welches vorlag.
Drei Hebel, die die meisten Retrieval-Setups nie nutzen
Sich entscheiden, nicht abzurufen
Vor dem Modellaufruf läuft eine Bewertung. Wenn die Frage den Korpus nicht braucht — oder der Korpus sie offensichtlich nicht beantworten kann — wird das Retrieval übersprungen, statt den Prompt mit lose verwandten Passagen zu füllen, die die Antwort verschlechtern. Nicht abzurufen ist schneller, günstiger und oft genauer.
Drei Tiefen pro Quelle
Nicht jedes Dokument verdient eine vollständige Indexierung. Quellen werden je nach tatsächlicher Nutzung in voller Tiefe, als Zusammenfassung oder als Referenz gespeichert, und identische Inhalte teilen sich Embeddings, statt zweimal bezahlt zu werden. Tiefe ist eine Kostenentscheidung, die Sie bewusst treffen sollten.
Dokumente, die zu lang zum Einbetten sind
Übergroße Dateien werden aus Anfang, Ende und Stichproben aus der Mitte zusammengefasst, mit einem Map-Reduce-Durchlauf als Rückfallebene, wenn selbst das nicht passt. Ein 300-seitiger Vertrag bleibt durchsuchbar, statt bei der Ingestion still übersprungen zu werden.
Alles indexieren — aber nicht in derselben Tiefe
Eine Richtlinie, die Ihr Agent mehrmals täglich zitiert, und eine Board-Unterlage, die er einmal im Quartal berührt, verdienen nicht dieselbe Behandlung. Sie unterschiedlich zu speichern ist der Unterschied zwischen einem Korpus, der skaliert, und einem, der schneller teuer wird als nützlich.
Retrieval-Qualität ist messbar — also messen wir sie
Context Precision, Context Recall, Faithfulness, Answer Relevancy — Retrieval hat echte Metriken, und eine Pipeline ohne sie wird nach Gefühl justiert. Jede Änderung an Chunking, Schwellenwerten oder Tiefe läuft vor dem Ausrollen gegen ein festes Fragenset. Aus „fühlt sich besser an“ wird so eine Zahl, die sich bewegt hat oder eben nicht.
Fragen, die sich lohnen
Zeigen Sie uns, was Ihr Agent immer wieder falsch macht
Meistens liegt die Lösung vor dem Modell, nicht im Modell.