Appearance
6. 提示词注入
提示词注入的原理是每次请求时都在指定深度位置增加一段指定的提示词。
用法通常包括:
- 在靠近尾部的位置编写指令,以便增加AI的指令/格式遵循率。
- 按照关键词触发注入知识,避免将所有内容写在提示词中塞满模型上下文。
当然与消息规则而言也各有优缺点,适合不同的场景:
- 消息规则可以将指令注入在消息对应位置,在之后的对话中该位置不会改变,输入缓存率好;但位置随着聊天增加而推移,直到被截断使上下文不再包含该内容。
- 提示词注入是每次请求固定在上下文中的某个位置,相当于对话会持续改变,输入缓存率更差(每次需要重算这些注入文本及其下方的所有内容);但不会随着对话推移被移出上下文,同时也能每次请求动态改变注入内容。
1. 深度
0代表在上下文末尾插入,1代表在最后一轮前面插入,2代表在倒数第二轮前面插入…… -1代表在上下文顶部(第一轮前面)插入,-2代表在第二轮前面插入……
轮数≠消息数:相同角色发的连续消息会被合并成一轮,或者说一次请求输出多条消息这都是一轮。
2. 注入条件
当前提示词注入分为:始终注入、普通匹配、正则匹配三种
3. 普通匹配
普通匹配的语法是一种类似搜索引擎的查询语法,使用空格代表与,使用|代表或,使用-代表非,使用括号可以将逻辑进行组合,例如:
爱音 素世代表对话中同时存在爱音和素世时注入。爱音|Anon代表会话中存在爱音或Anon时注入。爱音|Anon 素世|Soyo则意味着千早爱音和长崎素世,爱音soyorin,素世anon,AnonSoyo等等都能成功匹配。(爱音 素世)|(Anon Soyo)则意味着千早爱音和长崎素世,AnonSoyo能成功匹配,而爱音soyorin,素世anon不能成功匹配。苹果|Apple -公司则意味着苹果,Apple都能成功匹配,而Apple是美国科技公司则不能成功匹配。
4. 匹配范围
普通匹配/正则匹配会在最近的N轮对话中执行匹配,如果匹配成功则会注入提示词
同时也可以自己指定“搜索来源”和“最近轮数”(搜索轮数)
5. 注入提示词
推荐先阅读 7. 进阶:变量、变量模式、消息规则与表达式
注入提示词和普通提示词一样可以使用提示词中的变量以及各种表达式,如果是正则匹配还支持捕获组和捕获组变量,但不能使用除了Random/ReaderName外的其它消息规则中的变量(因为对于注入提示词而言,没有消息的概念)
另外,为了和用户输入区分开来(避免AI角色认为这注入的是你发送给他的消息),我们可以使用一些 XML 标签将内容包起来,例如:
<world_context>这里写一些知识条目、世界书之类</world_context><instruction>这里写一些对AI的指令、要求等等</instruction><status>当前状态:……</status>- ……(XML标签可以自己根据语义设计)
利用这一方法,我们可以将变量、消息规则、提示词注入结合起来使用,例如:
{{if witchification}}<world_context>
魔女化是……
</world_context>{{end}}当阶段条件满足,要魔女化(Witchification)时注入提示词说明什么是魔女化,即手动构造基于阶段的信息差,避免角色在前期就知道魔女化的过程造成的OOC。
<status>当前好感度:{{affection}}</status>可以给AI注入当前的状态。
其实我们有三个地方可以给AI输入这些状态信息:
- 用消息规则在用户消息后插入:每条用户消息都会带上当时的状态信息,可以让AI将对话内容和当时状态结合起来
- 提示词注入:例如设置深度0,则代表每次请求都会在最下方插入状态信息,但只会有当前状态,AI不知道历史某条消息时的状态
- 提示词里写变量(极不推荐):变化的提示词会直接破坏输入缓存,使得每次请求都必须全部重算
<instruction>
【选项】
在每次输出最后**必须**额外增加一条选项消息,根据当前剧情发展给{{User}}接下来的动作语言等提供1~4个选项,人称必须使用{{User}}的角度(在选项部分中,用“我”代指{{User}},用“你”代指你的身份),可使用中文括号表动作,格式如下:
- 选项内容1
- 选项内容2
</instruction>可以给AI注入一些指令要求,由于深度靠后指令遵循度通常会好一些。
{{if ReaderName=="千早爱音"}}<world_context>
注入内容A
</world_context>{{elseif ReaderName=="长崎素世"}}<world_context>
注入内容B
</world_context>{{end}}通常用于群聊,可以针对不同角色注入不同提示词,不同角色知道的信息不同,可以营造出信息差。
6. 调试
在会话设置里有一个“提示词注入调试”选项,点击即可查看刚才最近这次请求注入了哪些提示词内容,以及实际请求拼接后的情况。
7. 关于输入缓存(前缀缓存)
可以这样理解:LLM阅读一次文本后会将计算结果缓存下来,这样后续请求如果遇到有相同的前缀的内容时,就可以直接调用缓存而无需再读一遍,可以减少不必要的计算、加快请求速度、降低请求成本,缓存读取的价格通常只有输入(重新输入计算)的10%左右(DeepSeek官方的AI基础设施优化地非常好,缓存成功率非常高且价格极低,甚至可达到1%价格)。
因此如果你使用了提示词注入后,这会导致文本不相同破坏前缀缓存,使得LLM必须重新计算这些注入的文本以及其后方的所有内容(如聊天记录)
由此可得为了最佳的缓存率,最佳的深度通常是 0 或 1(底部);但如果注入的是不会改变的固定提示词的话,深度设置为 -1 (顶部)也可以避免缓存率下降。
深入了解前缀缓存可参考 DeepSeek 的这篇文档:上下文硬盘缓存