AI 成本优化｜用 Redis 语义缓存减少重复模型调用，先守住正确性边界

AI 成本优化｜用 Redis 语义缓存减少重复模型调用，先守住正确性边界

客服、内部知识助手和产品导购上线后，经常会遇到同一件事被不同用户换一种说法反复提问。每次都重新检索、拼接上下文并调用大模型，不仅增加 Token 成本，也让用户重复等待。Redis 官方给出的语义缓存模式，是把历史问题转换成向量，用相似度找到已验证的回答；命中时直接复用，未命中才进入完整模型链路。它比按字符串完全一致的传统缓存覆盖面更大，但也因此更需要明确的正确性边界。

语义缓存与 RAG 不是一回事

RAG 检索的是文档片段，检索结果还要作为上下文交给模型生成；语义缓存保存的是可直接返回的完整回答，目标是在命中时跳过模型调用。两者都可能使用向量检索，却承担不同责任。如果把缓存当知识库，过期回答会长期传播；如果把知识库查询误当缓存，又不会真正减少生成开销。

Redis 的参考模式会把原问题、向量、回答以及租户、语言、模型版本和安全标记等元数据放在 Hash 或 JSON 中，通过 Redis Search 做向量近邻查询，并配合 TTL 让旧结果失效。这些硬过滤条件比相似度本身更重要：两句话语义相近，不代表它们可以跨租户、跨地区或跨产品版本共用答案。

哪些问题适合缓存

稳定、重复、低个性化的请求最适合，例如公开退换规则、固定产品说明、通用操作步骤和已经人工确认的 FAQ。实时库存、账户余额、订单状态、医疗或法律建议以及需要读取当前权限的数据，不应仅凭语义相似就复用旧结果。含有时间、地点、用户身份或数量条件的问题，也要在缓存键与过滤条件中显式表达。

可以先从只读场景开始，建立允许缓存的意图白名单。回答进入缓存前记录知识版本、Prompt 版本、模型代码、温度、语言、租户和生成时间；命中时再次检查有效期与业务状态。高风险回答即使相似度很高，也应回到实时数据源或人工流程。

阈值不是越宽松越省钱

语义距离阈值过严，只有几乎相同的句子才能命中，节省有限；阈值过宽，则可能把“如何取消试用”错配成“如何取消正式合同”。正确做法是用真实问题对建立评测集，标注哪些可以共享回答、哪些必须区分，再观察不同阈值下的错误命中率与有效命中率。

不要只统计缓存命中率。更重要的指标包括错误命中率、命中后的用户追问率、人工转接率、答案版本滞后时间、节省的模型调用与新增的向量成本。对于边界样本，可以让另一套独立模型复核“两个问题是否允许共享同一答案”，但发布门槛仍要由人工标注集和线上反馈决定。

缓存失效要跟业务事件走

单纯设置固定 TTL 不足以保证正确。产品规则、知识文档、价格或模型 Prompt 更新时，应主动清理相关命名空间；租户配置改变时，只失效该租户的数据。缓存条目最好记录知识版本与内容哈希，使应用在命中后能判断依赖是否仍然有效。

还要防止缓存污染。只有通过结构校验、敏感信息检查和质量门槛的回答才能写入；用户输入、模型输出和日志中的个人信息应按数据策略处理。缓存是可重建的加速层，不应成为唯一事实来源，也不应绕开原本的权限判断。

与统一模型入口配合

AnyAIS 提供统一的模型代码、能力字段、价格与调用入口，语义缓存可以在业务层记录实际使用的模型和版本。当某个模型、Prompt 或知识库发生变化时，通过这些元数据精确划分缓存空间，而不是让不同生成条件共享结果。未命中的请求仍按统一入口调用，便于比较真实成本、时延和质量。

建议采用小流量灰度：先只记录潜在命中而不返回缓存，比较缓存答案与实时答案；确认错误命中可控后，再逐步放量。这样得到的节省不是靠冒险减少调用，而是在可验证的重复场景中复用已经确认的结果。

参考资料

• [Redis 官方：Semantic cache](https://redis.io/docs/latest/develop/use-cases/semantic-cache/)
• [RedisVL：SemanticCache API](https://redis.io/docs/latest/develop/ai/redisvl/api/cache/)

如果你正在分析多模型调用成本，可以先在 AnyAIS 查看模型价格与能力，再从最稳定的 FAQ 场景建立语义缓存评测集。