Reflexionsmuster (Рефлексія)

1. Konzeptüberblick und systemisches Problem

Autoregressive Sprachmodelle weisen eine fundamentale architektonische Eigenschaft auf: Sie generieren Token sequenziell und verfügen über keinen Mechanismus für ein hardwareseitiges „Backtracking“. Wenn das Modell zu Beginn einer Funktion einen suboptimalen Ansatz wählt, zwingt der Self-Attention-Mechanismus es dazu, den Code innerhalb dieser fehlerhaften Trajektorie fortzusetzen:

1. Die Illusion von Sicherheit: Das Modell generiert Code mit Halluzinationen oder fehlenden null/undefined-Prüfungen mit gleichermaßen hoher Konfidenz.
2. Auslassen von Edge Cases: Bei der Ein-Pass-Generierung (Zero-Shot) ist die Aufmerksamkeit des Modells auf das Basisszenario (Happy Path) fokussiert, während Fehlerbehandlung, Race Conditions und Speicherlimits ignoriert werden.
3. Geringe Qualität des ersten Entwurfs: Wie ein menschlicher Ingenieur schreibt auch künstliche Intelligenz selten makellosen Architekturcode beim ersten Versuch ohne sorgfältige Überprüfung.

Das Reflection Pattern etabliert einen metakognitiven Zyklus: Das Modell wird zum eigenen Code-Reviewer, der das Ergebnis gegen klare ingenieurtechnische Kriterien bewertet, bevor es die finale Antwort zurückgibt.

2. Architektonische Taxonomie und mentales Modell

Die klassische Implementierung des Reflexionspatterns besteht aus drei spezialisierten Komponenten:

• 1. Generator (Producer / Generator): Nimmt die Eingabeanforderungen des Nutzers entgegen und generiert die primäre Lösung $S_0$. Der Fokus liegt auf der Lösung der funktionalen Aufgabe.
• 2. Kritiker (Auditor / Critic): Erhält das generierte Artefakt $S_0$ und bewertet es aus der Perspektive eines peniblen Architekten oder Sicherheitsauditors anhand einer strukturierten Checkliste (Komplexität $O(N)$, Memory Leaks, OWASP-Schwachstellen, Typsicherheit). Er erstellt eine detaillierte Liste der Beanstandungen $C_0$.
• 3. Verfeinerer (Refiner): Erhält den Quellcode $S_0$ zusammen mit der Kritik $C_0$ und generiert eine aktualisierte Version $S_1$, in der alle angegebenen Mängel behoben sind.
• 4. Arten der Reflexion:
  • Interne Selbstreflexion (Internal Self-Reflection): Die Kritik erfolgt ausschließlich durch das LLM selbst mittels eines speziellen Prompts.
  • Umgebungsbezogene Reflexion (Grounded / External Reflection): Die Kritik stützt sich auf objektive Fakten – Compiler-Ausgaben, Linter-Fehler oder das Scheitern von Unit-Tests.

3. Technischer Pipeline und interne Mechanik

Der Lebenszyklus des reflexiven Prozesses:

1. Initial Drafting (Erstellung der primären Lösung): Der Generator erstellt eine Kandidatenlösung für die Aufgabe.
2. Adversarial Critique (Audit durch den Kritiker): Der Prompt des Kritikers wird mit der expliziten Anforderung aufgerufen, maximal streng zu sein: „Analysiere den folgenden Code. Finde mindestens 3 potenzielle Absturzpunkte, Memory Leaks oder Edge Cases, die im Production-Umfeld zu Fehlern führen.“
3. Stopping Invariant Evaluation (Prüfung des Abbruchkriteriums): Das Ergebnis der Kritik wird bewertet: Wenn keine kritischen Beanstandungen vorliegen oder das Limit der Runden erreicht ist (iterations >= 2), gibt das System die aktuelle Lösung zurück.
4. Targeted Revision (Gezielte Überarbeitung): Der Generator erhält eine Systemnachricht: „Hier ist der ursprüngliche Code und die Anmerkungen des Auditors. Schreibe die Funktion um und behebe jede Beanstandung, ohne die Funktionalität zu beeinträchtigen.“

4. Praktische Engineering-Szenarien im Production-Umfeld

01. Sicherheitsaudit von Code und Smart Contracts

Der Generator schreibt eine Transferfunktion in einem Solidity Smart Contract. Der Kritiker analysiert den Code und weist darauf hin: „Zeile 14 ist anfällig für Reentrancy-Angriffe, da die Balance-Änderung nach dem Aufruf des externen Contracts stattfindet.“ Der Refiner fügt den Modifier nonReentrant hinzu und verschiebt die State-Updates vor die Auszahlung (Checks-Effects-Interactions Pattern).

02. Performance-Optimierung von SQL- und ORM-Queries

Der Kritiker überprüft den für das Laden verbundener Entitäten generierten Code und warnt vor dem $N+1$-Query-Problem: „Ein Loop wurde verwendet, um auf verbundene Profile zuzugreifen; ersetzen Sie dies durch einen einzigen JOIN oder Eager Loading via include.“

03. Synthese robuster Regular Expressions

Das Erstellen einer Regular Expression zur Validierung komplexer E-Mail-Adressen oder Telefonnummern. In der Reflexionsphase testet der Kritiker die generierte Regex gegen 10 nicht-standardmäßige Edge-Cases (ReDoS-Angriffe, leere Strings, Sonderzeichen) und weist auf Fälle hin, in denen der Filter umgangen werden kann.

5. Fallstricke, typische Fehler und Sicherheit

• Sycophancy des Kritikers: Wenn der Prompt des Kritikers zu weich formuliert ist, neigt das Modell dazu, seine eigene Lösung zu loben („Der Code sieht großartig aus!“), was die Reflexion hinfällig macht. Diktieren Sie stets die Rolle eines kompromisslosen Sicherheitsauditors.
• Halluzinierte Kritik (Over-Critique): Der Kritiker kann Probleme erfinden, wo keine existieren, und den Generator dazu bringen, einfachen, funktionierenden Code durch unnötige Wrapper zu überkomplizieren. Verankern Sie die Kritik in realen Tests und dem Compiler.
• Endloses Oszillieren: Im ersten Schritt bittet der Kritiker um das Hinzufügen einer Prüfung, im zweiten darum, sie als redundant zu entfernen. Legen Sie unbedingt die maximale Anzahl der Schleifenschritte fest.