将素材库改造为可检索创意图书馆：Foundry 第三部分

构建 Foundry 第三部分：从归档到创意检索

第一部分提出了问题。第二部分说明了随着归档（archive）不断增长，常见的工作组织方式为何会变得不再可靠。现在我们来构建解决方案。

Foundry 把已有的归档转换成一个可检索的创意库。它会扫描文件，记录扫描结果，为每个资产做好准备以便检索，并把最终结果同步到 Weaviate。文件本身不会被移动或重命名。每一条检索结果仍然可以追溯到原始来源。

creative archive
↓
read-only scanner
↓
manifest and descriptions
↓
Weaviate collection
↓
keyword, semantic, or hybrid search
↓
source asset

从我们已有的归档开始

我们的测试归档包含来自五个虚构项目的 23 个资产。其中有概念美术、设计导出文件、制作笔记、音频、视频和参考图。

文件名被故意弄得不一致：

final_FINAL_v7.svg
BROLL_NEW2.svg
scene_14_USE_THIS.svg
logo_options_FINAL3.svg
bridge_texture.svg

这种混乱是有意为之。Foundry 应该能直接用在团队现有的归档上，而不是那种永远抽不出时间去搭建的完美归档。

第一步：扫描，不改动源文件

Foundry 从一次只读扫描开始。它会遍历所选文件夹，记录每个受支持文件的信息。

npm install
npm run demo

扫描器会捕获源路径、项目、文件类型、大小、修改日期以及内容哈希（content hash）。结果会写入：

output/manifest.json

内容哈希为每个资产赋予一个稳定的标识。即使文件名保持不变，它也能让 Foundry 检测出变化，并在没有变化时跳过处理。

浏览器把这份清单变成可视化的形式。图片可以预览，视频可以播放，文档即使没有缩略图也依然可见。

这第一个检查点很重要：检索找不到扫描器遗漏的东西。

第二步：为检索准备记录

清单告诉我们哪些文件存在。下一步是描述这些文件里到底包含什么。

准备阶段会补充描述、标签（tags）、抽取出的文本、关系角色（relationship role）以及源 URI。一条准备好的图片记录看起来像这样：

{

"fileName"

:

"rain-floor.jpg"

,

"relativePath"

:

"RAIN TRAILER/References/rain-floor.jpg"

,

"project"

:

"RAIN TRAILER"

,

"assetType"

:

"image"

,

"relationshipRole"

:

"reference"

,

"description"

:

"Heavy rain striking a reflective floor with bright droplets and bokeh."

,

"tags"

:

[

"rain"

,

"wet floor"

,

"reflection"

,

"atmosphere"

]

,

"sourceUri"

:

"foundry://RAIN TRAILER/References/rain-floor.jpg"

}

foundry:// 这个 URI 指向资产本身，但并不把 Weaviate 当成文件存储来用。生产版本可以使用 DAM 链接、挂载路径、S3 链接或应用路由。

目前，演示版本使用一份固定的精简增强清单（enrichment manifest），让每次运行都产生相同的结果。后续版本可以从图片描述、OCR、字幕转录和视频关键帧中自动生成这些上下文信息。

第三步：同步到 Weaviate

在同步之前，Foundry 会准确展示将要被索引的内容。用户可以在任何数据进入 Weaviate 之前，审阅描述、元数据和源路径。

随后，应用会创建或更新 Foundry 集合（collection）。Weaviate 会生成嵌入向量（embeddings），并把它们与元数据一起存储下来。每个对象都保留它的源路径和权利状态。

再次运行这一流程并不会产生重复。确定性的标识符确保每个资产都更新到同一个对象上。

同样的流程也可以通过命令行执行：

npm run scan
npm run ingest:prepare
npm run ingest:cloud

云端凭据保存在本地的 .env 文件中：

WEAVIATE_URL=https://your-cluster.weaviate.network
WEAVIATE_API_KEY=replace-with-a-read-write-api-key
WEAVIATE_COLLECTION=Foundry

第四步：检索归档

同步完成后，归档就变成了一个实时的检索工作空间。

第一个测试查询很容易描述，却很难对应到某个文件名：

white rabbit in a grassy landscape

结果中包括一张兔子参考图、Big Buck Bunny 的预告片（译注：Big Buck Bunny 是 Blender 基金会发布的开源短片，主角正是一只大兔子），以及相关的风景素材。用户无需记住文件名或文件夹，只要描述自己记得的内容，Foundry 就会把相关的作品带回眼前。

Foundry 提供三种检索模式：

keyword  → exact words and names
semantic → meaning represented by embeddings
hybrid   → keyword and semantic signals combined

关键词检索（keyword search）适用于记得文件名或制作术语的场景。语义检索（semantic search）适用于记得内容的场景。混合检索（hybrid search）则把两种记忆合并到同一组结果中。

过滤器让这些结果更实用。用户可以按项目、文件类型或关系角色来缩小归档范围。同样的模式还可以支持审批状态、权利、过期日期和交付格式等条件。

这个原型证明了什么

原型现在已经走完了从源文件夹到可用结果的完整流程：

- 它在不改动源文件的前提下扫描嵌套归档。
- 它通过内容哈希创建稳定记录，并检测变化。
- 它在导入前就丰富记录内容，而不是只依赖文件名。
- 它在 Weaviate 中存储可检索的记录以及被管理的嵌入向量。
- 它在同一个归档上对比了关键词、语义和混合检索。
- 它返回的图片和视频都带有指回源文件的链接。

Foundry 仍然只是一个原型。自动增强、增量重新扫描、基于权利的过滤以及相关性反馈，将是这个项目的下一次更新。

运行 Foundry

该项目已在 GitHub 上开源。

cp .env.example .env
# Add your Weaviate Cloud URL and API key
npm install
npm run demo

请使用 Node.js 22 或更高版本来进行云端同步和实时检索。本地清单无需云端凭据即可运行。

> 提示
>
> 探索 Foundry 仓库并按照 README 扫描示例归档，或接入你自己的 Weaviate Cloud 集合。

从隐藏的文件到有用的历史

Foundry 起源于一种常见的创作烦恼：记得作品，却不记得它在哪里。

它并不取代背后的文件夹、工具或习惯。它只是给归档提供了一种新的展现方式。一个原本只能依靠正确的文件名、文件夹或同事才能找到的资产，现在可以通过它背后的那个想法被找到。