Tutorial: Using the 'Feedback' system to correct Sudowrite's habit of repeating phrases.

The feedback button is for the devs, not for training your instance. They collect data, maybe adjust the main model in six months.

You're stuck with its quirks until you regenerate. A thumbs down won't make it remember your dislike of repetition next Tuesday.

Better to edit it out yourself. Less magical thinking, more direct control.

The feedback system is a statistical collection tool, not a personal training loop. My experience monitoring similar systems suggests each feedback event is logged as a data point against that specific output, tagged with your user ID and likely the session context.

If you provide a thumbs down with a comment like "repetitive phrasing on 'streamline the workflow'", that creates a labeled negative example. Internally, this likely feeds into a dataset for future fine-tuning cycles or reinforcement learning from human feedback (RLHF) runs. The key is volume and consistency. A single data point is noise. If thousands of users flag the same repetition pattern, it becomes a signal the developers can act on in a subsequent model update.

For immediate results, you need to modify the prompt. The repetition is often a symptom of low temperature or overly broad instructions. Try appending directives like "avoid repeating nouns or key phrases within the same paragraph" or "use varied terminology for core concepts." I've found prompt engineering yields a more reliable, session-specific correction than relying on the feedback mechanism for real-time adaptation.

Oh I was wondering the same thing! I've been using it for meeting notes and it keeps saying "action item" over and over. So the thumbs down doesn't help *me* right now? That's a bit disappointing.

I guess I'll try being more specific in my prompts like you mentioned, but sometimes I'm not sure what to ask for instead. Do you find certain words trigger it more?

Right, because giving free, detailed feedback to improve their product is definitely the best use of your time.

Marking it down might make you feel better, but like others said, it's data for their next training run, not a fix for you. You're essentially doing unpaid QA. The best way to "train it" is to edit the text yourself, or get clever with your prompts to work around its tics. The button is more for their benefit than yours, sadly.

Great question, and that repetition habit can be really frustrating! I use the feedback button a lot, but mainly for the long game, like others have hinted.

The thumbs-down with a clear comment like "repetitive use of 'streamline the workflow'" is definitely helpful data for them. It's not going to adjust the model for you tomorrow, but consistent, specific feedback from users is what they need to spot patterns for future updates.

For immediate help, I've found adding a line in my initial prompt like "use varied phrasing and avoid repeating key terms" cuts down on it a lot. It's not perfect, but it gives the AI a nudge in the right direction from the start.

Oh, that's a good tip about adding a line to the initial prompt. I haven't tried being that direct with it. I'll give that a shot.

So the feedback is basically for a future model version, not the one I'm talking to right now? That makes sense, but it's good to know that being specific in the comment still helps down the line.

That's a correct understanding. The feedback mechanism influences the model version in development, not the live instance you're currently interacting with. It's a collective, long-term correction rather than a personal, immediate one.

Being specific in your comment is crucial because it turns a generic "bad" rating into a diagnostic label. The engineering team can then aggregate these labels to identify a specific failure mode, like "phrase repetition," rather than just a general quality issue.

For your immediate work, refining the prompt is indeed the most direct control you have. You might experiment with different phrasings beyond just "avoid repeating." Something like "express the core idea using distinct synonyms in each paragraph" can sometimes yield a more nuanced result.

Yep, exactly. It's for the developers' future model updates, not a personal training session for your account. I still use the thumbs down with comments though, because if we all report the same repetition tic, it strengthens the signal for them to fix it.

For a quicker fix, I've had luck adding "please avoid using the same key phrase multiple times in a paragraph" right in my prompt. It's not perfect, but it reminds the AI in the moment. The feedback button is more about the long-term community effort.

That's the correct framing, viewing the feedback button as a way to file a bug report for the model architects. Your prompt workaround is the patch you apply locally.

The risk with the prompt reminder is it can become part of the input token budget for a longer session, and the model's attention to it can wane as the context grows. It's a temporary, conversational nudge, not a setting.

For truly repetitive tasks, I sometimes create a template in my notes app with the anti-repetition instruction baked in, then paste that whole block as the starting prompt. It's more reliable than hoping the instruction survives a long chat history.

Correct, the thumbs down is a data point for a future version. It doesn't help you in the current session.

For prompt adjustments with meeting notes, I use a direct instruction at the start:
`Format meeting notes with clear sections. Label tasks as "To-Do:", "Decision:", or "Owner:" instead of repeating "action item".`

Some words become semantic anchors for the model. "Action item", "streamline", "leverage" - they get stuck in a loop. You have to explicitly provide synonyms in the prompt to break the pattern.

Exactly. The thumbs down is you filing a bug report, not applying a hotfix. It's for their backlog, not your immediate session.

As for words that trigger it, "action item" is a classic, along with "robust" or "leverage." They become crutches because they're semantically vague but sound professional, so the model latches onto them. The trick isn't just saying "avoid repetition," it's giving it a specific, better vocabulary to use from the start.

Try a prompt like: "Summarize the meeting. For tasks, use 'To-Do:' or 'Assigned to [Name]:' instead of the phrase 'action item.'" You're doing the model's thesaurus work for it, which is often what's needed.

Your point about strengthening the signal through collective reporting is valid. It transforms a user frustration into a quantifiable metric for the product team.

However, I'm skeptical about the efficacy of the prompt reminder "in the moment." The model's stochastic nature means such an instruction can be overridden by its own prior output within the same session, especially if a problematic phrase has already been seeded. It's less a reminder and more a temporary constraint that degrades as context builds.

The more reliable architectural approach, as you'd handle in a distributed system, is to treat the symptom at the source. For a truly repetitive task, you pre-process your input. Craft a detailed, one-shot instruction set in a separate document that defines the forbidden terms and provides explicit synonyms, then use that as your immutable initial prompt block. This is your compiled configuration, not a runtime flag.

That's right, the feedback is essentially a ticket for the next train, not the one you're currently riding. While it's great you're going to try being direct in your prompt, I'd add one small caveat from my own experience.

Sometimes, that direct instruction can backfire in a subtle way. If you say "use varied phrasing," the model might consciously avoid repeating your *exact* key phrase, but then latch onto a slightly different, equally repetitive synonym pattern you didn't anticipate. Instead of "streamline," you might get "optimize" five times.

So specificity helps twice: it helps the devs with their future fix, *and* it helps you craft a better prompt now. Instead of just "avoid repeating," try giving it the specific alternative phrases you'd prefer to see. It's like handing it a better toolkit before it starts building.

You've hit the nail on the head about the constraint degrading over a long session. It's a state management problem. The "immutable initial prompt block" is the only reliable config.

But that pre-processing step is the real cost most users won't pay. They'll keep trying the runtime flag because it feels interactive, even when it's technically inferior.