281 lines
33 KiB
Markdown
281 lines
33 KiB
Markdown
# 手工处方双模型分析：实施与部署
|
||
|
||
本地实现日期：2026-09-09。功能默认关闭；本次没有迁移线上数据库、启动线上消费者、调用真实模型或批量分析历史患者。
|
||
|
||
## 本地运行包更新（2026-09-10）
|
||
|
||
用户反馈本地启动后看不到功能。核验发现：项目“一键运行”优先使用 `app/dist/DoctorWorkstation/DoctorWorkstation.exe`，原 EXE 尚未包含 `doctor_workstation.ui.dialogs.issued_prescription_ai`；桌面快捷方式另指向 `C:/Program Files/ZYT/DoctorWorkstation/DoctorWorkstation.exe`，该安装版为 1.3.0，同样没有此模块。
|
||
|
||
已为处方列表增加独立可见的 AI 状态说明，区分服务未启用、暂不可用、缺少查看权限和空列表；仍按真实权限显示报告入口，未启用/不可用时不展示虚构分数。服务恢复后清除错误说明。相关 65 项桌面回归、Ruff 和 diff 检查通过。
|
||
|
||
已将项目“一键运行”使用的目录更新为包含本功能的 1.4.2 运行包，旧目录备份为 `app/dist/DoctorWorkstation-before-prescription-ai-20260910-091537`。新 EXE SHA-256：`d97625e84b3e418aef471e24cfd8830cd07dda85a7762757a5b323d84ce10300`。归档模块、Qt WebEngine/Multimedia、字体、OpenSSL 同源与两项隔离启动检查通过，一键运行入口验证通过。完整证据见 `app/artifacts/issued-prescription-ai/local-package-build-20260910.md` 和 `local-package-promotion-20260910.json`。
|
||
|
||
桌面安装版没有更新。使用项目 `app/一键运行_医生工作站.bat` 可打开新包；现有客户端偏好连接线上后端 `https://admin.zhenyangtang.com.cn/adminapi`，本地程序更新不会自动部署线上代码、执行数据库迁移或启用分析任务。本轮未执行这些线上变更。
|
||
|
||
## Linux 宝塔进程预部署记录（2026-09-09）
|
||
|
||
已通过 SSH 在用户指定的 Linux 宝塔服务器完成进程配置。服务器尚未同步本功能代码，因此仅启动 Supervisor 管理服务，三个消费者均为 `STOPPED / Not started`，配置均为 `autostart=false`。未同步业务代码、修改应用 `.env`、迁移数据库或执行分析任务。
|
||
|
||
- 实际项目目录：`/www/wwwroot/zyt/server`；站点运行目录为其 `public` 子目录。
|
||
- PHP CLI：`/www/server/php/82/bin/php`，现场版本 8.2.28；运行用户 `www`。
|
||
- 进程名称：`prescription-ai-prepare`、`prescription-ai-qwen`、`prescription-ai-openai`；各一个实例，命令使用 PHP 和 `think` 的绝对路径。
|
||
- 已补齐宝塔官方 Supervisor 管理界面，复用服务器已安装的 Supervisor 4.2.1，未升级宝塔 Python 依赖。
|
||
- 主配置：`/etc/supervisor/supervisord.conf`；进程配置：`/www/server/panel/plugin/supervisor/profile/prescription-ai-*.ini`。
|
||
- 日志：`/www/server/panel/plugin/supervisor/log/`，每个进程分别记录 stdout/stderr，每文件 10 MB、保留 5 个轮转备份。
|
||
- 服务：`/etc/systemd/system/supervisord.service`，管理服务已设开机启动；三个消费者仍不会自动启动。
|
||
- 已配置异常退出重启、TERM 停止及进程组清理。prepare 停止等待为 600 秒，模型消费者为 14,400 秒；当前 worker 只在任务外层响应退出，单任务包含多次模型调用，调整上游超时/调用预算后应重新核对等待时间。
|
||
|
||
现场验证通过：Supervisor 配置解析、systemd 单元校验、PHP CLI 必需扩展、`www` 用户的信号函数与 runtime 写权限；宝塔 `GetPorcessList` 返回三个 `STOPPED` 进程，系统进程表中无处方 AI 消费者。配置校验没有执行业务命令，不能代替上线后模型联调。
|
||
|
||
代码同步后，先按下方部署顺序完成数据库、密钥、启用时间、权限和模型配置检查，再启动消费者。确认上线后将三个配置的 `autostart` 改为 `true` 并重新加载 Supervisor，才能在服务器重启后自动恢复消费者。保留现有快照密钥；如本地已对同一数据库登记任务，必须使用登记时的相同密钥。
|
||
|
||
## 已接入的业务流程
|
||
|
||
- 手工新增处方、空白处方第一次编辑为手工、临床内容修改：与处方保存处于同一数据库事务的分析事件。
|
||
- 新客户端对同一新增请求复用 `request_key`；服务端验证请求内容，网络响应丢失后返回原处方 ID。旧客户端按处方版本去重。
|
||
- 基于诊单的患者 ID 绑定，空白处方编辑时补齐患者 ID；绑定不足显示明确状态。
|
||
- 独立的资料准备、千问、OpenAI 三个消费者；一次冻结资料，两模型独立执行与失败重试。
|
||
- 分批读取授权资料和附件，保存模型读取覆盖与缺口；等待本次视频转写最多 5 分钟，晚到资料通过扫描安排新版本。
|
||
- 处方临床版本变化、作废、删除后取消旧任务。结果不可覆盖，旧报告保留过期标识。
|
||
- 桌面已开处方列表显示模型状态及“药味与剂量一致度”；点击/右键可看报告、候选方案、逐味差异、资料缺口和历史。患者详情也可进入。
|
||
- 提供单模型失败重试、重新分析和人工复核意见；AI 结果不会自动写回正式处方、审核、订单或药房。
|
||
- 快照、模型中间进度、报告正文和复核意见加密存储。服务端返回报告前重新验证处方和每个来源的授权。
|
||
|
||
## 百分比的含义
|
||
|
||
对两张单位、剂量基准、剂型等可比较的处方，服务端依据本地药材身份映射计算：
|
||
|
||
`一致度 = 100 × 2 × Σ(共同药味 min(医生剂量,AI剂量)/max(医生剂量,AI剂量)) ÷ (医生药味数+AI药味数)`。
|
||
|
||
药味别名、炮制和主辅方需要明确；单位/每剂或每日基准不明、剂型不可比较、关键资料不足、候选方案未生成时显示“—”及原因，不记为 0%。0% 仅表示可比较但无相同项。煎服与疗程差异另外展示。
|
||
|
||
此指标反映处方一致程度，不能称为医生准确率。医生统计只接受有证据的独立基线；普通“已查看/未采纳/已复核”不是独立专家判定，不能计为专家合格率。
|
||
|
||
## 部署顺序
|
||
|
||
1. 备份数据库，使用现有迁移方式执行 `server/database/migrations/2026_09_09_prescription_ai_analysis.sql`。默认表前缀是 `zyt_`，其他前缀需一致替换。脚本可重复执行，新增表和权限不修改现有报告表。
|
||
2. 核实角色权限：`tcm.prescriptionAi/statuses`、`reports`、`detail`、`regenerate`、`retry`、`review`、`statistics`。迁移继承现有患者 AI 报告的读取/生成权限；既有角色未获得相应权限时，应由管理员按实际职责配置。
|
||
3. 各 Web 与消费者节点配置同一个至少 32 字符的随机 `PRESCRIPTION_ANALYSIS.ENCRYPTION_KEY`。不配置时单节点会在非公开 `server/runtime/prescription_ai_private/snapshot.key` 建立密钥。多节点必须显式配置并备份相同密钥；丢失密钥将无法解密历史报告，不得把密钥提交代码库。
|
||
4. 将 `PRESCRIPTION_ANALYSIS.START_AT` 设为实际启用时刻的 Unix 秒时间戳，用于有界补偿扫描。保留既有 `prescription_ai` 双模型供应商配置，核验两个端点的实际图片、文件和 JSON 输出能力。
|
||
5. 先在测试环境配置 `PRESCRIPTION_ANALYSIS.ENABLED=true`，分别运行一次三个命令，确认任务与报告正常。上线启用需完成同样的真实供应商验证。
|
||
|
||
ThinkPHP `.env` 示例（随机密钥自行配置，不使用示例文字作密钥）：
|
||
|
||
```ini
|
||
[PRESCRIPTION_ANALYSIS]
|
||
ENABLED = false
|
||
START_AT = 0
|
||
```
|
||
|
||
在 `server` 目录运行三个独立进程，并交给现有进程守护器管理：
|
||
|
||
```sh
|
||
php think prescription-ai:work --lane=prepare
|
||
php think prescription-ai:work --lane=qwen
|
||
php think prescription-ai:work --lane=openai
|
||
```
|
||
|
||
`--once` 只处理一轮，适合诊断或已有定时执行方式。只启动 prepare 不会调用模型。默认每模型并发 1，每次任务最多自动尝试 3 次、手动重新尝试 2 轮，每模型每日最多领取 200 次任务。一次模型任务可能包含多次分片调用；实际调用次数及供应商可用的 token 使用量保存在加密进度和结果中，不能把任务数当成 token 数或费用金额。
|
||
|
||
`prescription_ai.manual_analysis` 控制输入预算和每模型任务最大调用次数；`prescription_analysis` 控制等待、租约、并发、补偿范围与任务预算。长请求超时应小于任务租约。调整后需重启常驻消费者。
|
||
|
||
## 历史补生成与回退
|
||
|
||
历史记录不会一次全量运行。先明确日期范围和条数进行预览：
|
||
|
||
```sh
|
||
php think prescription-ai:backfill --from=2026-09-01 --to=2026-09-09 --limit=50
|
||
```
|
||
|
||
确认预览范围后同命令追加 `--apply` 才登记任务；用返回的 `last_id` 继续传入 `--after-id` 翻页。日期筛选使用处方 `update_time`，不是处方笺日期。命令本身不调用模型，消费者随后执行。既有同版本任务不会重复创建；已失败的单模型从报告窗口重试。
|
||
|
||
回退时先停止三个消费者，再关闭功能开关并重启 Web 服务；保留新增表和密钥，旧处方流程继续工作。再次启用后从既定起始时间补偿缺失事件。不要删除历史报告表或密钥来暂停任务。
|
||
|
||
## 当前数据与供应商能力限制
|
||
|
||
- 旧来源缺少可重建历史版本，当前批次不能获得独立基线资格；列表仍可展示具备比较条件的辅助一致度，医生统计有效样本可能为 0。后补资料不会被冒充为医生开方时已经掌握的证据。
|
||
- 远程附件 URL 尚不能证明字节不可变；系统会分批提交并保留该缺口，不标记完整覆盖。默认仅使用已配置存储域名内授权上传路径。
|
||
- 当前 OpenAI-compatible 路径支持图片；PDF/不支持的文件保留能力缺口，由模型基于实际已读证据评估候选方案。一般附件缺口本身不再一律禁止候选方；关键用药安全信息仍缺失时继续暂缓。Dify 严格文件路径不允许偷偷丢弃附件并声称完整成功。通用本地 PDF 页面渲染/OCR 和附件内容寻址存储尚未接入，不能把链接清单当成全文已读。
|
||
- 聊天归档缺少完整同步水位时显示缺口；未能证明患者关联和授权的记录不会凭患者 ID 扩大读取。
|
||
- 自 2026-09-10 起默认研究对照模式：缺少用药、过敏等关键事实不再抑制候选方案，改为在假设下开方并逐项标注缺口与复核点。空白仍不等于“无”；男性/女性实际编码以及明确否认值会保留。
|
||
- 源资料自动更新扫描默认覆盖最近 7 天的分析批次。更久的处方可手动重新分析；历史全量更新需明确范围与预算。
|
||
- 暂无已验证的独立专家评审数据，不显示虚构的“医生准确率”。AI 百分比排序/全库筛选与专家抽样评审工作流不在当前接口内。
|
||
|
||
以上为实际支持边界，不代表已完成线上模型联调。
|
||
|
||
## 本地验证
|
||
|
||
新增 PHP 独立测试覆盖比较公式、统计排除与版本分层、资料隔离、文件分批、JSON 契约、恢复与加密；数据库测试只使用本地临时 MySQL 实例，创建随机前缀测试库，结束后删除该测试库，绝不加载应用生产数据库配置。
|
||
|
||
```sh
|
||
php server/tests/PrescriptionAiPolicyTest.php
|
||
php server/tests/PrescriptionAiComparisonTest.php
|
||
php server/tests/PrescriptionAiStatisticsTest.php
|
||
php server/tests/PrescriptionAiContextTest.php
|
||
php server/tests/PrescriptionAiGeneratorTest.php
|
||
```
|
||
|
||
将 `ZYT_AI_TEST_MYSQL_PORT` 指向独立的本地空密码测试 MySQL 后运行：
|
||
|
||
```sh
|
||
php server/tests/PrescriptionAiQueueTest.php
|
||
php server/tests/PrescriptionAiPipelineTest.php
|
||
```
|
||
|
||
桌面无网络测试使用项目 Python 环境，主要入口：`app/tests/test_issued_prescription_ai.py`；截图位于 `app/artifacts/issued-prescription-ai/`。
|
||
|
||
本轮最终验证：17 个后端测试脚本通过，包括 54 项数据库队列/真实保存检查、63 项带模型边界桩的完整链路检查、252 项比较器检查、64 项统计检查和 20 项策略/加密检查（检查数有重复覆盖，不相加冒充独立病例数）。桌面五份相关测试文件全部通过；PHP 语法检查及 `git diff --check` 通过。真实供应商输出质量、图片/PDF能力和线上进程配置仍需部署环境联调。
|
||
|
||
## 2026-09-10 本地运行排障
|
||
|
||
“等待转写/资料”有固定 300 秒截止时间。本次实际观察到等待截止后约 3 秒进入双模型分析，准备进程正常。部署时需区分桌面 Debug 配置、本地 API 域名映射与线上 API，不能仅因线上 Supervisor 未启动就认定本地任务没有消费者。
|
||
|
||
本次修复了真实供应商调用中暴露的四类问题：
|
||
|
||
- 接受完整单个 JSON 代码围栏，对合法来源引用列表去重；仍拒绝夹杂解释文字、遗漏或未知来源、错误字段和未通过临床校验的候选方案。
|
||
- 最终压缩按完整提示词计算预算，包括全部来源覆盖、附件状态和资料缺口；固定说明本身已超限时明确失败，不丢弃缺口或扩大调用预算。
|
||
- 严格附件传输保留全部逻辑附件；分析器将相同 URL 的不同来源分到不同请求，避免上游模型合并后遗漏来源。普通聊天保留原去重行为。
|
||
- 严格解析失败后持久化清除该步骤的无效返回缓存，保留其他成功步骤、累计调用记录及原重试上限，避免重试反复复用错误结果。调用记录新增经过格式限制的错误码，不记录新明文正文或凭据。
|
||
|
||
离线回归覆盖 Generator、UpstreamContract、StreamContract 和 Policy；本地模型进程在确认空闲后重启，失败任务通过原权限与预算检查恢复。OpenAI 已实际生成一份报告，但该应用的附件请求返回 HTTP 400 / `invalid_param`，故保留附件缺口，不能声称图片已被该模型读取。
|
||
|
||
随后通过只读 `/parameters` 核实：千问应用的 `allowed_file_types` 包含 `image/document/audio/video`；OpenAI 应用只有 `custom`，虽列出图片扩展名，但没有 `image` 类型。这是需要在 Dify 应用侧核对的实际配置差异；当前请求拒绝不能靠把图片标记为已处理解决。Dify 的[官方文件校验实现](https://github.com/langgenius/dify/blob/main/api/factories/file_factory/validation.py)也分别检查文件类型、扩展名与传输方式，部署版本具体行为仍需在该环境确认。
|
||
|
||
本轮最终状态为 OpenAI 报告成功、千问附件结构校验失败。千问两次手动重试额度已耗尽，未重置额度或创建新批次绕过限制；错误缓存清理已生效。两条模型消费者均已加载最新修复并继续运行，prepare 保留原正常进程。继续排障需要 Dify 管理后台的附件及输出配置；本次未修改远程业务代码或线上开关。
|
||
|
||
## 2026-09-10 中文展示与资料不全时的候选方案
|
||
|
||
按用户追加要求，界面的状态、资料缺口、来源编号和统计排除原因提供中文说明，兼容旧报告中嵌入的技术代码。原始存储数据、来源绑定和统计含义不因显示翻译而改变；医学缩写与模型品牌保留原文。
|
||
|
||
候选方案采用 `manual-prescription-available-evidence-v2` 提示词策略：图片未读、部分转写未完成、历史版本和归档同步无法验证等覆盖限制，不再单独阻止模型根据已有临床证据提出候选方。缺口仍逐项展示，候选方案注明资料不完整和医生复核要求；药味、剂量、单位等具备可比条件时，正常进行药味与剂量一致度比较。
|
||
|
||
若附件确已送达但一组返回结构不合格，清除该组无效缓存，丢弃全部识别内容，并逐项标记“模型未能正确解析这组附件”，继续其他资料及报告。该组附件不能被最终报告引用为已读证据。附件送达数量不符、文字证据结构错误或最终报告校验失败仍严格报错；重试保留已耗调用量。
|
||
|
||
年龄、性别、过敏史、当前用药或适用人群妊娠哺乳等关键安全事实缺失，未知的关键风险条件，或模型判断现有证据不足以支持具体用药时，仍暂缓具体候选用药，不能为了分数编造药味剂量。这不是无条件自动开具正式处方。医生统计保持首次独立基线口径，辅助对照结果不冒充医生准确率。
|
||
|
||
旧报告保持原分析结论；重新分析产生新批次并使用新策略。恢复遇到旧提示词版本时不复用旧输出，但保留累计调用预算，不因升级重置成本限制。此次变更不执行历史全量重跑。
|
||
|
||
本次验证：72 项桌面相关测试、Generator 回归、252 项比较器检查、PHP 语法与差异格式检查通过。Windows 1.4.2 中文包通过冻结入口、媒体组件和中文标签验证，已切换至 `app/dist/DoctorWorkstation`，旧包保留在 `app/dist/DoctorWorkstation-before-chinese-20260910-100701`；切换记录位于 `app/artifacts/issued-prescription-ai/local-package-promotion-chinese-20260910.json`。本地两条模型消费者在空闲时重启并加载新策略，prepare 保持正常运行。未关闭当前 Debug 客户端；重启当前本地客户端后使用新版显示，旧分析需要通过“重新分析”生成新批次。本轮没有生成新的真实患者报告。
|
||
|
||
## 2026-09-10 处理进度
|
||
|
||
追加 `2026_09_10_prescription_ai_progress.sql` 迁移，给任务表增加小型公开进度摘要；已有密文缓存与历史报告不变。列表和双模型报告窗口显示当前阶段、本阶段组数、等待说明、尝试次数及耗时，完成状态以结果保存成功为准。旧库尚未迁移时继续运行原流程并返回缺少分段进度的提示；迁移后需在空闲时重启三个消费者。界面每 5 秒读取最新状态，等待重试时冻结上次执行耗时。
|
||
|
||
本地数据库迁移及消费者更新已完成；测试和限制详见 [进度验证记录](prescription-ai-progress-2026-09-10.md)。线上部署须同步本次代码、执行追加迁移并重启对应消费者，本轮未改动远程服务器。
|
||
|
||
## 2026-09-10 研究对照：必须开出候选方
|
||
|
||
按用户确认的医学研究用途，默认要求两个模型在看不到本次人工方的前提下各自开出候选处方，再由服务端比较。
|
||
|
||
- 新配置 `prescription_ai.manual_analysis.require_candidate`（默认 `true`）与 `candidate_insist_rounds`（默认 2）。设为 `false` 可恢复原“关键安全信息缺失即暂缓候选方”的策略。
|
||
- 环境变量：`prescription_ai.MANUAL_REQUIRE_CANDIDATE`、`prescription_ai.MANUAL_CANDIDATE_INSIST_ROUNDS`。
|
||
- 提示词版本升至 `manual-prescription-required-candidate-v3`。恢复中的旧任务不复用旧提示词的输出，但保留已耗调用预算；已保存的历史报告不变，需要新策略时用“重新分析”生成新批次。
|
||
- 模型连续拒绝开方时任务以 `CANDIDATE_WITHHELD_BY_MODEL` 失败并可重试，拒绝的回答不进缓存，界面不显示为完成。追问会额外消耗调用预算，长期拒绝的模型请核对上游应用的内容策略配置。
|
||
- 未变：候选方不写回正式处方、审核、订单或药房；一致度仍由服务端固定算法计算；医生统计的独立基线口径不变。
|
||
|
||
## 2026-09-10 排障：准备资料过久与模型直接报错
|
||
|
||
现场记录（处方 7556 / 诊单 1391）显示三个独立问题，均已在本地修复。
|
||
|
||
**1. 每个批次固定卡 300 秒。** 该诊单有 25 条通话记录，全部是已结束但从未转写的旧通话（`transcription_status` 为空、无会话号、无分段）。原判断把"空转写状态"一律视为"仍可能到达"，于是每次都等满整个转写窗口；实际资料组装只需 3～4 秒（实测批次 1～4 的准备耗时均为 303～304 秒）。现在只有三种情况才等待：通话仍在进行、转写任务为 pending/running、或通话刚结束且在等待窗口之内。其余旧通话照常作为 `TRANSCRIPT_NOT_VERIFIED_COMPLETE` 缺口展示，不再阻塞。
|
||
|
||
**2. OpenAI 每次都在 90 秒超时。** 后台分阶段分析原本复用同步页面的 `prescription_ai.timeout=90`，而最终汇总一次调用就超过该时长，三次尝试全部 `UPSTREAM_TIMEOUT`。新增 `prescription_ai.manual_analysis.request_timeout`（默认 240 秒，上限 300，环境变量 `prescription_ai.MANUAL_REQUEST_TIMEOUT`），只作用于后台分析；同步页面仍用原超时。该值必须明显小于任务租约 `lease_seconds`（默认 600 秒），任务每一步都会续租。
|
||
|
||
**3. 千问每次因格式校验失败整支报废。** 结构不符原本直接结束整个模型分支，一次格式抖动就要走完整轮重试。现按方案第 9.3 节实现"最多一次受控格式修复"：任一阶段（文字、附件、压缩、最终报告、追问）解析失败时，立即在同一步骤内追问一次，只重申结构要求，不放宽校验、不接受夹带解释文字、不改动来源编号。修复失败才报错，且 `INVALID_EVIDENCE_OUTPUT`、`INVALID_REPORT_OUTPUT` 改为可重试。两次无效回答都不进缓存，调用次数照常计入预算，进度中记录 `format_rejects` 阶段标记（不含正文）。
|
||
|
||
其他：界面上"资料截止"等未设置的时间戳（服务端返回 0）显示为"—"，不再显示 0 或 1970 年。
|
||
|
||
本地验证：13 个后端离线测试通过（含新增的转写等待、格式修复、拒绝不入缓存与调用计数用例），桌面测试通过。三个本地消费者已在空闲时重启加载本次修复。线上未做任何改动。
|
||
|
||
## 2026-09-10 让一致度真正能算出来
|
||
|
||
排障中用真实数据复算发现：即使模型正常出方，百分比仍然恒为"—"。原因有三，都在本地修好了。
|
||
|
||
- **医生方没有逐味单位。** 工作站把用量单位存在处方级 `dosage_unit`（用量单位，实测 9389 张为 `g`），剂量基准由 `dose_unit=剂` 表达，逐味行只有药名、剂量、主辅方和药材 ID。比较器原来只在剂型为"饮片"时才补 `g/每剂`，而本机构 9507 张处方是"浓缩水丸"，于是每一味都判为"剂量单位缺失"。现在改为读取医生自己填写的 `dosage_unit`，并在 `dose_unit` 为剂/付时确定每剂基准；两者都没有时仍然不可比，不猜单位。所有套用都逐行记录在 `defaults` 中。
|
||
- **两边剂型和基准对不上。** 快照中新增"调配约定"（剂型、每味用量单位、每剂/每日基准），来自处方的调配字段，不含任何药味或剂量，交给两个模型，要求候选方按同一剂型、同一单位、按饮片原药材克数/每剂表达。比较器另外只做剂型写法归一（中药配方颗粒→颗粒等），不做任何剂量或提取比换算。
|
||
- **模型写的药名不在机构药材字典里。** 实测千问给出的 9 味中有 5 味无法唯一映射：机构字典里是"生麦冬""生五味子""麸炒白术""生地骨皮""麸炒苍术"，模型写的是"麦冬""五味子""炒白术""地骨皮""苍术"。按方案要求不能把生品与炮制品自动判为同一味，因此改为把机构药材名清单（仅药名，无库存、价格或患者信息）随候选阶段一起下发，要求逐字选用清单内名称；清单超过提示词预算四分之一时整体不下发，不做截断。
|
||
|
||
提示词版本升至 `manual-prescription-required-candidate-v4`。旧报告保持原结论，需要新口径请用"重新分析"。本轮新增 8 项比较器检查和 2 项候选阶段检查，后端 11 个离线测试与桌面相关测试全部通过。
|
||
|
||
## 2026-09-10 消费者被数据库断线卡死
|
||
|
||
把后台单次请求超时提到 240 秒后，OpenAI 那条消费者从领到任务起就再也没有恢复：日志连续输出 `storage_or_configuration_error`，任务只能等租约到期被判 `LEASE_EXPIRED`。
|
||
|
||
原因：本机 MySQL 的 `wait_timeout` 与 `interactive_timeout` 都是 **120 秒**，而一次模型调用期间数据库连接是空闲的。超时 90 秒时连接刚好活得下来，提到 240 秒后连接被服务端关闭，之后每一次查询都抛 `PDOException`，连 `fail()` 都写不进去，消费者就永久空转。
|
||
|
||
修复（只作用于消费者进程，不改 Web 配置）：
|
||
|
||
- 命令启动时对默认数据库连接打开 `break_reconnect`，断线自动重连。
|
||
- 每轮异常后主动关闭可能已失效的连接，下一轮重新建立。
|
||
- 失败输出改为"异常类名@文件:行号 + SQLSTATE"，不打印异常消息本身（消息可能带 SQL 值或病历文本）。原来那句 `storage_or_configuration_error` 查不出任何信息。
|
||
|
||
部署注意：数据库的 `wait_timeout` 应大于 `prescription_ai.manual_analysis.request_timeout`，两者与任务租约 `lease_seconds` 的关系是 请求超时 < wait_timeout 且 请求超时 << 租约。新增 `server/tests/PrescriptionAiWorkerResilienceTest.php` 固定这些约束。
|
||
|
||
## 2026-09-10 千问格式失败：不是输出被截断
|
||
|
||
先前根据"每次 completion 都在 4600～5700 tokens"怀疑上游最大输出长度截断。用合成数据实测否定了这一点：同一个千问应用被要求输出 200 条数组时返回了 13204 tokens 的**完整合法 JSON**（`probe_output_limit.php`）。再用合成病例跑完整候选阶段（`probe_final_schema.php`），千问 9.3 秒返回合法 v4 报告与 6 味候选方，零次格式修复。
|
||
|
||
因此失败来自真实病例的内容，而不是长度上限。最可能的是来源编号引用：真实病例有几十个来源编号和附件编号，模型引用了未读到或不存在的编号，整份报告即被拒。为此在最终提示词中显式给出 `ALLOWED_EVIDENCE_IDS`（本分支已读来源 + 实际解析成功的附件），并要求引用只能逐字取自该清单——不放宽校验，只消除歧义。未读成功的附件编号不会出现在清单里。
|
||
|
||
同时校验失败现在记录具体规则（`json_syntax`、`top_level`、`report_lists`、`candidate_herbs` 等）与返回内容长度，修复追问会附上该规则对应的中文提示。下一次真实失败即可直接读出原因，不再靠猜。
|
||
|
||
两个探针脚本只使用合成数据，不读取任何患者记录。
|
||
|
||
## 2026-09-10 首批真实对照结果与两处计分缺陷
|
||
|
||
数据库断线修复后，OpenAI 连续三次成功（批次 6、7、8），千问在批次 6 成功，四份结果全部 `comparable`、零不可比问题。也就是说"AI 独立开方 → 程序比较 → 列表出百分比"这条链路在真实数据上跑通了。
|
||
|
||
用真实结果逐味核对，发现两处会压低分数的缺陷：
|
||
|
||
- **炮制标签把同一味药拆成两项。** 机构药材字典把炮制写在药名里（醋五味子、麸炒白术、生麦冬），字典本身没有 processing 字段。模型按接口要求填了 `processing:"醋制"`，比较器就把 `[19,"","主方"]` 和 `[19,"醋制","主方"]` 当成两味不同的药。现在规则收窄为：**只有当处方写的炮制标签的每个字都已出现在药名中时**，才视为对药名的重复描述，不参与身份键（仍作为"炮制标注差异"展示）；药名没有承载的炮制（如"黄芪"+"蜜炙"）依旧是不同药项。字典自己声明了 processing 时行为不变。比较算法版本升至 `prescription-soft-dice-v1.1.0`。
|
||
- **主辅方语义不一致。** 本系统的"辅方"指与主方分开调配的另一张处方，医生用它装另包的煅龙骨、煅牡蛎等；模型把它理解成君臣佐使里的佐使药，于是茯苓、干石斛被标成"辅方"，和医生主方里的同一味药匹配不上。已在提示词中明确定义，并要求除非确有单独的辅助处方，所有药味一律填"主方"。
|
||
|
||
修正身份键后，批次 6 千问由 14.35% 升到 21.76%（共同药味 2→3）。主辅方定义要新批次才生效，历史结果保持原值不改写。
|
||
|
||
真实分数目前普遍偏低（0%～22%）：医生方 16～19 味，模型方 9～11 味，共同 0～3 味。这既有临床思路差异，也因为模型现在只能读到部分证据（附件仍读不到、聊天与转写有缺口）。这个数字是本指标的如实测量，不代表医生或模型谁对谁错。
|
||
|
||
## 2026-09-10 千问失败的真实原因与药名不在字典的处理
|
||
|
||
用只读探针把处方 9575 的冻结快照按当前代码重跑（不写任何数据），拿到了此前只能猜的答案：
|
||
|
||
- `final` 阶段被拒的规则是 **`candidate_fields`**——候选方对象的键或类型不合规（多出字段、`times_per_day`/`usage_days` 写成字符串、`evidence_references` 为空等），不是被截断，也不是来源编号问题。一次受控格式修复即通过。
|
||
- `files` 阶段被拒的规则是 `files_shape`——返回的附件条数或编号与清单不一致，同样一次修复即通过。
|
||
- 修复通过后仍然 `not_comparable`，原因是 `unknown_herb_name`：模型 12 味里有 1 味不在机构药材字典中（写"生山楂"，字典没有；另一例写"泽泻"，字典里是"生泽泻/麸泽泻"）。按方案不能自动替换或剔除，一味不认识整张方就不可比。
|
||
|
||
据此新增两项：
|
||
|
||
1. **药名回问。** 候选方生成后，服务端逐味核对机构药材名清单；有不在清单中的药名，就把这些药名回给模型，要求改用清单内逐字一致的名称，或在临床上确无合适药材时删除该味并说明，其余药味与剂量保持原判断。默认最多回问 2 次，服务端绝不代替模型换药。仍未纠正时，把这些药名写进候选方的风险提示，交给医生核对，不隐藏也不硬算分数。
|
||
2. **提示词按实际失败点收紧。** 候选方键集必须完全一致、数值字段必须是 JSON 数字、引用不得为空数组；附件阶段数组长度与编号必须和清单完全一致。
|
||
|
||
处方 9575 的完整重跑（生成 + 比较，只读）结果：`comparable`，9 次调用，其中 1 次附件格式修复、1 次候选字段修复、2 次药名回问，最终药味与剂量一致度 5.13%、药味重合 7.69%，零不可比问题。
|
||
|
||
|
||
## 2026-09-10 附件能力已放开与吞吐调整
|
||
|
||
只读核对两个应用的 `/parameters`（不提交任何患者数据）：
|
||
|
||
| 应用 | allowed_file_types | number_limits |
|
||
| --- | --- | --- |
|
||
| 千问 | image / document / audio / video | 3 |
|
||
| OpenAI | document / image / audio / video | 10 |
|
||
|
||
也就是说 OpenAI 应用先前"只有 custom、不含 image"的限制已经不在了，两个应用现在都接受图片。据此调整：
|
||
|
||
- **每个模型按自己的上限分批附件。** 新增 `prescription_ai.models.<模型>.max_files`（千问 3、OpenAI 10，环境变量 `prescription_ai.QWEN_MAX_FILES`、`prescription_ai.OPENAI_MAX_FILES`），全局 `max_files` 作为兜底。22 个附件在 OpenAI 侧由 8 次请求降到 3 次，直接缩短一份报告的时间。上限必须与应用配置一致：超限时 Dify 会用 400 invalid_param 拒绝整单。
|
||
- **每个模型允许 2 个任务并行**（`prescription_analysis.max_parallel_per_model` 1 → 2）。该值只有在同一通道真的运行了这么多消费者进程时才生效，因此本地按 `prepare×1、qwen×2、openai×2` 启动。此前列表里出现"已用时 1 小时"多半是排队等待，不是单份报告真的跑了一小时。
|
||
|
||
线上如需同样吞吐，需在进程守护器中为每个模型通道配置两个实例，并确认上游应用与账号的并发额度。
|
||
|
||
## 2026-09-10 报告窗口重新设计
|
||
|
||
原窗口把免责声明、批次信息、四段式流程、批次进度、两套模型面板（各自四个页签、复核下拉、意见框、两个按钮）纵向堆在一起，字号权重相同，医生打开后没有落点。重排为六层，信息一条没删，只是各归其位：
|
||
|
||
1. **标题卡**：处方/诊单/版本一行加粗，右侧是版本有效性、对照类型的状态药丸，再右是历史批次选择与刷新/重新分析。第二行小字放状态、失败原因、资料截止与批次建立时间。
|
||
2. **状态行**：读取提示与错误信息。
|
||
3. **流程条**：四阶段流程只在批次仍在处理或属于历史批次时显示，完成后不再占位。批次级进度行在两个模型各自报告阶段时隐藏，避免重复。
|
||
4. **两张结果卡（视觉重点）**：模型名 + 状态药丸 + **大号一致度数字** + "药味与剂量一致度"说明，下面是覆盖情况与原因、当前阶段、进度条与耗时。数字用中性墨色，不用红绿——高低不是评分。没有可比结果时显示灰色"—"。
|
||
5. **共用页签**：综合分析 / 候选用药 / 逐味对照 / 来源与缺口 由八个页签合并为四个，页内左右分栏同时显示两个模型的同一节，真正可以横向对照。
|
||
6. **复核条**：两个模型的复核状态、意见、保存与重试压缩到一行，原来纵向占用的约 200px 让给报告正文。免责声明降为脚注。
|
||
|
||
改动只在展示层：接口、轮询、权限、进度语义和落库数据都没变；`model_views` 的既有键全部保留，新增 `score`、`status_chip`、`card`、`model_label`。97 项桌面回归与 Ruff 通过，示意图见 `app/artifacts/issued-prescription-ai/redesign-running-20260910.png` 与 `redesign-finished-20260910.png`（合成数据，无网络）。
|