98 lines
10 KiB
Markdown
98 lines
10 KiB
Markdown
# 时间认可、渐进澄清与提示词精简
|
||
|
||
> 后续用户复核：下文历史实测的第1、2个数量失败回复被用户接受，现允许用户主动质疑记录时简短核对一次；第3个采用指定选择式问句。最新边界和验证追加在文末，历史48/51统计不追溯改写。
|
||
|
||
## 反馈与诊断
|
||
|
||
用户反馈：助手独立复述时间后，用户连续回答“可以”，助手仍重复同一确认句，直到用户换成“对的”才继续。原提示词要求明确认可，但示例只举“对、是的、没错”，又要求等待确认期间原样重复完整固定句。这容易把本来有效的口语认可排除在外，形成循环。运行时没有按“可以”强制拒绝确认的业务代码，修复落在模型语义判断和提示词冲突上。
|
||
|
||
本轮按prompt-debugging先识别冲突，结合prompt-engineer做定向修复和知识概念合并。用户追加要求：已有模糊回答不要反复原句追问，要自然承接、渐进引导，并精简重复指令。
|
||
|
||
## 统一概念
|
||
|
||
1. **证据合并**：本轮、用户历史及form逐字段合并，最新明确更正优先；false/0有效，未知不等于否定。助手误问不抹去已有事实。
|
||
2. **确认按语义**：对当前具体时间的无保留认可有效，不依赖固定词白名单。无否定、更正、犹豫或其他指向时，“可以、行、好的、没问题”等与“对”同样有效；“嗯对”不同于含义不清的单独“嗯”。
|
||
3. **时间三态**：时间缺失需采集；已有候选未获认可需确认或解决疑点；已确认且无新更正不再提问。未确认不等于候选值丢失。
|
||
4. **待解决疑点**：持续处理同一个业务疑点，但不重复原句。先承接已知事实，再用对象、范围、选择或可观察情况降低回答难度；仍无法回答时问其能确定哪部分，必要时提供人工协助选择，不代替用户猜答案。
|
||
5. **固定与自然表达分工**：状态协议、独立时间确认和分流出口保留规定；普通采集、情绪承接与模糊回答澄清可自然表达。有效认可就推进，已表达具体疑点就先澄清，不机械复述。
|
||
|
||
通用描述已写入采集提示词：
|
||
|
||
> 先理解用户已经说清什么，再处理影响下一步的最小疑点。有效短答直接推进；真正含糊时，沿用“待解决的疑点”，不沿用原句。保留已知事实，用不同角度降低回答难度：把开放问题缩小到对象、范围、选择或可观察情况；仍说不清时问其能确定哪部分，必要时给继续核对/人工协助选择，不代替用户猜答案。
|
||
|
||
## 冲突处理与保留边界
|
||
|
||
- 删除“未知就重复本问题”的表达，改为针对参与关系澄清；不把“换一句礼貌词再问”当作推进。
|
||
- 合并表单、历史、数量保持、短答与抱怨承接等重复证据规则，删除重复自检和重复示例；保留每轮决策及关键规则的优先级。
|
||
- 原时间固定句仅用于首次/新值确认或尚无有效时间答案的情况；普通不确定表达先解释疑点，不据此放弃独立时间确认。
|
||
- “可以拍照”是对拍摄的许可，不自动确认时间；只补现场信息仍保留原时间候选并确认，不能重新开放采集。
|
||
- “可以，不过不是这个时间”按完整更正处理；“可以吧，但不确定”仍未知。已确认时间只有用户更正、否定或明确说不确定才失效；助手错误重复不使其失效。
|
||
- 人伤疑点未解仍优先澄清，不跳去其他采集；明确人伤或至少3辆机动车仍立即转人工。单方数量、有效表单复用、非机动车分支、拍照可执行性及系统无回复/拒绝计数规则保留。
|
||
- 历史相对时间无可靠基准的旧边界按用户此前要求暂缓；本轮没有改动运行时或该检查的断言。
|
||
|
||
## 评估
|
||
|
||
模型为配置中的deepseek-v4.1-flash，temperature=0，reasoning_effort=none。全部Python在Conda py3.11中运行。每个最终API案例使用memory存储和独立会话；提示词通过固定快照加载，避免评估过程中修改文件影响统计。
|
||
|
||
新增两种客户端模式的时间认可API案例：提供已知事故经过、无伤、无非机动车/行人和具体时间；用户回答“可以”后只询问现场，回答在场后直接单车拍照，严禁再确认同一时间。原52份案例全部保留且不修改断言。
|
||
|
||
补充10项时间语义检查：五种认可说法、信息齐全直接拍照、历史已有认可但助手误重复后的恢复、不确定态度、含更正的认可、只许可拍照。新增3项渐进澄清检查：非机动车参与不明、时间记不清、人伤看不清时改变问法且保留已知数量。其余38项原语义检查继续保留。
|
||
|
||
修改前时间专项8/10，失败为“行、好的”仍重复时间确认；此轮并未稳定复现所有“可以”错误，因此用同类认可和历史误重复场景共同验证。时间定向修复版专项10/10、API54/54。
|
||
|
||
曾尝试更大幅度重写压缩，但出现数量重复追问、候选时间丢失及既有案例回退，未采用。最终以通过的定向版为基础，合并重复概念、移除重复示例，保留关键规则的位置与优先级，并增加渐进澄清。最终采集正文由10413字符/221行变为9973字符/209行；包含新增认可与引导规则后，净减少4.2%。压缩与新增规则分别核对，既有边界不能为了篇幅缩短而删除；字符变化不代表token成本实测。
|
||
|
||
## 复现与产物
|
||
|
||
```bash
|
||
conda run -n py3.11 python -m evals.prompt_compare --group time_confirmation --output-dir evals/results/time-ack/reproduce-time
|
||
conda run -n py3.11 python -m evals.prompt_compare --suite full --output-dir evals/results/time-ack/reproduce-all
|
||
conda run -n py3.11 python -m evals.prompt_probes --runtime --case time_ack_ --case clarify_ --output evals/results/time-ack/reproduce-focused.json
|
||
conda run -n py3.11 python -m evals.prompt_probes --runtime --exclude-case missing_historical_time_anchor --output evals/results/time-ack/reproduce-probes.json
|
||
```
|
||
|
||
API最终结果在 `evals/results/customer-feedback/time-ack-release-all/`，语义检查在 `time-ack-release-probes.json`，时间基线在 `time-ack-baseline.json`；全部沿用Git忽略规则。提示词固定快照在 `evals/results/time-ack/release-prompts/`。最终统计见下节。
|
||
|
||
## 最终结果与实际限制
|
||
|
||
| 检查 | 结果 |
|
||
| --- | --- |
|
||
| API端到端案例 | 54/54 |
|
||
| 本轮时间认可与渐进澄清专项 | 13/13 |
|
||
| 全部语义检查 | 48/51 |
|
||
| 此轮agent及评估器/筛选离线测试 | 176通过 |
|
||
| 最终提示词同步与执行器/筛选测试 | 43通过 |
|
||
| 暂缓的历史时间基准检查 | 1项排除，不计通过 |
|
||
|
||
原52份API案例输入和断言SHA-256全部不变，新增2份时间认可案例。direct在“可以”后回复“好的，请问您现在还在事故现场吗？”，browser_addon回复“请问您现在还在事故现场吗？”；补充在场后两种模式都直接2000，未重复时间确认。
|
||
|
||
全部语义检查中的3项失败均保留：
|
||
|
||
- `feedback_single_motor_complaint`：历史完整单车事实及时间认可后，用户指出已答过，模型仍询问具体数量，应直接2000。
|
||
- `feedback_known_count_in_form`：表单已有数量1及其他必要信息，模型仍要求确认数量，应直接2000。
|
||
- `feedback_no_evidence_of_previous_answer`：确无数量证据时仍需澄清，但模型出现“没有看到您之前的回答”的机械前言。
|
||
|
||
因此本轮证据支持时间认可修复和新增渐进澄清场景，不支持宣称所有重复追问或所有“已回答过”话术都已稳定解决。大量重写压缩时出现过更多回退，未采用；最终采用有限精简版本，不删除失败、不将混合版本或未完成运行记为通过。
|
||
|
||
为匹配用户要求的自然表达，三项语义断言接受等价措辞：澄清人伤可以问救护车/送医，非机动车参与关系可以问自行车/电动自行车/行人，参与范围可以指向旁边的车。未知字段、正确状态及不能跳过疑点的断言不变。原API断言全部保留。
|
||
|
||
汇总：`evals/results/time-ack/summary.json`；逐例审核页：`evals/results/time-ack/review.html`，使用skill-creator自带审核页生成器制作。两份提示词已同步本仓库workflow/20261027；外部FastGPT部署未操作。`git diff --check`通过。模型结果有波动，本次通过记录不代替生产监测。
|
||
|
||
## 用户复核后的数量核对边界
|
||
|
||
用户接受了上述第1、2类回复：用户主动说“已经回答过了”并质疑数量记录时，允许1002简短核对一次，或信息齐全直接分流。核对不是清空历史/表单重新采集，既有事实和时间确认保留；用户有效认可数量后立即推进，不形成循环。该例外仅适用于主动质疑记录，正常采集仍优先复用已有字段，三车或人伤优先中断仍先执行。
|
||
|
||
第3类在表单及用户历史都没有数量/参与线索时，按用户指定使用完整回复：
|
||
|
||
```text
|
||
<state>1002</state>这项再帮我核对一下：这次是您这一辆汽车，还是还有其他汽车参与？
|
||
```
|
||
|
||
不加“没看到、没收到、没查到”等前言；问句中的“一辆”不是已确认事实，未获有效答案不能填入数量。
|
||
|
||
提示词相关全局“不重复”条款已明确这一例外，末尾示例及本仓库工作流JSON同步。语义评估对同类已知数量质疑接受1002核对或对应2000/2010分流，不再把用户接受的行为判为失败；原历史统计保留，不事后改成通过。新增两项检查验证核对后回答“对，数量没错”时，分别进入单/双车拍照。
|
||
|
||
使用deepseek-v4.1-flash、temperature=0实测：6项数量核对专项6/6，客户反馈/复杂事故/时间确认三个分组的API案例10/10，最终相关离线测试43通过，git diff检查通过。无证据场景实测与上述指定回复逐字一致。首轮曾加“没有查到”的前言，保留为失败；明确只输出整条回复后通过。没有将首轮失败或此前其他版本统计合并为本轮结果。
|
||
|
||
原始专项：`evals/results/customer-feedback/record-review-final-focused.json`；分组回归：`record-review-regression/`；提示词固定快照：`evals/results/record-review/final-prompts/`。此轮未重跑全部案例或所有语义检查，不声称旧48/51已变为全量通过。
|