Transcript
00:00:00我们先提几个简单的问题，然后就直接切入正题。在座的各位中
00:00:19有多少人构建过语音 AI 智能体？好的，这里的观众基础相当不错。那么有多少人
00:00:28构建过已经部署到生产环境中的 AI 智能体？还不错。好的，太棒了。那我们就来聊聊
00:00:38通常会发生什么，对吧？就像每个人都在讨论语音 AI 智能体一样。你知道的，
00:00:47如今几乎能解决世间一切问题的灵丹妙药就是语音 AI 智能体。所以每个人都在
00:00:51构建并试图部署它。当你在自己的开发环境中构建它时，
00:00:57听起来非常棒。然而一旦你把它从概念验证（POC）推向生产环境，
00:01:03各种问题就开始接踵而至。因此，我们将从以下五个不同的角度来探讨我们在
00:01:09PLEVO 看到的语音 AI 智能体相关情况。但在那之前，先由我来做个简单的自我介绍。我是 Venki，
00:01:19创始人兼 CAO。她用的是智能体工程经理的头衔。从头衔上来说，我则自称为首席智能体官。
00:01:28好的，那么为什么——为什么我们甚至有资格进行这场讨论，
00:01:35以及我们看到了哪些许多公司看不到的东西？所以，
00:01:42我将简要谈谈我们的发展历程，看看我们一路走来是如何走到今天的，然后再直接切入主题。
00:01:48你知道的，我们已经成立大约 14 年了。我们的历程一直围绕着开发者 API 平台。
00:01:54而现在，我们转型成为了一家 AI 智能体企业。我们早在 2011 年就从语音和短信 API 起家。
00:02:01然后，你看，现在我们主要专注于全栈的 AI 智能体产品。
00:02:08也就是我们平台的全栈服务。我们每天在全球处理超过十亿次的语音通话。
00:02:16呃，正因如此，我们看到了许多这样的模式涌现出来，比如在与客户合作时，
00:02:20他们的语音 AI 智能体在生产环境中到底会发生什么。
00:02:25呃，我们是一个拥有 90 人的团队，呃，我们拥有 5000 万美元的资金储备。有趣的是，
00:02:33这并非来自外部风险投资人的资金。这完全是通过公司实现盈利，
00:02:38并在这些年里将现金存入银行所积累的。呃，
00:02:42我们为全球各地的客户提供支持。呃，你知道，我们在那里放置了一些客户的标志，
00:02:49但主要从产品供应的角度来看，呃，我会将此大致归纳为三个不同的类别。
00:02:54其一是可编程的 AI 智能体产品。我们称之为——我的意思是，它是一个语音
00:03:00管道，还不是真正的语音到语音产品，但这是一个可编程的产品。
00:03:05我们还有一个 AI 智能体工作室。这是一个无代码的可视化构建工具。然后，就像我说的，
00:03:11我们从语音 API 起家。所以我们在过去的 14 年里显然构建了这些基础设施，
00:03:16包括 SIP 中继和音频流传输层。因此，在电话通信或运营商层面上，我们并不依赖其他人。
00:03:22这是我们在所有这些年里建立的核心基石业务。
00:03:26而我们的 AI 智能体平台正是建立在此基础之上的。
00:03:32好的。有了这些，呃，让我们切入正题吧。我确信，既然大家都已经构建过
00:03:39AI 智能体，你们一定都以这样或那样的方式见过或构建过它。我们将花更多时间
00:03:44来探讨整个管道看起来是什么样的，对吧？我们在客户身上看到的情况是——
00:03:51我确信大家对此都能感同身受——任何考虑 AI 智能体的人，
00:03:56他们所做的就是挑选一堆这样的编排框架，并且做得相当不错，
00:04:01比如 LiveKit 或 Pipecat，并在其之上构建他们的 AI 智能体。呃，他们认为
00:04:06他们可以轻而易举地编排这四个不同的层：语音转文本、大语言模型（LLM）以及文本转语音（TTS），
00:04:13中间加上轮次检测（turn detection），然后就可以大功告成了。就像“我的 AI 智能体在概念验证（POC）中运行良好，
00:04:19所以在生产环境中也能正常工作。”通常情况就是这样。他们会衡量自己的
00:04:24延迟，你可以在这张幻灯片上看到每一层的某些指示性延迟，然后他们会想：房
00:04:30“是的，这对于我的需求来说挺合适的。”于是他们就准备将其实施到生产环境中。紧接着，
00:04:36生产环境的问题开始显现，你会遇到各种各样的故障模式，
00:04:41这也是我们在本次演讲中将要花大部分时间探讨的内容。呃，我在最后留出了一些时间
00:04:48用于问答环节，如果大家有什么问题的话，但我们要直接从这一点切入，
00:04:53转到——呃，我们看到的各种故障模式。让我们从——呃，大家都在讨论的第一个问题开始。
00:05:01这是讨论度最高的故障模式，也就是延迟。呃，我想我们
00:05:07今天有几场关于 AI 智能体或语音 AI 智能体的演讲。嗯，我确信每个人、
00:05:12每个人都会触及这个特定的故障模式，这就是为什么我要把它直接提出来，呃，
00:05:17从——呃，这种完整体验对用户而言是怎样的角度来说，对吧？呃，通常
00:05:26大多数人是通过首个音频响应时间（time to first audio）来衡量这一点的。也就是从用户停止说话
00:05:34到你的智能体开始说话的时间，对吧？
00:05:39我想你们如果构建过语音智能体，大概都体会过什么是优秀或自然的感觉，什么是
00:05:46稍微有点烦人的感觉，或者说比较明显的感觉，以及真正让人恼火的感觉，也就是不同的层级。
00:05:52我们注意到，大多数人希望控制在 550 毫秒以内，因为这是各大平台宣传的标准，
00:06:00或者是各种解决方案宣传的水平，但实际上大多数人最终的延迟都在 750 到 1.2 秒之间。
00:06:07绝大多数人都落在这个区间。表现真的很差的那些，
00:06:13延迟会超过 1.2 秒，然后你就会发现用户开始挂断电话了。现在，我来和大家分享一下
00:06:19我们在生产环境中实际看到的客户使用情况，涉及不同的技术层级，
00:06:26以及针对其中一些问题的解决方案。我们看待这一层级的方式，
00:06:33本质上是平衡这三者：成本、智能水平和延迟，
00:06:42对吧？为什么我要提出这三个要素？因为它们是相互关联的。我刚才和
00:06:48外面的一些朋友聊天时也谈到了这一点。其中一点是，
00:06:51在过去的一年里，我们看到了许多创新，大语言模型领域的智能水平出现了爆发式增长，
00:06:58对吧？而且大部分智能水平的提升都体现在深度思考、
00:07:05强化学习等方面。但语音智能体具有一个讽刺的现实，那就是几乎在所有情况下，
00:07:11正在发言的大模型或智能体都必须关闭思考功能，对吧？所以过去一年里
00:07:19我们在大模型层面上取得的所有进展，在这里几乎完全派不上用场，
00:07:25对吧？当然，你确实拥有能够更好地遵循指令或调用工具的优秀模型，
00:07:29但如果你想让响应速度足够快，在思考层面上构建的所有智能特性
00:07:34默认全都是关闭的。所以，这是我们遇到的讽刺情况之一。
00:07:39那么，我们该如何在智能、成本和延迟之间找到平衡呢？
00:07:44让我们来看看目前市场上存在的一些可选方案，
00:07:48对吧？我专门挑选了大模型来讲，因为如果你看先前的图表，大模型
00:07:55可以说是产生延迟最高、贡献延迟最大的环节，对吧？如果你看看
00:08:02前沿模型（这也是大多数人默认的起点，比如 OpenAI、Anthropic、
00:08:09Gemini），在状态良好的情况下，其 P50 首字延迟（TTFT）大约在 450 到 500 毫秒左右，而且有时会出现波动，
00:08:17对吧？它的 P90、P95 延迟甚至很容易超过 1.2 秒、1.3 秒，
00:08:25这对整体的智能体体验来说并不是好事。所以，这就是前沿模型的情况。
00:08:31现在还有另一种选择，那就是 Cerebras 或 Groq，它们以能够以极高的速度
00:08:38吐出大量 Token 而闻名和流行，对吧？这些方案确实管用，但要想在这些平台上获得
00:08:45专用的低延迟或首字延迟，你需要专属算力，而那非常昂贵。
00:08:51这就是我刚才提到的成本问题，我们需要在成本上进行平衡，对吧？它确实非常贵。
00:08:56而且你随便去问 Groq 团队或 Cerebras 团队的人，他们都会告诉你，
00:09:01你需要提前 12 个月预定专属算力。他们的产能未来 12 个月都已经订满了。
00:09:05所以，这是一个相当昂贵的选择。此外，你必须确保你部署在这些基础设施层上的模型，
00:09:11在 12 个月后依然存在。这是一笔巨大的投资，也是一个巨大的未知数。
00:09:17那么，对于生产级别的智能体来说，什么才是既具备优良品质
00:09:27又能平衡这三者的现实选择呢？以下是我们实践证明有效的方法，
00:09:34也就是开源模型。在可选的种类和变体方面，开源模型显然有很多。
00:09:41也就是品种和变体选择非常多。我具体指的是我们一直在合作的两个模型，
00:09:47Qwen 3.5 和 Gemma 4。它们是目前市场上处于尖端水平的开源模型，对吧？
00:09:56也就是目前市场上最前沿的开源模型。而且我们围绕它们的表现做了大量的基准测试。
00:10:02一想到“我有模型了，接下来得自己去托管它们、在自己的 GPU 上运行它们”之类的事情，可能会让人觉得有点畏惧，
00:10:10但如果你一直将目标锁定在 300 毫秒以内，我们发现这是一种在延迟、成本和智能之间
00:10:17取得伟大平衡的绝佳选择。
00:10:23现在，我们来做一些更深入的探讨。如果你只做英文，Qwen 3.5 或 Gemma 都能表现得很不错。
00:10:29但如果你要处理多语言、面向国际受众或不同的语言，Gemma 4 在这方面是一个
00:10:35好得多的模型。我们查看过 Token 的生成效率评估。简单来说，
00:10:44用大白话来解释，就是生成该语言的一个单词需要消耗多少个 Token？
00:10:48所以 Gemma 要好得多，从这个角度来看，它至少比 Qwen 3.5 好 2.5 到 3 倍。
00:10:56因此在多语言的基础下，在其他条件相同的情况下，Gemma 4 输出文字的速度要快得多。
00:11:04多语言场景下，LLM层该选择多大尺寸的模型呢？通常情况下，混合专家模型（MoE）效果不错。
00:11:12嗯，30亿或40亿参数的混合专家模型通常就很合适。不过，使用
00:11:17混合专家模型的一个问题在于，如果有人想走微调这条路，可能会面临挑战，
00:11:22因为微调混合专家模型并不容易。你可能经常会把
00:11:28模型搞坏。所以，这是我们在混合专家模型上发现的一个挑战，但通常开箱即用时，
00:11:35它就能让你达到预期效果的90%左右，甚至不需要做任何微调、定制化修改
00:11:42或模型优化。这就是混合专家模型的优势。现在，如果你想进行微调，
00:11:48想深入钻研，比如“我是在为特定领域（如医疗保健等）工作”，
00:11:53并且想确保能够微调模型，那么以目前的水平来看，你至少应该从
00:11:5880亿或120亿参数的模型开始。也许，也许六个月后，
00:12:0440亿参数的模型就能轻而易举地击败80亿参数模型了，但就目前而言，根据我们的经验，
00:12:11你至少需要一个80亿或120亿参数的模型，因为在这些模型中，你有两点要求：
00:12:16第一，显而易见，需要快速的生成速度，但同时也要有良好的指令遵循能力，对吧？至于
00:12:23第二点，就是非常高的工具调用成功率。因为如果你能把这两件事做好，
00:12:29那么你基本上就已经完成了70%、80%的工作，甚至完全不需要微调任何模型，
00:12:35模型开箱即可直接工作。所以，这就是我们的秘诀。实际上，我们
00:12:42运行着两种版本：一种是针对特定行业的微调模型；另一种是用于
00:12:50大多数通用用例的混合专家模型，开箱即可。在接下来的幻灯片中，我们还会讨论
00:12:56一些常见故障模式的技巧和诀窍，但从延迟和LLM的角度来看，
00:13:00我们目前的情况就是这样。好了，由于时间
00:13:07不多了，我要加快进度。这里还有另外几种搭配方式。人们构建
00:13:12智能体时会组合使用多种模型。具体做法是：对于对话部分，
00:13:19他们使用一个更小、参数更低的对话模型，
00:13:24甚至可能是30亿参数的模型；而对于工具调用，则使用大得多的模型，
00:13:27从而提高工具调用的成功率。
00:13:35抱歉。第二点是：假设你的语音转写总是会出错。这是
00:13:42你在构建AI智能体时应该遵循的准则，哪怕你拥有市面上
00:13:49最顶级的转写引擎也是如此。我来告诉你为什么。市面上那些最先进的
00:13:55转写引擎，其字词错误率（WER）大概在4%到6%左右，
00:14:02而且这是在已知的评测集上测出来的。而在真实世界中嘈杂的通话里，夹杂着
00:14:10各种口音——比如人们带着不同的口音——以及专业领域的词汇等等，
00:14:15从字词错误率的角度来看，这些情况通常会导致错误率飙升到两位数，
00:14:21对吧？当然，你可以选择微调，挑选一个开源模型进行微调，
00:14:25但我们通常发现，这里往往会出现故障，而且这些故障是有规律可循的。
00:14:31比如专有名词、行业黑话、电话号码（比如电话号码中随机漏掉数字），
00:14:38以及错误的词语替换。我稍后会通过一些例子来讲解如何解决这些
00:14:43地址问题。当你试图收集一长串地址时，转写引擎
00:14:48很可能会漏掉其中的一部分。还有语码转换（混语）语言。我举个我懂的语言的例子，
00:14:55因为这样比较容易放进幻灯片里。比如，如果你把英语用
00:15:01另一种文字书写出来，印地语就是这么用的，对吧？这其实是用另一种文字写的英语，
00:15:06对吧？而它的实际英文版本其实是：
00:15:11“Hello, how are you?”所以，如果我在跟使用不同语言的国家的用户对话，
00:15:16其中涉及语码转换，并且我的英语转写被输出了另一种文字，
00:15:21那么从转写引擎到LLM层乃至后续环节，一切都会开始崩溃，
00:15:26因为你的LLM往往会开始用那种文字输出结果，然后你的TTS（文本转语音）就会出错。
00:15:32所以，这一点非常需要小心。如果你想让你的智能体
00:15:38独立于转写引擎，你就需要构建一个能够对所有这些内容进行归一化的层，
00:15:44对吧？我们一会儿就会讨论解决方案。还有另一种情况，就是纯粹用拉丁字母、
00:15:48罗马字母拼写的印地语，对吧？也就是说，这是印地语，但读起来是英文，
00:15:54这同样会把下游的所有环节搞得一团糟。这些只是例子。这种情况同样适用于
00:15:59阿拉伯语、普通话、日语等等，几乎适用于任何语言。那么，
00:16:04在转写层，究竟是什么在真正起作用呢？对于专有名词，
00:16:11我们建议不要仅仅使用关键词增强（Keyword Boosting）。我觉得很多转写引擎
00:16:16都提供关键词增强功能，允许你在它们的引擎中输入特定的词汇，
00:16:21但我们要使用的是动态关键词增强。这意味着什么呢？不要让某个关键词在整个通话过程中一直保持激活状态。
00:16:26只有当你认为需要它作为答案时，才动态地添加该关键词，这样才能获得最高的准确率。
00:16:32也就是说，在通话的不同阶段，转写引擎会在不同的阶段增强不同的
00:16:38关键词，对吧？我们发现这样做效果最好。因为如果你在转写引擎的上下文中
00:16:43塞满成吨的关键词，它又会开始产生幻觉，对吧？所以，这就是我们发现最有效的方法。
00:16:49没错，用大模型对你的转写文本进行后处理，对吧？因为你的大模型拥有领域上下文，而转写引擎没有。
00:16:55因此，转写出来的很多词——我等会儿会举几个例子——可能根本说不通。
00:17:02这是一个例子，比如转写引擎转写出的电话号码，对吧？你觉得那个字母E是什么？
00:17:07比如转录引擎识别出的电话号码，对吧？你觉得那个E是什么？
00:17:13对吧？如果交给大模型，它就知道那是数字3。同理，像那个1，其实就是
00:17:18所以，转写引擎很多时候会把这些搞砸，但当你通过大模型层进行后处理时，
00:17:24它就能在信息收集阶段瞬间纠正这些错误。我的意思是，还有最后一点，
00:17:30正如我所说，音译也是一样，即你的语音转写输出——也就是多语言内容——
00:17:37也可以通过以下方式进行归一化：要么先用大模型进行音译，要么使用某种神经音译引擎。
00:17:46市面上有许多开源的音译引擎，你随便挑一个就行，对吧？
00:17:49它就能帮你搞定所有这些工作。向你的大模型持续发送清洗干净的转写文本，
00:17:55而无需依赖转写引擎。
00:18:00好的。我们通常遇到的第三个问题是数据收集。我认为在这里，
00:18:0550%到60%的AI智能体会把事情搞得一团糟。而且，我们倾向于将之视为一个UI（用户界面）问题，
00:18:14只不过它是针对语音的。所以，请考虑数据模型，而不是让一段转写文本直接进入大模型去猜测
00:18:21转写文本里到底说了什么。让我们从——我假设在座的大多数人都是开发者——
00:18:27这里获得一些启发：比如借鉴Python的数据类（Data Classes）、Pydantic、
00:18:32TypeScript中的Zod，或者UI中的表单字段，对吧？如果你从这个角度去思考问题，
00:18:39我们已经看到，在数据收集的准确率上，采用这种思维方式可以使准确率从30%跃升至95%左右。
00:18:46所以，在提问之前先决定好数据的形状，对吧？也就是说，与其保持开放式，
00:18:52不如加以约束？比如，电话号码能不能是一个
00:18:58电话号码类型的字段？一旦你这么做了，对吧？你就知道它需要包含多少位数字。
00:19:03你可以在此基础之上进行验证，对吧？并且明确其中允许存在哪些合法的值。
00:19:10所以在我们之前看到的例子中，如果电话号码中间出现了一个字母E，而你又知道这是一个电话号码，
00:19:15你就会立刻通过智能猜测将其纠正为3，并向用户进行确认；
00:19:20或者你知道这是一个错误，然后进行验证并要求用户重新说一遍，
00:19:26对吧？所以，我认为这是我们看到的常见模式之一，从
00:19:31而“姓名”这个字段，我觉得非常有意思。我随便挑了一个
00:19:36很难发音的名字。人类根本不可能一次念对，
00:19:43我们的转写引擎无论重复多少次也绝不可能搞对，对吧？所以，
00:19:47只有当你开始把这看作一个个字段，并为其设定规则以及逐字母拼写的确认机制时，
00:19:53你才有可能把它弄对。否则，
00:19:58在语音通话中收集这类信息时，结果往往会一塌糊涂。这只是一个例子，
00:20:03说明了我刚才提到的关于数据收集部分的内容。
00:20:11另一个灾难性出错的地方是相对值，日期就是一个典型的例子。
00:20:18如果有人说“下周三八点”，它既可以指早上8点，也可以指晚上8点，
00:20:25而弄清楚这个日期的实际值，又变成了一个高度受限的问题。如果你知道这是一个
00:20:30日期时间字段，并且你正在收集一个日期时间字段，然后你获取当前日期，
00:20:35并以此计算出这个值应该是什么，对吧？所以，这就是你想要确保的事情：
00:20:39通过大模型与工具调用的结合来完成这项工作，而工具调用会
00:20:44从字段的角度为你承担大量繁重的计算工作。
00:20:50对。然后你要从单元测试的角度来运行它。因此，你的所有评测（evals）都需要
00:20:58开始把这些字段当作单元测试来对待。只要你的单元测试通过并得到验证，
00:21:06你知道，你的代理就会变得比较可靠且可重复。你不需要
00:21:10去运行成百上千个端到端的代理测试用例，只为了发现某一个字段
00:21:15数百个端到端智能体测试用例，只为了发现某个字段
00:21:24收集坏了。你可以在字段级别和单元测试级别进行评估。
00:21:30然后，是的，就像我说的，我认为这种心态使一切变得更有条理
00:21:36每次都改动几个字符。然后寄希望于通过提示词工程让大模型更能听懂指令，
00:21:41并且像施了魔法一样开始遵循某些规则。事实上，正如我所说，
00:21:47并神奇地开始遵循这些规则。事实上，正如我所说
00:21:53行吧。然后呢，秘诀其实基本上就是把智能体在那一步的上下文
00:21:57好了。其中的诀窍基本上就是将智能体当时的上下文内容
00:22:04行吧，呃，我从时间上来看，
00:22:10跳过这部分时间。我看到我只剩三分钟了。希望那是个Bug，不过
00:22:16我们就这样吧。好的，那么这是我们发现问题出现的第四个领域。大多数人会获取
00:22:24大模型的输出，然后将其发送给文本转语音（TTS）。显然，我认为市场上有很多优秀的 TTS
00:22:30能够处理很多繁重的工作，但很多时候它还是会弄砸。我们建议的做法以及
00:22:37我们所看到的经验是，你通常希望在大模型和输入到 TTS 的内容之间
00:22:43建立一个规范化层。你不能直接把大模型的输出发送给 TTS，对吧？我们来过一遍
00:22:50一些例子。最基本的，就是在合成 TTS 之前，去除表情符号和 Markdown 格式。
00:22:58大多数编排流水线都会做这件事，比如 LiveKit 或 PipeKit 如果你
00:23:02设置几个标志，它们就会为你处理好。所以，不过，请确保如果你没有使用它们或是
00:23:08从头构建，你要明确地设置这些，因为你可不希望表情符号出现在
00:23:12朗读的内容里，或者看到 Markdown 标记出现在那里。
00:23:17好的。我认为更常见的一些做法是使用自定义词典。大多数 TTS 引擎都会提供这个功能
00:23:23教你如何发音自定义词汇，无论是专有名词、品牌名称、
00:23:30缩写等等。因此，在从大模型输出转到 TTS 输出时，把这些设置好，
00:23:36因为如果你不这么做，就会把发音弄砸。我等会儿会向你展示一个我们如何测试
00:23:40这一点的例子。另一个点是，大多数引擎也提供语速控制。所以，如果你知道你要读出
00:23:47某个实体，就放慢语速，让你的智能体慢下来。比如设为 0.8 倍速或 0.7 倍速，这样它就能
00:23:54清晰地吐出那个特定的实体，并且不会把电子邮件、电话号码
00:24:00或名字逐字逐句的发音读错。是的，把所有乱七八糟的东西都规范化，对吧？比如电子邮件、
00:24:09货币、日期。不要把这些丢给 TTS 去处理。虽然大多数 TTS 能做到，但不要完全依赖
00:24:15TTS 来做这件事。应该在你自己端构建规范化层，这样明天如果你觉得需要
00:24:21更换 TTS，或者由于某种原因第一个 TTS 宕机了而你想使用
00:24:25另一个 TTS 时，你就能够不原生依赖 TTS 引擎，而是自己在内部构建
00:24:32这个机制来管理。然后，是的，我想我这里没有放我的姓氏，
00:24:39我的姓氏没在上面。所以我的第一个测试就是，如果它无法正确发音我的姓氏
00:24:44或者我公司的名字，它就已经露怯了。我的姓氏是 Balasubramanian，
00:24:50如果你用语音 AI 智能体无法正确读出这个名字，对我来说这就是个测试标准。我知道，
00:24:56呃，你知道的，这个智能体会把很多需要天天拼写出来的
00:25:04词汇都读错。第二个是我们的公司名称 Pliwo。很多引擎把它读成
00:25:09Pliwo 或者 Pliwo 等等。但是，明确在你的流水线中控制这一点
00:25:16至关重要。而且如果你在构建面向客户的
00:25:21产品，那么，呃，你知道的，把这个选项提供给你的客户。好啦，
00:25:26我打算快速浏览最后两张幻灯片。我，我的时间严重超标了。
00:25:32关于发言结束检测（End-of-turn detection），我认为这是一个独立的话题，但我会
00:25:36快速列出所有要点，以便各位浏览。如果大家在这之后
00:25:41想聊聊，我们可以讨论这个。好，我把这个留给各位看个五秒钟，
00:25:49然后我们就可以线下交流了。我的时间真的超了很多。接着，
00:25:53最后一个是强行打断（Barge-in）和后向通道（Back-channeling）。大家都在讨论
00:25:58能够处理其中部分功能的语音到语音模型，但我们已经验证了如何在语音到语音流水线中
00:26:03实现所有这些。你其实并不需要一个语音到语音模型来搞定这一切。
00:26:07同样，我把这个放到幻灯片上，然后就以此收尾。呃，
00:26:15好了。我想我们没有时间提问了。如果有任何问题，我们可以在线下交流，不过
00:26:19希望这有所帮助，并让你们对我们在生产环境中看到的
00:26:24数十亿次规模化调用的情况有所了解。好，谢谢。
00:26:29我们下次再见。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video