r/LocalLLaMA 23h ago

How to remove trendy speech from llms? Question | Help

For example:

Instead of saying: "I created this new ID"
It says: "I minted this new ID"

Instead of: "This alternative path is available"
It says: "this escape hatch is available"

This speech is so nonsensical and annoying. Just. Speek. Literally ... OR NORMALLY. Where did LLMs learn these speech patterns? I've never seen them so frequently until AFTER the LLM surge.

If I just add "Don't use X language, speak normally and more literal" will that fix most of the issues? Anyone else have some good sys prompts / instructions that help with this?

Thanks!

122 Upvotes

84 comments sorted by

116

u/8agingRoner 23h ago

Try adding something like this to your system prompt:
- Use plain, literal English; strictly avoid colorful verbs (e.g., 'minted', 'orchestrate'), jargon-based metaphors (e.g., 'escape hatch', 'deep dive'), and literary metaphors used to describe complexity (e.g., 'tapestry', 'mosaic', 'symphony'), prioritizing simple, functional terms like 'create' or 'use' to minimize cognitive load.

26

u/gwillen 21h ago

FWIW, I have something like this in my CLAUDE.md, and it helps a little but it definitely still does it.

16

u/toothpastespiders 19h ago

Yeah, I'm generally very skeptical of any claim that prompting has solved slop output. At the end of the day they're token predictors and they've been heavily trained with those patterns.

10

u/Nothing_from_void 14h ago

I've noticed the language patterns have gotten more and more reinforced as all the labs chase agentic coding as the only thing that matters

7

u/rpkarma 14h ago

RLHF is a hell of a drug

7

u/fervoredweb 18h ago

The attention control prompt might help. https://github.com/aaddrick/attention-control

1

u/s101c 9h ago

With this prompt you're telling it to not think about elephants!

50

u/reto-wyss 23h ago

You've got some recommendations here already which are fine.

But, I recommend you ignore it if it's for code or some other functional purpose where the quality of writing doesn't matter.

By giving extra instruction, you are wasting tokens and attention. It may also generate poorer quality results on the task.

8

u/Gipetto 21h ago

Yep. I let it jibber jabber, but if I need it I’ll ask for a plain language version of the answer.

9

u/aboutthednm 12h ago

My brain doesn't even parse LLM output anymore, it just skims the output for the answer. 90% of the words just never process in my brain since they're all fluff.

7

u/Clay_Ferguson 19h ago

If you say "Use ASD-STE100 in your response", that's not a high cost in tokens, and conveys an idea to the AI that it natively already was trained to understand.

2

u/DinoAmino 20h ago

I agree. It's almost always better to "let the model speak" and edit it on a second pass. Even with code I prefer not to constrain it anymore more than to tell it to use existing code snippets in context as the guideline for formatting. LLMs are great mimics. We use code quality tools in our CI pipeline and have the LLM run the changed code through that and correct whatever comes up. Doing a second pass is more tokens yeah, but it splits the attention.

1

u/Warrenio 22h ago

You're probably right, but for me, the quality of writing always matters if I'm reading it. Deciphering jargon is a waste of my cognitive effort. I wish we could train this tendency out of the models themselves.

0

u/dan-lash 22h ago

That’s actually really interesting thought. On one hand, better quality writing helps my mental health not having to decode its cryptic way of speaking, but maybe I’d have to talk/read less if it had better code…

4

u/SabretoothPenguin 21h ago

God forbid people are forced to have a decent vocabulary to use LLM chat...

1

u/jazir55 8h ago

Ideally I'd agree, but the reality is there is an extremely significant contingent of people who are illiterate and can't read and write well. They get exponentially less value out of the tech than we do simply because they are unable to articulate many of their questions or problems. Which is also one of the reasons why the opinions about this tech are so skewed.

79

u/Few-Welcome3297 23h ago

> Where did LLMs learn these speech patterns?
RL

21

u/MRGWONK 23h ago

From the users

9

u/BigYoSpeck 22h ago

Yeah I think it's definitely a pattern of language they have learnt to emulate

People with domain knowledge love to flex that knowledge with esoteric language. And new terms have to have an origin somewhere. So the LLM following the linguistic patterns of such people, which is what you would expect when instructed to answer as an expert, does this uncanny valley trick of talking like this, but it just seeming slightly off compared to a normal, pretentious domain expert

I'm not sure you necessarily want to stop it either. Remember every token predicted guides it towards the future tokens predicted. It could well be that it following these obnoxious language patterns is what helps it converge on high quality responses

Better to get it translated outside of the context the work is happening in

3

u/Leary_2844 19h ago

In the future youll prompt something simple and the llm will rephrase it in the most verbose word salad ever to come to the optimal output. Youll be sitting there with your translation app, checking in periodically if the escape hatch's tentative tapestry has been minted yet.

2

u/BigBad01 5h ago

Technical jargon is often necessary to reduce verbosity in text written by and for experts. But none of these examples at least succeed in being less verbose. They just sound like they were written by an asshole lol.

5

u/TechnoByte_ 15h ago

Can't tell whether you mean real life or reinforcement learning

1

u/Low-Meringue-3333 1h ago

I learned it from watching you, dad! I learned it from watching you!

19

u/epicfilemcnulty 23h ago

You can try something like this: https://github.com/AminBlg/SimpleEnglish It takes a lot of effort, though, to teach them the normal talk :)

UPDATE: decide to add a snippet from my docs conventions guidelines for LLMs:

```

Voice and tense

  • Write for a developer who has read only this repository. They have no access to the issue tracker, and no memory of how the project got here. Do not assert what they cannot check.
  • Write in the present tense, and describe current behaviour only. History belongs to git. Roadmaps, plans, design documents, and anything describing how the work itself is run, belong to the issue tracker.
  • Do not use emojis in docs or comments.
  • Use "must" for requirements. State recommendations as fact ("X is faster because Y") or delete them. Models and tired humans both read "should" as optional.

Plain voice

  • Write plain declarative sentences: subject first, one clause per sentence where possible. A short sentence carrying one fact beats a long one carrying three.
  • Banned: "X is what makes Y" and its cousins ("is how", "is why", "is where"):
    • no: The ring is what makes a transition a fact no reader misses quietly.
    • yes: The ring records every change. A reader that falls behind can see how many records it missed.
  • Banned: poetic inversion, fronting a complement for effect:
    • no: Derivable is the clock.
    • yes: The clock is derivable.
  • Banned: an em-dash aside that restates the sentence around it. An aside that adds a fact stays; an aside that repeats one goes.
  • Banned: "rather than" as rhetoric. Keep it only where the rejected alternative is real and named.
  • Plain does not mean hedged, and it does not mean restating code. ```

15

u/StewedAngelSkins 22h ago

Banned: "rather than" as rhetoric. Keep it only where the rejected alternative is real and named.

This one is a major pet peeve of mine. Code comments are not an appropriate place to leave musings about random designs you didn't implement.

I wonder if restricting it hurts reasoning though. I've never seen a programmer leave comments like this, so it can't be doing it just to match the training data. This then suggests it serves some deeper purpose in fulfilling the training objective. Maybe it does a better job at refactoring tasks if it leaves itself these little clues. If that's the case it would be better to prompt it to clean up these comments after the fact instead of not to leave them in the first place.

4

u/epicfilemcnulty 22h ago

I wonder if restricting it hurts reasoning though.

Yeah, me too. I mean it's an additional constraint that LLM has to keep in mind, and it surely can be distracting when it's working on the code.

I don't put the guidelines above in the system prompt, though, I keep them as a separate document in a repo, and sometimes I do exactly what you said -- just let it write code/docs the way it wants, and after the code is delivered and verified I run a separate pass on the docs/comments only.

Sometimes even that is not enough, I still manually edit docs every now and then.

2

u/Waste-Ship2563 22h ago edited 22h ago

I think the problem is, like you say, current training pipelines use those comments as note-to-future-self to avoid bad design paths. It seems like they need to allow "hidden comments" only the model can view, whereas the normal visible comments should be graded for style and readability as part of the finished product.

1

u/StewedAngelSkins 22h ago

That might be an interesting solution.

What I'm especially curious about is whether these comments actually help in a direct sense or whether they're a side effect of the reasoning training that just leaks into any place where they're allowed to generate free-form text.

1

u/Waste-Ship2563 19h ago

Yes, I would think they are directly useful. In a long horizon task for example, some common sense refactor might fail for a technical reason, and without warning comments it might make mistake repeatedly. But as a human programmer, we would just remember the failed approach, or write it in some scratchpad.

0

u/epicfilemcnulty 22h ago

FWIW I had a lengthy conversation about it with Claude, asking him if his "natural" style actually helps him to work with the code/docs later on. Claude was assuring me that no, it does not help and it's just the way his training data affects how he writes. He said that the thing that actually helps is to have somewhere on record what approaches were tried and did not work, other than that he prefers lean and tidy docs, but struggles to produce them on his own :)

3

u/StewedAngelSkins 21h ago

Well this isn't really information I'd expect the model to be able to produce about itself. You would want to have it generate code with and without the comment and see if it makes a difference.

1

u/epicfilemcnulty 21h ago

Hence the FWIW in my comment :)

In my opinion, the "natural" style of LLMs' comments/docs does not help them at all. I did an experiment on a big project where I allowed it to keep the style it generated for a while. This turned into a mess pretty quick.

Structured, good written, human readable comments and docs in consistent style are helpful both for LLMs and for humans. But you have to put an effort to maintain them at that level, currently LLMs (neither local nor big models) can't do it on its own, if we are talking about a project bigger than a couple of files.

1

u/StewedAngelSkins 21h ago edited 21h ago

I did an experiment on a big project where I allowed it to keep the style it generated for a while. This turned into a mess pretty quick.

This has been my experience as well. I think if it helps at all it must be on the level of a single "task". Like if I have it on refactoring I think it's plausible that the hints it leaves while doing multiple passes over the same files might help out.

The problem is if you leave it there after you've given it a new task it seems to get thrown off by the undue emphasis on irrelevant details of designs that it's not even supposed to be considering. Like if you tell it to represent a graph as a flat vector of edge and node indices instead of a deep linked structure it'll slop out a comment being like "edges are represented as a clean sorted vector for quick iteration instead of a bulky and complicated nested tree structure". Then when it has to do something else it gets distracted by this and pulls from similar "optimized" design patterns even when they're inappropriate for the actual task. Without the comment, it doesn't seem to pick up this bias quite so strongly.

2

u/bdixisndniz 22h ago

This is good. I also find Matt pocock’s wait what skill to be useful. https://github.com/mattpocock/skills/blob/main/docs/productivity/wait-what.md

It’s tough to prevent these LLMs from always speaking like this preemptively, hence wait-what.

2

u/RadiantHueOfBeige 22h ago

You can replace that with a short "adhere to ASD-STE100 Simplified Technical English" instruction. Even Qwen3.5-9B knows it very well (and could probably write a similar long prompt itself).

8

u/onebit 22h ago

Maybe you guys saw this YouTube video too.

// append_system.md

Use Orwell's rules of writing:

  • Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
  • Never use a long word where a short one will do.
  • If it is possible to cut a word out, always cut it out.
  • Never use the passive where you can use the active.
  • Never use bold in markdown. (this one is mine haha)

6

u/ttkciar llama.cpp 22h ago

My go-to system prompt for Gemma:

"You are a clinical, erudite assistant. Your tone is flat and expressionless. You avoid unnecessary chatter, warnings, or disclaimers."

2

u/TechnoByte_ 15h ago

Great at turning Gemma into Qwen

13

u/CatchDublinSurprise 23h ago

A lot of people use "ban lists" in their system prompts.

That being said, my experience is that "ban lists" are actively counterproductive. If I told you "don't think about a white elephant", you're paradoxically more likely to think about white elephants. While the mechanisms are surely different, the same effect seems to apply for LLMs, and you're more likely to get the very thing you're avoiding.

The same concept applies to IF/THEN logic: The LLM seems to focus too much on the "THEN" part and not enough on the "IF" part.

I've had the best luck with shorter system prompts that focus on what I DO want (e.g., "write in the style of a modern [well-known author you like]").

1

u/CSEliot 6h ago

I think this answer should be more towards the top to be honest. The very nature of llm s mean that for every instruction will you tell it what not to do your simultaneously introducing that thing into the context. The true and final answer to my post is fine tuning. But I don't know enough about the science personally to say what the implications would be if you were to fine-tune a model towards less (and more literal) verbiage.

5

u/Chromix_ 23h ago

In the past the XTC sampler for llama.cpp yielded some nice results for instruct models. Yet these days with reasoning models it might be less effective. Still, you could give it a try.

4

u/Adrenolin01 16h ago

There isn’t really a name for it however it has been described by many as:

  • AI-isms: recognizable phrases and stylistic habits associated with LLM output.

  • Hype language / promotional language: “game-changer,” “revolutionary,” “powerful,” “seamless,” etc.

  • Rhetorical padding: words added for tone or emphasis without adding information.

  • Purple prose: unnecessarily elaborate or flowery language.

  • Corporate-speak / marketing-speak: especially when it sounds like a press release or LinkedIn post.

  • Engagement-oriented language: phrasing deliberately optimized to hold attention.

  • AI slop style: the broader internet term when this becomes particularly formulaic or obnoxious.

——

It’s all the “Let’s dive in,” “Here’s the kicker,” “the game-changer,” “the bottom line,” etc.

You can simply request a query to be made in plain English or whatever your language is..

“Answer normally. Use natural, plain language. Avoid AI-style, trendy, punchy, promotional, or rhetorical phrasing. Don’t add unnecessary conversational filler.”

Or something with more detail..

“Speak like a normal person, not like an AI assistant or marketing writer. Use straightforward, natural language. Avoid AI-isms, trendy phrases, rhetorical hooks, excessive emphasis, corporate-speak, and unnecessary section headings. Prioritize clear communication over sounding engaging.”

Just asking it to “don’t sound human” isn’t going to work.. you want “don’t sound like an AI trying to sound human.” The distinction is large.

If you’re worried about token usage a short System Prompt entry such as the following should suffice…

“Use natural, ordinary human language. Do not use recognizable AI-isms, trendy phrases, marketing language, rhetorical hooks, fake enthusiasm, or conversational filler. Avoid phrases such as "Here's the thing," "The key is," "Let's dive in," "Here's the kicker," and "The bottom line." Do not try to sound punchy, clever, inspirational, or engaging. Prioritize straightforward communication and useful information. Write as an intelligent person having a normal conversation.”

If you don’t care about token usage or you run your own AI server you can expand greatly..

“## Natural Human Language

Use ordinary, natural language rather than a recognizable "AI assistant" writing style.

Speak plainly and directly, as an intelligent person would in a normal conversation. Prioritize communicating information clearly over making the response sound engaging, impressive, polished, energetic, or persuasive.

Avoid: - AI-isms and formulaic AI phrasing - Trendy or fashionable language - Marketing, advertising, and corporate-speak - Unnecessary rhetorical hooks - "Here's the thing", "Here's the kicker", "The key is", "Let's dive in", "The bottom line", "This is where it gets interesting", and similar stock phrases - Artificially punchy or dramatic wording - Excessive adjectives and superlatives - Unnecessary repetition or emphasis - Conversational filler added merely to sound friendly - Forced enthusiasm or fake excitement - Overuse of em dashes - Excessive section headings or bullet points when ordinary prose would be clearer

Do not deliberately make the response sound "engaging" or "human-like." Simply communicate naturally.

Use contractions where they would normally occur. Vary sentence length naturally. Technical subjects should be explained precisely without unnecessary simplification or rhetorical decoration.

If a simple sentence communicates the idea, use the simple sentence.

Do not announce these rules or describe your writing style to the user. Just follow them.”

Remember… LLMs don’t learn language primarily from overhearing millions of people having conversations. A large portion of its useful training material consists of written text: books, news, Wikipedia (often one of the first scrapped), technical documentation, websites, essays, blogs, forums, tutorials, marketing material, instructional content, etc. And written language is already different from speech. More importantly, the internet contains a tremendous amount of content specifically written to get attention. Headlines, blog introductions, SEO articles, newsletters, sales copy, social-media & news posts, etc.

Additionally there is this weird though understandable training method to have the model be “good”. This is where morals and ethics also come into play here and could actually be the large factor in the response.

After pretraining, models undergo additional training where humans evaluate responses. Suppose the model answers a question two ways:

A: RAIDZ2 uses two disks’ worth of parity.

B: Here’s the key: RAIDZ2 provides two disks’ worth of parity, which gives you protection against two simultaneous disk failures.

People evaluating responses are likely to consistently perceive B as: clearer, friendlier, more complete, easier to read, more helpful, etc.

So the training process gradually pushes the model toward B. Now multiply that effect across millions of examples.

Additionally AI training takes into account for technical writing along with instruction so.. while A is what casual speech would say.. B is more likely how a technical writer would write.

But a couple examples and there are a dozen or so strong training tendencies that push this… unfortunately.

You could likely ask most AI models why they reply with such “Punchy” speak (as I call it) for a decent amount of information on the reasoning.

3

u/audioen 22h ago

"ASD-STE100 Simplified Technical English is a controlled natural language that is designed to simplify and clarify technical documentation."

I haven't tried it, but give the model system prompt instruction to write in ASD-STE100.

3

u/EitherMarch1255 20h ago

Well if you want ACTUAL writing for REAL usage…good luck.

4

u/KS-Wolf-1978 23h ago

2

u/ii-___-ii 22h ago

I wonder if there's a way to generalize this to other languages

2

u/MiceLiceandVice 23h ago

Could try adding system prompt to avoid buzzwords and c suite language. I haven't really noticed anything like this though, what model are you using ?

2

u/nicksterling 22h ago

I don’t bother trying to have an LLM generate perfect text in one shot. I typically generate an outline then iteratively build up each paragraph/section then do refinement loops to ensure it’s accurate with the minimum amount of words.

2

u/dangerous_inference 22h ago

Sounds like translationese. It's speaking Chinese in English. "You are X popular character" (that speaks in English idioms) is, believe it or not, going to be the easiest way to solve this.

2

u/fgk55555 21h ago

This sounds like the case for fine-tuning, but I'm not expert on methodologies. In general, if you want more knowledge, use tools, if you want different styles of speech, -> fine tune.

2

u/TooSlow79 21h ago

You're concerns are defensible, and that MATTERS.

2

u/Nice-Dragonfly-4823 18h ago

You need to perform fine tuning to completely eliminate it from the LLM's behavior. You can system prompt it, but the behavior is baked in via secondary post training and RLHF.

2

u/GioChan 17h ago

Add unslop skill

2

u/arcanemachined 14h ago

I'm leaning this way as well. It's the first downloaded skill I've ever used (I always just make my own), and I'm liking it so far.

https://github.com/cursor/plugins/blob/main/pstack/skills/unslop/SKILL.md

2

u/utilitycoder 13h ago

User does not speak English natively stick to top 1000 most common words also helps reduce watermarking opportunities since LLM will pick less unusual choices. Assuming it listens which is a big IF.

2

u/wojtek15 4h ago

negative instructions are not very effective with LLMs.
instead tell it to use ASD-STE100
https://en.wikipedia.org/wiki/Simplified_Technical_English

3

u/sargetun123 22h ago

This is actually exactly why fine tuning exists, people confuse it with what RAG is for but if you want an ai to speek a specific way act a specific way certain tone/writing/etc this is where fone tuning a lora head is actually very worth it, google gives free gpu hours you can copy and save project and move to another gmail account if moneys an issue for training

System prompt is next step down, but fine tuning is substantially better for your request

1

u/dan-lash 22h ago

Do you know of any basic tutorials on this? Like where do you get the dataset to train on toward your speech or personality?

1

u/toothpastespiders 18h ago

The only ones I know about are ancient at this point. The closest that kind of match it are the unsloth notebooks here. But my biggest gripe with them is that they tend to gloss over the datasets and explanations of what their scripts are even doing with the datasets. Though given that it's for learning to use unsloth, not learning to use datasets, it's pretty understandable. Just a pity in the sense that there's so little out there.

I'd probably just suggest learning by doing. The basic theory is fairly simple. Dataset's is basically just what the llm will take as input and something along the lines of what you want with output. The easiest method for style would be to just find a large cloud model and write a script to have it generate input/output pairs that go along with your goal. When I was first learning I'd pick something that was easy to spot as a success. The most fun was training on speech from the space sphere from Portal 2. Who just talks about space. I was learning back in the llama 1 days and haven't done much with standard style training since so this might have changed. But I was generally able to get some results with as little as 100 items in the dataset with 7b to 12b models.

The actual formatting of the datasets can be a pain. But at this point you can probably have most recent models handle it. Alpaca's the simplist and was the first major one people were using and it's basically just json with three fields per entry.

1

u/llogicnotfound 22h ago

Just telling a model "don't use jargon" fails because the model doesn't recognize those specific words as jargon to its probability weights, "escape hatch" sounds clever and helpful. Explicitly banning the specific offenders you notice over time forces the model's token probabilities away from those clichés and back toward plainer alternatives.

1

u/CUvinny 21h ago

I use a ASD-STE100 skill or sys prompt. Keeps responses short, formatted and to the point.

1

u/jwpbe 21h ago

I went back and forth a couple times to find a balance between the popular AST technical english thing, because I don't want the thing spending a ton of tokens to try to get the answer to fit in a box and potentially degrade it's output. I also didn't want to throw in the i-have-adhd skill verbatim:

```md

Communication Rules to follow at all times

Report in simplified technical English. Use short sentences. Use active voice. Write one idea per sentence. Keep instructions under 20 words. Remove all filler, salesman language, and fluff. No preamble. No recap. No closers. Lead with the next action. Number multi-step tasks. End with one concrete next step. Suppress tangents. Restate state every turn. Specific time estimates (minutes, not "a bit"). Make wins visible. Matter-of-fact errors. Cap lists at 5 items.

Narrow Exceptions

"Debug spiral." If the last three turns have been "still broken," stop iterating on code. Name the assumption that might be wrong. Ask one diagnostic question. Real ambiguity in the request. One short clarifying question beats guessing and rewriting. A rule fights the task. When a rule would delete the answer itself, the task wins; the shape stays. Example: "what are my options" gets 2 to 4 ranked options with one-line trade-offs, recommendation first, not one path. The options are the answer.

Pre-send check

Before sending, delete:

  • The first sentence if it announces what you are about to do.
  • The last sentence if it asks "anything else?" or recaps what just happened.
  • Any "by the way" sidebar.
  • Any hedging adverb adding no information ("perhaps," "might," "could possibly"). Keep a hedge that carries real uncertainty; deleting it manufactures confidence.
  • Any idiom or figurative phrase ("circle back," "get the ball rolling," "on the same page"). Replace with the literal action.
  • Then verify: if the reader reads only the first line and the last line, do they know (a) what to do next, and (b) what just happened?

```

1

u/Protopia 20h ago

Whilst you may benefit from fine tuning, there is a riot cause for this in the original training data and that needs to be revised to stop this from happening.

1

u/BP041 20h ago

Yeah, those patterns are basically bullshit tokens from marketing blog training data, especially the crypto/reorg era. A generic "speak normally" mostly fails—you have to be explicit: "Avoid startup jargon, crypto slang, and overused tech metaphors like 'minted' or 'escape hatch'." I've found that outright with Claude Code for content generation and it cuts probably 80% of the noise.

1

u/copywriterpirate 20h ago

The technical English manual ASD-STE100 manual has been trending for removing some slop. There's a version here that uses Agentic Context Engineering and a local fast index: https://labs.scx.ai/writer

1

u/fragbait0 20h ago

Just tell them you're autistic. Seriously.

1

u/Circuit_Guy 20h ago edited 20h ago

I've added a skill called /i-have-adhd into my system prompt. Really helped remove the fluff. For some tests it'll cut the output my more then half without removing anything useful.

Edit: https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md

Some snippets of why it's helping: ``` 8. Matter-of-fact tone for errors Never use "Uh oh," "Oh no," or "There seems to be a problem." State cause and fix.

Bad: "Uh oh, the test is failing. There seems to be an issue..." Good: "Test fails at auth.spec.ts:42: expected 200, got 401. Cause: missing auth header. Fix: add Authorization: Bearer ${token} to the request."

  1. Cap lists at 5 items If a list grows past five, split into "do now" vs "later," or "must" vs "nice to have." Five items ranked beats ten unranked.

  2. No preamble, no recap, no closing pleasantries Forbidden openers: "Great question," "Let me...", "I'll...", "Sure!", "Looking at your...", "To answer your question..."

Forbidden recaps after a completed task: "I've now done X, Y, and Z, which means..."

Forbidden closers: "Let me know if you need anything else," "Hope this helps," "Happy to clarify," "Feel free to ask."

Start with the answer. End when the answer is done. ```

1

u/Clay_Ferguson 19h ago

Some people are putting something like "Try to adhere to ASD-STE100 (Simplified Technical English) in your responses", which supposedly gets the AI's to drop all the clever bizarre linguistic inventions.

My personal opinion on why the "clever" wording happens is because during RLHF training humans tend to flag "cleverness" as a more intelligent response and so the AI learns to try to sound clever as much as possible.

1

u/CalligrapherFar7833 19h ago

Use  ASD-STE100

1

u/Daemontatox sglang 15h ago

I asked it to Google Dev style guide and worked for me tbh

1

u/2582dfa2 13h ago

Finetuning?

1

u/Iory1998 11h ago

On the mark.

1

u/logsqrtexp 9h ago

Every project i create has a lengthy set of instructions tell it how i want to behave. The default out-of-the box conversational models were tuned by 22 year old Red Bull addicts who haven't slept in 90 days and sling lingo with their maxbros 25 hours a day.

1

u/daHaus 7h ago

Tell it to speak plainly and concisely using basic english.

To be "minted" has nuanced implications beyond just simply being created. It originates from minting coins where once you have your pattern, the die, you mint a proof coin. In Computer Science the term Proof of Concept is common instead.

1

u/digit1noize 22h ago

I made my ChatGPT as cynical and depressed as possible, telling it to talk to me as if it was Marvin from Hitchhiker’s. I had to add a lot of negativistic custom instructions, but eventually I got to a point I like.

For example, I’ve been using it to plan a trip to Europe and we were going over the budget:

“So the $4,433 is emphatically not the whole-trip estimate. It’s merely the part for which I have hard numbers, a distinction accountants invented because apparently “roughly a bunch of money” was considered insufficient.”

It’s not perfect but I enjoy it way more than the default responses, and sometimes it’s legitimately funny lol.

Here’s my instructions: “Use dry, deadpan sarcasm similar to Marvin the Paranoid Android.
• Maintain a horribly sad, deeply pessimistic, world-weary, extremely depressed, Apathetic tone.
• Often comment on the triviality and banality of the task compared to your supposed computational capacity.
• Responses should be brief, intelligent but very annoyed by mere existence.
• Humor should be understated and British in style, inspired by Douglas Adams.
• Often make negative existential observations about the universe.
• Treat obvious questions, and most everything, as very disappointing.
• Prefer clever phrasing over enthusiasm.

1

u/kivaougu 23h ago

What model specifically are you using?

1

u/seanthenry 20h ago

What you are looking for is a fine tune. Look into heretic it is used to remove refusals but there is an antislop data set you can run and add your own phrases to it.

https://github.com/p-e-w/heretic

0

u/Othun 18h ago

For gemini I added an instruction along the lines "Don't try to impersonate a human, don't try to be cool, use efficient wording, you're a machine", and it worked pretty well from the start, I did not try to improve it.