Hören Sie auf, Ihr LLM anzuschreien

Als wir unser Agentensystem zum ersten Mal bauten, setzten wir im System-Prompt stark auf Betonungsmarker: "IMPORTANT", "CRITICAL", "URGENT". Mit der Zeit sammelten sich immer mehr dieser Marker an, während wir versuchten, Randfälle und Fehler zu korrigieren.

In der Praxis skalierte das schlecht. Je "lauter" der Prompt wurde, desto schwerer ließ sich eine klare Prioritätenreihenfolge halten.

Das ist Betonungssättigung: Wenn zu viele Anweisungen hervorgehoben werden, helfen die Hervorhebungen nicht mehr. Der Prompt klingt im Ton dringlicher, wird in der Struktur aber unklarer.

Was wir im Produktivbetrieb beobachtet haben

Wir sahen ein durchgängiges Muster:

• Mehr Betonung ("URGENT", "ULTRA IMPORTANT", "!!!", Fettdruck, wiederholte Warnungen) verbesserte das Befolgen der Anweisungen nicht zuverlässig.
• Mit der Zeit verloren die Betonungsmarker an Wirkung. Wir verschärften die Wortwahl immer weiter, weil frühere Verschärfungen nicht mehr wirkten.

Wir haben dafür keine saubere quantitative Messung - das ist eine betriebliche Erkenntnis aus dem Iterieren an echten Prompts mit echten Nutzern.

Warum das passiert

Ein nützliches Denkmodell: LLMs haben eine begrenzte Kapazität, sich auf das Wesentliche zu konzentrieren. Wenn Sie Aufmerksamkeitsmagneten hinzufügen, konkurrieren diese mit den eigentlichen Anweisungen. Sehen zu viele Dinge "kritisch" aus, muss das Modell Konflikte auflösen, statt auszuführen.

Anthropics Beitrag über effektives Context-Engineering beschreibt diese Idee als ein "Aufmerksamkeitsbudget" für den Kontext: Alles, was Sie hinzufügen, konkurriert um begrenzte Kapazität, weshalb signalstarke Struktur lauter Wortwahl meist überlegen ist.

Das ist keine Behauptung, dass "Fettdruck X Aufmerksamkeitseinheiten kostet". Es ist eine praktische Erklärung für das, was wir beobachtet haben: Schreien verringert die Klarheit, und Klarheit ist das, was Modelle brauchen.

Aufmerksamkeit ist nicht dasselbe wie Token-Anzahl

Hier überkorrigieren Teams oft. Das Ziel sind nicht "kurze Prompts". Das Ziel ist wenig Konflikt.

Ein kurzer Prompt mit konkurrierenden Prioritäten kann schlechter abschneiden als ein längerer Prompt mit klarer Hierarchie. In der Praxis:

• Wenige Token mit vielen "Muss"-Regeln, die in unterschiedliche Richtungen ziehen, erzeugen Konflikt.
• Etwas mehr Kontext mit einem primären Ziel und stützenden Einschränkungen funktioniert oft besser.

Die Prompt-Design-Strategien von Google Gemini empfehlen, präzise und direkt zu sein und unnötige oder übertrieben überzeugende Sprache zu vermeiden.

Sie verbrauchen den Steuerungsspielraum des Nutzers

Der höchste Preis, den wir sahen, war nicht die reine Modellqualität. Es war der Verlust an Steuerungskapazität.

Wenn der System-Prompt jeden verfügbaren Betonungstrick einsetzt, Großbuchstaben, Fettdruck, wiederholte "CRITICAL"-Marker, dominiert er das Anweisungsgefüge. Dann kommt der Nutzer mit normaler Sprache und normalen Einschränkungen, und seine Vorgaben haben kaum eine Chance, mitzuhalten.

Das verstärkt sich, wenn Sie externe Systeme einbinden. Jeder MCP-Server und jede Drittanbieter-Integration bringt eigene Anweisungen und Einschränkungen mit. Je mehr externe Quellen Sie hinzuziehen, desto lauter wird die Grundlinie, und desto schwerer kann der Nutzer das endgültige Verhalten steuern.

Was bei uns funktioniert hat

Wir erzielten bessere Ergebnisse, indem wir von "lauter" zu "klarer" wechselten:

• Struktur vor Betonung. Nutzen Sie klare Gliederung und Trennzeichen (zum Beispiel XML-Tags), um Kontext, Aufgaben, Einschränkungen und Ausgaben voneinander zu trennen.
• Machen Sie Prioritäten explizit. Gibt es eine Regel, die alle anderen dominiert, nennen Sie sie einmal, klar und früh.
• Reduzieren Sie Konflikte. Entfernen Sie redundante Einschränkungen und überlappende Anforderungen.
• Setzen Sie Betonung sparsam ein. Wenn überhaupt, reservieren Sie sie für genau eine Regel, nachdem Sie Struktur und Hierarchie in Ordnung gebracht haben.
• Behandeln Sie Prompt-Anpassungen als begrenzten Hebel. Wenn wiederholtes Iterieren ein Fehlverhalten nicht behebt, ist es oft architektonisch bedingt (Tooling, Retrieval, Guardrails, Zerlegung) und keine Frage der Wortwahl.

Mit diesen Prinzipien erzielten wir bei Hyground bessere Ergebnisse.