在 Redis Cloud 上用 LangCache 为…

适用于在 OpenAI、Anthropic 等 LLM 调用或 RAG 回答前加 cache-aside 语义缓存，减少模型调用成本与延迟，并调优命中率与精确率。

适用场景

解决思路

1. 把 LangCache 放在 LLM 调用前，采用标准 cache-aside 流程：先把用户 prompt 发送给 LangCache 的 search。
2. 如果 search 命中，直接返回已存储的 response，不再调用 LLM。
3. 如果 search 未命中，调用 LLM 生成 response，再对该 prompt 执行 set 写入 response，使后续相似 prompt 能命中。
4. 初始化 LangCache SDK：使用 server_url=f"https://{os.getenv('HOST')}"、cache_id=os.getenv("CACHE_ID")、api_key=os.getenv("API_KEY")。
5. 用 SDK 搜索和写入：result = lang_cache.search(prompt="What is Redis?", similarity_threshold=0.9)；若 result 存在，取 result[0]["response"]；否则 response = llm.generate("What is Redis?")，再 lang_cache.set(prompt="What is Redis?", response=response)。
6. 没有 SDK 可用时改用 REST：搜索用 POST /v1/caches/{cacheId}/entries/search，写入用 POST /v1/caches/{cacheId}/entries。
7. 调 similarity_threshold：该阈值控制新 prompt 与已缓存 prompt 的 embedding 余弦距离需要多接近才算命中；越高越严格、假阳性越少，越低命中越多、越可能返回离题答案。
8. 将 similarity_threshold 设为 0.95+，以要求近乎精确匹配；用于错误响应代价高的面向用户回答。
9. 将 similarity_threshold 设为 0.9，作为大多数工作负载的平衡默认值，并从这里开始调优。
10. 将 similarity_threshold 设为 0.8，以允许宽松语义匹配；用于内部工具、探索式查询、FAQ 去重。
11. 通过观察实际 cache-hit rate，并抽查返回答案是否仍然相关，来调整 similarity_threshold。
12. 按任务类型拆分缓存：为不同 LLM 工作负载创建不同的 cache_id，并把每次调用路由到正确缓存；不要让 code 问题与密码重置支持查询等不同任务共享同一个缓存，否则会交叉返回无关答案。
13. 在 Redis Cloud 中为每个任务创建独立 cache ID，并在代码中分别初始化，例如 support_cache 使用 support-cache-id，code_cache 使用 code-cache-id。
14. 作为更细粒度的替代方案，用 custom attributes 存储和搜索（如 {"category":"database"}），让任务留在同一个缓存中但通过属性过滤隔离；适用于同一 prompt 格式跨越多个子主题的情况。
15. 查看 references/langcache-usage.md 获取完整 SDK 与 REST 示例及基于属性的存储；查看 references/best-practices.md 获取最佳实践；参考 https://redis.io/docs/latest/develop/ai/langcache/。

适用边界 · 注意事项

• 没有 Redis Cloud LangCache 访问权限（server_url、cache_id、api_key）时不能使用；该技能依赖 Redis Cloud 的 LangCache 服务，且 LangCache 目前处于 preview，功能和行为可能变化。
• 不要把不同任务类型直接塞进同一个缓存且不用 custom attributes 隔离，否则会返回语义相近但任务无关的答案。
• 在错误响应代价极高且无法通过高阈值控制风险时，不要使用 0.8 这类宽松阈值。