中文资讯掘金 AI Fri, 14 Aug 2026 正文 ok 902 words

借助 EMR Serverless StarRocks 实现电商平台图搜图与文搜图

英文标题：借助 EMR Serverless StarRocks 实现电商平台图搜图、文搜图场景

该方案基于 EMR Serverless StarRocks，将多模态模型以 SQL 函数形式嵌入电商混合搜索链路，覆盖 OSS 图片挂载、向量化入库、ANN 索引、图搜图、文搜图及业务过滤和融合排序。商品图片通过 Object Table 挂载在 OSS 中，使用 `object_uri + etag` 识别新增或变更图片，从而仅对需要更新的 SKU 执行向量推理。StarRocks 将向量检索与价格、库存、类目等结构化条件在同一条 SQL 中融合，减少独立向量数据库与 OLAP 系统之间的数据同步和运维复杂度。该架构还可扩展到 UGC 图文匹配、盗图检测、同款比价和素材去重等多模态检索场景。

打开原文相关 3 · 机会 0

3.2 KB

589 B

161.1 KB

60.8 KB

81.0 KB

16.9 KB

中文

一、背景

电商搜索这些年走过三个阶段：关键词搜索、语义搜索、多模态搜索。今天用户的期待已经很直接——拍一张图就要找到同款，输入一句“米白色宽松棉麻衬衫”就要找到正确的商品。

这背后是两个高频场景。

问题在于，这两件事传统上都很难落在同一套系统里。

于是团队需要维护两套系统、编写两套链路：向量库中没有业务字段，OLAP 库中没有向量，中间依靠应用层反复拉取数据并拼接结果。商品更换主图后，向量更新可能延迟数小时，搜索结果仍然是旧款。

二、整体技术架构

基于 EMR Serverless StarRocks，使用 StarRocks AI Function 在库内直接调用多模态模型，将“OSS 图片 → 向量 → 混合检索 → 业务过滤与排序”整条链路收敛为标准 SQL。图片原图不离开 OSS，使用 Object Table 挂载增量文件；向量与商品业务属性存储在同一数据库中，向量检索与结构化过滤可在一条 SQL 内原生融合。

核心能力包括：

ai_embed_multimodal(file, 'image')：将商品主图编码为向量；
ai_embed_multimodal(text, 'text')：将用户自然语言查询编码到同一向量空间，这是文搜图能够跨模态命中图片向量的关键；
approx_cosine_similarity：在向量索引上执行 ANN 检索，并结合 WHERE 中的价格、库存、类目条件，通过一条 SQL 输出最终结果。

支持的算法与索引选型

图片.png

数据源	索引类型	距离度量	典型特点	推荐场景
StarRocks 内表	HNSW	L2、余弦相似度	低延迟、高召回；索引体积和内存占用相对较高	线上主搜、秒级响应的图搜图/文搜图
StarRocks 内表	IVFPQ	L2、余弦相似度	通过聚类和乘积量化降低索引体积；通常需要精排以提高最终精度	亿级 SKU、成本与内存敏感
DLF Paimon 湖表	Lumina Global Index	L2、余弦相似度、内积	数据保留在湖表；支持分片并行召回及结构化 Global Index 预过滤	全量商品资产留湖、多引擎共享、离线大批量召回

用户侧
  ├── 上传图片（图搜图）
  └── 输入文字描述（文搜图）
          │
          ▼
应用服务层
  ├── 图片预处理（裁剪 / 归一化）
  └── 调用 StarRocks AI Function 实时向量化
          │
          ▼
StarRocks Stella 2.2
  ├── 商品多模态表（SKU 信息 + 图像向量 + 文本向量）
  ├── ANN 向量索引（HNSW / IVF）
  └── AI Function：AI_EMBED(image / text, model)
          │
          ▼
结果处理层
  ├── Top-K 相似商品列表
  ├── 联合业务规则过滤（价格区间 / 库存 / 类目）
  └── 结果排序与展示

三、实践步骤

图片 - 2026-08-14T191928.617.png

第一步：使用 Object Table 挂载 OSS 商品图片

主图按类目和年月目录沉淀在 OSS 中。创建 Object Table 将对象映射进来，file 描述符可以直接传递给 AI 函数，签名地址由系统自动生成，SQL 中不会出现 AK/SK。

SET CATALOG default_catalog;
CREATE DATABASE IF NOT EXISTS ec_search;

CREATE OBJECT TABLE ec_search.obj_product_images PROPERTIES (
  "path" = "oss://<BUCKET>/product/images/",
  "aliyun.oss.endpoint" = "oss-cn-hangzhou-internal.aliyuncs.com",
  "aliyun.oss.public_endpoint" = "oss-cn-hangzhou.aliyuncs.com",
  "aliyun.oss.access_key" = "<AK>",
  "aliyun.oss.secret_key" = "<SK>",
  "recursive" = "true",
  "file_pattern" = ".*\\.(jpg|jpeg|png|webp)$"
);
REFRESH OBJECT TABLE ec_search.obj_product_images;

Object Table 固定包含 8 列（object_uri/etag/size/last_modified/content_type/storage_class/refresh_id/file），其中 etag 是执行增量处理的关键水位。主图被替换后，etag 发生变化，会自动触发重新向量化。

第二步：创建商品多模态表并规划向量索引

线上主搜索使用内表，向量列必须为 NOT NULL 的 ARRAY<FLOAT>，表模型使用 Primary Key 或 Duplicate Key：

CREATE TABLE ec_search.product_image_search (
  sku_id       BIGINT NOT NULL,
  spu_id       BIGINT,
  title        VARCHAR(1024),
  category     VARCHAR(64),
  brand        VARCHAR(64),
  price        DECIMAL(10,2),
  stock        INT,
  rating       FLOAT,
  sales_30d    BIGINT,
  object_uri   VARCHAR(1024),          
  etag         VARCHAR(256),           
  image_vector ARRAY<FLOAT> NOT NULL,  
  updated_at   DATETIME,
  INDEX idx_image_vec (image_vector) USING VECTOR (
    "index_type"       = "hnsw",
    "dim"              = "2560",
    "metric_type"      = "cosine_similarity",
    "is_vector_normed" = "false",
    "M"                = "16",
    "efconstruction"   = "200"
  )
) PRIMARY KEY (sku_id)
DISTRIBUTED BY HASH(sku_id) BUCKETS 32;

按照检索路径分表：product_image_search 承载图像向量，服务于图搜图与文搜图，因为文本查询向量与图像位于同一向量空间；另建 product_text_search，使用 ai_embed 生成的 1024 维文本向量服务“文搜文”。

如果全量商品向量需要保留在湖上并供多引擎共享，则可以落到 DLF Paimon 表：

CREATE TABLE dlf_catalog.`default`.product_vectors (
  sku_id BIGINT, object_uri STRING, etag STRING,
  category STRING, brand STRING, price DECIMAL(10,2), stock INT,
  image_vector ARRAY<FLOAT>, updated_at TIMESTAMP
) ENGINE = paimon
PROPERTIES ("file.format"="parquet","primary-key"="sku_id",
            "merge-engine"="partial-update","bucket"="4");

第三步：批量向量化入库，在 AI 函数调用前去重

将 Object Table 的 file 传递给 ai_embed_multimodal，并使用 object_uri + etag 执行 LEFT ANTI JOIN，过滤已经处理过的主图：

INSERT INTO ec_search.product_image_search
  (sku_id, spu_id, title, category, brand, price, stock, rating, sales_30d,
   object_uri, etag, image_vector, updated_at)
SELECT
  p.sku_id, p.spu_id, p.title, p.category, p.brand, p.price, p.stock, p.rating, p.sales_30d,
  o.object_uri, o.etag,
  ai_embed_multimodal(o.file, 'image') AS image_vector,
  now()
FROM ec_search.obj_product_images o
JOIN ec_search.dim_product p
  ON p.image_key = regexp_extract(o.object_uri, '.*/(.+)$', 1)
LEFT ANTI JOIN ec_search.product_image_search t
  ON t.object_uri = o.object_uri AND t.etag = o.etag
WHERE object_file_is_image(o.file);


SELECT COUNT(*) AS total,
       SUM(IF(image_vector IS NOT NULL AND array_length(image_vector)=2560,1,0)) AS valid_vec
FROM ec_search.product_image_search;

第四步：图搜图

关键点在于，要命中向量索引，查询向量必须是优化阶段可确定的常量数组。因此线上采用两步方式：应用层先调用一次向量化获取数组，再将其作为字面量拼接到检索 SQL 中。

SELECT ai_embed_multimodal('https://<BUCKET>.oss-cn-hangzhou.aliyuncs.com/upload/q.jpg', 'image');


SELECT sku_id, title, category, price, rating, object_uri,
       approx_cosine_similarity(image_vector, [0.0131, -0.0247, ]) AS score
FROM ec_search.product_image_search
WHERE stock > 0
  AND category = '女装'
  AND price BETWEEN 100 AND 500
  AND rating >= 4.0
ORDER BY score DESC
LIMIT 20;

第五步：文搜图（跨模态）

将用户输入的文字使用同一个多模态模型编码为 2560 维向量，直接与商品的 image_vector 比较相似度，这就是跨模态检索：

SELECT ai_embed_multimodal('米白色宽松棉麻衬衫', 'text');


SELECT sku_id, title, brand, price, object_uri,
       approx_cosine_similarity(image_vector, []) AS score
FROM ec_search.product_image_search
WHERE stock > 0
  AND category IN ('衬衫','女士衬衫')
  AND price < 2000
ORDER BY score DESC
LIMIT 20;

如果需要实现“文搜文”，即基于标题、属性描述进行同模态语义搜索，应使用 ai_embed 的 1024 维向量，并在独立的文本向量表上进行检索——不要与 2560 维图像向量混合计算。

建议在应用层缓存高频查询词的查询向量，避免重复调用模型。

第六步：融合排序与多路召回

向量相似度只是排序信号之一，线上通常还需叠加评分、销量和活动权重：

SELECT sku_id, title, price, rating, sales_30d,
       0.7 * approx_cosine_similarity(image_vector, [])
     + 0.2 * (rating / 5.0)
     + 0.1 * LOG(sales_30d + 1) / 10 AS final_score
FROM ec_search.product_image_search
WHERE stock > 0
ORDER BY final_score DESC
LIMIT 20;

注意：要命中 TopK 向量索引，ORDER BY 只能包含单个近似距离表达式。上述加权融合会导致索引不生效，因此适合作为精排层。正确做法是：先通过纯 approx_cosine_similarity 索引召回 Top-200 到 CTE，再在 CTE 上进行加权重排。

多路召回，包括图像向量召回、文本向量召回和关键词倒排召回，可使用 RRF 融合。各路先通过 ROW_NUMBER() 得到排名，再按照 SUM(1/(k+rank)) 计算分数；ORDER BY 应使用裸别名，不要带表前缀：

WITH img_recall AS (
  SELECT sku_id, ROW_NUMBER() OVER (ORDER BY approx_cosine_similarity(image_vector,[]) DESC) AS r
  FROM ec_search.product_image_search WHERE stock>0 ORDER BY r LIMIT 200),
txt_recall AS (
  SELECT sku_id, ROW_NUMBER() OVER (ORDER BY approx_cosine_similarity(text_vector,[]) DESC) AS r
  FROM ec_search.product_text_search WHERE stock>0 ORDER BY r LIMIT 200),
fused AS (
  SELECT sku_id, SUM(1.0/(60+r)) AS rrf
  FROM (SELECT sku_id,r FROM img_recall UNION ALL SELECT sku_id,r FROM txt_recall) u
  GROUP BY sku_id)
SELECT f.sku_id, p.title, p.price, ROUND(f.rrf,5) AS rrf_score
FROM fused f JOIN ec_search.product_image_search p ON f.sku_id=p.sku_id
ORDER BY rrf_score DESC LIMIT 20;

第七步：湖表检索与增量更新

在 DLF Paimon 湖表上检索时，同样使用近似函数与常量向量；查询向量应使用原生数组字面量。兼容 Bitmap/BTree Global Index 的结构化条件会作为 Prefilter 下推，其余条件则作为 Postfilter 执行：

SELECT sku_id, approx_cosine_similarity(image_vector, []) AS score
FROM dlf_catalog.`default`.product_vectors
WHERE category = '女装' AND stock > 0
ORDER BY score DESC LIMIT 20;

在增量维护方面，新品和换图商品都可通过 object_uri + etag 的 anti-join 自动纳入处理。周期性调度执行 REFRESH OBJECT TABLE → 向量化 INSERT 即可；ANN 索引支持增量构建，无需全量重建，建议在业务低峰期执行大批量回填。

四、实施成效

图片 - 2026-08-14T191936.925.png

方案落地后，最直接的变化是：商品图片首次成为可被语义检索的资产，并且检索结果天然携带业务约束。

归纳起来有四点收益：

在架构层面，向量库与 OLAP 库合一，减少了一套系统的部署、同步和故障面。
在效果层面，向量检索与结构化过滤原生融合，搜索结果可直接用于展示和排序。
在成本层面，object_uri + etag 增量水位确保仅对新增和换图的 SKU 调用模型，存量数据无需重复推理。
在安全层面，商品图片无需导出到第三方，可在库内完成加工和检索。

五、总结

通过 StarRocks，将多模态模型能力以 SQL 函数形式嵌入混合搜索链路，构建了“OSS 图片挂载 → 向量化入库 → ANN 索引 → 图搜图 / 文搜图 → 业务过滤与融合排序”的全链路闭环。

图片不离开 OSS，向量与业务数据存储在同一数据库中，推理即查询——使用一套 SQL 即可同时支撑拍照购物与自然语言找货。

同一套模板还可以迁移至 UGC 图文匹配、以图找店、盗图与侵权检测、同款比价、素材去重等场景。对于同样面临“图片存放于对象存储、检索需要携带业务条件、又不希望额外维护一套向量库”的团队，StarRocks 提供了一条清晰的落地路径——会写 SQL，就能实现多模态搜索。

English / 原文

一、背景

电商搜索这些年走过三个阶段：关键词搜索、语义搜索、多模态搜索。今天用户的期待已经很直接——拍一张图就要找到同款 ，打一句"米白色宽松棉麻衬衫"就要出对的货 。

这背后是两个高频场景。

问题在于，这两件事传统上都很难落在同一套系统里。

于是团队维护两套系统、写两套链路，向量库里没有业务字段，OLAP 库里没有向量，中间靠应用层来回捞数据拼结果。商品换了主图，向量更新延迟几小时，搜索出来还是旧款。

二、整体技术架构

基于 EMR Serverless StarRocks，用 StarRocks AI Function 在库内直接调用多模态模型，把"OSS 图片 → 向量 → 混合检索 → 业务过滤与排序"整条链路收敛成标准 SQL。图片原图不出 OSS，用 Object Table 挂载增量文件；向量与商品业务属性同库存储，向量检索与结构化过滤在一条 SQL 里原生融合。

核心能力有：

ai_embed_multimodal(file, 'image') 把商品主图编码成向量；
ai_embed_multimodal(text, 'text') 把用户的自然语言查询编码到同一向量空间 ——这是文搜图能跨模态命中图片向量的关键；
approx_cosine_similarity 在向量索引上做 ANN 检索，配合 WHERE 里的价格、库存、类目条件，一条 SQL 出最终结果。

支持的算法与索引选型

数据源	索引类型	距离度量	典型特点	推荐场景
StarRocks 内表	HNSW	L2、余弦相似度	低延迟、高召回；索引体积和内存占用相对较高	线上主搜、秒级响应的图搜图/文搜图
StarRocks 内表	IVFPQ	L2、余弦相似度	通过聚类和乘积量化降低索引体积；通常需要精排以提高最终精度	亿级 SKU、成本与内存敏感
DLF Paimon 湖表	Lumina Global Index	L2、余弦相似度、内积	数据保留在湖表；支持分片并行召回及结构化 Global Index 预过滤	全量商品资产留湖、多引擎共享、离线大批量召回

用户侧
  ├── 上传图片（图搜图）
  └── 输入文字描述（文搜图）
          │
          ▼
应用服务层
  ├── 图片预处理（裁剪 / 归一化）
  └── 调用 StarRocks AI Function 实时向量化
          │
          ▼
StarRocks Stella 2.2
  ├── 商品多模态表（SKU 信息 + 图像向量 + 文本向量）
  ├── ANN 向量索引（HNSW / IVF）
  └── AI Function：AI_EMBED(image / text, model)
          │
          ▼
结果处理层
  ├── Top-K 相似商品列表
  ├── 联合业务规则过滤（价格区间 / 库存 / 类目）
  └── 结果排序与展示

三、实践步骤

image - 2026-08-14T191928.617.png

第一步，用 Object Table 挂载 OSS 商品图片

主图按类目/年月目录沉淀在 OSS，建 Object Table 把对象映射进来，file 描述符直接交给 AI 函数、签名地址由系统自动生成，SQL 里不出现 AK/SK。

SET CATALOG default_catalog;
CREATE DATABASE IF NOT EXISTS ec_search;

CREATE OBJECT TABLE ec_search.obj_product_images PROPERTIES (
  "path" = "oss://<BUCKET>/product/images/",
  "aliyun.oss.endpoint" = "oss-cn-hangzhou-internal.aliyuncs.com",
  "aliyun.oss.public_endpoint" = "oss-cn-hangzhou.aliyuncs.com",
  "aliyun.oss.access_key" = "<AK>",
  "aliyun.oss.secret_key" = "<SK>",
  "recursive" = "true",
  "file_pattern" = ".*\.(jpg|jpeg|png|webp)$"
);
REFRESH OBJECT TABLE ec_search.obj_product_images;

Object Table 固定 8 列（object_uri/etag/size/last_modified/content_type/storage_class/refresh_id/file），其中 etag 是做增量水位的关键——主图被替换后 etag 变化，会自动触发重新向量化。

第二步，建商品多模态表并规划向量索引

线上主搜用内表，向量列必须是 NOT NULL 的 ARRAY<FLOAT>，表模型为 Primary Key 或 Duplicate Key；

CREATE TABLE ec_search.product_image_search (
  sku_id       BIGINT NOT NULL,
  spu_id       BIGINT,
  title        VARCHAR(1024),
  category     VARCHAR(64),
  brand        VARCHAR(64),
  price        DECIMAL(10,2),
  stock        INT,
  rating       FLOAT,
  sales_30d    BIGINT,
  object_uri   VARCHAR(1024),          
  etag         VARCHAR(256),           
  image_vector ARRAY<FLOAT> NOT NULL,  
  updated_at   DATETIME,
  INDEX idx_image_vec (image_vector) USING VECTOR (
    "index_type"       = "hnsw",
    "dim"              = "2560",
    "metric_type"      = "cosine_similarity",
    "is_vector_normed" = "false",
    "M"                = "16",
    "efconstruction"   = "200"
  )
) PRIMARY KEY (sku_id)
DISTRIBUTED BY HASH(sku_id) BUCKETS 32;

按检索路径分表：product_image_search 承载图像向量（服务图搜图 + 文搜图，因为文本查询向量与图像同空间），另建 product_text_search 用 ai_embed 的 1024 维文本向量服务"文搜文"。

若全量商品向量要留在湖上供多引擎共享，则落 DLF Paimon 表。

CREATE TABLE dlf_catalog.`default`.product_vectors (
  sku_id BIGINT, object_uri STRING, etag STRING,
  category STRING, brand STRING, price DECIMAL(10,2), stock INT,
  image_vector ARRAY<FLOAT>, updated_at TIMESTAMP
) ENGINE = paimon
PROPERTIES ("file.format"="parquet","primary-key"="sku_id",
            "merge-engine"="partial-update","bucket"="4");

第三步，批量向量化入库，去重在 AI 函数之前

把 Object Table 的 file 交给 ai_embed_multimodal，并用 object_uri + etag 做 LEFT ANTI JOIN 过滤已处理主图：

INSERT INTO ec_search.product_image_search
  (sku_id, spu_id, title, category, brand, price, stock, rating, sales_30d,
   object_uri, etag, image_vector, updated_at)
SELECT
  p.sku_id, p.spu_id, p.title, p.category, p.brand, p.price, p.stock, p.rating, p.sales_30d,
  o.object_uri, o.etag,
  ai_embed_multimodal(o.file, 'image') AS image_vector,
  now()
FROM ec_search.obj_product_images o
JOIN ec_search.dim_product p
  ON p.image_key = regexp_extract(o.object_uri, '.*/(.+)$', 1)
LEFT ANTI JOIN ec_search.product_image_search t
  ON t.object_uri = o.object_uri AND t.etag = o.etag
WHERE object_file_is_image(o.file);


SELECT COUNT(*) AS total,
       SUM(IF(image_vector IS NOT NULL AND array_length(image_vector)=2560,1,0)) AS valid_vec
FROM ec_search.product_image_search;

第四步，图搜图

关键点：要命中向量索引，查询向量必须是优化阶段可确定的常量数组 。所以线上是两步——应用层先调一次向量化拿到数组，再作为字面量拼进检索 SQL：

SELECT ai_embed_multimodal('https://<BUCKET>.oss-cn-hangzhou.aliyuncs.com/upload/q.jpg', 'image');


SELECT sku_id, title, category, price, rating, object_uri,
       approx_cosine_similarity(image_vector, [0.0131, -0.0247, ]) AS score
FROM ec_search.product_image_search
WHERE stock > 0
  AND category = '女装'
  AND price BETWEEN 100 AND 500
  AND rating >= 4.0
ORDER BY score DESC
LIMIT 20;

第五步，文搜图（跨模态）

用户输入的文字用同一个多模态模型 编码成 2560 维向量，直接与商品的 image_vector 比相似度——这就是跨模态检索：

SELECT ai_embed_multimodal('米白色宽松棉麻衬衫', 'text');


SELECT sku_id, title, brand, price, object_uri,
       approx_cosine_similarity(image_vector, []) AS score
FROM ec_search.product_image_search
WHERE stock > 0
  AND category IN ('衬衫','女士衬衫')
  AND price < 2000
ORDER BY score DESC
LIMIT 20;

如果要做"文搜文"（按标题、属性描述做同模态语义搜索），用 ai_embed 的 1024 维向量、在独立的文本向量表上检索——不要与 2560 维图像向量混算 。

高频查询词的查询向量建议在应用层缓存，避免重复调用模型。

第六步，融合排序与多路召回

向量相似度只是排序信号之一，线上通常还要叠加评分、销量、活动权重：

SELECT sku_id, title, price, rating, sales_30d,
       0.7 * approx_cosine_similarity(image_vector, [])
     + 0.2 * (rating / 5.0)
     + 0.1 * LOG(sales_30d + 1) / 10 AS final_score
FROM ec_search.product_image_search
WHERE stock > 0
ORDER BY final_score DESC
LIMIT 20;

注意：要命中 TopK 向量索引，ORDER BY 只能包含单个近似距离表达式。上面这种加权融合会使索引不生效，适合作为精排层 ——正确做法是先用纯 approx_cosine_similarity 索引召回 Top-200 到 CTE，再在 CTE 上做加权重排。

多路召回（图像向量召回 + 文本向量召回 + 关键词倒排召回）用 RRF 融合，各路各自 ROW_NUMBER() 出排名后按 SUM(1/(k+rank)) 打分；ORDER BY 用裸别名，不要带表前缀：

WITH img_recall AS (
  SELECT sku_id, ROW_NUMBER() OVER (ORDER BY approx_cosine_similarity(image_vector,[]) DESC) AS r
  FROM ec_search.product_image_search WHERE stock>0 ORDER BY r LIMIT 200),
txt_recall AS (
  SELECT sku_id, ROW_NUMBER() OVER (ORDER BY approx_cosine_similarity(text_vector,[]) DESC) AS r
  FROM ec_search.product_text_search WHERE stock>0 ORDER BY r LIMIT 200),
fused AS (
  SELECT sku_id, SUM(1.0/(60+r)) AS rrf
  FROM (SELECT sku_id,r FROM img_recall UNION ALL SELECT sku_id,r FROM txt_recall) u
  GROUP BY sku_id)
SELECT f.sku_id, p.title, p.price, ROUND(f.rrf,5) AS rrf_score
FROM fused f JOIN ec_search.product_image_search p ON f.sku_id=p.sku_id
ORDER BY rrf_score DESC LIMIT 20;

第七步，湖表检索与增量更新

在 DLF Paimon 湖表上检索时同样用近似函数与常量向量；查询向量要用原生数组字面量， 具备兼容 Bitmap/BTree Global Index 的结构化条件会作为 Prefilter 下推，其余作为 Postfilter 执行：

SELECT sku_id, approx_cosine_similarity(image_vector, []) AS score
FROM dlf_catalog.`default`.product_vectors
WHERE category = '女装' AND stock > 0
ORDER BY score DESC LIMIT 20;

增量维护上，新品与换图都靠 object_uri + etag 的 anti-join 自动纳入，周期调度执行 REFRESH OBJECT TABLE → 向量化 INSERT 即可；ANN 索引支持增量构建，无需全量重建，大批量回填建议低峰执行。

四、实施成效

image - 2026-08-14T191936.925.png

方案落地后，最直接的变化是商品图片第一次变成了可被语义检索的资产，而且检索天然带业务约束 。

归纳起来四点收益。

架构上，向量库与 OLAP 库合一，减少一套系统的部署、同步与故障面。
效果上，向量检索与结构化过滤原生融合，搜索结果直接可用于展示与排序。
成本上，object_uri + etag 增量水位保证只对新增和换图的 SKU 调用模型，存量不重复推理。安全上，商品图片不导出到第三方，在库内完成加工与检索。

五、总结

通过 StarRocks，把多模态模型能力以 SQL 函数的形式嵌入混合搜索链路，构建了"OSS 图片挂载 → 向量化入库 → ANN 索引 → 图搜图 / 文搜图 → 业务过滤与融合排序"的全链路闭环。

图片不出 OSS，向量与业务数据同库，推理即查询——用一套 SQL 同时支撑拍照购物与自然语言找货。

同一套模板还可平移到 UGC 图文匹配、以图找店、盗图与侵权检测、同款比价、素材去重等场景。对于同样面临"图片在对象存储、检索要带业务条件、还不想多维护一套向量库"的团队，StarRocks 提供了一条清晰的落地路径——会写 SQL，就能做多模态搜索。

借助 EMR Serverless StarRocks 实现电商平台图搜图与文搜图

中文

一、背景

二、整体技术架构

支持的算法与索引选型

三、实践步骤

第一步：使用 Object Table 挂载 OSS 商品图片

第二步：创建商品多模态表并规划向量索引

第三步：批量向量化入库，在 AI 函数调用前去重

第四步：图搜图

第五步：文搜图（跨模态）

第六步：融合排序与多路召回

第七步：湖表检索与增量更新

四、实施成效

五、总结

English / 原文

一、背景

二、整体技术架构

支持的算法与索引选型

三、实践步骤

第一步，用 Object Table 挂载 OSS 商品图片

第二步，建商品多模态表并规划向量索引

第三步，批量向量化入库，去重在 AI 函数之前

第四步，图搜图

第五步，文搜图（跨模态）

第六步，融合排序与多路召回

第七步，湖表检索与增量更新

四、实施成效

五、 总结

五、总结