第四章 边界确认的输入输出模板：定义输入字段、输出字段、异常响应、置信度阈值
在完成了“用户场景”与“业务问题”的定性确认后，产品经理与AI工程师需要在接口契约层面完成对齐。本章聚焦于边界确认四要素的模板化定义，这是从模糊需求走向可编码规则的关键一步。
🔑 核心观点： 边界确认的输入输出模板，本质上是一份机器可执行的“产品指令”。它定义了模型能力的入口（Input）、出口（Output）、不确定性（Confidence）以及失效模式（Exception）。这份模版是后续需求拆解与验收标准制定的唯一锚点。
4.1 业务问题与用户场景回顾
在实际项目中，为何需要“边界确认”模板？通常来自以下用户访谈中的痛点：
- 产品经理视角：“AI模型有时候不回答，有时候答非所问，我没办法跟客户承诺它的能力范围。”
- 算法工程师视角：“我不知道哪些情况需要拒绝回答，哪些情况可以尝试输出，缺乏明确的输入约束。”
- 质检/测试视角：“测试用例没有覆盖‘模型拒绝’的情况，我们不知道什么样的回答算越界。”
因此，本章的模板不是技术文档，而是产品需求到模型约束的翻译器。
4.2 需求拆解：四要素结构
我们将边界确认的需求，拆解为以下四个核心要素，必须全部定义才算对模型能力完成了切分：
| 核心要素 | 业务含义 | 产品侧交付物 |
|---|---|---|
| 输入字段 | 模型接收什么数据？数据格式、范围、约束是什么？ | 数据字段清单 + schema |
| 输出字段 | 模型必须返回什么？结构、类型、可选字段定义。 | 响应体模板 + 字段释义 |
| 异常响应 | 模型何时必须“说不”？如何返回“我不确定”或“我无法处理”？ | 异常码表 + 拒绝策略 |
| 置信度阈值 | 模型输出高于多少分才可信？低于阈值如何处理？ | 阈值矩阵 + 降级策略 |
4.3 模板详解：字段定义规范
4.3.1 输入字段定义表
产品经理需要按照以下粒度定义输入，避免模糊条件（如“用户提问”）导致算法侧出现解析歧义：
| 字段名 | 类型 | 必需/可选 | 约束/描述 |
|---|---|---|---|
| query_text | string | 必需 | 最大长度200字符；禁止HTML标签；必须为UTF-8 |
| user_context | object | 可选 | 需包含{user_id, session_id, timezone} |
| history | array | 可选 | 最多5轮对话历史；每轮固定[role, content]结构 |
| intent_hint | enum | 可选 | 只接受：[query, command, complaint]；其他值丢弃 |
4.3.2 输出字段定义表
| 字段名 | 类型 | 逻辑说明 | 置信度阈值绑定 |
|---|---|---|---|
| answer | string | 当模型置信度≥阈值时填充，否则为空字符串 | 0.70 |
| confidence_score | float | [0.0, 1.0]区间，任何情况下都必须返回 | — |
| exception_code | enum | 异常时返回预设代码：NORMAL, LOW_CONFIDENCE, INPUT_INVALID, OUT_OF_SCOPE | N/A |
| rejection_reason | string | 仅当exception_code非NORMAL时返回，说明具体原因 | N/A |
💡 产品实践经验： 必须在输出字段中强制包含
confidence_score。该字段是后续指标验证（如准确率、召回率、误拒绝率）的数字基础。没有置信度输出，就无法定义“边界在哪”。
4.4 异常响应与置信度阈值联动设计
异常响应不是简单的“报错”，而是模型能力边界的防守策略。置信度阈值与异常响应必须联动定义：
| 置信度区间 | 输出行为 | 异常响应码 | 产品表现 |
|---|---|---|---|
| ≥ 0.85 | 正常返回answer | NORMAL | 高可信度，直接展示 |
| [0.70, 0.85) | 返回answer + 置信度标注 | LOW_CONFIDENCE | 展示答案，但附带“AI不确定”提示 |
| [0.40, 0.70) | 不返回answer，仅返回fallback建议 | LOW_CONFIDENCE | 转人工或提供相近功能选项 |
| < 0.40 | 不返回answer，记录日志 | OUT_OF_SCOPE | 直接拒绝，不产生用户体验干扰 |
⚠️ 避坑指南： 不要将置信度阈值写为固定值。在验收标准中，必须定义动态调整规则（例如：上线初期置信度阈值设为0.85；运行2周后根据实际拒绝率、误报率调整为0.70）。阈值是业务参数，不是技术参数。
4.5 指标验证与验收标准
基于上述模板定义，以下为对应的验收指标：
- 准确率 (Precision)： 模型边界内的回答准确性 ≥ 90%。
- 精确率 vs 召回率均衡： 调整阈值0.70时，误拒绝率 ≤ 5%；误接受率 ≤ 3%。
- 异常覆盖率： 所有定义的异常码（INPUT_INVALID, OUT_OF_SCOPE, LOW_CONFIDENCE）在对应输入场景下100%触发。
- F1-Score 边界内评估： 仅对“模型未拒绝”的样本计算F1，确保接受范围内的质量。
4.6 交付物模板：输入输出边界确认文档
产品经理最终输出的标准化模板，使用JSON表达，作为研发的契约：
{
"边界确认版本": "1.0",
"模型能力名称": "智能问答系统V3",
"输入字段": [
{"name": "query_text", "type": "string", "required": true, "max_length": 200, "regex": "^[\\u4e00-\\u9fa5a-zA-Z0-9 .,?!]+$"},
{"name": "user_context", "type": "object", "required": false, "schema": {"user_id": "string", "session_id": "string"}}
],
"输出字段": [
{"name": "answer", "type": "string", "nullable": true, "condition": "confidence >= 0.70"},
{"name": "confidence_score", "type": "float", "required": true, "range": [0.0, 1.0]},
{"name": "exception_code", "type": "enum", "values": ["NORMAL", "LOW_CONFIDENCE", "INPUT_INVALID", "OUT_OF_SCOPE"]}
],
"异常响应策略": {
"INPUT_INVALID": {"behavior": "reject", "response_text": "输入格式不符合规范"},
"OUT_OF_SCOPE": {"behavior": "reject", "response_text": "暂不支持该问题类型"},
"LOW_CONFIDENCE": {"behavior": "degrade", "fallback_action": "transfer_to_human"}
},
"置信度阈值": {
"high_confidence_threshold": 0.85,
"low_confidence_threshold": 0.70,
"rejection_threshold": 0.40,
"evaluation_metric": "f1_score"
}
}
🛠️ 制作检查清单：
✓ 每个输入字段是否都明确了约束条件（长度、正则、可选性）？
✓ 异常码是否覆盖了所有已知边界场景（空输入、越界输入、低分输入）？
✓ 阈值是否定义了业务含义（如“低分”对应“人工介入”）？
✓ 输出字段是否包含置信度变量？
✓ 每个输入字段是否都明确了约束条件（长度、正则、可选性）？
✓ 异常码是否覆盖了所有已知边界场景（空输入、越界输入、低分输入）？
✓ 阈值是否定义了业务含义（如“低分”对应“人工介入”）？
✓ 输出字段是否包含置信度变量？
至此，我们已经从用户场景出发，经过需求拆解，将边界确认固化为输入输出模板及联动阈值。这份文档将直接作为后续能力切分与验收标准的基线。