1. 从“人肉”到“智能”一个运维团队的效率困局与破局我所在的团队曾经长期被两类看似简单、实则繁琐到令人头疼的任务所困扰。第一类是工单标注。每天来自不同业务线的告警、故障报告、用户反馈像雪花一样涌进工单系统。这些工单里有纯文本描述有工程师随手截的系统监控图有用户上传的错误日志截图甚至还有一小段录屏。我们的值班同学需要快速浏览这些多模态信息判断问题的紧急程度、可能归属的模块并打上相应的标签分派给对应的负责人。这个过程极度依赖个人经验效率低下且在交接班时容易产生标准不一的问题。第二类是舆情研判。我们需要从社交媒体、技术论坛、应用商店评论中捕捉关于我们服务的负面声音。这些信息同样是文本、图片比如用户晒出的错误界面、视频的混合体。传统做法是依赖关键词匹配和人工抽样查看不仅覆盖面窄而且对图片、视频中的信息完全无能为力经常是问题发酵了才后知后觉。这两个场景的核心痛点高度一致信息载体是多模态的文本、图像处理流程是割裂的分析决策严重依赖人工无法规模化、实时化。我们尝试过用传统的NLP工具处理文本用独立的CV服务分析图片再把结果拼凑起来但数据同步、关联查询、统一分析的复杂度呈指数级上升最终方案都难以落地。转机出现在我们接触到了阿里云EMR Serverless StarRocks以及其AI Function能力。这套组合拳让我们真正看到了将多模态AI分析能力“平民化”、“流程化”嵌入到数据查询层的可能。简单来说我们不再需要维护复杂的AI推理服务集群不再需要操心数据在不同系统间的搬运只需要像写SQL函数一样调用AI能力去分析工单里的图片或是研判舆情中的文本情感整个过程在同一个高性能的数据分析引擎内完成。这篇文章我就来详细拆解我们是如何基于这套架构构建起一个高效、智能的多模态工单与舆情处理平台的。2. 技术选型为什么是EMR Serverless StarRocks AI Function面对多模态数据处理的需求市场上可选方案很多。比如自建Kubernetes集群部署各种AI模型服务然后用Spark或Flink做数据管道进行调用或者使用各家云厂商独立的AI服务如视觉识别、NLP再通过API网关进行集成。但这些方案对我们中小规模的团队来说都存在明显的短板。自建AI服务集群运维成本高需要专门的同学负责GPU资源调度、模型版本管理、服务扩缩容和监控告警。对于工单、舆情这类间歇性、波峰波谷明显的场景资源利用率低成本不划算。云服务API拼接虽然免去了运维但带来了新的问题。首先网络延迟和API调用费用尤其是按次计费在大量数据处理时是一笔不小的开支。其次数据需要在对象存储、API服务和数据分析库之间来回流转架构复杂实时性差更别提进行复杂的多模态关联分析了例如先通过图片识别出错误码再关联文本描述中的时间线。阿里云EMR Serverless StarRocks的AI Function功能恰好击中了这些痛点。它的核心价值在于“将AI能力作为数据库的内置函数”。极致的易用性与集成度你不需要部署任何额外的服务。在StarRocks中通过一个简单的SQL函数调用例如ai_analyze_image(‘image_column‘, ‘model_name‘)就能直接对表中存储的图片URL或Base64编码数据进行AI分析。数据无需离开数据库分析结果直接作为新的字段返回可以立即参与后续的过滤、聚合、关联查询。这大大降低了使用门槛让数据分析师和运维工程师都能直接上手。Serverless形态成本可控EMR Serverless意味着我们无需预先购买和规划计算资源。只有在执行SQL查询、调用AI Function时才会按实际的计算消耗计费。对于工单处理这类定时或触发式任务以及舆情监测这类流式任务这种按需付费的模式比长期保有GPU实例要经济得多。强大的向量化执行引擎StarRocks本身就是一个性能极强的MPP分析型数据库。它的向量化执行引擎能够高效处理海量数据的复杂分析。当AI分析的结果通常是结构化数据或向量产生后可以立即利用StarRocks的高性能进行实时聚合、多维筛选和关联查询这是传统“数据库外部API”架构难以比拟的。丰富的预置模型与自定义支持阿里云提供了多种开箱即用的AI模型涵盖通用图像分类、物体检测、OCR光学字符识别、情感分析、文本分类等。这正是我们处理多模态工单和舆情所需要的。如果预置模型不满足需求还可以通过自定义方式接入部署在阿里云PAI或其它兼容Serving框架上的自定义模型。基于以上几点我们决定以EMR Serverless StarRocks为核心构建我们的智能处理管道。它的定位不是一个单纯的AI服务平台而是一个“具备原生AI分析能力的数据决策中枢”。3. 架构设计与核心组件拆解我们的整体架构遵循“数据入湖 - 统一分析 - 决策输出”的流水线设计目标是实现端到端的自动化与智能化。下图展示了核心的数据流与组件交互整个架构可以分为三层数据接入层、智能分析层和应用输出层。3.1 数据接入与存储层多模态数据的源头是分散的我们需要一个统一的地方来汇聚它们。工单数据来自内部的Jira、自研工单系统等。我们通过系统的Webhook或定时轮询API将新创建的工单包括标题、描述文本、附件列表实时或准实时地同步到消息队列如阿里云RocketMQ中。一个消费程序会解析这些消息将文本字段直接写入StarRocks而图片、视频等附件则上传至阿里云OSS对象存储并在StarRocks中保存其可访问的URL地址。这里的关键是建立工单ID与多媒体文件URL的关联关系。舆情数据我们使用爬虫框架如Scrapy对目标论坛、社交媒体进行定向采集。采集到的数据同样包含文本内容和图片链接。处理流程与工单类似文本和图片链接被结构化后送入消息队列最终落入StarRocks和OSS。注意将原始媒体文件存储在OSS而在StarRocks中只存URL是最佳实践。这避免了将大体积的二进制数据直接塞入分析数据库影响查询性能。StarRocks的AI Function可以直接通过HTTP协议读取OSS的URL进行分析需确保网络连通性与访问权限。3.2 智能分析层StarRocks与AI Function的核心联动这是整个系统的“大脑”。所有汇聚到StarRocks表中的原始数据在这里被赋予“理解”能力。我们主要利用了两类AI Function图像理解函数用于工单附件和舆情图片。AI_IMAGE_RECOGNIZE: 通用图像识别可以判断图片内容是否包含“屏幕截图”、“错误对话框”、“网络拓扑图”等帮助我们快速对工单附件进行分类。AI_OCR: 光学字符识别。这是提效的关键。很多工单里用户直接上传一张包含错误码、日志片段或监控图表的截图。传统方式需要人工肉眼识别并录入。现在通过OCR函数我们可以直接提取图片中的文字信息并将其作为新的文本字段与工单原有文本描述进行合并分析。例如从截图里提取出“Error Code: 500”极大丰富了分析维度。AI_OBJECT_DETECT: 物体检测。在特定场景下有用例如判断舆情图片中是否出现了我们产品的实体包装或界面元素。文本理解函数用于工单描述和舆情文本。AI_SENTIMENT_ANALYSIS: 情感分析。自动判断一段文本的情感极性正面、负面、中性。对于舆情研判这是核心指标可以快速过滤出负面情绪强烈的帖子。AI_TEXT_CLASSIFY: 文本分类。我们可以训练或使用预置模型将工单描述自动分类为“网络问题”、“数据库问题”、“应用BUG”、“需求咨询”等。这替代了最初的人工打标步骤。一个典型的提效SQL示例 假设我们有一张工单表tickets包含id工单ID、description文本描述、image_url截图OSS地址等字段。-- 步骤1使用AI Function对工单进行多模态分析生成一个增强后的视图 CREATE VIEW v_enhanced_tickets AS SELECT id, description, -- 对图片进行OCR提取文字 AI_OCR(image_url, ‘general‘) AS ocr_text, -- 对图片进行识别判断其类别 AI_IMAGE_RECOGNIZE(image_url, ‘classification‘) AS image_category, -- 对文本描述进行情感分析 AI_SENTIMENT_ANALYSIS(description) AS description_sentiment, -- 对文本描述进行自动分类 AI_TEXT_CLASSIFY(description, ‘ticket_category‘) AS predicted_category FROM tickets WHERE image_url IS NOT NULL OR description IS NOT NULL; -- 步骤2基于增强后的视图进行复杂的筛选和聚合 -- 例如找出所有包含“错误”截图且情感为负面的高优先级工单 SELECT predicted_category, COUNT(*) as count, AVG(CASE WHEN description_sentiment.label ‘negative‘ THEN 1 ELSE 0 END) as negative_ratio FROM v_enhanced_tickets WHERE image_category LIKE ‘%screenshot%‘ AND (description LIKE ‘%error%‘ OR ocr_text LIKE ‘%error%‘) AND description_sentiment.label ‘negative‘ GROUP BY predicted_category ORDER BY count DESC;这条SQL的执行过程完全由StarRocks在Serverless的计算资源上完成。它内部会调用相应的AI服务处理图片和文本并将结果无缝整合到查询流程中。对于数据分析师来说他们只需要关心业务逻辑无需了解背后的AI模型部署在哪里。3.3 应用输出与决策层分析完成的数据需要驱动具体的行动。实时告警与工单路由通过定时任务或监听StarRocks物化视图的变化我们将分析结果如“紧急程度高”、“预测为数据库故障”写回工单系统或通过消息通知触发自动化工单路由将其直接分配给对应的DBA或运维小组省去人工分拣环节。舆情仪表盘利用StarRocks对接BI工具如阿里云Quick BI、DataV我们构建了实时的舆情监控仪表盘。仪表盘上可以展示负面舆情趋势、热点问题分类、地域分布等帮助运营和产品团队快速感知市场声音。知识库沉淀处理完的工单其经过AI分析后的结构化信息问题分类、错误码、解决方案可以被自动抽取出来沉淀到知识库中为未来的智能问答或自动处理提供素材。4. 关键实现细节与避坑指南在实际落地过程中我们遇到了不少挑战也积累了一些关键经验。4.1 AI Function的调用优化与成本控制AI Function虽然方便但每次调用都涉及计算资源消耗。不加节制地使用成本可能飙升。策略一异步处理与批处理。对于实时性要求不高的历史工单分析、舆情日报生成等场景我们不会在查询每一条数据时都调用AI。而是通过调度系统如阿里云DataWorks在业务低峰期执行批处理任务一次性处理大量数据并将结果写回一张结果表。后续的查询直接使用结果表避免重复调用AI。策略二条件触发。在SQL中通过WHERE子句精确控制哪些数据需要调用AI。例如只对image_url不为空且description长度大于20个字符的工单进行OCR和分类过滤掉无效或信息量不足的记录。策略三模型选择。预置模型通常有不同规格如精度与速度的权衡。对于初步筛选可以使用速度更快的轻量级模型对于最终判定再使用高精度模型。需要根据业务场景做权衡。4.2 多模态信息的融合策略文本和图片分析结果出来后如何有效融合得出更准确的结论是关键。规则融合初期我们采用简单的规则。例如如果OCR文本中包含“Timeout”且文本情感为负面则工单紧急程度升级。如果图片类别是“网络拓扑图”且文本分类是“网络问题”则置信度提高。向量化融合与高级分析更高级的做法是利用AI Function将文本和图片特征都转化为向量embedding存储在StarRocks的Array类型或专用向量类型字段中。然后可以利用StarRocks的向量相似度搜索功能将新工单与历史已解决工单进行相似度匹配直接推荐解决方案。这才是多模态分析的终极价值——发现跨模态的深层关联。4.3 数据质量与模型效果治理“垃圾进垃圾出。” AI分析的效果极度依赖输入数据和质量。图片预处理从互联网爬取的图片质量参差不齐。我们增加了预处理环节对图片进行格式统一、尺寸缩放、去水印简单裁剪等操作以提高OCR和识别的准确率。这个预处理可以放在数据接入层通过一个简单的图像处理函数完成。模型效果监控我们不能完全信任AI的自动分类。我们建立了抽样复核机制定期人工检查AI分类的结果计算准确率、召回率等指标。如果发现某个类别的准确率持续下降可能需要重新训练模型或调整分类阈值。StarRocks的分析结果可以很方便地导出用于构建模型评估数据集。自定义模型接入预置的通用模型在处理特定领域问题时可能力不从心。例如识别我们自家软件特有的错误界面。这时我们利用阿里云PAI平台训练了一个自定义的图像分类模型并将其部署为在线服务。然后通过StarRocks AI Function的自定义函数功能将其封装成一个新的SQL函数ai_custom_recognize_ui实现了专业领域知识的注入。4.4 权限、网络与安全网络连通性确保StarRocks Serverless集群能够访问公网上的目标AI服务对于预置模型以及访问内网OSS存储桶。在阿里云VPC内需要正确配置安全组和路由。OSS权限AI Function读取OSS图片时需要使用具有对应读权限的AccessKey或通过STS临时令牌。建议使用RAM角色授权方式比直接写AK/SK更安全。数据隐私工单和舆情数据可能包含敏感信息。在调用外部AI服务即使是阿里云内部的时需确认其数据隐私协议。对于高度敏感数据应考虑使用私有化部署的模型或进行数据脱敏后再处理。5. 提效成果与未来展望上线这套系统后效果是立竿见影的。工单处理效率工单的初步分类和标注工作实现了85%以上的自动化值班工程师只需处理少数复杂或AI置信度低的case。平均工单流转时间从创建到分派给正确负责人缩短了70%。舆情响应速度实现了对负面舆情的7x24小时实时监测预警时间从平均发现滞后4小时提升到近乎实时分钟级。我们成功在多次潜在公关危机发酵前就介入处理。知识积累所有处理过的工单都变成了结构化的知识为后续构建智能运维知识库和故障自愈系统打下了坚实基础。当然这只是一个起点。基于目前架构我们还在探索更多可能性流批一体处理目前我们以批处理为主。未来可以结合StarRocks的实时摄入能力实现工单和舆情数据的实时流式分析达到“秒级感知分钟级响应”。多模态大模型深度集成随着类似Qwen-VL这类视觉-语言大模型能力的成熟我们可以探索更深入的多模态理解。例如直接让模型“阅读”一张复杂的系统监控图表截图并生成一段自然语言的问题描述摘要这将彻底改变运维工作模式。闭环自动化将分析结果与自动化运维平台如运维剧本更深度的集成。当系统判定为某一类常见故障且置信度极高时可以尝试自动触发预定义的修复流程真正走向智能运维。回过头看选择阿里云EMR Serverless StarRocks的AI Function本质上是选择了一条“以数据平台为中心渐进式智能升级”的路径。它没有要求我们一开始就搭建庞大复杂的AI中台而是让我们从最痛的几个点出发用最熟悉的SQL语言像搭积木一样逐步引入AI能力。这种低门槛、高集成、按需付费的方式对于大多数追求实效的技术团队来说可能是一条更务实、更容易成功的智能化转型之路。
