企业官网建设流程全解析

简介：针对医疗行业病历数据非结构化这一长期痛点，这份PDF以三甲医院急诊科为真实场景，面向医院信息化工程师、临床科研人员及DeepSeek技术爱好者，系统解答如何借助大模型实现病历结构化与辅助诊断。文档共二十一页，压缩包内仅单个PDF文件，大小约一点七九兆字节，下载后可直接在电脑或移动设备上阅读。内容从非结构化病历带来的信息检索、统计分析和决策支持问题切入，逐步展开DeepSeek模型架构与注意力机制原理、基于微调的病历结构化方案、辅助诊断模型设计、系统测试评估，以及急性胸痛和复杂外伤两个落地案例，覆盖了从背景研究到代码实现的完整链路。目前已有102人学习下载，尤其适合希望将大模型应用到医院信息系统改造和临床决策支持的读者，作为从零开始的项目参考。

1. 三甲急诊科碰上DeepSeek：病历结构化与辅助诊断，先想清楚两件事

三甲医院急诊科白班夜班下来，少则几十条、多则一两百条病历，主诉、现病史、查体、初步诊断全挤在医生几分钟的口述和键盘敲击里，落到系统里就是一段自由文本。等这些文本要用于不良事件上报、临床科研队列筛选、分诊系统输入时，卡点就出现了：机器没法直接消费自由文本。用DeepSeek做急诊病历结构化和辅助诊断，就是把这个卡点打开——把自然语言病历拆成规整的临床字段，再基于字段给出鉴别诊断候选。这篇笔记适合医院信息科、临床数据团队和医疗AI交付工程师，动手之前先接受一条边界：模型输出永远只做辅助，必须经过医生复核签字，才能进临床主流程。

2. 病历结构化的落法：一次DeepSeek调用，把急诊文本拆成临床字段

2.1 字段设计先行：不把字段立好，后面全白搭

病历结构化首先是字段设计问题，不是提示词问题。模型再稳，字段没定对，回写HIS时只会更乱。我的一般做法是按住这六个拆：主诉、现病史、既往史、生命体征、查体重点、初步诊断。这六个字段能覆盖急诊病历至少八成的结构化诉求，而且和后续辅助诊断的输入完全对齐。

字段数量的原则是宁少勿多。一次让模型拆二十个字段，尤其“发病诱因”“缓解因素”这类自由表达空间大的字段，输出稳定性一定会下降。我一般控制在6到10个，先跑通再扩。每个字段还尽量让取值有界，比如severity只允许critical/urgent/non-urgent三个枚举值，血压固定成“数字/数字”格式，你给模型的空间越小，它自由发挥的余地就越小。

2.2 第一条可跑的指令：DeepSeek API从密钥到JSON解析

密钥在DeepSeek官方开放平台申请，申请后创建API Key，走的是兼容OpenAI格式的接口。下面这段代码是我在急诊病历场景里最基础的一条调用链路，包含提示词、请求参数和后处理：

import json import re import time from openai import OpenAI client = OpenAI( api_key="sk-xxxxxx", # 替换为你在DeepSeek平台申请的密钥 base_url="https://api.deepseek.com", timeout=30.0 ) # 字段schema，直接序列化进system prompt，让模型按定义来 schema = { "chief_complaint": "主诉，保留患者原话或医生简缩表述", "present_illness": "现病史，按时间线描述，不超过300字", "past_history": "既往史，含过敏史、长期用药", "vitals": { "bp": "血压，格式如 130/85", "hr": "心率，数字", "rr": "呼吸频率，数字", "temp": "体温，数字", "spo2": "血氧饱和度，数字" }, "exam": "重点查体发现", "preliminary_diagnosis": "初步诊断，中文临床诊断，最多3个", "severity": "枚举值：critical/urgent/non-urgent" } def structure_ed_note(raw_text: str) -> dict: sys_prompt = ( "你是急诊科病历结构化引擎。把输入的急诊自由文本按schema抽取字段；" "未提及的字段写空字符串或null。只输出JSON对象，不要Markdown代码块，不要解释。" f"字段定义：{json.dumps(schema, ensure_ascii=False)}" ) resp = client.chat.completions.create( model="deepseek-chat", # 以DeepSeek文档当前可用的模型名为准 messages=[ {"role": "system", "content": sys_prompt}, {"role": "user", "content": f"以下急诊病历文本，请结构化：\n{raw_text}"} ], temperature=0.05, # 结构化任务要稳定，不要随机发挥 max_tokens=2048 # 长现病史可能超过512，给足空间 ) content = resp.choices[0].message.content # 双保险：剥离可能出现的Markdown代码块标记 content = re.sub(r"^```(?:json)?|```$", "", content.strip(), flags=re.MULTILINE) return json.loads(content) # 模拟一条急诊文本 raw = "患者男性，56岁，因胸痛伴大汗2小时来院。高血压5年。查体：神清，双肺呼吸音粗，未闻及干湿啰音。生命体征：血压130/85，心率88，呼吸20，体温36.8，血氧97%。初步诊断：ACS待排。" result = structure_ed_note(raw) print(json.dumps(result, ensure_ascii=False, indent=2))

注意我在temperature上只给了0.05。结构化抽取是确定性任务，不是写作任务，温度越高越容易在个别字段上“润色”，一润色就出错。max_tokens给到2048是因为急诊现病史常常一整段下来超过500字，给太窄会被拦腰截断。最后那行正则剥离代码块标记很关键，后面避坑章节会细说。

提示：如果DeepSeek文档中你的模型不支持某些结构化输出参数，不要把调用写死，先准备一个“提示词要求JSON + 正则兜底”的降级方案。

2.3 JSON剥离、缺失补偿、数字交叉核对：结构化翻车前的最后防线

上一步的代码能跑通，并不代表字段可信。我在实际验证中至少补三道校验，缺一道都会出问题。

第一道是JSON解析后的键检查。用result.keys()和schema比对，缺的键补空字符串。别小看这件事，模型偶尔会漏掉一个字段不输出，比如spo2没提，它就真不给这个键，直接丢给下游会触发KeyError。

第二道是数字字段交叉核对。生命体征是数值错误的重灾区，模型可能会把“心率88”写成“心率82”，或者血压分子分母写反。我一般这样兜底：

import re def cross_check_vitals(raw_text: str, parsed: dict) -> dict: """拿正则从原始文本再抓一遍关键数值，和模型输出比对，不一致以原文为准""" vitals = parsed.get("vitals", {}) patterns = { "bp": r"血压[：:\s]*(\d{1,3})/(\d{1,3})", "hr": r"心率[：:\s]*(\d{1,3})", "rr": r"呼吸[频率]?[：:\s]*(\d{1,3})", "temp": r"体温[：:\s]*(\d{1,2}(?:\.\d+)?)", "spo2": r"血氧[：:\s]*(\d{1,3})" } for key, pat in patterns.items(): m = re.search(pat, raw_text) if m: raw_value = m.group(1) model_value = str(vitals.get(key, "")).strip() if model_value != raw_value: vitals[key] = raw_value # 以原始文本为准 parsed["vitals"] = vitals return parsed

第三道是枚举值校验。severity字段只允许三个值，但模型偶尔会输出“urgent（疑似”）这种带括号的变体，直接匹配会失败。处理方式是先做规范化，剥离括号及注释，再判断是否落在枚举集合里，不在集合内默认置为non-urgent并在返回结果里加一个warning字段，提醒下游“此条severity为兜底值，需要人工复核”。

三道校验做完，结构化的结果才敢往HIS或者辅助诊断模块传。别嫌麻烦，急救场景里多一道校验，就是少一次翻车。

3. 辅助诊断：让DeepSeek从结构化字段给出分层鉴别诊断

3.1 急诊思维写进提示：先危险分层，再鉴别诊断

急诊医生的工作习惯和门诊不一样，第一步永远不是“是什么病”，而是“先处理谁”。我看过也踩过不少坑——直接问模型“这是什么病”，它会给出一个看似合理的诊断列表，但分不清哪个会要命。正确的做法是把急诊的分层逻辑写进提示词，强制模型分层来走。

下面是我常用的辅助诊断system prompt框架：

diag_system_prompt = """ 你是急诊科辅助诊断助手。你的任务是辅助，不是决定。 处理流程： 1. 先根据生命体征、主诉和查体判断危险分层（critical/urgent/non-urgent）。 2. 在危险分层内给出3~5个鉴别诊断候选，按可能性从高到低排列。 3. 每个候选必须包含两栏： - support：病历中支持该诊断的字段证据 - to_rule_out：为排除/确认该诊断需补做的检查 4. 严禁编造病历中不存在的症状、体征、检查结果。 只输出JSON：{"triage":"...","differential_diagnosis":[{"diagnosis":"","support":[],"to_rule_out":[]}]} """

这个模板有两层意思。第一层是流程约束，把“先分层后鉴别”写成了硬性步骤，模型在执行时就不会跳过危险分层直接给诊断列表。第二层是证据约束，要求每个候选都给support和to_rule_out，这等于让模型把推理过程摊开，方便医生和工程师两边都检查它是真的从病历字段推出来的，还是在拿训练数据里的套路凑数。

实际操作里，危险分层结果还会决定下游是否走强提醒流程：triage=critical时，不管诊断候选是什么，都要在界面上强制弹窗让医生确认；non-urgent则可以静默展示，不打断工作流。

3.2 给DeepSeek外挂参考库：既往确诊病历与急诊指南的检索增强

只有一个提示词，辅助诊断的上限很快会碰到。原因在于模型对罕见病和本院的用药习惯一无所知，全凭训练时的通用医学知识，容易把“常见病”放在太高的位置。常见的补法是检索增强：把既往确诊病历、急诊指南片段、本院用药目录向量化，按当前病历的文本相似度检索出Top3到Top5条，拼进上下文再让模型回答。

# 检索增强的简化流程：历史病历向量化，按相似度取top5拼接 from sentence_transformers import SentenceTransformer import chromadb embedder = SentenceTransformer("BAAI/bge-large-zh-v1.5") # 中文向量编码模型 db = chromadb.PersistentClient(path="./ed_archive") col = db.get_or_create_collection("cases", embedding_function=embedder) # 写入一条既往确认病历，假设最终确诊为急性心肌梗死 col.upsert( ids=["ED-20240101-001"], documents=["胸痛伴大汗2小时，ECG示ST段抬高，肌钙蛋白升高，确诊急性心肌梗死"], metadatas={"final_diagnosis": "急性心肌梗死"} ) # 检索 hits = col.query(query_texts=["胸痛 大汗 2小时"], n_results=3) for hit in hits["documents"]: print(hit)

拿到检索结果后，把它转成上下文文本，插入到diag_system_prompt之后、用户文本之前，格式大致是“以下是本院既往确诊病历片段，仅作诊断候选参考，不得直接照搬”。这里有两个细节值得注意：第一，参考病历的数据本身也属于患者隐私，存入向量库前必须脱敏；第二，参考病历的结论不能直接作为当前病例的诊断，提示词里必须写明“仅作参考”四个字，否则模型很容易把历史确诊当成当前结论输出。

RAG参数上，n_results一般取3到5，太少没参考价值，太多会把上下文撑大，挤占max_tokens。相似度阈值我通常设0.6左右，低于阈值的检索结果宁可不用，也不要硬塞给模型当噪声。

3.3 输出约束与置信度：哪些结果可以直接信，哪些必须复核

辅助诊断的输出同样要约束结构。除了让模型按JSON输出，我还会在每个诊断候选里加一个confidence字段，取值范围0到1，让模型自己给出把握程度。这样做的目的不是为了相信模型的自信，而是为了给界面交互一个分级依据。

confidence大于等于0.7的候选，可以显示为“高可能性”并列出支持证据；0.4到0.7之间的显示为“待排查”，默认勾选to_rule_out里的检查项；小于0.4的候选，直接沉底或者折叠，减少对医生的干扰。这个阈值划分不要照抄我的，你可以在自己医院的病历样本上跑一轮统计，看看模型在不同置信区间的准确率分布再定阈值。

更硬的一层约束是让模型只能用病历里出现的检查结果。我经历过模型在辅助诊断里写“心电图提示ST段抬高”，但原始病历根本没提心电图，这种幻觉放给医生就是严重的信任危机。处理办法是两层同时做：提示词里显式声明“不得引用病历中不存在的检查结果”，代码侧再对输出里的检查项做一次正则匹配，和原始文本比对，匹配不上的就从support列表里剔除。这层校验不能省，尤其辅助诊断这种高敏感场景。

4. 在医院落地：部署选型、接口对接与急诊峰值的并发

4.1 数据合规与部署选型：API调用还是本地部署

医院场景下，第一个要回答的不是性能问题而是数据合规问题。病历文本包含姓名、病案号、主诉、诊断，属于受保护健康信息，能不能出医院网络，取决于你所在机构的合规要求和当地法规。两条路各有拥趸。

我的建议是：先用官方API做POC，跑通字段设计、提示词、下游对接，验证病历结构化准确率能到多少；验证通过后，如果医院有院内GPU资源且数据出域审批难走，再迁到本地部署。POC阶段用API能省掉大量排查环境问题的时间，把精力集中在业务逻辑上。

本地部署最常见的做法是用vLLM拉起一个兼容OpenAI的服务：

# 安装vLLM pip install vllm # 从DeepSeek官方渠道获取开源权重，下载到院内部署服务器 huggingface-cli download <deepseek权重路径> --local-dir ./deepseek_local_model # 启动推理服务，端口8000 vllm serve ./deepseek_local_model \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --served-model-name deepseek-local

启动后，客户端代码只需要把base_url改成本机地址，其余逻辑完全不用动：

client = OpenAI( api_key="EMPTY", # vLLM本地服务不校验真实密钥 base_url="http://127.0.0.1:8000/v1" )

血糖是指数级别的。本地部署的硬伤是团队要能扛住运维：显存不够会导致单条请求排队，并发上来直接OOM，模型更新后需要自己重新做一轮评测。所以在选型时我给一个判断标准：如果医院连不了外网，或者信息科没有专人能24小时响应推理服务告警，就不建议硬上本地部署，脱敏后走官方API在POC阶段是更务实的选择。

4.2 和HIS/EMR的对接路径：文本从哪来，结构回写哪

病历文本的来源通常是HIS或者EMR里的急诊留观记录草稿。集成方式没有标准插件可下载，常见做法是自建一个中间服务，暴露结构化接口给院内集成平台调用。我一般会写一个轻量HTTP服务：

from fastapi import FastAPI, HTTPException app = FastAPI() @app.post("/api/v1/structure") async def structure_endpoint(payload: dict): note_id = payload.get("note_id") raw_text = payload.get("text", "").strip() if len(raw_text) < 20: raise HTTPException(status_code=400, detail="病历文本过短，拒绝结构化") try: result = structure_ed_note(raw_text) # 内部封装DeepSeek调用 result.setdefault("severity", "non-urgent") # 回写HIS由院内集成平台完成，本服务只返回标准化结果 return {"code": 0, "note_id": note_id, "result": result} except Exception as exc: # 结构化失败也要返回可读错误，方便上游记录 raise HTTPException(status_code=500, detail=f"structure failed: {exc}")

对接路径上有两个经验。第一，回写动作不要让这个服务直接做，因为HIS的接口格式各家不一样，直接耦合会让服务被“带偏”，更好的是把结构化结果返回给集成平台，由平台再按各系统的格式回写。第二，一定要做重复请求防护：同一个note_id在短时间内被重复推送，模型就要被重复调用，API费用和响应压力都会翻倍。我用内存字典加时间戳做了一层幂等，10分钟内相同note_id直接返回上次结果。

4.3 急诊高峰并发处理与降级策略

急诊流量不是均匀的，流感季节、突发事件、夜间急诊都会造成瞬时波峰。估算并发有一个粗略公式：单条病历结构化调用耗时约3到5秒（本地部署中等规模模型），如果一小时内来了60条病历，平均每50秒就要处理一条，单并发根本不够，至少要开4到8个并发才能覆盖波峰。

配置上我会在结构化入口前面加一个线程安全的任务队列，控制并发数，避免请求把推理服务打满。当队列积压超过一定长度（比如超过20条），说明模型处理速度跟不上输入速度，此时不能一直排队耗着医生时间，要启动降级策略：放弃完整结构化，只调用一个更轻量的文本分类模型或者基于规则的分诊脚本，输出severity和chief_complaint两个关键字段，保证分诊系统还能运转。

降级这个开关一定要做成可配置的，不要写死在代码里。我在真实环境里吃过亏：某次后端模型卡了十五分钟，队列积压了几百条，医生等不到结果直接放弃整个功能，从那以后我把降级阈值做成配置中心里的一个参数，值班工程师可以在不重启服务的情况下调整。

5. 避坑记录：病历结构化跑不稳的五个常见问题与排查

5.1 现象：JSON解析偶发报错，打印出来发现多了Markdown代码块

原因：DeepSeek在少部分请求里会“好心”把输出包进```json代码块，即使system prompt已经写了“不要Markdown代码块”。这不是概率性的稳定，一旦发生，json.loads直接抛异常，整条链路中断。

解决：在解析前先用正则把代码块标记剥掉，这是最简单也最可靠的兜底。我在2.2节里写了这行正则，实际线上跑了几个月，它能覆盖至少九成以上的代码块问题。如果某些模型版本还会在JSON前后加解释文字，再加一层“提取第一个{到最后一个}之间的子串”的逻辑，双保险。

5.2 现象：生命体征数字被“润色”改写，原文血压130/85变成130/80

原因：结构化任务里，模型把文本里的数字理解成了可以“规整”的对象，尤其原文里血压值不在常见范围内时，模型会倾向于往它熟悉的分布靠拢。温度设到0.05只会降低这种倾向，不会完全消除。

解决：数值字段一律做交叉核对。2.3节里的正则方案就是为此准备的，拿原始文本里的数字和模型输出比对，不一致以原文为准。不要信任模型对数字的复述，这是血泪经验。

5.3 现象：辅助诊断输出里出现病历里没有的检查结果，比如“心电图示ST段抬高”在原文根本没提

原因：这是大模型的经典幻觉，模型在生成诊断候选时，从训练数据里“回忆”出了典型表现，并当成了当前病历的事实。它错在把“典型表现”和“当前病历证据”混为一谈。

解决：三层防护。第一层，system prompt里显式声明“不得引用病历中不存在的检查结果”；第二层，输出解析后，把所有support列表里的检查项和原始文本做关键词匹配，匹配不上的剔除；第三层，在面向医生的界面上，把“模型引用证据”和“医生人工补充证据”用不同颜色区分，让医生一眼看出哪些是模型从病历里抓的，哪些是它自己脑补的。

5.4 现象：病历一长，输出字段就缺三少四，尤其是现病史后半段丢内容

原因：急诊病历虽然不长，但现病史常常一大段全写在一起，超过模型单次处理的有效长度时，模型会把注意力集中在开头，后半段细节被忽略。更隐蔽的原因是max_tokens不够，生成到一半被截断。

解决：两条路合用。一是调整max_tokens，给足2048以上；二是对超长文本做分段预处理，比如按“查体”“现病史”的标题拆成几段，分别做字段抽取再合并。分段不是偷懒，是让模型在每段上聚焦，整体准确率反而更高。

5.5 现象：结构化接口响应太慢，医生等了几秒没出结果，直接放弃了

原因：模型推理耗时摆在那里，本地部署中等规模模型单次调用2到4秒，如果再叠加队列排队，医生端的体感就是“转圈圈转半天”。我优化前的接口从进入队列到返回结果平均要8秒，临床根本不可接受。

解决：把完整结构化做成异步任务。前端先拿到“处理中”状态，结构化完成后回调推送结果，医生的操作不被阻塞。同时把降级策略阈值调低，如果完整结构化的预估耗时超过5秒，直接走轻量分诊脚本先出severity和主诉，其余字段后台慢慢补，补完了再静默更新。这事关临床信任，宁可先给一半结果，也不能让医生对着转圈等。

6. 怎么验证你没白做：字段级F1和医生双签，把DeepSeek放到闭环里

6.1 用字段级F1评估结构化质量，而不是看“整体感觉”

项目上线前，我会从急诊科调一批已归档的病历，人工标注出标准字段，构成一个黄金测试集。注意标注的人必须是临床医生，工程师盯着屏幕琢磨“这个词该放主诉还是现病史”只会自欺欺人。测试集规模不用太大，100到150条就能看出模型的真实水平。

评估指标用字段级F1，而不是单一的总体准确率，因为不同字段的重要性和难度不一样。主诉通常是短文本，主诉匹配相对容易；现病史是长文本，误差类型也复杂得多。按字段分别算F1值，能直观看到模型在哪类字段上拖后腿，再有针对性地改提示词或加后处理规则。

def field_f1(gold: str, pred: str) -> float: """单个字段的token级F1，gold为人工标注金标准，pred为模型预测""" gold_tokens = set(str(gold).split()) pred_tokens = set(str(pred).split()) if not gold_tokens and not pred_tokens: return 1.0 if not pred_tokens: return 0.0 common = gold_tokens & pred_tokens precision = len(common) / len(pred_tokens) recall = len(common) / len(gold_tokens) if precision + recall == 0: return 0.0 return 2 * precision * recall / (precision + recall) # 对测试集中每条病历逐字段计算，再按字段求均值 report = {} for field in ["chief_complaint", "present_illness", "vitals", "exam"]: scores = [field_f1(gold[field], pred[field]) for gold, pred in test_set] report[field] = round(sum(scores) / len(scores), 3) print(report)

需要说明，字段级F1衡量的是“抽取完整性”，而不是“临床正确性”。即使主诉、生命体征全部匹配上，也不代表初步诊断或者鉴别诊断候选一定是临床上正确的。诊断维度的评估，需要医生参与做二次判读：诊断是否合理、是否遗漏了致命性急症、to_rule_out建议是否恰当。这里的标准主观但不可少。

6.2 医生双签闭环：模型可以跑在前面，但不能把话说完

最后一步，也是最不能省的一步：把模型输出设计为“草案”而不是“结论”。医疗决策的闭环必须由人完成，DeepSeek可以快速给出结构化字段、鉴别诊断候选和补充检查建议，但所有输出都需要医生确认后才回写HIS主流程。

我在设计界面时用了一个状态机：模型返回的结果先进入“待确认”状态，医生逐字段审核验收，确认后状态变为“已确认”；遇到错误结果，医生可以直接修改字段，修改后的版本会记录日志，成为后续微调模型的训练素材。手术刀般的细节：日志里要同时保存模型原始输出和医生修改后内容，这一个是用来评估模型真实性能的，另一个是用来定位系统用久了之后阈值是否适合业务变化。

我自己的教训是曾经做一个辅助诊断功能，最初没有加这道人工复核，上线的第七天就收到急诊护士站投诉——模型给了一位腹痛患者“急性胰腺炎”的鉴别诊断，并把可能性排在最前面，患者实际只是急性肠胃炎。虽然界面有免责声明，但医生已经被诱导产生了先入为主的判断，这就是安全边界没守好。从那以后我的习惯是：所有模型输出都带一个“复核人”字段，没填复核人的数据不进临床主流程，辅助诊断永远只是辅助，医生才是最终签字的人。

希望帮到你。

本文还有配套的精品资源，点击获取