Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
需要。全留会慢、贵，而且旧信息可能干扰当前状态。
长上下文更像大桌子，不是自动整理桌子。东西全摊开，模型也会拿错。
历史消息分三类：当前有效事实、已解决过程、闲聊噪声。长上下文不该让这三类平权。
摘要不是为了“塞不下”才做，也是为了让模型看见当前状态。
我们把最近 6 轮原文保留，早期历史压成状态。投诉场景再额外保留关键原话。
用户情绪会不会被摘要磨掉？
会，所以情绪要结构化保留，比如“用户对重复解释不耐烦”。必要时保留原句。
成本也明显。长上下文模型每轮带全历史，用户多聊几次账单很快上去。
那摘要错了怎么办？
保留来源轮次，必要时回查原文。摘要更新做校验，不让模型凭空加事实。
还有隐私。全历史里可能有身份证、手机号，后续问题不需要就别反复发送。
我以为长上下文能省掉记忆系统，看来还是要做。
是的，长上下文降低了截断压力，但没有替代会话状态。
真正省事的是清晰状态，不是更大的窗口。
你好！看起来您对这段对话很感兴趣，但您还没有一个账号。
厌倦了每次访问都刷到同样的帖子？您注册账号后，您每次返回时都能精准定位到您上次浏览的位置，并可选择接收新回复通知（通过邮件或推送通知）。您还能收藏书签、为帖子顶，向社区成员表达您的欣赏。
有了你的建议，这篇帖子会更精彩哦 💗
