Rectification Prompter: Error-Based Optimization

• Rectification Prompter is a framework for prompt optimization that treats improvements as targeted error diagnosis and controlled repairs.
• It encompasses methods like Error Reflection Prompting, Contrastive Reflection, and Reflection-Enhanced Meta-Optimization to systematically diagnose and repair prompt mistakes.
• The approach uses iterative debugging, local validation, and memory-driven updates to enhance LLM performance across diverse tasks.

Searching arXiv for papers on prompt rectification, reflection-based prompt optimization, and related methodologies. “Rectification Prompter” can be understood as a plausible umbrella term for prompting and prompt-optimization methods that treat prompt improvement as error diagnosis, targeted repair, and controlled validation rather than as unconstrained prompt search. In the recent literature, this idea appears in three closely related forms: Error Reflection Prompting (ERP), which embeds an incorrect answer, explicit error reflection, and a corrected answer into in-context examples; Contrastive Reflection, which mines failure-heavy behavioral slices and proposes minimal prompt edits using nearby successful cases from the same slice; and Reflection-Enhanced Meta-Optimization (REMO), which couples TextGrad-style local prompt updates with a persistent “mistake notebook” and an LLM-based meta-controller that updates the optimizer itself (Li et al., 22 Aug 2025, Koh et al., 29 Jun 2026, Wu et al., 26 Aug 2025).

1. Conceptual foundations

The rectification view begins from a specific claim about prompt optimization: in practical LLM-agent settings, prompt improvement often resembles iterative debugging or rectification more than blind search. In the formulation used by Contrastive Reflection, an LLM program $\pi_\phi$ with prompt $\phi$ is evaluated by a task metric $m$ on validation data, with objective

$$\max_{\phi}\; \mathbb{E}_{(x,y)\sim D_{val}} \left[m(\pi_\phi(x),y)\right].$$

The method inserts an explicit diagnostic layer between failure observation and prompt editing. A slice selector

$$\mathcal{C}_t = g\!\left(D_{tr}, \{\pi_{\phi_t}(x):(x,y)\in D_{tr}\}\right)$$

produces error-anchored behavioral slices, and a reflection operator proposes a prompt edit

$\Delta\phi_t = r(\phi_t, C, a(C), E_C).$

The edited prompt is accepted only if validation improves, optionally subject to regression constraints: $$\phi_{t+1} = \begin{cases} \phi_c, & \text{if } A_t(\phi_c),\ \phi_t, & \text{otherwise.} \end{cases}$$ This makes rectification a validation-gated prompt-level repair process rather than an unrestricted rewrite process (Koh et al., 29 Jun 2026).

A central implication is that prompt rectification is defined less by a particular optimizer than by a workflow: identify a coherent failure mode, compare it to nearby successful behavior, propose a narrow repair, and reject edits that improve one region while damaging protected behavior elsewhere. This suggests a stronger connection to debugging, regression testing, and error analysis than to generic prompt search (Koh et al., 29 Jun 2026).

2. Error-centered exemplars and Error Reflection Prompting

ERP is the clearest exemplar-based realization of rectification. It extends Chain-of-Thought prompting by replacing “successful trace only” demonstrations with a three-part structure: Incorrect Answer, Error Reflection, and Correct Answer. The paper describes ERP as “comprised of an incorrect answer, error recognition, and a correct answer,” with the intended effect that the model learns not only the right procedure but also the boundaries of invalid reasoning. The practical template is consistent across tasks: $m$5 In arithmetic tasks, ERP uses error types including Misinterpretation, Missed Steps, Logical/Commonsense, Wrong Selection, and Algebraic/Calculation. In commonsense tasks, the reported categories are Self-Contradiction, Assumption, Encyclopedic, and Commonsense. The critique is local and operational: it is meant to identify the exact wrong step and state what should have happened instead, not merely to mark the answer as incorrect (Li et al., 22 Aug 2025).

ERP also supports automated generation. The reported procedure is: prompt the model to generate $n$ plausible errors for a question, construct an incorrect solution incorporating those errors, and then build the final ERP example with question, incorrect solution, error explanations, and correct solution. The public results show modest but consistent gains over few-shot CoT. For GPT-3.5 with 4-shot prompting, ERP improves GSM8K from 74.6% to 77.8%, AQUA from 54.3% to 58.7%, and MATH from 40.2% to 41.1%; 5-shot Auto ERP on GSM8K reaches 79.8%. For GPT-4, the gains are smaller but still positive: GSM8K 95.4% → 95.7%, AQUA 75.9% → 76.7%, and MATH 54.1% → 54.8%. On commonsense benchmarks, ERP also improves CSQA and slightly improves StrategyQA, but explicit error categories can reduce performance, as seen on StrategyQA where GPT-3.5 ERP with categories falls to 62.9% from 66.1% for plain ERP (Li et al., 22 Aug 2025).

3. Contrastive Reflection and slice-local prompt repair

Contrastive Reflection generalizes rectification from demonstration design to an iterative prompt-repair loop for LLM agents in information retrieval workflows. The framework is task-centric: QA agents expose retrieval or reasoning traces, and grading agents expose dimension-level scores and rationales. These traces are used to construct error-heavy slices rather than arbitrary failure batches. In the concrete implementation, a shallow entropy-based binary decision tree is fitted over training examples using derived diagnostic features and a binary correctness label, with splits selected by information gain

$$IG(S,\theta) = H(S) - \frac{|S_L|}{|S|}H(S_L) - \frac{|S_R|}{|S|}H(S_R),$$

where

$H(S)=-\sum_{c\in\{0,1\}} p_c(S)\log_2 p_c(S).$

The resulting leaves are ranked by error density, support, and interpretability. The selected evidence set contains not only failures but also successful examples from the same region/path, so the Teacher LLM sees the local behavioral boundary it is meant to preserve (Koh et al., 29 Jun 2026).

The Teacher receives four inputs: the tree path defining the slice, a small set of error examples from that slice, a small set of successful examples from the same region, and the relevant prompt section to edit. The output is a targeted prompt edit, not a full rewrite. In the public HotpotQA retrieval-augmented QA setup, one tree-selected contrastive repair improved held-out exact-match accuracy from 51.4% to 60.4%, with validation rising from 56.0 to 64.0. Failure-only reflection improved test accuracy to 54.6%, and random contrastive reflection to 59.0%. The fine-grained fixed/broken accounting is also informative: tree contrastive fixed 54 held-out examples and broke 9, random contrastive fixed 52 and broke 14, and failure-only fixed 35 and broke 19. A second tree-selected repair was rejected because it over-corrected: validation dropped to 58.2%, it fixed only 7 validation examples, and it broke 36. This makes the validation gate an essential part of the method rather than a peripheral safeguard (Koh et al., 29 Jun 2026).

4. Memory-driven rectification and meta-optimization

REMO extends rectification into a two-level corrective architecture. At the local level, it performs TextGrad-style prompt optimization. At the higher level, it maintains a persistent Reflection RAG / mistake notebook and a Self-Adaptive Optimizer that updates the optimizer prompt itself. At epoch $\phi$0, the system has a system prompt $\phi$1, memory $\phi$2, and optimizer prompt $\phi$3. For an input $\phi$4, it retrieves relevant memory

$\phi$5

then predicts

$\phi$6

When a prediction is wrong, the memory is updated with a structured record such as

$\phi$7

After a minibatch or epoch, a reflection summary $\phi$8 is produced and used to update the optimizer prompt,

$\phi$9

while a TextGrad-style pseudo-gradient $m$0 is converted into a new system prompt under the guidance of $m$1: $m$2 This architecture turns prompt rectification into a continual process that stores prior failures and also updates the policy by which future repairs are proposed (Wu et al., 26 Aug 2025).

The empirical findings are dominated by a generalization argument. On GSM8K, TextGrad alone is reported to overfit severely: with full training data, it reaches 91.0 validation accuracy and 62.0 test accuracy at 3 epochs, and 90.0 / 63.0 at 5 epochs. Reflection RAG greatly improves test accuracy to 89.0 and 89.8. The Adaptive Optimizer alone reaches 90.1 / 90.0 at 3 epochs and 90.3 / 93.2 at 5 epochs. The full RAG+Optimizer system is more stable, with 90.1 / 90.1 at 3 epochs and 90.3 / 90.5 at 5 epochs. The paper explicitly notes the cost of this robustness: 3–5× training time increase, top-$m$3 retrieval with $m$4, and noise sensitivity in the current simple concatenation-based memory fusion (Wu et al., 26 Aug 2025).

5. Shared architecture of a rectification prompter

Taken together, these papers suggest a common “Rectification Prompter” architecture, although this synthesis is broader than any single named method. The shared structure is a failure-centered control loop in which prompt improvement is anchored in observable mistakes, supported by localized evidence, and constrained by validation or memory rather than driven by unconstrained rephrasing (Li et al., 22 Aug 2025, Koh et al., 29 Jun 2026, Wu et al., 26 Aug 2025).

Approach	Rectification substrate	Control mechanism
ERP	In-context exemplars	Incorrect answer, error reflection, correct answer
Contrastive Reflection	Prompt edit loop	Slice-local contrast plus validation gate
REMO	Prompt optimizer with memory	Mistake notebook plus self-adaptive optimizer

In this composite view, rectification has at least five recurrent components. First, there is a defect representation: a wrong answer, a failed slice, or a stored mistake record. Second, there is a diagnostic contrast: explicit critique in ERP, nearby successful examples in Contrastive Reflection, or retrieved historical failures in REMO. Third, there is a repair operator: a corrected reasoning trace, a Teacher-proposed prompt patch, or a TextGrad-style update shaped by a meta-controller. Fourth, there is a safeguard: validation improvement, regression constraints, or a memory-informed strategy intended to reduce overfitting. Fifth, there is an implicit or explicit preservation objective: do not disturb nearby correct behavior while fixing the targeted failure (Li et al., 22 Aug 2025, Koh et al., 29 Jun 2026, Wu et al., 26 Aug 2025).

6. Empirical profile and evaluation discipline

The public evidence across these methods points to a consistent empirical pattern: rectification is most effective when the method sees both failure structure and a preservation signal. In Contrastive Reflection, the slice-local contrastive variant outperforms both failure-only reflection and random contrastive evidence, while also producing fewer regressions. In ERP, the strongest gains occur in arithmetic tasks, where errors are localizable and procedural. In REMO, the strongest single component is the self-adaptive optimizer, which sharply reduces the validation–test gap relative to TextGrad (Koh et al., 29 Jun 2026, Li et al., 22 Aug 2025, Wu et al., 26 Aug 2025).

Setting	Baseline	Rectification result
HotpotQA test EM	51.4	60.4 with tree contrastive
GSM8K, GPT-3.5, 4-shot	74.6 CoT	77.8 ERP
GSM8K, GPT-3.5	74.6 CoT	79.8 Auto ERP
GSM8K, full data, 5 epochs	63.0 TextGrad test	93.2 Adaptive Optimizer test

These results also clarify the role of evaluation. Contrastive Reflection uses a strict acceptance rule: keep an edit only if validation improves, and optionally only if regression constraints remain within tolerance. The HotpotQA study shows why this matters: a second repair that targeted another visible failure mode was rejected because it improved too little and broke too much. REMO’s results show a different form of evaluation discipline: the principal failure of plain TextGrad is not low validation performance but poor generalization, so stable rectification must inspect validation–test behavior rather than immediate prompt gains alone. ERP contributes a third lesson: evaluation depends on prompt format details, and more structure is not always better; error categories can improve analysis while harming task accuracy (Koh et al., 29 Jun 2026, Li et al., 22 Aug 2025, Wu et al., 26 Aug 2025).

7. Limitations and open problems

The current literature also makes the limitations of rectification-oriented prompting explicit. ERP is task-sensitive: the authors note overfitting, prompt tailoring to specific tasks, substantial token cost, and weaker gains on highly complex reasoning such as MATH. They also report that ERP appears less effective as model scale increases, and that rationale quality is a bottleneck for automated ERP generation (Li et al., 22 Aug 2025).

Contrastive Reflection assumes usable structured outputs or traces. When those traces are weak, slice quality degrades. The public evidence is also narrow: one public HotpotQA setup, one-step repair, and a light comparison to GEPA-light (57.0%) and MIPROv2-light (59.4%) rather than a broad cost-matched benchmark suite. The framework defines regression constraints formally, but the public HotpotQA experiment uses only validation-gated acceptance. Teacher-generated references are not guaranteed to be ground truth, and over-correction remains a live risk, as the rejected second repair demonstrates (Koh et al., 29 Jun 2026).

REMO introduces a different set of concerns. Its memory can accumulate noise; retrieval currently relies on simple concatenation, which the paper states may introduce redundancy or irrelevant context; cold-start behavior is unresolved; and the self-adaptive optimizer reportedly relies mainly on macro-level signals such as validation trends rather than fine-grained error-type distributions or severity analysis. The framework improves robustness but at increased computational overhead, with 3–5× longer training time than the TextGrad baseline (Wu et al., 26 Aug 2025).

A plausible implication is that a mature Rectification Prompter will need to integrate localized error representations, preservation-aware edits, historical memory, and held-out safeguards without assuming that any one of these is sufficient alone. The present literature supports the rectification principle itself—wrong trace, diagnosis, repair, and validation—but leaves open the questions of how to scale it across tasks, how to control memory quality, and how to guarantee that corrective edits remain both minimal and durable (Li et al., 22 Aug 2025, Koh et al., 29 Jun 2026, Wu et al., 26 Aug 2025).