智能导诊与问病方案
本方案面向导医导诊、在线问诊前置分流、健康咨询机器人、症状检索和服务分发等场景，目标是把自然语言输入转化为结构化的症状、科室、疾病和药品候选信息。
适用场景
- 用户输入自然语言症状后，给出就诊科室建议
- 在问诊前置环节做症状抽取和意图识别
- 健康助手或客服机器人理解用户表述并完成分流
- 需要将症状文本转为结构化标签，供后续知识库、搜索或推荐使用
- 希望在导诊流程中补充疾病候选和药品信息线索
典型业务问题
导诊与问病类产品常见的问题包括：
- 用户表述口语化、碎片化，系统难以直接理解
- 症状、疾病、科室之间缺少结构化映射
- 仅靠关键词匹配，容易出现误召回和无效推荐
- 导诊结果无法解释，难以和后续挂号、推荐或内容页联动
- 不同业务方对「导诊」「问病」「推荐用药」的边界理解不一致
推荐方案
智能导诊与问病通常不建议只接一个接口，而是按「先理解输入，再给出分流建议，再补充相关候选」的方式组合。
1. 先做实体识别
建议优先调用 高级·智能实体识别，把用户输入中的疾病、症状、药物、科室、医院、地区等实体抽取出来。
这一层适合承担：
- 识别口语化症状
- 把原句中的实体映射到标准名称
- 为后续导诊、问病、推荐用药提供结构化输入
- 支持高亮、标签展示、日志分析与内容召回
2. 生成科室建议
对于导诊主流程，建议调用 高级·自然语言智能分诊。
可重点使用返回结果中的：
- 一级科室与子科室结构
- 子科室
score meta.intent_score
这适合做：
- 首诊科室推荐
- 症状转挂号入口
- 导诊问答的下一步跳转
3. 补充疾病候选
如果业务希望在分诊基础上提供疾病方向参考，可继续调用 高级·自然语言智能问病。
这一步更适合：
- 提供疾病候选列表
- 做问病补充说明
- 支持知识内容、科普页和进一步问答联动
但这里的结果应理解为「候选疾病参考」，不应替代正式诊断。
4. 补充药品信息线索
如果业务场景还需要给出与疾病或症状相关的药品候选，可调用 高级·自然语言智能推荐用药。
更适合的使用方式是：
- 作为健康内容补充
- 作为药品信息入口或相关推荐
- 与药品主数据或药品详情页联动
不建议将该接口结果直接作为唯一用药决策依据。
推荐调用顺序
导诊主流程建议按下面的顺序设计：
- 调用 智能实体识别，提取症状、疾病、医院、科室等结构化实体
- 调用 自然语言智能分诊，给出科室建议
- 视业务需要调用 自然语言智能问病，补充疾病候选
- 如需药品信息补充，再调用 自然语言智能推荐用药
- 如需把科室建议落到具体医院，可继续衔接「医院信息」目录中的搜索和科室接口
推荐页面形态
这套能力比较适合下面几种产品形态：
- 症状输入框 + 科室推荐卡片
- 多轮问答式导诊助手
- 搜索框 + 结构化实体高亮
- 疾病候选列表 + 科室建议 + 内容推荐组合页
方案边界
智能导诊与问病方案应明确以下边界：
- 返回的是辅助判断结果，不是医疗诊断结论
- 推荐用药结果应视作信息参考，不应直接替代处方或专业判断
- 对低置信度样本，建议设置人工客服、医生咨询或线下就诊升级处理路径
- 高风险、急症、儿童、孕产妇等敏感场景，应增加更严格的业务策略
实施建议
- 保留原始输入、识别实体、推荐结果和最终用户点击路径，便于后续优化
- 将实体识别结果转换为结构化标签，提升搜索、推荐和数据分析能力
- 对
score或intent_score设定阈值，避免在低置信度情况下给出过强推荐 - 在 UI 上区分「推荐科室」「候选疾病」「相关药品」，不要混成单一结论