企业官网建设流程全解析

做医疗AI的同行，大概都有过标注任务下发那一刻的窒息感：几百份病历、出院小结、检查报告堆在工单里，每一份都要按字段拆成结构化数据，主诊断、合并症、用药、过敏史、手术史、异常检验指标，一样不能漏。而LLM自动标注医疗数据这件事，听起来像是个偷懒取巧的路子，实际上是我们踩了大半年坑之后，验证过的最靠谱的一条路。去年我们团队接了一个模拟医疗项目X，需要把某医院科室提供的数千份出院小结转成结构化训练集。按传统的人工标注加双人复核流程估算，交付周期要25个工作日左右。后来换成大模型流水线加少量人工质控，整体压缩到5个工作日上下。这篇文章就把整条方案的思路、Prompt设计、工程实现、质量兜底和踩过的坑全部摊开讲，给正在被标注任务折磨的同行一条可以照着走的路线。

1. 先算一笔账：医疗数据标注为什么又慢又贵

1.1 一份标注工单的成本拆解

说“效率翻倍”之前，得先知道基线到底在哪。我们当时的任务是把数千份出院小结转成结构化数据，字段包括主诊断、合并症、既往史、用药方案、过敏史、手术史、检验异常项等七八个大类，每个大类下面还有子字段。纯人工方案的成本，按当时行情估算是这样：

注意这个账本里还没有算一个更贵的隐性成本：医疗标注不能用通用众包，标注员得具备基础的医学知识，起码分得清“主诉”和“既往史”的区别，认识常见药名和诊断术语。这意味着招人、培训、考核都要时间，不是今天下单明天就能开工的。

1.2 慢的真凶：医学文本的三个反直觉难点

很多人以为病历标注就是“认词”，把诊断名、药名圈出来就行。真正上手就会发现医学文本有三个特别反直觉的地方。

第一个是否定与不确定语义。写“患者无发热”，如果规则里只匹配“发热”两个字，就会错标成阳性。更麻烦的是“未见明显异常”“暂不考虑”这类半否定表述，还有“发热待查”这种描述就诊原因而不是症状的短语。传统词典匹配在这一层几乎必炸，只能靠大量人工校验兜底。

第二个是缩写和口语化记录。病历里“COPD”“DM”“HTN”是常规操作，手写扫描件的识别结果更是五花八门，同一个科室不同医生写同一个药可能有三种写法。这些都需要靠上下文去猜，猜错了就是标注错误。

第三个是隐含信息和跨句依赖。主诊断有时候只在现病史段落里出现过一次，结论部分反而没写全；一段文本里前半部分说“患者否认冠心病”，后半部分又出现“因冠心病入院”，模型得结合整个病程才能判断既往史到底算有还是没有。这些恰恰是体力活之外最消耗标注员判断力的事情。

1.3 真正的瓶颈不只是钱，而是项目周期

钱的问题其实是表象，周期才是最要命的。标注卡住了，后面所有环节——模型训练、内部评测、小范围试用、效果迭代——全部顺延。我们当时粗算过，如果按纯人工流程走，光标注阶段就吃掉整个项目窗口的三分之一。对临床决策辅助这类项目来说，窗口期可能就是两三个月，标注慢一拍，后面所有节奏都被拖死。这也是为什么“LLM自动标注”的吸引力不在省了多少预算，而在它把数据处理的周期从“周”压缩到“天”，让整个团队的迭代节奏完全变了。

2. LLM凭啥能标医疗数据：从“查词典”到“读上下文”

2.1 规则系统和大模型的代差

以前大家做医疗信息抽取，主流方案是“词典加正则”。维护一份症状词典、药名词典，再写一堆否定词窗口规则，比如“无”“否认”“未见”后面几个词内的实体要翻转语义。这套方案不是不能用，而是维护成本会随着语料复杂度指数上升。同一个意思，医生有十种写法，规则就得写十条分支；碰到长距离否定，比如“患者自述既往体健，否认高血压、糖尿病、冠心病等慢性病史”，五六个实体堆在一起，窗口规则很容易漏掉后半部分的实体。

大模型走的完全是另一条路。它在预训练阶段见过海量医疗文本，对“否认胸痛”和“主诉胸痛”这种同一组词不同词序带来的语义差异，有天然的理解能力。从工程角度说，我们不用再去穷举语言的边角情况，只需要把“字段定义”和“输出约束”交代清楚，模型自己会处理否定范围、指代、缩写还原这些以前要写几百行规则的事情。注意，这不代表大模型不会错，只是它的错误模式更接近“人看走眼”，而不是“规则匹配撞墙”。

2.2 关键一步：Schema先行

很多人第一次用LLM做标注，上来就写一句“请抽取以下实体”，然后等模型输出。结果模型吐回一大段散文，或者给出一个格式随意的JSON，解析起来痛不欲生。正确做法是先定Schema，再写Prompt。所谓Schema，就是把标注规范翻译成机器可读的字段定义、类型和值域。下面是我们在项目里用的一个Prompt骨架，可以直接改着用：

SYSTEM_PROMPT = """ 你是一名医学信息结构化标注员，负责把出院小结中的信息抽取为JSON。严格遵循以下规范： 字段定义： - primary_diagnosis: 主诊断标准名称，字符串 - comorbidities: 除主诊断外的合并症列表，字符串数组 - fever: 住院期间是否存在发热，布尔值 - medications: 用药信息列表，每项包含 name（药物名称）、dose（剂量）、frequency（频次） - allergies: 过敏史列表，字符串数组，无过敏时输出空数组 抽取规则： - 只能抽取文本中出现或可由文本严格推出的信息 - 否定表述（如“无发热”“否认胸痛”）必须给出正确布尔值 - 缺少足够信息时，数值字段输出null，不要编造 - 输出必须是合法JSON，不要包含任何解释文字 """

看到没有，Prompt里最关键的不是“抽取”两个字，而是字段的类型、值域和边界规则。尤其要写清楚“无发热”属于否定、fever要标成false，这类例子放得越具体，模型理解越准。Schema到位之后，同样的Prompt换到不同科室、不同病历模板上，飘移幅度都会小很多。

2.3 模型选型的取舍：闭源API、开源私有化、垂直微调

我见过不少团队上来就问“用哪个医疗大模型”。其实模型选型要放在Schema之后讨论，因为选型依据是你的数据敏感度、预算和部署能力，跟字段怎么定义没直接关系。

我的建议是分阶段走。先拿几百份脱敏数据跑闭源API做可行性验证，把Schema和Few-shot调顺了，确认准确率能接受；如果后续要进敏感场景、数据不能出域，再切到开源模型本地部署。千万不要一上来就微调医疗垂直模型，数据量不到几万份的时候，微调收益不稳定，反而把大量时间烧在训练环境上。

3. 落地流水线：从原始病历到结构化字段的完整实现

3.1 先掰扯清楚Schema，再碰Prompt

刚才说的Prompt骨架，背后必须有一份完整的字段定义文档。这一步偷懒，后面所有环节都会还债。我们在项目里把Schema直接做成Pydantic模型，既当Prompt的说明，又当输出校验器，一份代码两处用：

from pydantic import BaseModel, Field from typing import List, Optional class Medication(BaseModel): name: str dose: Optional[str] = None frequency: Optional[str] = None class MedicalAnnotation(BaseModel): primary_diagnosis: str comorbidities: List[str] fever: bool medications: List[Medication] allergies: List[str]

字段定义阶段最容易吵起来的是“不确定值怎么处理”。我强烈建议每个字段都留null或“无法判断”这个出口，不要逼模型硬给答案。比如出院小结里根本没提过敏史，输出空数组没问题；但如果患者是意识不清入院、现病史一片空白，有些字段就该是null而不是默认值。模型一旦开始猜测默认值，错误会被悄悄放大，比明确说“不知道”可怕得多。

3.2 种子集：50条人工标注的正确打开方式

Schema定完，做一版“种子集”是必要动作。所谓种子集，就是人工精标几十条样本，作为模型的参考示例。数量不用多，质量要够硬。我们当时选了50条，覆盖心内、呼吸、普外等重点科室，同时兼顾长文本和短文本、复杂病历和简单病历。

种子集的价值不只在Few-shot，它还是后续所有评测的基准。每次改Prompt，先把这50条重新跑一遍，看有没有退化，相当于给标注流水线建了一组回归测试。种子集放在一个独立目录，人工逐条审核，标注人、复核人、确认时间都要记录，这块投入一定不能省。

3.3 动态Few-shot：让模型每次“抄”最像的例子

固定用50条做Few-shot不太现实，上下文窗口放不下那么多示例，而且一次全塞进去，模型反而抓不住重点。更实际的做法是动态检索：给当前这条待标注文本，从种子集里搜出最相似的3到5条，动态拼到Prompt里。相似度计算用文本嵌入向量就行，把种子文本和待标注文本都过一遍嵌入模型，取余弦相似度最高的前几条。

为什么“像”比“多”重要？因为病历的术语分布差异很大，心血管病历里的高频词在儿科病历里可能完全不出现。模型看到同科室、同病种的参考示例，输出的实体风格、诊断命名会明显更稳。我们实测同一个模型，固定随机示例的动态方案，实体F1能差出两三个点，这个差距在医疗场景里不是小事。

3.4 批量推理的工程配置：吞吐、重试与成本控制

原型验证通过后，就要考虑批量跑的工程问题了。先给一个最朴素的调用方式：

import json import requests import hashlib def call_llm(messages): resp = requests.post( "http://localhost:8000/v1/chat/completions", json={ "model": "your-local-model", "messages": messages, "temperature": 0.2, "max_tokens": 1024, }, timeout=60, ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] def annotate(text, fewshot_examples): messages = [ {"role": "system", "content": SYSTEM_PROMPT}, *fewshot_examples, {"role": "user", "content": text}, ] raw = call_llm(messages) try: return json.loads(raw) except json.JSONDecodeError: return {"_parse_error": raw}

temperature设到0.2左右，这个值既保留了一点多样性，又不会让输出飘得太远。批量处理要加三层保险：第一层是按文本哈希做结果缓存，同一份病历重复出现时直接命中缓存，省token；第二层是重试机制，接口超时或返回格式非法就自动重试两次，间隔递增；第三层是断点续跑，每处理完一批就把结果落盘，中途断了从上次的位置继续，不要让一上午的算力白跑。

成本这块有个简单公式可以提前算：单份成本约等于输入token数乘以3加输出token数，再乘以单价。之所以输入要大致按3倍估，是因为要加上系统Prompt、动态示例和重试消耗的token。我们用本地开源模型的时候，粗算单份成本比闭源API低一个数量级，但是要养一台推理机器，这个账得按项目周期综合算，不能只看单份价格。

3.5 后处理：术语标准化与格式兜底

模型输出JSON之后，不能直接入库。第一道关是Pydantic校验，字段缺失、类型不对、多出未知字段，全部拦截下来。第二道关是术语标准化，比如模型输出“高血压病”“高血压”“HTN”，要用模糊匹配映射到统一的ICD类标准术语。第三道关是针对关键字段的规则兜底，像过敏史如果出现“青霉素”“青霉素类”，要做归一化去重。这三道工序加起来，能把模型的“小毛病”在入库前过滤掉一大半。

4. 质量兜底：LLM输出的可信度是管出来的

4.1 自评机制：让模型自己承认“没把握”

见过太多人把LLM当“免费标注员”，模型输出什么就信什么。现实是大模型在某些句子上会自信地犯错，尤其是一段文本里同时出现“否认既往高血压”和“血压控制可”这种互相牵扯的信息。我们的做法是给每个字段加一个可选的confidence字段，范围0到1，模型自己判断这个抽取结果的把握有多大。看起来有点怪，但实测下来模型自评的置信度跟真实准确率有明显的正相关，低置信度区间值得重点人工复核。

更硬核一点的办法是自洽性校验：同一份病历用temperature等于0.3跑三次，把三次结果做多数投票，投票一致率高的直接入库，投票分散的直接送人工。这个方案能有效抓出模型“吃不准”的情况，缺点是推理成本翻三倍。我们只在争议大的字段上启用，比如过敏史和手术史，其他字段不跑。

4.2 人工抽检与双盲复核：把人放在最值钱的位置

人工在这套流水线里不是退场了，而是换了个位置。我们的复核策略分两层。第一层是低置信度全覆盖：模型自评低于阈值、JSON解析失败、自洽性投票不一致的样本，全部走人工。第二层是整体抽检：从通过自动校验的样本里再随机抽10%到15%做双人复核，计算标注员之间以及标注员与模型之间的一致性指标，用Kappa系数这类指标量化。如果模型和人工的一致性掉到某个阈值以下，就说明Prompt需要迭代，而不是继续闷头跑。

这里有个很有用的经验：抽检不要纯随机，要按科室和字段分层。某个罕见并发症在几千份病历里只出现十几次，随机抽检可能一次都抽不到，模型在那里错了你也发现不了。我们后来调整成“稀有实体所在文档提高抽检权重”，质控才真正覆盖到高风险样本。

4.3 错误回流：让Prompt在每次返工中变强

人工复核出来的错误，不能只改几份结果就完事，要形成闭环。我们把错误分成四类：漏抽实体、抽错值、凭空幻觉、格式违规。每一类错误都对应一个改进动作。漏抽和抽错值，通常是字段描述不够清楚，或者缺少同类反例，解决办法是往Few-shot里塞一个“错误样本”的修正示例；幻觉问题要在Prompt里强调“只依据文本，不推测”，最好要求模型输出时带上原文片段作为证据；格式违规则回到解析层，看是重试还是送人工。

每个Prompt版本要编号管理，改完必须跑回归集。我们的回归集就是那50条种子加上100条历史困难样本，每次改Prompt后整批重跑，对比字段级F1，防止修好一个老问题又带出三个新问题。这套闭环跑起来之后，标注质量会在一两周内明显上升，后期人工介入率能压到15%以下。

5. 实测数据、翻车现场与场景取舍

5.1 一组实测数据

项目中期，我们对1000份出院小结做了一次对比测试，三种路线放在同一批数据上跑，结果如下：

纯人工的准确率依然最高，这不用质疑。但加上抽检和低置信复核的混合方案，准确率已经逼近人工水平，而时间从8个工作日压到1天，这就是“效率翻倍”的真实含义。还要注意一个细节：不同字段的表现差异很大，主诊断和用药的F1明显高于过敏史和罕见并发症，所以分字段设定置信度阈值和抽检比例很有必要。

5.2 五个让我印象深刻的坑

第一个坑是幻觉。模型会把文本里没有的信息补出来，比如原文只写了“患者偶有咳嗽”，模型却抽出了“咳痰”，甚至编造了一段“既往有糖尿病史，血糖控制不佳”。解法是Prompt里强制要求关键字段附上原文证据片段，入库前校验证据是否真的出现在原文里，同时把脱敏后的文本和原文做一个映射，方便追查。

第二个坑是脱敏没前置。项目初期我们直接把含姓名、身份证号、住院号的原文本送进接口，被合规同事当场拦住。正确顺序永远是先脱敏再标注，姓名、编号、床号、联系方式全部正则替换成占位符，模型跑完之后再把占位符映射回去。

第三个坑是长文本截断。出院小结短的几百字，长的能到几千字，超出上下文窗口就必须切片。切不好，一个实体被切到两个chunk里，两边都抽不完整。我们后来按段落切块，块与块之间保留50到100字重叠，输出阶段对跨块重复实体做合并投票，漏抽率明显下降。

第四个坑是标注漂移。同一批数据分两个星期跑，前一批把“高血压病”标成“高血压”，后一批因为Few-shot换了几条示例，统一标成了“高血压病”。这类问题全靠术语标准化后处理加上每批次开头跑回归集来防。

第五个坑是稀有实体被“平均”淹没。全局F1看着有0.93，但把罕见并发症单拎出来可能只有0.6。模型在常见病上表现很好，稀有实体训练语料少、Few-shot里也没覆盖到，自然弱。解法就是前面说的分层抽检，让质控资源向稀有样本倾斜。

5.3 哪些场景适合LLM标注，哪些暂时别碰

最后给个清单，方便同行快速判断自家任务适不适合上这套方案：

我的个人体会是，LLM自动标注医疗数据最容易被误解的地方，在于把它当成“替代人”的方案。真正跑通之后你会发现，它替代掉的是机械劳动，放大的是医学判断力。人工不再逐字读病历，而是集中精力看模型拿不准的那15%——那些恰恰是最需要人来判断的样本。效率翻倍是真的，但翻倍的不是模型单个跑得快，而是整个团队的产出结构变了。如果你正打算上这套方案，我的建议是先拿一千份做小规模验证，只盯着字段级F1和人工介入率这两个数字，算完账再决定要不要全面铺开。