缓存、延迟与成本

本节目标

建立一个先测量、再优化的方法，理解前缀缓存、精确答案缓存和语义缓存的命中条件与风险。

优化前先定义用户任务与质量底线。将任务换成更便宜的模型而导致返工或人工介入，可能让单次API成本下降、端到端成本上升。

总延迟
= 排队 + 网关 + 检索 + 模型首token
+ 模型生成 + 工具循环 + 后处理 + 重试

这是诊断分解，不要把它当成所有架构的固定公式。先从Trace找最大或最不稳定的部分。如果等待主要来自一个慢工具，只缩短Prompt不会解决问题。

它重用相同输入前缀的中间计算，通常不是直接重用最终答案。提高命中率的通用思路是将稳定指令与示例放在前面，用户变量放在后面。但具体最小token、计费、保留时间和显式缓存参数都是供应商动态特性，不应把教程数值写死在架构里。

当规范化后请求完全相同时返回已保存答案。键必须包含会改变输出的所有版本，例如：

hash(租户 + 权限 + 规范化输入 + release_id
     + 知识快照 + 语言 + 安全策略)

忽略租户或权限可能跨用户泄露数据；忽略知识快照会长期返回过期规定。缓存值还需经过与正常输出相同的安全处理。

它对请求做Embedding，在相似度足够高时重用过去答案。这会把“字面相似”变成“业务上可互换”的决策，风险远高于普通前缀缓存。“如何取消订单”和“如何取消已发货订单”可能向量相似，但规则不同。它必须在任务级回归集、权限分区、知识过期和不确定时回退上单独验证。

对每个任务记录：输入、缓存读/写、输出token，模型和工具调用次数，重试次数，计费策略版本与项目/用户归属。价格表应带生效时间或版本，不要用当今价格回算历史请求后声称它是当时实际费用。

优化顺序通常从“减少无价值工作”开始：不调用就能解决、不重复检索、限制无界Agent循环、避免重试风暴，再考虑缩短Prompt、选更小模型或批处理。任何改动都要回到相同评测集。

为“内部制度问答”设计缓存键和失效规则，要求制度每周更新且不同部门权限不同。然后回答：

缓存与路由是质量、成本、时效和隐私的共同决策。下一步用 Trace与隐私边界获得足够细、但又不过度收集的证据。