目录
- 总结
- 明确定义 label schema（互斥 / 可多选）
- 一、总体设计原则（先说清楚“为什么这样分”）
- 二、Intent Schema 定义（可直接写进标注文档）
- Intent 1：FACT_QUERY（功能性 / 数据型查询）
- 1️⃣ Intent 定义（Definition）
- 2️⃣ 触发条件（When to use）
- 3️⃣ 示例（Positive Examples）
- 4️⃣ 不触发条件（When NOT to use）
- 5️⃣ 反例（Negative Examples）
- 6️⃣ 技术绑定（工程约束，面试加分）
- Intent 2：KNOWLEDGE_QUERY（知识型问答）
- 1️⃣ Intent 定义（Definition）
- 2️⃣ 触发条件（When to use）
- 3️⃣ 示例（Positive Examples）
- 4️⃣ 不触发条件（When NOT to use）
- 5️⃣ 反例（Negative Examples）
- 6️⃣ 技术绑定（工程约束）
- Intent 1：FACT_QUERY（功能性 / 数据型查询）
- 三、互斥 / 可多选规则（这是面试官必追问点）
- 1️⃣ 两个 Intent 是否互斥？
- 规则写法（直接可用）
- 2️⃣ 复合问题如何处理？（高级）
- 示例
- 1️⃣ 两个 Intent 是否互斥？
- 四、Golden Sample 示例（结合你这个场景）
- 引入 golden samples 做一致性校验
- 对高混淆样本做人工 review + 再标注
总结
intent 本身就高度相关，标注人员很容易混淆：
- 每个 label 的定义、反例和冲突规则写成标注规范。
- 同时引入一批 golden samples，作为高置信标准样本，在标注前做校准、标注中做抽检、入训前做质量 gate，用 golden accuracy 和 Kappa 系数监控一致性，避免 LoRA 学到不稳定边界。
- 对高混淆样本做人工 review + 再标注
明确定义 label schema（互斥 / 可多选）
很好，这个例子非常工程化，而且你给出了技术实现路径（function calling / RAG），这正是面试官希望看到的。下面我按“可直接作为标注规范 + 面试可复述”的方式，完整演示如何为这 2 个 Intent 定义 清晰、可执行、可校验 的 label schema。
一、总体设计原则（先说清楚“为什么这样分”）
Intent 的定义不是语义分类本身，而是“下游技术路径选择”
即：同一句用户输入，最终是 调用系统接口，还是 检索知识并生成答案。
因此：
- FACT_QUERY → function calling → 结构化返回
- KNOWLEDGE_QUERY → RAG → 自由文本生成
这句话在面试中说出来，会被认为是系统设计导向的 intent 设计。
二、Intent Schema 定义（可直接写进标注文档）
Intent 1：FACT_QUERY（功能性 / 数据型查询）
1️⃣ Intent 定义（Definition）
用户请求确定、可验证、来自系统或数据库的事实信息，
该信息需要通过 接口调用或参数化查询 获得，而非模型主观生成。
2️⃣ 触发条件（When to use）
什么触发条件？
“触发条件其实就是给标注员或者模型判定的具体规则，告诉你这条话应该归哪个 Intent。
触发条件 ≈ 业务场景特征
也就是说，它描述了用户在什么具体场景下，会产生某个 Intent 的需求。
但它比纯业务场景更可操作，因为它指明了模型或标注员可以观察到的特征（比如关键词、输出形式、信息来源），不是抽象概念。
| 概念 | 理解 | 举例 |
|---|---|---|
| 业务场景 | 用户在什么情境下提出请求 | “用户想查自己订单状态” |
| 触发条件 | 判定某条输入属于这个 Intent 的可观察特征 | “句子里有‘状态’、‘多少’，输出是结构化数据，可直接从接口获取” |
满足 至少一个：
- 查询实时 / 准实时数据
- 查询用户或业务系统中的结构化字段
- 明确要求「查 / 看 / 返回 / 给我具体数值」
典型动词
- 查、看、返回、多少、有没有、状态、列表
3️⃣ 示例（Positive Examples）
“我这个订单现在是什么状态？”
“帮我查一下上个月的账单金额”
“这个账号还有多少可用额度？”
“目前库存还有吗？”
4️⃣ 不触发条件（When NOT to use）
- 请求解释、原因、原理、使用建议
- 无法通过单次接口返回的开放性问题
5️⃣ 反例（Negative Examples）
“为什么我的订单一直没发货？” # 原因解释 → KNOWLEDGE_QUERY
“这个功能一般什么时候用？” # 使用场景 → KNOWLEDGE_QUERY
6️⃣ 技术绑定（工程约束，面试加分）
下游处理方式：
- 使用 function calling
- 必须生成结构化参数
- 禁止自由发挥式生成
Intent 2：KNOWLEDGE_QUERY（知识型问答）
1️⃣ Intent 定义（Definition）
用户请求背景解释、使用说明、原理性说明或经验性知识，
答案通常来自 文档、FAQ、知识库，而非业务系统接口。
2️⃣ 触发条件（When to use）
满足 至少一个：
- “是什么 / 为什么 / 怎么用 / 有什么区别”
- 无明确结构化返回格式
- 允许一定程度自然语言生成
典型动词
- 是什么、为什么、怎么、区别、介绍一下、解释
3️⃣ 示例（Positive Examples）
“这个功能是做什么用的？”
“为什么会出现这个错误？”
“如何使用自动续费？”
“接口超时一般是什么原因？”
4️⃣ 不触发条件（When NOT to use）
- 明确请求当前用户或系统状态
- 可通过单条接口直接返回的事实
5️⃣ 反例（Negative Examples）
“我当前的套餐是什么？” # FACT_QUERY
“这个月用了多少流量？” # FACT_QUERY
6️⃣ 技术绑定（工程约束）
下游处理方式：
- RAG（向量检索 + 文档拼接）
- 允许解释型生成
- 输出为自然语言
三、互斥 / 可多选规则（这是面试官必追问点）
1️⃣ 两个 Intent 是否互斥？
结论：默认互斥，但允许复合输入拆解
规则写法（直接可用）
- 单轮输入中：- 若问题核心是“拿数据” → FACT_QUERY- 若核心是“要解释” → KNOWLEDGE_QUERY
2️⃣ 复合问题如何处理？（高级）
示例
“我这个订单现在什么状态？为什么这么久还没发货？”
处理方式（你这样说非常加分）
- 主 Intent：FACT_QUERY（查状态）
- 子 Intent：KNOWLEDGE_QUERY（解释原因）
但在 标注层：
- 当前轮只打 FACT_QUERY
- 原因解释交给 下一轮或规则补充
👉 这体现你理解多意图 ≠ 多路径同时执行
四、Golden Sample 示例（结合你这个场景）
你可以直接给一个 golden 样本：
{"query": "帮我查一下订单12345的物流状态","intent": "FACT_QUERY","reason": "需要调用订单系统接口返回结构化字段"
}
{"query": "为什么我的订单会被取消？","intent": "KNOWLEDGE_QUERY","reason": "请求原因解释，答案来自规则或文档"
}
