尧图网页设计 
简介这份调优手册面向医疗信息化从业者、医保控费研究人员及自然语言处理工程师聚焦医疗电子病历挖掘与DRG医保控费场景系统讲解如何借助DeepSeek语义理解技术提升病历分组准确性与控费效率。资源为1个PDF文件压缩包约1.98MB内容完整、目录清晰涵盖引言、医疗电子病历挖掘与DRG概述、DeepSeek语义理解技术基础、调优前准备、数据预处理调优、模型架构调优、训练参数调优、模型评估与监控、常见问题解决方案及实践案例分享等模块。读者可从中获得从数据清洗、标注优化、特征提取到学习率、批量大小、正则化参数调整的完整调优思路并了解注意力增强模块、知识图谱融合等进阶方法以及模型部署与动态监控的排错经验。目前已有79人学习适合希望将DeepSeek落地于医疗文本分析、提升医保控费精度的中高级读者参考。1. 病历文本里藏着医保亏损的答案为什么 DRG 控费需要语义理解而不是关键词匹配一份 800 字的出院小结DRG 分组器只认其中 30 来个关键词剩下的信息全被丢掉。问题在于真正决定入组的往往不是「2型糖尿病」这五个字而是「血糖控制不佳」「合并糖尿病肾病Ⅲ期」「近三月反复因酮症住院」这些散落在病程记录里的语义线索。关键词匹配抓不到否定、抓不到程度、抓不到时间关系于是该入 ADRG 的进了保守组该有并发症的按单纯病种结算月底一算科室亏了十几万。这就是医疗电子病历挖掘要解决的事把非结构化的病历文本变成 DRG 分组器能吃的结构化证据。DeepSeek 这类大模型的价值不在「生成」而在「抽取」——从自由文本里稳定地拉出诊断、手术、并发症、入院病情这些入组要素。这套方案适合三类人医院信息科要做 DRG 预分组的、医保办要做事前控费的、以及做医疗 NLP 落地但被标注数据卡住的工程师。接下来我把从病历清洗到 DeepSeek 语义抽取再到 DRG 入组校验的完整链路拆开讲包括参数怎么设、哪些坑我踩过。2. 从病历原文到 DRG 入组要素语义抽取链路的四个环节2.1 先搞清楚 DRG 分组器到底要什么字段DRG 分组不是黑匣子它的输入是有限且明确的。以 CN-DRG 为例核心入组变量包括主要诊断MDC 决定大类、主要手术/操作、其他诊断决定 CC/MCC 等级、年龄、新生儿体重、出院方式。其中「其他诊断」是否构成并发症或合并症直接影响是进无 CC 组还是有 CC/MCC 组费率差距通常在 30% 到 80%。所以语义抽取的目标不是「理解整份病历」而是精准命中这几类字段。我一般把抽取任务拆成四个子任务子任务输入输出对应 DRG 变量诊断抽取出院诊断、病程记录ICD 编码候选主要诊断、其他诊断手术操作抽取手术记录、操作记录ICD-9-CM-3 编码候选主要手术并发症判定其他诊断 病程描述CC/MCC 标志CC/MCC 等级入院病情判定现病史、入院记录入院时已有/新发排除规则关键点不要试图让模型一次性输出所有字段。分任务抽取的准确率比合并抽取高 15% 以上这是我对比过三版 prompt 之后的结论。2.2 病历预处理把脏文本变成模型能吃的输入电子病历的脏是出了名的。同一份文档里混着模板残留、复制粘贴的重复段落、检验值表格、护理记录时间线。直接丢给模型token 浪费不说还会干扰抽取。预处理我一般做三件事import re def clean_emr_text(raw_text: str) - str: # 1. 去掉模板占位符和未填充字段 text re.sub(r【[^】]*】, , raw_text) # 去掉【待填】类标记 text re.sub(r\{[^}]*\}, , text) # 去掉{模板变量} # 2. 合并被换行打断的句子病历常见问题 text re.sub(r(?[^。\n])\n(?[^。\n]), , text) # 3. 去掉纯检验值行保留有临床描述的 lines text.split(\n) cleaned [] for line in lines: # 跳过纯数字单位的行如 白细胞 12.3 ↑ if re.match(r^[\u4e00-\u9fa5]\s*[\d.]\s*[↑↓]?\s*$, line.strip()): continue cleaned.append(line) return \n.join(cleaned)这段代码的逻辑第一步去掉模板残留第二步修复断句第三步过滤纯检验值行。参数上正则里的[^。\n]是中文病历常见的句末标点集合如果你的病历用英文标点需要相应调整。注意第三步不要过滤太狠——「血糖 12.3mmol/L控制不佳」这种带描述的行必须保留因为「控制不佳」是并发症判定的关键语义。提示预处理阶段不要做同义词替换或实体归一化这些留给模型做。预处理只做「去噪」不做「理解」。2.3 DeepSeek API 调用抽取任务的 prompt 设计与参数配置调用 DeepSeek API 做抽取核心是 prompt 的结构化程度。我试过三种方案纯指令、few-shot、JSON schema 约束。最终稳定用的是「角色 任务 输出格式 边界规则」四段式。import json from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.deepseek.com # DeepSeek 兼容 OpenAI SDK ) EXTRACT_PROMPT 你是医保 DRG 入组辅助系统。从以下病历文本中抽取诊断信息。 规则 1. 只抽取明确诊断不抽取症状描述如头痛不是诊断 2. 区分主要诊断和其他诊断主要诊断通常是出院诊断第一条 3. 标注每个诊断的入院病情1入院时已有2入院后新发 4. 如果诊断有分期/分型必须完整保留如糖尿病肾病Ⅲ期不能简化为糖尿病肾病 5. 输出 JSON 数组每个元素包含diagnosis, is_primary, admission_condition, evidence 病历文本 {emr_text} 输出 def extract_diagnosis(emr_text: str) - list: response client.chat.completions.create( modeldeepseek-chat, messages[ {role: user, content: EXTRACT_PROMPT.format(emr_textemr_text)} ], temperature0.1, # 抽取任务必须低温保证稳定性 max_tokens2048, response_format{type: json_object} # 强制 JSON 输出 ) result json.loads(response.choices[0].message.content) return result.get(diagnoses, [])参数说明temperature0.1是抽取任务的标配高于 0.3 会出现同一份病历两次抽取结果不一致的情况。response_format设为 JSON 可以避免模型输出多余解释文字但注意 DeepSeek 的 JSON 模式要求 prompt 里必须出现 json 字样否则会报错。max_tokens设 2048 是因为一份复杂病历的诊断列表可能很长设太小会截断。evidence字段是我强制要求模型输出的——它必须引用原文中支持该诊断的句子。这个字段在后期人工复核时极其有用相当于给每个抽取结果附了「证据链」。2.4 抽取结果到 DRG 入组的映射与校验模型抽出的诊断是自然语言DRG 分组器要的是 ICD 编码。这一步不能全靠模型我一般用「模型 编码库」双通道def map_to_icd(diagnosis_list: list, icd_db: dict) - list: 将自然语言诊断映射到 ICD 编码 icd_db: {诊断名: ICD编码} 的本地编码库 mapped [] for diag in diagnosis_list: name diag[diagnosis] # 精确匹配优先 if name in icd_db: diag[icd_code] icd_db[name] diag[match_type] exact else: # 模糊匹配取编码库中编辑距离最近的候选 candidates fuzzy_match(name, icd_db.keys(), threshold0.85) if candidates: diag[icd_code] icd_db[candidates[0]] diag[match_type] fuzzy diag[need_review] True # 模糊匹配的标记人工复核 else: diag[icd_code] None diag[need_review] True mapped.append(diag) return mapped逻辑说明精确匹配直接落码模糊匹配设 0.85 的阈值是经验值——低于这个值误匹配率飙升。所有模糊匹配的结果都打上need_review标记因为 ICD 编码错一位DRG 组别可能差好几千块钱。这一步的校验规则是如果主要诊断没有匹配到编码整份病历转人工不进入自动分组流程。3. 调优实战让 DeepSeek 在病历抽取上从 70% 到 92% 的四个动作3.1 用科室维度的 few-shot 替代通用 prompt通用 prompt 在三甲医院综合病历上跑诊断抽取的 F1 大概在 70% 左右。问题出在科室差异心内科的「心功能Ⅲ级」是诊断呼吸科的「呼吸衰竭Ⅱ型」是诊断但骨科的「术后第一天」不是诊断。通用规则覆盖不了这些边界。我的做法是按科室建 few-shot 示例库。每个科室准备 5 到 8 个标注样本拼进 promptFEW_SHOT_BY_DEPT { 心内科: [ {text: 出院诊断1.冠心病 2.心功能Ⅲ级, output: [{diagnosis: 冠心病, is_primary: True}, {diagnosis: 心功能Ⅲ级, is_primary: False}]}, # ... 更多示例 ], 呼吸科: [...], } def build_prompt(emr_text: str, dept: str) - str: examples FEW_SHOT_BY_DEPT.get(dept, []) example_str \n.join([ f输入{e[text]}\n输出{json.dumps(e[output], ensure_asciiFalse)} for e in examples ]) return f{EXTRACT_PROMPT}\n\n参考示例\n{example_str}\n\n病历文本\n{emr_text}这个改动的效果最明显心内科 F1 从 71% 提到 89%呼吸科从 68% 提到 86%。代价是 prompt 变长单次调用 token 增加约 800按 DeepSeek 的价格算每万份病历多花不到 20 块钱完全值得。3.2 否定与不确定语义的专项处理病历里最坑的是否定句和不确定描述。「排除恶性肿瘤」「暂不考虑系统性红斑狼疮」「恶性肿瘤待排」——这些如果被当成阳性诊断抽出来DRG 直接入错组。我在 prompt 里加了否定规则但模型仍然会漏。后来加了一层后处理NEGATION_PATTERNS [ r排除[了]?, r暂不考虑, r待排[除]?, r未见, r无[明显]?, r不除外, r疑似, r考虑.*可能 ] def check_negation(diagnosis: str, evidence: str) - bool: 检查诊断是否被否定或不确定修饰 for pattern in NEGATION_PATTERNS: if re.search(pattern r.{0,10} re.escape(diagnosis), evidence): return True # 被否定 return False注意「不除外」和「疑似」这类词——它们不是否定是不确定。处理方式不同否定直接丢弃不确定的保留但标记uncertainTrue转人工确认。这个区分很关键我见过有团队把「不除外肺癌」直接丢掉结果漏了该入组的病例。3.3 批量调优并发控制与结果缓存医院一天出院几百份病历串行调用 API 太慢。我一般用并发 缓存两层优化import hashlib from concurrent.futures import ThreadPoolExecutor cache {} # 生产环境用 Redis def extract_with_cache(emr_text: str, dept: str) - list: # 用文本哈希做缓存键 cache_key hashlib.md5((emr_text dept).encode()).hexdigest() if cache_key in cache: return cache[cache_key] result extract_diagnosis(build_prompt(emr_text, dept)) cache[cache_key] result return result def batch_extract(emr_list: list, max_workers: int 8) - list: with ThreadPoolExecutor(max_workersmax_workers) as executor: futures [ executor.submit(extract_with_cache, emr[text], emr[dept]) for emr in emr_list ] return [f.result() for f in futures]max_workers8是我实测的稳定值——再高会触发 API 限流反而变慢。缓存的意义在于同一份病历在预分组、复核、申诉三个环节都会被调用缓存命中率能到 60% 以上省下的 token 成本相当可观。3.4 用规则引擎兜底模型不是万能的有些字段模型就是抽不准比如「入院病情」——是入院时就有还是入院后新发。这个判断需要结合入院记录和病程记录的时间线模型容易搞混。我的做法是用规则引擎兜底def determine_admission_condition(diagnosis: str, admission_note: str, progress_notes: str) - int: 1入院时已有2入院后新发3不确定 # 如果诊断出现在入院记录中标记为入院时已有 if diagnosis in admission_note: return 1 # 如果诊断只出现在病程记录中且入院记录无相关描述 if diagnosis in progress_notes and diagnosis not in admission_note: return 2 return 3 # 不确定转人工这个规则简单但有效。模型负责从自由文本里找诊断规则负责判断时间关系。两者结合入院病情判定的准确率从纯模型的 76% 提到 94%。4. 避坑指南病历语义抽取到 DRG 入组的五个翻车现场4.1 坑一模型把「既往史」里的诊断当成现病史诊断现象一份因「急性阑尾炎」入院的病历模型抽出了「高血压」「2型糖尿病」作为其他诊断但这两个诊断写在既往史里本次住院并未针对它们做任何处理。DRG 分组器把它们当成 CC导致入组偏高。原因模型分不清「既往史」和「现病史」的语义边界。prompt 里没有明确告诉它「既往史中的诊断如果不影响本次住院不应作为其他诊断」。解决在 prompt 里加一条规则——「既往史中的诊断只有在本次住院期间有治疗、检查或影响治疗决策时才作为其他诊断输出」。同时在输出字段里加source_section标记来源段落后处理时对source_section既往史的诊断做二次确认。4.2 坑二ICD 编码模糊匹配把「糖尿病」匹配到「糖尿病性白内障」现象模糊匹配阈值设 0.8 时「糖尿病」匹配到了「糖尿病性白内障」的编码因为编辑距离近。结果一个单纯糖尿病被当成有并发症DRG 组别跳了两级。原因模糊匹配只看字符串相似度不看临床语义。糖尿病和糖尿病性白内障在字符串上确实像但临床含义完全不同。解决模糊匹配的候选列表必须加临床约束——如果诊断名是另一个诊断名的前缀优先匹配短的。同时把阈值从 0.8 提到 0.85并且所有模糊匹配结果强制人工复核。更稳妥的做法是维护一份「不可模糊匹配」的高风险诊断列表这些诊断必须精确匹配。4.3 坑三DeepSeek API 返回的 JSON 被截断现象一份诊断列表很长的病历API 返回的 JSON 不完整json.loads直接报错。原因max_tokens设小了或者模型在 JSON 末尾输出了多余的解释文字导致解析失败。解决第一max_tokens至少设 2048复杂病历设 4096。第二解析前先做清洗——找到第一个{和最后一个}截取中间部分再解析。第三加 try-except 兜底解析失败时降级为纯文本抽取不让整个流程挂掉。4.4 坑四并发调用触发限流导致批量任务大面积失败现象用 16 个线程并发调 API前 50 份病历正常之后大量返回 429 错误。原因DeepSeek API 有 QPS 限制并发数超过阈值直接限流。解决并发数控制在 8 以内并且加指数退避重试import time def call_with_retry(func, max_retries3): for i in range(max_retries): try: return func() except Exception as e: if 429 in str(e) and i max_retries - 1: time.sleep(2 ** i) # 1s, 2s, 4s else: raise4.5 坑五预处理把关键否定词过滤掉了现象一份病历的「排除肺结核」在预处理阶段被当成模板标记去掉了结果模型没看到否定信息把肺结核抽成了阳性诊断。原因预处理的正则【[^】]*】太激进把一些用方括号标注的临床描述也去掉了。解决预处理规则要窄——只去掉明确的模板占位符如「【待填】」「【请选择】」不要用通用方括号匹配。更安全的做法是预处理后做一次人工抽检确认没有误删关键信息。5. 把抽取准确率再往上推验证集构建与持续调优的一个具体技巧调优到 92% 之后再往上每提一个点都很难。我的经验是与其盲目改 prompt不如先建一个靠谱的验证集。具体做法从历史病历里随机抽 200 份覆盖主要科室每份由两名编码员独立标注诊断和 ICD 编码不一致的由第三名仲裁。这 200 份就是你的「金标准」。每次改 prompt 或换模型版本都在这 200 份上跑一遍看 F1 变化。没有验证集的调优就是玄学——你改了一个词感觉好像好了实际上可能只是这一批病历碰巧简单。验证集建好之后重点看两类错误假阳性模型抽了不该抽的和假阴性该抽的没抽到。这两类的调优方向完全不同。假阳性多就加否定规则和边界约束假阴性多就加 few-shot 示例和放宽抽取条件。我一般每周跑一次全量验证记录 F1 变化连续两周下降就回滚 prompt 版本。还有一个技巧把模型置信度低的抽取结果单独拿出来人工复核后补充进 few-shot 示例库。这样示例库会越来越贴合你的实际病历分布形成正向循环。我靠这个办法在三个月内把整体 F1 从 92% 推到了 95.3%而且没有换模型、没有加标注数据。最后说一个血泪教训不要追求 100% 准确率。医疗场景下模型抽取出错是必然的关键是建立「模型抽取 规则校验 人工复核」的三层防线。把模型的定位定在「减少人工工作量」而不是「替代人工」心态会好很多落地也会顺很多。希望帮到你。本文还有配套的精品资源点击获取 基于DeepSeek的病历语义抽取：从70%到92%的DRG入组优化实战
简介这份调优手册面向医疗信息化从业者、医保控费研究人员及自然语言处理工程师聚焦医疗电子病历挖掘与DRG医保控费场景系统讲解如何借助DeepSeek语义理解技术提升病历分组准确性与控费效率。资源为1个PDF文件压缩包约1.98MB内容完整、目录清晰涵盖引言、医疗电子病历挖掘与DRG概述、DeepSeek语义理解技术基础、调优前准备、数据预处理调优、模型架构调优、训练参数调优、模型评估与监控、常见问题解决方案及实践案例分享等模块。读者可从中获得从数据清洗、标注优化、特征提取到学习率、批量大小、正则化参数调整的完整调优思路并了解注意力增强模块、知识图谱融合等进阶方法以及模型部署与动态监控的排错经验。目前已有79人学习适合希望将DeepSeek落地于医疗文本分析、提升医保控费精度的中高级读者参考。1. 病历文本里藏着医保亏损的答案为什么 DRG 控费需要语义理解而不是关键词匹配一份 800 字的出院小结DRG 分组器只认其中 30 来个关键词剩下的信息全被丢掉。问题在于真正决定入组的往往不是「2型糖尿病」这五个字而是「血糖控制不佳」「合并糖尿病肾病Ⅲ期」「近三月反复因酮症住院」这些散落在病程记录里的语义线索。关键词匹配抓不到否定、抓不到程度、抓不到时间关系于是该入 ADRG 的进了保守组该有并发症的按单纯病种结算月底一算科室亏了十几万。这就是医疗电子病历挖掘要解决的事把非结构化的病历文本变成 DRG 分组器能吃的结构化证据。DeepSeek 这类大模型的价值不在「生成」而在「抽取」——从自由文本里稳定地拉出诊断、手术、并发症、入院病情这些入组要素。这套方案适合三类人医院信息科要做 DRG 预分组的、医保办要做事前控费的、以及做医疗 NLP 落地但被标注数据卡住的工程师。接下来我把从病历清洗到 DeepSeek 语义抽取再到 DRG 入组校验的完整链路拆开讲包括参数怎么设、哪些坑我踩过。2. 从病历原文到 DRG 入组要素语义抽取链路的四个环节2.1 先搞清楚 DRG 分组器到底要什么字段DRG 分组不是黑匣子它的输入是有限且明确的。以 CN-DRG 为例核心入组变量包括主要诊断MDC 决定大类、主要手术/操作、其他诊断决定 CC/MCC 等级、年龄、新生儿体重、出院方式。其中「其他诊断」是否构成并发症或合并症直接影响是进无 CC 组还是有 CC/MCC 组费率差距通常在 30% 到 80%。所以语义抽取的目标不是「理解整份病历」而是精准命中这几类字段。我一般把抽取任务拆成四个子任务子任务输入输出对应 DRG 变量诊断抽取出院诊断、病程记录ICD 编码候选主要诊断、其他诊断手术操作抽取手术记录、操作记录ICD-9-CM-3 编码候选主要手术并发症判定其他诊断 病程描述CC/MCC 标志CC/MCC 等级入院病情判定现病史、入院记录入院时已有/新发排除规则关键点不要试图让模型一次性输出所有字段。分任务抽取的准确率比合并抽取高 15% 以上这是我对比过三版 prompt 之后的结论。2.2 病历预处理把脏文本变成模型能吃的输入电子病历的脏是出了名的。同一份文档里混着模板残留、复制粘贴的重复段落、检验值表格、护理记录时间线。直接丢给模型token 浪费不说还会干扰抽取。预处理我一般做三件事import re def clean_emr_text(raw_text: str) - str: # 1. 去掉模板占位符和未填充字段 text re.sub(r【[^】]*】, , raw_text) # 去掉【待填】类标记 text re.sub(r\{[^}]*\}, , text) # 去掉{模板变量} # 2. 合并被换行打断的句子病历常见问题 text re.sub(r(?[^。\n])\n(?[^。\n]), , text) # 3. 去掉纯检验值行保留有临床描述的 lines text.split(\n) cleaned [] for line in lines: # 跳过纯数字单位的行如 白细胞 12.3 ↑ if re.match(r^[\u4e00-\u9fa5]\s*[\d.]\s*[↑↓]?\s*$, line.strip()): continue cleaned.append(line) return \n.join(cleaned)这段代码的逻辑第一步去掉模板残留第二步修复断句第三步过滤纯检验值行。参数上正则里的[^。\n]是中文病历常见的句末标点集合如果你的病历用英文标点需要相应调整。注意第三步不要过滤太狠——「血糖 12.3mmol/L控制不佳」这种带描述的行必须保留因为「控制不佳」是并发症判定的关键语义。提示预处理阶段不要做同义词替换或实体归一化这些留给模型做。预处理只做「去噪」不做「理解」。2.3 DeepSeek API 调用抽取任务的 prompt 设计与参数配置调用 DeepSeek API 做抽取核心是 prompt 的结构化程度。我试过三种方案纯指令、few-shot、JSON schema 约束。最终稳定用的是「角色 任务 输出格式 边界规则」四段式。import json from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.deepseek.com # DeepSeek 兼容 OpenAI SDK ) EXTRACT_PROMPT 你是医保 DRG 入组辅助系统。从以下病历文本中抽取诊断信息。 规则 1. 只抽取明确诊断不抽取症状描述如头痛不是诊断 2. 区分主要诊断和其他诊断主要诊断通常是出院诊断第一条 3. 标注每个诊断的入院病情1入院时已有2入院后新发 4. 如果诊断有分期/分型必须完整保留如糖尿病肾病Ⅲ期不能简化为糖尿病肾病 5. 输出 JSON 数组每个元素包含diagnosis, is_primary, admission_condition, evidence 病历文本 {emr_text} 输出 def extract_diagnosis(emr_text: str) - list: response client.chat.completions.create( modeldeepseek-chat, messages[ {role: user, content: EXTRACT_PROMPT.format(emr_textemr_text)} ], temperature0.1, # 抽取任务必须低温保证稳定性 max_tokens2048, response_format{type: json_object} # 强制 JSON 输出 ) result json.loads(response.choices[0].message.content) return result.get(diagnoses, [])参数说明temperature0.1是抽取任务的标配高于 0.3 会出现同一份病历两次抽取结果不一致的情况。response_format设为 JSON 可以避免模型输出多余解释文字但注意 DeepSeek 的 JSON 模式要求 prompt 里必须出现 json 字样否则会报错。max_tokens设 2048 是因为一份复杂病历的诊断列表可能很长设太小会截断。evidence字段是我强制要求模型输出的——它必须引用原文中支持该诊断的句子。这个字段在后期人工复核时极其有用相当于给每个抽取结果附了「证据链」。2.4 抽取结果到 DRG 入组的映射与校验模型抽出的诊断是自然语言DRG 分组器要的是 ICD 编码。这一步不能全靠模型我一般用「模型 编码库」双通道def map_to_icd(diagnosis_list: list, icd_db: dict) - list: 将自然语言诊断映射到 ICD 编码 icd_db: {诊断名: ICD编码} 的本地编码库 mapped [] for diag in diagnosis_list: name diag[diagnosis] # 精确匹配优先 if name in icd_db: diag[icd_code] icd_db[name] diag[match_type] exact else: # 模糊匹配取编码库中编辑距离最近的候选 candidates fuzzy_match(name, icd_db.keys(), threshold0.85) if candidates: diag[icd_code] icd_db[candidates[0]] diag[match_type] fuzzy diag[need_review] True # 模糊匹配的标记人工复核 else: diag[icd_code] None diag[need_review] True mapped.append(diag) return mapped逻辑说明精确匹配直接落码模糊匹配设 0.85 的阈值是经验值——低于这个值误匹配率飙升。所有模糊匹配的结果都打上need_review标记因为 ICD 编码错一位DRG 组别可能差好几千块钱。这一步的校验规则是如果主要诊断没有匹配到编码整份病历转人工不进入自动分组流程。3. 调优实战让 DeepSeek 在病历抽取上从 70% 到 92% 的四个动作3.1 用科室维度的 few-shot 替代通用 prompt通用 prompt 在三甲医院综合病历上跑诊断抽取的 F1 大概在 70% 左右。问题出在科室差异心内科的「心功能Ⅲ级」是诊断呼吸科的「呼吸衰竭Ⅱ型」是诊断但骨科的「术后第一天」不是诊断。通用规则覆盖不了这些边界。我的做法是按科室建 few-shot 示例库。每个科室准备 5 到 8 个标注样本拼进 promptFEW_SHOT_BY_DEPT { 心内科: [ {text: 出院诊断1.冠心病 2.心功能Ⅲ级, output: [{diagnosis: 冠心病, is_primary: True}, {diagnosis: 心功能Ⅲ级, is_primary: False}]}, # ... 更多示例 ], 呼吸科: [...], } def build_prompt(emr_text: str, dept: str) - str: examples FEW_SHOT_BY_DEPT.get(dept, []) example_str \n.join([ f输入{e[text]}\n输出{json.dumps(e[output], ensure_asciiFalse)} for e in examples ]) return f{EXTRACT_PROMPT}\n\n参考示例\n{example_str}\n\n病历文本\n{emr_text}这个改动的效果最明显心内科 F1 从 71% 提到 89%呼吸科从 68% 提到 86%。代价是 prompt 变长单次调用 token 增加约 800按 DeepSeek 的价格算每万份病历多花不到 20 块钱完全值得。3.2 否定与不确定语义的专项处理病历里最坑的是否定句和不确定描述。「排除恶性肿瘤」「暂不考虑系统性红斑狼疮」「恶性肿瘤待排」——这些如果被当成阳性诊断抽出来DRG 直接入错组。我在 prompt 里加了否定规则但模型仍然会漏。后来加了一层后处理NEGATION_PATTERNS [ r排除[了]?, r暂不考虑, r待排[除]?, r未见, r无[明显]?, r不除外, r疑似, r考虑.*可能 ] def check_negation(diagnosis: str, evidence: str) - bool: 检查诊断是否被否定或不确定修饰 for pattern in NEGATION_PATTERNS: if re.search(pattern r.{0,10} re.escape(diagnosis), evidence): return True # 被否定 return False注意「不除外」和「疑似」这类词——它们不是否定是不确定。处理方式不同否定直接丢弃不确定的保留但标记uncertainTrue转人工确认。这个区分很关键我见过有团队把「不除外肺癌」直接丢掉结果漏了该入组的病例。3.3 批量调优并发控制与结果缓存医院一天出院几百份病历串行调用 API 太慢。我一般用并发 缓存两层优化import hashlib from concurrent.futures import ThreadPoolExecutor cache {} # 生产环境用 Redis def extract_with_cache(emr_text: str, dept: str) - list: # 用文本哈希做缓存键 cache_key hashlib.md5((emr_text dept).encode()).hexdigest() if cache_key in cache: return cache[cache_key] result extract_diagnosis(build_prompt(emr_text, dept)) cache[cache_key] result return result def batch_extract(emr_list: list, max_workers: int 8) - list: with ThreadPoolExecutor(max_workersmax_workers) as executor: futures [ executor.submit(extract_with_cache, emr[text], emr[dept]) for emr in emr_list ] return [f.result() for f in futures]max_workers8是我实测的稳定值——再高会触发 API 限流反而变慢。缓存的意义在于同一份病历在预分组、复核、申诉三个环节都会被调用缓存命中率能到 60% 以上省下的 token 成本相当可观。3.4 用规则引擎兜底模型不是万能的有些字段模型就是抽不准比如「入院病情」——是入院时就有还是入院后新发。这个判断需要结合入院记录和病程记录的时间线模型容易搞混。我的做法是用规则引擎兜底def determine_admission_condition(diagnosis: str, admission_note: str, progress_notes: str) - int: 1入院时已有2入院后新发3不确定 # 如果诊断出现在入院记录中标记为入院时已有 if diagnosis in admission_note: return 1 # 如果诊断只出现在病程记录中且入院记录无相关描述 if diagnosis in progress_notes and diagnosis not in admission_note: return 2 return 3 # 不确定转人工这个规则简单但有效。模型负责从自由文本里找诊断规则负责判断时间关系。两者结合入院病情判定的准确率从纯模型的 76% 提到 94%。4. 避坑指南病历语义抽取到 DRG 入组的五个翻车现场4.1 坑一模型把「既往史」里的诊断当成现病史诊断现象一份因「急性阑尾炎」入院的病历模型抽出了「高血压」「2型糖尿病」作为其他诊断但这两个诊断写在既往史里本次住院并未针对它们做任何处理。DRG 分组器把它们当成 CC导致入组偏高。原因模型分不清「既往史」和「现病史」的语义边界。prompt 里没有明确告诉它「既往史中的诊断如果不影响本次住院不应作为其他诊断」。解决在 prompt 里加一条规则——「既往史中的诊断只有在本次住院期间有治疗、检查或影响治疗决策时才作为其他诊断输出」。同时在输出字段里加source_section标记来源段落后处理时对source_section既往史的诊断做二次确认。4.2 坑二ICD 编码模糊匹配把「糖尿病」匹配到「糖尿病性白内障」现象模糊匹配阈值设 0.8 时「糖尿病」匹配到了「糖尿病性白内障」的编码因为编辑距离近。结果一个单纯糖尿病被当成有并发症DRG 组别跳了两级。原因模糊匹配只看字符串相似度不看临床语义。糖尿病和糖尿病性白内障在字符串上确实像但临床含义完全不同。解决模糊匹配的候选列表必须加临床约束——如果诊断名是另一个诊断名的前缀优先匹配短的。同时把阈值从 0.8 提到 0.85并且所有模糊匹配结果强制人工复核。更稳妥的做法是维护一份「不可模糊匹配」的高风险诊断列表这些诊断必须精确匹配。4.3 坑三DeepSeek API 返回的 JSON 被截断现象一份诊断列表很长的病历API 返回的 JSON 不完整json.loads直接报错。原因max_tokens设小了或者模型在 JSON 末尾输出了多余的解释文字导致解析失败。解决第一max_tokens至少设 2048复杂病历设 4096。第二解析前先做清洗——找到第一个{和最后一个}截取中间部分再解析。第三加 try-except 兜底解析失败时降级为纯文本抽取不让整个流程挂掉。4.4 坑四并发调用触发限流导致批量任务大面积失败现象用 16 个线程并发调 API前 50 份病历正常之后大量返回 429 错误。原因DeepSeek API 有 QPS 限制并发数超过阈值直接限流。解决并发数控制在 8 以内并且加指数退避重试import time def call_with_retry(func, max_retries3): for i in range(max_retries): try: return func() except Exception as e: if 429 in str(e) and i max_retries - 1: time.sleep(2 ** i) # 1s, 2s, 4s else: raise4.5 坑五预处理把关键否定词过滤掉了现象一份病历的「排除肺结核」在预处理阶段被当成模板标记去掉了结果模型没看到否定信息把肺结核抽成了阳性诊断。原因预处理的正则【[^】]*】太激进把一些用方括号标注的临床描述也去掉了。解决预处理规则要窄——只去掉明确的模板占位符如「【待填】」「【请选择】」不要用通用方括号匹配。更安全的做法是预处理后做一次人工抽检确认没有误删关键信息。5. 把抽取准确率再往上推验证集构建与持续调优的一个具体技巧调优到 92% 之后再往上每提一个点都很难。我的经验是与其盲目改 prompt不如先建一个靠谱的验证集。具体做法从历史病历里随机抽 200 份覆盖主要科室每份由两名编码员独立标注诊断和 ICD 编码不一致的由第三名仲裁。这 200 份就是你的「金标准」。每次改 prompt 或换模型版本都在这 200 份上跑一遍看 F1 变化。没有验证集的调优就是玄学——你改了一个词感觉好像好了实际上可能只是这一批病历碰巧简单。验证集建好之后重点看两类错误假阳性模型抽了不该抽的和假阴性该抽的没抽到。这两类的调优方向完全不同。假阳性多就加否定规则和边界约束假阴性多就加 few-shot 示例和放宽抽取条件。我一般每周跑一次全量验证记录 F1 变化连续两周下降就回滚 prompt 版本。还有一个技巧把模型置信度低的抽取结果单独拿出来人工复核后补充进 few-shot 示例库。这样示例库会越来越贴合你的实际病历分布形成正向循环。我靠这个办法在三个月内把整体 F1 从 92% 推到了 95.3%而且没有换模型、没有加标注数据。最后说一个血泪教训不要追求 100% 准确率。医疗场景下模型抽取出错是必然的关键是建立「模型抽取 规则校验 人工复核」的三层防线。把模型的定位定在「减少人工工作量」而不是「替代人工」心态会好很多落地也会顺很多。希望帮到你。本文还有配套的精品资源点击获取