简介：这是一份面向医疗信息化从业者、数据挖掘工程师和医保控费研究人员的DeepSeek调优手册，聚焦医疗电子病历挖掘与DRG医保控费场景中的语义理解落地难题。文档共26页，内容从DRG基本概念与病历挖掘任务的关系切入，逐步展开DeepSeek技术原理、数据清洗与标注优化、模型架构调整、学习率与批量大小设置、评估监控指标及常见问题解决方案，并配有基于Python的简单示例和实践案例。其中数据预处理环节覆盖噪声去除、缺失值处理、特征提取与数据平衡；模型调优环节还引入注意力增强、知识图谱融合等进阶策略。资源以1个PDF文件打包，体积仅1.98MB，目录完整、文字图表显示正常，便于按章节查阅。目前已有79人学习，适合希望在医疗文本场景中优化模型效果、提升分组准确性和控费效率的读者。
1. 医疗电子病历挖掘与DRG医保控费：DeepSeek语义理解到底解哪道题
医疗电子病历挖掘这件事，最难的不是从病历里找出“冠心病”“PCI术”这些词，而是把几百份出院小结翻完后，还能保证每一份的主诊断、其他诊断、并发症和合并症都被编码员看全。DRG医保控费场景里，漏一个并发症，病例就从“不伴合并症组”滑到“伴合并症组”，医保支付差出几千甚至上万；多报一个既往病史里的陈旧性心梗当本次并发症，又成了编码高靠。DeepSeek语义理解技术被引入这条流水线，就是为了用大模型的上下文理解把非结构化的电子病历转成结构化的入组要素。这篇笔记按调优手册的写法，把参数三件套、Prompt约束、后处理校验和排错经验一次讲清，适合医院信息科、医保办和做DRG医疗数据挖掘的算法工程师照着落地。
2. 从病历文本到DRG入组：一条先“抽取”后“预测”的落地管线
2.1 DRG入组到底需要从病历里挖出哪四样东西
DRG分组的计算依据可以被压缩成一句话：主诊断决定内科组还是外科组，主要操作把外科病例细分，并发症与合并症（CC/MCC）再决定病例落在哪个支付档。所以我做医疗电子病历挖掘时，不会让模型直接输出“这是哪个DRG组”，而是先让它输出四样东西：主诊断原文和编码、主要手术原文和编码、其他诊断列表、并发症与合并症标记。这四样东西是入组器的输入，也是编码员每天手工在病案首页上填的字段。
用DeepSeek去做这四类抽取，比传统BiLSTM-CRF那套老NER管线强的地方在于长距离语义。电子病历里“既往有2型糖尿病史”“否认高血压病史”这类否定与时间限定，老管线靠规则要写几百条正则，DeepSeek在上下文里就能判断“病史”和“现患”的区别。另一个优势是零样本迁移：换一家医院的病历模板，老管线要重标数据，大模型只要在Prompt里换板块样例。
但这里有个很容易走偏的点：DRG入组只认病案首页的“主要诊断”和“主要手术”，而模型从出院小结里抽出来的诊断往往有三四十个。按医保版DRG逻辑，主要诊断要选“消耗医疗资源最多、住院时间最长”的那个。我一般在Prompt里加一句“优先选择本次住院治疗的核心疾病”，并在后处理里做规则排序，而不是把问题全扔给模型。把这一层想清楚，后文所有参数调优才有意义。
| 抽取字段 | 主要来源板块 | 输出示例 | 入组作用 |
|---|---|---|---|
| 主诊断 | 出院诊断/入院诊断 | 急性ST段抬高型心肌梗死（I21.0） | 决定ADRG内/外科方向 |
| 主要手术 | 手术记录/操作记录 | 经皮冠状动脉介入治疗（00.66） | 外科组细分 |
| 其他诊断 | 出院诊断 | 2型糖尿病（E11.9） | CC/MCC判定 |
| 并发症/合并症 | 出院诊断+病程记录 | 本例合并心力衰竭（I50.9） | 决定权重档位 |
2.2 最小可行管线：五个步骤把EMR变成结构化入组要素
我的落地顺序是五步：取数、脱敏、切块、抽取、入组预判。取数阶段，电子病历的格式千差万别，医院HIS里导出的可能是结构化字段、Word文档、扫描PDF经OCR的三种混合体。我一般统一转成JSON，至少保留下“入院记录”“出院小结”“手术记录”三个板块，这三个板块占了DRG入组九成以上的判断依据。
脱敏不是可选项，姓名、身份证号、住院号、家庭住址全部替换成匿名ID，再决定是走院内本地模型还是云端接口。医院数据出域这件事很敏感，我见过的大部分项目最终选择在院内一台GPU服务器上用vLLM拉起DeepSeek的本地服务，理由就一条：病历不进外部网络，模型服务端口只开在院内。这个部署方式对调优手册的意义在于，API调用参数和本地vLLM完全一致，下面这段代码里的本地地址按实际环境改就行。
import json from openai import OpenAI # 院内本地服务，vLLM 拉起后暴露 OpenAI 兼容接口 client = OpenAI( api_key="EMPTY", base_url="http://127.0.0.1:8000/v1" # 端口按实际部署修改 ) def build_prompt(record: dict) -> str: return f"""你是病案编码助手。请只依据下面给出的病历文本，抽取DRG入组所需信息。 “既往史”里提到的疾病不能算作本次并发症。 【出院小结】 {record.get("discharge_summary", "")} 【手术记录】 {record.get("operation_record", "")} 输出JSON： {{ "principal_diag_text": "主诊断原文", "principal_diag_icd": "主诊断ICD-10编码", "principal_op_text": "主要手术原文，无手术则为空串", "principal_op_icd": "主要手术编码，无手术则为空串", "other_diags": [{{"text": "诊断原文", "icd": "编码"}}], "cc_items": [{{"text": "并发症原文", "type": "CC/MCC"}}] }} """ def extract(record: dict) -> str: resp = client.chat.completions.create( model="deepseek-chat", # 本地部署时换成vLLM注册名 messages=[{"role": "user", "content": build_prompt(record)}], temperature=0.1, # 抽取任务尽量低随机性 top_p=0.2, presence_penalty=0.0, frequency_penalty=0.0, max_tokens=1500, ) return resp.choices[0].message.content代码逻辑分三段：第一段构造客户端，把地址指向本地vLLM服务或云端兼容接口；第二段是Prompt模板，注意我在提示里专门写了“既往史里的疾病不能算作本次并发症”，这句话是针对DRG高靠风险做的第一层约束，比单纯抽实体重要得多；第三段是调用参数，temperature、top_p、presence_penalty这三个参数是本手册的调优三件套，抽取任务用低随机性组合，后文会专门讲每个参数怎么调。
五步里最容易被人忽略的是“入组预判”这一步。模型输出JSON之后，要接一个院内分组器接口或按DRG分组逻辑表做映射，得到预测组号。组号能进一步映射到权重和支付标准，让业务方直观看到“模型改一个并发症标记，支付档位差多少”。这一步不做，调优就还是停留在文本层面，没有落到钱上。
2.3 按板块抽取与整篇抽取的差距：为什么我坚持切块
早期我做了一个很朴素版本：把整份病历文本一次性丢给模型，让它输出所有诊断。结果发现两个问题。第一，出院小结末尾“出院诊断”板块通常是编码员认定的最终结论，但病历中间“初步诊断”和“入院诊断”的措辞经常和它打架，模型容易把不同板块的诊断混在一起去重，导致主诊断选错。第二，手术记录里的一句话“行PCI术”是主手术的依据，但整篇输入时模型会把“建议行冠脉造影”这种治疗建议也当成已执行手术。
现在的做法是切块输入，把“出院诊断”“入院诊断”“既往史”“手术记录”作为独立章节放进Prompt，并且每个板块前加一行语义说明。这样做的代价是Prompt变长，但换来的是抽取结果和病案首页的逻辑对得上。切块这件事不是把病历拆碎就行，关键是要保住“板块名→业务含义”的映射，比如“既往史”板块在DRG里是CC/MCC排除区，不能把这里的糖尿病当成本次并发症。
| 病历板块 | 在DRG入组里的作用 | 容易出的错 |
|---|---|---|
| 出院诊断 | 主诊断和其他诊断的主要来源 | 和入院诊断混选 |
| 入院诊断 | 判断疾病是否本次新发 | 把入院前存在的慢性病当本次诊断 |
| 既往史 | CC/MCC排除区 | 把陈旧性疾病当并发症 |
| 手术记录 | 主手术和操作编码来源 | 把“建议手术”当成已执行手术 |
| 辅助检查 | 支撑CC/MCC判定的客观证据 | 模型读不懂检查缩写 |
3. 调优手册第一页：参数调优三件套与病历场景的取值区间
3.1 temperature、top_p、presence_penalty在抽取任务里分别管什么
参数调优三件套是temperature、top_p、presence_penalty。我见过很多人拿到DeepSeek API第一件事就是照抄默认参数，结果在DRG抽取这类任务上翻车，症状是同一份病历跑两遍，主诊断从“急性胰腺炎”变成“慢性胰腺炎急性发作”，这类随机性对入组是致命的。
temperature控制的是采样的随机程度。病历结构化抽取本质是“给定文本填固定字段”，正确答案的分布很集中，temperature超过0.3就能明显感觉到字段措辞在漂。我的经验是抽取类任务取0到0.1，只有主诊断排序这类需要模型做一点开放性判断时，才放宽到0.2。
top_p控制的是候选词集合的收窄比例。它的作用和temperature重叠，实际调参时一般固定其中一个。在病历场景里我把top_p放到0.1到0.3，配合低temperature，让模型只在概率最高的那部分候选里选词。两个参数不建议同时调大，否则重复运行的结果跳动会非常明显。
presence_penalty是很多人忽略的一个参数，它惩罚模型反复使用同一个词。在病历里，同一个诊断名称会出现很多次，比如“高血压病”在主诉、既往史、出院诊断里各出现一次，presence_penalty一开大，模型就会为了不重复而改写词语，把“高血压病”改成“血压增高”甚至漏掉。所以我在这类任务里把presence_penalty固定为0，不要对病历文本做任何形式的重复惩罚。
注意：参数调优三件套不要同时调大，调参时先固定presence_penalty为零，再只动temperature和top_p。
| 任务类型 | temperature | top_p | presence_penalty | frequency_penalty |
|---|---|---|---|---|
| 结构化字段抽取（诊断/手术/并发症） | 0~0.1 | 0.1~0.3 | 0 | 0 |
| 主诊断排序（从候选中选核心） | 0.1~0.2 | 0.3~0.5 | 0 | 0 |
| 编码质控说明（生成解释文本） | 0.3~0.5 | 0.5~0.7 | 0.1 | 0.1 |
这里的核心思路是：让模型在抽取阶段尽量当一台“只读机器”，把所有创造性留在后面对编码员生成的质控说明里。
3.2 批量调参实验脚本：用入组一致率代替手气调参
参数不是拍脑袋定的，我用一组人工复核过的病历做网格搜索。测试集规模不用大，50份覆盖了高权重DRG组的典型病例就够了，关键是每份都要有人工确认的主诊断、主手术、CC/MCC标签和最终组号。
import itertools, csv from openai import OpenAI client = OpenAI(api_key="EMPTY", base_url="http://127.0.0.1:8000/v1") # test_cases 每项是 (record, gold)，gold["drg_group"] 为人工标好的组号 test_cases = load_gold("drg_test_50.jsonl") param_grid = { "temperature": [0.0, 0.1, 0.3, 0.6, 0.9], "top_p": [0.1, 0.3, 0.9], "presence_penalty": [0.0, 0.3], } def evaluate(temp, top_p, presence): hit = 0 for record, gold in test_cases: raw = extract(record, temp, top_p, presence) pred_group = to_drg_group(parse_json(raw)) # 后处理+分组器 hit += int(pred_group == gold["drg_group"]) return hit / len(test_cases) results = [] for temp, top_p, presence in itertools.product( param_grid["temperature"], param_grid["top_p"], param_grid["presence_penalty"], ): acc = evaluate(temp, top_p, presence) results.append((acc, temp, top_p, presence)) print(f"temp={temp} top_p={top_p} presence={presence} -> {acc:.3f}") results.sort(reverse=True) with open("param_search_result.csv", "w", newline="") as f: writer = csv.writer(f) writer.writerow(["入组一致率", "temperature", "top_p", "presence_penalty"]) writer.writerows(results)这个脚本有两个关键设计。第一个是评估指标用“入组一致率”而不是字段准确率：模型把诊断抽对但ICD编码错一位，DRG组可能没变，业务上不算事故；反过来诊断字段全对但主诊断排序错一个，组号就变了，这是大事。第二是同一份测试集只用来搜索参数，不要拿它做最终效果评估，否则会过拟合这50份病历，换一批新病历指标立刻掉。
跑完网格搜索，我一般会看两张表。第一张是“最优参数组合下哪些病历入组不一致”，逐份人工看是因为参数对的Case往往有共同特征，比如全是产科病历或者全是“操作未执行”的模糊表述；第二张是“参数对指标敏感度”，如果temperature从0.1到0.6入组一致率只差1%，说明这组数据对大模型的前端采样并不敏感，真正的瓶颈在Prompt或后处理上，不用纠结小数点。
3.3 max_tokens与长病历截断：输出空间要留够
调优三件套之外，还有一个常被忽略的是max_tokens。一份带大量既往史和手术记录的出院小结可能到三四千字，模型输出的JSON包括所有其他诊断和并发症条目，经常一千多字。max_tokens设成256，输出会在JSON中间被切断，后处理解析直接失败，表现就是“抽出来的主诊断是空的”，错误提示一点不像截断。
我的习惯是把max_tokens放到1500到2000，并在Prompt里明确“其他诊断只输出与本次住院相关且影响DRG分组的条目，数量不超过15条”。这个数量约束很重要，否则模型会把病历里所有带病名的词都列出来，输出空间还是不够。
另一个我在长病历上遇到的问题确实是输入截断。DeepSeek的上下文窗口虽然大，但端口服务里配置的max_model_len可能被vLLM写成默认值，病历超过长度就被静默截掉后半段。检查方法很简单，在Prompt末尾加一行“请先输出原文总长度”，看返回值和实际字数对不对得上；根治办法是在取数阶段就按“出院诊断+手术记录+既往史”的优先级截断，而不是直接丢太长文本进来。
4. 让抽取结果经得起入组校验：Prompt约束与后处理兜底
4.1 一套面向DRG的病历抽取Prompt模板
参数调得再准，Prompt里没有业务约束也是白搭。我给DRG场景固定下来的一套Prompt模板分四层：角色声明、文本范围、输出约束、反例提示。角色声明只需要一句话“你是病案编码助手”，不要写“你是资深医学专家”这类虚的，因为系统提示里的角色一旦过于“资深”，模型会更倾向补全它认为合理的医学知识，而不是忠于原文。
文本范围是这四层里最关键的。我明确写“只依据本次提供文本，不依据常识补充诊断”，不然模型会把“患者长期口服阿司匹林”脑补成“冠心病”。输出约束里除了JSON格式，还要写明“未提及手术则手术字段为空串”，这是针对幻觉的正面拦截。反例提示则是把医院历史质控里最常抓到的错误写进去，比如“不要把既往史里的陈旧性疾病标为本次并发症”，这比在系统提示里写十句“要准确”有效得多。
def build_drg_prompt(record): template = """你是病案编码助手。只依据下面文本，不依据常识补充。 任务：抽取DRG入组四要素：主诊断、主要手术、其他诊断、并发症(CC/MCC)。 约束： 1. 主诊断必须是本次住院治疗的核心疾病，优先选消耗资源最多者； 2. 既往史、个人史、家族史中的疾病不进入“并发症”字段； 3. 未提及执行的手术，手术字段输出空串； 4. 其他诊断最多15条，只保留与本次住院相关的。 【既往史】 __HISTORY__ 【出院诊断】 __DISCHARGE__ 【手术记录】 __OPERATION__ 输出JSON： {"principal_diag_text":"","principal_diag_icd":"","principal_op_text":"","principal_op_icd":"","other_diags":[{"text":"","icd":""}],"cc_items":[{"text":"","type":"CC/MCC"}]} """ return (template .replace("__HISTORY__", record.get("history", "")[:600]) .replace("__DISCHARGE__", record.get("discharge_diag", "")[:2000]) .replace("__OPERATION__", record.get("operation", "")[:1500]))这套模板的核心是我把三个板块分别截了长度：既往史只留600字，出院诊断留2000字，手术记录留1500字。长度限制不是随意拍的，既往史在DRG入组里只用来做排除判断，长了反而会诱导模型把更多旧病当成现患；出院诊断是主要抽取对象，要给足；手术记录决定外科分组，也不能裁太狠。
4.2 JSON输出校验：正则、院内字典与必填字段三道闸
大模型输出JSON这件事，不同服务的可靠度不一样。DeepSeek的OpenAI兼容接口有的版本支持response_format强制JSON，有的版本不支持，所以我在代码里从来不做“假设输出一定是合法JSON”，而是用一个解析函数做容错：先试json.loads，失败就用正则把最外层花括号里的内容捞出来再解析，再失败就把这条样本丢进“解析失败队列”人工看。
JSON解析过了也不能直接信。我后处理里固定有三道闸：编码格式正则、院内字典归一化、必填字段检查。编码格式这道闸用ICD-10和手术码正则做第一层过滤，防的是模型把“高血压3级”后处理成“I119”又随手补个点号；院内字典归一化是把结果里所有编码去院内编码映射表里比对一次，出现“字典里没有的编码”一律标记待人工确认；必填字段检查保证主诊断字段不为空，手术记录存在但手术字段为空的情况也会被标出来。
import json, re ICD10_RE = re.compile(r"^[A-Z][0-9]{2}(\.[0-9]{1,2})?$") def parse_and_validate(raw: str, icd_dict: set): try: obj = json.loads(raw) except json.JSONDecodeError: m = re.search(r"\{.*\}", raw, re.S) if not m: return None, ["JSON解析失败"] obj = json.loads(m.group(0)) errs = [] if not obj.get("principal_diag_text") or not obj.get("principal_diag_icd"): errs.append("主诊断缺失") elif not ICD10_RE.match(obj["principal_diag_icd"]): errs.append(f"主诊断编码格式异常: {obj['principal_diag_icd']}") elif obj["principal_diag_icd"] not in icd_dict: errs.append(f"主诊断编码不在院内字典: {obj['principal_diag_icd']}") if obj.get("principal_op_text") and not obj.get("principal_op_icd"): errs.append("手术文本存在但编码为空") return obj, errs这段代码的逻辑是分层失败：先管JSON格式，再管编码格式，最后用院内字典兜底。注意第三层“编码不在院内字典”没有直接报错而是加入errs列表，是因为有些院内字典本身收录不全，直接拦截会把真阳性也杀掉，我一般让这类样本进入“待人工确认”队列，而不是自动置空。
4.3 入组差异回写：模型预测要能定位到“钱差在哪”
校验完字段，下一步是把抽取结果送进分组器，算预测组号和预测权重。这一步做出来，调优就真正落到医保支付场景了。我一般把“模型预测组号vs人工原编码组号”的差异分成三类：组号一致、组别一致但权重不同、组别都不同，每一类对应不同的处理优先级。
权重差异是业务方最关心的，因为直接对应支付金额。下面这张表是一个常见案例的简化版，我拿它给信息科和医保办解释“为什么一条并发症标记值几千块”：
| 对比项 | 人工原编码 | 模型预测 | 说明 |
|---|---|---|---|
| 主诊断 | 急性心力衰竭 I50.9 | 急性心力衰竭 I50.9 | 一致 |
| 其他诊断 | 无 | 慢性肾脏病3期 N18.3 | 模型从出院诊断里补抽出来 |
| 入组结果 | 不伴合并症组 | 伴合并症组 | 权重提高约0.3 |
这类差异的正确处理不是直接改编码，而是把模型预测结果作为质控线索回写给编码员，由编码员确认“慢性肾脏病3期”在本次住院是否有诊疗记录。漏抽是DRG质控要抓的第一个问题，模型补出来就是价值；但如果模型把既往史里的糖尿病当成本次合并症，那就是高靠风险，必须在Prompt和后处理两层都拦掉。
这一章最后落在一个习惯上：从模型输出到最终入组结果，每一步的中间产物都要留痕。哪份病历的哪个字段被模型改了、被哪条规则拦下来，都能回溯，才敢在生产环境跑。
5. 调优避坑指南：让DeepSeek在电子病历上翻车的五个典型Case
5.1 “拒绝填手术编码”和“脑补手术编码”：两个极端都要防
现象：一份病历从手术记录看明确做了“经尿道前列腺电切术”，但模型输出主手术字段为空；另一份病历只写了“建议完善冠脉造影检查”，模型却抽出了“冠状动脉造影术”并配上编码。
原因：前一种情况是Prompt里的“未提及手术输出空串”约束被模型误解成“不确定就不填”；后一种情况是模型把“建议做”当成了“已执行”，这是传统NER模型极少犯但大模型经常犯的错，因为它在做意图补全。
解决：我把手术抽取改成两步：先单独问“本次住院是否执行了有创操作或手术，回答是或否”，再让模型从手术记录中抽取手术名称。两步走之后，脑补手术的Case基本消失，空填的Case也能根据“是/否”结果自动判断是否进入人工复核。
5.2 “陈旧性”被当成“本次并发症”，权重虚高最危险
现象：出院诊断里同时有“陈旧性心肌梗死”和“急性心力衰竭”，模型把陈旧性心梗当成CC/MCC标了进去，入组权重被抬高了一段。
原因：DRG入组的CC/MCC列表要求是“本次住院期间存在且需要管理的并发症”，陈旧性状态在很多版本的分组方案里不构成当次入组并发症，这是临床上语义与时态判断的问题。模型对“陈旧性”“术后状态”“治疗后”这类修饰词的敏感度不够。
解决：Prompt里加时态约束词列表，并在后处理里做一次规则清洗：抽取出的cc_items文本里若包含“陈旧性”“既往”“病史”“术后状态”等关键字，直接降级为“其他诊断”，不进CC/MCC。规则清洗不是为了替代模型，而是给权重相关字段上一道保险。
5.3 同一份病历跑两遍结果不一样
现象：temperature设为0.6时，把同一份病历连续提交两次，一次预测入不伴合并症组，一次预测入伴合并症组，编码员拿着结果不知道怎么改。
原因：temperature过高导致采样随机性大，模型在同一位置可以选“糖尿病”也可以选“糖尿病状态”，代码层面没有做任何复现控制。
解决：抽取类任务把三件套压到前文给的区间，并在生产环节对每份病历做三次抽取投票，三个结果里至少两个一致才作为最终输出，否则标记“需要人工复核”。投票会显著增加调用成本，但DRG场景里一次入组判错的损失远大于三次模型调用的成本。上线三票制前，先确认本地服务的并发吞吐扛得住病案室批量跑数。
5.4 医院换病历模板后指标掉十个点
现象：从A科室试点推广到B科室，B科室用的是结构化表格病历，出院诊断写成一行一行的表格而非段落，模型的入组一致率从92%掉到82%。
原因：测试集全部来自A科室，Prompt里隐含了“出院诊断是一段自然语言”的假设。B科室的表格模板把诊断列和编码列并排，模型反而把表格里的旧编码当成参考直接抄，抄错一个数字就全错。
解决：上线新科室前，先抽20份该科室的病历跑一遍“模板归零测试”，不做任何调参，只看哪些字段系统性出错。如果是表格型病历，把抽取Prompt增加一行说明“文本里的编码列仅作参考，必须根据诊断文本重新给出编码”。
5.5 输出JSON被max_tokens截断，主诊断字段神秘消失
现象：日志显示模型正常返回，但解析后principal_diag_icd为空，人工看原始输出发现JSON在other_diags数组中间被切断。
原因：病历里“其他诊断”数量多，模型把无关的慢性病也列进JSON，输出超过max_tokens，被服务端截断。截断位置不固定，所以前一条还能解析，后一条直接报JSON格式错误。
解决：把max_tokens提高到1500以上，同时在Prompt里明确“其他诊断最多15条，只保留与本次住院相关的”。如果病历本身特别长，优先保证主诊断和主手术的JSON字段排在输出最前面，即使被截断也能保住关键字段。
6. 回到疗效：回归测试集与上线后的调优习惯
6.1 把编码员的纠错回流成回归集
调优手册最后一段，我给每个接手这个方案的人一个默认动作：建一份不少于30条的回归病历集，里面每一份都带人工复核过的DRG组号，并且每隔三个月把编码员在实际工作中改过的病历补充进来。回归集的作用不是再调一遍参数，而是防止每次Prompt改动按下葫芦浮起瓢。
我吃过大意没有回归集的亏。有一次为了提升手术编码的准确率，我在Prompt里加了一句“手术名称务必与记录原文一致”，手术字段的F1涨了两个点，结果并发症字段开始漏标，因为模型把更多注意力放到了“原文一致”上。如果没有回归集，这个副作用要等上一周才能被业务反馈出来。
现在的做法是任何改动都先跑回归集，记录三个数：字段级F1、入组一致率、高靠风险标记数。前两个数看效果，第三个数专门盯安全底线。
def regression_report(version, baseline_f1, baseline_group_acc): cases = load_gold("regression_30.jsonl") # 含人工组号与风险标记 f1, group_acc, risk_cnt = run_all(cases, version) print(f"字段F1: {f1:.3f} (baseline {baseline_f1:.3f})") print(f"入组一致率: {group_acc:.3f} (baseline {baseline_group_acc:.3f})") print(f"高靠风险标记数: {risk_cnt}") if group_acc < baseline_group_acc - 0.02: print("回归未通过，回滚 Prompt 与参数")这段脚本的判断逻辑很简单：入组一致率掉两个百分点以上就不上线。字段F1可以略降，因为有些抽取字面的调整不影响入组，但组号一致率是业务承诺，不能牺牲。我习惯把参数搜索、Prompt版本、回归报告三样东西放在同一次提交里留痕，三个月后回看，哪些改动是真正有效的，哪些只是当时觉得合理，一目了然。
我一直保留一个笨习惯：不管调优调得多顺手，每个月都让DeepSeek跑一遍去年这个月被医保反馈回来的高靠风险病例，看它有没有在同一个坑里翻两次车。大模型的随机性决定了没有一劳永逸的调优，只有把验证集、参数组合和回归习惯绑在一起，才能让语义理解在DRG控费里变成一个真正可交付出的工具。这份调优手册到这里，参数和坑都摆明了，剩下的要靠你在自己的病历数据上把每一档参数跑出来，希望帮到你。
本文还有配套的精品资源，点击获取
