Redis语义缓存减少重复模型请求

Redis语义缓存可以把含义相近的问题映射到已有答案，从而减少重复模型请求。要让这种复用可靠，必须先限定租户、知识版本、提示词和模型配置，再在这个范围内按向量距离检索；没有合格答案才调用模型。相似度高只说明表达接近，不能证明答案适用于当前请求。

本文以公开产品说明问答为例，给出接入骨架和指标计算方法。文中的数值是演算条件，没有声称已经完成线上压测。

RedisVL官方使用说明：https://redis.io/docs/latest/develop/ai/redisvl/user_guide/how_to_guides/llmcache/

先记录请求基线与可复用范围

先观察未接缓存时的模型请求数、输入输出用量、端到端P50/P95延迟，以及失败和重试次数。按“逻辑请求”与“实际模型调用”分别计数，避免一次重试被误当作两个用户问题。生成式回答的费用还会受输出长度影响，调用数下降比例不能直接等同于费用下降比例。

适合先试的是上下文稳定的说明类问答，例如“样品申请要提交哪些信息”和“申请样品需要准备什么资料”。相反，“是否支持退款”和“是否不支持退款”虽然共享大量词语，答案约束可能相反；金额、地区、产品型号和否定词都应纳入反例样本。订单状态、个人账户余额等请求不应混入这个公开说明缓存。

应用需要先决定缓存资格。本例只接受已经归类为公开说明的问题，不自动缓存所有模型输出，也不把一次回答合格与否交给距离阈值决定。

把缓存对象与隔离条件分开

原始问题用于生成问题向量，缓存答案保留可复用正文。租户范围、知识版本、提示词版本、模型配置是另外一组复用条件。即使两条问题向量非常接近，只要其中一项条件不同，也应在不同范围里检索。模型配置标识需要覆盖真正影响回答的配置变化，而非只放一个厂商名称。

把隔离条件仅写进metadata作为备注，不等于检索自动受限。这里把四项条件建为可过滤字段，写入时保存filters，读取时显式传入filter_expression。授权范围由服务端构造；搜索过滤不能代替数据库账号权限和应用授权。

用RedisVL接入受控查询与写入

准备支持RedisVL所需搜索与向量能力的Redis部署，再在独立环境安装并锁定与项目匹配的redisvl及向量化依赖。仅能执行GET/SET不能说明具备向量索引能力。下面是应用接入片段，构造cache后再把它注入业务函数；示例不包含模型服务凭据或完整服务启动代码。

import os
from redisvl.extensions.cache.llm import SemanticCache
from redisvl.utils.vectorize import HFTextVectorizer

# 连接信息由运行环境注入；模型权重需提前部署，版本在项目依赖中锁定。
cache = SemanticCache(
    name="support_semantic_v1",
    redis_url=os.environ["REDIS_URL"],
    vectorizer=HFTextVectorizer(model="redis/langcache-embed-v2"),
    distance_threshold=0.08,
    ttl=600,
    refresh_ttl_on_hit=False,
    filterable_fields=[
        {"name": name, "type": "tag"}
        for name in ("tenant", "kb", "policy", "model")
    ],
)
# 示例限定公开产品说明问答；scope内容应取自服务端真实发布版本。
scope = {
    "tenant": "demo", "kb": "manual-v3",
    "policy": "support-v2", "model": "answer-config-v1",
}

这里的600秒和0.08都只是起始试验值。RedisVL SemanticCache使用COSINE距离，数值更低表示匹配更严格；不是“0.08即92%正确率”。距离阈值要用该嵌入模型和本业务的正反例来选择，不能照搬其他模型的结果。更换向量化模型时要使用与新模型匹配的独立索引，不能把维度相同视为向量空间相同。

import logging
from redisvl.query.filter import Tag

log = logging.getLogger(__name__)

def answer_with_cache(cache, prompt, scope, generate):
    # scope由服务端授权上下文提供，不能直接相信客户端传入的租户。
    where = (
        (Tag("tenant") == scope["tenant"])
        & (Tag("kb") == scope["kb"])
        & (Tag("policy") == scope["policy"])
        & (Tag("model") == scope["model"])
    )
    try:
        hits = cache.check(
            prompt=prompt, filter_expression=where,
            return_fields=["response"], num_results=1
        )
    except Exception:
        # 示例在缓存层故障时降级；生产应分类计数并限制模型并发。
        log.warning("语义缓存查询失败，转为模型请求")
        hits = []
    if hits:
        return hits[0]["response"], "cache"

    # generate是应用注入的模型调用函数；失败时向上传递，不写入错误答案。
    response = generate(prompt)
    if not isinstance(response, str) or not response.strip():
        raise ValueError("模型未返回可缓存正文")
    try:
        cache.store(prompt=prompt, response=response, filters=scope)
    except Exception:
        # 缓存写入失败不丢弃已经生成的答案，不记录问题和答案原文。
        log.warning("语义缓存写入失败")
    return response, "model"

调用方只有在确认问题可缓存、授权上下文已经确定后，才调用answer_with_cache。generate应封装原有模型接口、限流和超时，并由应用判断返回内容满足可缓存要求。本例只展示最小字符串检查；实际业务还应阻止拒绝回答、临时错误和未完成的流式内容进入缓存。

该函数把缓存查询故障当作未命中继续服务，但故障率必须单独计数。若缓存故障导致所有请求落到模型端，还要通过已有模型限流保护容量；不能无限并发降级。初始化失败应由服务启动或部署处理，不在每个请求里重新创建索引。

以同一请求集比较成本与错误命中

比较前固定请求集、并发、模型配置和回答长度限制。分别记录关闭缓存、冷缓存、预热缓存三种场景，不能把已预热样本的命中率当作新流量效果。阈值选择使用一组样本，最终比较使用另一组保留样本，避免只适应已知问法。

例如，演算用的1000次逻辑请求，假设原本各调用模型一次，接入后有260次有效缓存命中，其他740次各调用一次模型，且没有重试和并发重复，那么模型调用从1000次降至740次，减少26%。这是条件成立时的算术结果，不是Redis对任意业务的性能承诺。即便命中率相同，真实费用也要加上嵌入成本及Redis资源开销。

未命中请求多了一段嵌入和搜索延迟，P95可能反而变差；命中也通常仍需计算查询向量。分别保留命中和未命中的延迟分布，再观察全部请求，不能只展示最快的缓存命中时间。若错误命中超出业务允许范围，先收紧范围与阈值，不以命中率目标逼迫扩大复用。

处理过期并发与常见问题

设置TTL后，知识更新就一定立即生效吗？不会。TTL限制的是缓存条目的存活时间，知识发布应同时切换kb版本，确保新请求不再检索旧范围。本例关闭命中续期，避免高频旧答案因持续访问不断延长寿命；若部署版本不支持此选项，应按对应版本接口落实同样的过期策略。

为什么同一个问题仍会同时请求模型？查询与写入之间不是一个原子生成操作。多个并发请求都可能看到未命中。可以先为同租户、同配置、同精确问题增加应用内请求合并；跨进程合并需另行设计超时、锁持有者与失败恢复。不要把语义接近的请求随意绑在同一把锁上。

有了语义缓存，还需要精确缓存吗？两者可以配合。精确重复问题可先按完整上下文标识命中，语义层承接不同说法；两层必须共用版本和授权约束。嵌入缓存存的是文本向量，答案缓存存的是模型回答，它们节省的是不同环节。

命中率很低应先调大阈值吗？先看请求是否本来缺少复用、过滤字段是否一致、知识是否频繁变更以及索引是否适配当前向量化模型。缓存样本少时低命中是合理现象。确认这些条件后再用成对正反例调整阈值，并保留可随时绕过缓存的业务开关。

官方接口参考：https://redis.io/docs/latest/develop/ai/redisvl/api/cache/