很好也很贵？OpenAI Realtime API 一手体验和 Voice AI 的未来

本节目由津津乐道制作播出。

各位听友大家好，

这里是二 t 开发者社区与津津乐道博客网络联合制作的博客节目编码人生。

我们新的一期节目又跟大家见面了。

今天呢正逢我们假期结束后的呃第一天，

然后我们的节目就新鲜上线了啊，

但是在上线的之前呢，

必须要跟大家来发出一个技术大会的邀请。

呃，

十月份十月二十五号到十月二十六号，rte 开发者社区和声网共同举办的 rt 二零二四大会将在北京举行。

啊，

其中呢有很多的技术论坛，

还有一系列的技术的周边活动，

那都是由我们二 t 社区一起来策划的。

今年的技术论坛呢还是覆盖了音视频技术，ai 生成视频 boys，ai 多模态大模型空间计算和新硬件云边端架构和 ai 等多个热门的技术话题。

呃，

这个话题还挺多的。

然后而且呢我们还做了一个呃市集的活动。

这个在后面的节目里面呢，

我陆续的也给大家放出一些细节啊，

我们津津乐道科技论盾编码人生的主播呢也会到现场和大家来互动。

如果大家想到现场跟我们互动的话呢，

也欢迎大家来参与我们的大会。

然后呢，

我我们的听友当然不能花钱买门票了，

对吧？

呃，

大家可以通过节目里面 sonote 里面的链接来报名限时的获取编码人生听众专属的限免门票啊，

期待和大家一起探索实时互动的更多。

可能十月二十五号到十月二十六号我们北京见。

哎，

那我们回到节目上啊，

今天这个节目也是蛮有趣儿的。

因为呢呃大家都知道，

在假期之前呢，openai 发布了它的 realtimeapi。

唉，

终于啊千呼万唤始出来。

呃，

之前呢我们看了它呃呃四欧的这个多模态的形式的这个发布会，

但是我们一直在期待呢。

哎这个东西我们什么时候能调用啊，

什么时候能用啊？

其实大家也等了很久，

哎，

这次他终于发出来了，

是吧？

给了大家一个 viewtime 的 api。

然后呢我们最近这几天呢也有很多的朋友，

包括我们自己也去做了一些试中，

但是呢还是想跟大家去聊一聊这个 realtimeapi 以及背后的一些呃故事吧。

所以今天我们请到了两位在这个领域沉浸很久的嘉宾啊，

甚至说是这样一个跟 openi 对接的这些开发者。

甚至在比我们更早的时间，

就已经开始跟 openai 那边去对接的这些朋友跟我们来分享一下关于 openai 新发布的这个 realtimeapi 背后的故事。

那详请两位的嘉宾呢先介绍一下自己，

好吗？

从呃从普列斯开始吧。

大家好，

我是普列斯。

然后我是那个开源那个实时多模态 ai 框架的一个联合发起人。

呃，

然后其实我们这个项目的话，

基本上在半年前当时四欧发布会上发布他们第一个呃视频的时候，

我们就已经开始筹备和在做了。

那当时的愿景就是说哪每天搜呃的语音接口出来了，

我们能够让所有开发者快速的接上啊，

那最近的话也是十月一号真正的发出来了。

那确实我们在发布后，

我们也第一时间提供了基于我们框架做的那个 openai 呃语音实时接口的一个 extension。

呃，

就类似一个积木可以快速放进去，

帮大家集成的啊，

并且提供了那个可以实时体验的一个 demo 啊。

大家有兴趣的话，

可以多关注一下我们社区的一个项目和我们体验的一个链接啊。

我这边主要就这些。

哎，

那能不能多给大家来介绍一下你的这个 turnframework 到底是做什么，

让大家有一个更深入的了解呢？

这样的话大家后面来听你的分享，

也更容易知道你的背景啊。

看框架的话，

本质上是我们为了解决在那个多模态 ai 呃出现之后，

我们发现其实针对以前那波做 ai 的同学，

就可能更多大家接触的是纯文本相关的一个模态。

一般在四 o 发布之后，

我们发现 ai 的交互模态它大幅增加，

它增加了至少音频和视频的模态。

但是增加了这块模态之后，

其实会对我们的集成工作啊，

包括我们需要处理的问题的话，

会复杂度会增加很多啊。

比如说音视频传输的话，

你就很很有非常可能需要用到实时音视频传输的技术啊，

包括那个 rtc 的技术和那个设备采集嗯三 a 处理。

那这些技术的话，

其实对原来做 ai 的那一波人其实不太熟的啊，

他们就会觉得去接这块东西非常的困难啊。

但是同时对同时对于另另一边另一波做音视频人来说呢，

其实 ai 这一块就是一个对他们来说不太熟悉的领域。

那所以我们做这个框架在初衷，

就是希望能够基于这个框架，

能快速的把这些音视频能力和 ai 能力模块化提供出来。

让大家可以更快的把自己擅长的部分，

形成可复用的积木。

让相关的呃相关的从业者开发者可以把这些积木快速的拼装起来，

去形成一个和 ai 语音语音语音图语音或者说视频图视频啊这样的一个多模态实时交互的一个场景，

能快速搭出来。

啊，

这也是我们这个框架最初成立的一个愿景和一个想要实现的目标啊。

哎，

那我能不能理解成你们做的其实是一个实时音频视频，

或者叫实时 ai 领域的 define 呢？

呃，

可以这么说，

但是会有些区别。

就是我们会认为迪拜现在更多是偏向于那种流水线式的 workflow 式的一个编程。

他们其实更关注整个 workflow 最终的一个结果的准确性。

呃，

但是我们这个框架的话，

呃，

他从 dayo 考虑的就是是最关注的就是就是知识。

所以中间你可以去编排这些流程。

但是呃 ai 它在任何回答的过程中，

它的数据都必须是流式的。

同时 ai 需要能够实时的响应一些状态。

比如说你需要能够实时的打断 ai，因为你不希望 ai 把所有的话全部说完，

那这些能力的话我认为是迪凡没有的啊。

对 ok 那好吧，

那一会儿让你去展开聊聊这个合作啊，

因为你可能跟他们接触的会比较深。

那有请我们下一位嘉宾来介绍一下自己吧。

哎，hello，我是 cage，我是石像呃的 airesearchlead。

然后主要做的事情就是在研究，

并且投资各种各样 ai 的最头部的独角兽。

然后我们主要有一个比较优秀的内容平台，

叫做海外独角兽当中发布的内容就是海外各类 ai 技术和公司的最前沿进展。

并且把这当中相关投资内容的研究开源发布在我们的平台上。

在海外独角兽上，

我们主要发布的是关于海外头部 ai 独角兽的最前沿的研究。

比如说在两个月前，

我们发布了关于四欧最呃比就比较前沿的研究叫做 voicevoiceagents 研究就当中提到了到底哪一些呃有声音有关的独角兽会受到影响。

到底呃四 o 这种模型，

尤其包括我们今天聊的 realtimeapi 会在哪些领域真正落地。

然后也包括在呃大概半个月之前，

在博文发布之前写了一篇叫做 iom 的范式，

转移 ro 带来新 statelaw。

对强化学习这个技术路线做了分析和预测。

然后所以我们就会做这些最前沿的研究和并且做相关的专题和讨论。

然后在加入十项之前呢，

我在字节做过 datascientist，在 cmu 做到 alnlpresearch。

对，

这差不多是我的呃对我的介绍。

那你应该是一个市场的观察者和一个研究者了啊，

是是对嗯哎所以今天我们是这个搭配啊，

跟大家聊聊啊。

今天我们 openai 啊推出的 realtime 的 api。

哎，

那普雷斯能不能跟大家介绍一下？

因为肯定还有很多的朋友呢是刚刚打开电梯的，

对于这个 real 没必变，

还不是特别特别了解，

尤其它是在假期之前发布的，

大家有很多人也没有来得及试用。

那是不是先跟大家去聊一聊呃，

这个产品的盖帽，

它到底发布出来之后解决了什么问题，

提供了什么样的能力。

甚至说你可以聊一聊，

嗯，

怎么跟他们去合作的。

嗯，

是不是可以跟大家介绍一下这个背景信息呢？

啊，

其实说嗯它是一个怎么样的一个东西的话，

呃，

有关这个具体的效果。

我我认为从那个半年前四 o 发布之后，

很多开发者已经在尝试了。

比如说大家会通过语音转文字，

然后把文文本给到大模型，

在文本给转给出来之后，

转成语音再送回来。

啊，

所以这样的呃语音对话场景，

其实大家在这半年来已经有很多的探索了。

啊，

但是那个欧 eni 这个 realtimeapi 它出来的更多的一个东西，

就是说它一个排除了这些 stt 和 tts 的影响的一个它直接提供一个模型来提供语音进语音出的这样一个呃集成方式来给到开发者。

其实以前我们做还是一个异步的过程。

比如说我首先说一句话，

他给我转成人文本，

然后扔给 api，然后 api 返回。

哎，

文本之后呢，

我在 tts 出来，

这中间其实是有一个比较大的一个延迟的。

我是不是能够可以这么理解啊？

首先这两种它都是异步的啊，

就它本质上都是说我有一个呃输入出去呃，

异语音的输入出去，

然后经过一个异步的流程，

然后语音输入呃语音输出再回来。

呃，

但区别是就是以前要过三道，

现在只要过一道。

对，

那么这里面一个很明确的一个改进，

就是它的延时会大幅降低。

啊，

其实我们能看到这一次接入，

如果有接入 openandrealtimeapi 的同学能感知到它的延时体验。

因为我们说一般来说之前我们做实时音视频交互的话，

我们认为说人与人。

比如说我们在两个地方，

我们希望能感觉他就在我身边一样。

交互的一个前提是呃整体的延时差不多在八百毫秒左右啊，

是那以前通过 stt 大模型，tts 这三道转的话，

基本上很非常难达到这样一个延时的标。

但是但是 oy 这一次就做到。

呃，

所以的话呃包括说其实我在早期揭露之后，

玩了一些之前大家玩的很多的。

比如说让他唱歌啊，

或者让他数数啊啊，

包括数数数的快一点，

数的慢一点啊。

就是呃当然唱歌其实他最终没有试出来了，

因为他呃可能会有版权问题。

我猜但他像数数那种数的快数的慢，

这些他都是能做到的。

所以我第一天拿到接入这个 ovirolltimeapi 的感觉就是我靠这个简直就是对 sttlmtts 的降维打积和秒杀就有这个东西，

我要 st 干嘛？

对，

所以对所以整体的话就我觉得嗯当时第一第一手拿到的他给大家给我带来的体验是这样的啊，

但是紧接着呃就是他的 api 的问题啊，

就我们也都看到了 goi 在 lunch 的时候，

他是有一些第三方的 rtc 合作伙伴来帮助他提供前置的一些东西的。

这个其实包含说呃音视频啊，

媒体媒体设备的一个数据采集。

然后音视频数据的传输啊，

包括那个前面的一些三 a 处理。

那这些东西的话，

其实大家看的话，

那个 os 他只提供了一个传输通道啊，

它其他任何东西都没有提供。

那这里面其实很大的一个问题是在于 rtc 这个领域它所包含的技术的东西实在是太多了。

相比以前大家一个普通的 resteapi 什么都有了。

现在你看到的就是一个包含了完全不一样的。

而且这些东西的话其实是没有办法欧至少欧盟 i 没有办法在短期内快速的去解决。

所以他只能选择说呃去选择一个第三方合作伙伴，

在去选择这块领域的专家来真正的帮他能够解决这里面的一个问题。

呃，

所以嗯呃这里面其实很多很多东西它不是一个靠投钱就能解决问题。

它很多需要呃时间的积累，

比如说设备的兼容兼容性，

对吧？

我们有这么多安卓设备啊，

我们有这么多啊 iphone 设备，

所有设备上的一个兼容性怎么去处理？

然后网络的呃网络的延时问题优化，

对传输优化，

包括全球的一个实时音视频接入。

lastmile，大家很多人会用手机手机的网络不稳定。

那如果说我们还用以前 restful 或者长链接，

它，

这是提供的 websocket。

如果我们只用那个那么对于一些弱网情况下，

你这个东西是没法用的。

啊，

所以针对这些问题，

它没有办法处理的情况下，

他唯一的选择就是去选择在这块呃领域比较深耕的一些 rtc 厂商作为他的合作伙伴来提供。

这也是他的文档上其实明确说了，

就是他的这个 websocket 的 api，他推荐你从服务端介入啊，

你不要从端上直接接他外 websocket 这个 api，不然这个 lastmile 我没法处理啊。

你因为我也看他那 websocket 的 api 了也确实是对于普通的开发者来讲太难了。

对，

就就甚至其实我们都不聊前面的 rtc 那一块，

我们只聊这个 websocket。

因为它本质上是有一个从无状态到有状态的一个变化。

我们说什么是无状态？

就以前就是一个 restfulapi，你把所有的 context 全部塞到一个 apirequest 请求里面的 body 里就结束了啊。

但但现在你会有个状态，

你会发现它有一个 conversation 的概念，

每个 conversation 是动态，

在你说话的时候实时生成的那他们也也说了，

对吧？

呃，

我我感觉是有点自豪的，

说我有我我我们提供了六种 client，request，二十四种 serverresponse。

我觉得大家都是开发者。

看到这个数字，

我我不觉得会对我不觉得是对他们是一种包助，

就觉得太复杂了。

这个集成就跟以前一个 resusapi 直接可以玩，

就完全不一样。

所以这个确实区别跟以前相比是比较大的啊，

而且即便开发者接了这些 api，他也解决不了这个网络传输啊等等这一层面的问题啊，

所以你们会发现其实 obi 这一次在发布的时候，

他的发布的那个 blog 里面，

它是有合作伙伴的 summercode 的，

就是他的 summercode。

不仅是他自己，

他自己提供的是一个非常基础的基于浏览器的一个 webrtc 的口口，

然后结合他 websocket 做的一个方案。

但是嗯他同时提供了合作伙伴的呃全套 sammercode，就那 samcode 是直接把他们的 rtc 和 openandrealtimeapi 是集成好的，

就是放在你面前啊，

就是放到碗里啊，

就让你去可以直接吃啊。

对对对，

哎，

这个时候我其实想问问 k 置啊，

这个呃因为你跟开发者和呃前沿的这些嗯 ai 的从业者接触的会比较多。

那在这个过程当中，

这次发布的这个 realtimeapi 对于他们来讲有什么样的呃第一反应呢？

我觉得第一反应呃，

从正面的角度来说，

呃，

我感知到的就是他的体验真的和之前四 opromise 的比较接近，

比较接近的就是那个普列斯。

前面提到的几点第一点，

它确实延迟降低了很多。

第二点，

它确实在 alignment 层面做的特别好。

所谓 alemon，就前面比如说呃唱一首歌啊，

调低一点声音，

调高一些声音，

这些其实是文本当中完全体现不出来的信息。

但在声音上，

他的回复能做的很好。

我觉得这些开发者的反馈都是非常正面非常积极的，

让他们看到了更多的想象空间。

然后但同时也会看到很多开发者的反应就是非常的贵。

就是目前 api 的定价呢，

它大概是呃大概一呃我看很多人试用下来是可能呃一分钟在将近一美元左右。

那这个其实可以这是大家普遍的反应太贵了，

用不起呀。

是的是的，

这个就让很多厂仅目前的实际使用来的比较的困难。

我觉得这是一个比较明确的呃大家共同的共识的点。

还有一些就是实际使用当中会有一些呃瑕疵，

它往往来自于呃我们会聊到就是呃四 o 这种模型。

它为了做端到端的声音，

它其实都要。

但这件事情有很多好处，

它更强的智能，

更低的延迟。

但是它过程整一个，

因为它是一个更大的黑盒，

所以它不可冲性更强。

它当中会出现一些 hellostinson，或者是一些突然之间出错误的问题。

那可能接下来会需要很多的开发者的 workflow，或者呃包括前面 place 提到那样的呃很好的 framework 来解决这样的问题。

对我觉得这都是我听到开发者从正面和负面的反馈。

唉，

提到贵的这个问题的，

还得问普列斯啊，

为什么会这么贵？

这是我去刷推也好，

去看一些开发者社区的讨论也好，

大家反馈的最普遍的问题。

说要是这么贵的话，

我怎么用呢？

对吧？

我开发一个什么样的应用才能回本儿啊，

这个可能是现在大家最头疼的问题。

当然了，

我们也知道 ai 的价格肯定会随着时间的推移慢慢的下降嘛。

比如说现在文本模型，

其实从以前的高价现现在基本就四舍五入。

不花钱的这个状态它是有一个过程的。

但是现在看起来这个 realtimeapi 用起来确实比当年文本 abi 出来还要贵，

而且贵很多。

这个是怎么样一个原因造成的这样的一个定价机制呢？

对我简单说一下。

首先那个呃从我我我观察了一下，

那个我用 overeverytime 的 playground 大概玩了一下，

然后观察了一下它 token 计算的一个逻辑啊。

整体的话发现它有一个比较呃比较耗钱的地方，

就是它会把你上前面输出的 audiooutput 的 token，然后作为下一次输入的 audioinput 的 token 放进来。

其实呃像大多数我们跟 ai 说话的场景，

我们说话不会说很久。

我们其实说的话不多，

但 a 回复你的会比较多。

然后你会发现呃，

其实单轮对话不是很耗钱。

但是当他把这些 audio 的数据积累起来之后，

他就他他就很夸张了。

基本上我的感受是，

如果我从零到一就建立连接，

然后看跟他说说一分钟他的前耗 token 耗费大概在两千到三千的 audiotoken。

其实是贴合他们嗯大概那个零点三美分的一个呃一分钟的一个定价的。

但是当你的对话再继续增长的时候，

你的 audiocontext 会不断变长。

这时候你每说一句话就都是都是在烧钱。

所以这时候我觉得这是大家觉得那个整体用下来比较贵的一个原因。

那至于为什么这么贵，

呃，

如果大家集成过的话，

会发现你的音频数据是在不断的通过 websock 的高频的发给那个 ovi 的。

呃，

基本上我们说音频它的音频采用的是是是二二四 k 嘛，

所以基本上你可能十毫秒这一个音频包不断的塞给他。

那基本上这个流量用的人多的话，

对他的服务器资源消耗其实是一个比较大的一个负担啊。

包括说它后面其实会涉及到，

我目前看到它应该会知道音频的编码解码这些的一些事情。

那这些的话对于它也也会消耗算力，

对它的成本其实相对来说会比以前高很多。

所以 token 其其实本身大家会觉得，

可可能有有人会说，

我以前 texttoken 也是把它 response 直接扔在我的 context 一起送出去啊。

为什么音频就这么贵？

因为因为它的单价，

就是因为这些成本的关系，

目前拉的比较高，

所以大家会觉得贵啊，

这是我整体的用下一个感觉。

而且我觉得人类说话的时候，

其实你感受不到自己。

说了这么多字儿，

但是给你算脱根的时候，

可能就算进来了。

比如说呃我不知道我们的听友知不知道啊，

我们通常一个人一分钟说话的呃速率的中位数是多少？

中文的话大概一分钟是在一百二十字左右一分钟。

那如果我们再反过来算 token，再包括刚才像普雷斯说的，

如果我们再把多轮对话的内容都塞回去的话，

那光是 token 可能就不少。

他现在其实已经做了一些事情，

比如说你在连上连接后不说话，

其实它是不会算你 token 的。

它会有一个 vad 去检测你说话。

开始的时候到说话结束的时候，

它只取这一段去做 audiotoken 的输入输出。

但仅仅是这样就已经很贵了。

所以 yeah，对，

但是其实你不说话，

它这个流也是在传输的。

其实本身按合理来来讲的话，

你这个流只要发生传输，

它应该按分钟就要计费。

所以我认为他已经呃通过已经想办法很便宜了，

对吧？

或者说他已经通过呃某种定价单价的定价方式，

已经把这块的费用给涵盖掉了啊。

对，

如果把按分钟的这个传输费用算进去的话，

有可能会更贵。

包括你不说话的时候，

可能都要给你计费的前提是他会不会去处理。

前面没有说话的那段音频，

如果他不需要处理，

那么对于他来说就是一个纯传输的费用。

其实如果是这样的话，

相对还好。

对嗯，

但是假如说以后我们有个场景，

我们是需要有一些需要 ai 根据环境的声音去做出一些判断。

比如先让他听听一段环境的声音，

再问他这是什么？

那这时候我觉得费用就会更更高。

对啊对，

包括有的时候我录播课的时候，

我们经常会说，

有的时候必要的停顿也是内容的一部分。

那这个必要的停顿，

它要不要算进去也是一个问题。

但是这个问题就来了，

现在既然这么贵，

但是产品有了，

对吧？appi 有了，

作为开发者来讲，

我们现在应该如何应对这么贵的 api，或者我换一个说法，

我开发一个什么样的 app 才值得这么贵的 ap 呢？

哼这个问题非常的有意思。

我觉得首先是呃我对成本的降低还是非常的乐观的。

尤其是这次 openi 的 deathday，他也发布了 promptcash。

这个在大概半年之前，mtrptt 和呃海外的 xtorpid 和国内的 deepseat 都在发布这样的功能。

就是把那个 face 前面提到的问题之前聊的所有的内容给 kv 是得存下来，

用这种方式来降低成本，

不会每一次再把它放进 inputcontext。

所以从这个角度可以做的工程优化在模型侧还很多。

然后第二个就是聊到到底什么样的场景，

目前是值得用这样的 api 的。

然后我觉得欧博安现在的一个官方的 demo 就给了一些答案。

比如说他们给出的例子是像健身教练啊，

语言学习啊等等。

然后与此同时还有像呃销售客服等等这样的场景，

他们都是认为是比较呃高价值的场景。

呃，

要是客服的话，

我是不是搞个呼叫中心更便宜啊，

但是销售可能不一样，

那有可能会带来高价值的回应嘛。

是，

就是这个问题很有意思。

就是其实首先在整个工作链条当中，

售前的销售确实是占列价值最大的。

但是我觉得还是从动态的角度来看，

未来长期在一年后两年后，

这类 api 的价格一定会以十呃呃两个数量级左右的呃速度去下降。

那么到那时后，

每年一个数量级下降的话，

那么在之后一定是肉眼可见的，

会比现在的呼叫中心来的便宜的。

然后我觉得更重要的问题就是他怎么做到这个呃场景价值的打正，

以及目前它真正可用的场景是什么？

这个我觉得我们还值得再深入探讨一下。

之前那个在 voiceagent 那篇文章，

我们分析当中提到过一个框架，

建立一个坐标轴。

就是啊我看到这张图了，

你其实做了一个象限图。

哎，

是的是的，

嗯，

我回头把这个象限图会放在咱节目的声道里面，

大家可以在声道里看到啊。

好啊。

然后这个象限图的横轴是左侧是偏呃准确度的要求比较高的场景。

右侧是偏创造力，

要求比较呃高的场景。

然后它的 y 轴也就是它的上面这一部分比较在乎的是它的实时性。

而下面的对实施的要求不高，

它是这可以是一步的。

然后在这样的一个象限图当中，

我们就可以看到呃，

我们刚刚说的高价值场景。

其实基本上在左上部分，

也就是对准确度要求很高的同时，

还要实时的这一部分的问题，

价值是最高的，

同时难度也是最高的。

比如说在客户场景，

销售场景，

它需要做很多的 rap 来调取很多的实际那个呃实际生产场景当中的 domainknowledge。

那这种 domainknowledge 到底怎么调？

到底能不能用工具调用的方式把它很好的接进来。

我觉得这种待会儿我们也可以仔细的再讨论一下。

然后所以对这右左上角这一块，

我觉得是明现在价值比较明确。

但与此同时呢呃它可用性到底是不是好用，

不是那么确定的。

毕竟我们前面聊反馈的时候也提到，

它现在准确度还不是那么的高。

呃，

那个可能在一分钟的时候就呃一分钟的使用过程当中会给你呃，

或者你偶尔崩一次。

那么这这个问题本身就比较的呃严重一些。

比如说呃 lemonlabs 这样的海外的 gts 公司，

它收入涨得很快，

看起来技术本身没有很多的壁垒。

但很重要的原因就是因为它本身的服务足够的稳定，

非常的可能。

所以客户就始终愿意去使用它，

然后呃回到我们这张象限图，

右上角这个是我我目前觉得被那个呃 realtimeapi 解锁的更多的。

但是它目前的价值可能没有完全的呃被实践，

或者说它的商业化还不足以 carver。

他如此昂贵的成本，

我觉得这是一个值得去。

考虑的问题。

然后比如说右上角当中提到的是陪伴心理医生，

然后私呃简单的私人助理等等这种很多时候他只需要一些灵活的给我一些反馈。

我能感受到他在倾听我的话，

他在回复我的话，

那么这时候他的智能对准确度要求没那么高，

偶尔一些小小的错误，

其实我只能容忍那个瑕疵，

容错度很高。

呃，

那个就像自动驾驶，

其实对容错度不高，

但很多 ai 的场景对容呃 ai 的容错度是很高的。

那么这一部分我是觉得呃未来价格打下来之后，

它是一定能生效的。

然后也就是说你觉得价格打下来之后，

在右上这个象限可能会首先的爆发。

是的，

我觉得右上这一个是语音 killerapp 呃，

作为一个很重要的人际交互的界面，

或者说是渠道来说的话，

它是最有可能直接爆发的。

左上这个象限我觉得是现在我们还要对它的可用性，

接下来做更多的讨论，

可能才呃才退验证。

但它的价值我觉得是毋庸置疑的。

举一个比较有意思的例子是呃，salesforce 这家公司最近也发布了一个呃声音的 agent。

它的 salesagent 定价也很离谱，

是一次兑换两美金，

一次对话两美金。

这个代表着它本身，

这一次对话带来的价值是非常高，

企业才乐意。

那它算长度吗？

还是就是这一轮对话，

它目前的定价比较的简单粗暴，

就是按照一次对呃一轮对话的角度来说，

呃，

是多轮组合的一个对话组。

还是说就是我问一次你答一次就是两美金。

呃，

目前看好像是呃我问一次你答一次，

但这是对话啊，

那好贵啊。

是的是的，

不过他们应该还有企业的各种各样的复杂的一些打折的定价。

但不管怎么说，

都可以说，

哎，

这个定价真的是本身的价值是很高的。

是啊，

听上去就比较高。

但是呃消 face 的用户我们都知道都是一些关注于销售驱动的一些公司，

他拿来做销售工具的那是不是在这个场景下，

就像你刚才说的，

他在这在这里可能会产生一些高附加值的场景。

所以即便是两美金，

可能也会有很多的客户来尝试。

它是的。

我相信是的，

我觉得这也是 openi 的策略。

因为呃以 openi 现在那么大的用户量级，

它一下子开放给所有用户，

它的 servingcost 也很难一下子承受住。

然后还有各种各样的通信问题。

那么不如先把它给高价值的用户给开放开来过程当中一起去打磨。

到底能不能把左上上限的这种呃那当中的一些难的问题给融合下来，

同时慢慢的去优化成本，

再去解锁右上上限的这这个场景。

我觉得它是它的呃整个 roadnap 应该是是像刚刚的那样。

现在来讲，

对于我们的开发者在做一些什么样的事情，

这个得问普列斯了。

因为你的 framework 里面肯定有很多的开发者已经在尝试去做很多事情了。

那在这个过程当中，

你发现了什么呢？

呃，

我们这边目前呃已经基于我们框架有做的一些场景的话，

比如说呃会有 aigaming 啊，

对吧？

我们之前有有同学那个基于我们这个做了一个剧本杀的一个应用，

就是你 ai 会有一些背景知识，

你可以跟他玩 rowplay 的 game，然后去找出凶手。

对，

然后 ai 可以对于我们的这种哀人在家玩剧本杀就可以实现了，

是吧？

呃，