Design and Implementation of a Batch Semantic Analysis Automation Tool for Electronic Medical Records — A Hands-on Blog关键词电子病历命名实体识别语义分析临床自然语言处理自动化工具Flask正则抽取写在前面我为什么要写这篇长文如果你在医疗信息化、临床科研或者单纯对怎么让机器读懂病历感兴趣那么这篇文章大概率对你有用。事情的缘起很简单。几个月前我手头积攒了一批中文电子病历EMR少说几十份多则上千份全部是自由文本或半结构化文本——主诉、现病史、既往史、查体、诊断、处置洋洋洒洒几段话信息密度极高但机器根本读不懂。我想做几件事把里面的疾病、症状、用药、检查都抽出来按科室归个类看看哪些病历病情危重需要优先处理最好还能给每份病历自动写一句话摘要最后把这些结果做成图表一眼看清这批病历的整体画像。市面上不是没有工具。深度学习模型精度高但训练要标注语料、部署要吃显卡对一个想快速验证想法的人来说门槛不低商用系统功能全但价格不菲、还要走采购流程开源脚本倒是不少可大多只解决抽实体这一个点缺界面、缺批量、缺可视化。于是我动手做了一个轻量、零外部依赖、即开即用的原型一个基于领域词典与正则模式的电子病历批量语义分析自动化工具。核心引擎只用 Python 标准库前端是原生 HTML/CSS/JS 配 Chart.js后端是 Flask。它能批量读入病历、自动抽实体、分科室、评严重度、写摘要、出图表、导结果。这篇文章不是一篇八股论文而是一篇能跟着动手的博客我会把设计思路、模块实现、完整代码、实验结果、逐份病历案例、部署教程、与其他方案的对比以及踩过的坑全都摊开来讲。如果你只想看结论可以跳到最后的结论与展望如果你想自己复现跟着部署与运维指南使用教程两步就能跑起来。目 录写在前面我为什么要写这篇长文第 1 章 为什么需要电子病历语义分析1.1 医疗数据的富矿与荒原1.2 电子病历的真实结构与被低估的痛点1.3 临床自然语言处理能带来什么1.4 本文要解决的三个具体问题1.5 本章小结第 2 章 工具总览它能做什么2.1 一句话定位2.2 功能全景清单2.3 一张图看懂工作流2.4 适合谁 / 不适合谁2.5 技术栈一览2.6 本章小结第 3 章 系统总体设计3.1 设计目标与原则3.2 总体架构分层图3.3 技术选型与理由3.4 实体类型配色与词条规模第 4 章 医学实体知识库详解4.1 七大类实体设计哲学4.2 词条来源与选取三原则4.3 跨类别术语的妥善处理4.4 科室关键词与严重度词表4.5 如何扩充你自己的知识库第 5 章 实体识别引擎从正则到工程5.1 为什么是规则化而不是深度学习5.2 长词优先策略5.3 预编译与性能优化5.4 结构化与扁平化双路输出5.5 引擎核心代码片段第 6 章 科室分类模块6.1 关键词加权评分机制6.2 一个真实的合并症干扰案例6.3 改进思路第 7 章 严重程度评估模块7.1 三级关键词阈值7.2 0–100 评分公式7.3 可视化呈现第 8 章 自动摘要生成8.1 模板填充而非生成8.2 为什么宁可死板也不要幻觉第 9 章 批量分析与可视化系统9.1 批量处理流程9.2 跨病历统计聚合9.3 仪表盘布局与图表9.4 详情页高亮与自定义分析第 10 章 完整代码走读10.1 实体字典 entities.py10.2 分析引擎 analyzer.py10.3 后端服务 app.py 关键路由第 11 章 实验与逐份病历案例11.1 实验数据与设置11.2 批量分析结果汇总11.3 12 份病历逐份解读11.4 性能与准确性讨论第 12 章 与主流方案的对比12.1 规则化 vs 深度学习 vs 商用12.2 一张对比表看懂取舍第 13 章 部署与运维指南13.1 环境准备13.2 启动服务13.3 接入你自己的病历数据13.4 二次开发指引第 14 章 使用教程五分钟跑通第 15 章 讨论与局限性15.1 规则化方法的适用边界15.2 与深度学习方法的互补关系15.3 其他工程局限第 16 章 结论与展望第 17 章 附录17.1 常见问题 FAQ17.2 术语表17.3 参考资源与文献17.4 免责声明第 1 章 为什么需要电子病历语义分析1.1 医疗数据的富矿与荒原医院每天产生的数据里有一类是结构化的化验单的数值、生命体征的曲线、医保结算的字段它们整齐、标准、易于计算。但还有一类——也是占比极大的一类——是自由文本门诊病历里医生写的一段段叙述住院病历里洋洋洒洒的病程记录会诊意见里夹叙夹议的讨论。这类文本是一座富矿。一份普通的出院小结可能包含主诊断、十余个既往诊断、一长串用药、若干检查结果以及医生对病情转归的判断。如果把这些非结构化信息全部变成结构化字段你就能做很多事按疾病统计科室负荷、追踪某种药物的使用趋势、筛查高危患者、构建科研队列、做病种质控、自动生成上报材料……但它同时是一片荒原。富矿之所以是荒原是因为机器读不懂它。你没法在 SQL 里SELECT disease FROM emr WHERE severity 80——因为disease和severity压根不存在于数据库里它们埋在一段中文叙述的某个句子中间。要从这片荒原里挖出金子靠人肉阅读是行不通的量太大靠简单的关键词搜索也不行同义词、缩写、表述变体太多。于是临床自然语言处理这门技术就成了连接富矿与荒原的桥。1.2 电子病历的真实结构与被低估的痛点我们先把电子病历的结构摊开看。一份典型的门诊/住院病历至少包含以下字段主诉患者本次就诊最主要的症状及持续时间例如反复胸闷 3 年加重伴气短 1 周。现病史本次疾病发生、发展、诊治的全过程。既往史过去的健康状况、慢性病、手术史、过敏史。体格检查医生查体所见包括生命体征与专科查体。辅助检查化验、影像、超声等结果。诊断门急诊或出院诊断常分主要诊断与次要诊断。处置 / 医嘱用药、手术、会诊、随访等。看起来字段清晰对吧但痛点恰恰藏在清晰之下术语不统一。同样是高血压可能写作高血压病“原发性高血压”“HBP”“HTN”同样是心肌梗死可能写心梗“AMI”“急性心肌梗死”。表述高度自由。同样一个糖尿病有人写2 型糖尿病多年有人写糖尿病史 10 年口服二甲双胍控制可有人写发现血糖升高 5 年。缩写与口语化。“房颤”“室上速”“呼衰”肾衰随处可见。否定与不确定表述。“否认肝炎结核史”“未见明显积液”“不排除肿瘤可能”——这些表述如果不做语义处理很容易把未见当成见。多诊断并存。一份病历往往主诊断之外还挂着三五个既往诊断且分不清主次。这些痛点叠加起来的结果是你手里明明有一座金矿却只能用人眼 CtrlF这种原始工具去挖。这正是本文工具的出发点。1.3 临床自然语言处理能带来什么临床自然语言处理Clinical NLP是医学信息学与自然语言处理的交叉领域目标是从临床文本中抽取、组织并推理医学知识。它通常包含这样一串任务命名实体识别NER把文本里的疾病“症状”“药物”“检查”“手术”“部位”指标等实体框出来。关系抽取识别实体之间的关系例如药物 A 用于治疗 疾病 B“症状 C 发生于 部位 D”。文本分类给整篇病历打标签例如科室、病种、是否手术、是否危重。否定/不确定检测判断某个实体是存在还是被否定/不确定。摘要生成把长篇叙述压成核心信息。本文工具聚焦于其中最基础也最实用的一层——实体识别 文本分类科室/严重度 摘要并把它们打包成批量 可视化 可导出的完整链路。换句话说它不追求做全所有 Clinical NLP 任务而是把从病历文本到结构化结果这条最刚需的主线做扎实。1.4 本文要解决的三个具体问题把上面说的揉成三个具体问题也就是本文工具要回答的怎么把一份病历拆解成结构化字段——通过实体识别引擎把疾病、症状、用药、检查等七大类实体从叙述中抽出来并能在原文上高亮标注。怎么给一批病历画像——通过科室分类、严重度评估、批量统计聚合让管理者从宏观层面看清这批病历的科室分布、病情梯度、高频病种与用药规律。怎么让人一眼看懂并拿去用——通过 Web 仪表盘、详情页高亮、自定义即时分析以及 JSON/CSV 导出把结果从机器输出变成人能用的资产。这三个问题分别对应工具的三层价值结构化看得清、聚合化看得全、可用化拿得走。1.5 本章小结本章交代了写作缘起与问题背景。医疗自由文本既是富矿也是荒原痛点在于术语不统一、表述自由、缩写口语化、否定表述、多诊断并存。Clinical NLP 是挖矿的桥而本文工具聚焦最刚需的实体识别 分类 摘要并以批量、可视化、可导出的形式交付。下一章我们直接看这个工具长什么样、能干什么。第 2 章 工具总览它能做什么2.1 一句话定位一个零依赖、即开即用的中文电子病历批量语义分析自动化工具上传一批病历自动抽实体、分科室、评严重度、写摘要、出图表、可导出。注意三个关键词零依赖核心引擎只用 Python 标准库不装 PyTorch/TensorFlow、即开即用一条命令起服务浏览器打开就能用、批量不是一次分析一份而是一批一起分析并聚合统计。2.2 功能全景清单逐项列一下工具的能力边界避免你产生不切实际的期待能力说明输入输出实体识别NER抽取 7 类医学实体病历文本带类别与位置的实体列表实体原文高亮在病历原文上彩色标注实体 原文HTML 高亮片段科室分类12 个科室关键词加权推断全文字段推断科室 得分明细严重程度评估危重/重度/中度/轻度四级全文字段等级 0–100 评分自动摘要主诉/诊断/用药/检查四槽位字段 实体一行紧凑摘要批量分析一次分析全量病历病历集合逐条结果 缓存跨病历统计分布/高频/均值聚合逐条结果统计指标集合可视化仪表盘4 卡片 4 图表 3 列表统计指标网页仪表盘详情页左原文高亮 右信息栏单条病历详情网页自定义分析粘贴任意文本即时分析自由文本即时结果结果导出JSON 全量 / CSV 摘要分析结果下载文件可以看到工具覆盖了从原始文本到可用资产的完整链路而不是只做其中一环。2.3 一张图看懂工作流病历数据 (JSON / 自定义文本) │ ▼ ┌──────────────────┐ │ 实体识别引擎 │ 7 类词典 正则预编译 └──────────────────┘ │ 实体(结构化 扁平化) ▼ ┌──────────────────┐ ┌──────────────────┐ │ 科室分类(加权) │ │ 严重度评估(分级) │ └──────────────────┘ └──────────────────┘ │ │ ▼ ▼ ┌──────────────────┐ │ 自动摘要(模板) │ └──────────────────┘ │ ▼ ┌──────────────────┐ │ 批量统计聚合 │ 科室/严重度/实体/高频 └──────────────────┘ │ ▼ ┌────────────────────────────────────┐ │ 表现层仪表盘 / 详情 / 自定义 / 导出 │ └────────────────────────────────────┘整条流水线是无状态的纯函数式处理给定一份病历经过识别 → 分类 → 评估 → 摘要 → 统计五个环节产出一份结构化结果。批量只是把单份处理套了一层循环再做一次聚合。2.4 适合谁 / 不适合谁适合医院科室、质控部门想快速对一批病历做结构化摸底的临床科研团队要构建科研队列、做病种统计的缺少深度学习工程能力但想先跑通原型的个人或小团队想把这个工具作为 AI Agent 工作流里语义处理组件的开发者。不适合追求高精度、要对接生产级 ICD 编码、需要模型持续迭代的大型系统请直接上深度学习方案需要否定检测、关系抽取、时序分析等高阶语义能力的场景本文工具暂未实现对隐私合规、权限管理、审计有强要求的正式生产环境本工具为原型未含鉴权。一句话它是快速验证想法和轻量辅助的利器不是替代专业医疗 AI 系统的银弹。2.5 技术栈一览层技术说明核心引擎Python 3 标准库re / json / collections零第三方依赖后端Flask 3.x轻量 Web 框架前端原生 HTML / CSS / JavaScript无构建工具图表Chart.jsCDN 引入环形/柱状图存储JSON 文件易读易改可换数据库技术选型的核心逻辑是能少依赖就少依赖。核心引擎只用标准库意味着你可以在任何装了 Python 的机器上直接跑分析逻辑不必担心环境冲突Flask 负责把引擎能力暴露成网页和 API前端三件套保证零构建、好维护。2.6 本章小结本章把工具的定位、功能清单、工作流、适用边界和技术栈一次性讲清。它是一个零依赖、即开即用、批量处理的轻量工具覆盖从实体识别到可视化的完整链路适合快速验证与轻量辅助但不是生产级医疗 AI 的替代品。下一章进入系统总体设计看它内部是如何分层的。本文未完第 3 章起见后续章节。第 3 章 系统总体设计如果说第 2 章是这个工具长什么样那本章就是它内部是怎么搭起来的。设计阶段最重要的不是写代码而是想清楚原则、结构与取舍。3.1 设计目标与原则工具在动手前先确立了五条设计原则它们像一把尺子后面每个模块的取舍都用它来量批量自动化支持一次性导入并分析多份病历自动完成从原始文本到结构化结果与统计报告的全流程减少人工干预。这里的关键词是全流程——不是分析完丢给你一堆 JSON 就完了而是连统计、图表、导出都一并做好。多维度语义提取不只抽实体还提供科室分类、严重度评估、自动摘要形成对一份病历的多层次语义画像。单一维度的抽取往往不够用你知道一份病历有高血压、糖尿病但不知道它该归哪个科、危不危重、主线是什么。多维度才能画像。可解释性优先所有抽取结果都对应明确的词典词条或关键词规则用户能追溯每个实体、每个判定的来源。这一点在医疗场景尤其重要——你不能告诉医生说模型觉得这病历危重却不给理由。规则化方法的天然优势就是白盒。轻量零依赖核心引擎只用 Python 标准库不引入深度学习框架普通计算环境即开即用。零依赖带来的好处不仅仅是部署省事更是可移植性与可审计性别人拿到代码不需要配环境就能读懂、能改、能跑。可视化与可导出提供 Web 仪表盘与实体高亮详情并支持 JSON/CSV 结果导出便于二次分析与系统对接。工具的价值最终要落到人能用、系统能接所以表现层与导出能力不是锦上添花而是交付闭环的必要一环。这五条原则可以浓缩成一句话让非技术背景的临床/管理人员也能用让技术背景的开发者也能改。3.2 总体架构分层图系统采用经典的分层架构自底向上依次为数据层、引擎层、服务层、表现层。分层的好处是职责清晰、耦合度低任何一层都能单独替换而不影响其他层。┌─────────────────────────────────────────────────────────┐ │ 表现层 (Presentation) │ │ 仪表盘 · 详情页 · 自定义分析页 · JSON/CSV 导出 │ ├─────────────────────────────────────────────────────────┤ │ 服务层 (Service) │ │ Flask 路由 · 批量分析 API · 单条分析 API · 导出 API │ ├─────────────────────────────────────────────────────────┤ │ 引擎层 (Engine) │ │ 实体识别 · 科室分类 · 严重度评估 · 自动摘要 · 批量统计 │ │ ┌──────────────────────────────────────┐ │ │ │ 医学实体知识库 (346 条词条) │ │ │ │ 疾病/症状/药物/检查/手术/部位/检验 │ │ │ └──────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────┤ │ 数据层 (Data) │ │ 样本病历 JSON · 自定义输入文本 │ └─────────────────────────────────────────────────────────┘各层职责数据层负责病历数据的加载与持久化。本原型用 JSON 文件存储好处是可读可改生产环境可无缝替换为数据库。引擎层系统的大脑封装全部语义分析逻辑识别、分类、评估、摘要、统计并依赖内置的医学实体知识库。这一层完全不依赖 Web可以脱离 Flask 单独作为库调用。服务层基于 Flask 的 HTTP 路由把引擎能力以页面和 API 形式对外暴露。批量分析、单条分析、导出都是在这里接线的。表现层通过模板渲染 前端 JavaScript 实现可视化交互包括仪表盘、详情页、自定义分析页与文件导出。这种引擎与 Web 解耦的结构非常关键你把engine/目录拷到任何 Python 项目里import之后就能用不必起一个 Web 服务。3.3 技术选型与理由技术选型不是追新而是够用且省心Python 标准库做引擎Python 在文本处理与正则匹配上表达力强、生态成熟标准库re、json、collections足以覆盖全部需求避免引入重型依赖。Flask 做后端轻量、灵活、学习成本低适合中小型 Web 服务不会因为框架本身的复杂度拖慢开发。原生 HTML/CSS/JS Chart.js 做前端不引入 React/Vue 与构建工具链降低维护门槛Chart.js 通过 CDN 引入几行配置就能画出专业图表。JSON 做存储病历样本与导出结果都用 JSON人类可读、便于调试也易于后续接入数据库或大数据平台。可能有读者会问为什么不用更高级的 NLP 库比如jieba分词、HanLP或者上 BERT答案是刻意的克制。分词对中文 NER 有帮助但本工具基于词典 正则的精确匹配不依赖分词反而避免因分词错误导致的实体切分问题而深度学习模型虽然精度更高却违背零依赖、即开即用的原则。选型始终服务于设计原则而不是反过来。3.4 实体类型配色与词条规模为了让人在看结果时能一眼区分七类实体在可视化中各分配了一种区分色。同时下表也给出了每类词典的词条数量——这是整个知识库的体量账本。类型标识中文名称配色词条数disease疾病诊断#e74c3c 红78symptom症状#e67e22 橙55medication药物#3498db 蓝77examination检查项目#9b59b6 紫41procedure手术/操作#1abc9c 青30body_part解剖部位#34495e 深灰34lab_value实验室指标#16a085 墨绿31合计——346这张表有三层含义第一七类覆盖均衡疾病与药物最多临床最核心的两类手术与实验室指标相对较少术语集中度高第二配色是功能性的红色疾病、橙色症状、蓝色药物符合疾病警示、症状提醒、药物信息的直觉第三346 这个数字不是拍脑袋它来自对真实病历高频术语的统计归纳后续扩充知识库时这张表就是你的基准线。第 4 章 医学实体知识库详解如果把整个工具比作一个人那引擎是大脑而医学实体知识库就是记忆和常识。没有它再聪明的算法也只是空转。本章把这块记忆拆开看。4.1 七大类实体设计哲学为什么是这七类而不是五类或十类这背后有一套设计哲学疾病诊断disease最核心的实体。一份病历的诊断决定了它的归属、危重度与用药逻辑。症状symptom患者主观不适与客观体征表现是连接主诉与诊断的桥梁。药物medication治疗的核心手段用药规律直接反映病种与诊疗路径。检查项目examination影像、内镜、功能检查等反映医生的诊断思路。手术/操作procedure治疗手段的另一极区分内科与外科病历的关键信号。解剖部位body_part症状与疾病的解剖定位常作为关系抽取的基础。实验室指标lab_value化验数值与项目名如糖化血红蛋白“肌酐”是量化病情的依据。这七类不是凭空定的而是对应临床病历的信息维度诊断维度、症状维度、用药维度、检查维度、操作维度、定位维度、量化维度。覆盖这七类一份病历的语义骨架就立起来了。4.2 词条来源与选取三原则词典里的 346 条词条从哪来主要来自两类渠道一是临床诊疗常见术语的归纳参考病历书写规范、常见慢病与急症术语二是从样本病历中反向提取高频词。选取时遵守三条原则临床高频性优先纳入真实病历里反复出现的术语。比如高血压糖尿病几乎每份内科病历都出现必须进库而某个罕见病即便术语规范若极少出现可暂缓收录。语义独立性词条应能独立承载一个明确医学概念。例如胸痛是一个独立症状左侧不是实体它只是部位修饰语不单独收录。边界清晰性尽量让词条不与其它类别大量重叠混淆。当然完全不重叠做不到见 4.3但原则上是能分就分。这三条原则保证了知识库小而准它不求覆盖全部医学术语但求覆盖高频且 unambiguous的那部分先让工具在常见场景跑得稳。4.3 跨类别术语的妥善处理现实中医学术语常有多重身份这是建词典时绕不开的坑。举两个例子“糖化血红蛋白”它是一项实验室检验指标测血糖控制的金标准也常作为检查项目被医生写进医嘱。“冠状动脉造影”既是检查用于诊断冠脉狭窄也是手术操作介入治疗的前置步骤。如果强行让一个术语只属于一类要么会漏抽要么会错分。本文的做法是允许同一术语出现在多个类别词典中抽取时按类别独立匹配——也就是说糖化血红蛋白会同时被疾病/检验与检查两类命中保留其多重语义属性。代价是统计时该术语会在不同类别各计一次但换来的是不丢信息。对于原型系统不丢信息比强行归类更重要。4.4 科室关键词与严重度词表除了实体词典知识库还藏着两组隐形词表它们不直接作为实体输出却是分类与评估的关键依据科室关键词映射12 个科室每个科室关联一组具有区分度的关键词。例如神经内科关联脑梗死、脑出血、癫痫、眩晕心血管内科关联冠心病、心肌梗死、心律失常、高血压呼吸内科关联肺炎、慢阻肺、哮喘、咳嗽。系统对全文字段统计各科室关键词命中数加权求和取最高者。严重程度关键词表三级 30 词危重级13 词如昏迷、休克、呼吸衰竭、心力衰竭、心肌梗死、DIC、脑出血等命中即判为最严重重度级11 词如急诊、入院、手术、溶栓、抢救等中度级6 词如住院、复查、随访等。这两组词表的规模12 科室、30 严重度词同样来自对样本病历的归纳是后续分类与评估准确率的地基。4.5 如何扩充你自己的知识库工具的价值在于可演进。扩充知识库是最高频的二次开发动作这里给出一套可操作的步骤收集术语从你的目标病历中导出高频未识别词或从专科术语表如某病种诊疗指南批量取词。分类归位按 4.1 的七类维度把术语归入对应词典跨类术语就放多类。去重与校验检查是否与已有词条重复或构成子串避免糖尿病和2 型糖尿病同时命中造成重复引擎已用长词优先策略缓解但仍建议人工核对。补充科室/严重度词新增病种往往要同步补充对应科室关键词若涉及危重症加入严重度词表。增量测试用新词典重新跑一份代表性病历确认召回提升且未引入错误匹配。版本管理把词典文件纳入 Git每次扩充留 commit便于回溯。一个实用建议先扩充疾病与药物两类因为这两类对统计结果影响最大手术、检查等类别术语集中、增量慢可以放到后面。本章小结第 3–4 章第 3 章确立了批量、多维、可解释、轻量、可导出五原则给出四层架构与零依赖技术选型并用配色表亮出了 346 条词条的体量账本。第 4 章深入知识库七类实体对应病历的七个信息维度词条选取遵循高频、独立、清晰三原则跨类术语允许多重归属科室与严重度两组隐形词表是分类评估的地基最后给出了可操作的扩充六步法。下一章进入引擎核心看这些词典如何被真正用起来。本文未完第 5 章起见后续章节。第 5 章 实体识别引擎从正则到工程前面几章把词典和架构讲完了本章进入最硬核的部分——引擎怎么把词典变成实际的抽取结果。我会把设计取舍、关键技巧和核心代码一并摊开。5.1 为什么是规则化而不是深度学习开门见山本文工具 deliberately 选择了规则化词典 正则而非深度学习。这不是因为不会用 BERT而是经过权衡后的主动选择。理由有四条零依赖即零门槛。深度学习 NER 需要 PyTorch/TensorFlow、预训练权重、GPU 推理环境对只想快速验证想法的人而言是重资产。规则化只用标准库任何装了 Python 的机器都能跑。白盒可解释。每条抽取都对应一个明确词条医生能追问为什么识别成这个你能立刻指出是词典里的哪一条。深度学习是黑盒出了问题难溯源。对已知术语召回近 100%。只要词条在库里正则匹配是确定性的不会偶尔抽不到。在高频术语覆盖到位的前提下核心场景的准确率极高。迭代成本低。发现漏词往词典里加一条就行不用重新训练、不用标注、不用调参。当然规则化有它的代价——对未收录术语的泛化弱、语义消歧能力有限。这些局限我们会在第 15 章专门讨论。但在轻量原型 高频术语覆盖的定位下规则化的性价比最高。5.2 长词优先策略正则匹配有个经典坑短词会截断长词。举个例子词典里同时有糖尿病和2 型糖尿病。如果按默认顺序把短词放前面正则交替表达式可能是(?:糖尿病|2 型糖尿病|...)。当文本出现2 型糖尿病时正则引擎从左到右扫描可能先命中糖尿病三个字于是只抽出糖尿病丢掉2 型这个关键修饰——结果错把2 型糖尿病识别成普通的糖尿病丢失了分型信息。解决办法很朴素也极有效把词条按字符串长度降序排列优先匹配长词。这样交替表达式变成(?:2 型糖尿病|糖尿病|...)遇到2 型糖尿病时长词先被匹配消费掉短词不再有机会截断它。这一步看似微小却是实体识别准确率的关键。它本质上是在模拟人类先认长的、再认短的的阅读直觉。5.3 预编译与性能优化另一个工程细节是正则的预编译。一份病历要用七类词典各匹配一遍如果每次分析都现场拼接正则字符串开销会随调用次数线性累积。本文在引擎初始化时就把每一类的交替表达式用re.compile预编译成模式对象缓存起来foretype,infoinself.entity_types.items():termssorted(info[dict],keylen,reverseTrue)# 长词优先self._patterns[etype]re.compile(r(?:|.join(re.escape(t)fortinterms)r))re.escape的作用是词条里若含有正则元字符如括号、点号转义后不会破坏正则语法。预编译带来的好处在批量场景下尤为明显——12 份病历的分析里正则对象只编译一次后续每次匹配都是 O(文本长度) 的线性扫描这也是端到端耗时低于 50 毫秒的关键之一。5.4 结构化与扁平化双路输出同一份抽取结果在不同场景下需要两种形态结构化输出按类聚合把识别出的实体按类别归并统计每类每词的命中频次。形态大致是{disease: {高血压: 2, 糖尿病: 1}, medication: {...}}。它适合做统计报表、侧栏展示、高频 Top 10。扁平化输出带位置保留每个匹配实体的文本、类别、起始与结束位置偏移按起始位置排序。形态是[{text:高血压,type:disease,start:12,end:15}, ...]。它适合前端把原文和实体精确对齐、做彩色高亮。为什么要两路因为结构化丢了位置无法高亮扁平化丢了聚合不利于统计。工具同时产出两者让统计和高亮各取所需。扁平化输出时还要处理重叠极少数情况下不同类别的正则可能覆盖同一段文本如跨类术语引擎按起始位置和长度做去重保留最匹配的那个保证前端高亮不混乱。位置信息还带来一个隐性价值可核验。你点开详情页看到高血压被标红是因为引擎在原文的第 12–15 个字符确实匹配到了这个词条——所见即所得不存在黑盒幻觉。5.5 引擎核心代码片段把 5.2–5.4 串起来实体识别引擎的核心逻辑简化版如下importrefromcollectionsimportdefaultdictclassEntityRecognizer:def__init__(self,entity_types):# entity_types: {disease: {dict: [...]}, ...}self._patterns{}foretype,infoinentity_types.items():termssorted(info[dict],keylen,reverseTrue)# 长词优先self._patterns[etype]re.compile(r(?:|.join(re.escape(t)fortinterms)r))defrecognize(self,text):flat[]# 扁平化输出structdefaultdict(lambda:defaultdict(int))# 结构化输出foretype,patinself._patterns.items():forminpat.finditer(text):span(m.start(),m.end())tokenm.group()flat.append({text:token,type:etype,start:span[0],end:span[1]})struct[etype][token]1flat.sort(keylambdax:x[start])# 按位置排序returnflat,dict(struct)这段代码只有二十来行却浓缩了规则化 NER 的全部精髓长词优先、预编译、双路输出。它不依赖任何第三方库拷到任何 Python 环境都能跑。下一章我们看光有实体还不够怎么把一份病历归到科室。