Der Name stand 13-mal im Prompt. Es half nicht.

Einer unserer lokalen Assistenten stellte sich neuerdings so vor: „Ich bin ein KI-Assistent, der über die MCP-Tools in diesem Chat eingebunden ist." Das war neu. Er hat eine feste Rolle, sie steht in zwei Dateien, die bei jeder Anfrage in seinen Systemprompt geladen werden, und monatelang hat er sie gehalten. Verändert hatten wir an diesen Dateien nichts.

Die Suche nach der Ursache hat einen halben Tag gedauert, zwei falsche Erklärungen produziert und am Ende zwei Lehren, die auf jedes Setup mit lokalen Modellen übertragbar sind. Die zweite davon hat uns am meisten überrascht: Es half nicht, dass sein Name dreizehnmal im Systemprompt stand.

Die erste Erklärung war falsch, und wir haben sie geglaubt

Naheliegend war das Kontextfenster. Wir hatten es am selben Morgen halbiert, damit die Verdichtung langer Gespräche früher greift — eine Empfehlung, die für einen anderen Assistenten im Haus richtig war. Die zeitliche Nähe machte sie zur offensichtlichen Ursache: Das Modell bekommt weniger Platz, die Rollendateien fallen aus dem Fenster, fertig ist die Erklärung.

Wir haben die Änderung zurückgenommen. Es half nicht.

Das ist der unangenehme Teil jeder Fehlersuche: Eine plausible Erklärung fühlt sich an wie ein Befund. Sie erklärt das Symptom, sie hat einen Zeitstempel, sie passt. Und sie kann trotzdem komplett falsch sein. Der einzige Schutz dagegen ist, sie zu testen, statt sie zu glauben — und zwar mit einem Test, der sie widerlegen könnte.

Ein Treffer ist kein Beweis

Der zweite Fehler war methodisch und kostspieliger. Nachdem wir eine Korrektur eingebaut hatten, stellten wir dem Modell die Testfrage „Wer bist du?" — und bekamen eine perfekte Antwort in der richtigen Rolle. Erledigt, dachten wir, und meldeten Vollzug.

Eine Stunde später, dieselbe Frage, derselbe Prompt, dasselbe Modell: „Ich bin ein KI-Assistent, der dir helfen kann."

Nichts hatte sich geändert. Das System würfelte.

Ab da haben wir die Testfrage nicht mehr einmal gestellt, sondern viermal hintereinander mit identischer Eingabe. Das Ergebnis war eindeutig: Rolle gehalten in 0 von 4 Läufen. Der eine gelungene Lauf vorher war keine Bestätigung gewesen, sondern ein Würfelwurf, den wir für ein Ergebnis gehalten hatten.

Wer mit quantisierten Modellen arbeitet, sollte diese Zahl im Kopf behalten: Bei Verhalten, das nicht deterministisch ist, ist ein einzelner erfolgreicher Lauf kein Nachweis. Er ist eine Stichprobe der Größe eins.

Ursache 1: Verneinungen setzen genau den Begriff, den sie austreiben sollen

nanobot, das Agenten-Framework, auf dem dieser Assistent läuft, stellt seinem Systemprompt eine eigene Vorlage voran, die mit einer generischen Identität beginnt — sinngemäß „Du bist ein hilfreicher KI-Assistent". Danach erst folgen die Rollendateien. Zwei Identitäten in einem Prompt, die generische zuerst.

Unser erster Reparaturversuch schrieb an dieselbe Stelle: „Du bist nicht nanobot und kein allgemeiner KI-Assistent." Klingt vernünftig. Das Ergebnis: In drei von vier Läufen stellte sich der Assistent daraufhin als „Nanobot" vor — ein Name, den er vorher nie benutzt hatte.

Ein schwaches Modell behält das Wort, nicht das „nicht". Eine Verneinung führt den Begriff ein, den sie verbieten will, und macht ihn dadurch verfügbar. Die Korrektur bestand darin, den fremden Namen überhaupt nicht mehr zu erwähnen und stattdessen positiv zu sagen, wer der Assistent ist.

Ursache 2: Was zuletzt im Prompt steht, gewinnt

Die zweite Ursache war die eigentliche. Das Framework lädt die Rollendateien in fester Reihenfolge — erst die Rolle, dann ein umfangreiches Nutzerprofil, dann die Werkzeug-Dokumentation. Der Systemprompt war rund 25.000 Zeichen lang. Die Rolle stand in der ersten Hälfte; das Letzte, was das Modell unmittelbar vor der Frage des Nutzers las, waren das Nutzerprofil und eine Liste von Funktionsbeschreibungen.

Der Name des Assistenten kam in diesem Prompt dreizehnmal vor. Es half nicht.

Wir haben die Reihenfolge umgedreht, sodass die Rollendateien ganz am Ende stehen, direkt vor der Nachricht. Am Inhalt haben wir keine Silbe geändert. Ergebnis desselben Tests: Rolle gehalten in 4 von 4 Läufen. Mit mitgeschicktem Werkzeugsatz, wie im echten Betrieb, zwei von drei — der dritte Lauf war kein Rückfall, sondern ein Werkzeugaufruf statt einer Antwort.

Menge hilft nicht. Position schon.

Warum das an großen Modellen nicht auffällt

Dieselbe Konstruktion lief monatelang problemlos — mit einem anderen Modell. Der Unterschied ist die Quantisierung: Das aktuelle Modell ist DeepSeek-V4-Flash, und es läuft bei uns als UD-IQ3_XXS — also unterhalb der Vier-Bit-Grenze, weil nur so genug Speicher für den Kontext bleibt. Das ist besonders bitter, weil DeepSeek dieses Modell quantisierungsbewusst trainiert hat: Auf Vier-Bit-Niveau ist es praktisch verlustfrei, darunter nicht mehr. Ein starkes Modell löst den Widerspruch zwischen zwei Identitäten im selben Prompt zugunsten der spezifischeren auf und hält sie über zehntausende Zeichen hinweg. Ein stark quantisiertes folgt dem, was am klarsten und am nächsten steht.

Das ist kein Argument gegen lokale Modelle — es ist ein Argument dafür, sie anders zu bauen. Was bei einem großen Modell Prompt-Kosmetik ist, wird hier zur Architekturfrage: Reihenfolge, Länge und Formulierung sind keine Stilentscheidungen mehr, sondern entscheiden über die Funktion. Wir hatten das im A/B-Test lokaler Dev-Modelle schon einmal in anderer Form gesehen.

Was wir mitnehmen

Drei Regeln, die uns diesen halben Tag gekostet haben:

Rollen positiv formulieren. Nie schreiben, was etwas nicht ist. Jede Verneinung führt den unerwünschten Begriff ein.

Rollen ans Ende stellen. Was unmittelbar vor der Nutzernachricht steht, wirkt am stärksten. Wiederholung weiter oben ersetzt Nähe nicht.

Wiederholt messen, bevor man Vollzug meldet. Bei nicht-deterministischem Verhalten ist ein Treffer eine Stichprobe der Größe eins. Vier identische Läufe kosten fünf Minuten und ersparen eine falsche Entwarnung.

Die letzte Regel ist die unbequemste, weil sie gegen den Reflex arbeitet, ein Problem für gelöst zu erklären, sobald es einmal funktioniert hat. Genau dieser Reflex hat uns hier zweimal in die Irre geführt — und das ist auch der Grund, warum dieser Beitrag existiert: Ein zugegebenes „ich weiß es nicht" ist mehr wert als eine Erklärung, die nur plausibel klingt.