用 GPT-Realtime 构建全天候零售客服:avatarin 的两周实战启示

2026-07-30 27 预计阅读时间: 1 分钟
来源: openai.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:8 分钟

avatarin 将 OpenAI 的 GPT-Realtime 用于山田电机的购物支持,为顾客提供全天候、多语言的实时服务。上线两周内,约 30,000 人使用了该智能体,问卷反馈中有 92% 为正面评价。这个案例的价值不只在于模型能够“说话”,更在于实时语音、多语言交互和零售业务流程被组合成了一个可持续运行的服务入口。

实时语音改变了客服的交互节奏

传统语音机器人通常经历语音识别、文本处理、模型生成、语音合成等多个串行步骤。每一段都可能增加等待时间,也容易让顾客感到自己在与一套菜单系统交互。

GPT-Realtime 这类实时模型将音频输入和音频输出放进持续会话中,更适合处理零售现场的自然对话:顾客可以补充条件、改口或继续追问,系统也能保留当前会话的上下文。对于门店和电商场景,常见请求包括:

  • 查询商品所在区域或营业时间;
  • 比较两款商品的规格;
  • 解释配送、安装和退换货规则;
  • 使用顾客熟悉的语言回答问题;
  • 在无法确认库存、价格或订单状态时转交人工。

多语言能力尤其重要。它让企业不必为每种语言分别搭建一整套语音识别、翻译和语音合成链路,但这并不意味着业务内容可以省略本地化审核。商品名称、保修条款和礼貌表达仍需要按市场校验。

30,000 次使用和 92% 好评说明了什么

两周内有 30,000 人使用,说明顾客愿意尝试实时智能体作为服务入口。92% 的问卷反馈为正面,则表明多数参与调查的用户认可这次体验。

这两个数字不能直接等同于问题解决率。团队还需要同时观察:

  • 首次联系解决率,而不只是会话数量;
  • 从提问到首段有效回答的延迟;
  • 顾客重复提问或主动中断的比例;
  • 转人工的原因、等待时间和成功率;
  • 不同语言下的准确率与满意度差异;
  • 回答涉及价格、库存和政策时的事实错误率。

问卷结果也可能存在自选择偏差:愿意提交评价的人不一定代表全部使用者。更稳妥的做法是把满意度、任务完成率、人工抽检和业务系统记录放在一起分析。

可以这样实践:搭建一个最小实时语音客户端

下面是一个可改造的 Python 示例。它读取本地 PCM16 单声道音频,通过 WebSocket 发送给 Realtime API,并把返回的音频写入文件。

示例假设当前 API 仍使用 session.updateinput_audio_buffer.appendresponse.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 服务。


相关推荐