# evidence.md — confidence-feedback

## 代码证据

### agent_step.thought 不可作为案例内容

- 文件：`AgentLoggingHook.java:135`
- 证据：`thought` 在写入前截断为 2000 字符，`modelOutput` 截断为 500 字符
- 结论：两者均不是返回给用户的完整答案，案例质量低

### ChatService 已有完整答案未持久化

- 文件：`ChatService.java:269`（executeChat）、`ChatService.java:353`（executeChatComplex）
- 证据：`String answer = response.getText()` 只用于返回前端，未写入任何持久化存储
- 结论：加 `DiagnosisSession.answer` 字段是最干净的方案

### ToolInvocationRepository 已有 findBySessionId

- 文件：`ToolInvocationRepository.java`
- 证据：`findBySessionId(String sessionId)` 已实现，返回 `List<ToolInvocation>`
- 结论：规则引擎可直接读取 tool_invocation 事实，无需新增查询方法

### tool_invocation 写入时序安全

- 文件：`LookupKnowledgeTool.java:144`
- 证据：`saveToolInvocation` 在工具执行时同步调用，早于 ChatService 的 SUCCESS 分支
- 结论：@Async evaluate 触发时 tool_invocation 数据已在库，无竞态

### 项目原无 @EnableAsync

- 证据：`grep -rn "EnableAsync"` 无任何命中（apply 前）
- 结论：需要新建 `AsyncConfig.java`

### CaseLibraryRepository.findByDiagnosisId 已有幂等检查支持

- 文件：`CaseLibraryRepository.java`
- 证据：`findByDiagnosisId(String diagnosisId)` 已实现
- 结论：useful 重复提交时可用此方法检查，不重复插入

## 设计推导

### evidence_score vs confidence 命名

- 基于工具调用的分数衡量的是证据收集充分度，不是答案准确性
- "confidence" 容易误解，改为 "evidence_score" 更准确
- LLM 自评才适合叫 confidence，但当前未实现

### BAD_CASE 不应混入 status

- status 有明确执行状态语义（RUNNING/SUCCESS/FAILED）
- 一个 SUCCESS 的 session 被标为 BAD_CASE 后，按 status 做的统计会失真
- feedback 字段本身就够，`WHERE feedback = 'not_useful'` 即可查 BadCase