IN THIS BREAKDOWN · 10 SECTIONS
You can read 20% of this breakdown.
The paper in one minute
People rarely get a piece of writing or code right on the first try; they reread it, notice problems, and revise. Aman Madaan, Niket Tandon, Peter Clark and colleagues at CMU, the Allen Institute for AI and elsewhere asked whether a language model can do the same with no training, using only prompts. Their method, Self-Refine, presented at NeurIPS 2023, uses one model in three roles.
First it generates an output from a few-shot prompt. Then it writes feedback on that output, using a prompt whose examples show feedback that is actionable (it proposes a concrete change) and specific (it names the part to change): "This code is slow as it uses a for loop which is brute force. A better approach is to use the formula n(n+1)/2." Then it refines: rewrites the output given the feedback and the full history of earlier outputs and feedback. The loop repeats up to four times, or stops when the feedback includes a stop signal, such as a quality score above a threshold.
They tested seven tasks: making dialogue responses more engaging, speeding up programs, improving variable names, math word problems (GSM8K), reversing the sentiment of reviews, generating acronyms, and writing a sentence that uses 20 to 30 given keywords. With GPT-3.5, ChatGPT and GPT-4, Self-Refine improved six of the seven, often by a lot. GPT-4's keyword coverage tripled from 15% to 45%. Math did not move: the model's feedback almost never noticed its own errors.
The analysis is as useful as the results. Specific feedback beat generic feedback, which beat none. Most of the gain came in the first round or two. And when refinement failed, the feedback was almost always to blame.
Research notes: the problem, approach and results
keyword coverage on constrained generation with GPT-4 after Self-Refine
change in math solve rate for all three models; ChatGPT's feedback said 'everything looks good' on 94% of answers
of the reviewed failures caused by the feedback (wrong fix or wrong location), not by the rewrite
A model's first draft is often close but not right: a reply that ignores the user's feelings, code that works but is slow, a sentence that misses required keywords. Fixing that usually meant training a separate refiner or collecting human feedback.
Use the same model three times with three few-shot prompts: generate an output, write specific and actionable feedback on it, and rewrite it using the feedback and the history of earlier attempts. Repeat up to four times or until the feedback says to stop.
Across seven tasks with GPT-3.5, ChatGPT and GPT-4, refined outputs were preferred or scored higher on six, by large margins on constrained generation and code readability. Math reasoning did not improve, because the feedback rarely found the errors.
Why it matters to an FDE
A draft, critique, rewrite loop is easy to add to almost any generation step, and customers often suggest it. This paper tells you where it pays.
It works when the model can see the problem. Missing keywords, a cold tone, a nested loop, single-letter variable names: things a reader spots and fixes. It does not work when spotting the problem is the hard part, as with a subtle arithmetic slip.
The feedback step is the bottleneck. In the authors' review of failures, 94% came from feedback that pointed at the wrong place or suggested the wrong fix. Spend effort on the critique prompt, and give it external signals (test results, a validator, a checklist) whenever you can.
An outside signal changes everything. On math, telling the model only which answers were wrong raised GPT-3.5 by 4.8 points where its own feedback had added nothing. If you have a check in code, use it to decide when to refine.
Read preference numbers carefully. Half the tasks were scored by asking GPT-4 which of two outputs is better. A large win-rate gap can come from small but consistent improvements, so do not read it as a quality percentage.
Understand the mechanism. Try it on a real problem.
Unlock this breakdown and 99 more papers.
Premium opens every paper in full, plus every answer, concept, course and guide on the site. One payment for six months of access.
6 months · One payment · No auto-renewal
- ◇1 architecture diagram
- </>1 runnable code experiment
- ▦1 results table
- ?5 interview questions with answers
- 03Key takeaways
How the loop works, the results by task and model, the ablations, and misreadings to avoid
Free account - 04How it works
The three prompts, what goes into each, stopping rules, and the evaluation setup
Premium - 05The numbers that matter
Gains by task, which ones are significant, the ablations, and how the headline number is built
Premium - 06Try it yourself
Separate error detection from repair, then see how A/B win rates exaggerate small improvements
Premium - 07Where it breaks
Where self-refinement fails and what the evaluation cannot show
Premium - 08Using it on a deployment
Adding a critique and rewrite step where it helps, and stopping where it does not
Premium - 09Interview angles
Five questions this paper prepares you for, with answer hints
Premium - 10Read next
Where to go from here on this site
Premium
