Correcting a summary is worth the thirty seconds when the correction outlives the summary. An edit repairs one account of one thread. A correction that’s kept becomes a rule, and shapes every account written after it. Which of the two you’re making decides almost everything about whether it’s worth doing.
- The gap between a general summary and the one you wanted is stable. Too long, dates buried, the ask at the bottom, the same way every Monday. A fault that repeats is a fault a rule can reach.
- A system can learn from you in two ways, and they cost very differently. Training on preferences takes tens of thousands of judgments. Keeping what you said takes one sentence.
- A correction can make things worse. In the study that measured this on email, feeding users’ own feedback back into the classifier lowered its accuracy by about five percent. The reasons sat in the mechanism rather than in the users.
- So there are two things to check. Can you read back what the system thinks you asked for? And does the next message from the same sender arrive in the new shape?
What it means for a summary to learn
Three quite different things get called feedback. One of them carries a rule.
The first is a signal. A thumbs up, a thumbs down, a star. It records that something was good or bad and stops there. A downward thumb could mean the length, the order, the tone, a missing date, a name in the wrong place. A signal is the cheapest feedback to give and the least useful to receive.
The second is an example. You rewrite the summary the way you wanted it, and the rewrite is kept as evidence. That carries much more, and carries it quietly. Somewhere in the difference between what you were given and what you wrote sits the thing you objected to. A dozen incidental choices sit there beside it. You shortened it, and you also happened to use the client’s initials. One of those was the point.
The third is an instruction. One sentence saying what you want instead. “Lead with the dates.” “Never drop the amount.” “For this supplier, tell me only what has changed since last week.” That’s the one of the three that arrives already in the shape of a rule, because you wrote it as one.
Underneath the three sits the question that decides whether any of this is worth your time. Ask it of every correction you’re about to make. Would I make this same correction again next week, on a different thread, from a different person? Yes means you’re describing a rule, and it should be stored as one. No means you’re repairing one summary. That’s a perfectly good thing to do, and it ends there.
Most software offers you the first kind of feedback and describes it as the third. That’s the gap this guide is about.
Why the same summary is wrong every time
A summary is one reading of a thread. Two people asked what matters in the same document disagree widely enough that a single right answer sits out of reach. A plain summary of every email works through that properly. Here it’s the premise rather than the subject.
What follows from it is the useful part. A summary written to a general standard is wrong for you in a consistent direction, because the gap between a general reader and your desk is a stable thing. You get the same disappointment every week. It usually falls on one of five axes.
Length. The account is faithful and three times longer than the decision needs. Or it’s short enough that you open the thread to find out what it meant, which costs you the whole saving.
What leads. The facts are all present and arranged as a story, so the deadline that governs your week sits in the fourth sentence. Order decides what you learn in the two seconds before you move on.
What has to survive. Every business has two or three things that belong in every account: the amount, the statutory date, the file reference, the name of the person actually asking. Drop one and the summary is unusable. It still reads as complete, because the other four facts are correct.
Vocabulary. Your trade has words for things, and a general summary uses the sender’s words instead. “The registration” means something exact in your office and something vague everywhere else.
The sender. Different correspondents want different shapes. A weekly report from a supplier wants only what changed. A first message from a prospective client wants the whole of what they asked for.
The arithmetic is what makes this worth doing. A fault that happens once is a nuisance you absorb and forget. A fault on every status report from one supplier, every Monday, for a year, is fifty occurrences of the same small tax. You pay each one at the moment you’d least like to stop and deal with it.
Two ways a system learns from you
The research on teaching a summarizer what people want is mostly about the first of these. It’s worth knowing what that bought and what it cost.
In Learning to summarize from human feedback, the authors set out to improve summaries by optimizing directly for what people preferred rather than for a similarity score. The paper went to the 2020 Neural Information Processing Systems conference, by Nisan Stiennon, Long Ouyang, Jeff Wu, Daniel Ziegler, Ryan Lowe, Chelsea Voss, Alec Radford, Dario Amodei and Paul Christiano. Their method worked, and the result is striking. A model with 1.3 billion parameters trained on human feedback beat a supervised model ten times its size. Readers preferred it over the dataset’s reference summaries 61 percent of the time, against 43 percent. Both of their feedback-trained models were judged better than the human-written summaries they’d originally been taught to imitate.
Now the price. The dataset they released to get there holds 64,832 summary comparisons, collected from paid labelers working to a written standard. That’s what it takes to move a general model toward general human taste.
Two things about that stay in the lab. The first is volume. Running a seven-person practice leaves you a long way short of sixty-four thousand judgments about your own mail, and a threshold that high puts being understood out of reach. The second is legibility. What a model learns from preference data lives in its weights, where there’s nothing to read, nothing to correct, and no way to find out why last week’s summaries changed shape.
The second way a system can learn is older and much plainer to describe. It keeps what you said. One sentence, stored in plain words, applied to the next thing that fits it. One instance is enough, so there’s no threshold to cross. The rule is a sentence in your language rather than a number in somebody’s model, so you can read the whole of it.
That’s the mechanism that fits one person and one mailbox. Its weakness is its strength inverted: it knows what you’ve actually said, and that’s all.
So a third thing usually runs alongside it, learning from what you do rather than what you say. The best public account of how that should look is Guidelines for Human-AI Interaction, presented at the 2019 conference on human factors in computing systems by Saleema Amershi, Dan Weld and eleven colleagues. They codified more than 150 scattered design recommendations into eighteen guidelines, then had 49 design practitioners test them against 20 popular products that use AI. Their thirteenth guideline is the one in question: “Learn from user behavior. Personalize the user’s experience by learning from their actions over time.”
Watching what you open and archive is cheap, because you’re doing those things anyway. The trouble is that behavior is ambiguous where a sentence is clear. You archived that thread unread because it was junk, or because you’d already settled it on the phone, or because you were on a train. The archive looks identical in all three cases. Their fifteenth guideline exists for that reason: “Encourage granular feedback. Enable the user to provide feedback indicating their preferences during regular interaction with the AI system.” Behavior is the cheap signal and the sentence is the clear one. A system holding only the first is guessing about you from evidence that reads the same way in three different cases.
What to correct and how to say it
Five kinds of correction are worth turning into a standing rule. They map onto the five axes above.
- The shape. How long, how dense, whether it comes as a paragraph or as lines you can run your eye down.
- What leads. The one thing that should be in the first six words, every time, whatever else follows.
- What must always survive. The amounts, the dates, the reference, the name of whoever is doing the asking.
- The words. What your business calls the thing, in place of what the sender called it.
- How one sender is handled. The supplier who sends the same report weekly, the client whose mail is always about one matter, the colleague who buries the ask in the last line.
Three kinds stay repairs. A wrong fact is a repair, not a preference, and the fix is to open the thread and read what was actually written. Anything you’d ask for once and then never again is a repair too. And a dissatisfaction you can’t put into words stays an objection until you can say what you wanted instead.
Then there’s how to phrase it, which matters more than people expect.
- Say what you want instead. “Too long” is a complaint, and cutting anything at all satisfies it. “Give me the deadlines and the amounts first, then two lines of context” is a rule, and one shape satisfies it.
- Name the scope out loud. This is the correction people get wrong most often. A rule can apply to one sender, to one kind of mail, or to everything you read. Those are three very different instructions. Say “shorter” while looking at a newsletter, meaning newsletters, and your client threads come back truncated.
- One rule at a time. Two changes in one sentence give you nothing to test. When the next summary comes back wrong, you’re left guessing which half failed.
- Correct on a representative example. The thread in front of you is the evidence your rule gets built from. Make the rule on an ordinary Tuesday rather than on the strangest email of the month.
- Say it while you’re looking at the failure. There and then, on the summary itself.
That last one comes from one of the oldest results in the field. In Paradox of the active user, a 1987 chapter in Interfacing Thought published by MIT Press, John Carroll and Mary Beth Rosson described what they called the production bias. “Their paramount goal is throughput. This is a desirable state of affairs in that it gives users a focus for their activity with a system”, they wrote, and on the other hand “it reduces their motivation to spend any time just learning about the system, so that when situations appear that could be more effectively handled by new procedures, they are likely to stick with the procedures they already know, regardless of their efficacy.”
They were writing about word processors, and the sentence describes your Tuesday exactly. A correction that makes you stop working, find a preferences screen and learn its vocabulary is a correction you’ll skip, however handsomely it would repay the two minutes. Carroll and Rosson are explicit about what this is. It’s a property of how anybody learns anything while trying to get work done, which makes it the design’s problem rather than yours.
Where learning from your edits goes wrong
One study took ordinary people’s corrections to an email system, fed them back into the machinery, and measured what happened. It’s worth reading closely, because the answer was the awkward one.
Interacting meaningfully with machine learning systems ran three experiments on a system that sorted email into folders and explained its reasoning as it went. It appeared in the International Journal of Human-Computer Studies in 2009, by Simone Stumpf, Vidya Rajaram, Lida Li, Weng-Keen Wong, Margaret Burnett, Thomas Dietterich, Erin Sullivan and Jonathan Herlocker. The first experiment was a think-aloud study. Participants saw why the system had filed a message where it did, and could say anything they liked about it, in any form they liked. They gave rich, specific, sensible advice. That was the encouraging result.
The second experiment put that advice into the algorithm as constraints, and accuracy went down. The constraint-based approach came out below plain online training by five percent on the participants’ keyword feedback, and by around three percent on the other paradigm. The authors went looking for why. Their three reasons are ordinary enough to recognize in your own working week.
Participants proposed the most obvious word for the folder, which the system had already learned, so the feedback was redundant. The handful of words they offered was too small a fraction of what the system was weighing to move any decision. And some of the advice, taken literally, “degraded the classifier by over-constraining the parameter space”. That’s a technical way of saying a true statement becomes a harmful rule when it’s applied more rigidly than you meant.
Their own conclusion is the honest one to carry away: “There are situations in which performance decreases by taking user feedback into account, possibly due to introduction of human errors into the learned information.”
The third experiment is the twist. The very same keyword feedback, taken through a different mechanism, produced a highly significant improvement, at p equal to 0.0057. Same people, same corrections, opposite outcomes. Whether your correction helps is largely a property of how the system takes it up, rather than of how well you phrased it.
Five failures show up in ordinary use. All five are visible once you know to look.
Over-reach. One correction applied wider than you meant it. This is the commonest by a distance, and it’s quiet. The thread you corrected comes back right, and a different one breaks next week.
The rule that was already true. You ask for something the system was doing anyway, the summaries look the same as before, and you conclude that corrections go nowhere here. Stumpf’s participants did exactly this.
The stale rule. February’s instruction is wrong in June. Rules stay until you take them out, and a mailbox that’s been learning for a year is carrying preferences you’d write differently today.
The silent change. Summaries start arriving in a different shape, and you’re left guessing whether that was your doing, somebody else’s update, or drift. Amershi’s group has three guidelines about precisely this, and they read like a specification: “Update and adapt cautiously. Limit disruptive changes when updating and adapting the AI system’s behaviors.” “Convey the consequences of user actions.” “Notify users about changes.”
The rule you would never have written down. Something learned from an unrepresentative moment, or from behavior that carried no meaning. Nobody would type “summarize everything the way I wanted it at 6pm on the worst Tuesday of the quarter”. A system inferring from actions can arrive there on its own.
All five become manageable under the same condition, which is why it’s the one to insist on. The preferences a system holds about you belong in a list you can read, in your own words, with each line editable and removable. That’s how you tell an over-reaching rule from a system that’s simply wrong, and those two problems have opposite fixes.
How to tell whether it learned
The test is cheap, and it takes about two weeks of normal mail.
- Write down what you asked for, and its scope, in the words you used. The sentence itself, so you can hold the result against it later.
- Wait for the next message inside that scope. Same sender, same kind of mail. That’s the fair test. A different sender’s thread leaves you where you started, and judging a per-sender rule on a stranger’s email is how people talk themselves out of a feature that was working.
- Check the edge as well as the middle. Look at one thread outside the scope you named, and confirm it came back the way it always does. A rule that improves the thing you aimed at and quietly alters everything else has done something other than what you asked.
- Count corrections, not summaries. The measurement that matters is whether you’re making the same correction a second time. One repeat means a rule that slipped or a scope that missed. Three repeats is your answer about the system.
- Read the list once a month and delete what has stopped being true. This takes a minute, and it’s the whole of the maintenance.
Two boundaries on what the test can tell you. A summary converges on something you can work from rather than on the one you’d have written yourself, because that target exists for nobody. The honest goal is a summary wrong in ways you can live with, rather than wrong the same way every week. And you’re measuring a rate rather than an instance. Some threads will always confound a general rule, and the fifth one that does still leaves the rule standing.
What a correction does not change
Four things sit next to this, and all four hold still when you correct a summary.
The ranking stays put. Asking for a shorter account says something about the account, and leaves open whether the thread was worth reaching you first. Which threads surface, and on what evidence, is a separate measurement, worked through in how email triage works. The corrections that feed it are a different kind of statement about a different question. Whether that side of it can be trusted has its own test, run the same way and on different evidence.
The date and the task stay separate. A rule can insist that deadlines lead every summary. Turning what a thread asks of you into something dated, which survives the thread being archived, is a different object with a different life, and email task management is where it lives.
The briefing stays separate. A preference about how one thread is described governs that thread. How your morning is presented is a separate read answering a separate question, and a rule that suits one will often be wrong for the other.
What happened stays what happened. A rule changes the account, and the thread underneath it holds still. The original messages are what was actually said. They stay a click away, and anything you’ll be held to is worth opening them for.
There’s a fifth thing worth naming, because people spend corrections on it. A summary can be badly shaped, which a rule fixes. It can also be strained by its source, which is a different problem. A thread that’s run for six weeks and reversed itself twice is hard to summarize for structural reasons, and those are set out in how to catch up on a long email chain. If the summaries you keep correcting are all forty-message chains, what you have is a source problem.
How Point takes a correction
Point is a full email client that works on your existing Gmail or Microsoft 365 account. Every thread in the feed arrives with a plain summary, written by Point before you sit down.
When one of those is faithful and still the wrong shape for you, you say so where you are. Point puts the summary you actually saw beside the space where you write what you’d change, so the correction lands against the thing in front of you rather than against your memory of it. One sentence in your own words is the whole of the input.
What happens next is the part that decides whether it was worth typing. Point keeps the sentence as a standing rule rather than spending it on the summary in front of you. The next message of that kind, from that sender, is summarized fresh with the rule already in place. Tell Point that summaries for you mean action items with dates, and the following week’s status report comes back with three action items and three dates at the top, where the story used to bury them.
Every preference Point holds about you lives in one place, written as plain sentences rather than as settings. The newest sits at the top, marked as added by you. You can write one directly before anything goes wrong, change the wording of any of them, or remove one that has stopped being true. Everything Point has learned about how you like things is there in a form you can read back.
The same rules carry into what Point writes for you. Ask for a reply, and the sign-off carries your phone number, because you said once that client mail should. You said it on some other thread, and it holds here. A friend gets the register you asked for rather than the formal one Point began with.
Each type of action carries its own level for how much Point does unprompted. The levels run from suggest-only through review to fully handled, and every type starts on review, so work arrives prepared and waits for you. Everything Point has done sits in one running log, in plain language, and you turn an action back from the entry that recorded it. The benefits page lists the rest of what’s finished before you open the inbox, and what an AI email client is makes the argument for the reading and the remembering living in the client rather than beside it.
Common questions
Does correcting an AI summary actually change anything?
It turns on whether the correction is stored as a rule or spent on one summary, and those two look identical at the moment you make them. To find out, name what you asked for. Then check the next message from the same sender that falls inside the scope you named. A changed shape there, and only there, means the correction was kept. Typing it again two weeks later is your answer the other way.
How many times do I have to say the same thing?
Once, when what you said is kept as a standing rule. The arithmetic in this guide is why that number is the one to hold out for. A fault that recurs weekly on one sender’s mail is fifty occurrences a year, and a system that has to be told fifty times has learned nothing. Making the same correction twice is the finding, not the process.
Will one correction change every summary I get?
That’s the risk, and it’s the one worth being deliberate about. A correction can properly apply to one sender, to one kind of mail, or to everything you read. Stating which you meant is the difference between a fix and a new problem. The common way this goes wrong is a rule made while looking at an unimportant email and applied to the ones that matter. So after you make a rule, check a thread outside the scope as well as one inside it.
Can it work out what I want without me telling it?
Partly, and less than you’d hope, because what you do is ambiguous where a sentence is clear. Opening, archiving and setting aside are all cheap signals, and every one of them has three plausible readings. That’s why the design guidance for systems like this asks for both: learning from behavior over time, and a way to state a preference during ordinary use. A summary tuned only from what you clicked is written by something inferring your taste from evidence that reads the same for junk as for already handled.
Is my correction used to train the AI?
That’s a separate question from whether it’s remembered, and worth keeping separate. A preference held for your account and material fed into model training are very different arrangements, with very different consequences for client confidentiality. What Point does with your mail on that front is set out in keeping your data out of AI training. That’s the page to read before you decide.
What if the summary is wrong about a fact rather than badly shaped?
Then you’re looking at a repair rather than a preference, and the fix is to open the thread and read what was written. A rule leaves a mistaken account mistaken, because a general instruction meaning “be right about this client’s deadline” is a thing nobody can write. Repairs are worth making, and they end where they start. That’s the test this guide runs on: would you make this same correction again next week, on somebody else’s thread.
What if I change my mind about a rule?
You should be able to remove it in the same number of seconds it took to make. This matters more than convenience. Rules stay until you take them out, and a preference set in February can be quietly wrong by June. A list you can read and prune is what keeps a year of corrections from turning into a shape nobody chose. Seeing what a system believes about you is what lets you tell an over-reaching rule from a system that’s simply mistaken.
The short version
An edit and a correction feel the same to make, and behave completely differently afterwards. One repairs the summary in front of you. The other becomes a standing rule and changes everything of that kind that arrives later. The second one is what’s worth interrupting your work for. The test that separates them is whether you’d make the same correction again next week, on somebody else’s thread.
What’s worth stating as a rule is the shape, what leads, what has to survive, the words your trade uses, and how one particular sender should be handled. Say what you want instead, name the scope out loud, and make one rule at a time. Then hold the system to two things: that you can read back what it believes about you in plain sentences, and that the same correction is only ever made once. A correction that vanishes costs you the thirty seconds and leaves the fault where it was.
What you end up teaching depends on what you read all day. An accounting practice mostly wants the statutory date and the figure at the front of everything, and a consultancy wants to know what moved in the scope since Friday. If your mail looks like something else again, the same morning is set out for other desks.