www
332 lines
8.0 KiB
Markdown
332 lines
8.0 KiB
Markdown
那 chatgpt 这个网页版是怎么做到记忆的，我使用网页版涩会给你从了120章节小说，挺好的
|
|
|
|
你在网页版感觉“120 章也记得住”，主要是因为 ChatGPT 产品层做了几件事，不是单纯“模型自己永久记住全文”。
|
|
|
|
简单说，网页版大概是这几层能力叠加：
|
|
|
|
```text
|
|
当前对话上下文
|
|
+ 上传文件解析
|
|
+ 长上下文窗口
|
|
+ 相关内容检索
|
|
+ 对话历史 / 项目文件 / 记忆能力
|
|
+ 系统自动挑选相关信息塞回模型
|
|
```
|
|
|
|
OpenAI 官方也说明，ChatGPT 的记忆包括“保存的记忆”和“引用聊天历史”，开启后会从过去对话里提取有用信息加入新对话；项目功能也可以把聊天、参考文件和自定义指令放在一起，让 ChatGPT 保持主题连续；文件上传也支持较大的文本/文档文件。([OpenAI Help Center][1])
|
|
|
|
---
|
|
|
|
# 一、网页版不是把 120 章永远塞进模型脑子里
|
|
|
|
你上传 120 章小说后，ChatGPT 能表现得不错，通常是因为：
|
|
|
|
1. 文件被解析成文本；
|
|
2. 系统知道这个文件属于当前会话/项目；
|
|
3. 你问问题时，系统会从文件和对话里找相关片段；
|
|
4. 把相关内容、摘要、上下文放进本次模型输入；
|
|
5. 模型基于这些内容回答。
|
|
|
|
也就是说，它不是“永久记住 120 章全文每个字”，而是：
|
|
|
|
> **文件在系统里，模型每次需要时可以被喂到相关内容。**
|
|
|
|
这和我前面说的小说流水线是同一个原理。
|
|
|
|
你的系统也要这么做：
|
|
|
|
```text
|
|
小说全文入库
|
|
章节摘要入库
|
|
人物状态入库
|
|
伏笔入库
|
|
按需检索
|
|
拼装上下文
|
|
再调用模型
|
|
```
|
|
|
|
---
|
|
|
|
# 二、为什么网页版看起来比普通 API 更聪明？
|
|
|
|
因为网页版 ChatGPT 已经帮你做了很多产品层工作。
|
|
|
|
比如：
|
|
|
|
## 1. 当前聊天本身有上下文
|
|
|
|
你在同一个聊天里连续讨论，前面的内容会作为上下文的一部分参与后续回答。
|
|
|
|
但这有长度限制，不是无限的。
|
|
|
|
---
|
|
|
|
## 2. 上传文件可以被引用
|
|
|
|
你上传小说文件后，ChatGPT 可以围绕文件问答、总结、分析。官方文件上传 FAQ 里提到，文本和文档文件有 token 上限，文件大小也有限制。([OpenAI Help Center][2])
|
|
|
|
这说明文件不是“变成模型永久记忆”，而是作为可处理的数据源。
|
|
|
|
---
|
|
|
|
## 3. ChatGPT 有记忆和引用聊天历史
|
|
|
|
官方说明，开启“Reference chat history”后，ChatGPT 会引用过去对话中有用的信息，让后续对话更个性化、更相关。([OpenAI Help Center][3])
|
|
|
|
但这类记忆更适合记：
|
|
|
|
你的偏好；
|
|
你的项目方向；
|
|
你常用技术栈；
|
|
你之前的要求；
|
|
你对风格的偏好。
|
|
|
|
它不适合当作“精确保存 120 章小说全文”的数据库。
|
|
|
|
---
|
|
|
|
## 4. Projects 可以聚合上下文
|
|
|
|
ChatGPT Projects 可以把聊天、文件和项目指令放在一起，让工作更连续。官方说明 Projects 可以组织聊天、上传参考文件、添加自定义指令，让 ChatGPT 围绕项目保持主题。([OpenAI Help Center][4])
|
|
|
|
这跟你系统里的“NovelSource + StoryBible + Memory + Character + Foreshadow”很像。
|
|
|
|
---
|
|
|
|
# 三、API 里为什么感觉不一样？
|
|
|
|
因为 API 默认不会自动帮你做这么完整的产品层。
|
|
|
|
API 更像一个模型调用接口：
|
|
|
|
```text
|
|
你传什么，它就基于什么回答。
|
|
```
|
|
|
|
如果你想让 API 也像网页版一样“记得住”，你要自己实现这些层：
|
|
|
|
```text
|
|
文件解析层
|
|
章节切分层
|
|
摘要层
|
|
向量检索层
|
|
上下文拼装层
|
|
记忆更新层
|
|
版本快照层
|
|
```
|
|
|
|
网页版帮你做了很多。
|
|
你自己的系统要自己做。
|
|
|
|
---
|
|
|
|
# 四、你系统应该仿照 ChatGPT 做什么？
|
|
|
|
你可以把 ChatGPT 的机制“产品化”到你自己的小说系统里。
|
|
|
|
## 1. 小说全文库
|
|
|
|
保存完整正文。
|
|
|
|
```text
|
|
NovelSource
|
|
NovelChapter
|
|
```
|
|
|
|
你现在已经有这部分。你的架构文档里也显示当前小说系统已支持小说源、章节、阅读器、章节导入和章节切割。
|
|
|
|
---
|
|
|
|
## 2. 小说摘要库
|
|
|
|
每章保存摘要。
|
|
|
|
```text
|
|
第1章摘要
|
|
第2章摘要
|
|
……
|
|
第120章摘要
|
|
```
|
|
|
|
后续写第 121 章，不传 120 章全文，只传相关摘要。
|
|
|
|
---
|
|
|
|
## 3. 人物状态库
|
|
|
|
不能只存人物初始设定，要存当前状态。
|
|
|
|
比如：
|
|
|
|
```text
|
|
主角当前知道什么
|
|
女主和男主关系到哪一步
|
|
反派是否暴露
|
|
某人有没有死亡
|
|
某秘密是否揭开
|
|
```
|
|
|
|
---
|
|
|
|
## 4. 伏笔库
|
|
|
|
专门管理伏笔。
|
|
|
|
```text
|
|
F001 首次出现第3章
|
|
当前状态 developing
|
|
预计第80章回收
|
|
```
|
|
|
|
---
|
|
|
|
## 5. 检索层
|
|
|
|
当写第 121 章时，系统根据章节卡自动检索：
|
|
|
|
```text
|
|
本章出场人物
|
|
相关伏笔
|
|
相关地点
|
|
上次出场章节
|
|
关键原文片段
|
|
```
|
|
|
|
---
|
|
|
|
## 6. 上下文拼装层
|
|
|
|
最后拼成给模型的输入：
|
|
|
|
```text
|
|
小说圣经摘要
|
|
当前卷纲
|
|
最近5章摘要
|
|
本章出场人物状态
|
|
本章相关伏笔
|
|
本章章节卡
|
|
相关原文片段
|
|
文风规则
|
|
禁止事项
|
|
```
|
|
|
|
这就等于你自己做了一个“小说版 ChatGPT 项目上下文”。
|
|
|
|
---
|
|
|
|
# 五、为什么你上传 120 章时效果还可以？
|
|
|
|
因为你给的是一个完整作品，任务可能是“分析、总结、改编、继续设计”。
|
|
这种情况下，模型可以通过文件检索和长上下文找到足够信息。
|
|
|
|
但如果你要自动写 300 章、500 章，情况就不一样了。
|
|
|
|
区别在这里：
|
|
|
|
| 场景 | 难度 |
|
|
| ------------------- | --- |
|
|
| 上传 120 章，让 AI 分析 | 较容易 |
|
|
| 上传 120 章，让 AI 改编剧本 | 中等 |
|
|
| 从第 1 章开始自动写到第 500 章 | 很难 |
|
|
| 多模型自动写长篇并保持伏笔、人设、节奏 | 更难 |
|
|
|
|
所以你做系统时不能只靠“上传全文让模型看”。
|
|
|
|
要做长期可控的记忆系统。
|
|
|
|
---
|
|
|
|
# 六、最接近 ChatGPT 网页版的自建方案
|
|
|
|
你可以这样设计：
|
|
|
|
```text
|
|
NovelSource = 文件/小说源
|
|
NovelChapter = 章节正文
|
|
NovelMemory = 自动摘要/人物状态/伏笔
|
|
NovelEmbedding = 章节向量索引
|
|
NovelContextBuilder = 上下文拼装器
|
|
AgentRun = 每次模型调用记录
|
|
```
|
|
|
|
写第 N 章时：
|
|
|
|
```text
|
|
1. 查 NovelBible
|
|
2. 查当前卷纲
|
|
3. 查最近 5 章摘要
|
|
4. 查出场人物状态
|
|
5. 用 embedding 检索相关旧章节片段
|
|
6. 查相关伏笔
|
|
7. 控制 token 预算
|
|
8. 拼 prompt
|
|
9. 调模型
|
|
10. 保存输出
|
|
11. 更新摘要/人物/伏笔
|
|
```
|
|
|
|
这就是你要在后台复刻的“ChatGPT 网页版长上下文体验”。
|
|
|
|
---
|
|
|
|
# 七、重点提醒
|
|
|
|
网页版看起来“记住”，但也会有问题：
|
|
|
|
1. 它不保证每个细节都准；
|
|
2. 它可能漏掉很早以前的小伏笔；
|
|
3. 它可能把相似角色混淆；
|
|
4. 它不会自动替你维护商业化流程；
|
|
5. 它没有你的数据库、成本、队列、版本、派生短剧任务控制。
|
|
|
|
所以你做系统不能完全依赖模型能力。
|
|
|
|
真正可控的是：
|
|
|
|
```text
|
|
系统记忆 > 模型记忆
|
|
结构化上下文 > 全文堆入
|
|
版本快照 > 当前文本覆盖
|
|
质检闭环 > 一次生成
|
|
```
|
|
|
|
---
|
|
|
|
# 八、对应你当前系统的落地判断
|
|
|
|
你现在项目里已经有：
|
|
|
|
```text
|
|
NovelsModule
|
|
StoryBiblesModule
|
|
CharactersModule
|
|
MemoriesModule
|
|
EpisodesModule
|
|
ScriptsModule
|
|
LiveActionModule
|
|
Provider Layer
|
|
BullMQ Worker
|
|
```
|
|
|
|
这些模块非常适合做“网页版 ChatGPT 类似的小说项目上下文”。
|
|
|
|
下一步不是纠结“API 怎么像网页版一样记住”，而是补：
|
|
|
|
```text
|
|
NovelContextBuilderService
|
|
NovelMemoryCompressorService
|
|
NovelEmbedding/RetrievalService
|
|
NovelVersionSnapshot
|
|
NovelAgentRunContextSnapshot
|
|
```
|
|
|
|
一句话：
|
|
|
|
> **ChatGPT 网页版是 OpenAI 帮你做了上下文管理；
|
|
> 你接 API，就要在自己的系统里做同样的上下文管理。**
|
|
|
|
[1]: https://help.openai.com/en/articles/8590148-memory-faq?utm_source=chatgpt.com "Memory FAQ"
|
|
[2]: https://help.openai.com/en/articles/8555545-file-uploads-faq?utm_source=chatgpt.com "File Uploads FAQ"
|
|
[3]: https://help.openai.com/en/articles/11146739-how-does-reference-saved-memories-work?utm_source=chatgpt.com "How does “Reference saved memories” work?"
|
|
[4]: https://help.openai.com/en/articles/10169521-projects-in-chatgpt?utm_source=chatgpt.com "Projects in ChatGPT"
|