Align label output target formats
This commit is contained in:
@@ -1,24 +1,32 @@
|
||||
# 多指令判断
|
||||
|
||||
多指令是独立维度,不属于业务标签树。它用于判断一个 query 是否需要拆成多个可独立执行的子任务,以及每个子任务对应的业务标签或 intent。
|
||||
多指令是独立维度,不属于业务标签树。它用于判断一个 query 是否需要拆成多个可独立执行的子任务,以及每个子任务对应的业务标签或 function。
|
||||
|
||||
## 输出目标
|
||||
|
||||
推荐结构:
|
||||
当前数据开发默认口径下,多指令最终 target 不是一个 JSON group,而是:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"condition": null,
|
||||
"querys": [
|
||||
{"subquery": "关闭卧室的灯", "intent": "设备控制"},
|
||||
{"subquery": "定一个明天下午四点的闹钟", "intent": "闹钟"}
|
||||
]
|
||||
}
|
||||
]
|
||||
1. 先把原 query 拆成多个可独立判断的子句。
|
||||
2. 每个子句单独判断业务标签和输出形态。
|
||||
3. 每个子句单独输出一条叶子 target。
|
||||
4. 如果需要输出 complex,complex 作为独立行放在最前面,不属于任何单个子句。
|
||||
|
||||
示例:
|
||||
|
||||
```text
|
||||
complex=true
|
||||
Agent(query="退出导航",tag="地图导航")
|
||||
Agent(query="打开后视镜加热",tag="车载控制")
|
||||
```
|
||||
|
||||
其中 `condition` 由自动任务维度负责判断;没有条件时为 `null`。
|
||||
其中 `query` 字段保留拆分后的子句文本,`tag` 字段是该子句的业务标签。
|
||||
|
||||
注意:
|
||||
|
||||
- 多指令只决定“是否拆分、怎么拆分、如何改写子句”。
|
||||
- 每个子句的 `tag` 或 function 仍要继续走业务标签判断和输出形态判断。
|
||||
- 多指令不是和 `Agent(...)` / function 并列的最终标签,而是把多个叶子 target 组合起来的结构。
|
||||
- `condition` 由自动任务维度负责;普通多指令没有 condition。
|
||||
|
||||
## 单意图
|
||||
|
||||
@@ -52,50 +60,29 @@
|
||||
|
||||
### 动作继承
|
||||
|
||||
“打开空调和电视”应改写为:
|
||||
“打开空调和电视”应拆成两个子句并分别输出:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"condition": null,
|
||||
"querys": [
|
||||
{"subquery": "打开空调", "intent": "设备控制"},
|
||||
{"subquery": "打开电视", "intent": "设备控制"}
|
||||
]
|
||||
}
|
||||
]
|
||||
```text
|
||||
Agent(query="打开空调",tag="设备控制")
|
||||
Agent(query="打开电视",tag="设备控制")
|
||||
```
|
||||
|
||||
### 无 trigger 的位置继承
|
||||
|
||||
“打开客厅电视和吸顶灯”应改写为:
|
||||
“打开客厅电视和吸顶灯”应拆成两个子句,并继承必要位置信息:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"condition": null,
|
||||
"querys": [
|
||||
{"subquery": "打开客厅电视", "intent": "设备控制"},
|
||||
{"subquery": "打开客厅吸顶灯", "intent": "设备控制"}
|
||||
]
|
||||
}
|
||||
]
|
||||
```text
|
||||
Agent(query="打开客厅电视",tag="设备控制")
|
||||
Agent(query="打开客厅吸顶灯",tag="设备控制")
|
||||
```
|
||||
|
||||
### 设备继承
|
||||
|
||||
“客厅吸顶灯调到最亮色温调到最大”应改写为:
|
||||
“客厅吸顶灯调到最亮色温调到最大”应拆成两个子句,并继承设备名:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"condition": null,
|
||||
"querys": [
|
||||
{"subquery": "客厅吸顶灯调到最亮", "intent": "设备控制"},
|
||||
{"subquery": "客厅吸顶灯色温调到最大", "intent": "设备控制"}
|
||||
]
|
||||
}
|
||||
]
|
||||
```text
|
||||
Agent(query="客厅吸顶灯调到最亮",tag="设备控制")
|
||||
Agent(query="客厅吸顶灯色温调到最大",tag="设备控制")
|
||||
```
|
||||
|
||||
## 典型单意图例子
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 标注输出形态
|
||||
|
||||
这个维度用于判断最终监督标签应该写成 function program、intent,还是 `Agent(tag="xxx")` 包装。详细 object、function、intent 定义见 `../输出能力/`。
|
||||
这个维度用于判断最终监督标签应该写成 function program、`Agent(tag="xxx")` 包装,还是特殊结构化输出。详细 object、function、intent 定义见 `../输出能力/`。
|
||||
|
||||
它和业务标签不同:
|
||||
|
||||
@@ -16,14 +16,44 @@
|
||||
- `../输出能力/意图目录.md`
|
||||
- `../输出能力/输出组合规范.md`
|
||||
|
||||
## 当前数据开发默认口径
|
||||
|
||||
在当前标签大师和数据开发链路里,最终 target 优先分成两类:
|
||||
|
||||
1. **Function 形式**:只有当某个能力已经有明确 function 定义和可用参数签名时,才输出 function program,例如 `QA()`、`CalendarQA(...)`、`Summarize(...)`。
|
||||
2. **Agent 形式**:没有明确 function 定义、或只是旧 tag / intent 业务标签时,默认输出 `Agent(tag="xxx")`,例如 `Agent(tag="地图导航")`。
|
||||
|
||||
`intent` 名称可以作为业务标签名、拆分子句里的意图字段或兼容中间形态,但在当前数据开发默认口径下,不作为首选最终 target。除非用户明确要求“输出 intent 形式”,否则不要把 `intent = 地图导航` 和 `Agent(tag="地图导航")` 并列反问。
|
||||
|
||||
## 两层输出结构
|
||||
|
||||
最终输出先判断外层结构,再判断叶子 target:
|
||||
|
||||
| 层级 | 类型 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| 外层结构 | 单意图 | 只有一个 query 和一个叶子 target。 |
|
||||
| 外层结构 | 多指令 | 需要拆成多个子句,每个子句单独输出一条叶子 target,并按行组合。 |
|
||||
| 外层结构 | 自动任务 | 需要输出 condition + querys,每个子任务再写自己的叶子 target。 |
|
||||
| 叶子 target | function program | 已 function 化且签名明确的能力。 |
|
||||
| 叶子 target | `Agent(tag="xxx")` | 未 function 化或旧 tag / intent 标签。 |
|
||||
|
||||
自动任务、多指令不是和 function / Agent 并列的叶子 target,而是包住 function / Agent 的结构化外壳。
|
||||
|
||||
多指令场景里,Agent 叶子 target 需要保留子句文本:
|
||||
|
||||
```text
|
||||
Agent(query="退出导航",tag="地图导航")
|
||||
Agent(query="打开后视镜加热",tag="车载控制")
|
||||
```
|
||||
|
||||
## 基本原则
|
||||
|
||||
1. 不要默认把所有旧 `tag标签` 包装成 `Agent(tag="xxx")`。
|
||||
1. 已 function 化并且 function 签名明确的能力,优先使用 function program。
|
||||
2. object 只作为 function 参数,不单独作为最终 target。
|
||||
3. function 可以是多行 program,允许先构造 object 再调用 function。
|
||||
4. intent 可以直接作为 target,也可以按任务要求包装成 `Agent(tag="xxx")`。
|
||||
5. Agent 字段表示承接方,是知识维度,不等于最终 target。
|
||||
6. 如果当前数据任务没有明确要求 function、intent 还是 Agent 包装,必须向用户确认,不要自行决定。
|
||||
4. 未 function 化或 function 签名不明确的旧 `tag标签` / intent 标签,默认使用 `Agent(tag="xxx")`。
|
||||
5. Agent 字段表示承接方,是知识维度,不等于最终 target 里的 tag 名;不要写成 `Agent(tag="mapAgent")`。
|
||||
6. 如果用户明确要求 function program,但对应卡片没有 function 签名,必须说明 function 待补充,不要臆造函数名和参数。
|
||||
7. 对 QA 子类尤其要保守:`医疗问答`、`百科`、`美食问答` 等可能只是知识分类,最终输出可能是 `QA()`,不一定是 `Agent(tag="医疗问答")`。
|
||||
|
||||
## 常见 Function 形态
|
||||
@@ -41,7 +71,7 @@
|
||||
|
||||
## Agent 包装形态
|
||||
|
||||
当任务明确是规划模型的 Agent 标签数据,或者用户明确给出 `Agent(tag="xxx")`,可以使用 Agent 包装形态。
|
||||
当能力没有明确 function 定义,或者任务使用旧 tag / Agent 标签体系时,使用 Agent 包装形态。
|
||||
|
||||
例子:
|
||||
|
||||
@@ -51,7 +81,7 @@ Agent(tag="餐饮服务")
|
||||
Agent(tag="设备控制")
|
||||
```
|
||||
|
||||
如果用户只说“地图导航标签”但没有说明输出格式,标签知识可以推荐业务标签,但生成数据前仍要确认最终 target。
|
||||
如果用户只说“地图导航标签”,且没有明确要求 function program 或 intent target,在当前数据开发默认口径下推荐 `Agent(tag="地图导航")`。
|
||||
|
||||
## 推荐输出
|
||||
|
||||
@@ -60,14 +90,13 @@ Agent(tag="设备控制")
|
||||
```text
|
||||
业务标签:地图导航
|
||||
输出形态候选:
|
||||
- Agent:Agent(tag="地图导航")
|
||||
- Function:SearchRoute / Navigation / 其他地图 function 候选
|
||||
推荐:待用户确认,当前需求未说明使用 Agent 还是 Function
|
||||
- 推荐:Agent(tag="地图导航")
|
||||
- Function:当前知识库没有确认可用的地图导航 function 签名,不要臆造 Navigation(...)
|
||||
```
|
||||
|
||||
做数据生成时,如果 target 不明确,必须先问:
|
||||
做数据生成时,如果用户明确要求 function program,但对应标签没有可用 function 签名,必须先问:
|
||||
|
||||
```text
|
||||
这批数据最终 target 是使用 function program、intent,
|
||||
还是使用 Agent 包装,例如 Agent(tag="地图导航")?
|
||||
这批数据要求输出 function program,但当前标签卡片没有确认 function 签名。
|
||||
是否先按 Agent(tag="地图导航") 生成,还是你补充地图导航 function 定义?
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user