当前位置: 首页 > article >正文

基于asr的所见即可说方案

年前写的文章对所见即可说方案进一步调研-CSDN博客,针对rk3568定制版,进行了Accessibility实现所见即可说功能的验证与调研,结论是不可行。

最终解决方案是:结合科大讯飞的AI大模型智能助手,使用rk3588板(3568性能太差),实现了所见即可说方案。

方案简述如下:

1、提示词唤醒AI --> 截屏 --> ocr文字识别 --> 热词上传到科大讯飞AI平台

2、语音下达包含热词的指令 --> asr平台返回消息和语音 --> 根据asr的框架解析出意图 --> 根据意图判断是所见即可说指令,并解析出热词 --> 根据ocr解析结果,获取对应热词的坐标 --> 模拟点击 --> 点击特效

这套方案不难理解,但是个人开发者难以实现。因为首先需要asr会员账号、asr的ocr算法和AI意图解析框架。然后将ocr算法集成到流程中,实现一个热词上传接口(参考asr文档所见即可说实体-交互大模型版本)。最终将截屏、模拟点击、点击特效等小功能串起来。

串流程容易,但是需要对大模型相关的技术有一定了解。

2025-02-06-16-17-24-screenshot-ocr-hotword

此方案,我认为还是偏过渡性质。本身还有好几个缺陷。

截屏和ocr带来的延时,采用的傻瓜方式,每次唤醒AI都需要做一次这些动作。

ocr算法也有一些bug,有些文字会识别不出或者识别错。

asr网络平台的稳定性也不太好。

直到项目完成也没有想到更好的办法,如果要提升性能,就会考虑像截屏这种能不能并发的操作,但是ai语音识别需要先保证上传成功热词。只有热词已有的情况下,才能正确识别语音,得到想要的意图,否则可能识别出来的是谐音的其他文字。

而上传热词,需要ocr,ocr需要截屏,是线性依赖的。

那么是否可以在前端页面每次切换时,只作一次截屏+ocr+热词上传,如果是只在当前应用内部的页面,是可以简单做到的,前端调用一个接口就行。如果是在其他应用页面上,就无法做到了。需求是要求支持第三方应用的。

反倒是当前这种AI语音控制的方式,无论是当前应用还是其他应用,都可以普适。

所以,这也是一个折衷的普适方案,而且延时1s不是那么明显,等AI语音助手说完话,在作第二轮语音交互,也很自然。唯一的就是可靠性这方面略差了点。


http://www.kler.cn/a/536870.html

相关文章:

  • Baklib赋能数字内容体验个性化推荐提升用户体验的未来之路
  • BUU22 [护网杯 2018]easy_tornado 1
  • 0207算法:寻找目标值、库存管理
  • 组合(力扣77)
  • 1-R语言概述
  • flappy-bird-gymnasium
  • oracle基础语法
  • Ubuntu系统 Zabbix 7.2LTS一键部署脚本
  • spring的事件驱动有时候比消息队列好用
  • 【Docker】 Manifest与Buildx:多架构镜像管理的解析与实践
  • 自己做了个微信小游戏:推一个箱子
  • 基于钉钉API的连接器实现:企业数据集成与自动化管理
  • 大模型产品Deepseek(五)、本地安装部署(Docker方式)
  • 【C语言】数 组与指针:深度剖析与等价表达
  • 力扣240 搜索二维矩阵 ll
  • golang命令大全13--相关资源与学习路径【完】
  • <论文>DeepSeek-R1:通过强化学习激励大语言模型的推理能力
  • python-leetcode-除法求值
  • UML学习
  • 【dotnet】安全编码规范
  • 【清晰教程】通过Docker为本地DeepSeek-r1部署WebUI界面
  • 2025年2月2日(多任务 线程)
  • vue3 的 onScopeDispose 是什么作用
  • 【数据结构-C语言】绪论
  • 0207算法:寻找目标值、库存管理
  • 101.对称二叉树 python