把AI网关放到医疗行业很多人的第一反应是先问一句这是真需求还是换个概念讲故事我过去一年大部分时间都在帮医院和医疗软件厂商做MAI Gateway这种场景化的AI网关说白了就是在模型服务和实际业务之间加一层统一入口把门诊导诊、辅助决策、报告生成、患者宣教这些低频词下的高频场景一个一个接进去。这篇文章不准备讲PPT上能搜到的东西只讲我真实做下来的路由设计、安全策略配置、以及怎么把不可控的模型输出变成临床和患者都能接受的回答。适合正在做医疗AI落地的工程师、产品经理和医院信息科同事参考也能给刚接触AI网关概念的人一点可上手的思路。1. 为什么医疗行业需要AI网关1.1 医疗AI落地的真实痛点做医疗AI项目之前我先给自己做了一个判断医院不是缺大模型而是缺一个能让大模型被安全使用的壳。医疗AI只要进入生产环境几乎所有人都会撞上三个真问题躲都躲不开。第一个问题是模型一多就彻底乱了。导诊场景想用一个理解能力强一点的通用对话模型病历结构化要接一个擅长医学文本的模型影像报告生成可能又要用另一家厂商的专科小模型。每个模型接口格式不一样、密钥不一样、调用限制不一样业务系统如果每个都直接对接维护成本会直接失控。我见过一家医院信息科的现状导诊、随访、宣教用了三个不同模型每个都保留一份对接文档新员工接手之后光是理清楚三套鉴权方式就要花一周多更别提后面要换模型时引起的连锁返工。第二个问题是数据安全的约束比普通行业高一大截。患者主诉、既往病史、检查结果、影像报告这些都是敏感信息在传给模型之前必须做充分脱敏传输过程要留痕模型服务方还得明确不采集、不落盘。这些约束不是靠写文档提醒开发同学“注意一点”就能落地的必须有一条强制链路在每一笔请求上强制执行策略。没有网关时每个业务系统自己写脱敏逻辑写出来的东西五花八门安全审计完全看运气。第三个问题是医疗流程不能随便断。门诊高峰期导诊要同时服务几百个患者如果上游模型服务出现故障或者响应变慢患者会直接堵在门诊入口。普通网站遇到超时还可以让用户等一下再刷新医疗场景里出现这种问题就不是单纯技术事故那么简单。临床科室对回答质量的容忍度也很低稍微不规范就要返工医生本来就很忙不可能每天把时间花在跟模型对话纠错上。所以我的结论很直接应用层直接对接大模型前期跑通演示很快后面越走越窄。业务系统不需要关心模型怎么调度、怎么降级、怎么合规它需要的是把“怎么用模型”这件事整体交出去自己只关注患者和医生到底要什么。1.2 AI网关到底管什么AI网关不是流量网关的简单改名。流量网关只认URL、IP和端口AI网关至少要管理六件事。统一入口放在第一位。所有模型请求先到网关业务系统不再直接持有模型地址和密钥只需要跟网关约定一套内部接口模型侧怎么变化基本不打扰业务方。智能路由是第二个能力。按场景选择模型按配置决定优先级按负载决定该发给谁。路由不是只做一次选择而是在调用过程中持续生效主模型超时了自动切备用某个模型连续报错就自动摘除这些动作放在网关层可以实现得干净利落。安全与合规过滤是医疗场景最重的一块。请求到网关之后先做数据格式识别、敏感信息检查、内容脱敏再决定是否放行模型返回之后还要做一次结果校验防止模型输出超出边界的内容。这一进一出两道检查是医疗AI能不能上线的分水岭。模型治理意味着所有模型都有档案。什么模型能用、擅长什么任务、当前什么版本、Token消耗多少都由网关统一管理。上线新模型不需要改业务代码替换旧模型也不需要业务方做联调。成本核算也不能靠手工记账。每个科室、每个病种、每个场景消耗了多少调用量、多少Token网关按请求自动归集。医院最终要知道花出去的钱换回了什么效果不能年底拉Excel算一笔糊涂账。最后是场景化模板。这是MAI Gateway区别于普通网关的关键网关不只是转发而是把导诊、报告生成、辅助决策这些业务动作拆成流程模板。每个模板里配好提示词、数据字段、校验规则和降级方案业务系统调用时只需要说“我要一次导诊”剩下的编排由网关完成。以上这些事情放在应用层去做会造成大量重复代码放在独立网关去做才能让模型策略真正变成可配置、可维护、可审计的资产。2. MAI Gateway的场景化设计思路2.1 什么是MAI GatewayMAI Gateway我习惯理解成Medical AI Gateway也就是医疗AI网关。它不是又一个OpenAPI转发壳子而是为医疗行业预置了大量场景抽象的AI接入层。普通网关只认识URL、Method和TokenMAI Gateway理解“分诊请求”“辅助决策请求”“报告生成请求”这些业务动作。每个动作都自带数据规则、校验规则和降级策略请求到了网关网关能判断出这是一次什么样的业务行为而不是机械地把它导到某个模型地址上。从架构上看MAI Gateway大致分成五块。接入层负责统一鉴权、协议转换、请求限流路由层根据场景标签、模型状态、负载情况做分发和降级策略层承载脱敏规则、内容合规和输出校验模型管理层维护模型注册表、版本和可用性状态审计层记录全量调用流水和Token账单。五块之间通过配置驱动不靠硬编码串联。这个设计的核心用意是让“场景”变成第一公民。临床科室提需求时说的是“我要一个能处理检验报告异常值提醒的功能”不是“我要接入某个模型”。网关先把这句话翻译成一个场景流程再决定这个流程用到哪些模型、哪些规则。业务方只需要面对业务语言模型技术细节被完全隔离在后面。如果你已经有一定技术基础可以把它想象成一个交换机业务系统是终端模型是上联端口交换机里的ACL和安全策略就是MAI Gateway的配置区。没有交换机每个终端得自己拉一根线直连上联有交换机的意义就在于集中管理和策略下发。2.2 场景化解决的核心维度真正做场景化设计时我基本围绕四个维度展开不是简单列一个接口清单。第一是业务场景的抽象粒度。导诊、辅助决策、报告生成、随访宣教这些都要按“完整业务动作”划分而不是按“调一次模型”划分。比如导诊动作包含紧急词预检、科室推荐、追问问题生成、低置信转人工四个步骤虽然中间也可能拆出来不同的模型请求但对业务方来说它们属于一个场景网关必须在一个流程模板里串起来。第二是数据分级管控。同一个接口里有的字段可以出内网有的字段只能留在院内私有化模型。网关必须定义数据分级标签根据标签决定请求路由到哪一类模型服务。这个维度在医疗场景里不能省否则即使模型能力再强合规上也会出问题。第三是业务优先级和容错级别。导诊并发高但对延迟容忍度略高用户输出一个小转圈可以接受影像报告生成并发低但对格式正确性要求极高宁可慢一点也不能输出错误内容。每个场景都要明确自己的可靠性等级网关配置和模型选型都跟着这个等级走。第四是模型准入和替换机制。同一个业务场景不可能绑定一个模型一辈子半路换模型是常态。网关必须提供“模型能力描述”和“场景需求描述”匹配机制新模型上线前先跑一组内置评测通过后才被路由层接受。这四个维度最终都会落实到三张配置表上路由表决定请求去哪里策略表决定请求怎么被检查和改造模型表决定哪些模型处于可用状态。日常运营工作基本就是在维护这三张表。规划维度需要考虑的问题网关配置动作场景抽象一个业务动作包含几步模型调用是否串联校验定义场景flow模板数据分级哪些字段敏感、哪些字段只能走私有化模型设置字段标签和路由约束业务优先级导诊要并发、报告要准确超时容忍不同配置超时阈值、重试策略模型替换新模型是否胜任该场景如何快速切换内置评测集、回退配置3. 典型医疗场景的拆解与实现3.1 场景一智能导诊与预问诊智能导诊是很多医疗AI项目第一个做演示的场景但它的坑也最多。患者输入“我头疼恶心两天了还有点发烧”系统要推荐科室还要追问几个关键问题补充病史。需求不复杂但直接调用模型很容易出现科室乱推荐、追问无逻辑的问题。我在MAI Gateway里把导诊流程拆成固定五步先做内容脱敏再判断有没有需要走急症通道的紧急词之后调用分诊模型用JSON Schema约束输出结构最后校验科室合法性和置信度必要时触发人工确认。脱敏这一步容易被忽略但患者可能直接在输入里泄露姓名和电话如果不处理这些信息会跟着请求一起进入模型日志。配置上我用类似下面这样的模板。紧急词命中就直接跳转急症提示不继续走正常分诊置信度阈值也放在这里低于0.7的输出不能作为唯一推荐结果。scenes: triage: llm_router: primary: private_med_llm fallback: cloud_med_llm input_policy: pii_mask_enabled: true emergency_words: - 胸痛 - 呼吸困难 - 意识不清 - 剧烈头痛 output_policy: require_json_schema: true schema_id: triage_result_v2 min_confidence: 0.7 legal_departments: - 呼吸内科 - 心内科 - 神经内科 - 消化内科 - 儿科 - 急诊科这套配置跑起来之后最值得说的经验是科室名称纠偏。模型经常输出“内科”“心血管科”但院内真实科室名称可能是“呼吸与危重症医学科”“心血管内科三病区”。直接拿模型输出去挂号系统必然失败所以网关里必须维护一张院内科室别名映射表。另外分诊结果不要只返回一个科室很多患者主诉对应多个疑似方向比如“头痛伴发热”可能是神经内科也可能是感染科网关应该支持“首诊科室转诊考虑科室”的排序结构而不是用一枚印章拍死。3.2 场景二临床辅助决策与知识问答辅助决策这类场景风险级别高我的设计原则是模型只做信息组织和表述真正的知识依据必须来自可追溯的知识库。比如医生问“患者有糖尿病肌酐120二甲双胍还继续用吗”如果模型直接从参数知识里凭记忆作答风险极大正确做法是先从院内指南库和检验说明里检索到相关片段把片段组装进上下文再让模型基于片段做判断。在网关里这个过程体现为“检索-增强-生成-引用校验”。拿到医生问题后第一步去向量知识库检索最相关的若干段第二步把检索结果和原始问题一起拼装第三步调用模型生成回答第四步做引用校验确保回答里的关键结论能在检索片段中找到出处找不到就降低结果的展示权重。这个校验动作放在业务系统里实现非常吃力但放在网关策略层是顺理成章的事。rag_config { top_k: 5, score_threshold: 0.65, max_context_chars: 20000, source_display: True, ref_check: True }我踩过的一个明显坑是试图把整份临床指南塞进提示词。模型接收的内容太长之后注意力会被无关段落稀释反而容易忽略最关键的禁忌信息。后来改成先检索再截断只把最相关的四五段送进上下文生成的回答贴合度明显提升。知识库版本管理也必须纳入网关指南更新后要能按版本生效医生看到回答时最好能看到引用的指南版本编号。这类输出的最后一行我会让模板强制加上“仅供参考请结合患者实际情况和临床判断决定”这句话不是摆设是给医生一个明确的使用边界。3.3 场景三影像报告生成与结构化影像报告生成不是让模型直接看CT片多数医院实际落地场景是两类把放射科医生写在草稿里的自由文本变成结构化字段或者把结构化测量数值生成一段自然语言报告。这两类都适合放在AI网关里处理因为核心难点不在模型格式而在术语统一、单位校验和字段完整性。比如医生录入“右上肺见15mm磨玻璃结节”模型把它提取成结构化字段时方向、部位、大小、性质都是独立字段。但模型可能把“右上肺”写进标准术语表之外的“右肺上叶”或者把15mm后面擅自加上“cm”这些都属于必须在网关阶段拦截的错误。我一般会在策略层加两道校验解剖位置必须命中原生术语表测量值必须带合法单位任何校验不通过的结果都标记为“待人工修改”而不是直接返回临床。配置示例可以看下面这一段简化规则field_validation: laterality: allowed: [左, 右, 双侧, 未明示] lung_lobe: allowed: [右上叶, 右中叶, 右下叶, 左上叶, 左下叶, 舌段] measurement: unit_required: true valid_units: diameter: [mm, cm] volume: [cm3, ml]报告生成和自由文本结构化对模型输出的要求差异很大前者要格式严谨后者要召回全面。自由文本抽取时我习惯用“先过分割再归一”的方案第一轮让模型把长句拆成若干个原子事实第二轮再把每个事实映射到标准术语。直接让模型一次性输出结构化结果很容易漏掉隐藏信息比如“右肺上叶见结节大小约15mm边缘欠光滑”里边缘特征是独立字段但放在自然语言里只是一个定语模型容易丢。这个场景里我另一个体会是模板版本管理非常重要。影像报告模板经常调整如果模板变了而网关配置没同步更新生成的报告格式还是老版放射科医生就要做大量重复修改。所以模板版本号必须写进网关的场景配置并且跟院内报告系统保持一致最好由信息科统一发布。3.4 场景四患者服务与健康宣教患者服务类的场景流量大、问题杂但安全底线同样很高。患者会问术后注意事项会问复查时间会问某个药应该怎么吃甚至会拿自己在网上搜到的一知半解来反问。这个场景里网关做的事情是维护多轮会话状态、对高敏感问题做强制转人工、对药品剂量类提问做硬性拦截。多轮会话状态必须放在网关层不能每次调用都让患者重新交代一遍背景。我会用Redis存会话上下文设置过期时间和最大轮次数既保证连续性又防止会话无限拉长。药品剂量问题我处理得比较保守只要提问内容命中常见药名加剂量词比如“mg”“克”“片”“粒”网关直接返回“请遵医嘱不建议根据网络信息自行调整用药”同时给后台推送一条人工接管提醒。这个拦截动作必须有因为模型就算知识再全也不掌握患者完整的肝肾功能和过敏史直接给剂量就是风险。conversation: ttl_seconds: 1800 max_turns: 20 session_store: redis guard_rules: - pattern: (mg|克|片|粒|单位) action: block_and_human reply_template: 请遵医嘱用药如需调整请咨询主治医生。 notify: true健康宣教最容易踩的坑是“听起来很合理但实际不对”。比如患者问“术后能不能喝鸡汤”模型的常识回答是“可以适量”但具体到某个术后第一天禁食的病例这个答案就是错的。所以我要求宣教场景的回答必须绑定知识库内容知识库没有覆盖的问题直接说“不太确定建议咨询医生”不允许模型自由发挥。在这个场景里谨慎比聪明更重要能够拒绝回答也是一种有价值的输出。4. 部署与配置实操从第一台机器到生产环境4.1 基础架构与组件选型我在生产环境里跑通的最小可靠架构包含四种组件一个无状态网关服务一组Redis实例承担会话与缓存一组PostgreSQL存储审计日志再加一个向量库支撑知识检索。网关服务本身建议至少部署两个副本前面挂负载均衡内部不保存业务状态任何一台宕机都可以被无缝替换。这个架构看起来不复杂但“不复杂”本身就是选择它的理由。医疗行业的运维力量普遍没有互联网公司那么强你上一套庞大的微服务平台看起来功能很多最后大概率是没人会维护。我倾向于先跑通一个所有核心组件都能满足的最小集合等业务规模真正上来了再横向扩展。组件选型上网关优先选择有成熟插件机制的开源方案或者直接基于通用网关二次开发把医疗策略写成插件挂在路由前后。后端模型可以接三类上游医院内网私有化部署的模型服务、云厂商API服务、院内已有的算法服务。网关的价值就是给这三类上游统一成一套内部接口业务方完全不需要区分这次请求到底被转发到了哪个模型。4.2 关键配置模型路由、API Key管理、缓存、限流模型路由配置是整个网关最核心的配置项。下面给出一个简化但完整的示例体现“按场景设置优先和备用模型”的思路providers: - name: private_med_llm endpoint: http://10.20.5.18:8000/v1 models: [med-base-72b] priority: 1 - name: cloud_med_llm endpoint: ${CLOUD_ENDPOINT} api_key_env: CLOUD_API_KEY models: [med-cloud-large] priority: 2 routes: triage: primary: private_med_llm/med-base-72b fallback: cloud_med_llm/med-cloud-large report_generation: primary: private_med_llm/med-base-72b fallback: 密钥管理有一条原则必须坚持业务系统拿到的只是网关侧的调用票据模型上游的密码只存在网关环境变量或者密钥管理系统里不允许业务方直接持有。业务系统持有模型密钥的最大问题是一旦密钥泄漏你连出事范围都说不清楚。轮换机制也要设好医疗项目周期长密钥定期换一次是基本操作。缓存配置也很有讲究。门诊导诊里大量重复问题可以直接缓存但缓存key不能只拿原始文本拼接最好用“场景标识脱敏后的输入模型版本”的组合。只认原始文本会导致两个问题患者输入里带了多余空格或标点时缓存不命中模型版本更新后缓存了旧答案。加上场景标识和模型版本能让缓存粒度更合理。限流要分场景设计。导诊并发高但每次请求轻报告生成并发低但耗时长两者不能共享一个限制阈值。拿导诊场景举例假设门诊日量5000平均每个患者触发3次导诊请求一天就是15000次导诊集中在上午8点到下午4点共8小时平均每秒约0.5次取峰值系数4大概峰值2次每秒。设计限流阈值5次每秒就已经足够还给模型故障后的重试留了空间。报告生成场景则更适合限制并发数比如同时最多只允许20个生成任务。场景日调用量估算集中时段设计QPS网关超时智能导诊15000次8小时530s影像报告生成500份医生手动触发并发2060s健康宣教2000次全时段215s4.3 与医院现有系统的集成AI网关要真正发挥价值必须跟院内业务系统打通而不是在业务旁边单独架一个孤岛。常见的集成对象包括HIS、EMR、集成平台、挂号系统数据交互方式以接口为主。我的做法是尽量不直连数据库优先走院内集成平台提供的服务接口或者消息队列把网关作为消费者挂上去。患者身份处理时网关只负责转发一个“匿名会话令牌”真实身份映射关系由网关内部维护。业务系统传给网关时可以使用临时token网关给模型侧再生成一次匿名标识这样链路任何一个环节的日志都不会同时包含患者的姓名和疾病信息。这件事看起来只是多一层转换实际项目里却经常被忽略导致脱敏工作只做了表面文章。模型服务的网络部署也要分级处理。涉及核心病历数据的场景一律走内网私有化模型只有明确不包含敏感字段的请求才允许转发到云上模型服务。医疗数据出域必须经过院内正式评估和决策不能因为模型在云端效果更好就直接默认允许这是底线。集成对象集成方式网关动作典型数据流分诊系统HTTP接口鉴权脱敏路由主诉→网关→分诊模型→科室推荐HIS集成平台MQ消息解析会话关联挂号信息→触发导诊会话EMRWebservice数据映射RAG检索病历片段→知识检索→辅助参考随访系统批量接口场景鉴权限流患者列表→宣教问答→回写结果5. 常见问题与排查心得5.1 请求超时和并发问题的处理接触过的医疗AI项目里上线初期出现最多的问题是超时。医生端在患者面前等了半天报告出不来患者端导诊一直转圈这种场面只要出现几次业务方对系统的信任感就没了。我先强调一个认知大模型请求不能用普通HTTP接口的超时预期去设置。模型生成是以token为单位的一个中文汉字大约就是一个token模型生成速度通常在每秒100到150个token之间。一段500字的回答有大概650个token生成耗时就需要4到6秒再加上排队和网络开销前端给30秒以上是合理的。有些场景比如报告生成我给到60秒依然能跑得通关键是要配合流式输出让前端先看到部分内容而不是干等最终结果。排查超时也有一个固定套路从网关日志里拉出两个时间戳一个是网关开始转发给上游模型的时间一个是上游模型返回的时间。两者差值大说明瓶颈在上游模型服务两者差值小但整体耗时长说明瓶颈在网关排队或者网络层。加上这两个时间点之后很多争论就自动平息了。# 简化排查命令思路 grep triage gateway-access.log \ | awk {print $request_id, $start_forward, $return_back, $total_time} \ | sort -k4 -nr | head -205.2 模型输出不稳定的应对模型输出问题不是“提示词写得好”就能完全解决的。我总结下来最高效的应对组合是强制输出格式、低温度参数、失败自动重试和规则兜底四者缺一不可。强制输出格式要依赖网关的输出校验模块明确要求JSON模式并校验字段类型。模型输出一旦不符合Schema系统自动重试一次并把重试结果做对比而不是直接把错误返回给业务方。温度参数在医疗场景里我一般调到0.2以下追求确定性和一致性不太需要太多创造性回答。规则兜底是最后一道防线比如导诊场景科室名称不合法时宁可返回“建议至导诊台人工咨询”也不能把模型自行拼出来的科室名返回。这套组合实操下来能把畸形输出率从百分之几降得非常低用户体验会有明显改善。5.3 数据合规和隐私保护的经验数据合规不能只停留在代码逻辑上还要体现在日志和人员权限里。网关默认不记录完整姓名、身份证号、手机号和详细住址只保留脱敏后的哈希值用来做关联分析。日志检索页面也要做脱敏展示运维人员看到的患者信息永远是被掩码的这样在需要排查问题时既有关联线索又不泄露明文信息。最小化传参是另一个我很看重但经常被忽略的点。导诊只需要年龄、主诉和持续时间那就不要把患者的婚姻史、过敏史、家族史全部传给模型。字段越少潜在暴露面就越小出事后需要排查的链路也越短。设计场景模板时就要想清楚“本次动作最少需要哪些字段”而不是图省事把整个病历对象都传过去。权限管理也要做分离。普通业务人员可以查看调用统计和报表但只有信息科指定人员能修改脱敏规则和路由策略。临床科室提需求可以直接改网关安全策略不行这中间必须有一个明确的职责边界。5.4 可观测性与全链路追踪医疗AI网关一旦投入生产可观测性就是救命稻草。我只关注三个层面的指标网关层的请求量、错误率、排队时长模型层的Token消耗、模型耗时、输出字符数业务层的回答采纳率、人工接管率、科室分布。三个层面独立统计必要时按请求ID串联起来。工具上Prometheus加Grafana做指标展示OpenTelemetry做链路追踪已经是比较成熟的组合。我实际碰到的经典案例是某个分诊场景的成功率突然下降业务方第一反应是模型不行了。后来从网关指标看到排队时长持续偏高再追踪到上游模型服务延迟从2秒涨到8秒触发路由规则自动切换到备用模型后排队时长回落成功率跟着恢复。整个过程没有改一行业务代码这就是把策略沉淀在网关层的价值。我在实际巡检时还有一个习惯每周看一次按场景分桶的Token消耗和回车率对比上周数据找异常。某个场景调用量突然翻倍背后可能不是好事也许是循环调用也许是页面问题主动发现总比被动响应要好。最后再分享一点个人体感做医疗行业AI网关让我最意外的是真正花时间最多的事情不是把模型接进来而是把不合适的回答挡在外面。分诊里的低置信度转人工宣教场景对剂量问题的硬拦截报告生成里的单位校验本质上都是在做一台“有边界感的交换机”。人工智能能不能真正服务患者不只看模型聪明不聪明还看病人在面对回答时有没有兜底机制。这套边界跑顺之后再回头调模型效果你会觉得比想象中简单得多因为所有质量问题都已经有了明确的责任接口和逃生通道。