AutoGLM 的场景和问题
2024-10-27
产品核心思路与技术原理
周末试了一下这个产品，整个产品思路是非常清楚的，就是通过语音识别用户意图分拆步骤，索引对应的软件完成相关的服务交付。技术原理上用的是手机的无障碍功能，整个技术路线是非常清晰的，从技术的实现难度上来说不是很难，关键要素在于用户的语音输入的过程里面对用户的意图识别并且进行拆解。
服务交付三步骤
分为三个步骤，第一是语音输入，第二是识别用户意图，第三是通过用户的产品来完成实施交付，目前它限定了几个场景，所以基础的实现难度不难。
产品优点：跨平台协作能力
先说一个优点，让大家意识到如何能让产品成为真正的跨平台体系运行，本身模型类产品要只在模型之内完成对应的交付，对于产品来说稍微有些单薄，所以能够调用系统里的其他产品完成协作服务可能才是开启人工智能服务的第一步。整个技术路线上也做了一些适配，至少对用户的常用行为做了分析，也做了一定的用户调研和使用场景的匹配，我理解这个问题背后的工程量没有特别大，拉一些主流 APP 的数据就可以。
模拟用户行为的准确性与优化
剩下的就是一些准确性和模拟用户行为的过程，因为这里面还涉及到一个会不会被系统或者应用本身断定为计算机行为或者进入了开启用户的验证模式，所以他要尽可能丝滑的模拟真实用户的使用方式和场景，这一点上可能经过了一些优化。
未来发展路径的探讨
当然个人对未来的发展是存疑的，从整个技术路线来说，它有几种方式来实现这个用户需求：
路径一：通过AI助手绑定账号，打通服务体系
第一种方式是将所有的用户数据打包到自己的系统里，就是相当于通过 AI 助手后台绑定用户的账号，打通到用户账号的服务体系，从而完成服务的过程，这一点就需要借助于用户在助手的账号里绑定其他平台的账号，也需要其他平台账号开放 API 接口，目前像打车和商旅出行等业务是基本上已经开放了 API 接口可以调用的，关于导航类的应用也可以跳转，至于其他的电商类的产品，目前都还是没有完全开放到其他平台可以直接调用 API 完成下单的过程，所以如果 AI 助手要完成服务的闭环的话，服务商会有支持的（垂直类服务），也有不支持的（平台类服务），但是对于用户来说体验的完整性是在这里完成的。
路径二：AI模拟手机操作行为（当前方式）
第二种方式就是现在的方式，通过 AI 模拟人在手机上的操作行为，这一点其实过往很多产品都已经尝试过这样的技术路线，像类似于 RPA 机器人或者说以前一些灰产手机，模仿用户行为做一些操作的助手都是可以实现的，本身没有什么技术难度，但是这条路线非常显然它的实现路径或者它的最终主导方式不在于各种助手类产品，最有效的方式还是通过手机自带的语音类助手，比如小爱同学或者 Siri，通过这样的方式让系统自带的语音助手来完成服务的接入和打通，这样对于手机来说是一个更有效的方式所，以未来这一入口大概率是由手机助手直接在系统级层面完成了，交给第三方工具的可能性不是特别大，或者让用户信赖第三方的权限来完成这个服务的可能性不是很大，准确性也要大打折扣。
两种路径的优劣与未来展望
显然这两种路径看起来第一种是非常难，但是对于用户有意义对自己产品也有壁垒的方式，第二种是大概率不太能长久运行，当然可以给手机厂商展现自己的技术能力也是一个方式，不过现在手机厂商自己都在自研自己的智能助手，对这个场景的普适性要存疑。
附注：语音识别准确度问题
注：AutoGLM 的语音识别准确度太低，几乎没有一次准确的。（当然也有可能是我口音太重？）