医疗问诊系统的 AI 增强实战：从症状描述到智能分诊的全链路 LLM 落地

医疗问诊系统的 AI 增强实战从症状描述到智能分诊的全链路 LLM 落地一、症状描述与科室匹配的两难困境在线问诊的入口瓶颈在线问诊平台面临一个核心矛盾患者输入的描述质量参差不齐而系统需要在极短时间内完成科室推荐。传统的做法依赖关键词匹配和规则引擎——头痛匹配神经内科胃痛匹配消化内科——但这种粗粒度映射在复杂症状面前几乎无解。一个同时描述头晕、心悸、手麻的患者究竟应该去心内科、神经内科还是内分泌科基于 LLM 的智能分诊方案试图解决三个层次的痛点。第一层是意图理解从非结构化的自然语言描述中提取关键医学实体。第二层是科室映射在 ICD-10 编码体系和科室知识图谱的约束下做多标签分类。第三层是紧急度分级识别急重症信号触发预警通道。这三层逻辑缺一不可且每一步都对延迟和准确率有严格要求。从工程角度看这不是一个调 API 就搞定的任务。LLM 在医疗场景下存在幻觉风险需要后处理校验链高并发问诊场景需要流式响应与兜底策略多轮对话的上下文管理需要维持超过 20 轮的 chat history 而不丢失关键信息。本文基于一个日活百万的在线问诊系统的改造实践拆解从症状描述到初步分诊的完整工程方案。二、LLM 驱动的分诊引擎双通道架构与意图路由机制整个系统的核心架构采用双通道 意图路由模式如下图所示双通道的设计出发点是安全性优先于智能化。急重症信号如胸痛伴呼吸困难、突发剧烈头痛、大量出血不容任何 LLM 推理的延迟和不确定性直接走规则引擎进入急诊通道。规则引擎维护了一份由医学团队审核的关键词-症状对照表命中即触发延迟控制在 5ms 以内。普通问诊通道则走 LLM 推理但在输入和输出两端都设置了严格的约束。输入端通过 Prompt 编排器注入科室列表、排除标准、输出格式约束输出端经过结构化解析后再由医学实体校验层做一次安全过滤——将 LLM 输出的科室推荐与知识图谱做交集校验剔除不在有效科室范围内的幻觉推荐。如果校验后结果为空则降级到兜底规则引擎。在意图路由环节我们还引入了一个轻量级 BERT 分类器作为急重症信号的二分类模型。它的作用不是取代规则引擎而是作为补漏网——规则引擎覆盖约 200 种已知急重症模式而 BERT 分类器可以在规则漏掉的边缘 case 上给出二次判断。两者取或逻辑任一命中即走紧急通道。三、分诊推理与结果校验的核心实现以下是分诊服务中 LLM 推理与后处理的核心代码实现Service public class TriageInferenceService { private final LlmClient llmClient; private final RuleEngine ruleEngine; private final MedicalEntityValidator entityValidator; private final EmergencyClassifier emergencyClassifier; /** * 构建 Prompt 模板核心设计思路 * 1. 注入动态科室列表约束 LLM 输出范围 * 2. 强制 JSON 结构化输出减少解析歧义 * 3. 加入不确定时返回空的安全兜底指令 */ private String buildPrompt(String symptom, ListString departments) { return 你是一位经验丰富的全科分诊助手。根据患者的症状描述推荐最可能的就诊科室。 ## 可用科室列表严格限制在此范围 %s ## 输出格式必须严格 JSON { primary: 首选科室名称, secondary: [备选科室1, 备选科室2], confidence: 0.85, reasoning: 推荐理由简述, urgency_level: normal|urgent|emergency } ## 安全规则 - 如果症状信息不足以做出判断primary 字段返回 建议补充更多信息 - 不要给出任何明确的诊断仅做科室推荐 - urgency_level 仅当存在急重症信号时设为 urgent 或 emergency ## 患者描述 %s .formatted(String.join(\n, departments), symptom); } /** * 执行分诊推理包含完整的安全保护链 */ public TriageResult triage(String symptom, String userId) { // Step 1: 急重症规则引擎前置检测延迟 5ms if (ruleEngine.matchEmergency(symptom)) { return TriageResult.emergency(急诊科, 规则引擎命中急重症模式); } // Step 2: BERT 分类器二次判断延迟约 20ms EmergencyResult er emergencyClassifier.predict(symptom); if (er.isEmergency()) { return TriageResult.emergency(急诊科, BERT 分类器检测到潜在的急重症信号置信度: er.getConfidence()); } try { // Step 3: LLM 推理核心路径 ListString deptList loadDepartmentList(); String prompt buildPrompt(symptom, deptList); LlmResponse llmResp llmClient.chat(prompt, LlmConfig.builder() .temperature(0.1) // 低温保证稳定输出 .maxTokens(512) .responseFormat(json) // 强制 JSON 输出 .timeoutMillis(15000) // 15s 超时保护 .build()); // Step 4: 结构化解析 TriageResult result parseJsonResponse(llmResp.getContent()); if (result null) { log.warn(LLM 输出解析失败降级至规则引擎, userId{}, userId); return ruleEngine.fallbackTriage(symptom); } // Step 5: 医学实体校验幻觉拦截 boolean isValid entityValidator.validate(result.getPrimary(), deptList); if (!isValid) { log.warn(LLM 推荐科室不在有效列表降级, recommended{}, result.getPrimary()); return ruleEngine.fallbackTriage(symptom); } return result; } catch (TimeoutException e) { log.error(LLM 推理超时降级至规则引擎, userId{}, userId, e); return ruleEngine.fallbackTriage(symptom); } catch (RateLimitExceededException e) { log.error(LLM 请求限流用户进入排队, userId{}, userId, e); return TriageResult.queued(系统繁忙请稍候我们将尽快为您分诊); } catch (Exception e) { log.error(LLM 推理未知异常降级至规则引擎, userId{}, userId, e); return ruleEngine.fallbackTriage(symptom); } } }代码中有几个值得注意的设计点。第一温度参数设为 0.1 而非默认值因为分诊场景对输出稳定性要求极高。第二每一层异常都有独立的降级路径不存在单点故障导致全链路不可用的风险。第三超时和限流是分开处理的——超时意味着服务不可达限流意味着需要排队而非直接降级这种差异化处理对用户体验至关重要。四、幻觉风险与延迟权衡该方案不适用哪些场景这个方案在如下场景下存在明显局限。首先是科室粒度问题大型三甲医院的科室体系远超通用列表的覆盖范围一些细分的亚专科如手外科、疼痛科LLM 很难精准命中。这要求系统根据接入医院的实际科室映射表做动态 Prompt 注入维护成本会随医院数量线性增长。其次是多语言和方言问题。非标准化的医学表达——比如觉得心里闹得慌、胃里翻个儿——对 LLM 的理解能力构成挑战。我们在一批方言测试集上实测分诊准确率从标准普通话描述的 92% 下降到约 76%。解决方案是增加一层口语化表达的规范化预处理但这又引入了额外的延迟和复杂度。在延迟方面整个 LLM 推理路径的 P99 延迟在 8-12 秒对实时对话场景尚可接受但如果后续叠加上多轮追问、检查报告解读等环节端到端延迟会迅速膨胀。建议将分诊定位为首次进入时的科室导航后续对话不应重复执行分诊逻辑。还有一个容易被忽略的风险点LLM 在输出 confidence 字段时其数值与真实准确率之间并无严格的统计对应关系。我们做了 2000 个样本的测试发现当 LLM 输出 confidence 0.9 时实际准确率为 88%当 confidence 在 0.7-0.9 之间时实际准确率反而升至 91%。这说明 LLM 的置信度校准并不理想不应直接作为可信度阈值使用。更好的做法是基于后校验的结果计算联合置信度。五、总结医疗问诊的 AI 增强核心不是让 LLM 替代医生判断而是用工程手段在安全性前置的前提下提升分诊效率和覆盖范围。本文实施的双通道架构将急重症识别延迟控制在毫秒级同时让普通问诊享受到 LLM 的语义理解能力。三层安全保护规则前置、BERT 补漏、实体校验构成了幻觉风险的纵深防御。落地时建议分三步走第一步在人机协同模式下运行所有 LLM 推荐都追加仅供参考标记并记录医生最终选择的科室做对照第二步在积累 10000 真实标注样本后做离线评估确定各环节的阈值参数第三步对准确率 95% 且急重症误判率为 0 的场景逐步放开自动分诊。监控方面需要持续跟踪分诊准确率、急重症漏报率、LLM 超时率和规则引擎降级比例这四个核心指标。