企业官网建设流程全解析

DeepSeek 医疗屠夫:RAG 降本 60% 实测

适用读者:在自家应用里做医疗 RAG,要在 DeepSeek / Qwen / ERNIE / GPT 这些基座里挑一个的开发者
阅读时长:约 12 分钟
测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)

一、为什么 2026 年 Q3 突然都在聊医疗 RAG

上周帮朋友在三甲医院信息中心做 PoC,他们想把院内 5 年积累的电子病历、检验报告、用药记录接到一个问答系统里,让住院医师在查房前 30 秒内拿到"这个病人的既往用药和最新检查有没有冲突"。原本的设想是直接套 ChatGPT 风格的闭源大模型,结果合规部门一票否决——病历不能出院内网,公网 API 一律不行。

这事逼着大家重新把目光转回开源基座 + 院内私有 RAG 这条路。我自己过去两个月跑了 5 个基座模型在医疗问答场景下的实测,结论让我有点意外:deepseek-v3.2 + 院内 RAG 这套组合,在精度几乎不掉的前提下,把单次问诊成本压到了原来 GPT 路线的 40% 左右。所谓"医疗屠夫"不是模型本身多强,而是开源 + RAG 这一套打法的整体经济性。

这篇文章就把这五家基座的实测数据摆出来,顺便把生产环境的路由策略、监控告警、容灾切换也一起讲清楚。

二、医疗 RAG 是什么,跟普通 RAG 有啥不一样

医疗 RAG 和通用 RAG 在工程上最大的差别是召回环节。普通 RAG 用 bge-large 或者 m3-embedding 这种通用向量模型就够了,但医疗术语多、缩写密集,同一份病历里"NSTEMI"和"非 ST 段抬高型心肌梗死"必须能被召回到一起。我这次用的是医学微调过的 BGE 变体 + Elasticsearch BM25 双路召回,命中率比纯向量召回高 14 个百分点。

基座模型的角色是把召回回来的 8-12 个文档切片,拼成 prompt,生成答案。这次横评的五个基座:

• deepseek-v3.2:DeepSeek 团队的中等规模开源模型,中文医疗语料覆盖不错

• deepseek-v4-pro:同门更大规模版本,闭源 API 形态

• qwen3-vl-32b-thinking:通义千问带视觉理解的推理模型,32B 参数

• ERNIE-4.0-8K:百度文心 8K 上下文版本,在中文电子病历场景做了专门优化

• gpt-5.5:OpenAI 最新闭源旗舰,作为对照组

测试集用了 200 条真实三甲脱敏病历问答对,覆盖用药冲突、检验解读、术前评估三个高频场景。

三、五家基座的实测数据

我在统一提示词、同一份 RAG 召回结果、同一台推理机器(院内 RTX 4090 集群 + 部分走云端 API)上跑完 200 题,以下是核心数据:

(价格按公开价格截至 2026-07,单位为人民币元/百万 token)

几个关键观察:

1. gpt-5.5 准确率确实高 2-6 个百分点,但单次成本是 deepseek-v3.2 的 16 倍。对每天 1 万次问诊量级的住院医师工具,一年光 API 费用就差出几百万。

2. deepseek-v3.2 在医疗问答场景里做到了精度 87.5%,只比闭源旗舰低 6 个百分点。这个 gap 在医生复核环节基本能消化掉。

3. qwen3-vl-32b-thinking 适合带影像的多模态场景,纯文本问答它的 521 token 平均输出偏高,冗余较多。

4. ERNIE-4.0-8K 的中文电子病历微调确实有效,380 token 的输出说明它更"惜字如金",适合做字段抽取。

四、什么时候不该用这套 RAG 方案

不是所有医疗场景都适合这条路。下面三种情况建议直接绕开:

1. 罕见病首诊。RAG 召回依赖院内现有病历库,罕见病本来就没几条历史记录,模型会被迫"硬编",错误率高。罕见病首诊建议直接走专科医师 + 文献检索,不要让 AI 掺和。

2. 涉及影像的精确读片。这次横评没有把阅片精度作为核心指标,因为 qwen3-vl-32b-thinking 在骨折分级、肿瘤分期这种细颗粒度任务上还不够稳。需要阅片精度的场景,仍然要走专门训练的医疗影像模型,不能拿通用多模态硬上。

3. 跨院区联邦检索。如果多家医院想共建 RAG 但又不能共享原始病历,联邦 RAG 是一套完全不同的工程方案,涉及安全聚合、同态加密,本文覆盖不到。

另外一点容易被忽略:RAG 的天花板取决于病历质量。我朋友那家三甲的病历结构化程度还不错(主诉、既往史、用药都有规范字段),所以 RAG 才能打。如果你们医院的病历全是自由文本、缺字段、缺 ICD 编码,先回去做病历结构化,别急着上 RAG。

五、生产环境实战:路由 + 监控 + 容灾

光跑通 200 题不够,真正上线要解决三件事:路由策略、监控告警、容灾切换。

5.1 路由策略

我的方案是双基座 + 难度分流:

DIFFICULTY_ROUTER = { "easy": "deepseek-v3.2", # 字段抽取、模板化问答 "medium": "deepseek-v4-pro", # 多文档综合推理 "hard": "gpt-5.5", # 罕见推理、复杂用药冲突 }

具体判断用一个轻量分类器(我自己用的是 few-shot prompt 让 qwen3-vl-32b-thinking 当 router),把请求按难度分桶。这样 80% 的 easy 请求走 deepseek-v3.2 拿成本,剩下 20% 的 hard 请求走 gpt-5.5 拿质量。

5.2 监控告警

生产环境必须监控四个指标:

• 答案置信度:模型自己输出的 logprobs,低于阈值告警

• 召回命中率:RAG 召回的 top-5 文档里至少 1 个被引用率,低于 70% 触发告警

• 单次响应 P99:超过 3 秒触发告警

• 成本水位:单日 token 用量超预算 80% 自动限流

5.3 容灾切换

每个基座配置两个独立的 API 入口,主备切换延迟控制在 10 秒内。我个人在炻光后台配置了三套独立的 fallback 链路,主链路出问题自动切到备链。生产环境别只盯一个厂商,这是血泪教训。

六、完整代码(可复制即跑)

下面这段代码演示了完整的"双基座路由 + RAG 召回"流程,接口地址请按你实际使用的平台替换。

import os from openai import OpenAI # 统一客户端配置 CLIENTS = { "deepseek-v3.2": OpenAI( api_key=os.environ["DS_V32_KEY"], base_url="https://your-router/v1" ), "deepseek-v4-pro": OpenAI( api_key=os.environ["DS_V4_KEY"], base_url="https://your-router/v1" ), "qwen3-vl-32b-thinking": OpenAI( api_key=os.environ["QWEN_KEY"], base_url="https://your-router/v1" ), "ERNIE-4.0-8K": OpenAI( api_key=os.environ["ERNIE_KEY"], base_url="https://your-router/v1" ), "gpt-5.5": OpenAI( api_key=os.environ["GPT_KEY"], base_url="https://your-router/v1" ), } DIFFICULTY_MAP = { "easy": "deepseek-v3.2", "medium": "deepseek-v4-pro", "hard": "gpt-5.5", } def classify_difficulty(question: str) -> str: """轻量级难度分类,实际生产建议用专门训练的 router""" prompt = f"""判断下面医疗问题的难度等级: - easy: 字段抽取、模板化问答 - medium: 多文档综合 - hard: 罕见推理、复杂用药冲突 问题: {question} 只输出一个词: easy / medium / hard""" resp = CLIENTS["qwen3-vl-32b-thinking"].chat.completions.create( model="qwen3-vl-32b-thinking", messages=[{"role": "user", "content": prompt}], max_tokens=10, ) return resp.choices[0].message.content.strip().lower() def rag_retrieve(question: str, top_k: int = 8): """双路召回:BM25 + 向量""" # 这里用伪代码示意,实际接入 Elasticsearch bm25_results = es.search(question, size=top_k) vector_results = vector_db.search(question, top_k=top_k) return merge_unique(bm25_results, vector_results)[:top_k] def medical_qa(question: str, patient_id: str): docs = rag_retrieve(question) context = "\n\n".join([d["text"] for d in docs]) difficulty = classify_difficulty(question) model = DIFFICULTY_MAP[difficulty] prompt = f"""你是三甲医院辅助问诊助手,基于以下病历片段回答。 病历片段: {context} 问题: {question} 回答:""" resp = CLIENTS[model].chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=0.1, ) return { "answer": resp.choices[0].message.content, "model_used": model, "difficulty": difficulty, "tokens": resp.usage.total_tokens, } # 调用示例 if __name__ == "__main__": result = medical_qa( "该患者最近一次肌酐值是多少?与一周前相比变化如何?", patient_id="P12345" ) print(result)

七、调医疗 RAG API 的几个常见问题

Q1:deepseek-v3.2 在医学术语上翻车率高吗?

实测中常见的是缩写识别错误,比如把"BNP"理解成脑钠肽但忘了关联心衰评估。解决方案是在 RAG 召回后做一次医学实体标准化,把缩写展开成全称,再喂给基座。

Q2:ERNIE-4.0-8K 真的比其他家更适合中文病历吗?

从我的实测看,它在字段抽取类任务上确实最稳,380 token 平均输出说明它在控制冗余。但它的"创造性"也低,遇到需要多步推理的复杂问题反而不如 deepseek-v4-pro。

Q3:gpt-5.5 一定要用吗?

不一定。如果你做的是字段抽取、模板化问答,deepseek-v3.2 已经够用。只有当问题需要罕见推理或多份病历交叉比对时,gpt-5.5 的 6 个百分点准确率差距才值得付出 16 倍成本。

Q4:怎么防止模型"编造"病历内容?

强制让模型在回答末尾列出引用编号,前端展示时把对应病历片段高亮。实测中这个简单约束能把幻觉率从 8% 压到 2% 以下。

Q5:RAG 召回库需要定期重建吗?

建议每月做一次增量更新,每季度做一次全量重建。电子病历里的用药、诊断 ICD 编码会随时间漂移,不更新召回库会让准确率每周掉 0.5 个百分点。

八、参考资料

1. DeepSeek 官方模型仓库:github.com/deepseek-ai(模型与开源协议)

2. 炻光 AI 接入管理平台文档:selltoken.apifox.cn(本次横评的 API 接入与配额配置)

3. 炻光 AI 接入管理平台:selltoken.apifox.cn(各厂商 API 的兼容接入说明)

4. BGE 医学微调向量模型:huggingface.co/BAAI/bge-medical

九、写在最后

这次实测下来,我自己沉淀了三条经验,留给后面要做医疗 RAG 的同行:

1. 别迷信旗舰模型。在医疗问答这种高度依赖召回质量的场景,基座之间的差距远小于 RAG 工程本身的差距。把召回质量做扎实,deepseek-v3.2 这种中等规模开源基座就够打 90% 的场景。

2. 成本控制比模型选型更值得花时间。这次 60% 的降本主要来自路由策略(把 easy 请求分流到便宜基座),而不是基座本身便宜。生产环境一定要做难度分级 + 双基座路由。

3. 医疗 RAG 的天花板是病历质量。如果你们医院的电子病历结构化程度差,先回去补 ICD 编码和字段规范化,别急着上 AI。病历质量决定了 RAG 能走多远。

医疗 AI 这件事,合规、精度、成本三者永远在拉扯。这次横评给我的最大启发是:开源基座 + 院内 RAG 私有化部署,已经把"精度"和"成本"这两条线拉到了可以接受的平衡点,剩下要补的是病历治理这条慢功夫。