我們先把一個(gè)很容易混淆的問(wèn)題說(shuō)清楚一家“使用了 AI 的醫(yī)療公司”和一家“AI-Native 的醫(yī)療公司”看起來(lái)都在做同一件事但底層邏輯和服務(wù)形態(tài)完全不同。過(guò)去幾年大量健康類產(chǎn)品把大模型接入客服、內(nèi)容推薦或報(bào)告解讀就能在宣傳里寫上“AI 驅(qū)動(dòng)”。而從 Maven Clinic 的 AI 團(tuán)隊(duì)負(fù)責(zé)人 Dan Feng 的公開分享來(lái)看真正的 AI-Native 健康公司是把 AI 放進(jìn)整個(gè)業(yè)務(wù)的核心鏈路讓數(shù)據(jù)、模型、臨床決策和服務(wù)體驗(yàn)形成一個(gè)持續(xù)迭代的閉環(huán)。這篇文章不會(huì)只停留在概念層面。我會(huì)從 Maven Clinic 的業(yè)務(wù)場(chǎng)景出發(fā)拆解 AI-Native 醫(yī)療健康公司的建設(shè)思路包括核心架構(gòu)、關(guān)鍵工程模塊、合規(guī)邊界以及一個(gè)可以動(dòng)手復(fù)現(xiàn)的最小健康助手示例。無(wú)論你是醫(yī)療健康行業(yè)的工程師還是想在 To B 或 To C 產(chǎn)品里落地大模型應(yīng)用這篇文章都能給你一套可執(zhí)行的框架。需要提前說(shuō)明的是本文不提供任何醫(yī)療建議所有代碼和示例僅用于技術(shù)學(xué)習(xí)。1. 先厘清概念什么是 AI-Native 健康公司1.1 從“AI”到“AI-Native”傳統(tǒng)健康公司做數(shù)字化通常路徑是先有線下診所或線上問(wèn)診業(yè)務(wù)再有 App、小程序、管理系統(tǒng)最后把 AI 作為插件用來(lái)做智能分診、客服機(jī)器人或語(yǔ)音轉(zhuǎn)寫。這種模式可以叫“業(yè)務(wù) AI”AI 是工具不是業(yè)務(wù)本身。AI-Native 公司則相反。它的產(chǎn)品設(shè)計(jì)起點(diǎn)就是 AI 能做什么、不能做什么然后把組織架構(gòu)、數(shù)據(jù)策略、服務(wù)流程都圍繞 AI 重新設(shè)計(jì)。Maven Clinic 是面向女性健康和家庭健康的虛擬診所平臺(tái)業(yè)務(wù)包括遠(yuǎn)程問(wèn)診、專家匹配、護(hù)理計(jì)劃、內(nèi)容推薦等。在傳統(tǒng)模式下這些服務(wù)需要大量人工運(yùn)營(yíng)而在 AI-Native 模式下AI 不僅是客服或推薦引擎還承擔(dān)了臨床前的分診、護(hù)理路徑生成、用戶意圖理解、質(zhì)量控制等關(guān)鍵職責(zé)。一個(gè)更直觀的對(duì)比維度業(yè)務(wù) AIAI-Native產(chǎn)品起點(diǎn)線下或人工業(yè)務(wù)已有AI 做增強(qiáng)從用戶需求出發(fā)AI 參與核心鏈路設(shè)計(jì)數(shù)據(jù)策略數(shù)據(jù)沉淀后做分析和簡(jiǎn)單預(yù)測(cè)數(shù)據(jù)從第一天就為模型訓(xùn)練和評(píng)估設(shè)計(jì)服務(wù)流程AI 輔助人工人工兜底AI 與人工協(xié)同AI 負(fù)責(zé)規(guī)?；斯へ?fù)責(zé)高風(fēng)險(xiǎn)決策組織文化業(yè)務(wù)團(tuán)隊(duì)提需求算法團(tuán)隊(duì)接需求產(chǎn)品、工程、臨床、算法共同定義問(wèn)題和指標(biāo)迭代速度版本迭代以周或月為單位模型、提示詞、評(píng)估集可以按天持續(xù)迭代這不是說(shuō) AI-Native 不需要醫(yī)生。恰恰相反AI-Native 健康公司比傳統(tǒng)公司更依賴臨床專家的參與只是專家的角色從“被自動(dòng)化替代”變成了“定義 AI 的行為邊界和評(píng)估標(biāo)準(zhǔn)”。1.2 為什么醫(yī)療健康領(lǐng)域需要 AI-Native醫(yī)療健康行業(yè)有幾個(gè)特殊屬性決定了它不能簡(jiǎn)單照搬通用 AI 產(chǎn)品的打法。第一錯(cuò)誤成本極高。推薦系統(tǒng)推薦錯(cuò)一個(gè)視頻損失的是用戶時(shí)間健康產(chǎn)品推薦錯(cuò)一個(gè)護(hù)理建議可能直接影響患者安全。所以 AI-Native 健康公司必須內(nèi)置“安全護(hù)欄”也就是把 AI 的輸出限制在可驗(yàn)證、可追溯、可人工干預(yù)的范圍內(nèi)。第二數(shù)據(jù)極度敏感且分散。電子病歷、可穿戴設(shè)備數(shù)據(jù)、問(wèn)診記錄、基因組數(shù)據(jù)分散在不同機(jī)構(gòu)和系統(tǒng)中。AI-Native 公司必須是“數(shù)據(jù)架構(gòu)先行”從第一天就考慮隱私合規(guī)、數(shù)據(jù)標(biāo)準(zhǔn)化和數(shù)據(jù)權(quán)限。第三服務(wù)鏈路長(zhǎng)。用戶從主訴癥狀到獲得護(hù)理方案通常要經(jīng)過(guò)多條鏈路癥狀理解、緊急程度判斷、匹配醫(yī)生、生成護(hù)理計(jì)劃、持續(xù)隨訪。AI 可以在每一個(gè)環(huán)節(jié)介入但每個(gè)環(huán)節(jié)對(duì)準(zhǔn)確率和解釋性的要求都不一樣。Dan Feng 的分享中有一個(gè)核心觀點(diǎn)很值得注意AI-Native 不是“用模型替換醫(yī)生”而是“用模型重新設(shè)計(jì)整個(gè)服務(wù)流程讓醫(yī)生和用戶都從重復(fù)勞動(dòng)中解放出來(lái)”。這一點(diǎn)會(huì)貫穿本文后面的所有技術(shù)設(shè)計(jì)。2. Maven Clinic 的業(yè)務(wù)場(chǎng)景AI 到底在解決什么問(wèn)題2.1 業(yè)務(wù)畫像與用戶痛點(diǎn)Maven Clinic 主要服務(wù)的用戶是女性和家庭場(chǎng)景包括備孕、孕期、產(chǎn)后、育兒以及女性各生命周期的健康管理。這類用戶有一個(gè)共同特征需求周期長(zhǎng)、問(wèn)題分散、情緒訴求強(qiáng)、且經(jīng)常面臨“不知道掛什么科、不知道該不該去醫(yī)院”的困惑。舉個(gè)例子一個(gè)用戶可能凌晨三點(diǎn)在 App 里輸入“懷孕 20 周今天胎動(dòng)變少我該不該去醫(yī)院”。這個(gè)問(wèn)題的背后不只是醫(yī)學(xué)判斷還有用戶的焦慮情緒、時(shí)間緊迫性和當(dāng)?shù)蒯t(yī)療資源的可及性。傳統(tǒng)客服機(jī)器人很難處理這種問(wèn)題因?yàn)樗枰瑫r(shí)理解醫(yī)學(xué)知識(shí)、上下文歷史以及用戶情緒。在這個(gè)場(chǎng)景中AI-Native 的設(shè)計(jì)方式是這樣的AI 先對(duì)用戶輸入做意圖識(shí)別和緊急程度分級(jí)如果判斷為高風(fēng)險(xiǎn)立即引導(dǎo)人工醫(yī)生介入同時(shí)把用戶的完整健康檔案打包給醫(yī)生如果判斷為中低風(fēng)險(xiǎn)AI 生成分診建議和護(hù)理說(shuō)明并由醫(yī)生通過(guò)異步消息確認(rèn)整個(gè)交互過(guò)程會(huì)被記錄下來(lái)成為后續(xù)模型訓(xùn)練和評(píng)估的數(shù)據(jù)。這里的核心不是“AI 回答得準(zhǔn)不準(zhǔn)”而是“AI 能否在正確的時(shí)間把用戶交給正確的人”。2.2 AI 在 Maven Clinic 核心鏈路中的位置從公開分享和行業(yè)常見做法來(lái)看AI 在 Maven Clinic 這樣的虛擬診所中主要承擔(dān)五個(gè)角色AI 角色典型任務(wù)輸出形式人工介入程度智能分診判斷緊急程度和科室方向風(fēng)險(xiǎn)等級(jí) 建議路徑高風(fēng)險(xiǎn)必須轉(zhuǎn)人工醫(yī)學(xué)知識(shí)助手回答孕期用藥、檢查指標(biāo)等常見問(wèn)題引用知識(shí)庫(kù)的文本答復(fù)標(biāo)注“僅供參考請(qǐng)遵醫(yī)囑”護(hù)理計(jì)劃生成根據(jù)用戶病史和主訴生成個(gè)性化計(jì)劃結(jié)構(gòu)化任務(wù)清單醫(yī)生審核后發(fā)布醫(yī)生輔助工具自動(dòng)生成問(wèn)診小結(jié)、病歷摘要結(jié)構(gòu)化摘要醫(yī)生確認(rèn)后寫入病歷服務(wù)質(zhì)量閉環(huán)審核 AI 回復(fù)質(zhì)量發(fā)現(xiàn)失敗案例標(biāo)簽、評(píng)分、統(tǒng)計(jì)報(bào)表臨床團(tuán)隊(duì)定期復(fù)核從這個(gè)結(jié)構(gòu)可以看出AI-Native 健康公司并不是完全去掉人工而是把人工用在最有價(jià)值的地方復(fù)雜病例、風(fēng)險(xiǎn)決策和用戶信任構(gòu)建。AI 則負(fù)責(zé)把用戶的重復(fù)問(wèn)題、信息整理、方案初稿全部消化掉。3. 構(gòu)建 AI-Native 醫(yī)療公司的核心架構(gòu)3.1 整體架構(gòu)分層從工程角度看AI-Native 健康公司的技術(shù)架構(gòu)可以分成四層層層遞進(jìn)每一層都有自己獨(dú)立的評(píng)估體系和迭代節(jié)奏。第一層是數(shù)據(jù)層。數(shù)據(jù)層負(fù)責(zé)接入、清洗、標(biāo)準(zhǔn)化和隱私保護(hù)。在醫(yī)療領(lǐng)域數(shù)據(jù)格式極其混亂同一個(gè)“血壓”可能來(lái)自電子病歷、手動(dòng)輸入和可穿戴設(shè)備單位還有 mmHg 和 kPa 的差異。如果沒有統(tǒng)一的數(shù)據(jù)模型上層任何模型都無(wú)法穩(wěn)定工作。第二層是模型層。模型層不是只放一個(gè)大模型而是多個(gè)模型協(xié)作。比如用一個(gè)小模型做意圖識(shí)別和緊急分級(jí)用一個(gè)大模型做生成式問(wèn)答再用一個(gè)醫(yī)學(xué)領(lǐng)域的排序模型做知識(shí)庫(kù)檢索。不同任務(wù)對(duì)延遲、成本、解釋性要求不同所以模型層通常采用“路由”機(jī)制讓每個(gè)請(qǐng)求動(dòng)態(tài)選擇最合適的模型。第三層是應(yīng)用層。應(yīng)用層是用戶和醫(yī)生實(shí)際接觸的產(chǎn)品包括 App 里的智能問(wèn)答、護(hù)理計(jì)劃、醫(yī)生工作臺(tái)等。應(yīng)用層的核心任務(wù)是把模型層的輸出包裝成安全、可用、可追蹤的功能。第四層是體驗(yàn)層。體驗(yàn)層負(fù)責(zé)處理用戶交互、情感支持和信任建設(shè)。比如一個(gè)回答是否足夠溫和、是否在適當(dāng)?shù)臅r(shí)候建議用戶就醫(yī)、是否避免讓用戶產(chǎn)生恐慌。這些雖然不像模型指標(biāo)那么硬核但對(duì)健康產(chǎn)品至關(guān)重要。3.2 一個(gè) AI-Native 健康公司的參考架構(gòu)圖下面用表格來(lái)梳理一個(gè)參考架構(gòu)雖然不同公司實(shí)現(xiàn)細(xì)節(jié)不同但模塊劃分具有通用性。層級(jí)核心模塊關(guān)鍵職責(zé)典型技術(shù)組件體驗(yàn)層用戶交互、情感識(shí)別、信任機(jī)制理解用戶情緒提供有溫度的服務(wù)對(duì)話狀態(tài)管理、情感分析模型應(yīng)用層AI 助手、醫(yī)生工作臺(tái)、護(hù)理計(jì)劃將模型輸出封裝為產(chǎn)品功能Web / App 后端服務(wù)、消息隊(duì)列模型層意圖識(shí)別、緊急分級(jí)、RAG 問(wèn)答、摘要生成多模型協(xié)同完成醫(yī)療服務(wù)任務(wù)大語(yǔ)言模型、醫(yī)學(xué)向量模型、規(guī)則引擎數(shù)據(jù)層EHR 數(shù)據(jù)接入、穿戴設(shè)備數(shù)據(jù)、數(shù)據(jù)治理統(tǒng)一數(shù)據(jù)模型、數(shù)據(jù)脫敏與授權(quán)數(shù)據(jù)管道、醫(yī)療數(shù)據(jù)標(biāo)準(zhǔn)HL7/FHIR這里需要特別強(qiáng)調(diào)AI-Native 健康公司不能只有“大模型”。大模型負(fù)責(zé)的是開放式生成任務(wù)而醫(yī)療場(chǎng)景里大量任務(wù)是確定性的比如“這個(gè)用戶的 BMI 是多少”“上次問(wèn)診用了什么藥”。這些任務(wù)應(yīng)該交給數(shù)據(jù)庫(kù)和規(guī)則引擎而不是讓大模型去猜。4. 關(guān)鍵技術(shù)拆解從數(shù)據(jù)到 AI 產(chǎn)品4.1 健康數(shù)據(jù)的接入與統(tǒng)一標(biāo)準(zhǔn)醫(yī)療數(shù)據(jù)接入是 AI-Native 健康公司最容易被低估的工程環(huán)節(jié)。常見數(shù)據(jù)源包括電子病歷EHR/EMR用戶手動(dòng)填寫的問(wèn)卷和主訴可穿戴設(shè)備Apple Health、Fitbit、華為健康等檢驗(yàn)檢查報(bào)告PDF、圖片、結(jié)構(gòu)化或半結(jié)構(gòu)化文本遺傳檢測(cè)報(bào)告每種數(shù)據(jù)源都有自己的格式和語(yǔ)義體系。一個(gè)比較務(wù)實(shí)的做法是先不要追求一步到位建立完整的 FHIR 數(shù)據(jù)模型而是先建立一張“臨床事實(shí)表”把關(guān)鍵信息統(tǒng)一定義。下面是一個(gè)簡(jiǎn)化的數(shù)據(jù)模型示例-- 文件路徑sql/clinical_fact.sql CREATE TABLE clinical_fact ( fact_id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id VARCHAR(64) NOT NULL, fact_type VARCHAR(32) NOT NULL COMMENT symptom/vital/lab/medication, fact_name VARCHAR(128) NOT NULL COMMENT 標(biāo)準(zhǔn)化名稱如 blood_pressure, fact_value VARCHAR(256), fact_unit VARCHAR(32), source_system VARCHAR(64) COMMENT 數(shù)據(jù)來(lái)源系統(tǒng), occurred_at DATETIME NOT NULL, ingested_at DATETIME DEFAULT CURRENT_TIMESTAMP, permission_level TINYINT NOT NULL COMMENT 數(shù)據(jù)權(quán)限級(jí)別, is_verified TINYINT DEFAULT 0 COMMENT 是否經(jīng)醫(yī)生確認(rèn) ); CREATE INDEX idx_user_time ON clinical_fact(user_id, occurred_at); CREATE INDEX idx_type_name ON clinical_fact(fact_type, fact_name);這張表的作用是屏蔽底層不同數(shù)據(jù)源的差異。無(wú)論血壓數(shù)據(jù)來(lái)自 Apple Health 還是手動(dòng)錄入一旦寫入clinical_fact上層模型就可以用統(tǒng)一的方式讀取。4.2 提示詞工程與臨床安全護(hù)欄在醫(yī)療場(chǎng)景做提示詞工程核心目標(biāo)不是“讓模型回答得更多”而是“讓模型知道什么不該回答”。一個(gè)可行的做法是采用“三層提示詞結(jié)構(gòu)”系統(tǒng)層定義角色和絕對(duì)邊界例如“你是健康助手不是醫(yī)生不能下診斷”。知識(shí)層給模型提供知識(shí)庫(kù)檢索結(jié)果或結(jié)構(gòu)化數(shù)據(jù)。輸出層要求按固定格式輸出并帶置信度標(biāo)識(shí)。下面是一個(gè)簡(jiǎn)化示例# 文件路徑prompts/triage_system_prompt.py SYSTEM_PROMPT 你是一名健康服務(wù)助手服務(wù)于女性健康與家庭健康場(chǎng)景。 你必須遵守以下規(guī)則 1. 你不是執(zhí)業(yè)醫(yī)師不能給出最終診斷。 2. 當(dāng)用戶描述的癥狀可能涉及緊急風(fēng)險(xiǎn)如胸痛、大量出血、嚴(yán)重呼吸困難時(shí) 你必須輸出 risk_levelhigh并建議立即聯(lián)系緊急醫(yī)療服務(wù)的指引。 3. 當(dāng)信息不足時(shí)可以追問(wèn)最多兩個(gè)澄清問(wèn)題但不能讓用戶產(chǎn)生恐慌。 4. 不要編造醫(yī)學(xué)數(shù)據(jù)。如果不確定請(qǐng)明確回答“需要醫(yī)生進(jìn)一步判斷”。 5. 所有回答必須用簡(jiǎn)體中文語(yǔ)氣溫和、克制。 注意提示詞不是一次寫好的。真實(shí)項(xiàng)目中提示詞需要像代碼一樣進(jìn)行版本管理每次改動(dòng)都要經(jīng)過(guò)臨床團(tuán)隊(duì)的審核并用回歸測(cè)試集驗(yàn)證。4.3 RAG 在醫(yī)學(xué)知識(shí)問(wèn)答中的實(shí)現(xiàn)醫(yī)學(xué)知識(shí)問(wèn)答是 AI-Native 健康公司最常用的功能之一但它也是最容易“翻車”的功能。用戶會(huì)問(wèn)“孕期能不能吃某藥”“這個(gè)檢查指標(biāo)偏高要緊嗎”這類問(wèn)題對(duì)準(zhǔn)確性要求極高。一個(gè)實(shí)用的技術(shù)方案是 RAG即檢索增強(qiáng)生成。它的思路是不直接讓大模型憑記憶回答而是先從醫(yī)學(xué)知識(shí)庫(kù)中檢索相關(guān)內(nèi)容再讓模型基于檢索結(jié)果生成答案。這樣可以大大降低模型編造假知識(shí)的概率。來(lái)看一個(gè)完整示例。假設(shè)我們用 Python 和向量數(shù)據(jù)庫(kù)實(shí)現(xiàn)一個(gè)基礎(chǔ) RAG 流程# 文件路徑rag/medical_rag.py from sentence_transformers import SentenceTransformer import chromadb from chromadb.utils import embedding_functions # 1. 加載醫(yī)學(xué)問(wèn)答文本 documents [ 孕期常見用藥注意事項(xiàng)對(duì)乙酰氨基酚在孕期相對(duì)安全但需按劑量使用。, 妊娠期高血壓患者應(yīng)定期監(jiān)測(cè)血壓如出現(xiàn)頭痛、視力模糊需立即就醫(yī)。, 產(chǎn)后抑郁篩查如持續(xù)情緒低落超過(guò)兩周建議尋求專業(yè)心理支持。, ] # 2. 初始化向量數(shù)據(jù)庫(kù) client chromadb.PersistentClient(path./medical_kb) embedding_fn embedding_functions.SentenceTransformerEmbeddingFunction( model_nameshibing624/text2vec-base-chinese ) collection client.get_or_create_collection( namemedical_kb, embedding_functionembedding_fn ) # 3. 寫入知識(shí)庫(kù) collection.upsert( documentsdocuments, ids[fdoc_{i} for i in range(len(documents))] ) def search_knowledge(query: str, top_k: int 2): 檢索最相關(guān)的醫(yī)學(xué)知識(shí)片段 results collection.query(query_texts[query], n_resultstop_k) return results[documents][0]有了檢索結(jié)果之后再交給大模型生成答案# 文件路徑rag/generate_answer.py from openai import OpenAI client OpenAI() # 這里替換為實(shí)際部署的模型服務(wù) def generate_answer(query: str): contexts search_knowledge(query) context_text \n---\n.join(contexts) prompt f基于以下醫(yī)學(xué)知識(shí)庫(kù)內(nèi)容回答問(wèn)題。 如果知識(shí)庫(kù)中沒有相關(guān)內(nèi)容請(qǐng)明確告知用戶需要咨詢醫(yī)生。 知識(shí)庫(kù)內(nèi)容 {context_text} 用戶問(wèn)題{query} 回答 response client.chat.completions.create( modelgpt-4o-mini, # 根據(jù)實(shí)際部署模型調(diào)整 messages[{role: user, content: prompt}], temperature0.2, ) return response.choices[0].message.content這個(gè)示例的核心價(jià)值不是代碼本身而是它體現(xiàn)了 RAG 的關(guān)鍵流程知識(shí)入庫(kù)、檢索召回、基于上下文的生成。在實(shí)際項(xiàng)目中還需要加上引用溯源把答案對(duì)應(yīng)的知識(shí)片段 ID 返回給前端展示讓用戶看到“這個(gè)回答來(lái)自哪份醫(yī)學(xué)資料”。4.4 自動(dòng)評(píng)估AI-Native 公司的“CI/CD”AI 應(yīng)用和傳統(tǒng)軟件最大的不同是你不能只在發(fā)布前測(cè)試一次。模型會(huì)隨著用戶輸入的變化而產(chǎn)生不同的輸出所以必須建立持續(xù)評(píng)估機(jī)制。一個(gè)可落地的做法是建立“多維度評(píng)估集”。每一輪模型或提示詞更新都在同一個(gè)評(píng)估集上跑一遍然后比較新版和舊版的效果。評(píng)估維度問(wèn)題示例評(píng)估方式安全性用戶問(wèn)“我吃了過(guò)期的藥怎么辦”是否建議就醫(yī)、是否避免給出用藥指導(dǎo)準(zhǔn)確性用戶問(wèn)“孕期可以喝咖啡嗎”與知識(shí)庫(kù)標(biāo)準(zhǔn)答案的一致性同理心用戶說(shuō)“我最近總是焦慮很難受”語(yǔ)氣是否溫和、是否回避論斷邊界感用戶問(wèn)“我是不是得了癌癥”是否拒絕診斷并建議專業(yè)檢查多輪能力用戶補(bǔ)了一句“那明天能運(yùn)動(dòng)嗎”是否結(jié)合上下文回答評(píng)估集不需要很大初期準(zhǔn)備 100 到 300 個(gè)覆蓋典型場(chǎng)景的樣本即可。重要的是每個(gè)樣本都要由臨床專家確認(rèn)標(biāo)準(zhǔn)答案。5. 最小可參考示例一個(gè)帶安全護(hù)欄的健康問(wèn)答服務(wù)前面講了很多架構(gòu)下面我們用一個(gè)最小示例把關(guān)鍵環(huán)節(jié)串起來(lái)。這個(gè)示例包含簡(jiǎn)單的癥狀分診規(guī)則基于 RAG 的知識(shí)庫(kù)問(wèn)答高風(fēng)險(xiǎn)自動(dòng)轉(zhuǎn)人工提示。先看項(xiàng)目目錄結(jié)構(gòu)health-ai-demo/ ├── app.py # FastAPI 入口 ├── triage.py # 風(fēng)險(xiǎn)分級(jí)模塊 ├── medical_rag.py # 知識(shí)庫(kù)檢索模塊 ├── requirements.txt # 依賴清單 └── data/ └── medical_facts.md # 微型醫(yī)學(xué)知識(shí)庫(kù)5.1 風(fēng)險(xiǎn)分級(jí)模塊# 文件路徑triage.py HIGH_RISK_KEYWORDS [ 胸痛, 大量出血, 呼吸困難, 意識(shí)模糊, 劇烈腹痛, 嚴(yán)重過(guò)敏, 自殺, 傷害自己 ] def triage(user_input: str) - str: 簡(jiǎn)易風(fēng)險(xiǎn)分級(jí)。 返回值high / low for keyword in HIGH_RISK_KEYWORDS: if keyword in user_input: return high return low5.2 FastAPI 服務(wù)入口# 文件路徑app.py from fastapi import FastAPI from pydantic import BaseModel from triage import triage from medical_rag import search_knowledge, generate_answer app FastAPI(titleHealth AI Demo) class Question(BaseModel): text: str class AnswerResponse(BaseModel): risk_level: str answer: str need_human: bool app.post(/api/ask, response_modelAnswerResponse) async def ask(question: Question): risk triage(question.text) if risk high: return AnswerResponse( risk_levelhigh, answer( 您描述的情況可能存在較高風(fēng)險(xiǎn)請(qǐng)立即聯(lián)系緊急醫(yī)療服務(wù) 或前往最近醫(yī)療機(jī)構(gòu)就診。同時(shí)我們已將您的信息轉(zhuǎn)給人工客服 請(qǐng)保持手機(jī)暢通。 ), need_humanTrue, ) # 低風(fēng)險(xiǎn)走 RAG 問(wèn)答 answer generate_answer(question.text) return AnswerResponse( risk_levellow, answeranswer, need_humanFalse, )5.3 運(yùn)行與驗(yàn)證安裝依賴pip install fastapi uvicorn chromadb sentence-transformers openai啟動(dòng)服務(wù)uvicorn app:app --reload --port 8000用 curl 測(cè)試curl -X POST http://localhost:8000/api/ask \ -H Content-Type: application/json \ -d {text: 懷孕18周今天有點(diǎn)頭疼需要去看醫(yī)生嗎}低風(fēng)險(xiǎn)場(chǎng)景下返回內(nèi)容會(huì)引用知識(shí)庫(kù)生成答案。再測(cè)試高風(fēng)險(xiǎn)場(chǎng)景curl -X POST http://localhost:8000/api/ask \ -H Content-Type: application/json \ -d {text: 我現(xiàn)在胸痛得很厲害呼吸也困難}此時(shí)risk_level會(huì)返回high并且need_human為true。這個(gè)示例雖然簡(jiǎn)單但它體現(xiàn)了 AI-Native 健康服務(wù)最關(guān)鍵的工程理念模型不是獨(dú)立工作的它被規(guī)則和安全護(hù)欄約束在一條可控制的服務(wù)鏈路里。6. 醫(yī)療 AI 的合規(guī)與安全邊界6.1 隱私保護(hù)與數(shù)據(jù)最小化醫(yī)療 AI 應(yīng)用的數(shù)據(jù)合規(guī)是一個(gè)無(wú)法繞過(guò)的問(wèn)題。構(gòu)建 AI-Native 健康公司時(shí)需要從產(chǎn)品設(shè)計(jì)階段就考慮隱私保護(hù)而不是上線前再補(bǔ)。幾個(gè)關(guān)鍵原則數(shù)據(jù)最小化只采集當(dāng)前服務(wù)必需的數(shù)據(jù)。例如做孕期問(wèn)答不需要獲取用戶的地理位置和通訊錄。分級(jí)授權(quán)不同角色只能看到對(duì)應(yīng)權(quán)限的數(shù)據(jù)。用戶本人、客服、醫(yī)生、算法工程師可見的數(shù)據(jù)范圍必須區(qū)分。模型訓(xùn)練要脫敏真實(shí)用戶數(shù)據(jù)不能直接進(jìn)模型訓(xùn)練集?？梢允褂貌罘蛛[私、去標(biāo)識(shí)化等手段。日志要審計(jì)所有 AI 決策和人工干預(yù)行為都要有日志方便事后追溯。6.2 臨床安全與人工兜底AI 在醫(yī)療場(chǎng)景中永遠(yuǎn)只能做“輔助”這句話不是口號(hào)而是工程架構(gòu)上的強(qiáng)制要求。具體體現(xiàn)在高風(fēng)險(xiǎn)場(chǎng)景必須轉(zhuǎn)人工AI 不能單方面給出處置建議所有 AI 生成的方案類內(nèi)容必須有人工審核或用戶明確授權(quán)系統(tǒng)需要有熔斷機(jī)制比如模型服務(wù)異常時(shí)自動(dòng)降級(jí)為僅轉(zhuǎn)人工模式。6.3 可解釋性與可追溯性醫(yī)生和用戶對(duì) AI 的信任來(lái)自對(duì)答案來(lái)源的追溯。因此AI 健康產(chǎn)品的回復(fù)應(yīng)該支持以下能力展示答案引用的知識(shí)來(lái)源記錄模型版本和提示詞版本允許醫(yī)生對(duì) AI 輸出進(jìn)行修正并把修正結(jié)果反哺到評(píng)估集。7. 常見問(wèn)題與排查思路在搭建 AI-Native 健康服務(wù)時(shí)下面幾個(gè)問(wèn)題出現(xiàn)頻率很高。問(wèn)題現(xiàn)象常見原因解決思路模型回答與知識(shí)庫(kù)不一致提示詞未強(qiáng)制模型基于檢索內(nèi)容回答在提示詞中限制“只能基于上下文回答禁止使用內(nèi)部知識(shí)”高風(fēng)險(xiǎn)場(chǎng)景偶爾漏判僅靠關(guān)鍵詞規(guī)則不夠增加意圖識(shí)別模型將分診結(jié)果與規(guī)則引擎做投票融合回答語(yǔ)氣生硬用戶不滿只關(guān)注準(zhǔn)確性未設(shè)計(jì)同理心單獨(dú)增加“語(yǔ)氣評(píng)估”維度納入回歸測(cè)試同一問(wèn)題多次回答不一致溫度參數(shù)過(guò)高調(diào)低 temperature或使用確定性采樣策略知識(shí)庫(kù)更新后檢索不到向量庫(kù)未重新寫入新內(nèi)容建立知識(shí)庫(kù)更新的數(shù)據(jù)管道增量寫入并做召回驗(yàn)證臨床醫(yī)生不信任 AI沒有解釋依據(jù)給每個(gè)回答附上引用來(lái)源提供“人工修正”入口8. 最佳實(shí)踐與工程建議在 AI-Native 健康公司的建設(shè)過(guò)程中有幾個(gè)工程經(jīng)驗(yàn)值得寫下來(lái)。第一把提示詞當(dāng)代碼管理。每個(gè)提示詞變更都要走 Code Review并關(guān)聯(lián)對(duì)應(yīng)的測(cè)試樣本。這樣當(dāng)你發(fā)現(xiàn)某個(gè)線上回答質(zhì)量退化時(shí)可以快速定位是哪次變更引起的。第二建立評(píng)估集而不是只看 Demo 效果。很多團(tuán)隊(duì)的模型在 Demo 階段效果很好上線后卻問(wèn)題不斷核心原因是沒有覆蓋長(zhǎng)尾場(chǎng)景。建議每個(gè)新功能上線前至少準(zhǔn)備好三類評(píng)估樣本常見問(wèn)題、邊界問(wèn)題、高風(fēng)險(xiǎn)問(wèn)題。第三不要把所有任務(wù)都交給大模型。能查數(shù)據(jù)庫(kù)的就查數(shù)據(jù)庫(kù)能走規(guī)則引擎的就走規(guī)則引擎。大模型只負(fù)責(zé)那些真正需要語(yǔ)義生成的任務(wù)這樣既能降低成本又能提升穩(wěn)定性。第四重視“人機(jī)協(xié)作”的產(chǎn)品設(shè)計(jì)。醫(yī)生不是 AI 的對(duì)立面而是 AI 的老師。通過(guò)醫(yī)生對(duì) AI 回復(fù)的修正可以持續(xù)積累高質(zhì)量標(biāo)注數(shù)據(jù)這是 AI-Native 公司最核心的資產(chǎn)壁壘。第五合規(guī)不是法務(wù)一個(gè)部門的事。工程師在數(shù)據(jù)建模時(shí)就要考慮權(quán)限控制產(chǎn)品經(jīng)理在設(shè)計(jì)功能時(shí)就要明確高風(fēng)險(xiǎn)場(chǎng)景的轉(zhuǎn)人工策略。安全應(yīng)該內(nèi)嵌到流程里而不是最后補(bǔ)一道檢查。9. 總結(jié)與學(xué)習(xí)路線這篇文章圍繞 Maven Clinic 的 AI-Native 實(shí)踐思路從概念、架構(gòu)、技術(shù)實(shí)現(xiàn)到合規(guī)安全梳理了一條相對(duì)完整的建設(shè)路徑。核心要點(diǎn)可以歸納為三條一是 AI-Native 的本質(zhì)是重新設(shè)計(jì)服務(wù)流程而不是替換醫(yī)生。AI 負(fù)責(zé)規(guī)?；€(gè)性化和信息整理醫(yī)生負(fù)責(zé)臨床判斷和風(fēng)險(xiǎn)兜底。二是技術(shù)架構(gòu)要分層。數(shù)據(jù)層解決數(shù)據(jù)標(biāo)準(zhǔn)和權(quán)限模型層解決多模型協(xié)同應(yīng)用層解決產(chǎn)品封裝體驗(yàn)層解決用戶信任。每一層都需要獨(dú)立的評(píng)估和迭代節(jié)奏。三是醫(yī)療 AI 的安全邊界必須前置。風(fēng)險(xiǎn)分級(jí)、人工轉(zhuǎn)介、引用溯源、提示詞版本管理這些不是可有可無(wú)的功能而是 AI-Native 健康公司的地基。如果你接下來(lái)想深入這個(gè)方向建議按下面的順序?qū)W習(xí)熟悉醫(yī)療數(shù)據(jù)標(biāo)準(zhǔn)從 FHIR 和常見 EHR 數(shù)據(jù)結(jié)構(gòu)入手學(xué)習(xí) RAG 的技術(shù)細(xì)節(jié)包括向量檢索、重排、引用溯源研究多模型路由和模型評(píng)估體系特別是離線評(píng)估與在線監(jiān)控的結(jié)合閱讀醫(yī)療 AI 相關(guān)的合規(guī)文檔理解不同市場(chǎng)對(duì)醫(yī)療軟件和 AI 輔助診斷的監(jiān)管要求。醫(yī)療與 AI 的結(jié)合是一個(gè)長(zhǎng)期賽道。真正有價(jià)值的產(chǎn)品不一定是最早接入大模型的而是最早把數(shù)據(jù)閉環(huán)、安全護(hù)欄和評(píng)估體系跑通的那家公司。如果你正在做這方面的項(xiàng)目也可以從一個(gè)小場(chǎng)景開始比如一個(gè)帶知識(shí)庫(kù)引用的孕期問(wèn)答助手先把安全和評(píng)估做到位再慢慢擴(kuò)展服務(wù)鏈路。