模型上下文缓存怎样避免租户数据串用

模型上下文缓存应当按服务端确认的租户、调用主体和有效权限范围分区，不能只把提问文本或文档编号作为键。缓存命中也不能代替当前授权；权限变化、文档版本变化或租户信息缺失时，应拒绝复用旧上下文。

我更倾向于先牺牲一点命中率，把复用范围说清楚。设想两个企业都问“报销上限是多少”，问题完全相同，能看到的制度却不同。这里是设计场景，不是线上事故复盘，也没有实测收益。

先分清业务上下文缓存和模型推理缓存

本文讨论应用自己保存的、已经筛选好的上下文片段，例如某次知识检索形成的材料集合。不是厂商自动提供的 prompt cache，也不是模型服务器内部 KV cache。三者的键、权限和存储位置并不相同；应用里的租户前缀不能改变供应商的隔离行为。

如果实际接入的是供应商缓存句柄，必须按对应服务的项目、账号、缓存资源权限和保留策略实现，不能照搬这里的字典键。本文不承诺任何厂商的缓存跨租户行为。一般多租户隔离原则可参阅 OWASP 多租户安全指南。

把租户身份与权限范围放进缓存描述

租户标识必须来自验证后的身份与当前成员关系，不能直接相信请求头、提示词或模型生成的 tenant_id。同一个租户内部也可能有部门、个人文档和字段权限；只有 tenant_id 仍不够。

我会先采用主体级隔离，再考虑权限等价共享：描述里同时包含环境、租户、主体、授权版本、有效读取范围、资源版本、模板版本和模型配置标识。有效范围不是角色名，而是授权服务计算的实际文档集合及字段投影。若还受地区、目的或其他动态条件影响，也必须纳入描述，否则不复用。

用结构化序列化生成缓存键

下面是原创的纯键构造示例，不连接缓存、不调用模型，也不是完整鉴权组件。函数只接收可信上游已经生成并检查过的描述。上游必须拒绝缺失值、错误类型和不支持的动态权限条件，不能用空字符串补齐。

import hashlib
import json

def context_key(verified_descriptor):
    # 描述只来自服务端：调用前已完成当前身份、权限及资源版本判断
    encoded = json.dumps(
        verified_descriptor, sort_keys=True,
        ensure_ascii=False, separators=(",", ":"), allow_nan=False
    ).encode("utf-8")
    # 固定序列化再摘要，避免自行用分隔符拼接引入歧义
    return "ctx:v1:" + hashlib.sha256(encoded).hexdigest()

descriptor = {
    "environment": "production",
    "tenant": "tenant-a",
    "subject": "member-7",
    "authorization_revision": "rev-12",
    "scope": [
        {"resource": "policy-9", "revision": "doc-3",
         "fields": ["body", "title"]}
    ],
    "template_revision": "template-2",
    "model_config": "config-4"
}
# 示例值是虚构配置；真实范围、字段及列表顺序由授权服务确定
key = context_key(descriptor)

字段与资源集合应由上游统一排序、去重；若文档顺序本身改变上下文含义，就保留顺序，不得为了命中率擅自排序。模型配置标识必须随相关配置变化而更新。若缓存的是“查询得到的上下文”，还要加入完整查询及筛选条件，或确定的检索结果标识，不能只保存示例中的字段就缓存任意问题结果。

SHA-256 的用途是把描述转换成固定长度标识，不是加密、签名或访问授权。不要把密钥、访问令牌、原始敏感文本放进描述；普通摘要也不能防止对低熵内容猜测。实现细节见 Python hashlib 文档。

命中后仍检查租户与授权版本

缓存记录除了正文，还应保存该描述或其可比对的服务端元数据、过期时间和来源资源版本。当前请求先取得授权快照，再按快照求键；读取后确认记录的租户、主体、授权版本和资源版本与快照一致，任何缺失或不一致都按未命中处理，不把旧内容交给模型。

这不是要求信任“记录里写着 tenant-a”就够了：缓存服务本身还需要受控读写权限，防止任意调用方覆盖记录。严格撤权语义还需要授权版本读取与缓存消费之间的一致性机制；简单先读权限再读缓存存在并发变化窗口，不能据此声称撤权立即生效。

不支持隔离时退回不复用的路径

如果当前授权服务不可用，不读受保护缓存，也不把客户端给出的租户作为替代。若授权已经完成，只是缓存不可用，可以在相同租户和权限约束下重新取得上下文；失败时返回受控错误，不能回退到共享键或管理员权限。

旧格式缓存缺少身份或版本字段时，我会让它自然失效或按既定运维策略清除，不做“新键没有就读旧键”的兼容。TTL 只能限制存活时间，不能保证权限变化到过期之前的数据仍然可读。授权版本更新用于阻断旧命中，数据删除则要覆盖旧条目与相应副本，两者不是一回事。

在命中率与隔离粒度之间做取舍

对刚开始做多租户上下文复用的服务，我会先选主体级键。对有严格隔离要求的场景，还应按要求选择独立缓存实例或存储边界；命名空间不是物理隔离。命中率下降并不自动说明设计错误，先明确谁能共享，再优化复用成本。

相同角色可以共用缓存吗？

不能仅凭角色名决定。个人文档、部门范围和字段权限可能不同；没有完整等价判断时保留主体隔离。

把租户编号哈希后就不会串用了吗？

不会。哈希不能修复可信身份缺失、漏掉权限条件、错误回退路径或缓存存储权限过宽。

缓存未命中能否跳过权限检查重新生成？

不能。重新检索材料与调用模型仍受当前租户和授权约束，缓存只是复用层，不是权限来源。