Skip to main content

上下文污染

info

上下文污染是特定会话中的持续性问题。一旦聊天会话的上下文被污染，应将该会话视为可丢弃的。从干净的上下文重新开始，对于保持 Roo Code 代理的准确性和有效性至关重要。

上下文污染是指不准确或无关的数据污染了语言模型的活跃上下文，导致模型得出错误的结论、向工具提供错误信息，并在每次交互中逐渐偏离预期任务。

上下文污染的症状​

通过观察以下行为来识别上下文污染：

  • 输出质量下降： 建议变得无意义、重复或无关。
  • 工具误用： 工具调用不再符合用户的请求。
  • 编排失败： 编排器链可能出现停滞、无限循环或无法完成的情况。
  • 临时修复： 重新应用干净的提示或指令只能短暂缓解问题，之后问题会重新出现。
  • 工具使用混乱： 模型难以正确使用或回忆系统提示中定义的工具。

常见成因​

上下文污染可能由多种因素触发：

  • 模型幻觉： 模型生成错误信息片段，并随后将其视为上下文中的事实部分。
  • 代码注释： 代码库中过时、错误或模糊的注释可能被模型误解，导致其误入歧途。
  • 污染的用户输入： 复制粘贴包含隐藏或恶意控制字符的日志或文本。
  • 上下文窗口溢出： 随着会话增长，较旧的有用信息可能被推出模型有限的上下文窗口，使得"污染"数据具有更大的相对影响。

一旦错误数据进入上下文，它往往会持续存在。模型在后续推理周期中会重新评估这些被污染的信息，类似于一个永久性缺陷影响其感知，直到上下文被完全重置。

"唤醒提示"能否解决上下文污染？​

简短回答： 不能。

纠正性提示可能暂时抑制症状，但问题数据仍保留在对话缓冲区中。一旦交互偏离纠正提示的狭窄范围，模型很可能重新回到被污染的状态。

详细解释：

  • 重新注入完整的工具定义或核心指令集有时可能在初始上下文污染后的一两次交互中掩盖损害。
  • 然而，底层被污染的上下文仍然存在。任何超出即时"补丁"范围的查询或任务都可能重新触发原始问题。
  • 这种方法不可靠，类似于在漏水的管道上贴警告标签，而不是修复它。

有效的恢复策略​

要可靠地从上下文污染中恢复：

  • 硬重置会话： 最可靠的解决方案是开始新的聊天会话。这将完全清除被污染的上下文。
  • 减少手动数据转储： 粘贴日志或其他数据时要有所选择。只包含模型所需的必要信息。
  • 管理上下文窗口大小： 对于大型或复杂的任务，考虑将其分解为更小、更集中的聊天会话。这有助于确保过时或无关的信息更快地从上下文窗口中老化。
  • 验证工具输出： 如果工具返回无意义或明显错误的数据，在模型处理并将其纳入上下文之前，从聊天历史中删除该消息。

解答一个常见问题："灵丹妙药"提示​

社区中一个常见问题是：

"你是否找到了能唤醒它的提示？也许是一个只包含工具指令的提示，我们可以手动重新推送进去？"

如前所述，没有任何单一提示能提供持久的修复。任何即时改善都是表面的，因为被污染的文本行仍然存在于会话历史中，随时可能引发进一步的问题。唯一可靠的解决方案是丢弃被污染的会话，启动新会话，并从一开始就为其提供干净的提示和正确的工具定义。