AI INFRA

Redis：转型 AI 数据库

向量搜索、语义缓存和新的 Agent 记忆层——不需要第二个数据库。

admin

• 10 min read
Redis：转型 AI 数据库
梯形图转SCL | 博途AI辅助编程文档 | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

Redis 团队在 2026 年的预测中直言不讳："没有上下文引擎的 AI 应用注定会失败。" 然后他们花了一年时间确保 Redis 就是那个上下文引擎。

到现在，这种转变已经不可能被忽视了。向量搜索、原生向量数据类型、完全托管的语义缓存以及专为 AI 代理设计的专用上下文引擎，都已经进入了许多团队已经用于会话存储等无聊任务的数据库中。以下是实际发生的变化，以及是否值得关注。

1、Redis 为什么要费心做 AI

在深入探讨 Redis 构建了什么之前，值得问一下为什么。传统的后端系统对其数据层有一个要求：速度。快速读取、快速写入、低延迟。Redis 作为内存数据库，在这方面已经做得和软件一样好了。

AI 应用程序对其数据层的需求完全不同：

  • 存储向量并运行相似性搜索的地方
  • 管理对话上下文和代理记忆的方法
  • 缓存模型推理结果的地方，这样你就不会为同一个答案支付两次费用

仔细看看这个列表，它几乎与 Redis 已经擅长的完全一致：内存优先、亚毫秒延迟，以及真正广泛的数据结构。

简而言之：Redis 在这里不是在追逐 AI 趋势——它是在将其实际优势指向 AI 的实际瓶颈，即数据基础设施，而不是模型质量。

2、四件套 AI 技术栈

到 2026 年，Redis 已经远远超越了"缓存中间件"，进入了更接近完整 AI 数据基础设施的领域，由四个协同工作的部分组成。

2.1 向量搜索

Redis 现在在功能上是一个向量数据库——这是四个功能中最基础的。

经典的 Redis 查询是精确匹配：给它一个键，返回一个值。AI 工作负载大多不问精确匹配的问题：

  • 用户问*"我如何退货？"* 你需要的是语义最接近的 FAQ，而不是拼写最接近的
  • 推荐引擎需要与某人正在查看的产品**"最相似"**的产品
  • 欺诈系统需要与当前交易**"最相似"**的历史模式

这些都无法用精确匹配解决。它需要向量相似性搜索。

工作原理

Redis 查询引擎（以前的 RediSearch 模块）将高维向量存储在 Hash 或 JSON 结构中，并在其上构建向量索引。

支持的索引算法：

  • FLAT — 暴力搜索。精确、慢，适合小数据集（10 万条以下）
  • HNSW — 近似最近邻。快速查询，生产中的默认选择
  • SVS-VAMANA — Redis 8.4 中的新功能，针对大规模数据集进行了优化

支持的距离度量：余弦相似度（最常见，适合文本嵌入）、欧几里得距离和点积。

混合查询——Redis 真正的差异化因素

Redis 向量搜索最强的论点不是原始速度——而是向量相似性和普通过滤器可以在同一个查询中运行。

# 在 category = "database" 的文档中，找到 5 个最相似的
FT.SEARCH doc_idx "(@category:{database})=>[KNN 5 @embedding $query_vec AS score]"
    PARAMS 2 query_vec <query_vector>
    SORTBY score
    DIALECT 2

这在生产中非常有用。在电子商务推荐流程中，先按类别过滤，然后按相似度排序，可以防止推荐严重超出类别的内容，仅仅因为嵌入恰好很接近。

实际应用：Java

在 Spring AI 中，这通过 RedisVectorStore 暴露：

// 创建 RedisVectorStore
RedisVectorStore vectorStore = RedisVectorStore.builder(jedisPooled, embeddingModel)
    .indexName("doc_idx")
    .prefix("doc:")
    .build();

// 添加文档向量
List<Document> documents = ...
vectorStore.add(documents);

// 运行相似性搜索
List<Document> results = vectorStore.similaritySearch(
    SearchRequest.builder()
        .query("Redis 向量搜索")
        .topK(5)
        .build()
);

Redis 还提供了 RedisVL for Java，一个专门为 AI 原生应用程序构建的客户端：

// RedisVL for Java — 更底层的向量操作
VectorQuery query = VectorQuery.builder()
    .vector(embedding)
    .topK(10)
    .build();
List<SearchResult> results = vectorStore.search(query);

2.2 向量集

Redis 8 引入了新东西：一等向量数据类型，而不是附加到现有结构上的向量索引。

向量集有两个核心命令：

  • VADD — 向向量集添加向量
  • VSIM — 查找与给定向量最相似的现有元素
# 创建一个向量集并添加向量，然后查询它
VSIM my_vectors <query_vector> COUNT 10

Redis 8.8 更进一步，优化了向量存储的内存效率——新的浮点精度控制选项可以将内存使用量减少高达 92%。对于任何在真实规模上运行向量搜索的团队来说，这不是一个小调整；这是一个有意义的更小的基础设施账单。

2.3 语义缓存

节省 token。减少延迟。实际上两者兼有。

LLM 使用中最大的成本驱动因素是 token——每次调用都要花钱，每次调用的延迟取决于你无法控制的网络条件和推理速度。

Redis 的答案是 LangCache，一个完全托管的语义缓存。它不是通过精确键匹配进行缓存，而是将向量嵌入与缓存的 LLM 响应一起存储，当新查询与它已经回答过的查询足够相似时，就提供缓存命中。

Redis 发布的基准测试数字：

  • 通过消除冗余 LLM 调用节省高达 70% 的成本
  • 缓存命中时响应速度快 15 倍
  • 比从头开始构建自己的语义缓存更快设置

想象一个客服机器人一遍又一遍地处理*"我如何退货？"* 和*"什么时候发货？"*，每次措辞略有不同。第一个用户触发真正的 LLM 调用。之后的每个类似问题都只命中缓存。

2.4 Redis Iris

AI 代理的上下文引擎——用 Redis 自己的话说，这是他们今年在 AI 领域发布的最重要的东西。

为什么代理需要上下文引擎

Redis 团队在自己的博客中很好地阐述了这个问题："代理的问题通常不是缺乏智能——而是缺乏上下文。"

处理任务的代理需要跨系统、会话和时间进行访问：坐在 CRM 中的客户数据、隐藏在文档存储中的知识、存在于实时事件流中的状态。在每一步从头开始重新加载和重新拼接所有这些，代理会可靠地在任何超过几轮的任务中失去线索。

Redis Iris 实际上是什么

2026 年 5 月，Redis 发布了 Redis Iris — 一个专门为 AI 代理构建的上下文引擎，作为代理和它需要读取的所有内容之间的层。它由五个核心部分组成：

  • Redis Context Retriever — 使外部数据源可被代理查询
  • Redis Agent Memory — 跨工作流和会话的记忆管理
  • Redis Data Integration — 实时数据集成
  • Redis LangCache — 上面描述的语义缓存
  • Redis Search — 向量搜索
代理记忆的两层设计

Redis Agent Memory 通过有意设计的两层结构管理代理的状态：

  • 短期记忆 — 当前会话的上下文：对话历史、临时状态
  • 长期记忆 — 跨会话持久化：用户偏好、历史事实、知识图谱

这就是只记得你上一条消息的代理和也记得你上周提到喜欢极简美学的代理之间的区别。

在 Java 中，你可以使用 Lettuce 和 DJL（用于 PyTorch）构建一个 Redis 支持的代理记忆层：

// 通过 Lettuce 的 Redis Agent Memory
// 工作记忆存在于 Hash 中
// 长期记忆存在于 JSON 中，由向量索引支持
// 事件历史存在于 Stream 中
这到底有多快？

以下是 Redis 发布的主要性能数字：

Redis 8.8 GA 在这些数字的基础上带来了进一步的性能提升和更低的基础设施占用空间。

3、整个管道，一张图

真正好的地方

难以反驳的性能。 每秒 66,000 次向量插入，搜索十亿向量的中位数延迟 200 毫秒，整体亚毫秒延迟——AI 应用程序对延迟极其敏感，Redis 的内存架构非常适合。

真正完整的 AI 数据栈。 向量搜索、语义缓存、代理记忆、上下文引擎——几乎 AI 应用程序数据层需要的一切，都在一个系统中。

没有新的技术栈需要学习。 如果你的团队已经在运行 Redis，就不需要引入、学习和操作单独的向量数据库。

真正的混合查询支持。 将向量相似性与普通过滤器相结合在生产中非常有用，而不仅仅是演示技巧。

成本数字是真实的。 语义缓存将 LLM 成本降低高达 70%，向量存储将内存降低高达 92%——这两种节省都会出现在基础设施账单上。

周围有成熟的生态系统。 RedisVL for Java、Spring AI 集成、LangChain/LangGraph 集成——客户端库已经很好地构建了。

不好的地方

向量搜索仍然不是专用的向量数据库。 Redis 的向量功能是分层在现有系统之上的，而不是从头开始设计的。在极端规模（数百亿向量）或复杂的索引策略下，像 Milvus 这样的专用系统可能仍然具有优势。

内存成本很高。 Redis 8.8 显著提高了内存效率，但向量数据仍然完全存在于 RAM 中，无论编码多么高效，它都比磁盘支持的向量存储更贵。

Redis Stack 已弃用。 RediSearch 已被合并到 Redis 8 核心中，从长远来看是好消息——但从旧模块迁移需要实际的工作。

4、结束语

回到这一切开始的问题：Redis 到底在这里为 AI 做了什么？

不是"在 Redis 上附加的 AI 功能。"整个数据库被重新定位为 AI 应用程序基础设施。 Redis 7.4 中的原生向量搜索、Redis 8 中的向量集、Redis 8.8 中 92% 的内存削减、LangCache 带来的 70% 成本削减，以及现在 Redis Iris 中完整的代理上下文引擎——这不再是过去那个只做缓存的中间件了。

对于一个已经在运行 Redis 的 Java 团队来说，这归结为一个简单的事实：你获得了 AI 应用程序所需的数据层，而无需在技术栈中添加第二个数据库。

原文链接：Redis Just Became a Full AI Database

汇智网翻译整理，转载请标明出处