拆解京东健康AI医生“大为”：医疗AI Agent如何从Demo走向生产系统

这次我们来拆一个很少见的标的写进财报里的AI医疗产品——京东健康的AI医生“大为”。医疗AI产品不少但多数停留在发布会PPT和演示Demo阶段。真正进入上市公司财报、被写进业务叙事里的确实不多。“大为”的价值不在于多了一个会聊天的医疗大模型而在于它直接嵌入京东健康的在线问诊、健康管理、用药服务链条成为一项能影响成本和收入结构的基础设施。这篇文章不聊股价建议只从技术落地和企业级AI产品角度拆三件事“大为”到底是什么长在什么业务场景里支撑它的技术底座有哪些关键模块为什么市场认为它有“价值重估”的潜力以及普通人如何跟踪验证。如果你在做AI Agent、医疗大模型、RAG落地或者关注大模型如何从技术Demo变成真实业务系统这篇文章可以收藏。1. 核心能力速览先把“大为”的关键信息列出来后续再展开。能力项说明产品定位京东健康体系内的AI医生面向用户的医疗服务入口技术类型医疗大模型 Agent RAG 医疗知识图谱 多模态识别核心功能预问诊、分诊导诊、辅助诊断建议、健康咨询、报告解读、用药提醒、复诊随访交互形态图文对话、语音问诊主要承载在京东健康App和相关小程序业务价值提升在线问诊效率、降低医生重复劳动、延长用户服务周期商业模式增强在线问诊转化、会员健康服务、药械服务联动关键门槛医疗责任归属、幻觉率控制、数据合规、人机协同估值影响从“卖药平台”向“医疗服务平台”迁移的叙事基础后续关注指标问诊量、AI渗透率、复诊率、财报关键词频次需要说明的是大部分技术参数、模型规模和内部实现京东健康不会完全公开。所以下面凡是涉及细节的推测我会明确标注“从业务形态推断”或“更稳妥的判断是”不会用猜测冒充事实。2. AI医生“大为”是什么产品定位不是聊天机器人2.1 从财报看到的信息从财报的业务表述看京东健康对“大为”的定位不是“智能问答机器人”而是“医疗服务能力的AI化”。在线问诊行业的核心成本是医生人力。一个医生同时只能接待一个用户问诊时长受限于打字速度和医生经验判断。平台做大之后问诊量增长会带来医生成本的线性增长。AI医生要解决的正是这个问题在用户进入人工问诊前由AI完成预问诊收集症状、病史、用药情况在问诊过程中AI提供辅助决策建议帮助医生快速完成判断在问诊结束后AI承担随访、用药提醒、报告解读等低频但耗时的工作。这其实是一个典型的“AI Agent 人工兜底”模式AI负责标准化、重复性、低风险的环节医生负责诊断、处方和复杂沟通。2.2 产品闭环拆解“大为”不是孤立功能。从互联网医疗的业务流程看它至少嵌在四个环节里问诊前用户描述症状AI分诊到对应科室推荐匹配医生问诊中AI整理用户主诉和关键信息辅助医生快速决策问诊后AI解读报告、生成用药提醒、安排复诊计划健康管理面向慢病用户提供长期随访和健康建议。这样拆下来就清楚了AI医生不是替代医生而是重新设计“问诊服务”的生产流程。它把医生从“重复问问题”里解放出来把更多精力放在“判断”和“决策”上。这也是AI医疗产品和通用ChatGPT类产品最本质的区别医疗AI的价值不在“生成文字”而在“完成一个医疗服务流程”。3. 技术底座拆解医疗Agent不是通用大模型加壳通用大模型经过Prompt工程可以回答“感冒了吃什么药”但距离可商用的AI医生还差很远。一个能在真实业务里运行的医疗Agent至少需要下面这些模块协同。3.1 医疗大模型与领域微调通用大模型的知识覆盖广但医学知识更新慢且容易产生“自信的幻觉”。医疗场景要求模型在“不知道”的时候承认不知道而不是编造一个治疗方案。所以“大为”这类产品的基础模型需要经过一系列医疗领域改造医学语料继续预训练问诊、诊断、用药等场景的指令微调基于医生反馈的偏好对齐高频错误样本的定向修复。这套流程和通用大模型微调一致但难点在数据质量。医疗对话数据涉及隐私清洗和标注成本远高于通用数据。3.2 RAG与知识库医疗知识是强时效性的。药品说明书会更新指南会修订新药会上市。如果只靠模型参数里的记忆必然出现版本滞后。更稳妥的方案是RAG把药品库、疾病指南、说明书、医学文献切成向量块用户提问时先检索再用原文兜底。这样做有两个好处回答可以附带来源用户和医生可以追溯到具体依据知识更新只需替换文档不需要频繁重训模型。RAG的工程难点不在“能检索到”而在“检索到的内容是否匹配当前问诊上下文”。同样是“发烧”一词儿童和老人、有基础病和无基础病对应的检索策略完全不同。3.3 知识图谱与推理大模型擅长自然语言理解但不擅长“多跳推理”和“严格逻辑约束”。医疗场景里疾病、症状、药品、科室之间存在大量结构化关系这正是知识图谱的强项。一个完整的医疗图谱至少包含四类节点节点类型示例疾病高血压、2型糖尿病、上呼吸道感染症状头痛、发热、呕吐、心悸药品布洛芬、二甲双胍、阿莫西林科室心血管内科、内分泌科、呼吸内科操作路径是大模型先从用户对话中抽取实体再交给图谱做规则校验。比如用户说“阿莫西林过敏”图谱会关联出禁用药物类别在后续推荐中自动拦截。这里有一个工程判断纯靠大模型做“药物相互作用判断”风险很高用“图谱规则优先大模型生成兜底”的混合架构更稳。3.4 工具调用与多模态识别医疗Agent还需要调用大量外部工具比如用药提醒调度科室医生排班查询处方药订单合规校验化验单OCR识别。以化验单识别为例用户拍一张血常规报告AI需要先识别表格文字再判断哪些指标异常最后结合用户主诉生成解读。这个链路不能靠单一模型完成必须用多模态模型 结构化解析 规则引擎串联。3.5 语音交互与安全护栏手机上的AI医生语音是重要入口。中老年用户打字慢语音问诊能显著降低使用门槛。这里需要ASR准确率、方言兼容、语音中医学实体抽取等能力。更要紧的是安全护栏。医疗场景不允许“自由发挥”系统必须包含风险问题拒答敏感词拦截处方药合规校验极端情绪识别转人工兜底触发条件。如果AI识别到“胸痛持续半小时”“呼吸困难”等高风险信号必须立即引导用户急救而不是继续问诊。4. 医疗AI Agent的工程实践参考虽然京东健康没有公开“大为”的完整技术架构但一个可商用的医疗AI Agent通常可以按下面这套流程设计和验证。以下代码和配置仅用于说明工程思路不是京东健康实际接口。4.1 系统架构按模块拆分医疗AI Agent可以分成六层用户入口层App / 小程序 / 语音助手 交互层多轮对话管理、语音识别、情绪识别 理解层意图识别、医学实体抽取、分诊决策 知识层RAG检索、知识图谱查询、医学规则引擎 行动层报告解析、药品校验、用药提醒、转人工调度 审计层日志留痕、质量抽评、合规审查这层结构的好处是每一层都可以独立评测和替换。知识库里换文档不需要动交互层语音识别换成新供应商也不会影响实体抽取。4.2 意图路由示例AI医生面对的第一件事是判断用户想干什么。# 示例代码医疗Agent意图路由非京东健康实际实现 def route_intent(user_query: str) - str: query user_query.lower() if 报告 in query or 化验 in query or 结果 in query: return report_interpretation if 药 in query and (怎么吃 in query or 几次 in query): return medication_guidance if 痛 in query or 烧 in query or 不舒服 in query: return symptom_triage if 预约 in query or 挂号 in query: return appointment_booking if 过敏 in query: return allergy_screening return fallback_to_human # 无法判断时转人工这段代码的关键点是最后一行当意图不明确时优先转人工而不是继续生成。这是医疗Agent和普通客服机器人最大的差异。4.3 问诊请求与响应结构一个标准化问诊请求建议包含用户身份、症状时间线、历史病史和当前用药情况。响应结构则需要带有“依据来源”和“风险等级”。下面是一个通用的JSON结构示例{ request_id: 20250601001, patient: { age: 45, gender: male, allergy_history: [penicillin] }, session: { chief_complaint: 咳嗽持续三天夜间加重, ongoing_medication: [ {name: 头孢克肟, dosage: 100mg} ] }, response: { likely_category: 急性上呼吸道感染待排, risk_level: moderate, suggestion: [ 建议线下就诊呼吸内科, 暂停使用当前抗生素需医生评估后再决定 ], evidence_source: [ 国家呼吸系统疾病诊疗指南_v2025, 头孢克肟说明书_不良反应部分 ], action: refer_to_human_doctor } }这个结构体现了一个核心原则AI给出的是“建议”而不是“诊断”且必须携带证据必须给出下一步行动方案。4.4 RAG配置模板RAG的召回质量直接决定医疗回答质量。下面是一个通用配置模板用于限定知识库类型、切片方式和召回参数retrieval: top_k: 5 score_threshold: 0.72 chunk_size: 512 chunk_overlap: 64 embedding_model: medical-embedding-v2 knowledge_base: - name: drug_instructions version: 2025.06 priority: high - name: clinical_guidelines version: 2025.03 priority: high - name: medical_qa_cases version: 2025.01 priority: medium rerank: enabled: true model: medical-cross-encoder filter_conditions: - drug_conflict_check: must_pass - age_group_match: requiredscore_threshold建议设高一点。医疗场景宁可“没找到答案”也要避免“拿错答案硬答”。召回质量不达标时应该触发回落机制而不是强行生成。4.5 评测与灰度验证医疗AI Agent的评测不建议只跑通用Benchmark。更有效的做法是分模块评测模块评测数据核心指标分诊准确率标注问诊会话科室匹配准确率报告解读真实脱敏化验单指标识别F1、异常项召回率用药审核药品组合案例冲突拦截率、误报率安全拒答风险问题集拒答率、误伤率转人工质量实际转人工会话用户满意度、转诊合理性灰度策略建议按“风险等级”分阶段放量先放开健康咨询类问题再放开常见病预问诊最后才考虑辅助诊断类能力。每一步都要有人工抽检和召回机制。5. 财报里的价值重估逻辑企业级AI产品的价值最终要体现在财务指标上。“大为”被写进财报叙事背后是四条可以量化的逻辑线。5.1 成本端问诊边际成本下降在线问诊平台最大的成本是医生人力成本。AI预问诊能把用户从“主诉表达”到“医生看到信息”的时间压缩到极致。医生不需要再花时间问“什么时候开始的”“有没有发热”“对什么药过敏”AI已经把这些信息结构化整理好了。这个改变带来两个结果同样数量的医生单位时间能服务更多用户平台增加问诊量的边际成本降低。当问诊量的增长不再需要等比例的医生数量增长平台的毛利率和运营效率就会发生变化。这是最直接的价值重估依据。5.2 收入端服务链条延长传统的“问诊-开药”模式用户在医生回复后大概率离开。AI医生可以把服务链条拉长问诊结束AI自动推送用药提醒药品快吃完时提示复诊开方慢病患者按周期收到随访问卷化验单异常时建议进一步检查。每多一次触达就可能多一次复购和续费。AI医生在这里的角色是“低成本运营用户关系”的工具。5.3 数据飞轮AI医生每服务一个用户都会产生结构化的健康数据。数据经过脱敏和标注后可以反过来优化模型提升后续问诊的准确率和体验。这形成一个闭环用户使用AI问诊 → 产生结构化数据 → 优化模型 → 体验提升 → 更多用户使用这个飞轮一旦转起来就是竞对很难复制的能力。数据积累和模型优化之间存在时间窗口优势。5.4 估值逻辑从卖药到“医疗服务平台”京东健康原本在资本市场的核心标签是“医药电商”。这个标签有明确的天花板毛利率受制于药品品类的价格竞争。AI医生“大为”的存在让京东健康可以讲一个更强的故事从“卖药的地方”变成“提供健康服务的入口”。用户先找AI问诊再按需求买药、买器械、买保险服务链路的入口从商品搜索变成了医疗咨询。这个迁移一旦成立估值体系就会从“零售公司”转向“科技医疗平台”。当然叙事需要数据支撑。市场真正会跟踪的还是AI渗透率、问诊量增速、复购率这些可以验证的指标。6. 合规与安全使用边界医疗AI是强监管领域。无论产品体验多好合规边界控制不好就会出大问题。这里重点说四个边界。责任边界AI不能独立承担诊断责任。产品的界面、话术、服务协议都必须明确“AI建议仅供参考最终以医生诊断为准”。系统如果无法判断必须引导用户转人工。隐私边界问诊数据属于医疗健康数据受个人信息保护相关法律严格约束。数据采集、存储、传输、流转都必须做脱敏、加密、权限控制。AI对话记录不能随意用于模型训练。内容边界涉及处方药推荐时必须遵循处方药管理要求。AI不能直接向用户销售处方药必须经过有资质的医师审方。授权边界如果AI需要采集用户的音频、人脸图像、体检报告必须取得用户明确同意并在显著位置说明用途。涉及第三方数据合作时必须确认数据来源的合法授权。任何做医疗AI的团队都应该把合规能力当成产品的一部分而不是上线之后补的“补丁”。7. 常见问题与排查方法医疗AI Agent在落地过程中最容易遇到下面这些问题。问题现象可能原因排查方式解决方案分诊推荐科室不对意图识别模型泛化不足抽样分析错误样本增加科室规则约束结合知识图谱修正回答引用过时信息RAG知识库版本未更新检查文档版本和更新时间建立知识库版本管理机制到期强制更新高风险问题未触发拦截安全规则漏配用高风险问题集回归测试补充风险触发词表增加规则优先级多轮对话后上下文混乱上下文窗口截断策略不合理查看对话日志中的关键信息丢失情况引入结构化摘要压缩冗余历史用户不满意却未转人工转人工阈值过高分析满意度评分与转人工率降低转人工触发阈值增加兜底入口报告识别指标遗漏OCR对模糊图片识别率低抽样统计异常项召回率增加清晰度判断模糊图片直接提示重拍药房下单金额异常推荐逻辑与库存系统不一致对比推荐结果和实际库存在推荐链路中增加库存实时校验以上问题不是某一家公司的特有情况而是医疗AI Agent从Demo到生产环境都会遇到的通用坑。排查的关键是把每个模块的日志留好、指标拆细。8. 跟踪AI医生落地效果的方法判断“大为”到底是真价值还是PPT概念不需要去猜财报措辞跟踪下面几件事就够了。跟踪维度具体指标说明用户侧月活跃问诊用户数AI医生是否真的被用户使用业务侧AI渗透率、转人工率AI能独立解决多少问题财务侧问诊收入、会员收入AI是否带来收入增量技术侧大模型版本更新频率团队是否在持续投入迭代产品侧新功能上线节奏是否只停留在对话还是延伸到报告、用药等场景招聘侧AI医疗岗位招聘数量加招是落地信号停招可能是收缩信号从前面的技术拆解可以看出AI医疗产品最重要的指标不是“对话流畅度”而是“流程渗透率”用户从进入AI问诊到最后完成服务闭环AI参与了多少步。这一步渗透得越深公司的服务成本越低估值逻辑越扎实。9. 总结与下一步AI医生“大为”值得关注的原因不是它聊得多好而是它把AI医疗从一个“演示能力”变成一个“生产工具”。它最值得验证的三个点是问诊成本是否真的下降用户复诊和购药转化是否提升数据飞轮是否形成稳定的迭代节奏。最容易踩的坑则是“过分相信模型生成能力”和“忽略医疗责任边界”。任何一个医疗AI产品都要先把合规、安全、转人工兜底做好再谈效率提升。如果要做同类的医疗AI Agent建议从最小闭环开始选一个垂直场景比如“用药咨询”或“化验单解读”把RAG和规则引擎跑通先证明它能稳定完成一类任务再扩展到更多场景。方法上可以先用开源医疗大模型搭一个可运行的原型验证意图识别、RAG召回和知识图谱这三块核心能力能不能对齐业务需求。判断标准很简单AI给出的建议有没有依据用户看不懂时能不能转给真人错误有没有被记录下来并持续修正。“大为”后续的表现重点看它在京东健康财报里被提到的频率和具体业务数据不用听发布会怎么说看季度问诊量和AI渗透率的变化趋势就够。