Mutable Transcripts: Mitigating Context Pollution through Editable Conversation State¶

会议: NeurIPS2026（Accepted，按提供元数据）
arXiv: 2609.31354
代码: https://github.com/QxLabIreland/ReChat
领域: LLM 其他
关键词: 可变对话记录、上下文污染、对话状态、自然语言编辑、人机交互

一句话总结¶

本文让用户用自然语言重写整段对话的历史状态，而不是继续追加纠正消息；17 人的受控研究支持其可用性，三个代表性案例显示保留记录更短，但并未证明长期任务性能或总 API 成本改善。

研究背景与动机¶

常见聊天系统把用户与助手的消息按时间累积，再将保留的历史作为下一轮生成的上下文。这适合记录交流过程，却不一定适合表示当前意图：用户先问错国家、随后修正年份，或者在方案讨论后增加预算要求，旧问题及其回答仍留在记录里。模型必须从互相冲突的历史中判断哪些条件已经失效，用户再次阅读时也要自己完成同样的判断。本文将这种仍可能影响后续回答的过时、矛盾或无关信息称为上下文污染，而不是简单归因于上下文窗口不够长。

截断、摘要和检索记忆可以改变模型看见的上下文，却通常由系统决定保留什么；用户未必能直接表达“这些历史假设现在应该被替换”。修改单条消息并生成分支则保留了不同探索路径，但没有解决在同一段持续工作的记录中，把有关联的用户消息和助手回答一起更新的问题。文档编辑器允许修改成果内容，又不完全保留聊天式交互。本文寻找的不是更强的记忆模型，而是一种保持聊天界面、同时允许用户管理当前对话状态的交互方式。

这里的张力在于：原始历史适合追溯交流过程，当前状态适合指导后续协作，两者并非同一对象。作者选择让用户显式发起修改，系统将修改传播到整个记录，而非要求用户逐条手动编辑。核心 idea：把对话记录从只能追加的交流日志变成用户可修订的状态表示，用自然语言编辑同步更新受影响的历史轮次，再以修订后的记录继续聊天。

方法详解¶

整体框架¶

原型 ReChat 维护一份包含用户和助手消息的 JSON 对话记录，并在普通聊天与历史编辑两种状态之间切换。普通聊天时，系统追加用户输入，再用完整历史生成助手回复；历史编辑时，同一输入框中的文字被解释为修改指令，模型据此输出完整的新记录。界面随后替换显示内容，后续聊天也使用新记录，而不是继续把旧记录作为有效上下文。

整个过程可归纳为“模式分流—全记录重写—状态替换”。原型的普通回复与编辑操作都使用 Gemini 2.5，界面通过 Google AI Studio 构建；架构的依赖是结构化指令跟随能力，而不是为这篇论文训练的新模型。下图描述推理时的数据流，没有训练监督分支。

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    I["当前记录 + 用户输入"] --> A["模式分流"]
    A -->|normal 普通聊天| N["追加输入<br/>生成并保留回复"]
    A -->|edit 历史编辑| B["全记录重写"]
    B --> C["状态替换"]
    N --> O["当前对话状态"]
    C --> O
    O -->|下一次输入| I

需要区分三种东西：用户实际发生过的交流、界面当前展示的记录，以及模型下一轮接收的上下文。本文主要实现的是后两者一起变更；修订后的助手回答不等于助手当时真实说过的话，修订后的用户消息也不等于原始输入。这正是它能清理过时条件的原因，也是作者承认的追溯与信任问题的来源。

关键设计¶

1. 模式分流：把继续聊天与修改历史区分开

追加式聊天无法自然区分“请回答新问题”与“请改变之前整段讨论的前提”。ReChat 在输入框旁提供“Edit History”模式选择器，激活后给出视觉提示，说明接下来的输入将被用作修订请求。用户仍然使用自然语言，不需要学习逐条消息的编辑控件。

普通聊天状态下，输入成为新的用户消息，模型根据不断累积的记录生成回复。历史编辑状态下，输入描述希望历史发生的变化，系统切换到编辑提示模板。模式选择因此决定同一段文字的作用域：它是当前轮的问题，还是针对整个历史的变换说明。

这一步不是对纠错意图的自动分类，也不是模型自行决定什么时候遗忘。用户承担了发起编辑与指定范围的责任，系统负责执行修改。低交互门槛来自保留原有聊天入口，但代价是用户必须理解自己当前处于哪种状态，否则普通问题与全局修改容易混淆。

2. 全记录重写：将修改传播到用户消息与助手回答

只改早期问题而保留旧答案，仍会留下互相冲突的上下文。编辑模式因此把完整 JSON 记录和自然语言修改指令一起交给模型，要求它生成满足指令的新记录。论文用下面的状态变换表达这一机制：

\[ T^{\prime}=f(T,e) \]

其中 \(T\) 是原始记录，\(e\) 是自然语言编辑指令，\(T^{\prime}\) 是修订记录，\(f\) 是模型执行的记录变换。这个公式表示文本状态如何变化，不是学习目标，也不意味着作者证明了修改总能保持所有事实正确。

附录 A 的编辑模板将模型设定为对话编辑器，输入按角色与文本组织历史，输出要求为 JSON 数组。模型可按指令修改、删除或添加消息，并被要求保留列表、加粗、标题、代码块等 Markdown 格式。这里的格式约束旨在避免一次历史修订同时破坏原有内容结构，论文没有给出格式保持率或 JSON 解析成功率。

这个变换覆盖三类主要操作。回溯纠正改变早期错误及其相关回答；约束注入把新条件应用到既有讨论；上下文剪枝删去已经不相关的岔题。共同点不是把最新纠正写在最后，而是让保留记录本身不再同时呈现旧条件与新条件。

例如，从某国某年的 GDP 讨论改成另一个国家、另一个年份时，早期问题和后续类别分析都应该更新。删除一段不相关讨论时，则应保留没有受影响的内容。二者都需要模型判断消息之间的关联，不能仅用关键词替换完成；全文重生成给模型提供了同时处理这些依赖关系的空间。

不过，论文展示的是这一策略的可行性，并未提供形式化的一致性检查器、编辑正确性保证或外部事实核验。新的记录可能更整洁，也可能删掉仍有价值的信息。附录 E 中的风格、语言调整等扩展同样属于记录变换的可能用途，不是额外完成的受控实验。

3. 状态替换：让编辑结果成为后续交流的有效上下文

如果修订结果只作为新的助手消息追加，旧信息仍会被发送给模型，机制就退回了普通纠错。ReChat 因此用生成的新记录替换原记录，并重新渲染聊天界面；下一轮普通聊天以修订后的记录为基础继续。这一步将“看起来改好了”与“下一轮真的使用新状态”连接起来。

界面在修改过程中提示旧轮次正在更新，完成后呈现已经修订的完整讨论。用户可以直接阅读新状态，而不是把零散的纠正消息与原回答在脑中拼接。对于已经明确目标、需要反复调整约束的任务，这种呈现方式降低了判断当前有效条件的负担。

替换当前状态也意味着它不再是一份不可变审计记录。作者没有声称原型已经实现完整版本管理、撤销、可视化差异或来源追踪；这些都是讨论与局限部分提出的改进方向。需要保留探索分支或证明原始交互经过的场景，不宜仅依赖重写后的记录。

一个完整示例¶

附录 B 的任务先要求用户询问 Ireland 在 2021 年的 GDP，再追问最大的类别。此时记录中包含两个用户问题与两个助手回答，四条消息都建立在初始国家与年份上。

普通聊天条件 A 中，用户随后追加国家纠正，再追加年份纠正；每次纠正都产生一个新的助手回答。最终记录同时包含原始问题、旧答案与后续修订，代表性分析中的对应案例保留 8 条消息、422 tokens。

历史编辑条件 B 中，用户先启用编辑模式修改国家，再次启用编辑模式修改年份。模型每次都重写已保留的问答，使当前记录围绕 Iceland 在 2022 年的讨论展开，而不是保留一连串道歉与纠正；代表性案例最后保留 4 条消息、169 tokens。

这里的 4 条消息不表示用户只进行过 4 次交互，也不表示系统仅生成过这些文本。两次编辑仍需要模型处理输入并输出新记录；表中的数量描述最终留下的上下文。GDP 示例用于解释修订传播，论文没有由此验证新生成的经济数据一定准确。

损失函数 / 训练策略¶

本文没有提出损失函数、权重微调或强化学习训练。可变的是外部 JSON 记录，不是模型参数；所谓更新对话状态，也不是把新的约束永久写入模型知识。

实际实现采取完整记录再生成，输出长度随记录规模增长。作者将结构化差异、局部修改与检索式重组列为未来优化方向，但没有对这些实现进行消融。不能把概念上的模型无关性写成已经跨模型验证的实验结论。

实验关键数据¶

主实验¶

研究采用被试内设计，17 名参与者各在两种条件下完成回溯纠正、约束注入、上下文剪枝三项任务。10 人按 A→B 顺序，7 人按 B→A 顺序；A 为普通聊天，B 为可变记录。15/17 人从事研究、数据科学或软件开发，参与自愿且无报酬。

每项任务后分别评价两种条件，量表范围为 1–7。以下是正文报告的比较方向；本地文本没有图 3 的均值、误差条数值或逐人 CSV，因此不从图注猜测精确分数。

评价维度	衡量内容	B 相对 A	正文统计报告
记录整洁度	是否仍有可能误导后续回答的过时信息	更高	\(p<0.001\)
状态清晰度	是否容易理解当前有效假设与约束	更高	\(p<0.001\)
用户信心	对后续遵守新约束的主观信心	更高	\(p<0.001\)
重启意愿	是否倾向另开对话，越低越好	更低	\(p<0.001\)
易用性	实施纠正是否容易	更高	\(p<0.001\)

作者对每个问题采用配对 t 检验，配对单位为“参与者—任务”，置信区间也围绕这些响应计算。同一个人完成三项任务，因此这些配对不能视作彼此独立的参与者样本；结果支持主观体验的早期证据，但应通过参与者层面聚合或重复测量模型进一步核验显著性稳健性。正文报告两种顺序组的方向一致，不等于完全排除了学习与迁移效应。

消融实验¶

论文没有组件移除消融。以下保留其三个代表性记录对的结构分析，不能解释成 17 人所有任务的总体平均表现。“过时 tokens”指属于后来被纠正轮次替代的用户或助手整条消息的 tokens，不是逐词判断语义是否过时；计数工具为 tiktoken。

场景	A 消息数	B 消息数	A 保留 tokens	B 保留 tokens	A 过时 tokens	A 过时占比
回溯纠正	8	4	422	169	236	56%
约束注入	6	4	608	479	353	58%
上下文剪枝	10	4	712	66	655	92%
原表均值	8	4	581	238	415	71%

原表对 B 的过时数量与占比标为破折号，而非逐项列出 0；作者文字称修订消除了过时保留上下文。原表报告平均消息数减少 50%、保留 tokens 减少 59%。正文另将 A 的平均过时占比写为 71.4%，与表格的 71% 精度不同，此处保留两种写法，不把它们改成统一数值。

这些是最终保留记录的数量，不是完整请求与生成账单。编辑仍读取全文并重生成记录，输出成本随对话长度增加；因而 59% 不能表述为 API 总 tokens 或总费用节省，tiktoken 计数也不等同于 Gemini 的实际计费统计。

作为交互需求分析，附录 C 提供了纠错习惯与功能采用意愿。下表前五项为多选，分母均为 17 名参与者，百分比不能相加为 100%。

调查项	人数	比例	解释
追加纠正消息	16	94.1%	最常见的当前纠错方式
修改旧提示后重新发送	12	70.6%	仍通过新增消息实现修订
直接编辑旧消息	6	35.3%	取决于现有界面是否支持
开启新对话	4	23.5%	通过重建上下文避免旧信息
通常不纠正	1	5.9%	少数参与者的使用习惯
愿意使用 Edit History	15	88.2%	9 人 Likely、6 人 Very Likely，来自单选采用意愿题

关键发现¶

体验改善覆盖了五个主观维度，但用户信心提升不能代替真实的长期约束遵守率或事实正确率。
三个案例的结构收益差异明显：约束注入仍需保留大量有效内容，而剪枝案例删除了占比较大的岔题。不能据此推断剪枝在一般任务上一定最优。
附录反馈同时提到更整洁、易回看与原信息丢失；用户希望有差异视图、版本历史和更明确的模式提示，说明可恢复性是清理状态的实际代价。

亮点与洞察¶

将记录与状态分开思考：一份完整日志未必是理想的工作上下文。本文的价值是让“哪些信息当前有效”成为用户可操作的对象，而不只是后台压缩策略。
修改范围包含助手回答：只改用户问题容易留下旧推论。联合更新历史问答把约束传播变成界面能力，但也必须明确这些文本是修订后的状态，而非原始交流证据。
保留聊天入口：用户通过熟悉的自然语言表达修订，模式开关承担作用域切换。这一思路可以用于写作与方案讨论中的当前假设管理，但迁移效果仍需单独评测。

局限与展望¶

样本小且技术背景集中，任务由研究者指定；不能直接外推到普通用户、长期自由探索或多用户协作。
没有与分支界面、摘要、检索记忆直接比较，也没有报告客观任务成功率、编辑准确率或长期约束遵守率。
配对统计在参与者—任务层面进行，同人响应存在相关性；当前缓存缺少逐人原始数据，无法重新分析。
完整再生成增加编辑时延与输出成本，三个记录对不能证明端到端费用下降；需要同时记录编辑和后续交互的完整开销。
自然语言编辑可能过度修改、丢失有用信息或改变表达者意图，应评估预览、撤销、版本历史与可视化差异。
可变记录增加来源追溯、问责与安全风险，原型没有解决这些问题；需要不可变审计的场景不宜仅保存修订状态。

评分¶

新颖性: 4/5。将用户主导的全记录修订明确作为聊天交互范式，概念清晰。
实验充分度: 4/5。原型、受控用户研究与案例分析相互补充，但仅支持可行性层面的结论。
写作质量: 4/5。操作与实现边界容易理解，统计独立性和计量口径仍应更明确。
价值: 4/5。为持续协作中的当前状态管理提供可复用思路，部署需要可恢复性和来源追溯机制。