62 lines
2.6 KiB
Markdown
62 lines
2.6 KiB
Markdown
# Proposal: 置信度评分与用户反馈机制
|
||
|
||
## 问题
|
||
|
||
DiagnosisSession 已预留 `selfEvaluation`（JSON）和 `feedback`（VARCHAR 16）两个字段，但目前完全为空——Agent 完成对话后不计算置信度，也没有接收用户反馈的 API，无法支撑报告质量评估和 BadCase 追踪。
|
||
|
||
## 建议方案
|
||
|
||
### 置信度评分（双轨）
|
||
|
||
**主轨：LLM 自评**
|
||
- 在 ChatService 的 `executeChat` 流程结束后，追加一次轻量 LLM 调用（EvaluationService），
|
||
将 Agent 的最终答案 + 步骤摘要传给模型，要求输出 `{"confidence": 0-100, "reasoning": "..."}` JSON。
|
||
- 结果写入 `DiagnosisSession.selfEvaluation`。
|
||
|
||
**兜底轨：规则计算**
|
||
- 若 LLM 自评失败（超时/解析失败），用规则计算：
|
||
- 基础分 60
|
||
- 工具调用数 > 0 每次 +5（上限 +20）
|
||
- 步数 <= 3 额外 +10
|
||
- 状态为 FAILED 直接 0
|
||
- 兜底结果同样写入 `selfEvaluation`，并附 `"source": "rule"` 标记。
|
||
|
||
### 用户反馈 API
|
||
|
||
新增 `POST /api/feedback`，接收：
|
||
```json
|
||
{ "sessionId": "xxx", "feedback": "useful" | "not_useful" }
|
||
```
|
||
后端操作：
|
||
1. 写入 `DiagnosisSession.feedback`。
|
||
2. 若 `feedback = "not_useful"`，将 `status` 更新为 `BAD_CASE`（需要在 status 枚举扩展此值）。
|
||
3. 若 `feedback = "useful"`，写入一条 `CaseLibrary` 记录（从 session 提取 query/answer）。
|
||
|
||
## 范围
|
||
|
||
- 新建 `EvaluationService`（置信度计算）
|
||
- 新建 `FeedbackService`（反馈处理）
|
||
- 新增 `POST /api/feedback` 接口（在 ChatController 或新 FeedbackController）
|
||
- 改造 `ChatService.executeChat` 在 SUCCESS 后调用 EvaluationService
|
||
- `DiagnosisSession.status` 枚举扩展 `BAD_CASE` 值
|
||
- Flyway 迁移：`diagnosis_session.status` 列注释更新（不改类型，字段已存在）
|
||
- 无需新建数据库表
|
||
|
||
## 非目标
|
||
|
||
- 不实现 Verifier Agent 完整链路（只做轻量自评，不是多 Agent 编排）
|
||
- 不实现案例沉淀的复杂结构化字段（CaseLibrary 的 faultCategory/errorCode 等填 GENERAL/null）
|
||
- 不实现 BadCase 的自动分析或 Prompt 优化流程
|
||
|
||
## 关键约束（来自 devflow）
|
||
|
||
- JPA ddl-auto = validate，表结构变更必须走 Flyway 迁移，但本次无需加新列
|
||
- `DiagnosisSession.selfEvaluation` 已声明为 JSON 类型，直接用 String 写入
|
||
- `CaseLibrary.faultCategory` 是枚举，默认填 GENERAL
|
||
- `SourceType.AUTO` 表示系统自动生成
|
||
|
||
## 风险
|
||
|
||
- LLM 自评 prompt 质量影响分数可信度，需要在 reasoning 字段记录依据
|
||
- BAD_CASE status 与现有 PENDING/RUNNING/SUCCESS/FAILED 并存，需确认 UI 是否受影响
|