悦华舞天
用户194
Share
分享
(未完成)AI实时语音通信(全双工方案)
输入“/”快速插入内容
(未完成)AI实时语音通信(全双工方案)
用户194
用户194
2025年7月16日修改
写在前面
已经是比较老的东西了,应该是2024年中写的,本来想作为自己私有资产的,后来想想算了,公开出来算了。
代码实现了60%,实验没有完整做完,效果未实测,理论应该可行。
看得懂的朋友可能不太多,看懂了觉得不错点个赞就好啦。
背景说明
本POC是为了验证一个思想方案:将AI静态语音通信,转变为实时语音通信。
传统AI语音通信的链路是:
音频输入-》音频输入结束-》静态音频文件-》语音识别音转文-》大模型文生文回复-》语音合成文生音-》音频回复
有几个要点:
•
整个链路的处理开始以及音频回复,必须等待音频输入结束;虽然工程上可以通过用户侧的静默,判定输入结束,但这不改变前面这个事实。
•
音转文和文转音都可以流式并且速度较快,大模型生成速度大约是20token/s,20-30汉字。
•
服务端和客户端之间的通信延迟主要取决于音频输入和输出的buffer大小,使用webrtc这类协议可以让延迟在1秒附近。
•
人类说话速度大约是3-5字/秒,所以实际链路处理速度远大于输入速度。
所以这里表现出的产品问题主要有:
•
端到端耗时较长。推测主要原因是大模型推理速度较慢(假设是20token/s,大约20-30汉字),较长的文本输出时,生成耗时较长(例如80字左右需要4s)。同时整体链路的启动需要等待音频完全的输入。
•
不允许回复侧打断输入;当然工程上允许用户中途的输入打断输出(等于是输出完全终止)。
预期实现效果
•
超低延迟:
◦
大模型推理必须在音频输入过程中就开始进行,以此降低音频输出延迟;
也就是所谓的流式输入模式(这个比较超前思维,希望大家结合下面看得懂)
◦
输入和输出buffer需要比较小(但是又在一个合理的尺度)
•
双向可打断:
◦
用户中途输入打断输出(工程上可解决)
◦
模型音频输出可打断用户,当用户输入卡壳,无意义,或者用户输入需要被澄清,反驳,或者模型角色设定性格比较着急。
•
双向附和音
◦
模型音频输出“嗯,嗯,是的,好的”等,属于中途附和,不是打断。
◦
用户输入“嗯,嗯,是的,好的”等,属于中途附和,不是打断。
•
主动发音:用户静默一段时间之后,主动发音维持对话
•
主动挂断:长时间无响应,可以主动挂断。
技术实现
选型
•
音频输入和输出:python sounddevice
https://github.com/spatialaudio/python-sounddevice
•
音转文ASR:阿里云流式ASR
https://help.aliyun.com/zh/isi/developer-reference/sdk-for-python-2?spm=a2c4g.11186623.0.0.76ea600d5NRphZ
•
大模型:minimax chat completion pro
https://platform.minimaxi.com/document/guides/chat-model/pro?id=64b79fa3e74cddc5215939f4
•
文转音TTS:minimax流式TTS
https://platform.minimaxi.com/document/guides/T2A-model/stream?id=65701c77024fd5d1dffbb8fe
技术初步推测
•
音频输入环节,使用流式输入或者buffer(长度固定or不固定)的切割输入
◦
同时给出静默符(例如0.5秒的静默),看工程上是否能实现
•
音生文环节,流式输出
◦
同时给出人声静默符(例如0.5秒没有音生文输出,则给出一个流式的静默文本符号)
•
在大模型文生文环节,使用流式输入与实时生成(阶段式生成)方案,方式如下:
◦
将Q拆为q1 q2 q3 ...
◦
第一次模型推理 q1->,得到a1
◦
第二次模型推理 q1 q2 a1->,得到a2
◦
...