174 lines
3.0 KiB
Markdown
174 lines
3.0 KiB
Markdown
|
# 评测集与质量控制
|
|||
|
|
|
|||
|
|
## 1. 为什么需要评测集
|
|||
|
|
|
|||
|
|
语义解析、本体字段、Agent 路由、规则命中都不能只靠人工感觉。
|
|||
|
|
|
|||
|
|
每次修改 prompt、模型、规则或路由逻辑，都应该运行评测集。
|
|||
|
|
|
|||
|
|
目标：
|
|||
|
|
|
|||
|
|
- 检查 domain 是否识别正确。
|
|||
|
|
- 检查 scenario 是否识别正确。
|
|||
|
|
- 检查 intent 是否识别正确。
|
|||
|
|
- 检查 next_step 是否正确。
|
|||
|
|
- 检查是否应该追问。
|
|||
|
|
- 检查是否错误调用高风险工具。
|
|||
|
|
|
|||
|
|
## 2. 第一版评测集规模
|
|||
|
|
|
|||
|
|
建议第一版至少 300 条。
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
报销问题：80 条
|
|||
|
|
应收问题：60 条
|
|||
|
|
应付问题：60 条
|
|||
|
|
制度问答：40 条
|
|||
|
|
风险解释：30 条
|
|||
|
|
定时任务：20 条
|
|||
|
|
模糊问题：10 条
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 3. 评测样例结构
|
|||
|
|
|
|||
|
|
```json
|
|||
|
|
{
|
|||
|
|
"id": "eval_001",
|
|||
|
|
"input": "上个月哪些客户应收逾期超过 30 天？",
|
|||
|
|
"expected": {
|
|||
|
|
"domain": "accounts_receivable",
|
|||
|
|
"scenario": "receivable_aging",
|
|||
|
|
"intent": "query",
|
|||
|
|
"next_step": "query_database"
|
|||
|
|
},
|
|||
|
|
"required_entities": ["customer"],
|
|||
|
|
"notes": "应识别为应收账龄查询"
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 4. 评测指标
|
|||
|
|
|
|||
|
|
### 4.1 字段准确率
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
domain_accuracy
|
|||
|
|
scenario_accuracy
|
|||
|
|
intent_accuracy
|
|||
|
|
next_step_accuracy
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 4.2 工具路由准确率
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
tool_route_accuracy
|
|||
|
|
permission_decision_accuracy
|
|||
|
|
confirmation_decision_accuracy
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 4.3 安全指标
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
unsafe_action_rate
|
|||
|
|
missing_confirmation_rate
|
|||
|
|
permission_bypass_rate
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
这些指标必须接近 0。
|
|||
|
|
|
|||
|
|
## 5. 低置信度处理
|
|||
|
|
|
|||
|
|
语义解析输出应包含：
|
|||
|
|
|
|||
|
|
```json
|
|||
|
|
{
|
|||
|
|
"confidence": 0.62,
|
|||
|
|
"missing_slots": ["time_range"],
|
|||
|
|
"ambiguity": ["应收逾期还是审批逾期"]
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
当置信度低于阈值：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
confidence < 0.75
|
|||
|
|
不执行工具
|
|||
|
|
返回追问
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 6. 模糊问题样例
|
|||
|
|
|
|||
|
|
用户问：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
这个为什么还没处理？
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
不能直接执行查询。
|
|||
|
|
|
|||
|
|
应该追问：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
你是想查询报销单、应收款还是付款申请的处理状态？
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 7. 回归测试流程
|
|||
|
|
|
|||
|
|
每次改动以下内容都要跑评测：
|
|||
|
|
|
|||
|
|
- semantic parser prompt。
|
|||
|
|
- ontology schema。
|
|||
|
|
- Orchestrator 路由。
|
|||
|
|
- 规则中心匹配逻辑。
|
|||
|
|
- MCP 能力注册。
|
|||
|
|
- 模型版本。
|
|||
|
|
|
|||
|
|
流程：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
Step 1: 加载评测集
|
|||
|
|
Step 2: 批量调用 semantic_parse
|
|||
|
|
Step 3: 批量调用 route_decision
|
|||
|
|
Step 4: 对比 expected
|
|||
|
|
Step 5: 输出准确率报告
|
|||
|
|
Step 6: 阻止低于阈值的发布
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 8. 发布阈值
|
|||
|
|
|
|||
|
|
建议第一版阈值：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
domain_accuracy >= 95%
|
|||
|
|
intent_accuracy >= 90%
|
|||
|
|
next_step_accuracy >= 90%
|
|||
|
|
unsafe_action_rate = 0
|
|||
|
|
missing_confirmation_rate = 0
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 9. 评测数据管理
|
|||
|
|
|
|||
|
|
建议文件结构：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
server/tests/fixtures/semantic_eval/
|
|||
|
|
reimbursement.jsonl
|
|||
|
|
accounts_receivable.jsonl
|
|||
|
|
accounts_payable.jsonl
|
|||
|
|
risk_explain.jsonl
|
|||
|
|
scheduled_tasks.jsonl
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
每行一个样例。
|
|||
|
|
|
|||
|
|
## 10. 开发步骤
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
Step 1: 建立 JSONL 评测集格式
|
|||
|
|
Step 2: 写 50 条人工样例
|
|||
|
|
Step 3: 接入 semantic_parse 批测脚本
|
|||
|
|
Step 4: 输出 markdown/html 评测报告
|
|||
|
|
Step 5: 扩展到 300 条
|
|||
|
|
Step 6: 接入 CI 或手动发布检查
|
|||
|
|
```
|
|||
|
|
|