avatarin 将 OpenAI 的 GPT-Realtime 用于山田电机的购物支持,为顾客提供全天候、多语言的实时服务。上线两周内,约 30,000 人使用了该智能体,问卷反馈中有 92% 为正面评价。这个案例的价值不只在于模型能够“说话”,更在于实时语音、多语言交互和零售业务流程被组合成了一个可持续运行的服务入口。
实时语音改变了客服的交互节奏
传统语音机器人通常经历语音识别、文本处理、模型生成、语音合成等多个串行步骤。每一段都可能增加等待时间,也容易让顾客感到自己在与一套菜单系统交互。
GPT-Realtime 这类实时模型将音频输入和音频输出放进持续会话中,更适合处理零售现场的自然对话:顾客可以补充条件、改口或继续追问,系统也能保留当前会话的上下文。对于门店和电商场景,常见请求包括:
- 查询商品所在区域或营业时间;
- 比较两款商品的规格;
- 解释配送、安装和退换货规则;
- 使用顾客熟悉的语言回答问题;
- 在无法确认库存、价格或订单状态时转交人工。
多语言能力尤其重要。它让企业不必为每种语言分别搭建一整套语音识别、翻译和语音合成链路,但这并不意味着业务内容可以省略本地化审核。商品名称、保修条款和礼貌表达仍需要按市场校验。
30,000 次使用和 92% 好评说明了什么
两周内有 30,000 人使用,说明顾客愿意尝试实时智能体作为服务入口。92% 的问卷反馈为正面,则表明多数参与调查的用户认可这次体验。
这两个数字不能直接等同于问题解决率。团队还需要同时观察:
- 首次联系解决率,而不只是会话数量;
- 从提问到首段有效回答的延迟;
- 顾客重复提问或主动中断的比例;
- 转人工的原因、等待时间和成功率;
- 不同语言下的准确率与满意度差异;
- 回答涉及价格、库存和政策时的事实错误率。
问卷结果也可能存在自选择偏差:愿意提交评价的人不一定代表全部使用者。更稳妥的做法是把满意度、任务完成率、人工抽检和业务系统记录放在一起分析。
可以这样实践:搭建一个最小实时语音客户端
下面是一个可改造的 Python 示例。它读取本地 PCM16 单声道音频,通过 WebSocket 发送给 Realtime API,并把返回的音频写入文件。
示例假设当前 API 仍使用 session.update、input_audio_buffer.append 和 response.audio.delta 等事件。正式接入前应根据当前 API 文档确认模型名称、事件字段和音频格式。服务端不要把 API Key 下发到浏览器、门店终端或移动应用。
安装依赖:
python -m pip install websocket-client
export OPENAI_API_KEY="replace-with-your-key"
export OPENAI_REALTIME_MODEL="replace-with-current-realtime-model"
python realtime_retail_demo.py question.pcm answer.pcm
question.pcm 应为 24 kHz、单声道、16 位 little-endian PCM。创建 realtime_retail_demo.py:
import base64
import json
import os
import sys
import websocket
if len(sys.argv) != 3:
raise SystemExit("usage: python realtime_retail_demo.py input.pcm output.pcm")
api_key = os.environ["OPENAI_API_KEY"]
model = os.environ["OPENAI_REALTIME_MODEL"]
url = f"wss://api.openai.com/v1/realtime?model={model}"
ws = websocket.create_connection(
url,
header=[f"Authorization: Bearer {api_key}"],
)
ws.send(json.dumps({
"type": "session.update",
"session": {
"modalities": ["text", "audio"],
"instructions": (
"You are a multilingual retail assistant. "
"Answer briefly in the customer's language. "
"Never invent prices, inventory, warranty terms, or order status. "
"When verified data is unavailable, offer a human handoff."
),
"input_audio_format": "pcm16",
"output_audio_format": "pcm16"
}
}))
with open(sys.argv[1], "rb") as source:
while chunk := source.read(12_000):
ws.send(json.dumps({
"type": "input_audio_buffer.append",
"audio": base64.b64encode(chunk).decode("ascii")
}))
ws.send(json.dumps({"type": "input_audio_buffer.commit"}))
ws.send(json.dumps({"type": "response.create"}))
with open(sys.argv[2], "wb") as output:
while True:
event = json.loads(ws.recv())
event_type = event.get("type")
if event_type == "response.audio.delta":
output.write(base64.b64decode(event["delta"]))
elif event_type == "response.done":
break
elif event_type == "error":
raise RuntimeError(json.dumps(event, ensure_ascii=False))
ws.close()
print(f"audio response written to {sys.argv[2]}")
这个最小示例只验证音频链路。生产系统还应通过后端工具查询商品目录、实时库存、订单状态和门店信息。模型可以负责理解问题和组织回答,但价格、库存、配送承诺等事实应来自权威业务系统。
从演示走向 24/7 服务
全天候运行的难点往往不在模型调用,而在异常处理和责任边界。落地时可以采用以下检查表:
- 为库存、价格、订单和政策数据设置明确的数据源与更新时间;
- 给每个工具调用设置超时、重试和降级回答;
- 明确触发人工接管的条件,并把会话摘要一并交给客服;
- 告知顾客正在与 AI 交互,并按地区法规处理录音和个人信息;
- 对电话号码、地址、订单号等敏感数据执行脱敏和最小化留存;
- 分语言建立测试集,覆盖口音、噪声、打断和商品专有名词;
- 持续抽检高风险回答,不用满意度代替事实准确性。
avatarin 的数据展示了实时、多语言零售智能体的可接受度:顾客确实会使用,也可能给出积极反馈。更重要的工程结论是,GPT-Realtime 应被放在一套受约束的服务架构里。让模型处理对话,让业务系统提供事实,让人工团队承接例外,才能把一次亮眼的试运行变成稳定的 24/7 服务。