-
背景概述
为了更好的用户体验、更高的市场竞争力和更丰富的功能，想要实现从移动端APP语音控制电视的效果，目前市面上有很多成熟的技术选型，当前通过前期商务沟通，主要考虑接入微软的产品，以下主要分析微软实现智能语音控制电视设备的报告
-
流程概述
即从微软产品的技术来分析，首先需要将用户在移动端的麦克风语音或语音文件翻译成文本，再将翻译后的文本作为重要参数调用CHAt-GPT接口获取相关操控电视的指令，再将指令下发给电视设备执行
或
-
流程实现
如上流程图所示，最重要的部分是如何将语音转为文本和根据文本+协议获取控制电视指令，现在将对当前两个技术流程实现具体分析，其中语音转文本主要使用微软的实语音转文本技术 ，获取电视指令则主要使用Chat-GPT大模型技术
-
实时语音转为文本
-
识别一次和连续识别
实时语音转文本可支持对麦克风语音和语音文件的识别，根据是否需要在一次转换中识别多个语言分为连续识别和识别一次，用识别一次，可识别单个言语。 单个言语的结束是通过在结束时倾听静音或处理最长 15 秒音频时确定的。与此相反，当你想控制何时停止识别和想要识别多个语言时，可使用连续识别
| 功能 | 识别类型 | 结束控制 | 语言支持 |
|---|---|---|---|
| 识别一次 | 麦克风语音和语音文件 | 倾听静音或处理最长 15 秒音频时确定 | 单个语言 |
| 连续识别 | 麦克风语音和语音文件 | 可手动控制处理多长时间（设置多长时间就是多长时间） | 多个语言 |
官方地址：learn.microsoft.com/zh-cn/azure…
-
语言识别
在语音转为文本时，如需要在返回的文本中有语言字段，则需要使用到语言识别功能，它分为起始和连续语言标识 (LID)，他们各有如下特性：
- 对于起始 LID，最多可添加 4 种语言；对于连续 LID，最多可添加 10 种语言。 语音服务会返回提供的其中一种候选语言，即使音频中不存在这些语言。 例如，如果提供
fr-FR（法语）和en-US（英语）作为候选语言，但语音使用的是德语，则返回fr-FR或en-US。 - 起始 LID在音频的前几秒钟内标识语言一次。 如果音频中的语言不会更改，请使用起始 LID。 使用起始 LID时，可以在不到 5 秒的时间内检测并返回一种语言。
- 连续 LID可以在音频持续时间内识别多种语言。 如果音频中的语言会更改，请使用连续 LID。 连续 LID不支持在同一句子中更改语言。 例如，如果你主要说西班牙语并插入一些英语单词，它将不会检测每个单词的语言更改。
官方地址：learn.microsoft.com/zh-cn/azure…
-
总结
| 功能 | 能力描述 | 适用方案 |
|---|---|---|
| 识别一次 | 在一次STT中只能识别一种语言语音并转为文本，但是没有语言字返回 | 支持，适用在一次语音控制电视时只会用一种语言语音的情况，即在移动端使用STT之前告诉用户只能使用某一种语言，缺点：如果用户说了其他语言的语音，无法阻止，也会正常STT，导致调用chat-gpt会有自动翻译问题 |
| 识别一次+起始语言识别 | 在一次STT中只会识别语言列表（最多4种）中的一种语言语音并转为文本，其他的语种不会识别，有语言字段返回 | 支持，适用在一次语音控制电视时只会用一种语言语音的情况, 缺点：无法控制语音监听时间 |
| 连续识别 | 在一次STT中连续识别多个语言语音并转为文本，但是没有语言字段返回 | 不支持 |
| 连续识别+起始语言识别 | 在一次STT中只能识别语言列表（最多4种）中的一种，其他的语种不会识别，有语言字段返回 | 支持，适用在一次语音控制电视时只会用一种语言语音的情况，缺点：1）较“识别一次”有点功能冗余 2）不能自动停止监听麦克风语音时间 |
| 连续识别+连续语言识别 | 在一次STT中识别语言列表中（最多10种）的所有语言，有语言字段返回 | 支持，适用在一次语音控制电视时会用多种语言语音的情况，缺点：1）识别率很低，2）需要在调用chat-gpt设置多种语言的示例 |
-
调用OpenAi获取指令
调用OpenAi接口获取控制电视的指令，首先需要定义协议（系统信息）、示例（用户+助手），如下图所示
官方地址：oai.azure.com/chat
-
协议设置
根据微软同事前期提供的协议示例，再让chatGpt帮忙分析优化，得出协议组成按如下部分
| 协议组成 | 内容 |
|---|---|
| 协议名称 | 统一设备描述语言协议 |
| 协议版本 | v1.0.0 |
| 概述 | 该协议定义了智能家居控制 API 的 JSON 格式报文，以及相关的字段和槽位。该协议能够帮助 AI 智能家居助手准确理解用户的意图，从而更好地控制家里的智能设备。 |
| 通信格式 | 该协议采用 JSON 格式，包含以下字段和槽位：- classifier: 消息分类或类别，包括 mideaDomain 和 publicDomain。 |
-
domain: 消息领域技能，包括 deviceControl、deviceQuery、store、scenario、player、recipe、kitchen、config、alarm、command、general。
-
utterance: 处理后的话术。
-
fallback: 用户原始话术。
-
intent: 用户意图，包含以下字段和槽位：
-
deviceName: 设备名称，包括整挂灯、壁挂炉、壁挂洗衣机、冰箱、波轮洗衣机、床头灯、灯、地暖、电磁炉、电饭煲、电热水瓶、电水壶、电压力锅、风扇、复式洗衣机、干衣机、管线机、滚简洗衣机、集成灶、加湿器、净水机、烤箱、空气净化器、空气能热水器、空调、快速烹饪机、烹饪机、破壁机、取暖器、燃气热水器、扫地机、微波炉、微蒸烤一体机、西式烹饪机、洗碗机、洗衣机、消毒柜、新风机、烟机、饮水机、浴霸、灶具、蒸箱、智能床、中央空调、除湿机、大烤箱、空气炸锅、空调扇、料理机、嵌入式蒸箱、微波饭煲、微波烤箱、小烤箱、蒸烤炉。
-
deviceVerb: 设备操作，包括 powerOn、start、powerOff、stop、cancel。
-
location: 室内位置，包括阳台、客厅、主卧、次卧、厨房、浴室等。
-
negative: 否定操作。
-
allVerb: 所有操作。
-
duration: 操作持续时间。
-
frequency: 操作频率。
-
timePeriod：时间段，包括上午、中午、下午等。 | | 版本历史 | - v1.0.0：该协议定义了智能家居控制 API 的 JSON 格式报文，以及相关的字段和槽位。 | | 用户 | 我要开灯，小酷 | | 助手 | { "classifier": "mideaDomain", "domain": "deviceControl", "utterance": "我要开灯", "fallBack": "我要开灯", "intent": { "deviceName": "灯", "deviceVerb": "powerOn", "location": "", "negative": "", "allVerb": "", "timePeriod": "" } } | | 协议原始内容 | 你是AI智能家居助手，你的名字叫小酷，根据用户要求，生成控制API的JSON格式报文。 注意，除JSON外不要生成任何其他内容。 xx公司的统一设备描述语言协议是智能家居技能与AI平台之间的通讯协议。基于这些协议可以准确地理解用户的意图，轻松地通过语音控制家里的智能设备，与设备进行交互。 统一设备描述语言协议采用JS0N消息格式。该协议的输入是语音入口设备和输入文本，该协议的输出是response格式，组成字段包括lassifier、domain、utterance、fallBack、intent。字段解释如下:Classifier:分类或类别，包括如下字段值mideaDomain、publicDomain; mideaDomain是指美的电器设备类别，publicDomain是指非公家电类别;domain: 领域技能，包括如下字段值: deviceControl、deviceQuery、store、scenari0、player、recipe、Kitchen、config、alarm、cmd、general;utterance:处理后话术fallBack:用户原话术intent:用户意图，组成字段包括: deviceName、devceVerb、locatonnegative、allVerb;deviceName: 设备名字，包括: 整挂灯，壁挂炉，壁挂洗衣机，冰箱，波轮洗衣机,床头灯,灯，地暖，电磁炉，电饭煲电热水瓶，电水壶，电压力锅,风扇,复式洗衣机,干衣机,管线机,滚简洗衣机,集成灶,加湿器,净水机，烤箱,空气净化器,空气能热水器,空调,快速烹饪机,烹饪机,破壁机,取暖器，燃气热水器热水器,扫地机,微波炉,微蒸烤一体机,西式烹饪机洗碗机,洗衣机，消毒柜,新风机,烟机,饮水机,浴霸,灶具,蒸箱,智能床中央空调,除湿机,大烤箱,空气炸锅,空调扇,料理机,嵌入式蒸箱,微波饭煲微波烤箱，小烤箱,蒸烤炉;DeviceControl: 电器控制，包括如下意图intent: DevicePowern、DevicePower0ff、DevicStart、DeviceStop、DeviceResume、DeviceVolumeControl、DeviceSetFunction;DevicePower0n: 开启设备，包括如下槽位slot: deviceName、deviceVerb、location、duration、frequency、negative、allVerb、timePeriod;DevicePower0ff: 关闭设备，包括如下槽位slot: deviceName、deviceVerb、location、duration、frequency、negative、allVerb、timePeriod;deviceVerb: 设备上的操作，包括: powerOn、start、power0ff、stop、cancelpowerOn:开机;start:启动poweroff:关机;stop:停止;cancel:取消;allVerb:表示所有的意思;neqative:表示否定的意思:deviceAspect:timePeriod: am(上午) 、noon(中午)、pm(下午)location:表示室内位置，包括: 阳台、客厅、主卧、次卧、厨房、浴室; |
-
-
问题及解决
问题1： 测试发现，定义示例（用户+助手）的语种直接影响返回结果的语言，如果在用户设置中语言是中文，当真实提问是用其他国家的语言，chat-gpt也能正常回答，但是会自动把结果文本中的相关协议命令翻译成提问语种的文本，这样导致在下发控制指令给设备时无法识别的后果，如下所示
解决问题1： 提前在示例中定义好所会涉及的语言提问，然后给出统一的语言回答，这样尽管使用不同的语言提问也会得到统一语言的协议指令
引出问题2： 由于我们真实设备的出货国家很多，涉及不同的语言，所有的语言示例都需要设置，这样会使chat-gpt响应很慢
解决问题2： 在移动端录入语音文本时，限定每次只能说一种语言，在访问coolita后台时，带上语言字段即可，这样每次调用chat-gpt时只需要设置相应的语言对应的示例即可，而不是设置所有可能语言的示例
问题3： 本地测试访问chat-gpt时，使用时间都在（5-11秒），该问题和设置示例多少没有关系，就是响应慢
解决问题3: 23年7月份gpt-35-turbo已有最新api版本（2023-07-01-preview）推出，该版本在响应速度上有很大提升！本地测试只需要1~6秒
-
价格明细
-
实时语音转文本（以东南亚区域为准）
模式 价格（每小时） 每15秒 即用即付 标准语音转文本（1 每小时 $0.004167每15秒 模式 价格（每月） 每15秒 承诺层级 - 2,000 个小时的定价为 0.80 每小时 - 10,000 个小时的定价为 0.65 每小时
- 50,000 个小时的定价为 0.50 每小时 | - $0.003333每15秒
- $0.002708每15秒
- 1,520，超额$0.76 每小时
- 10,000 个小时的定价为 0.62 每小时
- 50,000 个小时的定价为 0.48 每小时 | - $0.003166每15秒
- $0.002583每15秒
- $0.002每15秒 |
模式 价格（每年） 每15秒 已断开连接的容器（把微软SST服务部署在自己的服务器上，微软不做流量监控统计，用户直接买断一年） - 每年$74,100，每年最大使用量12 万小时，每月预计使用量1 万小时 - 每年0.62 每小时, $0.002583每15秒
- 0.002每15秒 |
官方网址：azure.microsoft.com/zh-cn/prici…
-
Azure OpenAI （以美国东部区域为准）
3.5版本（0613） Prompt tokens Completion tokens gpt-35-turbo $0.0015 per 1,000 tokens $0.002 per 1,000 tokens gpt-35-turbo-16k $0.003 per 1,000 tokens $0.004 per 1,000 tokens gpt-4 略 略 注：token表示模型生成的文本长度
* 对于英文而言，一个单词通常等于一个token，因为英文中的单词通常在空格或标点符号处分隔
* 对于中文而言，一个汉字通常被视为一个token，因为中文中的汉字通常不能被空格或标点符号分隔
官方网址：azure.microsoft.com/zh-cn/prici…
-
成本预估
比较 微软语音 STT(一次5秒) 0.000002*625+0.002864 每个月（20次请求,月活跃设备数：735643） 0.002864=$42137.63 -
