slvccans/ST-Amily2-Chat-Optimisation
1
0
Fork 0
mirror of https://github.com/Wx-2025/ST-Amily2-Chat-Optimisation.git synced 2026-06-13 09:15:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
0d7e3b799e4bb9e7bf9c982ff4e7c99af5b1451e
ST-Amily2-Chat-Optimisation/HanLin.md
Jenkins CI 0d7e3b799e release: v2.2.6 [2026-06-13 01:02:05] 
### 新功能
- **翰林院向量化质量升级**：
  - **边界感知切块**：替换四个来源（聊天记录/小说/世界书/手动）的纯字符硬切——优先在段落边界断开，其次句末标点（含中文引号闭合），极端长串才硬切；句子/对话不再被拦腰截断，embedding 质量同步受益。仅影响新录入，已有向量无需重建
  - **注入时序重排**：检索结果注入提示词前按时序重排（聊天记录按楼层、小说按卷/章/节——中文数字章节号可解析），rerank 只决定"选哪些块"，不再决定呈现顺序；修复"不打不相识的剧情之后紧跟关系亲密"这类因按相关度排序导致的认知时间错乱
  - **断层提示**：聊天记录相邻块楼层跳跃时自动插入"与上文相隔约 N 楼，并非连续发生"提示行，消除中间剧情缺失造成的割裂感
  - **时间标识**：新录入的聊天记录块在来源标识中带上消息发送时间（ST 向量存储不持久化元数据，时间必须写入块文本才能在检索后取回；旧格式块兼容解析）
- **记忆块工作流（memory-blocks）**：剧情优化新增"自定义记忆块"体系——占位符驱动的并发工作流框架
  - 在剧情优化面板「匹配替换 (sulv)」下方可增删自定义块：每个块定义一个占位符，执行剧情优化时主/拦截提示词中的占位符会被块的产出替换
  - **静态块**：直接输出固定内容；**AI 调用块**：用所选 API 功能槽独立请求一次，把回复（或其中指定 `<标签>` 的内容）作为替换值
  - 原有 sulv1-4 速率占位符迁入同一框架，行为与旧版逐字节一致
  - 块定义为纯 JSON、随设置持久化，为后续导入导出与战斗系统接入预留扩展点
  - 框架层新增**顺序拼接式 Chain**（`composeChain`）：与占位符替换并列的第二种组合范式——同链的块并发执行后按 `order` 排序、以 `separator` 拼接并可选 `header/footer` 包裹，产出一个完整注入块；为记忆注入合成块与战斗系统"底部战报块"预留的承载结构，本版本暂无 UI 入口
- **API 连接配置**：
  - 角色世界书（cwb）与一键生卡（autoCharCard）纳入旧配置自动迁移：老用户首次加载会把旧 URL / Key / 模型自动迁移为连接配置并分配槽位（一键生卡仅在规划者与执行者配置一致或规划者为空时迁移，避免悄悄改变行为）
  - **profile 已分配时参数控件 informational 化**：主面板 / 并发剧情优化 / 角色世界书 / 术语表的温度、maxTokens 控件在槽位分配 profile 后自动禁用并显示"由连接配置控制"提示，消除"改了没效果"的用户陷阱
  - **profile 状态卡新增"本设备无 Key"警示**：API Key 仅保存在最初填写它的设备/浏览器上（安全设计，不随云端设置同步），换设备后状态卡会直接亮出警示徽标，不必等到调用报错才发现
### 修复
- **独立聊天记忆从摆设变真功能（原作遗留坑）**：此前向量数据"随卡不随聊天"——开启"独立聊天记忆"后录入仍存进角色库、查询却去查一个从未被写入过的聊天集合、计数恒为 0，整体静默失效。现已重构为聊天级分桶：
  - 独立模式下，聊天记录类向量按当前聊天隔离存储与检索，同一张卡开多个聊天（不同剧情线）的记忆互不污染
  - 小说 / 世界书 / 手动录入属于"知识"，仍随角色卡跨聊天共享；全局库不受影响
  - 知识管理列表为聊天专属库显示"聊天级"徽标；聊天级库禁止移动到全局
  - 统一模式（默认关闭独立记忆）的存量数据与行为完全不变
  - 已知限制：聊天专属记忆跟随聊天文件，重命名聊天文件会使其失联（与 ST 官方向量扩展同等限制）
- **超级排序截断顺序修正**：开启"超级排序"时，时序重排发生在 top_n 截断之前，导致保留的是"时序最早"而非"最相关"的块，检索结果长期偏向最旧的聊天记录。现改为先按相关度截取 top_n、再做时序排序
- **翰林院向量化失败（"向量化块数量不识别"反馈）**：
  - 一次性清洗 profile-sync 历史污染：`retrieval/rerank.apiKey` 中的掩码占位符在持久层根治（此前仅读取侧防御）；`apiEndpoint` / `rerank.apiMode` 的非法值（如被旧版写入的空字符串）归一化为 `custom`
  - 修复 `apiEndpoint` 为空/非法时请求被硬定向到 `api.openai.com`、无视用户自定义 URL 的问题（CSP 拦截 / 401 的元凶）
  - 修复**本地代理（LM Studio/Ollama）模式**自始就缺少 URL 分支、同样被错误定向到 openai.com 的问题
  - API 模式下拉补全 `OpenAI 官方` / `Azure` 选项；默认 API 模式改为 `custom`（与默认 URL 配套），新用户不再因选项缺失导致首次保存写入空值
  - profile-sync 给下拉框赋不存在选项值的污染源头修复（影响所有模块面板，不止翰林院）
- **Rerank "API Key 未提供"报错升级**：当原因是"连接配置在本设备没有可用 Key"时，报错会直接说明 Key 的设备本地性并指引到 API 连接配置重新填写（向量化 Google 直连、获取模型列表同步处理）
- **旧配置迁移**：一键生卡迁移时排除掩码占位符，避免把历史污染的假 Key 迁入新连接配置
- **超级记忆稳定性专项**（针对"工作不大稳定"反馈，4 处根因一次修复）：
  - **切聊天竞态污染**：CHAT_CHANGED 时超级记忆立即全量同步，而表格系统延迟 100ms 才加载新聊天的表格，导致【旧聊天】的表格内容被写进【新角色】的记忆世界书；两边表名不同时旧表条目无 GC 兜底会**永久残留**（"记忆串台"元凶）。现 CHAT_CHANGED 只确保世界书存在，新状态同步交由 `loadTables()` 完成后的自动推送，单次且时序正确
  - **死代码双轨存储拆除**：`saveStateToMetadata` / `tryRestoreStateFromMetadata` 把表格状态写到 `msg.metadata`——该字段非 ST 持久化位（同 v2.2.5 二次填表修过的坑），写入即蒸发、恢复永远为空，且每次同步还白调一次 `saveChat()`。整条链路删除，表格状态唯一信源为表格系统的 `msg.extra.amily2_tables_data`
  - **`awaitSync()` 穿透**：同步队列正忙时 `pushUpdate` 会用一个立即 resolve 的空 Promise 覆盖 `_syncPromise`，Pipeline Stage 4 等待形同虚设、后续阶段在同步未完成时被放行。现忙时不覆盖，正在运行的 drain 循环自然吃掉新入队项
  - **开关打开不生效**：启动时若总开关为关，初始化早退且不注册监听器；此后在 UI 勾选开关只写设置，超级记忆直到刷新页面前都是死的。现勾选即触发初始化（幂等）
  - 附带：`forceSyncAll` 的表格角色推断改为复用 `events-schema.inferTableRole`，消除两处重复逻辑漂移风险；每次切聊天的双倍全量同步（restore 路径一次 + 显式一次）随死代码移除归一
### 重构
- 表格核心 `manager.js` 瘦身（约 1050 → 600 行）：19 个 UI 突变操作拆分至 `actions/ui-mutations.js`，SuperMemory 事件分发拆分至 `events-dispatch.js`；全部经 re-export 保持兼容，外部调用路径零改动
- 角色世界书最后 2 处散乱的厂商 URL 判断迁移至 `detectVendor` 统一入口，业务路径上不再有硬编码的 URL substring 判断
2026-06-13 01:02:05 +08:00

12 KiB
Raw Blame History

## 翰林院篇：忆识核心与RAG系统 翰林院，是Amily2号的忆识核心，是真正的记忆中枢。它基于RAG（检索增强生成）技术，能让角色拥有可随时查阅、永不遗忘的知识库。
注意：本篇所有功能，均围绕着一个核心——将你的知识（无论是聊天记录、手动输入的文本，还是世界书条目）转化为向量数据，存入一个特殊的“忆识宝库”中。当你和角色对话时，系统会自动检索宝库中最相关的内容，注入到提示词中，让角色“记起”相关信息。

0. 原理速览：文本向量化（Embedding & Rerank）

本节并非专业科普文献，不建议作为专业知识内容进行参考——只为帮你理解翰林院"为什么需要两套模型、它们各管什么"。

文本向量化的作用和意义是：让计算机可以读懂人类的语言，并且可以找到最接近的内容（或理解其意思）。

Embedding 模型（忆识检索用）

比如我们有 3 个类型的标签，分别为：电子设备、体育运动、水果。

当我们传入"苹果手机"、"华为手机"、"跑步机"、"苹果"时，向量化后会得到每个文本的数字表示（通常是几百维的向量），如：

苹果手机： [0.2, 0.8, -0.1, 0.7, ...] (300个数字)
华为手机： [0.3, 0.7, -0.2, 0.6, ...] (300个数字)
跑步机：   [0.8, 0.1, 0.9, -0.3, ...] (300个数字)
苹果：     [-0.1, 0.2, 0.8, 0.9, ...] (300个数字)

同时我们也有每个类别标签的向量表示：

电子设备： [0.1, 0.9, -0.2, 0.8, ...]
体育运动： [0.9, 0.2, 0.8, -0.1, ...]
水果：     [-0.2, 0.1, 0.7, 0.8, ...]

在实际应用中，我们通过计算相似度来找到最匹配的内容：

  1. 计算"苹果"与各标签的相似度：与"水果"0.92、与"电子设备"0.15、与"体育运动"0.08
  2. 计算"苹果手机"与各标签的相似度：与"电子设备"0.88、与"水果"0.35、与"体育运动"0.12
  3. 查找相似内容：如果想找与"苹果手机"相似的内容——与"华为手机"0.95、与"跑步机"0.23、与"苹果"0.31

对计算机来说，直接的"苹果"、"手机"、"电子设备"等词语是不存在意义的，而向量化后的数字是可以被计算机理解和计算的。向量化可以确保计算机或 AI 能知道你"可能"想找些什么，并找到最接近的内容。 这正是"忆识检索"做的事：你的知识被切块、向量化存入宝库；对话时把最近的消息也向量化，按相似度捞出最相关的忆识。

Reranker 模型（忆识精炼用）

Rerank 模型和 Embedding 模型的功能类似，但更加精细，可以对候选内容给出"更符合查询意思"的评分，选出最贴切的内容块。

以下是一个极简示意（并不是 rerank 模型的实际工作机制，只为便于理解）。假设有个超简化的 Reranker，只关注两个词："便宜"和"智能"：

  • 用户查询："便宜的智能手机"
  • 候选答案：① "这款手机很智能"　② "这个价格很便宜"　③ "智能手机性价比高"

评分规则（简化版）：匹配"便宜"+2 分、匹配"智能"+1 分、两个词都匹配额外 +3 分（奖励深度相关）：

候选 匹配分析 总分
① 这款手机很智能 仅"智能" +1 1
② 这个价格很便宜 仅"便宜" +2 2
③ 智能手机性价比高 "智能"+1、"性价比高"≈"便宜"+2、双匹配+3 6

Rerank 后：③ > ② > ①——原本排最后的"智能手机性价比高"被识别为最佳匹配。

为什么两个都要

Rerank 模型比 Embedding 模型算力需求更大（看看价格便可得知）、速度更慢，但更加精确。所以最常见的组合就是：先由 Embedding 模型快速筛出特征相近的块（粗筛），再由 Reranker 在小范围内选出最贴合的块（精筛），既保证质量又节约 Token 用量。翰林院的"忆识检索"+"忆识精炼"两个页签正是这套组合。

1. 总览与核心开关

这里是翰林院的仪表面板，展示了核心状态并提供了最高权限的操作。

总览界面

上图：翰林院总览区域

配置项 说明
开启忆识检索之权 翰林院的总开关。关闭后，所有检索和注入功能都将暂停，但不会影响向量化的录入。
忆识总数 显示当前角色忆识宝库中存储的向量总数。旁边的刷新按钮可以手动更新这个数字。
清空宝库 （危险操作） 一键删除当前角色所有的忆识。此操作不可逆，三思而后行。
存档封印 保存你在翰林院界面所做的所有设置。虽然大多数设置是即时生效的，但点击一下总没错。
Ps：其实1.1.7版本后基本没卵用了。

附加说明：忘记给刷新按钮增加自动刷新了，最好选择角色之后手动刷新一下。

2. 忆识检索 (Retrieval)

这里负责配置连接外部“神力之源”（Embedding API）的通道，它是将文字转化为向量的根本。

忆识检索界面

上图：忆识检索配置区域

配置项 说明
API设定 选择你的Embedding服务商。如果你有自己的中转或特殊服务……也得自定义，毕竟其他的东西没完善。
自定义路径 当API设定为自定义时，在此处填写你的完整API地址。
通行令牌 (API Key) 你的Embedding API密钥。
嵌入模型 你想使用的Embedding模型。点击获取模型按钮可以自动从API拉取可用模型列表。
测试神力 点击后会尝试用你填写的配置连接API，检查是否能成功“沟通”。
重置为初 将此页面的所有设置恢复到最初的默认状态。
重要提示：此处的API与主殿的API是**完全独立**的。主殿API负责聊天，翰林院API负责将知识向量化。两者可以相同，也可以不同。

3. 书库编纂 (Historiography)

这里是向忆识宝库中“录入”向量的地方，提供了多种方式。

凝识法则

这是最常用的功能，可以将你们的聊天记录转化为忆识（向量）。

凝识法则界面

上图：凝识法则配置区域

配置项 说明
准许凝识 此功能的总开关（我一直开着的，不知道关了它之后录入还好不好使。）
凝识范围 设定要转换的聊天记录楼层范围。例如，1-10就是转换最早的10条消息。
消息来源 选择要转换谁说的话，是你，还是AI，还是两者都要。
标签提取 一个高级功能，可以让你只提取消息中特定XML标签里的内容进行转换，可单可多，可预览编辑，但标签顺序要一致。
开始凝识 点击后，立刻根据以上设定，将聊天记录录入忆识宝库。
预览内容 在不实际录入的情况下，查看根据当前设定会生成哪些文本内容。

手动录入 & 按条目编纂

手动与按条目编纂

手动与按条目编纂

上图：手动录入与按条目编纂区域

功能区 说明
手动录入 在文本框里粘贴任何你想要角色记住的文字（比如角色设定、背景故事），然后点击开始录入，即可存入宝库。
按条目编纂 可以直接选择一个世界书及其中的条目，将其内容整个录入忆识宝库。对于已经整理好的知识非常方便。

附加说明：没事不要加太多东西，酒馆向量库炸了你不炸了吗。

4. 忆识精炼 (Rerank)

当检索到的忆识过多时，Rerank功能可以对初步检索结果进行二次排序，选出与当前对话最最相关的几条，大大提高知识注入的精准度。

忆识精炼界面

上图：Rerank配置区域

配置项 说明
启用 Rerank 此功能的总开关。
Rerank API 地址/Key/模型 和Embedding API一样，你需要一个专门的Rerank模型服务。配置方法完全相同。
返回结果数 (top_n) Rerank之后，最终返回多少条最相关的忆识。
混合分数权重 (Alpha) 一个高级参数，用于平衡原始相似度分数和Rerank分数。保持默认的0.7通常效果最好。
Rerank 时上奏 开启后，每次成功执行Rerank都会在聊天框里发一条通知。

附加说明：听说这东西的提示词挺重要，但是我还没加。而且LLM的实现方式有点复杂，我慢慢整吧还是。

5. 高级设定

这里提供了一些微调参数，让你对翰林院的行为有更精细的控制。

高级设定界面

上图：检索微调区域

配置项 说明
书卷尺寸 (Chunk Size) 在录入知识时，将长文本切分成的小块的大小。这会影响检索的粒度。
上下文关联度 (Overlap) 每个小块之间重叠的字符数，以确保上下文的连续性。
忆识匹配度 (Threshold) 只有相似度高于这个阈值的忆识才会被检索出来。
检索参考的消息数量 系统会拿最近几条消息作为“问题”去检索忆识宝库。
单次检索最大结果数 在Rerank之前，初步从向量库中捞出多少条相关的忆识。

附加说明：没有附加说明，就单纯不想写。

圣言注入

这里决定了检索到的忆识，将以何种方式“告诉”给角色。

圣言注入界面

上图：圣言注入配置区域

配置项 说明
圣言模板 注入内容的格式。{{text}}是占位符，会被实际的忆识内容替换，占位符不要乱改。
但是上面的提示词可以随意改，例如：“这里是已发生过事情中的相关记忆片段，请以以下内容作为参考：{{text}}。”像是这样。
注入位置 决定了这段“圣言”放在提示词的哪个位置。聊天内 @ 深度是最常用的，可以模拟一条特定角色的历史消息。

6. 起居注

这里是翰林院的运行日志，记录了每一次知识录入、检索、注入的详细过程。如果遇到问题，来这里看看，通常能找到原因。

起居注界面

上图：起居注区域

附加说明：翰林院的教程就到这里了。这玩意很强大，但也需要耐心调教。多试试不同的设置，找到最适合你和你的角色的用法吧。

重要提示：但要是有关翰林院的报错，你还给我截图红色框框，你看我把不把你头打爆。
Reference in New Issue View Git Blame Copy Permalink