01 业务背景
消费金融、小微贷款公司每天通过多个渠道与客户高频交互，沉淀出海量的非结构化数据：客服热线的语音通话（经 ASR 转写）、客户上传的图片工单（还款凭证、身份证件、合同截图）、App 内的在线聊天记录，以及散布在黑猫投诉、应用商店、微博、贴吧等外部渠道的舆情帖子。
这些数据背后，是一整套对时效性和准确性要求极高的业务诉求：
- 在客户情绪失控前识别出愤怒、焦虑的高危工单优先派单，避免投诉升级；
- 第一时间发现"暴力催收""套路贷/高利贷""个人信息泄露"等高危合规指控并上报法务；
- 对全量工单自动完成情感、情绪、意图、风险的多维打标，替代人工质检抽检；
- 实时监测外部负面舆情，判断是否需要公关介入，并与内部工单风险交叉印证。
在引入 StarRocks AI Function 之前，公司主要依赖人工听录音、看截图、逐条读聊天记录，效率极低且覆盖率不足；辅助的关键词规则引擎又难以理解语义，反讽、转折、隐晦表达大量漏报误报，根本无法支撑多模态数据的综合研判。更棘手的是，语音、图片、文本三类数据分散在不同系统，内外部风险无法联动，"内部工单里冒头的风险，外部黑猫上其实早已发酵"这种关键信号完全被割裂。
02 技术挑战
在尝试自建大模型调用链路的过程中，团队主要遇到三类问题：
- 多模态加工链路长、系统割裂。语音要先过 ASR、图片要先过 VLM 做 OCR，再把文本送进分类/打标模型，最后落库做检索和报表。每一环都是独立系统，中间靠落表读表传递数据，链路长、排查难，一条工单从进来到出预警要跨好几个平台。
- 非结构化数据"只能看不能算"。情感、意图、风险这些关键维度散落在录音和图片里，无法作为结构化字段参与查询、聚合和预警。想出一张"当日高危工单按意图分布"的报表，都得先人工把标签补齐。
- 工程复杂度和成本控制难。对全量工单逐条调用大模型，需要自己实现数据分片、并发、重试、结果回填；而大模型按调用次数计费，每天新增几万工单如果不做增量去重，很容易把老工单重跑一遍，白白烧掉预算。
03 解决方案
基于阿里云 EMR Serverless StarRocks，用 StarRocks AI Function 在库内直接调用大模型，用标准 SQL 完成了从"语音/图片/文本原始素材"到"可预警、可报表的结构化风险资产"的全链路加工。核心思路是：数据不出库，推理即查询，多模态与结构化混合分析统一在一个引擎里完成。
方案用到的核心能力包括：
- StarRocks AI Function（ai_complete 做文本理解与多模态识别、ai_classify 做分类打标、ai_filter 做语义过滤、ai_extract 做字段抽取、ai_agg 做聚合摘要）、
- 向量检索（ai_embed 配合 cosine_similarity 做相似工单语义召回），
- 混合检索（标量+向量+全文做多维关联分析）
整体流程分为六步：
- 外部 OSS 语音/图片、App 聊天、外部舆情统一入库；
- 对全量工单做情感分析、情绪/意图/风险打标、字段抽取与摘要；
- 生成文本向量与图片向量；
- 用 cosine_similarity 做语义检索；
- SQL 出日报大盘、用 ai_agg 汇总危机简报，并做内外部风险交叉印证。
04 实战操作
第一步，建库建表。
用 Object Table 把 OSS 上的语音/图片工单直接映射进来。金融公司的语音录音、图片凭证原文件几乎都沉淀在 OSS，建 Object Table 把对象映射成库内的表：object_uri 直接当 image_url 用，file 描述符交给 VLM/ASR，签名地址由系统自动生成，实现"文件不出 OSS"。
-- 把 OSS 上的语音/图片工单映射为 Object Table CREATE OBJECT TABLE obj_call_audio PROPERTIES ( "path" = "oss://your-bucket/calls", "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" = ".*\\.(wav|mp3|m4a|jpg|png)$" ); REFRESH OBJECT TABLE obj_call_audio;
映射完成后，后续凡是"给模型传图片/音频"的地方，都可以直接把 file 字段当参数，例如 ai_complete('qwen-omni-turbo', prompt, file, 'audio')，全程文件不出 OSS。
在此基础上，再建工单主表和打标结果表：语音、图片、聊天三类工单进同一张主表，情感打标、文本向量、图片向量、外部舆情各自建表，全部同库存储：
-- 工单主表：语音/图片/聊天三类统一入库 CREATE TABLE work_order_src ( order_id VARCHAR(64) NOT NULL, channel VARCHAR(16), -- voice / image / chat image_url VARCHAR(1024), -- 图片工单原图（可取自 object_uri） raw_content VARCHAR(8192), -- ASR 转写 / OCR 文本 / 聊天原文 created_at DATETIME ) PRIMARY KEY (order_id) DISTRIBUTED BY HASH(order_id) BUCKETS 8; -- 情感分析 + 多维打标结果表 CREATE TABLE wo_analysis ( order_id VARCHAR(64) NOT NULL, sentiment VARCHAR(16), -- 正面/中性/负面 emotion VARCHAR(32), -- 平静/焦虑/愤怒/不满/感激 intent VARCHAR(32), -- 还款咨询/费用异议/投诉/催收异议... risk_level VARCHAR(16), -- high/mid/low risk_reason VARCHAR(512), summary VARCHAR(1024) ) PRIMARY KEY (order_id) DISTRIBUTED BY HASH(order_id) BUCKETS 8;
第二步，图片工单 VLM 识别。
图片工单用视觉大模型做 OCR 与内容识别，把结果回填到 raw_content，之后与文本工单同流程处理，AI 函数可以直接写进 UPDATE 语句：
UPDATE work_order_src SET raw_content = ai_complete('qwen-vl-plus', '这是贷款客服收到的图片工单，请描述图片内容，若是票据/证件/合同请提取关键文字，只输出识别结果', image_url, 'image') WHERE channel = 'image';
实测中，还款凭证图正确提取出了购买方名称、社会信用代码等票据字段，合同/海报图则输出了结构化画面描述。
第三步，一条 SQL 完成情感分析加多维打标。
一次性完成情感、情绪、意图三类分类，叠加暴力催收、套路贷、信息泄露、投诉意向四路风险语义过滤，再生成摘要。多路风险命中时，CASE 的先后顺序即优先级：
INSERT INTO wo_analysis WITH flags AS ( SELECT order_id, get_json_string(ai_classify(raw_content, ['正面','中性','负面']), '$.labels[0]') AS sentiment, get_json_string(ai_classify(raw_content, ['平静','焦虑','愤怒','不满','感激']), '$.labels[0]') AS emotion, get_json_string(ai_classify(raw_content, ['还款咨询','投诉','催收异议','费用异议','信息安全','其他']), '$.labels[0]') AS intent, ai_filter('这条工单是否指控暴力催收爆通讯录威胁上门骚扰家人', raw_content) AS f_collect, ai_filter('这条工单是否指控套路贷高利贷砍头息或实际利率远超宣传', raw_content) AS f_usury, ai_filter('这条工单是否指控本公司泄露了客户身份证银行卡等隐私信息', raw_content) AS f_privacy, ai_complete(CONCAT('用40字内概括这条贷款客服工单的核心诉求，只输出概括:\n', raw_content)) AS summary FROM work_order_src ) SELECT order_id, sentiment, emotion, intent, CASE WHEN f_collect THEN 'high' WHEN f_usury THEN 'high' WHEN f_privacy THEN 'high' ELSE 'low' END, CASE WHEN f_collect THEN '暴力催收指控' WHEN f_usury THEN '套路贷/高利贷指控' WHEN f_privacy THEN '个人信息泄露指控' ELSE NULL END, summary FROM flags;
第四步，生成向量并做舆情分析。
文本工单生成 1024 维文本向量，图片工单生成 2560 维视觉向量；外部舆情帖同样用 ai_classify 做情感与主题分类、用 ai_filter 判断是否需要公关介入。
第五步，语义检索加纯 SQL 报表。
质检员输入一句自然语言，就能定位语义最相近的工单；
-- 以文搜工单：语义检索相似投诉 WITH q AS (SELECT ai_embed('催收人员骚扰家人和联系人，威胁上门') AS qv) SELECT e.order_id, wa.risk_reason, ROUND(cosine_similarity(e.text_embedding, q.qv), 4) AS score FROM wo_text_emb e LEFT JOIN wo_analysis wa ON e.order_id = wa.order_id CROSS JOIN q ORDER BY score DESC LIMIT 3;
实测这条检索的 top1 精准命中了暴力催收工单（相似度 0.83），信息泄露、套路贷工单紧随其后。
第六步，危机简报与内外风险交叉印证。
用 ai_agg 把当日高危负面舆情自动汇总成一份 200 字内的危机简报，包含主要风险点、监管/品牌影响、优先处置建议；再用一条 SQL 把同一风险主题在内部工单和外部舆情的命中数并排对齐，形成"内部预警的风险外部已在发酵"的闭环：
-- 危机简报 WITH neg AS (SELECT content FROM public_opinion WHERE risk_level = 'high') SELECT ai_agg(content, '你是金融公司舆情分析师，汇总以下负面舆情，生成200字内危机简报，包含主要风险点、监管/品牌影响、优先处置建议') AS briefing FROM neg;
一个尤其值得强调的成本细节：大模型按调用次数计费，每天新增几万工单时，在调用 AI 函数之前用 LEFT ANTI JOIN 过滤掉已处理的记录，去重需发生在 AI 函数之前——靠目标表主键去重仍会调用模型并计费。
若走 Object Table，用 object_uri 加 etag 做 anti-join 更严谨，文件被覆盖上传后 etag 变化会自动触发重新打标。
-- Object Table 场景：object_uri + etag 双键 anti-join WITH new_files AS ( SELECT o.object_uri, o.etag, o.file FROM paimon.fin_cs.obj_call_audio o LEFT ANTI JOIN wo_analysis wa ON o.object_uri = wa.object_uri AND o.etag = wa.etag -- 覆盖上传 → etag 变 → 重新命中 ) SELECT object_uri, etag, ai_complete('qwen-omni-turbo', '转写并概括这通催收/客服录音的核心诉求', file, 'audio') AS summary FROM new_files;
05 实施成效
方案上线后，最直接的变化是三类原本"只能看不能算"的非结构化工单，全部变成了可查询、可聚合、可预警的结构化数据资产。
归纳起来，收益主要体现在四个方面。
- 质检与合规效率上，全量工单自动打标替代人工抽检，高危指控从"事后回看"提前到"实时拦截"。
- 数据链路上，语音、图片、文本三类工单与外部舆情统一接入同一个 StarRocks，内外部风险可以交叉印证，无需在多个系统间搬运数据。
- 工程复杂度上，数据加工与模型调用统一为标准 SQL，无需自建推理服务和调度系统，新场景上线从周级缩短到天级。
- 数据安全上，金融敏感数据在库内完成加工与分析，不导出到外部系统，契合金融行业的数据安全与合规要求。
06 总结
通过 StarRocks，AI Function把大模型能力以 SQL 函数的形式嵌入到数据处理链路中，多模态混合检索拓展了数据查询效率。构建了覆盖"语音/图片/文本加工 → 情感分析与多维打标 → 语义检索 → 报表大盘 → 舆情研判 → 内外风险交叉印证"的全链路多模态闭环。整个方案数据不出库，推理即查询，让原本割裂、依赖人工的多模态工单研判，变成了一条条可复用、可编排的标准 SQL。
对于同样存在多模态非结构化数据加工、大规模语义打标、语义检索与舆情监控需求的团队，StarRocks AI Function 提供了一条将大模型能力融入现有数据链路的可行路径——会写 SQL，就能调用大模型。
