到上一篇为止每张图片已经拥有了「结构化标签 自然语言说明」的双重表达。但要在千万张图片里回答「帮我找一批跟这张图相似的场景」靠标签 LIKE 是做不到语义级匹配的——还需要把图片和文字编码成同一空间里的向量。这就是向量化流水线Embedding 流水线的职责。本篇拆解三件事流水线怎么跑五步流程、模型与版本怎么管CLIP 双塔 版本化向量、向量表为什么是湖仓里唯一带分区的表。一、五步流水线每日凌晨 6 点前完成流水线 T1 调度每日凌晨 6 点前跑完五步环环相扣① 增量识别按 create_time / update_time 水位只处理新增图片和标签变更的图片——不做全量重算这是成本控制的前提② 成本分级高价值数据规则命中 / 事件抽帧全量处理普通数据按比例抽样——与抽帧、caption 一脉相承的分级思路③ 向量生成图片走 image encoder、文字caption走 text encoder双路经同一 CLIP 模型编码保证图文向量落在同一空间——这是文搜图能成立的地基④ 幂等写回按 (image_id, embedding_version, dt) 主键 Upsert 进向量表重跑无副作用标签变了图片没变就不重算图像向量⑤ 索引刷新通知 StarRocks 做分区级增量索引刷新SLA ≤ 1 小时——新数据当日可检索。实现选型上采用 Spark / Ray GPU 算子UDF 调用模型服务批次失败可断点续跑——与 VLM 推理共享同一套弹性 GPU 资源池凌晨窗口错峰使用。二、模型与版本CLIP 双塔与向量版本化为什么是 CLIP 这类双塔模型它用对比学习把图片和文本映射到同一向量空间「雨天夜间高速行人横穿」这句话的向量会天然靠近这类图片的向量——文搜图、图搜图本质上是同一个最近邻问题。业界沿这条路线持续演进SigLIP 以 Sigmoid 损失提升判别力中文场景可评估 Chinese-CLIP模型选型不是一锤子买卖。模型一定会换代向量怎么办答案是把embedding_version 放进主键模型升级后新旧向量并存用 vector_status 区分检索默认 active 版本——灰度切换与回滚都不需要重刷全量数据。「增量向量化 版本化索引」是特斯拉、Wayve 等数据引擎迭代的通用做法双写灰度是其中标配。三、向量表湖仓里唯一的分区表流水线落地的 dwd_mining_image_vector_detail 是整个湖仓里一个特殊的存在它是全湖体量最大的明细表千万~亿级行 × 高维向量也是湖仓内唯一带分区的表其余表以 bucket 主键 Upsert 管理。联合主键为 (image_id, embedding_version, dt)dt 即分区键。为什么唯独它要分区两个理由都指向「大」生命周期降冷——历史分区可以整体降冷到更便宜的存储检索却只扫近期分区不受影响向量索引增量刷新——按分区触发刷新每天只建新分区的那部分索引而不是全量重建。一个分区设计同时解决了存储成本和索引成本两个最贵的问题。 本篇要点回顾① 五步流水线每日凌晨 6 点前完成增量识别 → 成本分级 → 图文双路编码 → 幂等写回 → 索引刷新② 同一 CLIP 模型双塔编码保证图文同空间文搜图图搜图是同一个最近邻问题③ embedding_version 入主键模型换代新旧并存可灰度可回滚④ 向量表是全湖最大的明细表、唯一分区表分区同时解决降冷与索引增量刷新。向量生产齐了最后一环是检索本身一句自然语言怎么变成一次毫秒级的最近邻查询下篇讲多模态语义检索统一检索 API 的五步处理、StarRocks 外部表双 HNSW 索引、P95 ≤ 2 秒的性能目标与内表冗余降级路径——挖掘系列在此收官。