企业官网建设流程全解析

1. 从一条更新日志说起：Redis 接入 AI 到底改了什么

Redis 官方在 8.0 版本里正式把向量检索能力做进内核，同时配套发布了 Redis Query Engine 和 Redis Insight 的 AI 辅助功能。很多同学看到“Redis 接入 AI”第一反应是“Redis 要变成大模型了？”——不是。它做的是把 Redis 从单纯的键值缓存，扩展成一个能存向量、能算相似度、能直接给 RAG 和 AI Agent 当记忆底座的实时数据层。换句话说，以前你要做 AI 应用，向量库、缓存、会话状态得分开维护三套；现在 Redis 一个实例就能把这三件事全兜住。

我最早接触 Redis 是拿它做接口缓存和分布式锁，那会儿数据类型翻来覆去就是 String、Hash、List、Set、ZSet 五件套。后来做推荐系统，开始用 Redis 存用户画像和实时特征，但向量检索还是得靠专门的向量数据库。直到 Redis 8.0 把向量集（Vector Set）作为原生数据类型引入，我才真正意识到这个方向变了。Vector Set 不是外挂模块，是跟 String、Hash 平级的一等公民，底层用的是 HNSW 索引，支持余弦相似度、内积和欧氏距离三种度量方式。

这篇文章我打算按实际落地的顺序来讲：先拆清楚 Redis 这次接入 AI 的核心能力边界，再讲向量集和 Query Engine 的实操细节，然后是 RAG 和 AI Agent 记忆这两个最典型的场景怎么搭，最后把我踩过的坑和排查经验整理出来。不管你是刚接触 Redis 的新手，还是已经用它扛过双十一流量的老手，都能从里面找到能直接抄作业的部分。

提示：本文所有命令基于 Redis 8.0 及以上版本，低版本不支持 Vector Set 数据类型，需要先升级或使用 Redis Stack。

2. Redis 接入 AI 的核心能力拆解与选型逻辑

2.1 为什么是 Redis 而不是再搭一套向量库

做 AI 应用的人都有一个共同的痛：技术栈越堆越多。缓存用 Redis，向量检索用 Milvus 或 Qdrant，会话状态用 PostgreSQL，消息队列用 Kafka。每多一个组件，就多一份运维成本、多一个故障点、多一层网络延迟。我见过一个团队为了做一个客服机器人，光中间件就部署了七种，结果联调阶段一半时间在排查组件之间的连接问题。

Redis 接入 AI 的核心逻辑就是收敛技术栈。它把向量检索、全文检索、JSON 文档存储、缓存、消息流全部放在一个进程里。你不需要在缓存和向量库之间做数据同步，因为它们是同一份数据。用户会话存在 Hash 里，对应的语义向量存在 Vector Set 里，检索的时候一个命令就能同时拿到结构化字段和相似度分数。

从性能角度看，Redis 本身就是内存数据库，向量检索走的是内存中的 HNSW 图索引，延迟天然比磁盘型向量库低一个数量级。我实测过一个 10 万条 768 维向量的数据集，Redis Vector Set 的 Top-10 检索 P99 延迟在 2ms 以内，同样的数据放到磁盘型向量库里大概在 15-30ms。对于需要实时响应的 AI Agent 场景，这个差距直接决定了用户体验。

从成本角度看，如果你的业务本来就在用 Redis 做缓存，那接入向量检索的边际成本几乎为零。不需要额外采购向量数据库的 license，不需要额外的服务器，只需要把 Redis 版本升到 8.0 并预留足够的内存空间。对于中小团队来说，这个账算下来非常划算。

2.2 Vector Set 与 Query Engine 的分工

Redis 这次接入 AI 的能力分两层，很多人容易搞混，我先把边界划清楚。

Vector Set是数据类型层面的能力。你可以把它理解为一个专门存向量的有序集合，每个向量有一个唯一的成员名，支持添加、删除、查询相似向量。它的命令前缀是VADD、VREM、VSIM、VDIM、VCARD这几个。Vector Set 适合场景简单、只需要做向量相似度检索的情况，比如以图搜图、语义去重、推荐召回。

Redis Query Engine是索引和查询层面的能力。它支持在 Hash 和 JSON 文档上建二级索引，包括向量字段索引、全文索引、数值索引、标签索引。查询的时候可以用FT.SEARCH做混合检索——比如“找出 category 为 electronics 且向量与查询向量相似度最高的 10 条记录”。Query Engine 适合场景复杂、需要结构化过滤加向量检索的情况，比如电商商品搜索、知识库 RAG。

选型逻辑很简单：如果你的数据只有向量没有其他字段，或者过滤条件非常简单，用 Vector Set 就够了，命令直观，上手快。如果你的数据是 JSON 文档，有多个字段需要组合过滤，或者需要全文检索和向量检索混用，那就上 Query Engine。我个人的建议是，只要涉及 RAG 场景，直接用 Query Engine，因为知识库文档天然带有来源、时间、分类这些元数据，纯向量检索不够用。

2.3 与 AI 生态的对接方式

Redis 接入 AI 不只是自己内部的能力升级，它还提供了跟主流 AI 框架的对接层。官方维护了 LangChain、LlamaIndex、Semantic Kernel 等框架的 Redis 集成包，你可以直接把 Redis 当作向量存储（VectorStore）或记忆组件（Memory）传进去。

以 LangChain 为例，RedisVectorStore这个类封装了索引创建、文档写入、相似度检索的全流程。你只需要在初始化的时候传入 Redis 连接信息和索引配置，后面add_documents和similarity_search就能直接用。LlamaIndex 那边对应的是RedisVectorStore，Semantic Kernel 用的是RedisMemoryStore。这些集成包的好处是屏蔽了底层命令细节，坏处是版本兼容性需要留意——LangChain 的 Redis 集成在 0.1.x 和 0.2.x 之间有过一次比较大的 API 调整，升级的时候要看好 changelog。

如果你不想引入框架依赖，直接用redis-py客户端操作原生命令也完全可行。我后面实操部分会两种方式都给出来，你可以根据自己的项目情况选。

3. 环境搭建与 Vector Set 实操要点

3.1 安装方式选择与版本确认

Redis 8.0 的安装方式跟之前版本差不多，但有几个细节需要注意。Linux 下最省事的方式是用官方 APT 源或编译安装，Windows 下官方不直接提供安装包，需要用 WSL2 或者 Docker。我强烈建议用 Docker，跨平台一致性好，版本管理也方便。

docker run -d --name redis-ai \ -p 6379:6379 \ -v redis-data:/data \ redis:8.0 \ redis-server --appendonly yes --requirepass yourpassword

这条命令做了几件事：映射 6379 端口，挂载数据卷做持久化，开启 AOF 追加日志，设置密码。--appendonly yes这个参数在做 AI 应用时特别重要，因为向量数据重建成本很高，一旦丢失重新 embedding 要花不少钱和时间。

装完之后用redis-cli连上去，执行INFO server看版本号，确认是 8.0 以上。然后执行COMMAND DOCS VADD看有没有返回文档，如果有说明 Vector Set 命令可用。我遇到过有人装了 7.4 版本然后到处找为什么VADD报未知命令，就是版本没对上。

注意：Redis Stack 和 Redis 8.0 都支持向量能力，但命令集有细微差异。Redis Stack 用的是FT.CREATE建索引配合FT.SEARCH查询，Redis 8.0 额外提供了VADD/VSIM这套更轻量的 Vector Set 命令。选哪个取决于你的场景复杂度。

3.2 Vector Set 命令详解与参数计算

Vector Set 的核心命令就五个，但每个命令的参数都有讲究。我先给一个完整的写入和查询示例，然后逐个拆解。

# 添加向量，维度 4，成员名为 doc:1 VADD my_vectors VALUES 4 0.1 0.2 0.3 0.4 doc:1 # 批量添加 VADD my_vectors VALUES 4 0.5 0.6 0.7 0.8 doc:2 VADD my_vectors VALUES 4 0.9 0.1 0.2 0.3 doc:3 # 查询与 [0.1,0.2,0.3,0.4] 最相似的 2 个 VSIM my_vectors VALUES 4 0.1 0.2 0.3 0.4 COUNT 2 WITHSCORES

VADD的第一个参数是 key 名，VALUES后面跟维度数和具体的浮点数，最后是成员名。维度数必须跟实际向量长度一致，否则会报错。这里有个坑：Redis 不会自动帮你校验维度是否跟已有向量一致，如果你先写了 4 维的向量，后面又写 5 维的，它会直接报错拒绝写入。所以建 key 之前一定要确认好 embedding 模型的输出维度。

VSIM支持三种查询方式：按值查（VALUES）、按已存成员查（ELE）、按元素查（ELE加成员名）。COUNT指定返回数量，WITHSCORES返回相似度分数。默认用的是余弦相似度，分数范围 0 到 1，越接近 1 越相似。如果你想用内积或欧氏距离，需要在VADD的时候用DIST参数指定，但同一个 key 下所有向量必须用同一种度量方式。

关于维度选择，我补充一个实操经验。OpenAI 的text-embedding-3-small默认输出 1536 维，text-embedding-3-large是 3072 维。维度越高检索精度越好，但内存占用和计算量也越大。我做过对比测试，在 10 万条文档的知识库场景下，1536 维和 3072 维的召回率差距在 3% 左右，但内存占用差了整整一倍。所以如果你的内存预算有限，1536 维是性价比比较高的选择。如果用的是国产模型比如通义千问的 embedding，维度通常是 1024 或 1536，也够用。

3.3 内存占用估算与容量规划

向量检索是内存密集型操作，容量规划做不好很容易把 Redis 实例撑爆。我给大家一个估算公式：

单条向量内存占用 ≈ 维度数 × 4 字节 + 成员名长度 + HNSW 索引开销

HNSW 索引开销大概是原始向量数据的 1.5 到 2 倍，取决于M参数（每个节点的连接数）。M越大索引越精确但内存占用越高，默认值是 16，一般场景够用。

举个例子，10 万条 1536 维向量，单条向量数据是 1536 × 4 = 6144 字节，约 6KB。加上索引开销按 1.8 倍算，单条约 11KB。10 万条就是 1.1GB。再加上成员名、key 的元数据开销，实际占用大概 1.3GB 左右。这个量级对于一台 8GB 内存的服务器来说完全可以承受。

但如果你要做百万级甚至千万级的向量检索，内存就要认真算了。100 万条 1536 维向量大概需要 13GB 内存，1000 万条就是 130GB。这时候要么用更高维度的压缩技术（比如 PQ 量化），要么做分片集群。Redis 8.0 的 Vector Set 目前还不支持量化压缩，所以大规模场景还是得用 Query Engine 配合分片。

提示：生产环境一定要设置maxmemory和淘汰策略。向量数据建议用noeviction策略，避免被 LRU 淘汰掉导致检索结果缺失。如果内存实在紧张，可以考虑把冷数据向量放到磁盘型向量库，热数据放 Redis。

4. Query Engine 混合检索与 RAG 场景落地

4.1 建索引：字段类型与参数配置

Query Engine 的入口是FT.CREATE命令，它决定了你的数据怎么被索引、怎么被查询。我以一个知识库 RAG 场景为例，数据是 JSON 文档，包含content（正文）、source（来源）、category（分类）、embedding（向量）四个字段。

FT.CREATE idx:knowledge ON JSON PREFIX 1 kb: SCHEMA $.content AS content TEXT $.source AS source TAG $.category AS category TAG $.embedding AS embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 1536 DISTANCE_METRIC COSINE M 16 EF_CONSTRUCTION 200

这段配置里有几个关键参数需要解释。ON JSON表示索引的是 JSON 文档，PREFIX 1 kb:表示只索引 key 以kb:开头的文档。SCHEMA后面定义字段映射，$.content AS content是把 JSON 里的$.content路径映射为索引字段content。

向量字段的配置是重点。VECTOR HNSW 6表示用 HNSW 算法，后面跟 6 个参数。TYPE FLOAT32是向量数据类型，也可以用FLOAT64，但 FLOAT32 省一半内存且精度足够。DIM 1536是维度，必须跟 embedding 模型输出一致。DISTANCE_METRIC COSINE是度量方式，文本语义检索一般用余弦。M 16是 HNSW 的邻居数，EF_CONSTRUCTION 200是建索引时的搜索宽度。

EF_CONSTRUCTION这个参数值得多说一句。它控制建索引时的精度，值越大索引质量越高但建索引越慢。200 是一个比较均衡的值，如果对召回率要求极高可以调到 500，但建索引时间会翻倍。我一般用 200，实测召回率已经能到 95% 以上。

4.2 写入与检索：完整代码示例

建完索引后，用 Python 的redis-py客户端写入和检索。先装依赖：

pip install redis openai

写入部分，我封装了一个函数，把文档内容和 embedding 一起写进去：

import redis import json import numpy as np from openai import OpenAI r = redis.Redis(host='localhost', port=6379, password='yourpassword', decode_responses=True) client = OpenAI(api_key='your-api-key') def add_document(doc_id, content, source, category): # 生成 embedding resp = client.embeddings.create( model='text-embedding-3-small', input=content ) embedding = resp.data[0].embedding # 写入 Redis JSON doc = { 'content': content, 'source': source, 'category': category, 'embedding': embedding } r.json().set(f'kb:{doc_id}', '$', doc) return doc_id

这里用的是r.json().set，需要 Redis 支持 JSON 模块。Redis 8.0 默认集成了 JSON 能力，如果是 Redis Stack 也自带。写入的时候 embedding 直接以数组形式存进去，Query Engine 会自动把它转成 FLOAT32 向量。

检索部分，支持纯向量检索和混合检索两种模式：

def search_knowledge(query, top_k=5, category=None): # 生成查询向量 resp = client.embeddings.create( model='text-embedding-3-small', input=query ) query_vec = resp.data[0].embedding query_bytes = np.array(query_vec, dtype=np.float32).tobytes() # 构建查询 if category: base_query = f'(@category:{{{category}}})' else: base_query = '*' # 混合检索：结构化过滤 + 向量相似度 q = ( f'{base_query}=>[KNN {top_k} @embedding $vec AS score]' ) results = r.ft('idx:knowledge').search( q, query_params={'vec': query_bytes} ) docs = [] for doc in results.docs: docs.append({ 'id': doc.id, 'content': doc.content, 'source': doc.source, 'score': doc.score }) return docs

这段代码的核心是KNN查询语法。=>[KNN 5 @embedding $vec AS score]的意思是：在embedding字段上做 KNN 检索，返回最相似的 5 条，相似度分数命名为score。前面的(@category:{electronics})是结构化过滤条件，只有满足这个条件的文档才会进入向量检索。这种“先过滤再检索”的模式比“先检索再过滤”效率高很多，因为 HNSW 索引的搜索空间被提前缩小了。

4.3 RAG 完整链路：从文档入库到答案生成

把上面的写入和检索串起来，就是一个完整的 RAG 链路。我把它拆成四个阶段：

阶段一：文档预处理。把 PDF、Word、网页等原始文档切成 chunk，每个 chunk 控制在 500 到 1000 字。切分的时候要保留上下文重叠，一般重叠 100 到 200 字，避免语义被切断。我用的是 LangChain 的RecursiveCharacterTextSplitter，它对中文的支持还不错。

阶段二：向量化入库。对每个 chunk 调 embedding 接口生成向量，连同 chunk 内容、来源、分类一起写入 Redis。这一步的耗时主要在 embedding 接口调用上，10 万条文档大概需要几个小时。建议用批量接口，一次传多条文本，能省不少时间。

阶段三：检索召回。用户提问后，先把问题向量化，然后走上面的混合检索拿到 Top-K 相关 chunk。K 一般取 5 到 10，太少可能漏掉关键信息，太多会超出大模型的上下文窗口。

阶段四：答案生成。把召回的 chunk 拼成 prompt，加上用户问题，一起发给大模型生成答案。prompt 模板大概是这样的：

你是一个知识库助手，请根据以下参考资料回答用户问题。 如果参考资料中没有相关信息，请直接说不知道，不要编造。 参考资料： {context} 用户问题：{question}

这个链路我跑过好几个项目，实测下来检索召回率能到 90% 以上，答案准确率取决于大模型本身的能力。用 GPT-4 级别的模型，答案准确率能到 85% 左右；用 7B 级别的开源模型，大概在 70% 左右。

注意：RAG 的效果瓶颈往往不在检索，而在文档切分质量。我见过很多团队检索召回率上不去，排查半天发现是 chunk 切得太碎，一个完整的语义单元被切成三段，检索出来都是残缺信息。切分策略值得花时间调优。

5. AI Agent 记忆层与分布式锁的实战细节

5.1 用 Redis 做 Agent 的短期与长期记忆

AI Agent 跟普通聊天机器人的区别在于它有记忆。短期记忆是当前会话的上下文，长期记忆是跨会话的用户偏好和历史事实。Redis 在这两个层面都能派上用场。

短期记忆用 List 或 Stream 存会话消息，每个会话一个 key，消息按时间顺序追加。设置 TTL 让过期会话自动清理，避免内存无限增长。

def add_message(session_id, role, content): key = f'session:{session_id}:messages' message = json.dumps({'role': role, 'content': content}) r.rpush(key, message) r.expire(key, 3600) # 1 小时过期 def get_recent_messages(session_id, limit=10): key = f'session:{session_id}:messages' messages = r.lrange(key, -limit, -1) return [json.loads(m) for m in messages]

长期记忆用 Vector Set 存用户的历史事实和偏好。比如用户说过“我对花生过敏”，这条信息向量化后存进去，下次用户问“推荐一个餐厅”，Agent 先检索长期记忆，发现过敏信息，就能在推荐时避开相关餐厅。

def add_long_term_memory(user_id, fact): resp = client.embeddings.create( model='text-embedding-3-small', input=fact ) vec = resp.data[0].embedding key = f'user:{user_id}:memories' r.vadd(key, vec, fact) # 成员名直接用 fact 文本 def recall_memories(user_id, query, top_k=3): resp = client.embeddings.create( model='text-embedding-3-small', input=query ) query_vec = resp.data[0].embedding key = f'user:{user_id}:memories' return r.vsim(key, query_vec, count=top_k)

这套记忆机制的关键在于写入时机。不是每句话都值得存长期记忆，只有包含事实性信息、偏好、约束条件的句子才需要。我一般用一个轻量级分类器或者直接让大模型判断“这句话是否包含值得长期记住的信息”，避免记忆库被噪音污染。

5.2 分布式锁在 AI 任务调度中的应用

AI 应用里有很多场景需要分布式锁。比如多个 Agent 实例同时处理同一个用户请求，需要保证只有一个实例真正调用大模型接口，避免重复计费和资源浪费。再比如定时任务做向量索引重建，需要保证同一时间只有一个实例在执行。

Redis 分布式锁的标准做法是SET key value NX PX timeout，value 用唯一标识（比如 UUID），释放锁的时候用 Lua 脚本校验 value 再删除，避免误删别人的锁。

import uuid def acquire_lock(lock_name, timeout_ms=30000): token = str(uuid.uuid4()) ok = r.set(lock_name, token, nx=True, px=timeout_ms) return token if ok else None def release_lock(lock_name, token): lua = """ if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end """ r.eval(lua, 1, lock_name, token)

这里有几个坑要提醒。第一，timeout_ms要设置合理，太短会导致任务没执行完锁就过期了，太长会导致故障时锁迟迟不释放。我一般根据任务的平均执行时间乘以 3 来设置。第二，如果任务执行时间可能超过锁的超时时间，需要做锁续期（watchdog），用一个后台线程定期刷新锁的过期时间。第三，Redis 主从切换的时候锁可能丢失，如果对一致性要求极高，需要用 Redlock 算法或者干脆用 ZooKeeper。

提示：AI 任务调度场景下，我建议锁的粒度尽量细。比如按用户 ID 加锁而不是全局加锁，这样不同用户的请求可以并行处理，吞吐量能提升好几倍。

5.3 缓存治理：避免 AI 应用把 Redis 打爆

AI 应用对 Redis 的访问模式跟传统缓存不太一样。传统缓存是读多写少，AI 应用是读写都频繁，而且向量数据占内存大。如果不做治理，很容易出现内存告警。

我总结了几条治理经验。第一，区分数据生命周期。会话消息设短 TTL（1 到 24 小时），向量数据设长 TTL 或不设 TTL 但定期清理冷数据。第二，控制向量维度。能用 1024 维就不要用 3072 维，内存差三倍。第三，限制单次检索返回量。COUNT参数不要设太大，一般 10 到 20 足够，设 100 会拖慢查询还浪费带宽。第四，监控关键指标。重点看used_memory、evicted_keys、keyspace_hits、keyspace_misses这几个，evicted_keys持续大于 0 说明内存不够了，要么扩容要么清理数据。

我还建议给 AI 相关的 key 加统一前缀，比如ai:vec:、ai:session:、ai:lock:，方便用SCAN命令批量管理和监控。不要用KEYS命令做批量操作，它会阻塞 Redis 主线程，生产环境用SCAN游标遍历。

6. 常见问题排查与避坑经验实录

6.1 向量检索相关问题速查

EF_RUNTIME是查询时的搜索宽度参数，可以在VSIM或FT.SEARCH时动态指定。值越大召回率越高但越慢，默认是 10。我一般设 50 到 100，在召回率和延迟之间取平衡。

6.2 我踩过的三个坑

第一个坑：embedding 模型换了但没重建索引。项目初期用的是某国产模型的 1024 维 embedding，后来换成 OpenAI 的 1536 维，结果查询一直报维度错误。原因是旧数据的向量维度没变，新查询向量维度变了。解决办法是写一个迁移脚本，把所有文档重新 embedding 一遍。这件事的教训是：embedding 模型一旦确定，尽量不要中途更换，如果非要换，必须全量重建。

第二个坑：JSON 路径映射写错导致索引为空。FT.CREATE的时候$.embedding AS embedding这个路径必须跟实际 JSON 结构完全一致。我有一次 JSON 里 embedding 是嵌套在$.metadata.embedding下面，但索引配置写的是$.embedding，结果索引建好了但一条数据都搜不到。排查了半天才发现是路径问题。建议建完索引后用FT.INFO idx:knowledge看num_docs字段，如果是 0 说明索引没匹配到数据。

第三个坑：分布式锁超时导致任务重复执行。有个定时任务做向量索引重建，锁超时设了 30 秒，但实际执行要 2 分钟。结果第一个实例还在跑，锁就过期了，第二个实例拿到锁也开始跑，两个实例同时重建索引，把 Redis CPU 打满了。后来改成锁超时 5 分钟，并加了 watchdog 续期机制才解决。这个坑的教训是：锁超时时间一定要大于任务最大执行时间，拿不准就设长一点，配合续期机制。

6.3 性能调优的几个实操技巧

批量写入用 pipeline。逐条VADD的网络往返开销很大，用 pipeline 批量提交能提升 5 到 10 倍吞吐。Python 里用r.pipeline()上下文管理器，把多条命令攒起来一次发送。

检索时先过滤再向量搜索。Query Engine 的混合查询语法(@category:{x})=>[KNN ...]会先做结构化过滤再向量检索，比先向量检索再过滤快很多。如果你的过滤条件能大幅缩小候选集，一定要用这个语法。

合理设置 HNSW 参数。M控制索引的连通性，值越大召回率越高但内存占用越大。EF_CONSTRUCTION控制建索引精度，EF_RUNTIME控制查询精度。我的经验值是M=16、EF_CONSTRUCTION=200、EF_RUNTIME=50，这个组合在大多数场景下都能达到 95% 以上的召回率和毫秒级延迟。

用连接池管理客户端连接。AI 应用通常并发较高，每次请求新建连接开销很大。redis-py默认就有连接池，但要注意设置max_connections避免连接数过多把 Redis 的maxclients撑爆。

7. 从缓存到 AI 数据层：一个老用户的观察

Redis 这次接入 AI，本质上是从“缓存中间件”向“实时 AI 数据层”的定位升级。以前我们用它扛流量、做锁、存会话，现在它还能做向量检索、混合查询、Agent 记忆。对于已经在用 Redis 的团队来说，这意味着不需要引入新的向量数据库就能快速搭起 RAG 和 Agent 应用，试错成本极低。

但也要清醒地看到边界。Redis 的向量能力适合中小规模、低延迟、实时性要求高的场景。如果是亿级向量、离线批量检索、复杂多路召回，专业的向量数据库仍然有优势。选型的时候不要因为“Redis 能做”就硬上，要根据数据规模、延迟要求、团队运维能力综合判断。

我在实际项目里的做法是：热数据放 Redis 做实时检索，冷数据放对象存储做归档，用 Redis 的 TTL 机制自动做冷热分层。这样既享受了 Redis 的低延迟，又控制了内存成本。这套方案在几个知识库项目里跑下来，稳定性和性价比都还不错。

最后分享一个小技巧：如果你不确定该用 Vector Set 还是 Query Engine，先用 Vector Set 快速验证效果，等场景复杂了再迁移到 Query Engine。迁移成本不高，主要是把VADD换成FT.CREATE加 JSON 写入，检索逻辑从VSIM换成FT.SEARCH。先跑通再优化，比一开始就纠结架构选型要高效得多。