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能力。这种低门槛、高集成、按需付费的方式，对于大多数追求实效的技术团队来说，可能是一条更务实、更容易成功的智能化转型之路。
