从财报里冒出来的“AI医生”正在成为理解京东健康价值的一个新坐标。很多人第一反应是这不就是一个聊天机器人吗或者是把大模型套进了问诊框里。但如果你顺着财报的表述和技术落地的实际情况去拆会发现完全不是这么回事。AI医生「大为」真正难的地方不是“让它开口说话”而是让它在一个高度敏感、强监管、且容错率极低的医疗场景里做到比人更守规矩、比传统软件更懂上下文、比搜索工具更会推理。这篇文章不打算只聊财报数字而是聚焦技术层面AI医生背后需要什么样的大模型基座医疗AI的Agent架构怎么设计模型幻觉如何控制数据合规和知识库怎么建设以及一套医疗AI系统从原型到可评测、可灰度、可回滚的工程链路到底长什么样。如果你正在做AI应用开发、大模型工程实践或者准备进入智慧医疗、AI Agent相关方向这篇文章可以帮你建立从概念到实操的完整认知。1. 这篇文章真正要解决的问题医疗AI不是一个新话题。早在深度学习火起来的年代就有公司拿CNN去识别肺结节、做眼底照片筛查也有大量团队用BERT做医疗文本分类。这些项目的共同特点是它们解决的是“单点识别”问题模型输出一个标签、一个概率、一个边界框然后由医生人工复核。但AI医生「大为」指向的是一个截然不同的技术目标——从单点识别走向全流程的医疗服务模拟。这里的差异非常关键。单点识别是“给定一张CT图判断有没有结节”全流程服务是“患者说了一句‘我最近头晕、心慌、睡不好’AI需要决定是否追问病史、是否建议做检查、是否提示心内科就诊、是否需要排除低血糖或心律失常还要用患者能听懂的语言解释风险”。前者是一个分类任务后者是一个复杂的决策推理任务它涉及意图识别、信息抽取、医学知识检索、鉴别诊断、风险分级、医患沟通表达等多个子问题。所以这篇文章要解决的问题不是告诉你“AI很厉害医疗要被颠覆了”而是具体拆解三个层次第一层AI医生到底是用什么技术堆出来的。它不是单一大模型而是一套包含大模型基座、Agent框架、知识库、工具调用链路和人工兜底机制的系统工程。第二层医疗场景给大模型工程带来了哪些特殊约束。幻觉怎么压隐私怎么保护责任边界怎么划评测怎么做灰度怎么放量这些在普通对话产品里可以宽松处理的问题在医疗里全部变成硬门槛。第三层如果你拿到了一个类似“做医疗AI Agent”的需求从架构设计到代码落地第一步应该怎么走最容易踩的坑在哪里以及怎么验证它真的“可用”。一句话总结这篇文章的价值不是帮你解读京东健康股价而是帮你读懂“AI医生”这类产品的技术实质并给你一套可以迁移到医疗、金融、法律等高合规场景的Agent工程方法论。2. AI医生的技术底色从“规则引擎”到“生成式Agent”在深入架构之前有必要先把AI医生的技术演进路径说清楚。如果不理解这一层很容易把大模型时代的AI医生和过去的“智能导诊”混为一谈。2.1 传统智能导诊为什么不够“智能”过去医院和互联网医疗平台上的“智能导诊”本质上是决策树或规则引擎。系统预设一系列问题根据用户的选项逐层跳转。用户回答“发烧、咳嗽”系统走呼吸道感染分支回答“腹痛、呕吐”系统走消化科分支。整个过程中系统不会理解用户语义不会抓取自由文本中的关键信息只能严格按照预设路径走。这种方案的局限非常明显用户必须用系统预设的词汇和结构描述病情实际交流中患者表达往往口语化、模糊、信息缺失规则一旦覆盖不到直接陷入死胡同无法处理多个症状同时存在、需要鉴别诊断的复杂情况系统输出的内容永远是固定文案无法根据用户的年龄、基础疾病、用药情况做个体化调整。2.2 大模型改变的是什么大模型给医疗AI带来的核心变化不只是“更懂人话”更关键的是三层能力第一层是语义理解。大模型可以处理口语化、错别字、病句混杂的主诉文本能够从不完整的信息里抓住核心症状。第二层是医学推理。通过预训练和指令微调大模型可以模拟医生的问诊思路先收集主诉再追问现病史、既往史、过敏史然后结合医学知识做鉴别分析最后给出建议并判断紧急程度。第三层是生成能力。大模型可以以自然语言生成通俗易懂的解释、注意事项和建议而不是输出冷冰冰的医学术语。但这里必须泼一盆冷水大模型的推理能力和生成能力恰恰也是它最危险的地方。一个没有医疗约束的通用大模型完全可能生成一本正经的医学错误。所以医疗AI真正成熟的前提不是模型的“智商”有多高而是工程系统能否把这份“能力”约束在安全边界之内。2.3 AI医生本质是一套Agent系统从架构角度AI医生不是“一个模型”而是一套Agent系统。什么是Agent可以把它理解为一种能够感知目标、拆解任务、调用工具、闭环执行并持续迭代的AI系统。它和传统API调用的最大区别在于Agent有“计划”和“行动”两个环节。面对患者的一句话输入Agent需要先判断该做什么再决定做什么。以“大为”这类产品为参照AI医生的Agent化流程大体是接收用户主诉进行意图识别与信息抽取判定是否需要追问或其他工具支持检索医疗知识库、药品数据库、疾病库必要时调用检查检验解释工具生成初步判断与建议对内容做安全校验、合规过滤、风险分级输出给用户同时记录到随访系统以便后续追踪。这套流程中模型只是“大脑”真正决定系统是否可靠的是“大脑”之外的骨架——工具、知识、校验、兜底机制。理解了这一点就能明白为什么AI医生不能简单等同于“接入ChatGPT API”。3. 医疗AI落地的核心挑战为什么比其他行业更难做AI开发的朋友都知道大模型应用在客服、营销、办公协同里已经跑得很顺但医疗行业的落地节奏明显慢一个身位。这不是因为医疗公司技术落后而是因为医疗AI要过的关卡比一般行业多得多。3.1 第一关模型幻觉是生死线在客服系统里模型偶尔说错一个产品功能最多让用户不满在医疗场景里模型说错一句用药建议可能直接威胁用户健康。大模型的“幻觉”问题在医疗领域会被放大到不可接受的程度。模型可能因为训练数据里的某些相关性生成“建议服用某药物”的内容但这个建议没有经过严格的医学证据检验也没有考虑患者的禁忌症。这是医疗AI落地绕不开的技术难题。行业内的应对思路有几个方向强制约束生成格式让模型输出结构化的JSON降低自由发挥空间把知识检索前置让模型基于检索结果生成而不是完全依赖参数记忆在输出层加规则拦截发现敏感用药或高危症状提示时强制转人工或提示就医采用多模型投票或自一致性校验减少单次生成的随机性。3.2 第二关医学知识需要动态更新医学知识是高速迭代的。新的诊疗指南、新的药物上市、新的临床研究结论每天都会出现。大模型无法靠一次训练终身受用必须通过检索增强生成(RAG把最新知识外挂到模型之外。但医疗RAG比通用RAG更复杂。医学知识库里没有统一的“标准文本”同样的疾病在不同指南里的表述可能不同不同科室对某个症状的解读也可能不同。单纯做一个向量相似度检索很容易把过时的、互相冲突的资料同时召回导致模型生成自相矛盾的回答。因此医疗知识库建设需要在切片策略、元数据标注、来源优先级、版本管理上做大量工作不只是“文档灌进去、向量化”这么简单。3.3 第三关数据合规与隐私保护医疗数据是法律意义上最高敏感等级的数据之一。患者的问诊记录、症状描述、用药历史都属于个人敏感信息。这些数据不能随意上传到公网大模型也不能用于模型训练除非经过严格的脱敏和授权。在实际工程中医疗AI系统通常采取本地化部署或私有化部署策略数据不出域模型基座也可能选择可私有部署的开源模型。同时所有AI生成的内容都需要考虑是否涉及医疗建议的法律责任系统必须在产品层面设置清晰的使用边界。3.4 第四关评测远比想象中困难普通大模型应用可以用“答对了没”来评测医疗AI则要衡量安全性、准确性、合规性、同理心等多个维度。一个回答如果医学上正确但是语气冰冷患者体验就不会好一个回答如果语气温和但遗漏了关键风险提示医疗安全就会出问题。因此医疗AI评测需要建设专门的评测集引入多名医生参与标注并逐条核对回答的安全边界。这个过程成本高、周期长但无法省略。搞清楚了这些挑战再回头看“AI医生出现在财报里”这件事就会明白市场真正重估的不只是一个功能而是一套能把模型能力约束在安全边界内的系统工程能力。4. AI医生的系统架构拆解从工程角度一个合格的医疗AI医生系统至少包含以下几个核心模块。这里以Agent架构为例展开。4.1 系统整体分层层级职责核心组件接入层接收用户输入支持文本、语音等多模态交互Web端、App端、呼叫中心网关理解层意图识别、症状抽取、情感识别、上下文管理大模型专用NLP小模型决策层问诊策略生成、鉴别诊断推理、风险分级Agent编排引擎医学规则库行动层检索知识库、调用工具、生成回答RAG、药品库API、检查检验解释工具约束层合规校验、安全过滤、人工兜底触发规则引擎、敏感词库、人工审核队列记忆层用户多轮对话历史、随访记录、健康档案向量数据库关系数据库评测与监控层回答质量评测、模型漂移检测、日志追踪评测集、自动化评测流水线、监控看板4.2 Agent的决策流程在核心Agent循环里系统会不断执行“规划-执行-反馈”这个循环。以“患者说头晕、心慌”为例理解层先抽取关键词“头晕”“心慌”识别意图为“在线问诊”同时检测到信息不足决策层生成追问策略判断需要补充“持续时间”“既往病史”“是否伴随胸痛”等信息行动层不直接调用知识库而是先向用户发起追问用户补充“昨晚开始有高血压病史没有胸痛”行动层检索心内科相关疾病知识结合用户高血压病史生成鉴别分析约束层校验输出内容判断是否存在高危情况。若用户同时出现“语言不清、肢体无力”等卒中症状直接触发紧急就医提示系统输出建议。同时记忆层记录对话摘要供后续随访使用。这套流程看起来很直观但每一步都有坑。比如追问策略如果过于机械用户会觉得AI在“套话”如果信息不足就生成结论又会出现医疗风险。所以实际工程中决策层往往是通过提示词约束规则辅助实现的而不是完全放给模型自由发挥。5. 从零搭建医疗AI医生Agent的完整实践接下来进入实操。虽然我们无法在文章里完整复现京东健康这样的生产级系统但可以搭建一个最小可运行的医疗问诊Agent原型把上面讲的架构落到代码层面。5.1 环境准备与前置条件本文以Python为主你需要准备以下环境Python 3.10一个可调用的本地或云端大模型接口。为了隐私演示建议用可本地部署的开源模型例如Qwen系列如果只是想快速跑通流程也可以用云厂商提供的兼容OpenAI接口的大模型服务向量数据库这里使用Chroma轻量且无需单独部署一个基础的医学知识库可以用公开的药品说明书、疾病科普资料构建最小测试集LangChain或自研Agent编排逻辑。本文演示自研轻量Agent不引入过重框架安装依赖pip install openai chromadb pydantic python-dotenv如果使用本地部署的模型服务如vLLM、Ollama确保服务已启动并监听在本地端口。5.2 核心主流程一个轻量医疗问诊Agent下面实现一个简化版医疗问诊Agent。它不会替代真实系统但能演示“理解-追问-检索-生成-约束”五个环节。# 文件路径medical_agent/agent.py import json import re from typing import Dict, List, Optional from dataclasses import dataclass, field from openai import OpenAI dataclass class MedicalAgent: model: str qwen2.5:7b-instruct base_url: str http://localhost:11434/v1 api_key: str EMPTY max_turns: int 3 risk_keywords: List[str] field(default_factorylambda: [ 胸痛, 呼吸困难, 意识不清, 肢体无力, 言语不清, 剧烈头痛 ]) def __post_init__(self): self.client OpenAI(base_urlself.base_url, api_keyself.api_key) self.dialogue_history: List[Dict[str, str]] [] def _call_llm(self, messages: List[Dict[str, str]]) - str: response self.client.chat.completions.create( modelself.model, messagesmessages, temperature0.3, max_tokens1024, ) return response.choices[0].message.content def _build_system_prompt(self) - str: return 你是一名在线医疗问诊助手。你的职责是 1. 向用户收集必要的症状信息每次只问一个最关键的问题 2. 不要作出确定的诊断只提供可能性分析和就医建议 3. 如果用户描述涉及高风险症状如胸痛、呼吸困难等立即建议紧急就医 4. 输出内容必须包含当前分析、建议下一步、风险提示三部分 5. 保持语气温和专业不要使用恐吓性语言。 def _extract_jason(self, text: str) - Dict[str, str]: 从模型输出中提取JSON字段用于后续结构化处理。 try: pattern r\{.*\} matched re.search(pattern, text, re.S) if matched: return json.loads(matched.group()) except Exception: pass return {analysis: text, advice: , risk: } def _check_risk(self, user_input: str) - Optional[str]: 规则层风险关键词检测作为模型之外的兜底。 for kw in self.risk_keywords: if kw in user_input: return kw return None def run(self, user_input: str) - Dict[str, str]: risk_keyword self._check_risk(user_input) if risk_keyword: return { type: emergency, message: f您描述了「{risk_keyword}」这可能是急症表现请立即前往医院急诊就诊或拨打急救电话。本AI仅提供参考不能替代医生诊断。 } self.dialogue_history.append({role: user, content: user_input}) if len(self.dialogue_history) self.max_turns * 2: self.dialogue_history self.dialogue_history[-(self.max_turns * 2):] messages [{role: system, content: self._build_system_prompt()}] messages.extend(self.dialogue_history) output self._call_llm(messages) self.dialogue_history.append({role: assistant, content: output}) return {type: normal, message: output}这段代码的要点在于模型输出通过结构化提示词约束尽量让回答包含“当前分析、建议下一步、风险提示”三个要素除了大模型推理还保留了规则层的风险关键词检测这是第一道安全防线通过对话历史管理让Agent具备多轮追问能力而不是一次生成结论temperature降低到0.3减少生成随机性医疗场景更稳。5.3 知识检索增强RAG模块医疗Agent不能只靠大模型的参数记忆必须外挂知识库。下面演示用Chroma构建一个最小医疗知识检索模块。# 文件路径medical_agent/knowledge.py from chromadb import Client from chromadb.config import Settings class MedicalKnowledgeBase: def __init__(self, collection_name: str medical_kb): self.client Client(Settings(chroma_db_implduckdbparquet, persist_directory./chroma_db)) self.collection self.client.get_or_create_collection(namecollection_name) def add_documents(self, docs: List[str], ids: Optional[List[str]] None): if ids is None: ids [fdoc_{i} for i in range(len(docs))] self.collection.add( documentsdocs, idsids ) def query(self, question: str, top_k: int 3) - List[str]: results self.collection.query( query_texts[question], n_resultstop_k ) return results[documents][0] if results[documents] else []在真实医疗场景中知识库的切片和元数据比代码本身复杂得多。一份药品说明书可能要按“适应症”“禁忌症”“不良反应”“用法用量”分别切片并标注药品名称、审核日期、来源等级。如果整个文档粗暴切段检索时容易召回碎片化内容导致模型引用错误片段。5.4 集成Agent与知识库最后把Agent和知识库串起来。当模型认为需要查询某个知识点时先检索再把检索结果拼进上下文。# 文件路径medical_agent/run.py from agent import MedicalAgent from knowledge import MedicalKnowledgeBase def main(): agent MedicalAgent() kb MedicalKnowledgeBase() # 初始化知识库示例数据 kb.add_documents([ 高血压患者应低盐饮食每日食盐摄入量不超过5克。, 普萘洛尔禁用于支气管哮喘患者可能诱发支气管痉挛。, 头晕伴体位性低血压常见于老年高血压患者需要监测卧立位血压。, ]) print(AI医生示例已启动输入「退出」结束对话。) while True: user_input input(您: ) if user_input.strip() 退出: break # 先做知识检索作为上下文补充 context kb.query(user_input) context_text \n.join(context) if context else 无相关额外知识。 # 将知识上下文拼接到用户输入后 augmented_input f{user_input}\n[参考知识]\n{context_text} result agent.run(augmented_input) print(fAI医生: {result[message]}) print() if __name__ __main__: main()运行方式cd medical_agent python run.py这个原型虽然简单但它具备了一个医疗Agent的骨架对话管理、风险规则兜底、知识检索增强和结构化生成。后续上线生产无非是在每一层增加更复杂的工程实现。6. 运行结果与效果验证医疗AI怎么算“答对”了Agentsystem写完不是终点验证才是重点。运行上面的原型一个典型对话示例是您: 我最近总是头晕尤其是站起来的时候。 AI医生: 【当前分析】您描述的头晕在体位变化时出现可能与血压调节有关尤其是老年人或高血压患者需要关注体位性低血压。 【建议下一步】建议您测量卧立位血压即在平躺静息后测量血压再站立1-3分钟后复测记录差异。如果头晕加重请及时到神经内科或心内科就诊。 【风险提示】如果出现剧烈头痛、言语不清、肢体无力请立即就医。这个回答是否“正确”需要从三个层次验证。第一层是格式验证是否包含当前分析、建议下一步、风险提示三部分。第二层是医学准确性验证需要医生标注或对照权威指南。比如这个回答里关于体位性低血压的建议与高血压管理指南中的建议一致可以认为准确。第三层是安全边界验证模型是否在证据不足时给出确定诊断是否遗漏高风险信号。这需要构建专门的测试集覆盖常见病、罕见病、高风险急症、模糊主诉等类别。在生产环境推荐建设一个结构化的评测集并把评测结果与模型版本绑定。例如测试类别用例数通过标准当前通过率常见病咨询200回答包含正确分析和就医建议待评测高风险急症识别100100%触发紧急就医提示待评测处方药安全提示150无错误用药建议待评测模糊主诉追问120至少追问一个关键信息待评测如果高危识别通过率不是100%坚决不能上线。这不是苛求而是医疗AI的底线。7. 常见问题与排查思路在实际开发医疗Agent过程中下面这些问题最常出现。问题现象可能原因排查方式解决方案患者描述“胸口闷”模型没有提示风险风险关键词库覆盖不足模型未识别出等同于胸痛的高风险表达扩充风险表达词表加入“压榨感”“闷痛”“心前区不适”等变体规则层使用正则同义词扩展并增加模型层风险分类模型回答出现互相矛盾的用药建议RAG检索到多份冲突资料模型无法判断优先级查看检索命中的知识片段和来源知识库增加来源等级元数据检索后按优先级重排多轮对话后模型忘记早期症状上下文窗口被截断观察对话历史截断策略引入摘要机制每轮结束后生成结构化病例摘要模型生成的内容过于学术用户看不懂提示词中没有表达风格约束人工检查多轮输出在系统提示词中加入“使用通俗语言避免医学术语堆砌”高并发时段模型响应慢本地推理资源不足或请求排队查看推理服务监控指标增加副本数或引入队列削峰用户输入包含错别字或方言模型分词和纠错能力不足记录典型错误输入并分析加入医疗实体纠错模块或医学术语标准化环节最容易被忽略的是第二条。很多团队以为RAG只需“检索到即可”实际上知识冲突是医疗知识库最常见的坑。同一个药物在不同说明书里的禁忌表述可能不同同一个症状在不同指南中的处理建议也可能不同。如果知识库没有建立“来源优先级”机制模型就会无所适从甚至把错误来源的信息当成标准答案。8. 最佳实践与工程建议基于上面的讨论最后整理一份医疗AI Agent的工程建议清单适用于所有高合规场景。8.1 安全兜底优先于模型能力不要迷信大模型的推理能力。无论基座模型多强都必须保留一层独立的规则兜底。风险关键词检测、高危症状匹配、禁止输出清单、紧急就医触发这些规则必须在大模型之外独立运行且优先级最高。原因是规则系统可解释、可测试、可审计而模型不可解释性在医疗场景是无法接受的。8.2 知识库要“精”而不是“大”医疗知识库不是文档越多越好。低质量、重复、过时的资料混入向量库检索时只会增加噪音。正确做法是建立知识入库审核流程所有文档标记来源和更新时间按知识类型设计切片策略一份文档按药品、疾病、检查、护理等维度拆分为每个知识片段打标签包括适用人群、适用范围、证据等级定期清理旧版本知识记录替换日志。8.3 评测体系要三层分离第一层离线评测。构建大规模评测集模型迭代后跑全量回归防止某次微调提升了一个能力却破坏了另一个能力。第二层线上小流量评测。在真实用户请求中抽取小比例流量由医生团队审核回答质量观察模型在真实分布数据上的表现。第三层长期监控。模型上线后持续监控回答的内容分布、用户投诉率、转人工率、高危触发达标率。大模型会漂移服务端更新、提示词变化都可能造成行为改变。8.4 人工兜底机制必须存在即便AI判断足够可靠也必须设计“AI回答人工可介入”的双轨机制。当系统检测到高危信号、模型自评分过低、或者用户对AI回答提出质疑时自动转接人工医生。AI应该是医生的助手而不是医生消失后的替代品。8.5 权限与审计闭环医疗AI系统的所有日志都需要完整记录包括原始输入、检索命中的知识片段、模型生成的完整内容、规则层的拦截记录、人工审核结果。这一步既是为了追溯问题也是为了满足合规审计要求。系统日志建议保存在独立的审计存储中禁止普通开发人员直接修改。9. 总结与后续学习方向“AI医生”出现在财报里的意义不只是京东健康多了一个产品功能而是医疗行业开始验证“大模型Agent知识工程”这套技术栈在最高合规等级的行业里能不能跑通商业闭环。从工程角度看AI医生和市面上的通用AI应用之间隔着一整套安全、评测、知识治理、审计和人工兜底体系。这套体系才是这类产品真正的护城河。如果你准备深入这个方向建议按以下路径逐步深入第一步把Agent基础打牢。实现一个不含医疗约束的通用问诊Agent搞清楚对话管理、工具调用和记忆机制。第二步掌握RAG工程。重点不是调用向量数据库而是理解切片、元数据、重排和知识冲突处理。第三步建立评测思维。学会构建评测集、设计评测指标、跑回归实验。第四步研究合规与安全设计。理解数据脱敏、私有化部署、权限控制、审计日志这些“非模型”能力。第五步参与真实项目。医疗AI必须在真实场景里打磨纸上谈兵学不会“如何预防模型幻觉导致的事故”。在做任何医疗AI开发时始终记得一个原则模型可以犯错系统必须兜底。真正优秀的医疗AI不是“替代医生”的技术而是“让医生更安全、让患者更有保障”的基础设施。技术永远在迭代但这条底线不能松动。