直接回答
端侧 AI 结果缓存是一层复用派生输出的机制，不是用户曾经提出或批准内容的永久档案。它只有在当前请求按明确策略与旧请求等价时，才应该避免重复计算。缓存命中表示应用定义的键和新鲜度规则匹配；这并不能证明答案正确、安全，或现在仍适合用户使用。持久会话历史和结果溯源应保存在各自的数据记录中，缓存本身应允许被丢弃。 有效缓存键要包含所有会改变含义的输入：规范化源内容或稳定来源修订、任务标识、语言方向、相关设置、模型制品修订、分词器或模板修订、提示词版本、解析器/schema 版本和输出格式。不要把原始敏感文字放进可见键或日志。带密钥摘要可能减少暴露，但仍需威胁模型和冲突处理。如果应用无法可靠识别来源修订，就应禁用该情形下的复用，或询问用户，而不是把不完整键当作相同请求。 身份匹配与新鲜度要分开。键回答请求属于哪个等价范围；过期或失效策略决定过去保存的输出此刻是否仍可复用。源内容被编辑、模型或提示词改变、解析器修复、任务设置变化、源记录删除、同意撤销，都是明确的失效事件。TTL 可以限定复用时间，但短期限无法补救遗漏了关键输入的缓存键。如果任务依赖快速变化的上下文，即使文本相同也可能不适合缓存。 只缓存已完整结束、通过结构校验和任务验收的输出。超时、解析失败、已取消生成、部分流式结果或通用错误，不应伪装成成功答案写入缓存。若流程要求用户审核，要保留待审核状态；未经审核的生成结果不能满足一个要求用户确认的工作流。缓存记录可以保留“需审核”状态，但缓存命中不能悄悄把它升级成“已批准”。 把缓存结果视为派生用户数据。明确保存位置、是否备份、保留期限、源记录删除时如何联动删除，以及导出是否包括缓存。尽量减少保存字段，不要把源文字复制进诊断元数据。本地推理不能证明应用没有其他网络请求，应用内缓存也不会自动继承 HTTP 缓存的隐私语义。存储和网络路径应分别审核。 并发请求也要有明确定义。两个相同请求同时到达时，协调器可以共享一个进行中的任务、排队，或各自执行；但不应持久化重复条目，也不能把不同键的结果串错。安全诊断可记录键版本和缓存决策。缓存 schema 改版时应明确迁移或失效旧条目，不能用新语义重新解释旧结果。 设计有上限的清理，并让未命中原因可区分。在影响用户流程时，应能辨别条目已过期、失效、被容量回收、当前不可用或从未缓存。容量淘汰属于存储策略，不代表结果已经过时。只在条目能服务其定义用途期间保留它；源记录删除或用户重置时，也应清除相关派生结果。测试要覆盖键变化、失效触发、过期、失败、并发和删除，但不要据此发布没有依据的准确率或性能结论。
用户编辑文字后再次请求本地摘要
笔记应用提供本地摘要功能。用户先运行一次，随后编辑两句话并改变输出风格，再次点击生成。团队希望在安全时复用已完成工作，但不能把旧摘要显示成描述了修改后的笔记，或满足新的输出要求。
决策
将来源修订和所有会改变含义的任务配置纳入复用键；笔记变化时失效；显示返回结果是否来自缓存以及是否仍需审核。
预期结果
第二次请求不会复用旧修订笔记的摘要。完全等价的请求可在既定期限内复用有效条目，但不能仅因它来自缓存就宣称准确。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- PRIVACY-01：本地推理不能证明应用的所有其他数据路径都没有网络请求。
- COVE-MODEL-02：当前模型配置的 SHA-256 字段为空，不能把配置描述说成制品已验证。
设备兼容结论须绑定具体设备、系统、模型、运行时、后端和工作负载，不能靠参数量推测。
实施流程
The cache key schema, the source and artifact references, and the deletion and rebuild tests form a single comparative record. These evidence items should be documented together so that a rebuilt entry can be matched against the original on the same key, source, artifact, and prompt basis, and any mismatch in the recorded values can be identified directly from that comparison without extending the scope. (62 words)
- 定义何时算同一个请求. 列出来源身份和修订、任务、语言方向、设置、模型制品、提示词/模板、解析器/schema、输出格式及改变含义的用户上下文。必要因素未知时，对该情形禁用复用。
- 构造注意隐私且有版本的键. 对选定字段进行确定性序列化，并加入键 schema 版本。不要将原始文字写进键或日志；若用摘要，应规定输入编码、冲突处理及摘要是否可能泄露容易猜到的输入。
- 分别制定新鲜度和失效规则. 按任务选择期限，并逐项列出源文编辑、模型或提示词升级、解析器变化、源删除或同意撤销等失效事件。不要用过期时间替代漏掉的键字段。
- 只持久化符合条件的完成结果. 只有生成结束且通过结构和任务验收后才写入成功缓存。取消、部分结果、超时和格式错误不得作为成功结果保存；若流程需要人工判断，保留待审核状态。
- 协调重复请求并执行清理. 决定等价进行中请求是合并、排队还是独立执行，并确保每个结果仍绑定准确的键。限制容量；源删除或用户重置时移除条目；将容量淘汰与语义失效分别记录。
- 测试复用边界并解释结果. 使用夹具一次改变一个键字段，再验证期限、内容编辑、模型/提示词/解析器变化、失败、并发、删除和重启。缓存决定影响用户信任时应能解释，但不能把它描述为正确性保证。
验收标准
- 缓存键包括文档列出的所有会改变任务含义的输入，并带有明确 schema 版本。
- 过期、失效、失败、部分或待审核输出不会被静默复用成已批准的成功结果。
- 源删除、用户重置、容量淘汰和相同请求并发行为分别定义并通过测试；诊断不会暴露原始输入内容。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 持久结果历史 | 保留带模型和提示词溯源的历史输出 | 回答过去生成过什么以及何时生成；不决定该结果能否满足新的请求。 |
| 结果缓存 | 完整键和新鲜度策略匹配时复用输出 | 减少等价任务重复工作；条目可过期、失效、淘汰或删除，也不能证明内容正确。 |
| 每次都重新生成 | 所有请求都重新执行所选任务 | 避免旧缓存复用，但会重复工作；仍需处理失败、审核、隐私和历史记录。 |
需要避免的失败模式
- 缓存键遗漏会改变含义的输入
- 将过期时间当作完整身份键的替代品
- 把取消、部分或未审核结果当成已批准答案
Caching without provenance, and keeping results after source deletion, undermine the integrity of the recorded evidence and must be avoided. Release wording describing this fact card should rely solely on what has been documented, and the cache entries referenced under the privacy and coverage fact-card boundaries should be described only through the recorded schema, references, and tests. (57 words)
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
缓存命中是否意味着生成答案正确？
不是。它只表示条目符合应用定义的缓存键和新鲜度规则。正确性仍取决于任务、输出校验和必要的用户审核；命中本身不提供额外质量证据。
设置 TTL 就足以保证缓存键安全吗？
不够。过期只限制条目可复用的时间，不能弥补遗漏来源修订、提示词、模型、解析器、语种方向或其他关键输入的缓存键。
为避免重试循环，应该缓存失败或取消的生成吗？
不要把它们存成成功结果。需要时可以单独留存失败分类和重试策略，但后续有效请求必须仍能运行并创建自己的结果。