生产级 AI 内容创作与 Demo 式生成工具的核心区别是什么？
对如今的创作者来说，单生成一张图、一段 15 秒视频并不难；难的是让同一个角色、道具、服饰、物料在不同场景中始终保持一致，让故事能够连贯发展，不必每次都从零开始。这正是 OpenArt 想要解决的问题。作为全球使用最广泛的 AI 图像和视频生成平台之一，OpenArt 已吸引包括个人爱好者、营销从业者和专业影视制作团队在内超过 800 万创作者。在产品设计上，OpenArt 聚集了包括GPT、MiniMax、 Seedance 、Gemini Omni系列、阿里Wan系列在内100多款热门模型，并通过 Character Builder（角色构建器）、One-Click Story（一键故事生成）和分镜制作工具，让创作者批量产出预告片、广告与社交媒体视频，并打造属于自己的 AI 原生 IP。而随着创作者的历史素材库持续膨胀，语义检索能力就成了支撑创作连续性的底层基础设施。为此，OpenArt 面向订阅用户上线了个人历史作品语义搜索能力，并将底层向量存储与检索体系从 Elasticsearch 全面迁移至 Zilliz Cloud。创作者只需输入角色、场景或风格描述，就能同时检索素材画面与生成提示词，快速定位可复用的历史作品。- P99 搜索延迟从 25 秒降至约 300 毫秒，搜索速度提升约 80 倍
- 约 4.56 亿个历史向量平滑迁移，无需重新计算Embedding
- 原生支持图像与提示词双向量联合检索，彻底移除自研双路 kNN 融合代码
01
素材持续积累，检索开始跟不上创作节奏
OpenArt 最初采用的是 Elasticsearch 的向量搜索能力支撑历史素材检索。在素材规模较小时，这套方案尚能满足业务需求；但当历史向量积累到数亿级别，延迟、维护与成本问题开始集中爆发。最直观的问题是检索速度急剧恶化，P99 搜索延迟达到 25 秒。Elasticsearch的原生索引生命周期管理是为日志数据设计的，因此它大约每 90 天将 OpenArt 的索引从热索引滚动到温索引，再到冷索引，最后冻结索引，导致大部分素材向量数据库最终处于冻结状态。而向量搜索的访问模式恰好与日志场景相反：Top K 排序需要对全量数据完成打分，几乎每次查询都要从冻结层跨网络拉取数据，最终导致 P99 搜索延迟高达 25 秒。第二个问题是索引数量呈指数级增长。Elasticsearch默认每 90 天至少创建一个新索引，并且不自动合并，导致单次查询需要遍历的索引数量随时间指数级增长。OpenArt 预测，随着公司的业务规模不断增长，搜索性能将在大约两年内出现暴跌。第三个问题在于不合理的成本与资源配置：OpenArt 只用到了向量搜索这一项能力，却要为Elasticsearch整套通用搜索平台付费；加上团队在未充分实测业务负载的情况下就敲定了集群规格，导致计算资源长期处于过量配置状态。第四个问题则是自研双路检索带来的长期运维负担。在 Elasticsearch 中，图像向量与文本向量无法原生联合查询，OpenArt 不得不自行实现双路 kNN 检索算法，再接入第三方组件完成结果融合与条件过滤。这部分代码并非产品核心竞争力，却要随产品迭代持续维护，占用了大量工程资源。面对不断膨胀的创作素材库，OpenArt 需要一套既能保证检索性能、又能控制成本与运维复杂度的方案，让工程团队把精力重新放回产品本身。02
Zilliz Cloud 为什么能成为OpenArt 的核心检索组件
在选型阶段，OpenArt 曾评估过 Pinecone 与 Qdrant，也有早期自行部署 Milvus 的经验。但前两者的能力并不满足OpenArt 的需求，本地化Milvus带来的部署与运维成本，又会拖慢团队的发展脚步。而 Zilliz Cloud 作为 Milvus 官方推出的全托管服务，不仅100% 兼容 Milvus API，团队既有的技术积累与客户端代码都可以直接复用，运维负担也随之大幅降低。清晰的控制台设计，甚至可以做到运维团队不看文档就能凭直觉完成相关操作。而在成本上， Zilliz Cloud 的On demand设计，也非常适配创意档案库这类业务。素材库的典型特征是数据总量持续累积，但任意时刻，只有一小部分数据会被检索。如果采用按数据量计费的方案，OpenArt 需要为全部存量素材持续付费，成本极不划算。而在On demand模式下，Zilliz Cloud 会自动按数据热度做分层调度：高频访问的热数据移入缓存，低频冷数据下沉到冷存储，OpenArt 不必在应用侧自行维护数据生命周期策略，也只需要为实际产生的检索算力付费。另外，随着数据持续入库，Zilliz Cloud 的段级自动压缩能力，还能在后台自动合并数据片段。解决了 OpenArt 此前使用ES时面临的索引无限制增长问题，确保素材库持续扩张时，检索速度不会同步衰减。成本与更放心的全托管服务之外，Zilliz Cloud带给OpenArt最大的惊喜之处在于，它彻底重构了OpenArt的完整检索链路与体验。03
OpenArt 如何利用 Zilliz Cloud重构检索体验
OpenArt 基于 Zilliz Cloud 构建了一套面向创作者个人历史作品的语义搜索服务，向符合条件的付费订阅用户开放。借助该能力，即使用户在几个月内积累了数千张图片和视频，也只需输入角色名称、画面风格或场景描述，就能按语义快速找回过去生成的内容，而不必依赖文件名、标签或创建日期。实现这一体验的难点在于，AI 生成的内容通常没有标题、标签等元数据，只有生成结果和对应的 Prompt。而这两者包含的信息并不完全相同：Prompt 记录了创作者的意图，图片或视频则反映模型实际生成的内容。因此，OpenArt 需要同时对生成内容和 Prompt 建立向量索引，才能提高历史作品的检索覆盖率和相关性。在技术架构上，OpenArt 将应用服务和主数据库部署在 Google Cloud，使用运行在 Modal Serverless GPU 上的自托管 Jina CLIP 模型生成向量，并将向量存储和检索交给 Zilliz Cloud。整套系统采用写入与读取分离的设计：写入流程随内容生成事件在后台持续运行，搜索请求则独立执行，避免向量生成和写入过程直接阻塞在线检索。在数据写入端，OpenArt 将每次生成的内容和 Prompt 分别转化为向量，写入 Zilliz Cloud。用户生成图片或视频后，系统首先将作品快照保存到 Google Cloud 的主数据库，再通过 Google Cloud Function 触发 Modal 上的 Jina CLIP 模型进行向量化。由于 Jina CLIP 能将图像和文本映射到同一向量空间，OpenArt 可以使用同一个模型分别生成内容向量和 Prompt 向量，并将它们连同生成记录 ID、用户 ID 和项目 ID 一起写入 Zilliz Cloud。对于视频，系统会提取视频中的快照帧进行向量化，因此图片和视频可以共用同一套索引与检索流程，无需额外建设视频检索Pipeline。除了实时写入，OpenArt 还运行定时回填任务，将符合订阅条件的用户此前积累的历史作品分批导入 Zilliz Cloud。这套机制也承担数据补偿功能：如果实时写入出现遗漏，后续回填任务会再次处理，确保历史内容能够被持续纳入搜索范围。在数据读取端，OpenArt 利用 Zilliz Cloud 的多向量检索能力，可以在一次请求中完成内容与 Prompt 的联合搜索。当用户输入搜索词时，系统首先通过同一个 Jina CLIP 模型将查询转化为向量，再向 Zilliz Cloud 发起一次多向量搜索，同时检索生成内容和 Prompt 两个向量字段，并根据预设权重融合相关性结果。Zilliz Cloud 在检索过程中直接应用用户 ID、项目 ID 等过滤条件，完成结果融合并返回 Top K 候选。OpenArt 随后通过 Google Cloud 上的主数据库进行最终匹配与过滤，再将结果呈现给用户。由于重度创作者的单个项目就可能包含上千个素材，一些宽泛搜索词还可能匹配数千条记录，OpenArt 每次查询需要返回超过 1,000 条候选结果，对向量检索的性能和规模提出了较高要求。最终，Zilliz Cloud 帮助 OpenArt 简化了检索架构，并将搜索响应时间控制在约 300 毫秒。此前使用 Elasticsearch 时，OpenArt 需要同时查询由索引生命周期策略创建的多个索引，再跨网络获取结果并执行自建的双路 kNN 融合逻辑。迁移到 Zilliz Cloud 后，这一过程简化为针对单个 Collection 的一次多向量检索请求，无需再自行维护复杂的结果融合代码。同时，OpenArt 将内容向量与 Prompt 向量的权重配置交由 Feature Flag 管理，可以在生产环境中灵活调整相关性策略，而不必重新开发检索逻辑。这不仅降低了系统复杂度和维护成本，也让团队能够将更多精力投入创作者搜索体验的持续优化。04
OpenArt的迁移与选型经验
最终，OpenArt从 Elasticsearch 迁出了约 4.56 亿个历史向量，整个迁移过程无需重新计算向量，团队还顺势清除了一批不再需要的记录，并修复了旧写入链路中持续引入数据问题的缺陷。而经历了两次架构迁移（早期从自部署 Milvus 迁出，本次从 Elasticsearch 迁出）之后，OpenArt 团队也总结出向量数据库选型与落地的四条核心原则：定价模型要匹配业务增长曲线。先明确计费依据，再判断自身增长最快的指标是否与计费维度重合；如果二者高度重合，业务做得越大成本压力越重，问题会随成功一同放大。存储架构要适配访问模式。不要只看功能列表，要深究底层存储设计。适合日志场景的数据降温策略，放到向量检索场景中反而会成为性能瓶颈。先测负载再配资源。在未充分摸底真实工作负载之前，不要贸然敲定集群规格，过量配置是最常见的成本浪费来源。把迁移当作数据清理的契机。所有随迁移保留的数据，都会持续产生存储与检索成本，借机清理冗余数据，轻装上阵才是最优解。05
未来规划：从历史素材检索到Agent memory
目前，Zilliz Cloud 主要服务的是 OpenArt 创作者个人历史作品的语义检索。未来，团队计划将其应用扩展到更多场景，包括共享素材与模板库的语义检索，以及进一步完善标量过滤能力，以支持更丰富的搜索需求。首先是共享素材与模板库。OpenArt 希望利用语义搜索支持团队的素材标注工作和模板推荐，让平台能够更高效地管理、检索和推荐创作资源。其次是标量过滤（Scalar Filtering）。这项能力曾在迁移过程中被暂缓推进，如今已重新进入团队的优先事项。不过，OpenArt 最感兴趣的方向是 Agent Memory。OpenArt 正在从提供独立的 AI 创作工具，转向由 AI Agent 统一协调多个工具、完成更复杂的创作任务。例如，将原本 15 秒的视频生成能力，扩展为制作 1 分钟甚至 3 分钟的完整影片。这一转变也对 Agent 的上下文记忆提出了更高要求。Agent 不仅需要协调不同的生成工具，还需要跨会话记住创作者正在处理哪个项目、正在为哪个品牌制作广告，以便在后续任务中延续此前的创作上下文，而不是每次都从头开始。这些信息的存储和语义检索，本质上依然是向量检索问题，也将是 Zilliz Cloud 下一阶段最重要的落地场景。