Context-Budgeting ist im Exam-Kontext ein zentrales Architekturthema: Nicht „so viel Kontext wie möglich“ gewinnt, sondern „genug relevanter Kontext in stabiler Struktur“. Wenn du zu wenig Kontext gibst, füllt das Modell Lücken mit plausiblen, aber falschen Annahmen (klassische Halluzinations-Risiken). Wenn du zu viel gibst, sinkt die Signalqualität: wichtige Infos gehen im Rauschen unter, Antworten werden unpräzise, langsam oder inkonsistent. Für die Prüfung solltest du deshalb immer argumentieren können, wie du Kontext bewusst begrenzt, priorisierst und formst.
Ein praktisches Denkmodell ist „Need-to-answer“. Frage dich vor jedem Prompt: Welche Informationen sind zwingend nötig, damit das Modell die konkrete Aufgabe korrekt lösen kann? Alles andere ist optional oder sogar schädlich. Typische Fehler in Systemdesigns sind: komplette Chat-Historie blind mitschicken, irrelevante Dokumentabschnitte anhängen oder Rohdaten ohne Verdichtung weiterreichen. Besser ist ein mehrstufiges Vorgehen: erst filtern, dann verdichten, dann strukturieren.
Filtern bedeutet, nur aufgabenrelevante Quellen einzubeziehen (z. B. nur die API-Spezifikation des betroffenen Endpunkts statt der gesamten Doku). Verdichten bedeutet, lange Inhalte in präzise Zusammenfassungen oder Factsheets umzuwandeln. Strukturieren heißt, dem Modell klare Blöcke zu geben, etwa: Ziel, Constraints, Eingabedaten, gewünschtes Ausgabeformat. Diese Struktur reduziert Interpretationsspielraum und erhöht die Reproduzierbarkeit.
Im agentischen Setup wird Context-Budgeting noch wichtiger, weil mehrere Schritte und Tools kombiniert werden. Gute Praxis ist, pro Schritt ein eigenes „lokales Kontextpaket“ zu bauen: Der Retrieval-Schritt bekommt Suchkriterien und Quellenhinweise, der Analyse-Schritt bekommt nur extrahierte Fakten, der Ausgabe-Schritt bekommt validierte Ergebnisse + Formatregeln. So verhinderst du, dass jeder Schritt den gesamten Verlauf trägt. Das senkt Kosten und reduziert Fehlerfortpflanzung.
Prüfungsrelevant ist auch die Balance zwischen factual grounding und instruction overload. Viele Teams versuchen Halluzinationen zu bekämpfen, indem sie immer mehr Regeln in den Prompt packen. Das führt oft zum Gegenteil: Das Modell priorisiert widersprüchliche Instruktionen falsch oder übersieht den Kernauftrag. Besser: wenige, harte Regeln (z. B. „nur aus Quelle X zitieren“, „bei Unsicherheit Rückfrage“) plus klare Erfolgskriterien. Wenn Quellen fehlen, sollte der Agent explizit „insufficient context“ melden statt zu raten.
Ein solides Pattern für Examszenarien ist:
1) Kontextquellen ranken (Relevanz, Aktualität, Vertrauensniveau),
2) Top-N auswählen,
3) in ein kompaktes Arbeits-Template überführen,
4) Ausgabe gegen Kriterien validieren.
Messbar wird gutes Context-Budgeting durch Kennzahlen: Antwortgenauigkeit, Konsistenz über Wiederholungen, Tokenverbrauch, Latenz und Anzahl notwendiger Korrekturschleifen. Wenn Genauigkeit steigt und Tokens sinken, ist dein Budgeting wahrscheinlich gut. Wenn Antworten trotz mehr Kontext schlechter werden, hast du ein Overload-Signal.
Für die Prüfung ist die Kernbotschaft: Context-Budgeting ist keine Prompt-Kosmetik, sondern Architekturarbeit. Du designst bewusst, welche Information wann in welcher Form in den Entscheidungsprozess gelangt. Genau das trennt robuste, produktionsfähige Agentensysteme von Demo-Setups.
Du betreibst einen Support-Agenten, der falsche Antworten gibt, obwohl du ihm jetzt die komplette Wissensdatenbank in den Prompt einfügst. Wie würdest du das Context-Budgeting redesignen, um Genauigkeit und Stabilität zu verbessern?
Ich würde die Wissensbasis nicht komplett einbetten, sondern über Retrieval auf relevante Abschnitte begrenzen (Top-N nach Relevanz/Aktualität). Danach würde ich die Treffer in ein strukturiertes Fakten-Template verdichten und dem Modell klare Antwortregeln geben (nur aus gelieferten Quellen, sonst Unsicherheit melden). Abschließend validiere ich die Ausgabe gegen Kriterien wie Quellenbezug, Korrektheit und Format, um Halluzinationen früh zu erkennen.