Lorebooks

"Note: This guide is currently largely influenced by this rentry."Lorebooks are NovelAI's way of adding misc. bits of text into generation context without actively cutting and pasting them into the actual body of your current story. Most other services offer a similar concept, calling it World Information or whatever else seemed appropriate. At the time of writing though, NovelAI gives you the most options as to how additional text is entered into the context.

What is a Lorebook?
A Lorebook (LB) lets you slap information into context without messing up the visual flow of your story and (most of the time) without you actively having to choose to insert them at any given moment.

Sounds like Memory or Author's Note with extra steps, right?

Yeah, basically.

A more accurate way of putting it would be that Memory and Author's Note are "VIP" Lorebooks: they are directly in the right-hand sidebar, can't be deleted and are always active, no matter what. They're the always-on lite-version of what you can do with Lorebooks.

What are cards?
Cards are a fun and visually informative way of letting you share and use lorebooks. In essence, NovelAI lets you embed the data of one or a multitude of lorebooks and categories into a .png file so you can share it with others or hoard them in a vault for your own use. Thanks to an Anon we have this card generator that itch.io made unusable in non-chromium based browsers due to some shenanigans. This issue is host-based so you can just go to the creator's github get yourself a godot environment and run the card maker locally.

If you just want to use them we have a large list of them in the thread's OP, some for specific setups like the Den of Sin or other, more general ones made for monthly card decks.

So what's a Lorebook made up of?
Glad I asked.

At its core a lorebook consists of a body and activation tags. The body gets inserted if a tag is found in the story or context. This process can be fine-tuned to a disturbing degree using the option NovelAI leaves at your disposal.

See the following class diagram for a basic list of the options a LB has. Not counting tags a Lorebook gives you 14 options you can mess with, that have varying degrees of interplay depending on their state. Some work in unison, others change interpretation and some just overrule the rest.

For the types listed below and most of your use cases only 4 of them really matter, unless you wanna go balls-deep into tweaking insertion positions.

Anyway, the 4 core options are:

Enabled

Can the lorebook be activated at all?

Search Range


 * How far back does its search for triggers go?

Force Activation

Is it just blindly inserted as long it also Enabled?

Cascading Activation

Can the text of another lorebook (memory and author's note included) activate this Lorebook?

These options influence when and why a given Lorebook is activated.

The other 10 options focus on how the LB's contents get inserted into the context of your story. I personally have not experimented with them long and seriously enough to make any reasonable distinctions here. For all I care right now these settings don't matter for sorting LBs into types. The only point I can make is that some types of LB may benefit more from certain extra fiddling than others.

But Key-Relative insertion is in-between Force Activation and Cascading Activation, why doesn't it matter to you?
Because it doesn't mess with activation in any way whatsoever. It's all about insertion, which I'm not concerned with here, 'cause it gets inserted either way.

Anyway, on to the annals of each option in a near-perfect vacuum!

Enabled
Is it on? Or is it off? This option acts as a gate and simply ignores the activation triggers of a lorebook while it is off. Generally you want this option active at all times, unless you manually mess around with force-activating entries as you see fit.

Search Range
How far back - counting in characters from the end of your story - can an entry search for its trigger to get activated? Note: This option does not apply for cascading activation.

Force Activation
Makes a lorebook get forcibly inserted into the context. Force-activated LBs are essentially compartmentalized versions of memory / author's note.

Key Relative Insertion
Causes the Lorebook entry to be inserted relative to the last of its keys to be found within the context, i.e. as close to the bottom of the context as possible. Note: This changes how insertion positions function. If You active key relativity you have to wrangle insertion positions.

Positive Insertion positions will insert the entry after the key. Negative insertion positions will insert the entry before the key.

Entries with this setting enabled should typically have a lower Insertion Order than the story context (default 0) and a sufficient amount of reserved tokens.

Large numbers of relatively inserted lorebook entries can slow down context creation.

Cascading activation
Lets a lorebook be activated by tags it can find in already-activated lorebooks already included in the current context as it is built. Memory and author's note also work for this. Tags within lorebooks will be found with no regard for search range. A Search Range of 0 with cascading activation active results in a lorebook that can only be activated by another lorebook.

Prefix
A bit of text that gets added in front of the lorebook's content after it was potentially trimmed down and before it gets slapped into context.

Suffix
A bit of text that gets added at the end of the lorebook's content after it was potentially trimmed down and before it gets slapped into context.

Token Budget
A budget, either in tokens or a decimal percentage (0.1 being 10%) of the context size the lorebook is weighed against. By default the budget is 2048 tokens, the current maximum context size. Exceeding a lowered budget will result in the lorebook being locked out of the context with the reason of "no space".

''Of note: Both Prefix and Suffix tokens count for this budget. It's usually best not to mess with the budget unless you really know what you're doing.''

Reserved Tokens
How many tokens of the total context can this Lorebook always demand? This option is usually kept at max unless you want to work with trimming.

Insertion Order
Works like onboarding for a plane, in a sense. The higher your priority the earlier your LB gets inserted. If your LB is activated by cascading, as it can only find lorebooks / memory / author's note keys if it gets onboarded after them. If two LBs have the same insertion order but one of them cascades off of the other it's a gamble on which one gets inserted first.

Insertion Position
The location the entry will be inserted into the context. 0 is the very top of the context, 1 is one unit down, 2 is two units down etc. Negative numbers will count from the bottom of the context starting with -1 at the very bottom, making -2 one unit up, -3 two units up etc.

Trim direction
Where - if necessary - does your lorebook get shortened? 3 Options: Top, Bottom or Don't, as advertised.

Maximum Trim Type
Up to where can trimming occur? Starting from the nearest newline? At each full sentence? At every token? The latter isn't really advised as it results in broken grammar within context.

Insertion Type
How does a lorebook get inserted? Does it get a full newline to separate it from the current context? Does it just get squished into a paragraph as though it is just another sentence? Or does it just interject itself at the level of tokens? Again, the last option here is pretty fucky unless you're an actual expert.

Now that you've read about the options you can disregard most of them and return to the core 4.

What about Categories?
Categories for lorebooks can help you sort them, apply category-specific insertion rules and phrase biases that apply based on the activation status of at least one or more of its entries; or the creation of a "subcontext".

What is a subcontext?
It's a context that is built on the level of a category's active lorebooks that will be assembled before the full context is built, meaning you have another layer of abstraction and get a bundle instead of individual lorebook entries. This also means that such a subxontext will be inserted into the larger context as a blob.

Phrase Biasing
Phrase Biasing can be added to lorebooks as well. Interestingly, you can also enable an option to activate a group of biases while a lorebook is not activated / triggered, making it possible to add positive biases to tags that would ultimately activate the lorebook.

= The types according to Void =

Basic Lorebooks (LB / BLB)
These Lorebooks are running on pure defaults. It's the most "intuitive" way to use them, since you slap information in, add a tag and you're basically "good" to go.

A decent use case for this would be a comprehensive rundown of a character, activated by the character's name(s). A basic LB only really remains a basic LB while you keep all settings vanilla. Most changes to the core 4 turn it into one of the below types.

Activated by

 * Story

Force-Activated Lorebook (FAL)
This is just memory with extra steps. The only real difference (without extra edits) is that this can be turned off, meaning you don't have to delete any text and can just reactivate it at will.

Activated by

 * You, the user

Cascading / Tree-like Lorebook (CLB/TreeLB)
From one LB sprout a dozen others, who may or may not sprout more. It starts at one and grows like cancer.

Activated by

 * Story
 * Memory
 * Author's Note
 * Activated Lorebooks

Specialized Lorebook (SpecL / SLB)
These take some more explaining, since they don't seem intuitive from the get go. For V1 of this I'll just say the idea is compartmentalization. You link specific details you find important for your story to specific triggers, phrases and RegEx patterns, ensuring activation only occurs when "needed".

Activated by

 * Story
 * Memory (with cascading activation)
 * Author's Note (with cascading activation)
 * Activated Lorebooks (with cascading activation)

Inverse Cascading Lorebook (ICL)
You can call them Reverse Cascading Lorebooks if you like. The core idea behind the name is that, unlike regular, "intuitive" CLB-Types this type of Lorebook moves from a bunch of Lorebooks that trigger at the front, followed by cascading activations that coalesce into one or very few Lorebooks that serve as a kind of "anchor". A term that keeps coming into my mind here is "chaining", which is also why the below image suggests zeroing out the search range for some of these inputs. These 0 search range ICLs can't activate unless a Lorebook (or Memory / Author's Note) containing one of its trigger terms is active.

Activated by

 * Story
 * Memory
 * Author's Note
 * Activated Lorebooks

= Fin = And while there's likely a ton more to discuss, plan and divulge that's it, for now.