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