Voice Agents are here. Context turns them into real customer value.
TL;DR · AI 摘要
Voice Agents are here. Context turns them into real customer value. Databricks Blog Skip to main content Industries Octo...
核心要点
- 主题聚焦:Voice Agents are here. Context turns them into r
- 来源:Databricks,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
语音代理已到来。上下文使其转化为真正的客户价值。 | Databricks 博客
跳至主要内容
行业
2026年10月28日
语音代理已到来。上下文使其转化为真正的客户价值。
Databricks 如何将受控上下文、您的业务本体论和快速AI决策结合,实时定制每一段客户对话。
作者:Sathish Gangichetty、Rohit Bhagwat 和 Usman Zubair
摘要
*语音正在改变客户与品牌互动的方式。从实体店转向网站再到应用程序的用户,现在期望能直接与购买商品的公司对话,这种转变也正在影响供应商、司机和现场团队。*迄今为止,大多数企业AI的应用方向是内部的。更大的机会在于企业每天与客户和合作伙伴的对话,而这些对话现在都可以被实时捕获、理解并采取行动。*任何团队都可以构建一个能回应的语音代理,但只有当代理了解来电者身份时,才能创造价值。从那里开始,它能够适应该人、遵守既定规则,并在每次通话中不断改进。*在 Databricks 上,代理的“大脑”与您的受控数据并存。上下文和本体论为每个答案提供基础,快速的AI决策定制每个对话回合,每次通话都会形成一个学习循环。*入门非常简单。选择一个高频率的常规通话,衡量代理处理它的效果,并使用DIVA蓝图作为下一个项目的起点。
在继续阅读之前:观看这个简短的演示。
在这个简短的演示中,语音代理在通话中途的几分之一秒内做出决策,并在不打断对话的情况下改变回应方式。这种实时决策能力使语音代理能够切换语言、在合适时机将来电者转接给人员,或为最有价值的客户提供他们期望的体验。
为什么选择语音,以及为什么现在?
考虑消费者业务中每天发生的三个场景:
- 凌晨6点,一名司机因送货时间窗口延误而致电调度中心,请求调整他的码头预约时间。他正在开车,因此无法使用应用程序。另外三名司机已经在等待,他每多等一分钟,下一次送货的风险就增加一分。
- 正午时分,一个Drive-thru(路边取餐)有四辆车在排队,而只有一名员工在使用耳机,同时处理支付和派发订单。顾客只能通过语音点餐,因此排队速度取决于这名员工处理订单的速度。
- 晚上,一场风暴导致航班停飞,滞留的旅客致电酒店预订房间并推迟到达时间。在登机口两手各提着一个行李箱,电话比网站更方便快捷。预订团队只有两个人,却要处理四十通来电。
在这些场景中的每一个,语音都是客户联系企业最快或唯一的方式。那么,如果语音最终能最有效地满足客户需求和企业需求,为什么它经常不可用,或者在最近的实践中执行得如此糟糕?
多年来,答案是语音技术难以正确实现。但这一情况已不再成立。如今合成语音听起来自然,对话可以被转录为文本并在通话过程中实时处理,而现代语音代理可以跟上人们在对话中相互回应所需的约200毫秒的节奏。
企业对语音代理的思考方式尚未跟上技术发展的步伐。目前,大多数企业的AI投资主要集中在面向员工的助手工具上,而更大的机会则存在于企业每天与客户和合作伙伴的对话中。美国一家最大的快餐连锁品牌已经朝着这一方向迈进,他们正在开发一款语音代理,顾客只需通过语音即可添加商品、修改订单并完成结账。
语音代理创造价值的典型应用场景
从司机调整码头预约到旅客在暴风雨后保留房间,每一次通话都不仅仅依赖于语音识别。要真正发挥作用,代理需要与你最优秀的员工一样具备完整的上下文信息:谁在通话,对方已经采取了哪些行动,以及可以采取哪些应对措施。
缺失的关键在于了解客户
大多数语音代理试点项目证明了代理可以进行对话,但很少有项目能证明代理可以被真正信任地处理真实客户事务。上下文信息能够弥补这一差距。拥有上下文信息时,代理可以针对每个通话者进行个性化适配,在既定规则范围内进行对话,并通过每次通话不断优化。缺乏上下文信息时,即使是最自然的语音也只能给出通用回答。
设想一个具体场景:一位忠实客户来电投诉订单延迟。代理已经知道客户身份、订购内容以及包裹当前状态。它会先道歉,然后提供经授权的忠诚度积分补偿,并安排补发商品。如果客户仍然不满,代理会在瞬间察觉情绪变化,并决定将通话转接至下一位可用人员。接通的人员能立即获取完整上下文信息,客户既无需等待排队,也无需重复说明情况。同样的模式也适用于患者调整预约或订阅者因未识别的收费无法登录的情况。在每种情况下,代理都会在客户离开应用或网站需要即时解答时介入,通话结束后再将客户引导回原有流程。
在实时通话中整合这些上下文信息才是真正的挑战。这些信息分散在多个系统中,代理需要在瞬间获取这些信息,并且在整个过程中必须始终受到管控。这正是Databricks发挥作用的地方。
语音代理的"大脑":在Databricks上实现上下文、本体论和治理
语音代理由两个部分组成。第一部分是对话层,负责处理通话本身:传输音频、将语音转换为文本以及进行语音回复。专业合作伙伴在这一领域表现优异。在我们的原型系统中,LiveKit负责通话连接,Deepgram处理语音转文字和默认语音,ElevenLabs则提供富有表现力的语音。Twilio等电话运营商可以接入传统电话线路。
第二部分是"大脑",由Databricks提供。在每次通话回合中,它会检索来电者的上下文信息,应用企业的业务规则,并决定下一步行动,无论是回答问题、提出方案还是转接人工。它还会记录每次决策,以便团队后续审查。对话层决定了代理的声音表现,而"大脑"决定了代理是否能给出正确的答案。
这个"大脑"建立在Databricks上已实现的三个核心要素基础上:
- 上下文是代理当前需要的数据:包括通话者相关的客户信息、订单信息、产品信息和政策信息。
- 本体论决定了这些数据如何相互关联。它捕捉了支撑您业务的定义和关系,例如什么构成了忠诚度会员资格、订单属于哪家门店、哪些政策适用于哪些产品,从而使代理能够像您的员工一样理解您的业务。
- 治理决定了谁可以看到什么内容。在Databricks上,AI代理遵循与您企业数据目录中员工已遵循的相同访问规则。
对于Databricks客户而言,无需搭建新的平台。代理直接在您现有数据所在的环境中运行,并通过经过批准的只读查询连接到您已运行的系统,例如订单系统、忠诚度计划和CRM系统。
支柱1:基于业务的每个答案
在客户交互过程中,代理会使用您的上下文和本体论查找该人员的订单、您的政策和产品信息,使每个答案都反映您的业务,而非互联网上的通用知识。代理仅能看到属于呼叫者的记录,并通过检查您的系统来确认其身份,而不是依赖对方的陈述。您的业务决定代理可以提供的优惠、可授予的信用额度,以及何时需要由人工接管。
如果代理在您的数据中找不到答案,它会告知呼叫者并将其转接至人工,而不是猜测。它给出的每个答案都可以追溯到原始记录。涉及医疗、财务或安全等敏感话题会按设计转接至人工,且代理永远不会提供医疗建议。仅对话内容会通过语音合作伙伴传递,客户数据则保留在您的治理平台上。
支柱2:通过快速AI决策定制每个对话
语音代理需要两种类型的思维。某些决策必须在极短时间内完成,例如是否立即将遇到码头问题的司机或情绪激动的呼叫者转接至人工。其他决策需要仔细推理,例如确定延迟订单的正确解决方案。研究人员将这种现象称为快速和慢速思维,或系统1和系统2,AI现在也以相同方式构建。大型语言模型(系统2)负责仔细推理,而一种新的快速决策模型(系统1),如TypeSafe AI的Jev,则处理即时判断。Databricks通过ai_decide将系统1决策能力引入您的治理数据,使代理能够快速做出判断并展示其置信度。
在语音代理中,这两种能力会在每次对话轮次中协同工作。
- 忠诚会员或回头客将获得完整的客户历史记录和其有资格获得的优惠,由您最强大的模型提供支持,而常规问题则以低成本快速获得准确答案。
- 情绪激动的呼叫者会连同订单或预订信息、之前的投诉记录和已提供的优惠一起转接至人工。
- 切换语言的呼叫者会看到代理同步切换语言。
- 看到未识别账单且无法登录的订阅者会直接与您的记录核对,并立即转接至账户恢复流程,而无需等待通用队列。
- 拨打取消订阅电话的订阅者会立即听到其实际有资格获得的保留优惠,此时仍有机会改变主意。
- 询问症状是否严重的患者会连同完整对话记录转接至护士。
- 报告码头事故的司机会立即升级处理,避免造成运货损失。
这使您能够将最强大的模型用于对客户产生实际影响的场景,同时将更快、成本更低的模型用于其他所有情况。
支柱 3:通过每次通话创建学习循环
所有这些决策都会被记录下来。在电话层面已处理好通话者同意和录音披露后,每次通话都可以在一个受控位置进行捕获:通话内容、查询信息、使用哪个模型进行回答,以及每个决策背后的原因。您的团队可以使用与管理其他数据相同的策略,控制谁可以访问这些记录以及保留多长时间。代理继承了 Databricks 平台的安全和合规计划,包括在 Databricks Trust Center 中描述的 HIPAA 和 SOC 2 Type II 认证选项。语音合作伙伴需提供自己的认证,这些认证需要在您的部署过程中进行审查。
这些记录使代理能够不断改进。每次通话都可以自动进行质量评分,客户体验和联络中心领导者可以使用自然语言询问有关通话的问题,例如“为什么上周二退款请求突然激增”。随后,这些洞察可以反馈到更优的提示语和模型中,进一步提升语音代理的效果。
在 Databricks 上开始使用语音代理
启动使用语音代理不需要大规模的项目。构建模块现已可用,Databricks 智能语音代理(DIVA)蓝图(在 GitHub 上开源)为您的团队提供了一个可运行的起点。语音将成为您现有系统之上的新渠道。
语音代理负责处理那些填满队列的常规通话,例如订单状态查询、补货提醒和重新预订,这样您的员工就可以专注于需要人工处理的对话:愤怒的客户、复杂的请求,或更愿意与真人交谈的通话者。当员工接起电话时,完整的通话历史已经显示在屏幕上,如果出现问题,通话将转交给拥有完整对话记录的人员。
这就是客户服务的未来方向。Gartner 预测,到 2029 年,代理式人工智能将无需人工干预自主解决 80% 的常见客户服务问题,从而将运营成本降低 30%。
Databricks 行业工程师建议从为期 90 天的试点项目开始,覆盖一个渠道、一个团队以及您最繁忙的常规通话类型,例如订单状态查询、司机签到或供应商确认。在试点开始前,记录当前每通电话的成本、处理时间和客户满意度,并跟踪通话者是否再次回来并进行购买,以便在试点结束时进行结果对比。一旦试点结果稳定,您可以将相同的受控设置扩展到更多地点和更多类型的通话。
下次领导会议的三个问题
- 我们最常处理哪些客户和合作伙伴的对话?其中哪些对话目前可以由代理准确回答?
- 如果明天由语音代理代表我们接听电话,它是否能知道对话对象是谁,并遵循与我们的员工相同的规则?
- 我们是否可以追踪代理在通话中做出的每个决策,并证明这些决策是受控的?
要了解实际效果,请观看完整演示,并将 DIVA 蓝图与您的技术团队分享。其中包括编码代理可以直接遵循的现成说明。然后联系您的 Databricks 账户团队,讨论并构思您的首个用例。
您的客户将很快通过AI代理与您进行互动。关键在于该代理对客户的了解程度。
相关标签:
Retail & Consumer Goods
订阅博客,获取最新文章
订阅我们的博客,最新文章将直接发送到您的邮箱。
立即订阅
查看所有博客文章
slice-start id="_gatsby-scripts-1"
slice-end id="_gatsby-scripts-1"