mirror of
https://github.com/Wx-2025/ST-Amily2-Chat-Optimisation.git
synced 2026-06-13 09:15:50 +00:00
0d7e3b799e
### 新功能 - **翰林院向量化质量升级**： - **边界感知切块**：替换四个来源（聊天记录/小说/世界书/手动）的纯字符硬切——优先在段落边界断开，其次句末标点（含中文引号闭合），极端长串才硬切；句子/对话不再被拦腰截断，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 判断
212 lines
12 KiB
Markdown
212 lines
12 KiB
Markdown
---
|
||
|
||
## 翰林院篇：忆识核心与RAG系统
|
||
|
||
翰林院，是Amily2号的忆识核心，是真正的记忆中枢。它基于RAG（检索增强生成）技术，能让角色拥有可随时查阅、永不遗忘的知识库。
|
||
|
||
<div style="padding: 10px; background-color: #d1ecf1; border: 1px solid #bee5eb; border-radius: 5px; color: #0c5460;">
|
||
注意：本篇所有功能，均围绕着一个核心——将你的知识（无论是聊天记录、手动输入的文本，还是世界书条目）转化为向量数据，存入一个特殊的“忆识宝库”中。当你和角色对话时，系统会自动检索宝库中最相关的内容，注入到提示词中，让角色“记起”相关信息。
|
||
</div>
|
||
|
||
---
|
||
|
||
### 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. 总览与核心开关
|
||
|
||
这里是翰林院的仪表面板，展示了核心状态并提供了最高权限的操作。
|
||
|
||
|
||
*<center>上图：翰林院总览区域</center>*
|
||
|
||
| 配置项 | 说明 |
|
||
|---|---|
|
||
| **开启忆识检索之权** | **翰林院的总开关**。关闭后，所有检索和注入功能都将暂停，但不会影响向量化的录入。 |
|
||
| **忆识总数** | 显示当前角色忆识宝库中存储的向量总数。旁边的**刷新**按钮可以手动更新这个数字。 |
|
||
| **清空宝库** | **（危险操作）** 一键删除当前角色**所有**的忆识。此操作不可逆，三思而后行。 |
|
||
| **存档封印** | 保存你在翰林院界面所做的所有设置。虽然大多数设置是即时生效的，但点击一下总没错。<br />Ps：其实`1.1.7`版本后基本没卵用了。 |
|
||
|
||
> **附加说明**：忘记给刷新按钮增加自动刷新了，最好选择角色之后手动刷新一下。
|
||
|
||
---
|
||
|
||
### 2. 忆识检索 (Retrieval)
|
||
|
||
这里负责配置连接外部“神力之源”（Embedding API）的通道，它是将文字转化为向量的根本。
|
||
|
||
|
||
*<center>上图：忆识检索配置区域</center>*
|
||
|
||
| 配置项 | 说明 |
|
||
|---|---|
|
||
| **API设定** | 选择你的Embedding服务商。如果你有自己的中转或特殊服务……也得`自定义`，毕竟其他的东西没完善。 |
|
||
| **自定义路径** | 当`API设定`为`自定义`时，在此处填写你的完整API地址。 |
|
||
| **通行令牌 (API Key)** | 你的Embedding API密钥。 |
|
||
| **嵌入模型** | 你想使用的Embedding模型。点击`获取模型`按钮可以自动从API拉取可用模型列表。 |
|
||
| **测试神力** | 点击后会尝试用你填写的配置连接API，检查是否能成功“沟通”。 |
|
||
| **重置为初** | 将此页面的所有设置恢复到最初的默认状态。 |
|
||
|
||
> <div style="padding: 10px; background-color: #f8d7da; border: 1px solid #f5c6cb; border-radius: 5px; color: #721c24;"> 重要提示：此处的API与主殿的API是**完全独立**的。主殿API负责聊天，翰林院API负责将知识向量化。两者可以相同，也可以不同。</div>
|
||
|
||
---
|
||
|
||
### 3. 书库编纂 (Historiography)
|
||
|
||
这里是向忆识宝库中“录入”向量的地方，提供了多种方式。
|
||
|
||
#### 凝识法则
|
||
这是最常用的功能，可以将你们的聊天记录转化为忆识（向量）。
|
||
|
||
|
||
*<center>上图：凝识法则配置区域</center>*
|
||
|
||
| 配置项 | 说明 |
|
||
|---|---|
|
||
| **准许凝识** | 此功能的总开关（我一直开着的，不知道关了它之后录入还好不好使。） |
|
||
| **凝识范围** | 设定要转换的聊天记录楼层范围。例如，1-10就是转换最早的10条消息。 |
|
||
| **消息来源** | 选择要转换谁说的话，是你，还是AI，还是两者都要。 |
|
||
| **标签提取** | 一个高级功能，可以让你只提取消息中特定XML标签里的内容进行转换，可单可多，可预览编辑，但标签顺序要一致。 |
|
||
| **开始凝识** | 点击后，立刻根据以上设定，将聊天记录录入忆识宝库。 |
|
||
| **预览内容** | 在不实际录入的情况下，查看根据当前设定会生成哪些文本内容。 |
|
||
|
||
#### 手动录入 & 按条目编纂
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
*<center>上图：手动录入与按条目编纂区域</center>*
|
||
|
||
| 功能区 | 说明 |
|
||
|---|---|
|
||
| **手动录入** | 在文本框里粘贴任何你想要角色记住的文字（比如角色设定、背景故事），然后点击`开始录入`，即可存入宝库。 |
|
||
| **按条目编纂** | 可以直接选择一个**世界书**及其中的**条目**，将其内容整个录入忆识宝库。对于已经整理好的知识非常方便。 |
|
||
|
||
> **附加说明**：没事不要加太多东西，酒馆向量库炸了你不炸了吗。
|
||
|
||
---
|
||
|
||
### 4. 忆识精炼 (Rerank)
|
||
|
||
当检索到的忆识过多时，Rerank功能可以对初步检索结果进行二次排序，选出与当前对话**最最相关**的几条，大大提高知识注入的精准度。
|
||
|
||
|
||
*<center>上图：Rerank配置区域</center>*
|
||
|
||
| 配置项 | 说明 |
|
||
|---|---|
|
||
| **启用 Rerank** | 此功能的总开关。 |
|
||
| **Rerank API 地址/Key/模型** | 和Embedding API一样，你需要一个专门的Rerank模型服务。配置方法完全相同。 |
|
||
| **返回结果数 (top_n)** | Rerank之后，最终返回多少条最相关的忆识。 |
|
||
| **混合分数权重 (Alpha)** | 一个高级参数，用于平衡原始相似度分数和Rerank分数。保持默认的0.7通常效果最好。 |
|
||
| **Rerank 时上奏** | 开启后，每次成功执行Rerank都会在聊天框里发一条通知。 |
|
||
|
||
> **附加说明**：听说这东西的提示词挺重要，但是我还没加。而且LLM的实现方式有点复杂，我慢慢整吧还是。
|
||
|
||
---
|
||
|
||
### 5. 高级设定
|
||
|
||
这里提供了一些微调参数，让你对翰林院的行为有更精细的控制。
|
||
|
||
|
||
*<center>上图：检索微调区域</center>*
|
||
|
||
| 配置项 | 说明 |
|
||
|---|---|
|
||
| **书卷尺寸 (Chunk Size)** | 在录入知识时，将长文本切分成的小块的大小。这会影响检索的粒度。 |
|
||
| **上下文关联度 (Overlap)** | 每个小块之间重叠的字符数，以确保上下文的连续性。 |
|
||
| **忆识匹配度 (Threshold)** | 只有相似度高于这个阈值的忆识才会被检索出来。 |
|
||
| **检索参考的消息数量** | 系统会拿最近几条消息作为“问题”去检索忆识宝库。 |
|
||
| **单次检索最大结果数** | 在Rerank之前，初步从向量库中捞出多少条相关的忆识。 |
|
||
|
||
> **附加说明**：没有附加说明，就单纯不想写。
|
||
|
||
---
|
||
|
||
#### 圣言注入
|
||
这里决定了检索到的忆识，将以何种方式“告诉”给角色。
|
||
|
||
|
||
*<center>上图：圣言注入配置区域</center>*
|
||
|
||
| 配置项 | 说明 |
|
||
|---|---|
|
||
| **圣言模板** | 注入内容的格式。`{{text}}`是占位符，会被实际的忆识内容替换，占位符不要乱改。<br />但是上面的提示词可以随意改，例如：“这里是已发生过事情中的相关记忆片段，请以以下内容作为参考：{{text}}。”像是这样。 |
|
||
| **注入位置** | 决定了这段“圣言”放在提示词的哪个位置。`聊天内 @ 深度`是最常用的，可以模拟一条特定角色的历史消息。 |
|
||
|
||
---
|
||
|
||
### 6. 起居注
|
||
|
||
这里是翰林院的运行日志，记录了每一次知识录入、检索、注入的详细过程。如果遇到问题，来这里看看，通常能找到原因。
|
||
|
||
|
||
*<center>上图：起居注区域</center>*
|
||
|
||
> **附加说明**：翰林院的教程就到这里了。这玩意很强大，但也需要耐心调教。多试试不同的设置，找到最适合你和你的角色的用法吧。
|
||
>
|
||
> <div style="padding: 10px; background-color: #f8d7da; border: 1px solid #f5c6cb; border-radius: 5px; color: #721c24;"> 重要提示：但要是有关翰林院的报错，你还给我截图红色框框，你看我把不把你头打爆。</div>
|
||
|
||
---
|