3.6 KiB
3.6 KiB
处方 AI：慢与报错的排障记录（2026-09-10）
只记录元数据与结论，不含患者资料、报告正文、附件地址或凭据。
现场测量
| 观察 | 数据 |
|---|---|
| 准备资料耗时 | 批次 1～4 均为 303～304 秒；其中资料组装约 3～4 秒，其余为转写等待窗口 |
| 触发等待的原因 | 诊单 1391 有 25 条已结束通话，transcription_status 为空、无会话号、0 分段；旧判断把"空状态"视为可能到达 |
| OpenAI 失败 | 批次 2/3/4 连续 UPSTREAM_TIMEOUT，每次恰好 90 秒 = prescription_ai.timeout |
| 千问失败 | 批次 2/3/4 均为 INVALID_REPORT_OUTPUT（60～64 秒），单次格式不符即整支失败 |
| 首份成功候选方 | 批次 5 千问 available_for_review（v3 提示词），9 味 |
| 该候选方为何仍无百分比 | 医生方 19 味无逐味单位（处方级 dosage_unit=g、dose_unit=剂、剂型浓缩水丸）；候选方剂型"中药配方颗粒"不在受支持剂型内、基准 per_day；9 味中 5 味药名无法唯一映射机构字典（机构为"生麦冬/生五味子/麸炒白术/生地骨皮/麸炒苍术"） |
| 机构数据分布 | dosage_unit：g 9389 张、ml 92 张、空 126 张；剂型：浓缩水丸 9507、饮片 92、汤剂 7、丸剂 1；药材字典单位：克 497/500 |
修复
- 只在通话进行中、转写 pending/running、或刚结束且在等待窗口内时才等待转写；旧通话保留为缺口。
- 后台分析单次请求超时独立配置，默认 240 秒（同步页面仍 90 秒），必须小于任务租约 600 秒。
- 每个阶段允许一次受控格式修复（重申结构、不放宽校验）；无效回答不入缓存；
INVALID_EVIDENCE_OUTPUT、INVALID_REPORT_OUTPUT改为可重试。 - 比较器读取医生处方级
dosage_unit与dose_unit=剂/付；快照新增"调配约定"（剂型/单位/基准）下发给两个模型；候选阶段下发机构药材名清单，要求逐字选用；剂型仅做写法归一，不做任何剂量换算。 - 提示词预算默认 24000 → 48000 字节，减少分片与压缩轮次。
- 界面未设置的时间戳显示"—"。
验证
- 后端离线测试 11 个全部通过（比较器 262 项、进度 38 项、策略 20 项、统计 64 项等）。
- 独立 MySQL（端口 13379）上 Queue 68 / Pipeline 80，旧结构 Queue 66 / Pipeline 75 通过；测试结束后已停止该实例。
- 桌面
test_issued_prescription_ai.py等相关测试通过，Ruff 通过。tests/test_busy_overlay.py::test_shell_construction_never_shows_orphan_business_controls在本次改动前后同样失败，属既有问题，未在本轮处理。 - 真实链路：批次 4 的 OpenAI 第 3 次尝试在新超时下已越过 90 秒继续执行（单次调用实测约 174 秒），不再固定在 90 秒失败。
追加（13:00 后）
- 首份可比结果：批次 6 千问 一致度 14.35%、药味重合 14.81%（医生 17 味 / AI 10 味 / 共同 2 味，0 个不可比问题）。
- OpenAI 消费者从 12:24 起持续
storage_or_configuration_error：MySQLwait_timeout=120秒 < 新的 240 秒请求超时，长调用期间连接被服务端关闭，之后所有查询失败且无法恢复。已在消费者进程打开断线重连、失败后主动关闭连接，并把失败输出改为"异常类@文件:行号 + SQLSTATE"。 - 截断假设被实测否定：千问可返回 13204 tokens 的完整 JSON；合成病例的候选阶段 9.3 秒通过，零修复。真实病例的失败改从来源编号引用入手，最终提示词新增
ALLOWED_EVIDENCE_IDS，并记录具体校验规则。