Building Foundry Part 2: Where creative workflows break

构建 Foundry 第二部分：创意工作流程的断裂点 | Weaviate

构建 Foundry 第二部分：创意工作流程的断裂点

2026年8月13日

·

6分钟阅读

Shan Blackwood

Web开发人员 - 增长

Svitlana Smolianova

设计负责人

Victoria Slocum

机器学习工程师

构建 Foundry：关于创意工作流程、语义搜索和 Weaviate 的实用系列。

阅读该系列的上一篇文章：第一部分：AI 并没有取代创造力，而是消除了摩擦。

大多数创意团队已经意识到他们在搜索上浪费了时间。但更不明显的是，问题实际发生在何处。通常，问题不会从工具不佳或团队疏忽开始。相反，随着项目规模扩大，命名规范逐渐偏离，元数据质量下降，保持一切井井有条的成本最终会超过接受一定程度混乱的成本。在一段时间内，这种权衡似乎合理。但随后检索开始失效，没有人再能找到任何东西。

第一次失败：文件夹

当项目规模较小时、所有权稳定且团队成员对同一概念模型达成共识时，文件夹结构表现最佳。但创意生产很少能长期保持这种状态。

在游戏开发中，一个环境团队可能按生态系统分类资产，另一个按冲刺周期分类，第三个按引擎就绪状态分类。这三种结构在各自团队内部都有意义。但在两年的开发周期中，它们会变成同一工作成果的互不兼容的地图。在影视制作中，素材通常先按拍摄日整理，随后在剪辑阶段按场景重新整理，而视效和调色则保留各自衍生的结构。在设计团队中，客户项目、探索文件和最终导出文件往往存在于不同的系统中，彼此之间的关联较弱。

文件夹仍然重要，但随着时间推移，它们描述的是文件最终存放的位置，而非文件本身的用途。

这些失败会随时间累积 ​

这些问题中的任何一个都相对容易处理。但它们的叠加效应会逐渐显现。

项目初期通常结构清晰。但随着团队成员轮岗，供应商使用不同惯例贡献资产，命名规范逐渐偏离。标签管理因截止日期和角色不同而参差不齐。归档内容持续增长。最终团队不再拥有统一系统，而是形成了多个部分重叠的系统。此时查找素材不再依赖搜索，而是依赖社交记忆：询问可能记得的人。

这种模式无法扩展。它还导致机构知识获取的不均衡。资深成员成为隐性搜索引擎，新成员则需要花费更长时间重建已有文件中已存在的上下文。

检索需要采取不同的方式 ​

如果我们将其视为检索问题而非组织问题，需求将发生改变。

检索系统必须在命名不规范时仍能工作。必须在标签不完整时仍能工作。必须在用户能清晰描述意图但无法复现创建时使用的原始措辞时仍能工作。同时在精确约束至关重要的场景（如项目、时间范围、权利状态、交付格式或素材类型）中仍需保持精确性。

这就是现代系统结合多信号的原因：

• 语义相似性用于含义匹配
• 关键词匹配用于精确术语
• 元数据过滤用于硬性约束

这可以通过两阶段路径实现：先进行数据摄入，再执行检索。

数据摄入阶段是为未来搜索准备素材。文件被处理，生成嵌入向量，附加可用元数据。在创意工作流中，这可能包括项目标识符、文件类型、时间戳、贡献者角色、权利或授权字段，以及您已追踪的任何生产特定属性。目标是捕获足够的结构化信息和语义表示，使未来查询能通过多条路径找到正确结果。

检索阶段是整合这些路径的环节。用户可能先用自然语言搜索，再通过元数据过滤器精炼结果，最后依赖结合语义和关键词评分的混合排序。向量数据库可以按规模存储带元数据的嵌入向量，这意味着语义搜索和过滤搜索可以流畅衔接。

以Weaviate为例，我们可以摄入带嵌入向量和元数据的素材，通过向量和关键词信号进行查询，然后应用元数据约束获得生产就绪的结果。

下一步 ​

创意工作流不会因为团队混乱而中断。它们中断是因为生产系统优化了交付速度，而媒体检索系统通常优化了理想数据规范，而实际项目难以维持这种规范。

构建基于向量的检索系统是希望减少搜索耗时、避免创意工作滞留归档的团队的务实方向。

在下一篇文章中，我们将从基础开始构建：数据摄入。一个只读发现流程将扫描混乱的创意归档，将其转换为结构化清单，准备进行元数据丰富和向量嵌入。之后，我们可以将这些记录摄入Weaviate，并添加混合查询和元数据过滤。

准备开始构建？ ​

查看快速入门教程，或注册免费的Weaviate云账户。

GitHub

Forum

X (Twitter)

不想错过其他博客文章？

订阅我们的双周电子简报以保持更新！

通过提交，我同意

Terms of Service

和

.