业务进行文件索引和空间索引的一些实践

描述当前 Brand Space 云空间搜索的实现方式：先根据用户意图定位相关文件夹，再在该文件夹范围内做 retrieval unit 级别的混合检索。

核心结构

当前结构是：

brand_space_folder

  -> 意图路由和资料分区

brand_space_file

  -> 文件级资源元数据、存储信息、处理状态

brand_space_retrieval_unit

  -> 真正参与搜索的最小证据单元

也就是说，系统不是直接全局搜索文件，而是：

用户意图

  -> 找到对应一级文件夹

  -> 在该文件夹及子文件夹内搜索证据片段

  -> 聚合回文件

文件夹优先

一级文件夹是 Brand Space 的第一层语义边界，例如：

Brand Voice
Product Facts
Visual Identity
Messaging Boundaries
Campaign Assets

它解决的问题是：

这个意图应该去哪个资料区域里找？

searchBrandKeyword 会先读取用户的 Brand Space 文件夹，并基于文件夹的 name、path、description、agentInstructions 做 folder routing。

如果命中了一级文件夹，搜索范围会限制在该文件夹及其子文件夹下。这样可以避免一个全局关键词或语义召回把不相关资料区的文件拉进来。

如果无法明确路由到文件夹，则退回全局 retrieval unit 搜索，保证 recall。

文件表

brand_space_file 保存资源级信息：

id
userId
folderId
path
name
fileType
mimeType
storageUrl
size
content
processingStatus
createdAt
updatedAt

它的职责是：

管理资源
展示资源
记录处理状态
保存原始或提取后的 evidence content

它不是主要检索单位，也不保存文件级 AI compact metadata。

检索单元

真正进入搜索的是 brand_space_retrieval_unit：

fileId
unitIndex
unitType
titleText
evidenceText
aliases
keywords
keyFacts
restrictions
searchVector
embedding
pageNumber
timeStartMs
timeEndMs

evidenceText 是可检索、可 rerank、可引用的证据文本，来源包括：

原文
PDF / DOC / DOCX 解析文本
图片 OCR 和简短视觉描述
视频 transcript、visible text 和简短 scene description

AI compact extraction 只负责提炼结构化索引字段：

{
  aliases: string[]
  keywords: string[]
  keyFacts: string[]
  restrictions: string[]
}

这些字段会写入 retrieval unit。brand_space_file 不保存文件级 AI metadata。

处理链路

上传或创建资源后，worker 异步处理：

resource

  -> evidence extraction

  -> compact AI extraction

  -> build retrieval units

  -> Gemini Embedding 2

  -> weighted FTS index

  -> mark ready

不同文件类型生成不同 unit：

txt / markdown

  -> text_chunk

pdf / doc / docx

  -> document_section

image

  -> image_asset

video

  -> video_segment

核心结构

文件夹优先

文件表

检索单元

处理链路

订阅后解锁完整文章