场景AI技能与热更新机制

1. AI应用的碎片化趋势

在安防、交通、金融等领域,人工智能(AI)已经得到了大规模的落地应用。随着数字化和智能化的发展,AI的落地场景也变得越来越多、越来越场景化,逐步渗透到城市治理、工业生产、能源和化工园区等诸多领域。然后碎片化意味着很难标准化,很难标准化意味着边际成本无法有效降低。只有解决了这个难题,才能让AI更好、更快的落地到千行百业。

2. 如何让AI能力场景化

常规的计算机视觉任务包括检测、识别、跟踪、分割等,在实际落地场景中使用得最多的就是人、车、物的检测和识别。从数学或信息角度,CV算法就是把非结构化的图像数据变成结构化和半结构化(特征向量)数据。AI能力更多的是一种底层能力,如何把这种底层能力包装成各种场景中特定的业务能力,需要根据场景来做特定的开发。但是具体的行业千差万别,很难用一个通用的产品来满足千变万化的需求。

场景化AI处理过程的抽象

通常我们用AI视觉来解决的问题,本质上是让机器代替人的工作。而之前人的工作主要就是监控并发现问题,在发现问题的时候及时触发告警,必要的时候还要进行干预。把这个过程进行抽象,我们就可以让一个模块持续的“看”视频流内容,智能识别和理解画面内容,判断画面里的是否有目标对象、目标对象是否有特定的行为或表征。一旦检测到特定的目标或行为,就可以触发告警产生“事件”。同时,这个事件会带上一些结构化的基本信息(如目标对象的位置、标签),以及一些附加信息,比如包含特定目标或行为的evidence截图,还要截取一段对应的小视频,方便处理事件的人去查看。

按照上面的过程,对于视频监控的分析就抽象成抽取事件的过程。不过不同场景下,抽取的逻辑是不一样的。举个简单的例子,如果要判断一个人是否离岗,那么我可能需要先在图像区域先画出工作区域,然后通过AI算法检测出这个区域是否一直有人,如果持续一段时间都没有发现工作人员存在,那么就可以触发一个离岗的“事件”。

技能模型抽象

但是对于另外一个场景,可能这个事件的判决逻辑完全不同,我们可以把某个场景下完成特定功能的判决代码抽象成一个插件。另外不同场景下,即使判决逻辑流程是完全一样,中间使用的一些参数也是不一样的,这些参数可以抽象成参数传递给技能插件模块。基于这样的抽象,我们可以通过一种描述语言来定义这个场景技能。判决逻辑代码部分称之为技能插件,参数和配置方面则是技能参数。当把视频图像帧喂给技能插件模块时,技能插件模块就基于插件里的代码逻辑和技能参数进行处理和加工,判决是否要产生事件。

技能插件和技能参数两者可以独立的管理维护,两者更新的频度也不太一样。通常来说技能参数可能会比较频繁的更新,而且粒度会比较细,可能每个设备的技能参数都不一样。技能插件的更新则相对低频一些,除了新场景需要开发新插件外,即使是旧插件的版本更新,也会考虑代码的质量和稳定性,一般需要经过严格的测试才会进行大规模的更新。

3. 场景技能的热更新

一般说来,这些场景AI技能逻辑可以随着设备的程序一起发布,但是也会面临更新的问题。对于设备的固件程序,我们可以进行OTA升级,不过OTA升级也会带来一些问题。一方面OTA升级会让整个系统中断服务,另一方面,OTA升级需要升级的程序包的大小也更大,再者OTA升级的风险也相对较高。鉴于此,通常OTA的频率都会比较低,但是我们对于技能插件和技能参数的更新却会比较频繁。用户随时都可能开启新技能或更改现有技能的参数配置。

动态热更新的方式

对于嵌入式平台而言,基本都是拿C/C++实现的业务代码逻辑。对C/C++比较友好的热加载方式就是动态链接库(.so)。除了能做到动态加载与卸载,对性能方面也几乎没有什么影响。但是需要注意的是so方式加载对接口的signature要严格保持一致,否则就会出现问题。这里就要求对技能插件的接口有较好的抽象封装,能比较灵活的适应各种场景的技能。交换的信息格式也要用json、xml之类的灵活的数据格式。

对于资源相对丰富一些设备,可以嵌入lua,javascript,python等其他脚本语言通过混合编程来实现AI技能的判决逻辑,不过这些脚本语言需要调用底层的AI算法模型来处理图像数据,所以外层的业务代码需要把基础的AI能力包装好后以回调函数、JNI等方式注册进来供脚本调用。

技能插件管理平台

终端支持了插件的热更新后,那么云端也需要有对应的管理平台来管理这些插件以及它们的不同版本。插件的开发者和AI模型的开发者都可以在管理平台上上传自己的新技能插件、新AI算法模型,也可以以新的版本更新之前旧的版本。

新增或更新技能插件后,需要有一种机制让终端设备感知到,并在合适的时机进行拉取和更新。管理平台需要提供一些灰度、分批、强制的机制,控制好升级的量级、突发和并发的流量,降低对平台的开销。还要考虑好如果升级的技能插件存在问题的应急机制(比如回滚方式等)。

设备与技能的关联

如果技能插件做成了一个开放的平台,那么用户就有丰富的技能插件可以选择。但是毕竟AI算法是运行在终端设备上的,终端设备的算力无法扩充,哪怕用户愿意付费,也不能让一个终端设备承载超过其计算力的技能插件。需要有一种控制策略来管理设备与技能的关联匹配。通常来说,根据技能调用的AI算法模型和对应的频度,是可以计算出对应的算力、内存等资源消耗的。对于终端设备也能知道当前已经加载的技能插件以及剩余的计算、存储资源的。有了这两方面的信息,就可以在用户为设备关联技能时,做不同的策略。比如,可以让用户只看到这台设备的资源还能承载的技能列表,也可以让用户看到所有的技能,但是当添加关联时,动态判断资源是否允许,对于不允许的关联予以资源不允许的提示。

可视化配置

前面提到了技能插件和技能参数的抽象和管理,这里再提一下一些特殊的技能参数。通常我们只对画面中的一部分区域感兴趣,就需要人工对画面的区域进行一些标定,这些标定的区域就是ROI(Region Of Interest)。像这种技能的参数不太可能通过填入坐标数值的方式配置,而需要提供一种可视化的交互方式,让用户在截图或实时视频流画面上,手工框出感兴趣的区域。对于其他一些普通的判决门限,逗留时长等含义明确,方便输入和选择的参数,则可以直接在表单里配置。

4. 事件的消费

场景AI技能产生出来的事件,可以有多种消费方式。一方面可以实时的触发场景联动或告警输出,另一方面,可以把这些事件进行二次挖掘,做各种更深层次、更大覆盖度的数据分析。比如可以检索出一定时空范围内的人、车的轨迹;可以根据目标对象的一些特征进行全时空范围的检索。

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇