中医智能预问诊系统架构与工程实践

作者：热心市民鹿先生2026.11.07 01:02浏览量：0

简介：本文面向架构师与开发者，系统阐述中医智能预问诊系统的设计思路与落地路径：从四诊信息采集、多轮对话编排，到病历草稿生成与辨证提示，拆解流程效率、结构化输出与安全合规等工程要点，并给出可复用的模块划分、数据模型与评估方法，帮助团队低成本构建可上线的数字医师助手。

中医智能预问诊系统架构与工程实践

一、背景与问题定义

中医临床诊疗的第一环是”问诊”：医生通过对话采集主诉、现病史、既往史、舌象与脉象描述等信息，再据此完成辨证论治。这一过程高度依赖医生的个人经验，耗时且质量不稳定。在基层医疗与互联网医疗快速扩张的背景下，供需矛盾被进一步放大：社区卫生服务中心缺乏经验丰富的中医师，问诊质量参差不齐；患者挂号前不知道应该选择哪个科室；在线咨询在夜间缺少值班人力；门诊病历书写仓促导致记录不完整。

大语言模型的出现，使得”由 AI 模拟问诊过程、承担初步信息采集与病历草稿生成”成为可行的工程目标。需要强调的是，这类系统的定位应是数字医师助手：完成预问诊、分诊建议与病历初稿，最终判断权与责任仍归属于接诊医生。本文以某大型中医医院的智能预问诊部署为参考场景，讨论系统的目标、架构、关键模块与工程权衡。

系统目标可归纳为四条：

  • 流程提效：在患者候诊阶段完成预问诊，将主诉与症状史结构化，生成标准化病历草稿，缩短医生接诊时的录入时间。
  • 质量均一化：以固定的问诊提纲约束采集范围，减少漏问、漏记，使基层问诊达到可接受的下限质量。
  • 就医导航：通过数轮问答形成初步病情画像，给出科室或专科方向的建议。
  • 全天候可用：提供 7×24 小时的初步咨询入口，缓解患者焦虑并分流非紧急需求。

二、总体架构

推荐采用分层架构，将”对话能力”与”业务约束”解耦，避免把全部逻辑塞进一个提示词里。

  1. 接入层      Web / 小程序 / 院内自助机 / 医生工作站
  2.    │
  3. 对话编排层  会话管理 · 问诊提纲状态机 · 槽位填充 · 追问策略
  4.    │
  5. 能力层      LLM 推理网关 · 结构化抽取 · 知识检索(RAG) · 安全审核
  6.    │
  7. 数据层      问诊模板库 · 术语与证候词表 · 病历文书模板 · 会话与审计日志
  8.    │
  9. 输出层      病历草稿 · 辨证提示 · 分诊建议 · 医生复核界面

接入层面向多端复用同一套会话服务，前端只负责渲染与采集（含舌象照片上传入口）。对话编排层是系统的大脑，负责决定”下一个该问什么”，这是与通用聊天机器人最本质的差异。能力层封装模型调用、结构化输出与内容安全。数据层沉淀领域资产，是长期迭代的核心。输出层必须提供医生可编辑、可签名的复核界面，而非直接写入正式病历。

三、核心模块设计

3.1 问诊提纲与状态机

中医问诊有相对成熟的采集框架（如十问歌所覆盖的寒热、汗、头身、饮食、二便、睡眠等维度）。工程上应将其建模为带槽位的问诊提纲，而非自由对话：

  1. INQUIRY_SCHEMA = {
  2.     "chief_complaint": {"required": True, "desc": "主诉及持续时间"},
  3.     "present_illness": {
  4.         "duration":    {"required": True},
  5.         "location":    {"required": True},
  6.         "character":   {"required": True},   # 疼痛性质、诱因
  7.         "aggravating": {"required": False},
  8.     },
  9.     "system_review": {
  10.         "cold_heat":  {"required": True},    # 寒热
  11.         "sweat":      {"required": False},   # 汗
  12.         "appetite":   {"required": False},   # 饮食
  13.         "stool_urine":{"required": False},   # 二便
  14.         "sleep":      {"required": False},   # 睡眠
  15.     },
  16.     "history": {"past": {}, "medication": {}, "allergy": {}},
  17. }

编排器每一轮执行三步：读取当前槽位填充状态 → 选出优先级最高的缺失槽位 → 生成一个自然的追问句。这样既能保证采集完整性，又不会像问卷那样机械。追问应遵循”一次只问一件事”的原则，并允许患者用自由文本回答后由抽取模块回填多个槽位。

3.2 结构化抽取与校验

模型输出必须是可校验的结构化数据，而非散文。建议采用”约束解码 + 后置校验”双保险：

  1. def extract_slots(utterance, schema):
  2.     raw = llm.invoke(
  3.         prompt=EXTRACT_PROMPT,
  4.         response_format={"type": "json_object"},
  5.         input=utterance,
  6.     )
  7.     data = json.loads(raw)
  8.     # 归一化：把"拉肚子"映射到"腹泻"，"睡不着"映射到"失眠"
  9.     data = normalize_terms(data, TERM_DICT)
  10.     # 校验：类型、枚举值、必填项、数值范围
  11.     return validate(data, schema), missing_fields(data, schema)

术语归一化依赖领域词表而非模型幻觉。凡是抽取置信度低或与既往回答冲突的槽位，应标记为”待医生确认”，并在草稿中显式提示，而不是静默采用。

3.3 知识检索与辨证提示

辨证提示不应由模型凭空生成。更稳妥的做法是检索增强：以结构化槽位作为查询条件，从证候知识库中召回候选证型与对应治法方剂，再由模型组织为可读的提示文本，并附来源条目供医生追溯。输出措辞应统一为”提示/参考”，避免形成诊断结论式表述。

3.4 病历草稿生成

病历文书有严格的版式要求。建议使用模板渲染 + 模型润色的组合：模板保证字段位置与格式合规，模型只负责把口语化描述改写为规范的医学术语表述。生成结果需包含主诉、现病史、既往史、中医四诊摘要，并标注哪些内容来自患者自述、哪些来自模型归纳，便于医生快速甄别。

四、关键工程权衡

延迟与轮次的平衡。 预问诊发生在候诊窗口内，端到端时延需控制在秒级。可通过流式输出首句、并行预取下一问题、缓存高频问诊路径来优化。同时应限制总轮次上限（如 8～12 轮），超限则收敛为”信息不足，建议面诊”。

多模态的边界。 舌象照片可采集，但受光照、设备、拍摄角度影响极大，模型输出的舌色舌苔描述只能作为参考线索，必须在界面明示”非诊断依据”。脉诊无法远程采集，系统应主动声明该维度缺失，而非编造。

幻觉与安全。 三层防护：输入侧过滤急症红旗症状（如胸痛伴冷汗、意识改变）并直接引导急诊；生成侧用结构化输出与知识检索约束内容；输出侧做敏感表述审核。所有会话需留存审计日志，支持回溯。

评估方法。 离线用标注问诊记录评测槽位抽取的准确率与召回率；在线关注病历草稿的医生修改率、平均接诊时长变化、分诊建议采纳率。修改率是最贴近真实价值的指标——若医生几乎不改，说明草稿质量达标。

五、落地建议

建议分阶段推进：先做”采集 + 病历草稿”这一确定性最强的环节，在单一科室试点，积累标注数据；再逐步引入辨证提示与分诊建议；最后打通医生工作站的回写链路。领域资产（问诊模板、术语词表、证候库）的建设投入应高于模型调参投入，因为前者决定系统的上限与可维护性。

总而言之，中医智能预问诊系统的技术核心不在于模型有多强，而在于用工程约束把模型的开放性收敛到临床可接受的范围：提纲约束采集范围，结构化约束输出格式，检索约束知识来源，复核界面约束责任边界。四者到位，系统才具备真正上线的条件。

最热文章