一次直播和图像识别技术应用的探索之旅

背景

Think Better。

很多行业都在“卷”，作为金融科技行业的信也，也不例外。除了卷云计算、大数据和人工智能这些非常有深度的技术以外，信也向着技术融合创新的方向逐步探索，做得更好一些，为用户提供更好的价值，才是卷的目的。

起因

在金融科技行业的业务场景中，有一个比较常见的业务就是”授信“，例如给用户提高额度，那么就需要用户提交一些资料，来证明其还款能力，以提高授信额度。常见有的：提交车辆信息、税务记录、工资卡流水记录或学历认证等等。一般在产品功能设计中，给用户提供上传截图的功能，获取相应的资料，再通过风控系统与业务系统的核验，以满足业务流程的需要。某些业务场景在对反欺诈诉求要求比较高的情况下，人工介入审核资料也是比较普遍的做法，但实际上，这是一个“斗智斗勇”的过程，因为收集到的资料很有可能不是用户本人或 PS 过的，很难保证真实性。在传统的业务模式中，风控系统的成本很高，上传多张截图并进行后续识别认证，用户体验也不太好。

一个思考就来了：怎么能够降低风控成本，提升用户体验？

仔细想来，前面说的过程实际上就是一个“静态”的资料提交审核过程。这种“静态”的过程是个黑盒，一是无法得知用户获取资料的过程信息，二是资料获取后，难以进行违规操作的检测，避免造假。

如果整个过程中，有“一个人”在指导用户操作，并且全程检测呢？

用一个“程序”去看直播

将静态过程转变为动态过程

前面提到的老流程，是黑盒，难以实时风控策略，如果设计一套系统，让程序像一个人一样，从一开始就介入，指导着用户现场操作，并全程录制并检测违规操作，那么就可以大大提高用户体验，增强反欺诈能力。思考这个程序的功能，可以得出，其须有识别和录制的功能：

1. 用户操作的整个过程，可以使用屏幕直播推流的技术，让这个程序从一开就看到用户的屏幕，并记录整个过程
2. 程序可以通过语音，告诉用户应该如何操作，跳转到哪个网页或者打开哪个 App
3. 当用户达到指定的页面的时候，程序则可以将业务系统需要的信息截取保存下来
4. 这个程序必须聪明点儿，它看着直播，还得能看懂直播，必须能仔细观察，看到哪些行为是违规的，理解力则依赖：图像识别技术

直播的选型与实践

主流直播的技术方向有两个：

1. RTMP+CDN
2. RTC+SD-RTN

选型一般要考虑使用场景，直播的场景一般为一个主播推流，上万人观看，但我们这个场景稍微不同，是一个程序在“看”，没有其他观众，并且对实时性要求较高，所以 RTC 是首选。

一个 RTC 的数据包数据格式如下：

0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0xc8     |   packet sequence number      | default to 0  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|1|  CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier            |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |       0x10    |    0x00       |           length=0            |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |                         RTP payload                           |
      |                             ....                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTC 在移动网络下，最大的挑战是弱网或断网下的稳定性表现，发生卡顿和中断会影响用户体验。解决这类问题，业内一般使用多链路传输技术，例如苹果的 MPTCP(Multi-Path TCP) ，在手机网络切换 Wifi 和蜂窝网络或网络网络丢包较高的情况发生时，多链路的使用，可以大大增强稳定性。但这种技术也带来了高功耗和高流量。那么使用 弱网冗余传输 来就可以优化这种情况，即在 RTC 检测到弱网环境下才开启双链路的传输。

另外，还需要使用 FFMPEG 来当做看的“眼睛”。但很遗憾，FFMPEG 并不支持直接对 RTC 视频流的读取，那么就必须将 RTC 转换为 RTMP 协议，因为 RTMP 在大规模观看的时候需要启用 CDN 网络来进行分发，而 RTC 转 RTMP 在服务端侧完成内网转发，则避免了这个问题，FFMPEG 在使用的过程中类似于如下命令:

ffmpeg -i "rtmp://boliu.koofenqi.com/koo-tuiliu-test/testneo?auth_key=1684307737-0-0-52941de184ba86a371f8fd36d030b723" -vframes 1 -r 1 -q:v 2

拿到视频流信息则可以交给识别部分来让程序理解当前屏幕上的内容。这部分的流程如下图：

识别技术的实践

当源源不断得到屏幕的视频画面的时候，如何识别当前的画面是目标页面或者是存在违规行为的画面，那么有两种实现思路：

1. OCR 图像转换为文本，使用正则表达式来达到检测目标文本特征或异常文本特征
2. 利用特征提取技术，识别图像中是否存在目标元素特征

OCR 技术有一个问题：即页面较为复杂的时候，文本转换时间不可控，不太满足实时性的要求。那么利用体征提取技术，则可以避免此类问题的发生。

在此种图像识别技术方案下，一般分为如下子任务：

• (a) Image Classification： 图像分类，用于识别画面中元素的类别（如：bottle、cup、cube）。
• (b) Object Localization： 目标检测，用于检测图像中每个元素的类别，并准确标出它们的位置。
• © Semantic Segmentation： 图像语义分割，用于标出图像中每个像素点所属的类别，属于同一类别的像素点用一个颜色标识。
• (d) Instance Segmentation： 实例分割，值得注意的是，（b）中的目标检测任务只需要标注出物体位置，而（d）中的实例分割任务不仅要标注出物体位置，还需要标注出物体的外形轮廓。

当预设目标页面的元素出现，则可将图像的语义转换为置信度、风险度等结果输出给程序，进行业务判定。

这个“程序”有点普通但也有点意思

一个流程引擎，支援业务流程的执行

这个程序像一个引导用户做流程的业务员一样，那么它具备以下功能：

1. 熟悉各种业务流程，按照业务流程的规定，进行业务流程的执行
2. 一直维持着与客户端的通讯
3. 指挥客户端、直播服务、图像识别服务、反欺诈服务进行协调工作

那么这个程序实际上就是一个流程引擎，在整个流程引擎的架构设计中，需要考虑如下几个方面：

• 长连接性能指标，例如：
  • 吞吐(Thoughput) >= 1000
  • Latency <= 100ms
  • Concurrent >= 500
  • Error Rate <= 1%
• 保证安全性
  • websocket 握手令牌校验
  • 消息体二进制编码
• 流程适配性强
  • 业务节点配置化
  • 客户端预置指令模块化
• 全程做到实时监控
  • websocket 通讯监控
  • 流程执行监控
  • 客户端异常监控
  • 服务异常监控
• 客户端兼容性达标
  • iOS/Android/HarmonyOS 兼容覆盖
  • 主流机型兼容覆盖
  • 各种网络异常兼容覆盖
• 稳定性强
  • 业务单元执行异常恢复
  • 网络通讯异常恢复
  • 客户端与服务端的系统异常恢复

整个流程引擎的架构设计如下：

在前面，流程引擎维持与客户端的通讯，使用 websocket 长连接服务。一个典型的长连接服务如下图：

在安全性方面，使用令牌技术，在 websocket 连接发起的时候，检测令牌是否有效，避免非法客户端的连接，并且数据传输防止信息泄露，通讯的数据包使用二进制流，那么在编码方面，选用 protocolbuf，来实现客户端与服务端的传输数据的序列化和反序列化。

多技术的融合应用达到的效果

一套 WebSokcet/RTC/FFMEPG/ImageRecognition 的技术组合

将这些技术进行融合以后，例如需要用户通过自己的机动车信息来提升额度的话，就可以这样完成：

1. 用户手机通过 websocket 连接上服务端
2. 流程引擎启动，指引客户端发起屏幕 RTC 推流
3. 根据业务流程配置，使用 FFMPEG 处理屏幕视频画面
4. 图像识别服务将画面进行标定与检测，确认业务信息的截取
5. 服务端对整个视频画面进行录制保存
6. 流程引擎时时刻刻执行反欺诈策略，检测用户操作是否存在违规和欺诈行为

当这样一个融合多种技术方案的探索落地以后，便诞生了可以满足各个业务场景使用的 _ 推流认证平台 _。

目前，_ 推流认证平台 _正服务于一些对风险要求较高的流程中，该平台可以让用户不再手动操作繁琐的流程，只需要听着语音点一点，平台将自动获取资料，完成后续流程。

这样的多技术融合的探索，是一种有意思也有相当业务价值的尝试！

探索的脚步永不停歇

未来，将会有更多有意思有价值的探索持续进行，创新的源泉来自热衷思考，敢实践，不怕失败的解决各种问题。展望未来，后期还有更多可以持续优化创新的地方：

1. 业务流程引擎使用 webassembly 技术，形成安全的二进制程序，结合边缘网络(Edge Network)，实现离线的流程执行
2. 图像识别采用卷积神经网络，训练更优秀的识别模型，为风险识别提供更多的基础能力
3. 使用移动端的机器学习技术，利用手机本身的 AI 算力，加载图像识别模型，进一步缩短业务流程时间

作者：Neo，现任移动研发专家
来源：拍码场
原文：https://mp.weixin.qq.com/s/D87RZhQAQP_LRZjjcARl4g