EMR Serverless StarRocks Stella 能力解读，从海量广告素材、游戏聊天数据到金融 RAG 的一站式 SQL 实践

数据分析领域正在经历一次底层能力升级——不是把数据搬去 AI 系统处理，而是让 AI 原生运行在数据引擎内部。阿里云 EMR Serverless StarRocks（Stella）最新发布的 AI Function能力，正式将多模态 Embedding、AI 聚合和向量混合检索纳入 SQL 执行链路，使得图片、视频、文本数据可以在同一张 SQL 里完成向量化、打标、检索和汇总，无需外部向量数据库或额外的调度系统。

本文从新功能亮点、架构设计、场景实践和总结四个角度，介绍这次发布带来的工程价值。

一、新功能发布亮点

1.1 多模态 Embedding：图片、视频、文本映射到统一向量空间

ai_embed_multimodal 是本次发布的核心能力之一。它通过 modality 参数（image / video / text）区分输入类型，将不同模态的数据映射到同一个 1024 维向量空间（基于 qwen3-vl-embedding），天然支持跨模态检索——用一段文字描述去搜索视频、用一张图片去检索商品。

相比部分竞品仅支持图片，StarRocks 是同类分析型引擎中唯一同时支持图片、视频和多内容融合向量化的，且支持直接读取 OSS URL、base64 编码和 Paimon 内表中的 VARBINARY 二进制。引擎本身不下载多模态二进制数据，只将 URL 传给模型 API，由模型侧完成读取，避免引擎侧额外的下载与传输开销。

-- 图片向量化：直传 OSS URL
SELECT ai_embed_multimodal(cover_url, 'image') AS visual_vec FROM clips;
-- 跨模态检索：文本查询搜视频封面
SELECT clip_id, cosine_similarity(visual_vec, ai_embed_multimodal('美妆主播讲防晒', 'text')) AS score
FROM clip_visual_emb
ORDER BY score DESC LIMIT 20;

1.2 AI 聚合：让 GROUP BY 具备语义汇总能力

ai_agg 和 ai_agg_summary 提供了跨行的 map-reduce 式 LLM 汇总能力，是同类产品中的独有算子。传统做法需要把数据导出后拼接长文本交给模型，而 StarRocks 把它做成了原生聚合函数，天然契合数仓的 GROUP BY 场景。

典型用法：把一个客户的全部工单、一场直播的数百个片段、或一组用户评论，在 SQL 内直接按分组聚合为一句话画像。

-- 按客户聚合全部工单，生成一句话画像
SELECT customer_id, ai_agg(ticket_content, '总结该客户的核心诉求和情绪特征') AS portrait
FROM support_tickets
GROUP BY customer_id;

1.3 语义过滤谓词：自然语言条件直接写进 WHERE

ai_filter(text, condition) 返回布尔值，可以直接出现在 WHERE 子句中。运营团队无需维护复杂的正则或关键词表，用自然语言描述业务规则即可完成语义筛选：

-- 直播合规审核：一句 SQL 筛出全部违规片段
SELECT clip_id, asr_text
FROM live_clips
WHERE ai_filter(asr_text, '包含极限词、虚假比价或医疗功效承诺');

1.4 向量 + 全文 + 结构化混合检索

AI Function 生成的向量存入 Paimon 湖表或 StarRocks 内表后，可直接利用 HNSW 向量索引和 GIN 全文索引做混合检索。通过 cosine_similarity 做语义召回，MATCH 做精确关键词命中，再叠加结构化字段过滤（日期、品类、地域），在一条 SQL 中完成多路融合排序（如 RRF），取代传统"向量库 + ES + 业务库"三系统串联的架构。

1.5 默认模型免部署，函数级模型分层

本批次起，所有内置 AI Function 均提供"默认模型"重载——省略 model 参数即可开箱调用，无需预先部署模型或购买 GPU 资源。同时保留函数级显式指定模型的能力，允许同一条 SQL 中不同函数选择不同成本、能力档位的模型（如初筛用 qwen3.6-plus，复核用 qwen3.7-max），通过参数调整即可完成模型切换，不改造执行架构。

二、架构优势：从"调用模型"到"生产级 AI 数据计算"

如果只是把模型 API 包装成函数，与客户自己写脚本调接口相比没有本质区别。StarRocks AI Function 的价值在于，让优化器、执行引擎、资源治理、AI 网关和可观测体系共同承担生产责任。

2.1 SQL 原生，数据不搬家

传统方案需要为每个 AI 场景重复建设"读库 → 组装请求 → 调模型 → 重试 → 落库"的独立程序。StarRocks 将这些工作收敛到 SQL 执行链路：数据无需导出到外部环境，读取、过滤、AI 计算和结果写入在一条链路内完成。业务团队只维护 SQL 和结果表，减少中间文件与重复存储。

2.2 异步 Pipeline，面向批量高吞吐

AI 调用不是逐行同步阻塞执行，而是由专用的 AI Pipeline 调度。输入按 Chunk 和子批次进入 AI 算子，模型请求异步提交，等待响应期间执行线程可处理其他任务。Embedding 支持批量请求以减少大量小 HTTP 调用。配合 FE 层的谓词下推、Limit 下推和 Top-N 下推，先在调用模型前减少数据量，再由 Pipeline 并发执行远端调用。

2.3 资源消耗有界

QPS Limiter、Max Inflight、有界 AIChunkBuffer、单响应大小上限和内存准入形成多层边界；消费变慢时向生产端反压，避免无界堆积；查询取消和超时信号会传播到 AI 调用链路，及时释放请求、线程和内存。这使得高并发场景下不会因为单个模型响应变慢而导致整个集群资源失控。

2.4 多账号 AI 网关：负载均衡与多级 Fallback

AI 调用统一进入阿里云 AI 网关，一个 Model API 可绑定多个百炼账号或服务实例，按权重负载均衡，聚合账号配额、削峰填谷。当主服务命中 429、5xx 或流式首包超时时，按优先级触发 Fallback，尝试备用账号或兼容模型。对业务 SQL 完全透明——Stella 只看到一个稳定的 API 端点，账号扩缩容、密钥更新和服务实例变化由网关统一管理。

2.5 两层容错，重试次数可计算

网关先在一次调用内完成多账号选路和 Fallback，尽量返回一次最终结果；只有网关最终仍失败时，Stella 才按查询策略执行受预算约束的有限重试。两层职责分离，避免网关重试与客户端重试无界相乘。

2.6 端到端可观测

Explain 看 AIProjection 下推位置，Profile 看调用数、等待时间、重试次数、Token 消耗，Audit 做查询级成本核算和失败归因，网关日志看后端服务状态码和 Fallback 命中。发生问题时可以清晰区分数据扫描、Pipeline 排队、账号限流、网关选路和模型推理五类瓶颈。

三、场景实践

场景一：广告素材库多模态检索、分析、生成与投放回流

游戏和电商买量团队每周需要产出大量广告素材（视频脚本、封面图、关键帧），传统模式依赖人工打标检索、人工写脚本、人工归因效果，而素材 AI 理解、向量库和投放数据分散在三四个系统中。StarRocks 通过 Object Table + AI Function 在单套引擎内打通"素材管理 → 检索 → 生产 → 归因"的完整闭环：

素材入库与检索。 OSS 上的素材目录通过 CREATE OBJECT TABLE 一条 DDL 编目成 SQL 可查的元数据表，文件本体留在 OSS、二进制不进引擎。封面/关键帧图片通过 ai_embed_multimodal(url, 'image') 向量化后，运营输入自然语言或上传一张图即可做跨模态检索——以文搜图、以图搜图，一条 SQL 搞定。

-- 以文搜图：一句话召回相关素材封面
SELECT object_uri, cosine_similarity(embedding,
       ai_embed_multimodal('真人出镜的赛车玩法，下雪场景', 'text')) AS score
FROM asset_img_emb
ORDER BY score DESC LIMIT 20;

AI 打标与语义审核。 ai_classify 对素材进行多维自动打标（品类、话术类型、情绪、风险等级），ai_filter 直接在 WHERE 中做合规语义审核（极限词、虚假承诺），取代人工逐条审片。

批量脚本生成与二创。 通过 ai_agg_summary 从历史高效脚本中提炼爆款套路，再用 ai_complete 按品牌调性批量生成新脚本和分镜。文本 embedding 支持召回高效脚本片段做二创拼装，产能从人工"几支/天"提升到批量"几百支/次"。

投放效果归因与正循环。 素材元数据、向量与投放效果数据在同一集群内，一句 SQL 做 JOIN 归因。ai_agg_summary 按标签维度汇总高转化套路，向量检索反查"与高转化素材相似但未投放"的存量片段。归因结论写入结果表，直接反哺下一轮脚本生成，形成"生产 → 投放 → 归因 → 再生产"的数据闭环。

-- 素材效果归因：按标签维度聚合，AI 提炼高转化套路
SELECT creative_tag, count(*) AS cnt, avg(ctr) AS avg_ctr, avg(cvr) AS avg_cvr,
       ai_agg_summary(script_text) AS pattern_insight
FROM ad_performance JOIN script_metadata USING (script_uri)
WHERE dt >= date_sub(current_date(), 14)
GROUP BY creative_tag ORDER BY avg_cvr DESC;

增量降本。 URI + ETag 做 anti-join，只对新增或变更版本的素材调用 AI Function，模型费用只花在增量上，避免全量重算重复付费。

场景二：游戏聊天数据批量处理

游戏公司每天产生数百万条玩家聊天记录，需要完成情感分析、投诉识别、风险标签、多语言翻译等任务。传统脚本方案存在并发低、单账号易限流、失败后需人工补偿的问题。

使用 StarRocks AI Function：

INSERT INTO chat_ai_results
SELECT
    message_id,
    ai_sentiment(message_text) AS sentiment,
    ai_classify(message_text, ['正常交流','辱骂攻击','广告引流','账号交易','投诉反馈']) AS category,
    ai_filter(message_text, '是否包含诈骗或站外引流风险') AS is_risky,
    ai_translate(message_text, '', 'Chinese') AS message_cn
FROM chat_messages
WHERE dt = '2026-07-15' AND message_text IS NOT NULL;

按日期增量写入，AI Pipeline 异步并发调度，多账号网关负载均衡，失败行隔离后只重跑未成功数据。业务不再维护并发框架、任务队列和重试逻辑。

场景三：金融文本检索与 RAG

银行/保险机构的合同、公告、研报、工单等文本数据已存入。AI Function 可完成从向量化到混合检索的全链路：

1. ai_embed(document_text) 生成文本向量，写入带 HNSW 索引的列
   
2. 结合 GIN 全文索引做关键词精确匹配
   
3. 一条 SQL 完成"向量语义召回 + 精确关键词命中 + 日期/产品线结构化过滤"的混合检索
   
4. 检索结果直接传给 ai_complete 做 RAG 问答
   

数据始终在湖上，不需要维护独立的向量数据库和 ETL 同步链路。

四、总结

StarRocks AI Function 新能力的核心定位不是"多一种调模型的方式"，而是在分析型数据库内建立了一套生产级的 AI 数据处理体系。其差异化可以概括为三点：

第一，能力独有。ai_agg 跨行语义聚合、ai_filter 自然语言 WHERE 过滤、ai_embed_multimodal 视频 + 多内容融合向量化，是同类产品中未提供的原生算子。

第二，架构生产就绪。异步 Pipeline 高吞吐、资源多层边界防止放大、多账号 AI 网关消除单点、两层容错职责分离、端到端观测可归因——这些不是"能不能调通"的问题，而是"百万行数据批量跑一晚上能不能稳定跑完"的问题。

第三，链路极简。数据在湖上不搬家，一条 SQL 完成从读取、向量化、打标、混合检索到结果回写的全流程。取代传统"向量库 + 搜索引擎 + 调度系统 + 业务脚本"的多系统拼装，运维和数据一致性成本显著降低。

Release Notes