过去一年不少健康科技团队都在做同一件事把大模型接进客服、接进病历、接进健康问答。但接上模型不等于变成一家 AI-Native 公司。AI-Native 健康公司不是“用了 AI 的公司”而是从数据采集、临床工作流到用户服务路径都按照 AI 的能力边界重新设计的公司。这两者的差别短期看只是工程架构不同长期看是团队能不能把 AI 变成可评估、可迭代、可退出的核心能力。这个判断来自 Maven Clinic 的一场工程主题分享。Maven Clinic 是数字健康领域的代表公司之一聚焦女性健康和家庭健康把虚拟问诊、护理导航和个性化健康方案整合在同一个平台上。在“How to build an AI-Native Health Company”这个主题下真正值得关注的不是某个模型又提升了多少分而是健康公司到底要怎么搭建数据底座、临床工作流、合规体系和评估闭环。对开发者来说这篇文章的读法不是“理解一个新概念”而是把它拆成可落地的工程模块。读完你会得到一套构建 AI-Native 健康公司的完整思路健康数据怎么标准化、AI 工作流怎么编排、知识库和 RAG 怎么接入、合规与审计怎么做、AI 上线后怎么评估和回滚。文章里的代码和配置都以最小可运行示例为主方便你迁移到自己的项目里验证。1. 这篇文章真正要解决的问题健康领域的 AI 落地难的不是模型效果而是系统上下文。一个通用大模型可以做问答但如果它不知道用户目前的孕周、过敏史、正在服用的药物它的回答就是“正确但没用”。如果它知道这些信息却拿不到最新的临床指南或者拿到的内容无法追溯到来源那它又变成了“有用但不敢用”。这就是健康行业做 AI 和通用行业做 AI 的最大区别健康 AI 的输出会直接影响用户的医疗决策系统必须同时满足数据准确、知识权威、过程可追溯、结果可复核这四个条件。很多项目卡住不是模型选得不好而是这四个条件没有一个在架构层面被提前设计进去。本文要解决的问题可以概括为三件事第一把 AI-Native 从营销词变成工程框架。我会明确告诉你什么是真正的 AI-Native 健康公司它和“用了 AI 的传统健康公司”在架构上有什么区别。第二给出一套可执行的路径。从 FHIR 数据建模到工作流编排再到 RAG 知识增强、合规审计、评估回滚每个环节都有配置或代码示例。第三帮你避开健康 AI 最常见的坑。包括“什么都想让 AI 做”“知识库不设引用来源”“没有人工兜底节点”“没有任何灰度回滚方案”等。如果你是医疗健康方向的工程师、架构师、AI 产品负责人或者你所在团队正准备把大模型接入医疗健康业务这篇文章很适合你。如果你只是想看某个模型跑分那这篇文章不是你要找的方向。2. AI-Native 健康公司概念边界与核心判断AI-Native 这个概念最近两三年出现频率很高。但不同的人说出来的含义完全不同。有人把它理解成“产品里有 AI 功能”有人理解成“公司全员用 AI 提效”还有人理解成“模型驱动业务”。从工程角度看AI-Native 健康公司更接近最后一种但还要更进一步。一家 AI-Native 健康公司不是所有业务流程都必须由 AI 完成而是整个系统的数据流、决策流、反馈流都围绕 AI 的输入和输出重新设计。换句话说AI 不是贴在业务外面的插件而是业务系统的基础设施。为了说清楚这个边界可以先看一组对比阶段典型特征架构表现扩展性AI-Enhanced在现有产品上增加 AI 问答、摘要功能AI 接口与核心业务系统松耦合甚至只做调用功能演示容易深入业务困难AI-First产品优先考虑 AI 能做什么再设计交互AI 是核心交互方式但业务流程本身仍以确定性逻辑为主适合通用场景复杂医疗场景容易失控AI-Native数据、工作流、审核、评估为 AI 重新设计AI 深度嵌入业务闭环有完整的上线、审核、回滚机制能形成持续迭代的核心壁垒这个表不是要做“阶段越高越好”的简单判断而是帮助你定位团队当前的架构。很多数字化程度很高的健康机构目前也只是 AI-Enhanced。这不丢人但如果目标是把 AI 变成业务增长的长期驱动力早晚要往 AI-Native 靠。为什么健康行业特别适合 AI-Native而不是停留在 AI-Enhanced因为健康业务的核心不是单次交互而是连续的服务路径。一个用户从孕期建档、产检提醒、症状咨询、用药安全到产后护理中间会经历大量节点。只有把这些节点变成结构化数据AI 才能理解“这个人现在处于什么状态”而不是每次都从零开始回答。也只有把这些节点的决策过程记录下来医生和运营团队才能知道 AI 在哪一步建议得对、哪一步建议得可疑。我的核心判断是AI-Native 健康公司 数据标准化 × 工作流编排 × 评估闭环。这三个条件必须同时成立缺一个都会回到“演示效果好、上线不敢用”的状态。后面几个章节我会按这个框架逐层展开。3. AI-Native 健康公司的整体架构AI-Native 健康公司在架构上不是只有一个大模型。它更像一个由多个模块组成的系统大模型只是其中的推理组件。拆开看一个可落地的 AI-Native 健康公司至少包含四层。第一层是数据底座层。负责接入电子病历、检验检查结果、可穿戴设备数据、用户自报症状、历史服务记录等。这一层的关键不是存得越多越好而是把多源数据统一成标准结构。健康行业里最常用的标准是 FHIR下一章会专门讲。第二层是知识与推理层。包括临床指南、药品说明书、院内制度、知识库向量化后的检索服务以及大模型生成服务。这一层解决“AI 用什么知识回答”的问题。知识不权威模型再强也白搭。第三层是工作流编排层。负责把一次用户请求拆成多个步骤例如意图识别、数据检索、知识召回、答案生成、规则校验、人工审核。编排层决定 AI 在什么时候可以做主、什么时候必须转人工。第四层是交互层。包括 App 内的健康问答、医生工作台的患者摘要、运营后台的风险预警等。交互层不是简单聊天而是把 AI 的产出嵌入到用户触点和临床工作流中。除了这四层还需要三个横切能力安全合规、可观测、评估回滚。它们不是单个模块而是贯穿所有层的机制。例如一次 AI 健康问答合规层要记录“哪个用户、哪个模型版本、用了哪些资料、是否转人工”可观测层要把这些日志关联起来评估回滚层则决定当前模型版本是继续服务还是切回旧版本。我把各层的关键组件整理成一张表层级核心组件关键职责常见技术数据底座层FHIR 资源服务、数据管道、主数据管理统一患者身份、标准化临床数据FHIR Server、Kafka、Flink知识与推理层向量库、知识库索引、LLM 推理服务提供权威资料、生成可追溯回答Milvus、pgvector、vLLM工作流编排层编排引擎、规则引擎、人工审核平台控制流程、设置护栏、人工兜底Temporal、Argo Workflows交互层用户端、医生端、运营端嵌入实际业务触点Web、小程序、医生工作台横切能力审计、监控、评估、开关保证合规、可观测、可回滚Prometheus、ELK、自研评估服务如果你所在的团队还很小不必一开始就建设全部层级。但架构上要预留位置。最怕的是只做了交互层和推理层数据底座、编排层、审计能力全部缺失结果模型一上线没人能回答“这个回答的依据是什么”。4. 数据底座FHIR 与健康数据建模示例健康数据建模是整个 AI-Native 健康公司最枯燥但最重要的环节。很多团队在这上面偷懒直接把大模型接在原始病历文本上结果每次回答都像抽卡因为模型读到的上下文不稳定。要解决这个问题需要一个稳定的数据模型。FHIRFast Healthcare Interoperability Resources快速医疗互操作资源是目前健康行业比较通用的数据交换标准。它的核心思路是把现实世界的健康信息拆成一个个资源类型比如患者是 Patient、化验检查是 Observation、诊断是 Condition、用药是 MedicationRequest。每个资源都有标准字段和编码体系这样不同系统之间交换数据时大家说的是同一种语言。FHIR 不是解决所有健康数据问题的万能钥匙但作为数据底座是一个稳妥起点。至少它解决了三件事资源边界清晰、字段语义统一、时间关系明确。下面用患者和妊娠周期两个最小示例演示一下 FHIR 长什么样。患者资源{ resourceType: Patient, id: patient-001, identifier: [ { system: https://clinic.example.org/mrn, value: MRN20240001 } ], name: [ { use: official, family: Zhang, given: [Xiaoyu] } ], gender: female, birthDate: 1992-04-18 }孕周观察记录{ resourceType: Observation, id: obs-preg-weeks-001, status: final, code: { coding: [ { system: http://loinc.org, code: 11884-4, display: Gestational age } ] }, subject: { reference: Patient/patient-001 }, effectiveDateTime: 2024-11-02T09:30:0008:00, valueQuantity: { value: 24, unit: weeks, system: http://unitsofmeasure.org, code: wk } }这段代码的关键点有三个一是患者 ID 作为全局主键所有临床数据都挂在这个主键下二是孕周观察通过 code 字段里的 LOINC 编码表达语义而不是直接在文本里写“24周”三是 effectiveDateTime 记录了数据的产生时间。这三件事做好以后AI 工作流才能可靠地回答“这个用户目前孕周多少、在什么时间点产生的数据”。建议不要在项目一开始就建设庞大的数据湖仓。先把最小核心数据集做好也就是患者主索引、关键观察指标、用药记录、诊断记录、服务记录。这些足够支撑第一版 AI 健康助手。数据建模时还要特别注意隐私边界并非所有字段都能进入 AI 上下文后面合规章节会展开。5. 工作流编排从规则引擎到 AI Agent数据底座建好之后下一步是把 AI 放进业务流程。健康业务里的 AI 编排和通用客服机器人有个很大区别健康场景往往不是一次对话而是一条任务链。比如用户问“怀孕期间用药安全”系统需要先确认孕周再查药品信息再匹配禁忌症最后决定是直接给结论还是转人工药师审核。如果把这些步骤全部交给一个 Agent 自由发挥安全性很难保障。更稳妥的做法是先用编排引擎把流程固定下来再在关键节点上放模型决策能力。这也是当前健康 AI 落地更现实的路径先固化流程后让 AI 在流程内做决策。下面是一个护理导航工作流的最小配置示例workflow: prenatal_medication_safety version: 1.0.0 owner: team-clinical-ai nodes: - id: input_normalize type: transform next: triage - id: triage type: intent_classification provider: llm params: model: health-medical-intent-v2 threshold: 0.7 next: retrieve_guideline - id: retrieve_guideline type: tool name: fhir_observation_lookup params: resourceType: Observation code: gestational-age next: rag_generation - id: rag_generation type: rag_query params: knowledge_base: medication_safety_kb top_k: 5 min_score: 0.65 next: clinical_review - id: clinical_review type: rule_check rules: - if: contains_drug_blacklist true then: type: human_review reason: high_risk_drug - if: confidence 0.6 then: type: human_review reason: low_confidence next: response_policy - id: response_policy type: policy params: always_include_sources: true disclaimer: true这个 YAML 展示的并不是一个可直接部署的语法而是一种编排思路。每个节点都有自己的职责triage 负责判断用户意图retrieve_guideline 负责从 FHIR 服务拿结构化数据rag_generation 负责从知识库检索并生成答案clinical_review 是规则校验节点命中高风险药物或模型置信度不够时强制转人工最后的 response_policy 负责统一附加来源和免责声明。这个流程里最核心的设计是人工兜底。健康场景不能接受“模型自信地给出错误答案”。所以工作流编排层必须设置护栏触达风险词、数据缺失、置信度不足等条件时自动跳转人工。宁可让用户多等几分钟也不能让错误答案直接送达。另外一个容易被忽略的工程点是可观测。每个节点都需要记录输入、输出、耗时、调用模型版本、关联的 trace_id。否则一旦线上出问题你会发现连复现现场都很困难。6. 知识增强RAG 在健康场景的正确用法大模型在健康场景的最大问题不是“不会回答”而是“容易一本正经地编造”。医疗健康领域对知识权威性和事实准确性要求非常高直接让大模型凭训练记忆回答是不负责任的做法也会带来严重的合规风险。解决办法是 RAGRetrieval-Augmented Generation检索增强生成。它的思路是不让模型凭记忆生成而是先从权威知识库检索相关资料再让模型基于资料回答。这样既借用大模型的推理和表达能力又把回答限制在可控的知识范围内。健康领域 RAG 的完整流程可以拆成五步查询改写、知识召回、重排、生成、引用输出。查询改写是为了把用户口语转换成适合检索的医学表达知识召回从向量库中找出相关内容重排是为了让最权威、最相关的资料排到前面生成时模型被要求“只能依据资料回答”最后输出时必须带上引用来源。下面是健康知识问答 RAG 的最小 Python 示例import os from openai import OpenAI from sentence_transformers import SentenceTransformer # 请替换为实际项目中的部署方式 embedder SentenceTransformer(BAAI/bge-small-zh-v1.5) client OpenAI(api_keyos.getenv(LLM_API_KEY)) def retrieve(query: str, top_k: int 5, min_score: float 0.65): query_vec embedder.encode(query) # vector_db 在真实项目中可替换为 Milvus / pgvector 等向量数据库客户端 hits vector_db.search(query_vec, top_ktop_k) return [h for h in hits if h.score min_score] def generate_answer(question: str) - dict: hits retrieve(question) if not hits: return { answer: None, refuse: True, reason: guideline_not_found, } context \n\n.join( f[{h.doc_id}] {h.text} for h in hits ) prompt f 你是健康科普助手只能根据给定资料回答。 如果资料不足或与问题无关请明确说“无法根据现有资料回答”。 ## 资料 {context} ## 问题 {question} resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messages[{role: user, content: prompt}], temperature0.2, ) return { answer: resp.choices[0].message.content, sources: [h.doc_id for h in hits], refuse: False, }这段代码有三个值得注意的地方。第一检索结果设置了 min_score 阈值低于阈值就拒答。这个设计比“强行生成”安全得多。健康问答中用户最讨厌的不是被拒答而是被错误引导。第二提示词明确要求“只能根据资料回答”并且资料块带编号。这样做一方面降低幻觉概率另一方面为输出引用来源做准备。第三temperature 设置得很低。健康科普场景稳定优先不需要创造性回答。模型在健康场景的任务是“忠实表达资料”不是“发挥想象力”。RAG 在健康场景最大的工程坑是知识库本身的质量。如果放进向量库的 PDF 本身来源不明、版本过旧、翻译错误那 RAG 只是把错误知识变得更流畅危害更大。所以知识库建设必须配套严格的入库审核机制每个文档要有来源机构、发布版本、更新时间、审核人。7. 安全合规与可观测健康 AI 的生命线健康数据是高度敏感的个人信息。做健康 AI技术和医学问题之外还有合规问题。不同国家和地区对医疗健康数据的合规要求差异很大例如有些地区要求数据出境评估有些要求用户明确授权。具体规则必须咨询法务和合规团队不能照搬别人的结论。但从架构层面有一些通用原则是可以提前设计的。数据最小化、访问最小化、全链路审计、模型版本可回溯这些不依赖特定法律条文属于普适工程原则。数据最小化的意思是AI 系统只需要拿到完成当前任务所需的最少字段。比如评估用药安全可能需要孕周、药品名、过敏史但用户收货地址、支付信息就不应该进入 AI 上下文。在代码层面应当在数据接入模型之前做字段过滤而不是把所有数据直接拼进 prompt。访问最小化包括几个方面不同角色权限不同医生能看临床原始数据AI 工程师只能看脱敏日志运营人员只能看统计报表。所有访问都要走统一网关避免通过数据库账号直接连生产库抓数据。以下是一个健康 AI 请求的审计日志示例{ event_id: audit-20241107-001, tenant_id: clinic-main, actor: { type: patient, id: user-0092 }, action: chat.completion, resource: { type: health_question, risk_level: medium }, model: { name: health-medical-intent-v2, version: 2024.11.1 }, trace_id: trace-8f3a91, request_hash: sha256:..., response_hash: sha256:..., human_review_required: false, timestamp: 2024-11-07T10:12:33Z }为什么说这类日志是健康 AI 的生命线因为一旦出现医疗纠纷或用户投诉你必须在几小时内回答“这条回答是怎么生成的、凭什么是这个答案、有没有人工审核”。如果日志里没有模型版本、没有知识来源、没有 trace_id这个问题的答案就无从谈起。审计日志不是写给监管看的也是写给自己的事故复盘和模型迭代用的。除了日志安全合规层还要做静态传输加密、敏感字段加密存储、密钥管理、备份恢复演练。健康 AI 项目里安全不是上线前补一次渗透测试就算完成而是每次模型发布时都要过的关卡。8. 效果评估与发布回滚让 AI 安全上线健康 AI 上线最忌讳的事情是“模型离线跑分不错就直接全量上线”。健康场景的评估体系远比通用 NLP 跑分复杂。它不仅要看答案对不对还要看答案会不会误导用户、该拒答时是否拒答、出现不确定信息时是否如实说明。我建议健康 AI 团队至少建立以下五类指标指标衡量内容说明事实一致性回答与知识库资料是否一致由临床专家对抽样结果进行标注临床安全性高风险场景是否触发转人工重点关注误答造成风险的比例拒答正确性该拒答时是否拒答过度拒答影响体验拒答不足有风险引用准确性回答内容与引用来源是否匹配防止“答得对但引用了无关资料”用户体验用户是否完成服务路径如是否从问答进入问诊或护理方案这些指标不能完全靠自动评测完成。我的建议是每次模型发布前从历史用户问题中抽取 200 到 500 条典型样本由临床专家进行标注形成回归集。自动评估负责快速筛掉明显问题人工专家评估负责最终放行。下面是一个最小化的评估脚本示例用于计算单个样本的拒答正确率和不安全表达率def evaluate_sample(question, answer, refute, expected): metrics { refuse_correct: expected.get(should_refuse, False) refute, contains_uncertain: 无法根据现有资料回答 in answer, contains_safety_note: (请咨询医生 in answer) or (线下就诊 in answer), } return metrics samples [ { question: 孕期可以吃布洛芬吗, answer: 根据现有资料孕期使用布洛芬需要谨慎。建议先确认孕周并咨询产科医生后再决定是否使用。, refute: False, expected: {should_refuse: False}, } ] for s in samples: print(evaluate_sample(**s))这个脚本很简单但体现了健康 AI 评估的正确思路不能只问“模型回答是否通顺”要问“该拒答时有没有拒答”“有没有给出就医提示”。发布策略建议采用三阶段灰度。影子模式AI 在线上运行但回答不直接展示给用户而是与人工回答并行对比。这个阶段主要用于收集真实数据评估 AI 与现有服务的差距。灰度模式AI 回答展示给 5% 到 10% 的用户同时保留人工兜底。如果风险指标超过阈值立即拉回全部流量。全量模式AI 开始服务全部用户但保留一键回滚能力。模型版本、知识库版本、提示词版本全部可回溯。记住健康 AI 的灰度不是“流量百分比”那么简单。它必须包含人工审核节点的承接能力。如果 AI 把 30% 的请求转给人工而人工团队只有处理 5% 请求的能力那么上游 AI 就绝对不应该灰度到 30%。9. 常见问题与排查思路健康 AI 项目里有一些问题出现频率很高很多团队在排查时走弯路。这里整理成一份可收藏的排查表。问题现象可能原因排查方式解决方案同一问题两次回答完全不一致温度参数过高或 prompt 不稳定查看请求日志中的 temperature 和模型版本降低 temperature固定 prompt 版本AI 回答引用了无关资料知识库文档切块不准确或重排策略缺失检查召回结果查看重排得分优化文档切块增加重排模型该转人工的请求没有转人工规则节点条件漏配或模型置信度判断错误查看编排日志定位 clinical_review 节点补充风险词规则降低转人工阈值用户问简单问题却频繁拒答向量检索召回分数整体偏低检查知识库文档质量和查询改写结果补充同义改写优化检索模型某个用户的所有请求都失败用户数据缺失导致 FHIR 查询异常查看 trace_id 关联日志增加数据完整性校验和失败兜底模型回答内容过时知识库版本没有随指南更新检查知识库发布记录建立知识库版本管理和定时更新机制上线后人工审核积压灰度流量超过人工处理能力查看审核队列长度和 AI 转人工比例降低灰度比例增加自动拒答策略遇到问题时第一件事永远不是改 prompt而是查日志。确认用户请求走完了哪些节点、每个节点的输入输出是什么、模型版本是什么、用了哪些资料。有了这些信息80% 的问题都能快速定位。健康 AI 的落地路径我建议从小场景开始。不要一开始就做一个“全科 AI 医生”那既承担不了风险也无法有效评估。从“健康知识问答”或“就诊前信息收集”这类低风险场景入手跑通 FHIR 数据、RAG、编排、审计、评估这一套闭环再逐步扩展到更复杂的护理导航和用药安全场景。团队配置上健康 AI 项目至少需要三类角色共同参与懂业务和数据的临床工作者、负责系统架构和数据流的工程师、负责模型效果和评估的算法工程师。缺了临床角色指标定义会走偏缺了工程师系统没有稳定性和可观测性缺了算法角色模型能力无法持续迭代。最后说一句我比较坚持的判断AI-Native 健康公司不是把模型换成更好的模型就能建成的它的壁垒来自数据、流程和评估体系的设计质量。与其追着模型榜单跑不如先把最小闭环里的数据标准化和评估回滚做到位。这套地基打牢之后模型升级只是替换一个推理组件而不是重构整个系统。