前大模型时代AI系统建设

mindmap
  root((AI系统结合建设))
    AIOps
      告警、监控信息过载
      监控数据挖掘
    业务方向
      培训
      个人助理
      客服
      面谈考察
      生物识别应用
      内容提取
      ...
    AI技术
    	数据
    	  非结构化数据提取
    	  数据标注
    	  数据规范化
    	  数据通道
    	    离线
    	    实时
    	  ...
    	算法/模型
    	  模型微调
    	  模型设计/训练
    	  NLP
    	  CV
    	  ...
    平台化(中台化)
      MLOps
      MaaS
      融合AI技术的
低代码流程引擎
      SaaS（AI功能产品）
      KaaS（知识服务）
      ...

AI系统结合建设

中台化

系统驱动引擎、可配置化、个性化需求能支持

  • SaaS-AI功能产品
  • KaaS-知识服务
  • MaaS-模型服务
  • MLOps
  • 融合AI技术的低代码流程引擎

业务方向

  • 面谈考察

  • 培训

  • 助手

    • 个人助理
    • 客服
    • 辅助录入

  • 风控

  • 内容推荐

  • 生物识别应用

  • …

AI技术

算法/模型

  • 模型微调
  • 模型设计与训练
  • NLP精进：分词、纠错、问句改写、词性标注、指代消解、实体识别、长难句压缩
  • CV
  • …

数据

  • 数据标注
  • 数据规范化
  • 非结构化数据提取
  • …

AIOps

MLOps的能力子域

锚向规模化应用场景的集成化管理问题：敏捷+共享+可度量。AutoML框架，包含数据预处理、自动化特征工程、自动化模型优化三部分。数据预处理主要负责：特征分类、数据编码、缺失值处理等常见基础操作。

  • 数据工程
  • 模型训练
  • 模型部署
  • 模型监控
  • 资产管理

特征工程

特征工程是机器学习中至关重要的工作，直接决定模型精度的上限。当你用手工对特征进行组合和变换时，挖掘速度慢，或者不全面。那自动化特征工程干啥？

  1. 高阶特征。如用户在某品类下的订单数量，使用了用户和品类两个实体
  2. 快速特征选择：自动化特征工程（通常是笛卡尔积），会产生大量无效特征，使用lightGBM模型快速识别有效特征和无用特征，从指标提升级特征重要性角度考虑，剪裁没用的特征，重要特征与其它特征再次进行更高阶的组合

相较于DeepFM，DeepFFM算法，自动化特征工程有两个优势：

  1. 许多交叉特征如用户商品点击率有较强的业务意义，让模型直接感知组合好的特征往往比自动学习特征间的关系更为简单（相较于通过模型自动交叉学习要更优）
  2. 高维稀疏ID特征，DeepFM，DeepFFM等算法对这些特征的学习很难充分，自动化特征工程能给这些稀疏ID构造很强的特征表示

DevOps的初期代价

  • DO 分离后，运维不了解业务架构：业务架构必须沉淀

  • 分层运维边界模糊，全局协作效率低

  • 工具分散建设，也进一步推动告警泛滥的状况

    • 如用户端监控：测速、返回码、自动化测试、移动分析…

    • 业务侧监控：各维度产品指标、舆情监控、攻击防御…

    • 服务内监控：模块间调用、L5 失败率、组件监控、lvs…

    • 基础资源监控：丢包断线、死机重启、硬件故障、容量监控…

AI 的擅长点

  • 文本 NLP，与舆情监控一般可发挥内容理解能力
  • 基于时间序列的预测
  • 解决根因分析效果不好的问题（之前准确率只有 60%）
    • 基于 CMDB，但若 CMDB 管理不严，对分析极为不利
    • 若绕过 CMDB，基于 IP 做聚类分析，重新自发掘模块链分析
    • 通过告警关联规则发掘模块相关性，可进行权重发掘（如频繁集发掘算法）
    • 流量过滤点如网关易成为干扰因素，其扇出值太大、熵值高（可能的状态多）

监控数据挖掘

背景

  • 监控系统建设林立

    • 算是专业之道

    • 产生多维度监控数据

  • 无线互联网的监控比PC挑战更高，可出现的问题更多

    • 在手机端会增加更多千奇百怪问题，如IP变动导致用户被安全限制。

    • 跨省跨网也不利于接入调度，可能导致服务访问变慢

    • 例如安全限制投诉 50%、WIFI 鉴权投诉 12%、热点切换投诉 38%

  • 告警泛滥

如何做

  • 维度组合：综合查看指标，思考系统问题点（建模？）
  • 让告警更有效
    • 需识别生死指标
      • 不能设定阈值，靠波动判断
      • 只能有一个
      • 不用业务指标做生死指标
        • 在线数
        • 收入数
    • 去阈值「通过统计设定成功率滑动窗口（动态值区间）」
    • 与过去同比变化
    • 多维度汇聚（可做聚类分析）
      • 主被调
      • 返回码
      • 是否有版本发布
      • 网络变更事件
  • 根因分析：链路分析（链路本身是分层的）
    • 正向
      • 将告警投射到链路环节上
      • 从运维经验看，相临近的告警，后面的告警引起前端告警几率大
    • 逆向：干扰剔除，进行分类识别
      • 指向
        • 现象告警
        • 原因告警
      • 特征
        • 持续告警：不重要不紧急，65%
        • 波动告警：业务重要性决定，24% – 版本发布？故障自恢复？
        • 关联告警：有因有果，及时处理，10%，这才是值得精力投向所在

参考