写点什么

社区供稿丨 GPT-4o 对实时互动与 RTC 的影响

作者:声网
  • 2024-05-29
    四川
  • 本文字数:5877 字

    阅读完需:约 19 分钟

社区供稿丨GPT-4o 对实时互动与 RTC 的影响

以下文章来源于共识粉碎机 ,作者 AI 芋圆子


前面的话:


GPT-4o 发布当周,我们的社区伙伴「共识粉碎机」就主办了一场主题为「GPT-4o 对实时互动与 RTC 的影响」讨论会。涉及的话题包括:


  • GPT-4o 如何降低延迟(VAD 模块可能也应用了 LLM?)

  • GPT-4o 怎么影响实时互动场景(分析了医疗、法律、教育、陪伴和客服等场景)

  • GPT-4o 应用到实时,也有不完善的地方

  • GPT-4o 为什么要用到 RTC(Input 场景 RTC 可以被视作解决方案。Output 场景 RTC 不一定是必须。)

  • 怎么选择 RTC 供应商

  • 实时场景对端侧的影响


另外,此次讨论会嘉宾史业民在我们的播客《编码人声》里深度解析了 GPT-4o 的能力边界,并基于实时多模态开发的一手经验,给开发者提出了不少建议,也欢迎收听。


这次讨论会的信息量极大,Enjoy!


本期讨论会参与者:


杜金房老师: 烟台小樱桃网络科技有限公司创始人,FreeSWITCH 中文社区创始人,RTS 社区和 RTSCon 创始人,《FreeSWITCH 权威指南》、《Kamailio 实战》、《深入理解 FFmpeg》作者,FreeSWITCH 开源项目核心 Committer。杜老师同时是 RTE 实时互动开发者社区联合主理人。


刘连响老师: 资深 RTC 技术专家,推特 @leeoxiang。


史业民老师: 实时互动 AI 创业者,前智源研究院研究员。


徐净文老师: 负责百川的战略、投融资、开源生态、海外等业务。



1、GPT4o 如何降低延迟

GPT4o 前调用 OpenAI API 延迟极限情况下可以压缩到 2 秒


  • 中美跨海光缆差不多 100-200ms,如果考虑丢包,那平均在 300-400ms。

  • 语音场景需要经过 ASR(语音转文本),在大模型无法流式输入的情况下,一般需要说完一句话再喂给大模型,平均需要 400-500ms 延迟。

  • 如果不考虑 Planning 和 RAG 等环节,只计算 First Token 的话过去平均需要 700-1000ms 延迟。

  • 大模型可以流式输出,但一般第一句话节后给 TTS(文本转语音),TTS 环节也需要 400-500ms 延迟。

  • 所以整体延迟最低可以低到 2 秒。

  • 上述场景主要是考虑的网络良好的情况,如果在室外体验,丢包概率会大幅增加,延迟还会再往上波动。


但在客服等场景中还经常需要做 Planning 和 RAG,延迟会进一步增加


  • 上述主要是可以用 First Token 来判断延迟的场景,对话内容比较简单。

  • 像在类似客服等场景,在 First Token 前还需要先做 Planning 和 RAG,就可能还需要经历 1-2 次完整延迟,整体延迟就会远远超过 2 秒,可能到 4-5 秒或者更高。


GPT4o 优化延迟的机制


  • VAD(Voice Activity Detection)提升:VAD 主要用于尽早发现用户说完话,用于触发大模型,过去用停顿时间判断,现在可能有了语义理解能力。

  • 端到端能力:端到端可以替换掉 ASR 和 TTS 的延迟,开发者未来可以用 GPT4o 的 ASR/TTS,也可以自己做。

  • 其他延迟优化还包括流式处理、异步处理,多个模块在向量画的过程中如何统一,在 GPT4o 的设计上有很多巧思。


VAD 模块可能也应用了 LLM


  • 之前有一些简单的 VAD 判断标准,比如停顿 1000 毫秒,就默认用户说完话了。

  • 但现在 GPT4o 为了节省时间,单纯用停顿判断肯定不可能,应该要走到语义层面。

  • 最极端或者暴力的方案,可以拿 GPT4o 的模型去 Finetune 一个小的 VAD 模型, 模型可以控制在 0.5B-1B 的规模,类似于向下降维打击的方式实现 VAD。

  • 这样对于 VAD 模型来说,Input 是 Audio,Output 就是说完与否的“Yes or No”。


GPT4o 后,还可以通过工程并发的方式进一步降低延迟


  • 在 GPT4o 前,工程角度已经可以在一些特殊场景,提前做好 RAG 等检索工作,然后再将 TTS 与 Output 等场景做成并行,通过很多工程做法,在不考虑跨海传输的情况下,有机会将延迟控制在 1 秒以内。

  • 现在在复杂一点的场景,甚至到 Planning 和 RAG 相关的场景,也可以尝试做并行进一步压缩延迟。

  • 基于 DSL(Domain SPecific Language)结果做 RAG、对输入的 Vision 和 Audio 做向量化预处理、刚刚提到的 VAD,这三个部分也可以做并行。

  • 现在还不确定 OpenAI 会不会开放着三个接口,从模型工程角度来说,如果这几个部分都做好,几乎可以把 RAG 的延迟都覆盖掉。


在做应用的时候还可以用一些鸡贼的产品体验进一步降低“延迟感”


  • 为了提高用户体验,可以在产品层面做一些改动。例如 OpenAI 的 Demo 中,在响应时间的过程里,手机中的画面会有波动的动画,在这个过程中,哪怕没有任何的实质性输出,人看到动画也会觉得亲切一些,对延迟的敏感度也会降低。

  • 在下面杜金房老师演示的视频中,也可以通过“嘟”的方式给用户起到心理安慰,“AI 马上就要说话了”。

  • 但这种场景也会有明显的局限,只适合用户已经知道对面是 AI 的情况,这种情况对延迟的容忍度也会相对较高。在不想让用户知道对面是 AI 的场景,这类产品功能也会容易暴露对面是 AI 不是真人。

2、GPT4o 怎么影响实时互动场景

有哪些实时互动场景可以开始做了


  • 类似 Hume.AI 等各种陪伴产品。

  • VR 游戏=Vision Pro/PICO 场景的互动产品。

  • 互动机器人,互动机器人加入实时互动能力后,对用户体验提升帮助很大。

  • AI 音箱,可能会出现新的落地场景。

  • 还包括现在也有在讨论车载互动能力,让开车的过程中没那么无聊,以及解放双手做一些车内的控制任务。


还有一些典型的行业场景,也很适合实时互动需求


  • 这些场景一般都非常个性化。

  • 出现的时候会比较紧急,一点点延迟提高都能带来使用者的体验改善。

  • 可以通过季节性、年龄等维度进行预处理,进一步减少延迟。


医疗进入实时互动可以大大减缓患者焦虑


  • 远程诊断咨询,个性化建议,都可以做非常多的实时性提升。

  • 疾病症状季节性集中度非常高,所以在 Planning 和 RAG 上可以做非常多预处理,可以压缩模型时间。

  • 即时交互可以解决心理焦虑,从用户端体验会变得非常好。像美国有个机构 Hippocratic AI 正在做,延迟大概在 5 秒,那等 5 秒的过程患者会非常焦虑的。因为机构 Hippocratic AI 是用视频/语音方式来解决的,所以需要差不多 5 秒延迟。模型在延迟上小小提升,就可以解决患者焦虑的状态。

  • 医疗场景中每个人都认为自己的小病是大事,但不一定很严重。如果能够更快的得到权威的回应,就在心理层面有很大的帮助, 甚至不一定要在物理层面上改善。只要是及时的回答,就可能能解决问题。

  • 医疗也要分场景,疾病会有轻重之分。如果是重症,那调用 Planning 和 RAG 的成分就会非常多,但大部分的医疗场景中,高频发生的还是小病疾病。比如小朋友发烧、老人摔跤、吃过敏药后忘记医嘱喝了酒等场景,不需要调用非常厚的医疗词典,也不需要让很多专家模型介入,这些场景的延迟改善会更加明显一点。在这些场景,5 秒到 1 秒的改善,对于用户体验的提高是非常大的。

  • 目前还没到 OTC 开药和重症阶段,现在短期还很难因为实时互动改变。但是比如心理辅助,比如患者就站在桥旁边,那实时互动就能立刻见效。


法律引入实时互动后适合现场处理场景


  • 过去的处理周期非常长:形成文档,然后通过人去解决。比如车险报警,过去是拍照上传、交警介入。

  • 现在有了 GPT4o 的实时机制后,非常多的裁决是可以现场发生的,当然最后处理部分还是需要人来介入。

  • 除了车险和现场暴力事件,剩下的还是一定程度能接受延迟。


教育引入实时后适合在线解题和语言教学场景


  • GPT4o 的 Demo 上就有在线解题。

  • 解题是个高度个性化的过程,还包括题库的应用,结合 RAG 和模型能力提高,再加上 RTC 的实时效果,在线教育领域的教学和辅助能力会有巨大提升,也可以做更多市场化的尝试了。

  • 过去需要上传,需要等待。那现在变成了更像辅导和学习伴侣的过程,在语言教学等场景,会实质性的改变学生的学习曲线和接受度。


GPT4o 后最快会是哪些场景能跑出来


  • 最直接的场景是陪伴,因为陪伴对 Planning 和 RAG 的要求低,只需要定义好角色背景和音色,而且非常适合应用到 GPT4o 的端到端场景。很容易就可以把延迟迅速降下来。

  • 客服等场景稍微复杂点,需要用到 Planning 和 RAG,延迟没有陪伴降的这么厉害。在这类场景里,延迟不是主要取决于端到端和 First Token,还要取决于整个 Pipeline 的系统级延迟。但如果做好并行机制和各种优化,也可以到 1-2 秒的延迟。

3、GPT4o 应用到实时也有不完善的地方

在触发机制等问题上还无法做到完全实时


  • 之前提到 VAD 的进步是延迟降低的一个关键是因素,需要尽早触发多模态模型,那就需要符合 VAD 的触发条件,在用户无法说话,或者 用户正在说话过程中的情况,大模型就无法触发。

  • 举一个例子,在 OpenAI 的 Demo 里有一个例子是两个人+一个 AI 互动,但如果假设 A 停了几秒,B 再去说,就会发现 AI 提前介入,B 的话就会被 AI 抢了。就必须要提前设计好 AB 角色以及 AI 对应角色的角色分析,添加更多的限定条件。

  • 在实时互动场景中,也需要 AI 能够在用户沟通中回复一些内容,可以更好激发用户去表达,现那也做不到。

  • 如果你要他说话之前就能回答,那还需要做很多工程工作,中间可能还会有误触发方案,但长期应该可以解决。这更多是场景决定的需求,例如实时翻译和需要插话的场景,要设置提前触发的请求规则。但在类似 Assistant 的场景,就不需要设置插话的提前触发条件。


具体举一些场景来看的话


  • 例如开着摄像头,要试试去看场景有什么变化,有什么危险,如果不设定定时触发机制,那 GPT4o 无法实时提醒。

  • 例如同声传译和语法纠错场景,需要在说话过程中就进行处理,或者实时纠错。这里也不能直接应用,因为 VAD 机制需要判断说完话。

  • 例如盲人眼睛场景,用户希望的是戴上眼镜就能实时感受路况。但现在的需要用户不断地问有没有违宪,或者工程上设置一个 1-2 秒的自动请求机制,来帮助 GPT4o 高频判断。

  • 总体来讲,GPT4o 如果是从助手级别(接收完人类指令),已经几乎完美了。但到了上述要更进一步的实时交互,还存在失望的地方,可能到下一代 GPT5 可以满足。

4、GPT4o 为什么要用到 RTC

GPT4o 为什么需要 RTC?用 RTC 的 LLM 会产生时空穿越??


  • 在 GPT4o 的 RTC 场景中有两个方向,Input 和 Output。

  • Input 场景中,LLM 需要实时接收用户的视频,人不能加速产生内容,为了降低 100-200 毫秒的延迟,RTC 可以被视作是必须的解决方案。

  • Output 场景中,RTC 不一定是必须,也可以用 WebSocket 等方案,链路存在但是开发者还没有大范围集成。

  • 与 Input 场景不同,在 Output 场景中, LLM 生成音视频未来可能做到两倍速,甚至四倍速、八倍速。那 Output 的 Token 生成速度会比时间还快,但是播放时候必须是一倍速,这就造成了在倍速场景中会有时空穿越的感觉,延迟实际上是负数。 只要解决首帧、First Token 的延迟就可以了。内容会因为生成比播放还快,而先预存在本地,然后再播放,就类似现在听网络小说、看视频一样。

  • 如果开发者有很强的优化能力,或者传输数据量没那么大的情况,提前做好 ASR/TTS 等,那可能可以不用 RTC。


LLM 可能还会影响新的 RTC 技术


  • RTC 行业发展这么多年了,已经很成熟了,看不到明显的增长了,LLM 出来后大家很兴奋,觉得应该能做点事情。

  • 最直接的交互方式还是语音和视频,也是 RTC 的强项,有些人在探索结合,也有直接转型 LLM 的。

  • GPT4o 出来后,大家又看了新挑战,比如做四倍速 RTC、八倍速 RTC,可能还会有新的 RTC 技术出来。

  • 我们现在很多假设都是 RTC 一倍的情况,未来 RTC 可能是两倍、四倍场景。那在正常情况下,比如 RTC 是 500 毫秒延迟,但是弱网可能就是 1 秒,稍微慢一点也能接受。但如果未来有了两倍速 RTC,那可能网络条件差了点,延迟还是在 500 毫秒到 1 秒之间,那也会有很大帮助。


但目前的 LLM RTC 需求还不复杂


  • 主要还是一进一出的场景。

  • 以前 RTC 场景里复杂的比如小班课,一堂课可能有几十路 RTC,就比一进一出高很多。

  • 难度可能还比不上直播连麦的难度,直播间里玩法也非常多样。

  • 未来也要看 LLM 玩法的迭代,越复杂的玩法需求越大

  • RTC 国内最大的是社交娱乐和教育,后面来来回回想了很多场景要起来,比如 IoT 等,但最后还是没起来。现在还不确定 LLM 会不会也是这样一个需求,谨慎乐观。


除了直接延迟外,RTC 在网络不好的场景,以及对打断有需求的场景有明显优势


  • 网络好的时候延迟差别不大。但是网络不好的时候差别很大,比如丢了个包那来回 200 毫秒就没了,如果再丢一个包那 20 毫秒又没了。TCP 是最后组件,前面的延迟炸了,后面也会累积。

  • RTC 做了很多抗弱网策略,加重传策略,包括猜测下一个声音做补全等。

  • 没办法直接给出和 CDN 延迟差多少,还是 Case by Case,只能说不好的情况下差比较多。

  • RTC 也适合互相打断,流式传输必备。CDN 不适合打断场景。



5、怎么选择 RTC 供应商

先讲讲 RTC 的发展历史


  • Google 在 2010 年收购了 WebRTC 技术公司,然后再 2011 年通过 Chrome 开放了 WebRTC 源代码,相当于 Chrome 就具有了实时能力。因为要做一套 RTC 引擎成本还很高,涉及到算法、编解码、各种规范,Google 开放 WebRTC 之前 有能力把 RTC 做好的并不多。

  • 2013-2014 就有第一波热潮,那时候出现了很多 RTC 创业公司,然后很快都接着死了。迎来了第一波低谷。

  • 2015 年出现了声网,后面国内也有几家。2016-20187,国内出现了上千直播平台,开始有了连麦的需求。然后紧接着 2018 年在线教育跑起来了。

  • 2020 年最大的一波来了,疫情期间,包括各种视频会议、在线教育等居家办公需求。

  • 疫情热度过后,RTC 需求就开始降温了,进入第二次低谷。


OpenAI 目前选择了 LiveKit,但未来 API 可能可以不与 LiveKit 绑定


  • 看全球的 RTC 供应商,除了国内的声网、腾讯 TRTC 等也多数不能打。

  • OpenAI 在选择方案的时候肯定非常谨慎,可能会更多考虑开放标准,也会考虑到中国公司的情况。如果是闭源方法,就会涉及到开发者怎么选择;不能绑定一家商业公司。在这个层面,LiveKit 是个非常好的生态位,你想用的话可以用 LiveKit 的 Cloud,也可以自己建。

  • OpenAI 现在也开始自己招人,那和 LiveKit 可能就是合作关系,前期可能会给一些咨询费一起共建,但后面可能还是会自建。

  • 未来可能是 ChatGPT 产品用 LiveKit,API 端可能不绑定 RTC。


未来客户可能也能使用商业 RTC 方案


  • 现在给不出一个准确的答案,这个要取决于 OpenAI 的决策。

  • 但推测 OpenAI 可以采用一个开放的标准,让各家产品都可以接入,这是一个更加平台风格的选择。

  • 比如客户想做成商业产品或者在全球应用,那就采用商用方案,这是最省研发成本的。


使用 GPT4o 不一定必须用其自带的 TTS


  • TTS 都在一个大模型里面,对开发者不是那么友好。

  • 比如 Hume.AI,已经带有情感 TTS 的,那怎么和新 4o 去闭环;客户不一定能接受 OpenAI 现在给的几种声音模式,会有更多样化的需求,比如更像某个人的声音(定制化的),或者更卡通化等风格需求。

  • 那可能 4o API 最好同时支持 Voice 出和 Text 出。


各方是怎么看要不要用 RTC 的


  • 模型公司角度很可能会优选 RTC,成熟,可拓展性也好,同时可以开放给开发者不同选择。

  • 开发者角度,延迟还是越少越好,越实时互动的场景越需要 RTC。

6、实时场景对端侧的影响

Vocie Assistant 场景对于端侧硬件的要求


  • 如果全部使用 GPT4o,端侧只接收视频,就几乎不需要算力

  • 如果要将 VAD 技术放在端侧,那端侧就需要一定算力。但总体会远远低于 LLM 的算力。


对 RTC/RTE 感兴趣的朋友也欢迎访问 RTE 开发者社区:


https://www.rtecommunity.dev/


最后我们放一张本次活动的听众 Agent 创业者 王轶老师 参与互动后画的一张图,也比较清晰的展现了 RTC 引入后 LLM 的流程变化




用户头像

声网

关注

还未添加个人签名 2021-02-05 加入

声网(NASDAQ:API)成立于2014年。开发者可通过声网API,在应用内构建多种实时音视频互动场景。使用声网服务的包括小米、陌陌、斗鱼、哔哩哔哩、新东方、小红书、HTC VIVE 、Yalla等遍布全球的巨头、独角兽企业。

评论

发布
暂无评论
社区供稿丨GPT-4o 对实时互动与 RTC 的影响_声网_InfoQ写作社区