跳到主要内容

3 篇博文 含有标签「data-retention」

查看所有标签

你的智能体对话记录是可被取证的,且法务从未批准过

· 阅读需 10 分钟
Tian Pan
Software Engineer

你按照每一份可观测性指南的要求对代理(agent)进行了插桩。每一个回合都有一个 span:完整的 prompt、检索到的块(chunks)、模型的思维链、它考虑过的工具调用、它起草随后又放弃的计划,以及最终的行动。存储费用是每 GB 三分钱,而在事件响应期间,这些追踪(traces)已经救了你十几次。你保留了一切,因为保留一切几乎是免费的,而且偶尔还能立大功。

这是平台团队中没人建模过的部分:那个追踪记录是用流畅的英语写成的,它点名道姓地揣测你的客户,还起草了你从未实际执行的操作。它是你公司产生的最容易被引用的制品,而原告律师会对着幻灯片上印着的你公司 Logo,向陪审团宣读其中最“精彩”的 200 个单词。让你的系统具备可调试性的推理追踪(reasoning trace),正是让它承担法律责任的推理追踪。

擦除模型仍在读取的上下文:数据保留策略带来的隐患

· 阅读需 13 分钟
Tian Pan
Software Engineer

一个每晚运行的数据留存 worker(retention worker)会删除任何超过 30 天的用户消息。一个从 3 月初开始的长周期企业支持会话,到 5 月底仍然处于活跃状态。在第 41 轮对话请求进来时,你的 Prompt 组装器(prompt assembler)从同一个消息表中读取数据,而那个留存 worker 一直在悄悄地清理这个表。第 1 到 28 轮已经消失了。模型接收到的对话是从第 29 轮开始的,没有任何信号表明之前的对话曾经存在过。用户问道:“我们之前商定的 SLA 是什么?”模型自信地编造了一个数字,因为真正的答案在第 4 轮——而留存 worker 在前一天晚上把它删除了。

这不是模型故障。模型完全按照其应有的方式运行:从交给它的上下文中生成一个看似合理的答案。故障发生在更上游,处于两个团队之间的鸿沟中——每个团队都认为自己拥有消息表。

真正信守承诺的隐私模式:在 AI 功能中构建用户可控的数据边界

· 阅读需 11 分钟
Tian Pan
Software Engineer

2026 年 3 月,一场集体诉讼指控 Perplexity 的“无痕模式”(Incognito Mode)正在将对话数据和用户标识符路由到 Meta 和 Google 的广告网络 —— 甚至对于明确激活了该功能的付费订阅者也是如此。该功能被称为“无痕”。用户认为这意味着私密。但实现方式却并非如此。

这是 AI 隐私模式中最常见的失败模式:名字是营销,实现是“留存戏剧”(retention theater)。工程师上线了一个开关。法务批准了措辞。用户按下开关并信任它。但在数据管道的某处,输入内容仍在流向日志服务、训练任务或某个没人记得拦截的第三方分析 SDK。