wuyang6
69 lines
6.1 KiB
Markdown
69 lines
6.1 KiB
Markdown
# 车载控制
|
||
|
||
## 标注输出
|
||
|
||
> 注意：旧标签资料中同时存在 tag 标签和 Function 定义。本卡片不直接声明最终训练标签；生成数据前必须结合 `判断维度/标注输出形态.md` 确认当前任务使用 Agent 形式还是 Function 形式。
|
||
|
||
- 旧 tag 标签：车载控制
|
||
- Agent 包装候选（不代表最终）：Agent(tag="车载控制")
|
||
- Function 输出候选：Query：打开车窗code：(未共识)Query：关闭智驾code：(未共识)code：device定义示例：满足：车载端本地执行调用对应设备执行操作，并获取执行结果，基于执行结果生成对应TTS
|
||
- 推荐输出形态：待确认。
|
||
|
||
## 功能抽象
|
||
|
||
车载控制
|
||
|
||
## 适用范围
|
||
|
||
车载端设备控制功能：设备类型：可控制的设备约200种，包括空调、雨刮、前备箱、灯等音区：设备和车内音区可以关联，音区包括主驾、副驾、后排、前排等，如果query中不包含音区则默认使用ASR识别音区。query中包含音区的示例为“打开主驾空调”、“关闭副驾车窗”。不包含音区的示例为“打开车窗”、“关闭雨刮”控制的操作包括：打开or关闭设备：例如“打开空调”、打开主驾空调设置设备属性：例如“前备箱最大开度设置为百分之五十”车载端特有控制功能：车载特有功能：智驾、泊车、哨兵、用车习惯、音区、行车记录仪、各类车控功能页面控制的操作包括：打开or关闭功能或页面：打开自动泊车、打开儿童锁页面设置功能属性：充电阈值设置为百分之八十参考文档：全量词表车控全功能梳理
|
||
|
||
### 意向性车控表达
|
||
|
||
当 query 包含车内设备、车内空间、车载功能或明确车载上下文，并表达舒适度、主观感受、状态不满或潜在操作意向时，优先归入 `车载控制`。
|
||
|
||
典型信号：
|
||
|
||
- 车内设备：空调、车窗、座椅、阅读灯、后视镜、雨刮、引擎盖、车门、氛围灯等。
|
||
- 车内空间/位置：车里、车内、后排、副驾、我这边、头顶、脚底下等。
|
||
- 车载功能/俗称：车耳朵、防反光、压线提示音、雨雪防滑模式、湿滑模式等。
|
||
|
||
示例：
|
||
|
||
- 车里空调好热。
|
||
- 脚底下好冷，腿快冻麻了。
|
||
- 风一直吹我脸，有点难受。
|
||
- 后视镜反光看不清，有个防反光的功能你帮我调一下。
|
||
|
||
边界：
|
||
|
||
- 如果 query 不包含车内设备/空间/功能线索，只是“我好热啊”“我有点晕车”这类身体感受或闲聊表达，不要强行归入车载控制，通常按闲聊/QA 等非车控标签判断。
|
||
- 如果上文已经明确是车控慢系统确认链路，次轮“帮我开启”“调一下吧”等确认/继续类表达可以继承车控任务；没有上文时不做继承。
|
||
|
||
## 典型 Query
|
||
|
||
打开空调打开座椅加热自动泊车
|
||
|
||
## 三级语义功能点
|
||
|
||
打开操作(ActivateAction<object@OpenIntent>)关闭操作CloseAction<object@VehicleModule[adjustment]>调整操作InformAction<object@VehicleModule[adjustment]>
|
||
|
||
## Function / Agent 说明
|
||
|
||
Query：打开车窗code：(未共识)Query：关闭智驾code：(未共识)code：device定义示例：满足：车载端本地执行调用对应设备执行操作，并获取执行结果，基于执行结果生成对应TTS
|
||
|
||
## 满足边界问题
|
||
|
||
（待讨论）边界1：车载设备和家庭设备区分车载既有设备属性又有房间属性，因此车载设备可能和家庭设备存在冲突，例如“空调”、“冰箱”、“灯”边界2：车载控制和自动任务（见下面自动任务）车载控制部分指令也存在条件，和自动任务语义存在冲突倒车时后视镜自动下翻需要明确定义出来到底哪些是车载控制，哪些是自动任务手机端等如果要接入自动任务存在相似问题边界3：车载端特有的控制功能，和其他端语义存在冲突 打开360——APP/车控——长线都是控制（只区分控制和IOT）打开监控——IOT/车控（device区分）驾驶模式——QA/车控（分端）以下问题同边界1：车载端特有的控制功能定义为“车载控制”，其他端特有的控制功能会定义成“xx控制”么（其他端暂不定义新的标签）如果把IOT设备拿到车上进行语控，是否属于车载控制（同边界1）对于主控设备的操作是否属于设备控制：（对手机说和对车说不一样，协同响应如何迁移planning模型？）打开车窗打开车辆座椅加热打开车辆方向盘加热打开电视电视播放小猪佩奇跟手机说——IOT电视跟电视说——主控设备跟车说——车载后排电视在当前设备上的系统级别控制请求，但是带设备关键字，是否属于设备控制：电视发起请求：query = 电视音量大一点电视发起请求：query = 电视亮一点手机控车、家控车不属于设备控制，任何控车场景都属于车载控制。例如手机或音箱端发起如下请求：打开车窗打开座椅加热打开方向盘加热主控设备（例如电视、音箱）只有支持spec协议的功能才支持IOT控制，其他不支持的功能需要走协同响应，但是两种场景query类别均属于“设备控制”。例如音箱控电视场景：走IOT控制的功能：打开电视走协同响应的功能：电视播放小猪佩奇在当前设备发起控制当前设备的指令属于系统控制，不属于设备控制：电视发起请求：query = 电视音量大一点音箱发起请求：query = 电视音量大一点
|
||
|
||
## 易混淆标签
|
||
|
||
系统控制设备控制应用控制自动任务车载设备状态查询QA
|
||
|
||
## 划分原则
|
||
|
||
边界1：设备识别统一建模，对全部任意device统一定义，不区分车载还是iot场景，默认device是本机。在device正确的前提下，是否走IOT spec协议或协同响应等由skill或control agent自己判断。（TODO，中控设备决策做到什么程度，音箱端：打开摄像头）目前扫地机、洗衣机、冰箱是3个特例。边界2：条件任务，统一建模，全部按照自动任务的形式出function边界3：在车载端，车控优先
|
||
|
||
## 未解决问题
|
||
|
||
待补充。
|