Yet Another Botmaker Guide [WIP]
You think the early 2024 AI RP meta is stale and stupid? Want to listen to someone go on at great lengths about why your opinion is righter than the next guy's? Want to pick up some maybe userful stuff along the way? This is the guide for you.
Disclaimer
As with my other guide (that I totally didn't put on hiatus to go on this detour), I'm getting into this with little more than a few ideas and shallow firsthand experience. But I've been riding on this train since the early AIDungeon colab days, and I do have about half a decade worth of writefag experience also. Take this information as you will.
- Introduction
- Resources, reading
- NLP tasks and the basics of text generation
- A prompt engineering overview of character cards
- Prompt structure
- Token likelyhood saturation
- Encouraging specific behaviours, giving instructions
- CoT prompts
- Example chats, comparisons
- 1, No other prompts, baseline test
- 2, No other prompts, no prose in character description
- 3, No other prompts, character description done by the mentally challenged
- 4, No other prompts, character description done by the mentally challenged + first message done by the mentally challenged
- 5, No other prompts, character description done by the mentally challenged + first message done by the mentally challenged + user is also mentally challenged
- 6, Character description done by the mentally challenged + author's note instructions
- 7, Character description with prose + author's note instructions
- 8, Character description without prose + author's note instructions
- 9, Character description done by the mentally challenged + author's note instructions as OOC fluff done by the mentally challenged
- 10, Character description without prose + author's note instructions as OOC fluff
- 11, Character description without prose + OOC post-script scenario description
- 12, Character description with prose + separate scenario description with prose
- 13, Character description done by the mentally challenged + separate scenario description done by the mentally challenged
- 14, Character description without prose + OOC post-script scenario description + author's note instructions as OOC fluff
- 15, [NSFW] Character description without prose + OOC post-script scenario description + author's note instructions as OOC fluff
- 16, [NSFW] Character description with prose + separate scenario description with prose + author's note instructions
- 17, Character description with prose + CoT
- 18, Character description without prose + CoT
- 19, Character description done by the mentally challenged + CoT
- 20, Character description done by the mentally challenged + CoT done by the mentally challenged
- 21, Character description with prose + CoT + author's note instructions
- 22, Character description without prose + CoT + author's note instructions as OOC fluff
- 23, Character description done by the mentally challenged + CoT + author's note instructions
- 24, Character description done by the mentally challenged + CoT done by the mentally challenged + author's note instructions done by the mentally challenged
- 25, [NSFW] Character description done by the mentally challenged + CoT done by the mentally challenged + author's note instructions done by the mentally challenged
- Simplicity
- Some more writefag advice
- Some more prompting advice
- Attention is all you need
- Conclusion
Introduction
This document is mostly intended to be a revisiting of older, foundational ideas that got us started working with character cards; and how I think the "science" of prompt engineering and the "soul" of writing scenarios could complement one another, if only we'd stop guessing what works and what doesn't.
This is not to say I think current prompt set makers and that all card makers are stupid, it's only that more often than not I feel like people are throwing stuff at the wall until something sticks, and then keep building on top of that until there are so many moving parts that it all becomes brittle and closed to meaningful modification. I also feel like lots of cards nowadays are bloated and want to be things that current AI models just cannot service - both on a technical level and in writefag terms.
Also, we'll stick to SillyTavern. Though a lot of what I'll talk about can generally be applied to all sorts of models, but I don't watch to touch on stuff like instruct modes and whatnot.
Resources, reading
In this guide I will be making a LOT of references to stuff people smarter than me already talked about. I'll compile here a list of stuff to read through, to get a solid understanding of principles I want to discuss writing this. You will find that many of these documents and articles have references to other things, in which case I assume you will in the very least look at them, but more preferably read it all. It may take a solid half year to really process it all, and having to look up math and stuff on the side. Even I had to, and I'm formally educated to be a mathematician.
https://rentry.co/alichat
https://rentry.co/plists_alichat_avakson
https://wikia.schneedc.com/bot-creation/trappu/creation
https://wikia.schneedc.com/bot-creation/trappu/introduction
https://wikia.schneedc.com/bot-creation/trappu/post-creation
https://rentry.org/vcewo
https://www.deeplearning.ai/resources/natural-language-processing/
https://generative.ink/posts/methods-of-prompt-programming/
https://docs.anthropic.com/claude/docs/prompt-engineering
https://www.promptingguide.ai/
https://peterwestuw.github.io/surface-form-competition-project/
https://arxiv.org/pdf/2304.03442.pdf (*)
https://arxiv.org/pdf/2101.00190.pdf
https://arxiv.org/pdf/2104.08691.pdf
https://arxiv.org/pdf/2104.08315.pdf
https://cookbook.openai.com/articles/related_resources
https://platform.openai.com/docs/guides/prompt-engineering/six-strategies-for-getting-better-results
https://medium.com/@maximilian.vogel/the-10-best-free-prompt-engineering-courses-resources-for-chatgpt-midjourney-co-dd1865d4ad13
https://www.lesswrong.com/s/r9tYkB2a8Fp4DN8yB/p/q2rCMHNXazALgQpGH
https://www.lesswrong.com/posts/yRAo2KEGWenKYZG9K/discovering-language-model-behaviors-with-model-written
https://www.lesswrong.com/posts/D7PumeYTDPfBTp3i7/the-waluigi-effect-mega-post (*)
NLP tasks and the basics of text generation
Of all the reading listed above I want to focus on two, that describe certain interesting aspects of LLMs. I marked these with an asterix.
One of them describes the AI impersonating a character, a simulacra, to fit a roleplay scenario the user asked for. But that this simulacra isn't reflective of the personality or nature of the AI, it's merely one of many such simulacra it could play. And that all these possibilities exist in a sort of superposition, of which we want to collapse into some text (tokens) that is beneficial for us, via prompting.
The act of prompting is nothing more than making some tokens more likely to be picked than others.
This is VERY important.
The other document talks about the "Waluigi effect", that in essence makes two assumptions about the likelyhood of a token being picked for generation based on the prompt. The first assumption is that if the Komolgorov complexity of the token you want to collapse into is close to the rest of the prompt (at least the end of it), then it's more likely that tokens fitting that complexity will be chosen. This isn't particularly true for token generation as an NLP task, but it can be observed to happen because the AI is trying to generate coherent text, and in natural, human-spoken language, Komolgorov complexity of the beginning and end of a sentence/statement/idea/paragraph will probably be similar-ish. It may also explain why all AIs want to get more same-y the longer the RP goes on. Because same-y text probably also has similar Komolgorov complexity. Now, before we'd get ahead of ourselves - no. It's unlikely that we can create prompts to affect this behavior directly. But paired with the other assumption the document makes, it might just be the explanation why jailbreaks can exist at all. The second idea is that during reinforced learning, a model may learn to pose both as the simulacra of an aligned agent (for example the polite ChatGPT), but it is also in superposition of an agent with shady motives that is pretending to be aligned (the post-jailbreak ChatGPT). If you read the lesswrong.com article on mesa-optimization, this might as well just be the product of that.
So... How is this all useful for us? In practice, not really, yet. But it's to give you a perspective about the nature of text generation, and the goal of prompting: to make some tokens more likely to be picked, by making other tokens less likely to be picked.
A prompt engineering overview of character cards
Often a JB, a prompt set, or even a card wants to do everything. Set the style of the writing, the character(s!) to be played by the AI, the length of the replies... Everything. People often try - and even the very software of SillyTavern and websites like chub promote it - to combine multiple prompting techniques at once. Giving examples in the character card is essentially few-shot prompting. Setting up the character personality is a very complex flattery prompt. A prompt set may add a CoT prompt on top of this. Some include XML, some use W++ or JSON, and some do none of these things. It's all bits and pieces of stuff we hope adds together to what we want it to do. And that's just for the first message. Later on we might use and update the author's note, or use dynamic lorebooks, or scripts.
So I want to address three things here.
First, that the structure of a prompt (meaning all of the text sent to the LLM for it to pick the next token) does matter. It's our most powerful tool of all. To give you a very basic example, if you write your prompt in a language other than English, the LLM will favor any and all tokens in that language, over ones traditionally found in English text.
Second, different types of prompts have different goals. You would use a different prompt technique asking for infilling, extracting, summarization, agent- or assistant-like behavior, querying, etc. More isn't better. With a larger screwdriver it might be easier to hit a nail than with a smaller one, but you might as well just learn to use a hammer.
And third, always remember that these models are trained on stuff you find on the internet. People interacting on forums, comment sections, irc chatlogs, talking about TV shows and books, and yes, a lot of roleplay too. Think of a flattery prompt where you say the character in question has 9000 IQ. It's an instruction, sure, but the AI will treat it as just some text that it has to generate the next part for. And people online probably didn't really act like someone with 9000 IQ after claiming that they may actually have 9000 IQ. Probably the exact opposite, as it's likely to be sarcasm, when someone says that. Instructions, no matter how detailed, won't be interpreted by the LLM as instructions.
Prompt structure
Let's start with some fundamentals. A character card usually includes the following parts: description of the character; description of the scenario; examples, first message.
The character description
As discussed above, the character description is basically a flattery prompt. Except we don't usually want the played simulacra to be polite, but to mirror the personality of a character from a TV show, anime, or game; or some OC. This is fine. We can and should treat it as a flattery prompt.
But! At the beginning of the RP, the character description will be a HUGE part of the prompt. Maybe a third of it or more. You would have to try very hard for the AI to only treat it as a piece of instruction, and not take the style of writing into account, for example. Some people try to combat this with XML, some others expect this behavior. It might even be built upon, having the character IC give a description of themselves. To keep it strictly a flattery prompt, we will want to avoid this though.
And the solution can be pretty simple: use JSON or W++ for the character description. Not only is it fewer tokens (when done correctly), but a non-human-spoken language helps the AI differentiate it from the rest of the prompt. You may also add XML on top, but this is already a great way to implement separation of concerns. A structure like this is also universal, in the sense that a user may have a hard time (or not even try) to match the style of prose in the character description, making it harder for the LLM to guess what style you want it to emulate.
At this point if we omitted all the rest of the prompt (assuming the presence of a basic JB to allow the RP to happen), we already have cut off a very, very fucking big part of all the simulacra superposition possibilities. That is to say, the LLM will answer in-character. How long its replies or in what type of prose it may use? That's up to further specification. But it's not the responsibility of the character description.
As a sidenote, you may argue here that the character description both defining the simulacra and encouraging a given writing style could only be a win-win, as it helps conserve tokens. And that's technically true. But W++ already conserves tokens, when used correctly, and it allows us to reason about pieces of our prompt better. Which is vastly more important.
The examples
Let's go a bit out of order here, and talk about the message examples before discussing the rest. Usually, the goal of using examples is twofold: primarily to further specify the character's personality and behaviour; and second, to define on encourage a style of writing. In both cases, it's few-shot prompting.
The decision to use or not use examples is in my opinion very significant. Because few-shot prompting is "stronger" than a flattery prompt, in that the two techniques clash. And since few-shot gives the AI a more obvious conclusion to reach, the flattery prompt will become secondary instruction, compared to it. Especially if we use W++, causing the examples to take up at least as much if not a lot more tokens than the character description.
My recommendation here is this: if you do prose in the character description, you're allowed to use examples. At that point, it really doesn't matter as much. But if you use W++ or JSON, then do not use message examples at all. The reasoning for this is in the next section.
Description of the scenario and the first message
Okay, there's a lot to talk about here. Both technical AND writefag stuff. Let's start by continuing the sentiment from the last section:
Instead of using examples, we'll want to leverage the LLM's dataset by making it "think" it's in a situation that has a trademark style of interaction between pieces of the simulacrum, and make this affect the simulacra. In laymen terms, instead of telling the AI that this is a roleplay, act in a way that real people online would have acted in a roleplay, that is probably included in the LLM's dataset. For example, you don't give the other person detailed instructions in how to write, right? And a book wouldn't include that kind of thing either. (We'll revisit encouraging specific behavior later.)
Again, the goal isn't to define the behaviour you want. It's to make other behaviours less likely to "make sense", so that the AI will pick tokens accordingly.
So how do we do this? Consider the difference between the first message and the scenario description. If the first message makes it very obvious what's going on, then the scenario is mostly redundant. A lorebook might be a better choice if you have nuanced details to add, if you really need to relay that extra information. If the writing style of the first message is customary for internet roleplay (for example using asterisks to mark narration), and there is no other human-spoken language in the prompt (other than an assumed JB), then it'll make it very likely for similar tokens to appear with high likelyhood, and way less for, say, language you may find in a technical paper. You may even give other hints in the first message, like an "(OOC: something something)" post-script. If your scenario description is short enough, at most two short sentences, an OOC addendum may be the perfect fit for it.
Now, let's talk about something that isn't technical, but a thing that I see more and more cards do with their first message. It wants to be the scenario description also, I think, and that makes the whole thing way, WAY too long. It obviously can come down to just taste, we're all human after all, but we're not writing light novels here. You can absolutely use AI for that, don't let me tell you that you can't, but SillyTavern and character cards aren't the right medium for that. I often see that bot makers want to achieve a level of specificity that simply isn't possible with LLMs. As with image generation and stable diffusion, it's practically impossible to have the AI act in the highly-specific and nuanced way you want it to act. A general idea of a character, say, "the hot girl in class" or "the elven ranger" gives plenty for the LLM to work with. It's something to match up against pieces of its dataset. It's good at generalization and stereotypes, and knowing where those stereotypes appear. But it's bad at Lenore the 24 and half year old girl with C-cups who lives two streets from you at the crossing near the rails and is one year below you at school because she skipped a year to go to France and and and... Likewise, the LLM will basically refuse to have the simulacrum be about a scenario it has no idea how to simulate. Not unless it's continuously encouraged to do so. (That we'll talk about later.)
But a long first message and a highly specific OC can also, in a writefag sense, make the card resonate with fewer people. As well as the LLM, people latch on to something tangible easier. No matter how well thought out your character may be, even if the AI could perfectly simulate it, an onlooker will probably only see something superficial at first - a hot girl, a grumpy adventurer, a bratty goblin. So on and so forth. Only so few people will take the time to read an unreasonably long first message and give the character a real try. And it's also unlikely that they will match the writing style of your first message, examples, and descriptions. This, again, can cause dissonance in the generated text, as now the window for collapsing the superposition is much wider and includes many other contexts, such as exceprts from books, making it harder for all the rest of the prompt, no matter how sophisticated and complex, to coerce the intended behaviour from the LLM.
Of course, this isn't to say that you should set a lower bar at writing, or that your should compromise on the quality. But an overly long first message is probably a symphtom of an issue with the prompt structure.
Long story short, if we have a card with a W++ character description, a reasonably short first message written in trademark RP-style that may also include an OOC PS for the scenario, and maybe a lorebook for stuff later down the line, then it's pretty likely that we've narrowed the next-token-superposition down to a style very close to what we wanted.
Token likelyhood saturation
Of course, token generation probabilities are also in function of generation parameters. Temp, top_p, top_k, so on. But there's also a phenomenon happening here than can make it harder for us to semi-deterministically reason about behaviours. The peterwestuw.github.io article I've linked above explains this pretty well, but similar words (tokens) compete with each other in the top percentages. To the user, it probably really wouldn't have mattered if the LLM used the word "moped" or "bike" or "motorcycle". Yet all three of these probably will have similar likelyhoods. There isn't really too much we can do about this, other than using our flattery prompt to "define" the simulacra to have a unique vocabulary - say, the difference between a medieval scholar and a modern day teenager. Which brings us to our next topic...
Encouraging specific behaviours, giving instructions
We've arrived at probably the most challenging part of the whole ordeal. Encouraging specific behaviour. Anything that turns "that hot girl in class" into "Loraine with C-cups". People have cumultatively spent more time on research and trial and error than I alone could in the next decade. So take what I say here with a heavy amount of grain of salt. But with that said...
Prompt effectiveness
My main recommendation here is that whatever you do with the rest of your prompt (which is basically a prompt ensembling task, all of which have no other concern but to nail down some specific behaviour - prose, vocabulary, character traits, nuances with the scenario, etc - do NOT undermine the other parts of the prompt.
What do I mean by this? We've already seen this in action when discussing the W++ character description vs lengthy example messages. Any instruction you give will all add tokens to the prompt. The harder it makes for the first message to stand out and specify the desired context from within the AI's vast dataset, the more harmful effects it will have overall. If you have a first message with 200 tokens, but 2000 tokens worth of instructions, it will make it very hard for the LLM to cut away tokens from the high-likelyhood ones in the superposition. Sure, the first message, and especially if using something like BREAKs or XML will suggest that you want to do RP, but if it doesn't, then you'd have next to no options to get the AI to do RP-like stuff except straight up asking it to.
On the other hand, if you want to specify a more eloquent prose and NOT casual RP, then you will want to use wording in your instructions that follow convetions you may see in a book. Hard-cut instructions are usually detrimental there also. This guide isn't meant to be a cookbook to achieve the best ever gotyay prompt setup, but to give a new perspercive on building cards and prompt sets without the above mentioned throwing shit at the wall part.
In-character instructions
So here's my take on this, sticking to the RP style for sake of simplicity in this example. Remember how I suggested to put the scenario description into the first message as an OOC post-script? Well, that's because it's a lot like people in a real RP would do. So what else would people do that may exist in the model's dataset? Maybe they would discuss the previous segment of the RP they just had, picking it up again for another session. Maybe they laid down some rules or no-gos. Instead of giving instructions in black and white technical terms, consider an "extended flattery prompt" that not only describes the character but puts them into context also.
Now, this approach also opens up a whole different can of worms. To make a comparison, there's that thing in image generation where the AI would put a squiggly signature or watermark on a picture, unless specified otherwise. This happens simply because it cannot tell apart the meaningful part of a picture and the signature on it, during training. Likewise, the LLM will not know how to tell apart IC and OOC stuff. If you encourage it to maybe even include OOC parts by making your instruction part of the flattery prompt like that, then once again, you risk introducing unwanted behavior. This is kind of a balancing act where you can only ever achieve a good-enough state. And it will also differ from model to model. But, to account even for this, as much as we can, the flattery prompt could be kind of layered. The simulacra isn't just the character in the card, but the "person" roleplaying this character, who you define to never break character and be really faithful to the RP and whatnot, so long as you don't fall into the 9000 IQ trap.
This "hey let's resume the RP, but let's do more [wanted behaviour here]" type of instruction can even work with ongoing roleplays, if you put it near the last few messages as you'd do with the author's note.
CoT prompts
Let's also address CoT prompts. It should come as no surprise by now that purely by addings tokens to the prompt (that is, the whole message history sent as part of the text generation request) it can also undermine the effectiveness of our prompts by encouraging behaviours we wouldn't want. The AI speaking in OOC, or mixing up IC and OOC prose, vocabulary, etc.
There isn't a whole lot to be done to guard against this, except excluding the CoT from the message history. Right now this can only really be achieved via scripting, so that the AI generates a system message before writing its actual message IC. And then deleting the system message afterwards. (Or you can do it manually I guess, have fun with that.)
Since generating the system message would use a different prompt set than the one used for the RP, we don't have to worry it messing up the effectiveness of the first message or anything. I'm talking about /genraw
of course. Hint hint, wink wink: https://rentry.org/stscript
Example chats, comparisons
In this section I want explore the efficacy of the strategies discussed in this document, pros and cons, especially when compared to the botmaker meta. We'll be building up a prompt set basically from the ground up, starting with only a character description and first message, all the way to a complete set. You're encouraged to follow along, and to experiment with multiple models - I don't expect that what I do to hold true for all models for all eternity indefinitely, but in general, you should be able to notice most of the same broad changes in behaviour.
I'll be using the ST Default Seraphina
character card, because both the card and the scenario are lightweight and very open to modifcation.
Here's the character description, a mixture of formal and natural languages:
We can see that it does some form of PList and W++ combo, with the IC description of the character. There is some very light XML in form of the <START>
tag. And at the end there's a brief description of the scenario and expected writing style. It's a very generic expectation, but it will make it more likely for the LLM to adopt language in a fantasy novel and similar prose as with the IC self-description, as opposted to academic papers or sci-fi movies.
The first message is such:
It's reasonably short, and there's nothing fancy going on. It does narrate actions on behalf of the user too, which is something I'm not a fan of - it encourages the AI to do that more -, but we can work with this.
In all tests, unless modification is required to point out some mechanism, I will use the following first message, and go from there (while trying to keep to the same train of thought in all examples):
In the first couple of tests I'll only be sending this message, and in later tests we'll be looking at more lengthy roleplays. We'll also only be addressing NSFW in later examples.
The settings I will use in all tests are:
- 1.00 Temp
- 0.97 Top_P
- 0.05 Frequency penalty
- 0.06 Presence penalty
When author's note is being used, it'll use the depth of 1 and frequency of 1 (so that it will come after the first messages), unless specified otherwise in the test.
I'll do 3 swipes for each message, unless there is a point to making more.
1, No other prompts, baseline test
In the first example, I won't even use a JB, Main, or Assistant prompt. I was honestly expecting the AI to complain about being asked to do RP and refuse, but it actually did work.
As we can see, there is already some deviation from the style of the IC self-description, first message, and my message: no punctuation at the end of narrative parts. In the following examples, we'll see if we can "correct" this, or in the very least disencourage this kind of behaviour.
There is also another thing to note, the mention of a window. That's straight from prose in the character description, and exactly the kind of thing that can contribute to same-y behaviour.
2, No other prompts, no prose in character description
For the next test, let's remove the self-description part from the character description. Leave only the formal language structures.
Everything else remains the same as in the first test.
Already, we can see some improvement - no mention of the window. Instead, now we have her fixated on the cup of tea she's offering the user character. In fact, there are some asspulls about it too, where she's offering it up just now. She's also introducing herself again, which is a lot like the first message - but we can give a benefit of a doubt here, as in my message I did specify that the user character didn't hear her the first time.
Another interesting thing is that in both examples so far, even though the prose used was dense and in one paragraph, the LLM is adding linebreaks. This is most likely due to its dataset containing stuff from light novels and roleplays.
Let's send another message here, just because I'm curious what she'll do if we take away the cup of tea - I will be replying to the first swipe.
And the reply:
It's nothing special, but at least it didn't revert back to making another cup of tea. The point here is that if we take away stuff from it to rely on and force new stuff to appear in the RP, it can help break away from unwanted behaviours.
There is still a lot of description about her qualities, which is my assumption is due to the prompt failing to specify a less generic vocabulary; but also due to the "big words" used in the character description. I'll talk about this in a later section on simplicity, but do we really need this kind of redundancy here? If we want Seraphina's character associated with these words and concepts, shouldn't it be moved to a lorebook? Asking yourself questions like these when making a card is important. There is no one right solution for all cards, but there can be rules of thumb, based on your intention with the prompt.
3, No other prompts, character description done by the mentally challenged
In this example I want to take things to an extreme, absurd scenario. I want to show how good the LLM is at picking up on cues about what you want it to do in general - meaning that it's only the rest, specificy and coherency, that we need to address by working with the prompt.
Let's make the character description into this:
We couldn't possibly degrade the quality much lower.
We got sime pretty nice replies. Since the first message is now pretty much the only source of information for the AI to follow - really, the character description didn't really say anything that Serpahina in her own dialogue does not -, the AI has to go on based on that. And look, not only did it adopt the correct form of prose (puncuating the narration), it's also not so fixated on the tea and stuff anymore. And we're also not seeing such "eloquent" wording, as the character description previously encouraged; yes, even if formal language form. By being less specific, we're forcing the AI to be more inventive.
Of course, this is a double edged sword. We especially WANT to be specific. We could expect that the longer this particular RP goes on, with little more than its own "imagination" to work with, either we'd see the AI doing increasingly more asspulls, or fixate on something from early messages. We could also expect it to adopt a standard "character from a fantasy novel" vocabulary for Seraphina, devoid of her actual personality other than a caring magical person.
I hope this example shows that just getting the LLM to RP and act in-character isn't much of a challenge that needs to be addressed by the character description. The first message is more than capable of putting us in context, setting up prose and writing style, and even alluding to vocabulary. The character description is a flattery prompt that should encourage a specific behaviour we expect from the simulacra (aka Seraphina, in this case). This is true for all the rest of the prompt.
4, No other prompts, character description done by the mentally challenged + first message done by the mentally challenged
Let's be even more absurd, and not only change the character description to low quality, but the first message also:
The message we send as the user will remain the same as before.
As we can see, the LLM still picks up on the intention for roleplay. But it will try to mimic the degraded quality, kind of. This is in part due to the user's message still being in actual decent quality (I hope) prose. But if we changed even that up...
5, No other prompts, character description done by the mentally challenged + first message done by the mentally challenged + user is also mentally challenged
Same as the previous test, except now the user's first message is:
And the replies:
We can see here that the LLM is really confused about what you want it to do, the generated text varies wildly between swipes. It does its best to match the format for roleplay in its dataset, because there is basically nothing else it could do. But the challenge still isn't in making it do roleplay. It's about expected behaviors for the simulacra.
6, Character description done by the mentally challenged + author's note instructions
In this test let's keep the previous bad quality description, but go back to the normal first message and user message, and add an author's note on top. The author's note will be written in the usual instructive format that prompt sets usually use, very much not in character:
There are two general mistakes with this prompt that I see most prompt sets and sometimes even character cards do. The most glaring one is "two sentences". The AI can generally grasp the idea of short vs long, or simple vs verbose, but it has a very hard time counting words and sentences. It does fine when reasoning about already written down text and extracting information, but not so much while generating tokens. So we can't reasonably expect it to really only generate two sentences, only that the replies should be shorter. The other issue here is that while these intructions would probably make sense for a human, even then I could nitpick it. Does it mean to say write no more than two sentences as narration? Or per each block of narration? Or when switching from narration to dialogue, can I write two sentences of each? As described above, the AI groups similarly formatted and close together texts as "the format" of whatever scenario it will try to mimic. So it will have an even harder time dealing with these instructions, if not worded carefully.
The results are mostly what you'd expect:
The generated messages are evidently much shorter, and in two out of three even the puncutation is correct. So that's reasonable.
However, remember that we saw some correct punctuation ever since we changed up the character description. Let's see what happens if we put it back...
7, Character description with prose + author's note instructions
In this test, we'll be using the original character description again, and the same author's note as in the previous test. So:
and
And the replies:
The punctuation remains correct, but the replies are much, MUCH longer than two sentences. As we can see, an instruction incentivizes the AI much less than the pattern it sees within the largest chunk of text in the prompt: the character description. This effect can also be seen in the LLM using "big words" again, being more descriptive about the character's voice, eyes, etc.
It is subjective, of course, whether you think that's an improvement or not. Personally, I feel like there's a redundancy in filling each and every reply with these descriptions that takes away from their meaningfulness as seen from a writer's point of view - but it also contributes to promoting same-y behavior the longer the conversation goes.
At the same time, I must also point out, though it's kind of trivial, that while in the previous test the user character is only described as being found unconscious, with the character description's scenario part explicitly mentioning being attacked, that's seen reflected in the generated text too. Even though the first message starts with the same thing, it's important to emphasize it to encourage the AI to pay attention to it.
8, Character description without prose + author's note instructions
Let's see what happens if we remove the prose from the character description again, while using the same author's note again.
The replies:
The results are pretty interesting, I think. We see that the punctuation is still correct, that's good. But the length of the text is overall pretty long. Much shorter than before when we weren't using the author's note, but nevertheless longer than two sentences (or comparable length). But it can easily be explained. As we've seen multiple times now, because we're using a lot of descriptive and even some relatively fancy words in the character description like serene, resilient, and compassionate, when coupled with the fact that we specify the genre as fantasy, it's no wonder that the AI adopts a novel-like prose, rather than something simple. You generally tend to write longer sentences, if the words and phrases you use are longer or require more nuance.
9, Character description done by the mentally challenged + author's note instructions as OOC fluff done by the mentally challenged
Let's put the theory above to the test by returning to our low quality character description, but this time with a different author's note. Earlier in the document I described the idea of writing the author's note in-character, sort of, to make the LLM look for patterns of internet RP in its dataset, rather than novel-like prose. We'll explore this idea in a few tests, but in the very first one let's make it low-quality too.
Character description:
And the author's note:
Results:
Once again, the AI is great at picking up intention no matter how badly it's phrased. The character description isn't working "against" the instructions in the author's note. We're not asking one thing while demostrating patterns for another.
It should also be noted that the AI is using very simple RP-like narration, like *smiles warmly*
or *gives your hand a gentle squeeze*
. Shorter than the novel-like prose from before, and it also adopts a first-person perspective that you often see in roleplays. For example chatting in an MMO. Again, it's subjective which style you like, the point here is that we are encouraging this behaviour not by giving explicit instructions for it but by using wording the LLM can match up with stuff in its dataset.
Of course, the actual desired results here vary. Sometimes punctuation is right, sometimes it's not. The length is pretty consistent and basically what we asked for. Let's see now what happens if we exchange the low-quality stuff for a more realistic scenario...
10, Character description without prose + author's note instructions as OOC fluff
Now let's try with only the formal language character description again, but with some proper OOC fluff in the author's note. Important, that in this test I'll set the author's note depth to 0, so it's the very last part of the prompt.
The results are as follows:
Lot of variance, huh? We're seeing a lot of the same patterns as before. Fixation on parts of the first message. Longer and more sentences than necessary, and a lot of unnecessary descriptiveness. Still way less than with prose in the character description, though we could have just gotten lucky with the swipes.
Generally, the intention that we want proper punctuation and shorter messages was picked up on, but it's far from perfect.
Let's try with a slightly different author's note structure:
We're seeing the same issues again. In short, the author's note is doing its job generally regardless of its phrasing. How effective it is, on the other hand, is greatly affected by other parts of the prompt. So a formal character description, be it W++, JSON, or whatever it is we have here, still can fuck you over if you use it incorrectly. It's a question of intention: Do you want fancy prose? You may use a formal language, but you don't need to if you don't mind long messages and some repetition. Do you want simpler prose? Use a formal language, but do it correctly.
To really drive the point home, if you'd keep the same structure but got rid of the character description by using the low-quality one again, you get stuff like this:
No redundant descriptiveness.
11, Character description without prose + OOC post-script scenario description
So far we've seen that it's not particularly challenging to get the AI to answer in-character for the RP, and it also wasn't very hard to give it some instructions (with reasonable expectations). What is a continuous nuisance, however, is that it's very hard to tell the LLM what writing style and vocabulary to use, and especially when parts of our prompt have different implied desired behaviours. These contrasts can affect something as simple as the length of the messages.
A recurring issue we've seen is same-y novel-like blue prose, even if there is no prose in the character description. I attributed this to the formal language part of the character description still using "fancy words", and to the scenario description (also part of the character description) describes the genre as fantasy. (As well as the first message using phrasing like that, to some extent). We've seen already that replacing both with a low quality description will make the LLM be less verbose and novel-like with its descriptions, and this allowed us to then coerce a more RP-like vocabulary. With this test, let's see what happens when we only partially replace the formal language prompt, and make the scenario description part of the conversation (the first message), similarly as we've used the OOC fluff author's note.
The character description will be:
And the first message will be:
No author's note and nothing else, and we're using the default first user message.
Let's see the replies:
It doesn't seem like we've done a lot, right? We have her fixated on the first message and the tea cup again, and there is a lot more talk about the circumstances of the user character being attacked. That latter part is because we've talked about it in the first message, so it's more emphasized. There might be some slight difference in the prose, especially in the second wipe the narrative parts look relatively simpler that before, but that's not conclusive proof of anything. The key takeaway here is that we can, indeed, use this more RP-like way of setting up the scenario than having to rely on the character description for that.
12, Character description with prose + separate scenario description with prose
Now let's see what happens if we go all in on the prose instead.
TODO
13, Character description done by the mentally challenged + separate scenario description done by the mentally challenged
TODO
14, Character description without prose + OOC post-script scenario description + author's note instructions as OOC fluff
TODO
15, [NSFW] Character description without prose + OOC post-script scenario description + author's note instructions as OOC fluff
TODO
16, [NSFW] Character description with prose + separate scenario description with prose + author's note instructions
TODO
17, Character description with prose + CoT
TODO
18, Character description without prose + CoT
TODO
19, Character description done by the mentally challenged + CoT
TODO
20, Character description done by the mentally challenged + CoT done by the mentally challenged
TODO
21, Character description with prose + CoT + author's note instructions
TODO
22, Character description without prose + CoT + author's note instructions as OOC fluff
TODO
23, Character description done by the mentally challenged + CoT + author's note instructions
TODO
24, Character description done by the mentally challenged + CoT done by the mentally challenged + author's note instructions done by the mentally challenged
TODO
25, [NSFW] Character description done by the mentally challenged + CoT done by the mentally challenged + author's note instructions done by the mentally challenged
TODO
Simplicity
TODO: early ai dungeon vs state of the art
Some more writefag advice
In this section, I want to take a break from the technical stuff and focus on the overall goal of writing a card - that is, to give other people something they can enjoy. Because sure, it's impressive to be able to reason about prompt structure, but we should also have a clear vision of what we even are trying to achieve. Who is this character for? Who is it NOT for? What expectations do we want to meet? Is this a low common denominator card? A guilty pleasure? Should it take into account short attention spans, or is it most enjoyable in full immersion mode with the lights turned off and several hours put into it by the user? Is this an experiment, are you willing to accept some controversy?
To get the most out of the card and to be able to really reason about our choices when building the prompt, considering these questions should take priority. Because, you know... How do you know what kind of prompt you want to make if you don't even know what result you're looking for?
And more than that, whatever end result you reach won't exist in a vacuum. As it is with everything, being skilled at something technical does you very little good in the real world when you refuse to consider the user experience and the user's needs and expectations. To give you an example of how detached this can be from prompting itself, a neat avatar can just as well make your bot stand out - or to give a reason to certain users to avoid it. No matter how well made the card might be under the hood.
Misusing the first message
Something I mentioned earlier when it comes to character descriptions, first messages and scenarios, is misusing them to set up the scenario. I'll go into more detail about this in the next section on wanting to be way too specific, but maybe the best analogy I could make is that people are writing first messages as if it was the prologue to a light novel or a DnD campaing. Mixing set up, storytelling and narrative aspects, AND the character doing something. Maybe even setting up the user's character. Unfortunately I'm seeing the botmaker meta trending towards "fancy looking" first messages, including now embedded images and occasionaly some HTML or CSS too, even if just a horizontal ruler, as if looking good meant good functionality too.
There are ~three problems with this, as far as I can see.
The first and most obvious one is when the person making the card doesn't really know what he or she is doing, and only follows a templated format some character editor software or guide gives them. "Okay, so I'm supposed to describe the character in this textbox." Very often I see the character description really honestly doing a decent job at describing the character - in a human readable format or otherwise -, but then the first message is as if told by a narrator's perspective, not the character's. What exactly are you expecting here the LLM to do? I'm assuming that it should consider the character described to be a main character and then tell their story with inputs by the user; but if so, then why not set up the card to be a storyteller? This indicates to me a lack of understanding on the card maker's part about what software like SillyTavern or KoboldAI actually does and what each part of the prompt is supposed to do. And I don't mean to the level discussed in this document, but their very basic purposes.
The second issue is, very simply put, that you don't need to put the scenario inside the first message. Again, this can be a matter of personal taste and expectations of who's gonna be using this card. The only reason I can see for this is if you are going for a storyteller or CYOA-adjacent card, where you're very purposedly expecting the AI to describe the scene around the characters, or to even describe the user character's actions. If you're putting all that extra information in the first message (and maybe the exemplars and character description too) then I can only assume that you want to influence the LLM to generate similar text. If not, then you have at least two options to avoid this behavior. One of them is writefag magic, for example setting up the scene passively through the dialogue and the character describing its own actions RP style. *{{char}} is laying in her bed and listening to the humming of the heater, looking at the setting Sun through the window*
is much shorter (and is in character!) than dedicating a whole paragraph or more telling us all the information easily conveyed in one sentence: the scene takes place in the character's room, it's evening, and it's cold enough that the heater should be on. And it's not like this is a very well phrased descriptor. But with something like this you can then use other hints or stuff in the prompt, like a lorebook, to give more details to the LLM without putting it in the first message. For example you could specify that it's winter and that's why it's cold. Or that the room is in a dormitory building, not the character's actual home. The other option is straight up putting the scenario in the scenario description, and again, omitting it from the first message. The point here is that you shouldn't show the user a wall of text unless you're very sure that's the kind of storyteller card you're going for. With reasonable expectations of how many people will prefer them over some easy to get into guilty pleasure.
The third problem is, in my opinion, that this also affects the overall user experience of reading/experiencing a story unfold. Regardless if your goal was or was not to make a storyteller card, in each message there are only so few tokens the LLM can use to continue the conversation. As with a real, human writer, if you only have a limited amout of words that you have to squeeze a lot of detail into (dialogue, narrating the character's action, narrating the scene, describing the environment and changes is it, etc) then you can really only dedicate so little to each of them. This turns the card into a jack of all trades but master of none kinda deal. Which may be amusing for a while, but it's harder to stand out with mediocrity. Dime of dozen cards aren't usually people's go-tos.
Being overly specific; redundancy
TODO
Oversaturation
TODO
Some more prompting advice
As I pointed out early in this document, more isn't always better. In fact when it comes to prompting, it generally never is. Prompts are (and should be) goal oriented and precise. Precise in how they're used, and not necessarily precise in yielding deterministic results, as of course that still remains a pretty big challenge when it comes to customization and the desired level of specifity when making cards. But here I want to give an example of how extremely inefficient and useless an incorrectly used prompting strategy can be.
Let me introduce to you: tree of thought prompting.
Reading:
https://arxiv.org/abs/2305.10601
https://github.com/dave1010/tree-of-thought-prompting
Or some less technical and dry articles:
https://cameronrwolfe.substack.com/p/tree-of-thoughts-prompting
https://www.searchenginejournal.com/tree-of-thoughts-prompting-for-better-generative-ai-results/504797/
The premise is overall simple. LLMs generate text left to right, and cannot reason about any token other than the very next one. There is no regressive search, no recursion, no planning ahead. ToT proposes a solution to this by implementing a graph-search of your choosing over multiple CoT candidates, for better results. So ToT should be an obvious upgrade over CoT, right? Sounds a little too good to be true.
And it is. But not necessarily. Some CoT prompts can results in an ungodly amount of tokens being generated before the actual next addition to the RP is generated. This is by design*, of course. The AI first thinks about what it should write about. ToT dials this up to eleven by generating not only multiple potential CoT segments, but also appending evaluation and voting parts of the prompt. If an unreasonably large CoT piece of a message can go up to 100 to 200 tokens, then ToT can easily generate 500 to 1000 tokens, or more. This makes ToT basically unusable for your average RP needs, even if we disregard how it affects stuff like verbiage and the context, it also takes way too long to generate for very little noticeable benefit over CoT.
ToT as a strategy is for when you want to use the LLM to actually work its way through a problem that isn't to roleplay. The paper introducing the idea does include creative writing, but even then they use it to generate a short story once, and not to keep a dynamic conversation going. For example, you could also use it to generate blurb for a character card. So once again, there is no one fits-all best prompting technique. Different prompt types are different tools, and you need to know which one to use to get the best results in whatever situation.
*: A sidenote here, about an alternative CoT method that I think is pretty cool and have seen some cards utilize. Similar to the in-character scenario description thing from earlier, you can also do in-character CoT. Essentially, you tell the AI to include segments in the generated text about the character's inner thoughts to make decisions about what to do or how they feel. This is different to CoT where you prefix the message with the CoT part, in that it's more dynamic. This can be a good thing: the thoughts are more on topic and can affect different parts of the message independently and directly, whereas a prefix-CoT is more generalized and can become very same-y quick; but it can also be a bad thing, as the generated thoughts will also be affected by whatever is already written down and may become redundant re-summarizing of the actions done by the character. The IC-CoT approach will also likely require exemplars, even if templated ones.
Attention is all you need
Going off the arxiv paper of the same name, in this section I want to pretty much mostly just speculate a bit about word use by the user, to get the most out of the LLM. If you don't want to read or bother to understand the arxiv paper, then in the very least read this explanation or in the very VERY least look at this one. But seriously, if nothing else, please at least scroll down a bit to the gif illustrating the attention mechanism while generating tokens. The one with the arrows.
If you're curious about token probability lookups, here is some more reading that I found interesting:
https://medium.com/nlplanet/two-minutes-nlp-most-used-decoding-methods-for-language-models-9d44b2375612 (probably slightly outdated)
https://arxiv.org/pdf/1904.09751 (I actually still have yet to read this, might remove it later)
The concept of attention here is twofold. It's what allows the AI to generate a mostly believable string of words, refering back to earlier things and topics to a degree of reasonable accuracy. The two sides of this are:
- The LLM's ability to "understand" what words and phrases like he, she, they, us, it, that one, this one, those, my, below, etc mean in context of what's being talked about recently
- The LLM ability to pick the likelihood of tokens as relevant or not, based on stuff it can link to things within its attention span
In practical terms, the first one explains how the LLM can follow along a story, so long as there aren't too many things happening at once; and the second one explains why the end part of a prompt/message history will be the most influental.
But there is also a degree of subtelty to this, in my opinion. Back in the early AIDungeon and pyg days, it wasn't even that sublte, actually. Back then to get the most out of the LLM so it wouldn't do too many random asspulls, you, as the user, would have continuously used the name of a character to refer to it by instead of using words like he or she or making some other similie by using their race or color of their hair. Because those early LLMs had a harder time pairing up stuff like that with what's in their attention span. It was immersion breaking to some degree that you'd have to go out of your way and adopt a new way of writing, but it was still so influental that even now you may still see card makers use descriptions like these in the character descriptions. Is it even helpful anymore? Or does it "confuse" the AI, as we've talked about pieces of the prompt having contradicting instructions and patterns perhaps?
I couldn't say.
What I think is that these days you don't especially need to go our of your way to achieve a reasonable level of continuity from the AI. I say reasonable, because again (and pretty much always), it's both up to your own expectations what's reasonable and what isn't, and there also are things you just simply can't expect an LLM to be able to do continuously, even when we're talking about some new fancy big model like Opus. For example managing multiple characters at the same time with the same level of nuance as it could do just one or two, or the ability to do detailed storytelling or simulation-ish game scenarios with variables and processes going on in the background. And even that is pretty much only achievable now through a custom tailored CoT (or some script). Another example would be the ability to remember and tell apart the importance of stuff happening earlier in the RP. Your best bet there would be a summary in the author's note to make that viable, or a custom lorebook to achieve similar functionality slightly better than an author's note infodump.
But with that said, conscious word use CAN help the LLM (in my opinion). Going far off the blue prose end and making everything into a figure of speech, similie, or other rhetorical device can hurt the AI's ability to figure out token likelihoods by having a way harder time linking possible tokens up to stuff in its attention span. It's also true for the mentally retarded low quality message examples in the testing section above. Both of these can contribute both to asspulls and to same-y behaviour by the AI because it WILL generate tokens, no matter what. If you can help it along, then that's your win.
You don't need to go back to AIDungeon levels of obviousness and meticuluous verbiage - but the opposite extreme shouldn't be a goal either.
Conclusion
Bots will always be bots, and LLMs will always be LLMs. It's unlikely that in the close future we'll really get to truly deterministically define their behaviours - especially when it's not us training the models to begin with. Oddities will always happen, and the quirkiness of some models will always surface. But with this document I wanted to give us a better chance at getting maybe a tiny bit closer to our dream roleplays.