# 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 是否受影响