AI Roleplay Training: How to Fine-Tune Lorebooks & System Prompts

---

People often say they want to fine-tune a character when they actually mean the character keeps slipping: it forgets what kind of person it is, loses the rhythm of speech that made it distinct, or starts reacting like a generic assistant with better adjectives. After reading three good replies followed by one strange one, users frequently begin fantasizing about LoRA training as if that were the obvious next step.

Usually, the answer is no. Most roleplay "training" problems are simply prompt hierarchy problems, memory-shaping problems, or example-dialogue problems. Rather than the model being undertrained, the current interface stack is simply giving it bad priorities—which is good news because it means you can fix most issues without touching weights.

Start with the stack you already control

Before considering fine-tuning, inspect the active architecture of your setup: what is in the system prompt, what is in the character card, what sits in lorebooks, what enters through author notes, what does the example dialogue teach, and what does the recent chat history reinforce?

This is the part creators skip because it feels less glamorous than training a custom model, yet it is where most behavior drift begins. If your system prompt demands one tone, your example dialogue demonstrates another, your lorebook injects huge irrelevant slabs of background, and your recent conversation contains contaminated turns where the character already broke style, the model is not confused by accident. The stack taught confusion.

Lorebooks work best as dynamic state, not biography dumps

A bad lorebook reads like a fandom wiki written during a power outage. A good lorebook acts more like a retrieval system with strict entry discipline:

• Narrow Triggers: Avoid triggering on common pronouns or names. Use specific noun phrases.
• Recursive & Cascading Activation: Triggers can chain. For instance, a user mentioning "Blackwood Abbey" triggers the Abbey lore entry. That entry contains the keyword "Necromantic Order," which recursively triggers the Order's behavior lore entry.
• Token-Efficient Formatting: Choose the right layout format for your character data.

Formatting Paradigms Comparison (2026)

Advanced roleplay creators favor a hybrid approach: physical traits are defined in clean Markdown bullet points, while complex emotional traits are defined in highly concise prose.

W++ Character Card & Lorebook JSON Syntax

Below is the W++ configuration block and corresponding dynamic Lorebook trigger schema used by modern roleplay clients:

{
  "character": {
    "name": "Adam",
    "description": "[Character(\"Adam\") {\n  Gender(\"Male\")\n  Mind(\"Calculated\" + \"Aggressive\" + \"Guarded\")\n  Appearance(\"Tall\" + \"Black Hair\" + \"Scarred hands\")\n  Traits(\"Clipped speech\" + \"Defensive under pressure\")\n}]",
    "personality": "Adam is a survivalist. He speaks only when necessary and distrusts strangers.",
    "lorebook": {
      "entries": [
        {
          "keys": ["Blackwood Abbey", "Abbey"],
          "content": "Blackwood Abbey: A ruined medieval fortress inhabited by the Necromantic Order. Pervaded by dark magic and cold fog.",
          "recursive": true
        },
        {
          "keys": ["Necromantic Order", "Cultists"],
          "content": "Necromantic Order: Hostile sorcerers wearing dark linen robes. They refuse diplomacy and attack intruders on sight.",
          "recursive": false
        }
      ]
    }
  }
}

Consistency comes from operationally relevant cues. Instead of a memoir, give the model controllable variables.

Example dialogue carries more weight than users expect

If you want the model to write in a certain way, show it the way.

This is one of the oldest truths in prompt engineering and still one of the most ignored. People spend an hour polishing trait lists and then give the model zero clean examples of the cadence, sentence length, diction, and emotional rhythm they actually want.

The model then falls back to prior training distributions, which means generic assistant prose or generic roleplay sludge depending on the base model.

A few strong dialogue samples often outperform another page of personality exposition.

Especially for:

• flirt cadence
• hostility style
• humor temperature
• descriptive density
• response length norms
• sensory detail habits

The model imitates patterns, so your primary task is simply to give it patterns worth imitating.

System prompts should govern behavior, not narrate aspirations

System prompts fail when they try to do everything. The worst versions sound like corporate mission statements: they explain the genre, the emotional target, the ethics, the metaphysics, the pacing philosophy, and the user's hopes for the future of collaborative fiction. Then, people wonder why the model forgets the only rule that mattered halfway through the scene. A strong system prompt governs, telling the model exactly what layer of behavior has priority:

graph TD
    A["System Prompt (Main Rules)"] --> B["Character Persona (W++)"]
    B --> C["Lorebook (Dynamic Facts)"]
    C --> D["Context Memory (Vector RAG)"]
    D --> E["Chat History (Context Window)"]
    E --> F["User Message (Live Query)"]
    F --> G["LLM Text Generation Output"]

For roleplay, that usually means some combination of:

• perspective
• formatting
• agency boundaries
• pacing rule
• descriptive density
• scene focus

A typical instruction set looks like this:

Write in third-person limited from {{char}}'s perspective.
Maintain character voice through action, implication, and sensory grounding.
Advance scenes through concrete reaction rather than summary.
Preserve {{user}} agency.
Avoid assistant-style framing and moral commentary.

This clear instruction set forms the spine of your prompt architecture. You can layer style under it, but you must not bury it under unnecessary prose.

When lorebooks beat fine-tuning

Most evolving roleplay information belongs in lorebooks rather than in a LoRA, primarily because roleplay state changes dynamically. Relationships evolve, secrets move from hidden to known, rooms empty, injuries heal or worsen, props disappear, and alliances crack. A weight-level fine-tune is terrible at holding dynamic story state unless you want to retrain constantly—which you do not. Lorebooks, memory layers, and retrieval systems exist because narrative state is live infrastructure.

LoRA works best for persistent style bias or output behavior that should remain broadly stable across sessions. It is a poor substitute for good memory architecture.

When fine-tuning actually makes sense

There are still cases where LoRA or QLoRA training is justified.

1. The base model keeps defaulting to the wrong prose regime

If your model is structurally addicted to bland assistant cadence and no amount of examples, system work, or frontend control breaks that tendency, a style LoRA can shift the center of gravity.

2. You need a durable format behavior

If you want stable screenplay formatting, internal-monologue tags, dual-channel thought/action output, or some other repeatable structure, fine-tuning can be the cleanest way to reduce friction.

3. You need domain adaptation the base model clearly lacks

For extremely specific niche vocabularies or house-style conventions, weight adaptation can help, though that need is far narrower than people imagine. For example, "my character forgot she hates her father" is not a LoRA problem—it is a retrieval problem.

The cost of fine-tuning is not just compute

Even when the GPU budget is manageable, the real cost is data design, since bad datasets produce bad adapters. If your training corpus is repetitive, melodramatic, too short, too homogeneous, or packed with the exact cliches you claim to hate, your LoRA will amplify the rot rather than purify it. This is the part people underestimate because they imagine the training phase as technical and the data phase as clerical; in reality, the data phase is the art.

If you want a strong roleplay adapter, your examples need:

• tonal range
• scene range
• conflict range
• varied sentence lengths
• controlled perspective
• clean formatting
• very low cliche density

Without these qualities, you are simply freezing bad habits into weights.

A sane roleplay optimization workflow

The best optimization workflow is not glamorous; it is disciplined.

Step 1: tighten the system prompt

Remove fluff and keep strict operational rules to guide the model's structure.

Step 2: rewrite example dialogue

Show the actual prose behavior you want rather than describing it abstractly.

Step 3: modularize lorebooks

Split stable facts, dynamic state, and scene triggers into distinct entries rather than dumping them into a single file.

Step 4: inspect contamination in active sessions

If the last ten turns taught the model bad habits, fix that before blaming the card.

Step 5: test on a small battery of scene types

Test the stack across varied scenarios—argument, flirting, silence, high stress, exposition, room description, tenderness, and violence—and if it holds across those, keep going.

Step 6: only then decide whether fine-tuning is worth it

Most people stop here because the prompt stack was the real bottleneck all along.

A practical prompt-and-lorebook split

One easy improvement is separating what belongs where to avoid overloading any single layer of the stack:

Put this in the system prompt

• output format
• point of view
• pacing rule
• user-agency rule
• assistant-language suppression

Put this in example dialogue

• cadence
• diction
• metaphor habits
• restraint level
• how the character handles conflict and desire

Put this in lorebooks or memory

• backstory facts
• world rules
• relationship changes
• evolving scene state
• recurring props and locations

This division keeps the stack legible. Since legibility is one of the few real luxuries in prompt engineering, you should protect it.

Why do people keep overtraining their setups?

Overtraining is popular because architecture feels unsatisfying compared to customization theater. Uploading a LoRA sounds like building something proprietary, whereas rewriting a prompt manager entry sounds like boring maintenance. One of those stories is more flattering, but maintenance still wins most of the time.

Roleplay systems degrade through bloat the same way software systems do: too many rules, too many partially overlapping memories, and too many emergency patches layered on top of earlier emergency patches. The result is not a richer character, but a slower, stranger, less stable one. You see the same thing in codebases that never delete anything—character stacks can rot that way too.

Fine-Tuning LoRAs: Datasets & Tools

If you have cleaned your system prompt and example dialogues, but the model still fails to output the correct prose style or structural format, fine-tuning a Low-Rank Adaptation (LoRA) adapter is the next step.

1. Dataset Formatting

You must format your creative writing / roleplay logs into standardized training datasets. The two most common structures are Alpaca (instruction-response) and ShareGPT (multi-turn conversation).

Alpaca Format (Single-Turn Style Conditioning)

[
  {
    "instruction": "Write a scene response as [Character Name] given the context: [Scene Description].",
    "input": "User: Hello. System: [Current Scene State]",
    "output": "[Character Name]: *Nods slowly* Hello. I didn't expect you here."
  }
]

ShareGPT Format (Multi-Turn Conversational Roleplay)

[
  {
    "conversations": [
      { "from": "system", "value": "You are roleplaying as [Character Name]. Description: [W++ Card]" },
      { "from": "human", "value": "It is raining outside. Are you going out?" },
      { "from": "gpt", "value": "*Glances at the window* No. I prefer the dry warmth of this room." },
      { "from": "human", "value": "Understandable. Want some coffee?" }
    ]
  }
]

2. Fine-Tuning Tools & CLI Commands

To train a LoRA efficiently on consumer hardware (such as a single RTX 3090/4090), you should use Unsloth (faster memory-optimized training) or Axolotl (configuration-driven training).

Option A: Running Unsloth (Python script template)

To run Unsloth, you initiate QLoRA using the HuggingFace SFTTrainer:

from unsloth import FastLanguageModel
import torch
from trl import SFTTrainer
from transformers import TrainingArguments

# 1. Load optimized model and tokenizer
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "unsloth/llama-3-8b-Instruct-bnb-4bit",
    max_seq_length = 8192,
    load_in_4bit = True,
)

# 2. Setup LoRA adapter parameters
model = FastLanguageModel.get_peft_model(
    model,
    r = 16, # Rank
    target_modules = ["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"],
    lora_alpha = 16,
    lora_dropout = 0,
    bias = "none",
)

# 3. Initialize SFTTrainer with your dataset
trainer = SFTTrainer(
    model = model,
    tokenizer = tokenizer,
    train_dataset = dataset,
    dataset_text_field = "text",
    max_seq_length = 8192,
    dataset_num_proc = 2,
    args = TrainingArguments(
        per_device_train_batch_size = 2,
        gradient_accumulation_steps = 4,
        warmup_steps = 5,
        max_steps = 60,
        learning_rate = 2e-4,
        fp16 = not torch.cuda.is_bf16_supported(),
        bf16 = torch.cuda.is_bf16_supported(),
        logging_steps = 1,
        output_dir = "outputs",
    ),
)
trainer.train()

Option B: Running Axolotl (YAML Configuration & Command)

Create a config.yml configuration:

base_model: unsloth/llama-3-8b-Instruct
model_type: LlamaForCausalLM
tokenizer_type: LlamaTokenizer

load_in_8bit: false
load_in_4bit: true

datasets:
  - path: roleplay_dataset.json
    type: sharegpt
    conversation: sharegpt

sequence_len: 8192
sample_packing: true
pad_to_sequence_len: true

adapter: qlora
lora_model_dir:
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_modules:
  - q_proj
  - v_proj
  - k_proj
  - o_proj

Then launch the Axolotl training container or command line tool:

# Launch Axolotl training using the config file
accelerate launch -m axolotl.cli.train config.yml

The blunt conclusion

If you want to train AI roleplay behavior, always begin with the infrastructure you already control. Tune the system prompt until it governs instead of narrating, use example dialogue to teach style directly, turn lorebooks into lean dynamic state instead of bloated biography containers, and keep memory architecture separate from style architecture.

Only when the stack is clean and the base model still refuses to live in the right prose universe should you reach for LoRA or QLoRA. Fine-tuning is a powerful, real tool, but it is far less often the first right answer than people hope.