在 RAG 系统中配置 Redis 缓存的核心做法是将查询向量化后存储检索结果，通过语义相似度匹配复用已有缓存，从而跳过重复的向量检索和 LLM 生成流程。该方案适合查询重复率高的场景，需注意缓存失效策略以避免返回过期知识。

命令速用版

以下是 Redis 缓存配置的基础命令和 Python 代码片段，可直接用于 RAG 系统集成。

# 安装 Redis Python 客户端
pip install redis==4.5.5
pip install redis.asyncio

# 启动 Redis 服务（Linux）
redis-server `--port` 6379

# 检查 Redis 连接
redis-cli ping
# 预期返回：PONG

# Python 语义缓存示例
import redis.asyncio as aioredis
from sentence_transformers import SentenceTransformer

model = SentenceTransformer('all-MiniLM-L6-v2')
redis_client = aioredis.from_url("redis://localhost")

async def cache_query_response(query: str, response: str):
    query_vector = model.encode(query).astype(np.float32).tobytes()
    await redis_client.setex(query_vector, 3600, response)  # 缓存 1 小时

为什么会这样

Redis 能减少向量检索次数的根本原因是将语义相近的查询结果存储在内存中，避免重复计算。

RAG 系统每次收到查询时，传统流程需要依次执行 Embedding 提取、向量数据库检索、拼接 Prompt、LLM 生成。高并发场景下，Embedding 计算和向量数据库的 CPU 损耗会瞬间飙升。Redis 作为内存数据存储，具有低延迟、高吞吐量的特点，适合缓存高频查询结果和生成内容。

语义缓存设计不应仅基于原始查询字符串匹配，而应通过语义相似性判断是否可以复用已有缓存结果。将用户查询向量化后，使用近似最近邻方法在缓存中查找语义相近的历史查询，可显著减少对检索模块和生成模块的重复调用。

分步处理

按以下四个层级逐步部署 Redis 缓存，每层都有明确的检查点。

第一步：部署 Redis 服务

确保 Redis 服务已部署并可访问，推荐 6.2+ 版本。配置 Redis 连接参数时，设置合理的密码和数据库编号。

redis:
  host: localhost
  port: 6379
  password: your_secure_password
  db: 0
  cache_ttl: 86400  # 缓存默认过期时间（秒）

检查点：使用redis-cli ping确认连接正常。

第二步：实现 Embedding 缓存

Embedding 是最贵的链路，调用大模型 API 成本高且网络延迟明显。将所有 Embedding 结果用 Redis 持久化缓存，TTL 建议设置 30 天以上。

缓存 Key 的做法需要规范化，因为用户问法不同但语义一样的情况很常见。如果不规范化，缓存命中率会非常低。

第三步：实现语义缓存检索

当接收到新的用户请求时，首先将查询语义向量化，并在 Redis 中查找是否存在语义相近的缓存结果。如果存在相似查询的缓存响应，则直接返回缓存内容，跳过检索和生成流程。

async def get_cached_response(query: str):
    query_vector = model.encode(query).astype(np.float32)
    async for key in redis_client.scan_iter():
        cached_vector = np.frombuffer(key, dtype=np.float32)
        similarity = np.dot(query_vector, cached_vector) / (np.linalg.norm(query_vector) * np.linalg.norm(cached_vector))
        if similarity > 0.85:  # 设置语义相似度阈值
            return await redis_client.get(key)
    return None

检查点：相似度阈值需要根据业务场景调整，公开资料中没有看到可靠的量化数据说明最佳阈值。

第四步：配置缓存失效策略

为避免缓存过期导致的信息滞后，可采用主动更新策略。当知识库内容更新时，触发缓存清理或重新生成缓存条目。设置合理的 TTL 值可以自动清除过期缓存，确保返回结果的时效性。

async def invalidate_cache_by_query(query: str):
    query_vector = model.encode(query).astype(np.float32)
    # 清理相关缓存条目
    await redis_client.delete(query_vector)

检查点：验证知识库更新后，相关缓存是否按时失效。

怎么验证是否生效

通过以下三个维度验证 Redis 缓存是否正常工作。

缓存命中率监控：记录每次查询的缓存命中情况，计算命中率公式为命中次数/总查询次数。公开资料中没有看到可靠的量化数据说明预期命中率，需根据业务场景自行评估。

响应时间对比：对比开启缓存前后的端到端响应时间。缓存命中时应直接返回结果，跳过检索和生成流程，响应时间应明显缩短。

Redis 内存使用：使用redis-cli info memory查看内存占用情况，确保缓存数据量在可接受范围内。

常见坑

以下是实际部署中容易出错的点，需提前规避。

缓存不一致问题：动态 RAG 的最大特征是数据随时更新，如果缓存最终答案，一旦上游数据变了，会导致缓存不一致、答案错误。缓存设计应采用分层结构，区分缓存输入、缓存中间结果、缓存检索、缓存最终答案。

语义相似度阈值设置：阈值过高会导致缓存命中率低，阈值过低会返回不相关的缓存结果。需要根据业务场景测试调整，公开资料中没有看到统一的推荐值。

TTL 设置不合理：TTL 过短会导致缓存频繁失效，失去优化意义；TTL 过长会导致过期信息返回。不同业务场景需要不同的 TTL 策略。

内存溢出风险：Redis 是内存数据库，缓存数据量过大可能导致内存不足。需要设置最大内存限制和淘汰策略，如maxmemory-policy allkeys-lru。

常见问题

Redis 缓存适合所有 RAG 场景吗

不适合。Redis 缓存最适合查询重复率高的场景，如企业 FAQ、产品知识库。对于查询高度多样化、知识频繁更新的场景，缓存收益有限。

语义缓存和键值缓存有什么区别

键值缓存基于原始查询字符串精确匹配，语义缓存基于向量相似度模糊匹配。语义缓存能识别"苹果公司发布新手机"和"iPhone 15 上市"是同一件事，键值缓存不能。

缓存失效策略应该如何选择

可采用基于时间、基于事件、基于内容或混合策略。知识库更新频繁的场景建议用基于事件失效，查询模式稳定的场景可用基于时间失效。

Redis 缓存会影响答案准确性吗

可能。如果缓存过期或知识库更新后未及时清理缓存，会返回过时信息。需要配合合理的 TTL 和主动失效策略来确保时效性。

参考来源

• CSDN 博客 - 高并发大模型 RAG 系统调优：基于 Python Asyncio 与 Redis 向量多级缓存的性能突破
• 如何在 RAG 系统中使用 Redis 缓存来减少重复查询和生成任务
• 深度解密：基于 Python 的高性能 RAG 系统设计，从向量检索到缓存穿透防御
• 第 07 篇：Redis + AI 大模型：向量检索、语义缓存与 RAG 架构实战
• LangChain RAG 实战：如何用 Redis Stack 优化向量检索性能
• 动态 RAG 性能优化指南：四级缓存体系详解
• 如何解决 GraphRAG 性能瓶颈：分布式缓存 Redis 实战指南
• 企业级 RAG 系统 Golang 实战：缓存、重排序与混合检索优化
• RAG 实战指南 Day 28:RAG 系统缓存与性能优化
• 10 分钟上手 RAGFlow Redis 连接器：消息队列与缓存优化实战指南