spaCy中文命名实体识别实战：从模型选型到自定义训练与部署

1. 为什么中文命名实体识别我选了 spaCy

先交代一下背景。我前阵子接了个文本挖掘的活，要在一批中文资讯里把人名、机构名、地点、时间这些实体抽出来，喂给下游的关联分析。刚开始我没多想，直接拿现成的一套分词工具加规则去搞，结果实体边界各种乱，人名和头衔粘在一起，地名拆得七零八落，规则越写越厚还互相打架。后来换了思路，认真评估了一圈开源方案，最后落地在 spaCy 上。

很多人一听 spaCy 的第一反应是“这不是英文 NLP 的工具吗，中文能行吗”。说实话我一开始也有这个顾虑，但实际跑完一通之后，我的结论是：spaCy 在中文 NER 这件事上完全够用，而且它的工程化体验比不少中文原生的框架要舒服得多。它能做到什么程度呢——预训练的中文模型直接能识别PERSON、ORG、GPE（地理政治实体）、TIME、DATE这些常见类型；如果业务里有特殊实体，比如药品名、产品名、文件编号，你也可以用很小的样本量训练出自己的实体类型，或者用基于规则的组件快速兜底。

这篇文章适合谁看呢。一是刚接触 NLP、想找一个能快速落地中文实体抽取方案的开发者；二是已经在用规则或词典做抽取、但被维护成本和准确率折磨得头大的朋友。我尽量把从安装、模型选型、推理、到自定义训练的完整链路都写清楚，附上我实际跑过的参数和踩坑记录，你可以直接照着复现，不用再走一遍弯路。

2. 方案选型：spaCy 在中文 NER 里的定位和优势

2.1 生态里有哪些选择，我为什么没选它们

中文实体识别这事，市面上能用的方案大概分四类：基于词典和规则的、基于标注平台生成的序列标注模型、各种大模型的 Few-shot 抽取、以及今天要重点讲的 spaCy 这类通用 NLP 框架。

基于词典和规则，比如自己维护一个机构名表加前后缀匹配，短平快，但泛化能力几乎没有。我遇到过的情况是，今天新增一个公司名，明天改个简称，后天又来个“某某分公司”，规则永远在打补丁。基于序列标注的模型，比如用某个深度学习框架自己训 BERT+CRF，效果确实好，但对硬件和数据标注量的要求偏高，团队里如果没有专门做 NLP 的人，维护起来相当吃力。大模型抽取则是另一个路线，用提示词让模型返回 JSON，效果灵活，但缺点是推理成本高、响应不稳定，尤其是做批量离线处理时，千篇一律的 Prompt 很容易在长文本上丢实体。

spaCy 恰好卡在这些方案中间：它自带预训练模型，开箱即用；有统一的文档对象（Doc）和可视化工具，调试友好；最关键是它支持“规则 + 统计模型”混合，可以在不重新训练的情况下先解决大部分高频问题，再针对剩余难点做小样本增量训练。对我这种既要快速上线、又要保证一定准确率的场景，这个平衡点很值钱。

2.2 spaCy 中文模型的工作原理简析

要真正用好 spaCy 的中文 NER，得先理解它的处理管线里到底发生了什么。

spaCy 的主打设计是 Language Processing Pipeline，简单说就是：把原始文本送进去，经过分词（Tokenizer）、词形还原、词性标注、依存句法分析、命名实体识别等组件，最后产出一个 Doc 对象。英文模型默认自带 tokenization，而中文因为缺少天然空格分隔，spaCy 采用了一个中间层——把中文分词的活外包给专门的组件，默认支持两种：

• 基于 jieba 分词的流水线：spaCy 的中文模型在加载时会把分词结果按要求映射成 Token，后续的 NER 模型会在这些 Token 序列上做标签预测。
• 基于字符（Transformer）的流水线：在部分较新的模型中，直接按字符建模，通过上下文编码预测每个字符的实体标签和边界。

不管你用哪种，最终 NER 输出的结构都是一致的：每个实体有text（原文）、label_（实体类型）、start和end（字符级偏移量）。我实际使用中验证过，spaCy 的实体偏移是字符层面的，而不是词层面的，这个设计对中文特别友好——因为中文实体经常跨词边界，比如“北京市朝阳区”是三个词，但你希望它作为一个完整的 GPE 实体被识别出来。

2.3 它和“预训练模型”之间的关系

还有一个常被误解的概念。很多人以为 spaCy 就是一个分词器，其实它的价值主要在预训练模型里。中文模型包zh_core_web_sm、zh_core_web_md、zh_core_web_lg这些，其实是“模型 + 词向量 + 管线配置”的打包产物。

我最初图省事只装了sm版本，结果发现它对长文本的实体召回率一般，后来换了lg版本，明显感觉到地名和机构名的边界判断更准了。这不是玄学，而是lg模型里包含了更大的静态词向量，尽管现代 NER 模型更多依赖上下文编码，但静态向量作为输入特征仍然能提供有价值的先验知识。选型建议是：内存不敏感就上大模型，追求低延迟就选小模型，后面我会给出具体评估数据。

3. 环境准备与模型选型实操

3.1 安装步骤与版本选择

这部分是纯实操，跟着做就行。我使用的是 Python 3.10，spaCy 版本是 3.7.x，这两个版本组合相对稳定。安装命令非常简单：

pip install spacy python -m spacy download zh_core_web_lg

这里有个细节要注意：python -m spacy download下载的是指定版本的模型包，它和 spaCy 框架版本必须匹配。如果你先装了一个很新的 spaCy，再下载一个旧模型包，可能在加载时直接报错，提示版本不兼容。为了避免这个问题，我推荐一种更稳妥的方式：直接指定版本安装。

pip install spacy==3.7.2 pip install https://github.com/explosion/spacy-models/releases/download/zh_core_web_lg-3.7.0/zh_core_web_lg-3.7.0-py3-none-any.whl

装完以后，可以写一个三行脚本验证环境：

import spacy nlp = spacy.load("zh_core_web_lg") doc = nlp("小明在北京的字节跳动公司工作") for ent in doc.ents: print(ent.text, ent.label_)

预期输出会包含小明（PERSON）、北京（GPE）、字节跳动公司（ORG）。如果这里没识别出来，大概率是模型没有真正加载成功或者版本不对，先解决环境问题再往下走。

3.2 不同中文模型的对比和选择

我把三个常用中文模型都实际跑了一遍，用了一段大约 1000 字的混合文本（包含新闻、人物介绍、公司信息），测试结果大概如下：

注意，这里 F1 是我在特定测试集上的主观感受，不是官方基准，但它反映的趋势是对的：模型越大，实体边界越准。尤其是GPE和ORG这两类，小模型的误判率明显偏高，经常把“美国”识别成GPE没问题，但把“美国队”整体当GPE就尴尬了。大模型在这类边界问题上好很多。

内存方面，lg模型加载后大概占用 600MB 左右内存，如果你是在 2GB 内存的服务器上跑，建议老老实实用sm加规则兜底，不要硬上大模型。我在一台 4GB 内存的虚拟机上跑lg，做单条短文本推理没问题，但一旦批量处理几十万条，内存直接告警，最后不得不切回md加自定义规则方案。

3.3 试试 spaCy 自带的可视化调试工具

调 NER 的时候，光看打印出来的(text, label_)列表不够直观。spaCy 自带一个displacy工具，可以直接把实体渲染成网页上那种高亮带标签的形式。

from spacy import displacy doc = nlp("腾讯控股在深圳发布2024年度财报，马化腾出席发布会") html = displacy.render(doc, style="ent", jupyter=False) with open("visual.html", "w", encoding="utf-8") as f: f.write(html)

用浏览器打开visual.html，每个实体都会被不同颜色的标记框出来。这个工具有个隐藏价值：你可以通过视觉检查快速发现模型的系统性问题，比如某个类型一直在多标或少标，而不需要一条条对文本。

我用这个工具检查第一批测试结果时，发现模型把大量公司产品的简称（例如“微信”）识别成了PERSON。后来仔细一看，是因为该词在训练语料里经常作为发言人姓名出现，产生了数据偏差。这个发现直接引导我用了第 4 节的规则修正方案。

4. 核心实操：用 spaCy 做中文命名实体识别的完整流程

4.1 基础预测：加载模型并抽取实体

当你拿到一批文本，第一步就是加载模型、逐条处理、收集结果。这里有一个比较容易忽略的点：nlp()返回的 Doc 对象里，不仅包括doc.ents，还包括每个词 token 的细粒度标签，比如token.ent_iob_和token.ent_type_。如果你需要把每个 token 的位置都弄清楚，或者要导出 BIO 格式的训练数据，这套底层信息是绕不开的。

import spacy from spacy import displacy nlp = spacy.load("zh_core_web_lg") texts = [ "阿里巴巴集团创始人马云在杭州出席了活动", "华为发布新手机，余承东表示销量超出预期", "中国石油在新疆发现了新的油田" ] for text in texts: doc = nlp(text) print("原文：", text) for ent in doc.ents: print(f" 实体: {ent.text}, 类型: {ent.label_}, 位置: {ent.start}:{ent.end}")

输出时，ent.start和ent.end是字符级的偏移量。举个例子，"阿里巴巴集团"如果作为一个实体，起始位置是 0，结束位置是 6。这个偏移量在你后续要做文本打标、知识图谱构建时非常关键，直接用text[ent.start:ent.end]就能截取实体原文，不会出错。

4.2 关键参数调整：如何控制 NER 的灵敏度

spaCy 预训练模型对短文本的实体识别默认是“宁可少标，不愿错标”，但实际业务往往希望召回率更高一些。你可以通过修改 NER 组件的scorer阈值或后处理逻辑来调整，但最直接的方式是在管道中增加规则组件做修正。

举个例子，我想让模型对“某某公司”这类模式更敏感，可以先定义一个实体标注规则：

import spacy from spacy.tokens import Span nlp = spacy.load("zh_core_web_lg") def add_company_ent(doc): new_ents = [] for token in doc: if token.text.endswith("公司") and token.text not in [e.text for e in doc.ents]: ent = Span(doc, token.i, token.i + 1, label="ORG") new_ents.append(ent) # 合并原有实体与新实体，同时过滤重叠 final_ents = list(doc.ents) + new_ents filtered = [] seen = set() for ent in final_ents: if (ent.start, ent.end) not in seen: seen.add((ent.start, ent.end)) filtered.append(ent) doc.ents = filtered return doc nlp.add_pipe(add_company_ent, after="ner") doc = nlp("腾讯公司和未知公司合作") for ent in doc.ents: print(ent.text, ent.label_)

这类“基于规则的校正”是一个很实用的生产技巧，特别适合词典里的高频词、品牌词。它不是重新训练模型，只是在预测结果上做修正，所以速度快，也不影响模型本身的泛化能力。

4.3 自定义实体类型：基于规则添加新类别

很多时候，预置的PERSON、ORG、GPE并不能满足业务需求。比如我要识别文本里的“产品型号”，它可能长得像iPhone 15 Pro、A100 GPU、X2000-4T。这些模式很规律，用规则远好过于训练模型。

spaCy 提供了EntityRuler，专门用来干这个。它支持两种匹配模式：一种是纯文本匹配，一种是基于词性、词形、正则表达式的匹配。

import spacy from spacy.pipeline import EntityRuler nlp = spacy.load("zh_core_web_lg") ruler = EntityRuler(nlp) patterns = [ {"label": "PRODUCT", "pattern": [{"TEXT": {"REGEX": "X[0-9]{4}-[A-Z0-9]+"}}]}, {"label": "PRODUCT", "pattern": [{"LOWER": "iphone"}, {"TEXT": {"REGEX": "\\d+\\s?(pro|mini|max)?"}}]} ] ruler.add_patterns(patterns) nlp.add_pipe(ruler, before="ner")

这里我特意把EntityRuler放在ner组件之前，这样规则匹配到的实体可以作为先验信息传入 NER 组件。反过来，如果你把规则放在 NER 之后，规则只会做后处理，两者的交互逻辑完全不同。实际项目里哪种顺序更好，取决于你的规则和模型谁更可靠：如果规则是“硬规则”，应该放在前面；如果规则是“兜底”，放在后面。

还有一个细节要注意：EntityRuler的匹配是基于 token 的，中文里 token 是词级别的。所以如果产品名里包含“苹果手机”这种一个词拆不开的表达，你需要让分词器别把它切开，或者在 pattern 里用TEXT的完整值匹配，不能图省事只写一个词根。

4.4 训练自定义实体：从 BIO 标注到 spaCy 格式

真实业务里，规则永远无法覆盖所有表达。比如“某高管被任命为CEO”这种语义关系，规则无法泛化，这时就需要用标注数据训练自己的 NER 模型。

spaCy 训练自定义实体的输入格式是Doc对象的spans信息，不是纯文本。你可以从一个简单的 BIO 标注文件生成：

阿 O 里 B-PERSON 巴 I-PERSON 巴 I-PERSON 集 O 团 O 创 O 始 O 人 O 马 B-PERSON 云 I-PERSON

转换脚本大致是这样：

def convert_bio_to_spacy(bio_path, output_path, nlp): docs = [] words, ents = [], [] with open(bio_path, "r", encoding="utf-8") as f: for line in f: line = line.strip() if not line: if words: doc = nlp.make_doc("".join(words)) doc.ents = [ Span(doc, start, end, label) for start, end, label in ents ] docs.append(doc) words, ents = [], [] else: parts = line.split() if len(parts) == 2: word, tag = parts else: continue start_char = len("".join(words)) words.append(word) if tag != "O": prefix, label = tag.split("-", 1) if prefix == "B": ents.append([start_char, start_char + len(word), label]) elif prefix == "I": if ents and ents[-1][2] == label: ents[-1][1] = start_char + len(word)

然后调用spacy.training做增量训练：

import spacy from spacy.training import Example import random nlp = spacy.load("zh_core_web_lg") ner = nlp.get_pipe("ner") ner.add_label("POSITION") optimizer = nlp.resume_training() for itn in range(30): random.shuffle(docs) losses = {} for doc in docs: example = Example.from_dict(doc, {"entities": [(ent.start, ent.end, ent.label_) for ent in doc.ents]}) nlp.update([example], sgd=optimizer, losses=losses) print(f"iteration {itn}: {losses}")

训练完成后，nlp.to_disk("custom_ner_model")即可保存。下次加载时用spacy.load("custom_ner_model")，你自定义的POSITION类型就会和预置类型共存。

这里我必须提醒一句：resume_training()是在原有模型基础上继续训练，不是从零开始。如果你数据量特别少（比如几百条），那么训练轮次建议控制在 20~50 轮之间，多了会过拟合，把原有模型的能力损坏掉。我在一次实验中，用 500 条数据训了 100 轮，结果预置的GPE识别率从 0.85 掉到了 0.60，典型的灾难性遗忘。后来把轮次降到 30，并加入一部分原始模型的通用标签数据做混合训练，问题才缓解。

5. 数据准备与标注格式进阶

5.1 中文实体标注的两个核心难点

做自定义实体训练，第一关不是模型，而是数据标注。中文标注有两个核心难点，我想单独拿出来说清楚。

第一个难点是实体边界模糊。“北京大学”是机构名，但“北京大学的张教授”里“北京大学”做定语，本质上还是机构名，边界没变化。不过“北京”是地名，“大学”是普通名词，如果标成GPE就没道理了。这个问题没有银弹，只能靠标注规范的粒度来统一：是标最小语义单位（北京、大学各自独立），还是标完整组合（北京大学）？一旦定了，全流程都要遵守。

第二个难点是嵌套实体。比如“中国石油天然气集团公司”，内部嵌套“中国石油”“天然气”“集团公司”等多个潜在实体。在常见的 BIO 格式里，嵌套只能取一层，你必须决定是标最大的机构名，还是标内部的局部实体。我不建议在初版数据里引入嵌套标注，工程复杂度会指数上升。宁可先统一成扁平标注，等模型基线出来，再针对高频嵌套场景加规则或第二层模型。

5.2 标注工具推荐与协作建议

spaCy 官方提供了prodigy标注工具，商业授权，效果很好，但我更喜欢在早期用轻量方案。常用的有：

• Label Studio：开源，支持 NER 的 span 标注，导出格式可以转成 spaCy 的.spacy文件。是个人项目里我最常用的。
• Doccano：轻量文本标注工具，适合小型团队。
• 手工 JSON：数据在几百条时，直接写脚本在终端里逐条录入也没有问题。

无论用哪个工具，我建议导出后写一个统一的校验脚本，检查最多的三个问题：标签是否合法、偏移量是否对齐（text[start:end]和标注文本是否一致）、是否有重叠实体。

def validate(doc): text = doc.text for ent in doc.ents: assert text[ent.start:ent.end] == ent.text, f"偏移错误: {ent.text} vs {text[ent.start:ent.end]}" assert ent.label_ in LABELS, f"非法标签: {ent.label_}"

这个脚本能在早期拦截 80% 的数据错误，避免模型训完才发现数据有问题。

5.3 转换到 spaCy 二进制训练格式

spaCy 3.x 的训练流程通常以.spacy二进制文件为输入。你不需要自己写序列化，可以用spacy.training里的工具函数把 Doc 列表保存为二进制：

from spacy.training import biluo_tags_to_spans from spacy.tokens import DocBin from spacy.util import minibatch db = DocBin() for doc in docs: db.add(doc) db.to_disk("train.spacy") db.to_disk("dev.spacy")

然后将config.cfg里的训练数据路径指过去，就能跑spacy train了。这一步能避免你用 JSON 或其他格式踩一些奇怪的坑——二进制格式是 spaCy 原生支持，序列化效率高，加载速度快，训练中也更稳定。

6. 性能优化与部署实践

6.1 批处理加速方案

处理大量文本时，千万别一条条循环调用nlp()。spaCy 的nlp.pipe()天生支持批处理，内部的模型推理是向量化的，能充分利用 CPU/GPU 并行能力。

texts = [...] # 大量文本列表 for doc in nlp.pipe(texts, batch_size=64, n_process=2): # 处理单个 doc pass

batch_size的选择要平衡内存和速度。我在一台 8 核 CPU 的机器上测试过：

• batch_size=32，内存稳定，吞吐量适中；
• batch_size=128，吞吐量提升约 30%，但内存占用也涨了近一倍；
• 如果文本长度差异很大，建议先按长度排序再分批，避免 GPU/CPU 浪费在 padding 上。

6.2 用正则表达式做实体后处理

模型再准，也不可能 100% 贴合业务。我在生产代码里总会留一个“后处理扩展”的接口，专门处理模型输出里的系统性问题。

举例来说，模型经常把“腾讯音乐”拆成腾讯（ORG）和音乐（无标签），但我希望它整体作为ORG。可以在管道末尾加一个规则替换：

import re from spacy.tokens import Span def merge_org(doc): text = doc.text pattern = re.compile(r"(腾讯音乐|华为云|阿里健康)") for match in pattern.finditer(text): start, end = match.span() # 判断这段字符是否已经被标成实体或部分实体 if not any(e.start <= start and e.end >= end for e in doc.ents): doc.ents = list(doc.ents) + [Span(doc, start, end, "ORG")] return doc

这种做法的好处是，你不需要为了几个固定短语去重新训练模型，部署快，逻辑透明，出了问题也容易回滚。代价是维护正则列表比较枯燥，但收益是可解释、可控。所有后处理规则我建议单独写一个配置文件维护，不要散落在主流程代码里。

6.3 模型服务的接口封装

模型最终要对外提供服务，我一般是封装一个独立的 FastAPI 服务，把 spaCy 模型常驻内存，通过 HTTP 接口接收文本并返回结构化 JSON。

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() nlp = load_model() class TextInput(BaseModel): text: str @app.post("/ner") def ner_endpoint(input: TextInput): doc = nlp(input.text) ents = [ {"text": ent.text, "label": ent.label_, "start": ent.start, "end": ent.end} for ent in doc.ents ] return {"entities": ents}

启动时用uvicorn app:app --host 0.0.0.0 --port 8000，再用 Nginx 做反向代理。这个接口可以直接给前端调用，也可以作为内部微服务给下游的清洗、检索模块调用。如果你担心并发，可以用一个全局锁或进程池来控制模型实例数量，避免同一时间大量请求打进来把内存撑爆。

7. 常见问题与排查技巧实录

7.1 加载模型失败或内存不足

现象：spacy.load("zh_core_web_lg")报错OSError: [E050] Can't find model 'zh_core_web_lg'。

排查：先确认模型包是否真的下载成功。用python -m spacy info zh_core_web_lg检查，如果没有输出，说明模型没装好。更常见的情况是模型包版本和 spaCy 版本不匹配。我在好几个环境里遇到zh_core_web_lg装的是旧版，spaCy 是 3.7，两者不兼容，加载时直接报 E050。解决方式是卸载重装匹配版本：

pip uninstall zh_core_web_lg -y pip install https://github.com/explosion/spacy-models/releases/download/zh_core_web_lg-3.7.0/zh_core_web_lg-3.7.0-py3-none-any.whl

内存不足的解决思路：换sm或md模型；如果必须用lg，就把进程的内存上限调高，或者减少并发。服务器上跑之前先用free -g看一眼，别到 OOM 才找原因。

7.2 实体识别不准，尤其是人名地名

现象：模型把人名和头衔粘在一起，比如“董事长马云”被整体识别成PERSON；或者“上海市政府”被拆成上海和市政府。

原因：中文实体边界和词边界天然不对齐，预训练模型对低频词的边界判断也不稳定。这属于模型本身的局限，不是代码 bug。

对策：优先用EntityRuler添加高频人物、地名后缀规则；其次检查你输入文本里是否有特殊符号干扰。我踩过的坑是——文本里如果有多余的引号、括号、换行符，模型很容易把符号附近的内容误判为实体的一部分。预处理环节加一步清洗，把全角空格、不可见字符去掉，能显著改善边界准确率。

7.3 自定义实体训练后原有实体识别变差

这是增量训练最容易踩的坑，我在 4.4 节里提过一次，这里再展开讲。

原因：增量训练时，优化器只看到新数据，对旧知识产生了灾难性遗忘。特别是数据量小、训练轮次高的情况下，模型会过度拟合新实体类型，同时丢失对PERSON、GPE等的判别能力。

解决方案有几条：

1. 使用较大的学习率衰减策略，训练轮次控制在 20~30 之间；
2. 训练数据里混入一部分带预置实体标签的历史样本，比如每 100 条新数据里掺 20 条原始训练集样本；
3. 先冻结 NER 组件的部分参数，只更新最后几层；
4. 如果资源允许，也可以在完整数据集上从零训练，而不是增量训练。

我用过最有效的还是混合训练。具体操作：从原始模型训练语料中截取一小部分（或者拿一批已标注好的通用数据），加入docs列表中一起nlp.update()，这样模型在拟合新任务的同时不会忘掉老任务。

7.4 统一实体格式：时间、日期和数值的归一化

预训练模型识别DATE和TIME时，返回的通常是原文片段，比如“2024年3月15日”“下午三点”。但下游通常需要标准化的时间格式。我一般会加一个后处理函数，把文本时间格式转换成 ISO 8601 或者时间戳：

import re from dateutil import parser def normalize_time(text): text = text.replace("年", "-").replace("月", "-").replace("日", "") try: return parser.parse(text).isoformat() except: return None

当然，中文时间表达有大量口语和模糊表述，比如“上个月”“三周后”，这类情况和 NER 关系不大，建议单独用时间解析库处理，不要把这个问题扔给 NER 模型。

8. 性能评估指标与调优心得

8.1 用官方工具算精确率、召回率和 F1

模型跑完不是看一眼效果就行，需要用量化指标评估。spaCy 自带scorer，可以对标注数据做评估：

from spacy.scorer import Scorer from spacy.training import Example examples = [] for doc in dev_docs: pred = nlp(doc.text) examples.append(Example(pred, doc)) scores = Scorer().score(examples) print(scores["ents_p"], scores["ents_r"], scores["ents_f"])

这里的ents_p是精确率，ents_r是召回率，ents_f是 F1。在中文 NER 上，我一般会重点看ents_per_type的细分分数，因为整体分数可能被高频实体拉高，低频但重要的实体类别表现反而很差。

举个例子，有一次我的整体 F1 到了 0.88，但拆开一看，PERSON的 F1 只有 0.62，原因是训练数据里人名样本不够多，模型已经“偏科”了。后面我补充了 200 条人名密集的标注数据，PERSONF1 直接升到 0.80。

评估这块虽然枯燥，但真不能省。哪怕只是每周跑一次离线评估，也能在模型退化初期发现问题，而不是等部署上线后让业务团队来投诉。

8.2 常见调优技巧：数据增强和难例挖掘

一个特别有效的技巧是难例挖掘。把模型预测错误的样本收集起来，人工修正，再加回训练集。这比随机补充数据高效得多，因为模型最缺的恰恰是它“不确定”的那部分样本。

具体操作流程：

1. 在开发集上跑模型，输出所有预测错误的实体；
2. 按错误类型归类：边界错误、标签错误、漏识别；
3. 挑出高频的错误模式，针对性地补标注数据；
4. 每补充一批，重新训练并评估，看 F1 是否提升。

我在一次项目里用这个流程，三轮迭代把 F1 从 0.78 提到了 0.86，每一轮只补充几百条样本。数据增强没有捷径，但在方向正确的前提下，少量高质量数据就能带来明显收益。

8.3 规则和模型的配合策略

走到这一步，你应该能理解为什么我强调规则和模型要混合使用了。规则解决高置信、低泛化的场景，模型解决低置信、高泛化的场景。两者是互补关系，不是替代关系。

我自己的实践准则是：

• 高频且模式稳定的实体（型号、编号、固定品牌）用规则；
• 低频且表达多样的实体（人名、地名、机构全称）用模型；
• 规则和模型都输出时，以规则优先，但要加入“重叠过滤”逻辑；
• 规则识别不到的，再交给模型，作为兜底。

这套策略的好处是，即使规则部分更新频繁，也不会影响模型的稳定性。部署上线后，我可以在不重新训练模型的情况下，通过修改规则配置文件快速适配新业务，这对运营迭代非常友好。

9. 后续扩展与个人体会

这个基于 spaCy 的中文 NER 项目，最初只是我随手调研的一个技术方案，但实际落地后帮我把一条完整的文本处理链路跑通了，从数据标注、模型训练、规则融合，到最终的接口封装。整套流程跑完，我对 spaCy 的工程化能力有了很深的信任感。

如果你后续想继续扩展，有几个方向我认为值得投入：一是把 NER 的结果接入知识图谱，实体作为节点，关系作为边，做成一个完整的实体关系抽取 pipeline；二是在现有模型基础上引入更多预训练语言模型特征，比如用 Transformer 编码替代静态词向量，进一步提升低频实体的识别效果；三是做实体链接，把识别出的“华为”链接到知识库中特定的实体现有编码上，这个方向挑战很大，但业务价值也很大。

最后分享一个我个人的体会：用 spaCy 做中文 NER，最大的瓶颈从来不是框架本身，而是你对数据的理解和对错误的分析能力。框架会给你一套好用的工具，但只有当你愿意反复检查输出、拆分错误类型、针对性补充数据时，模型效果才会真正上一个台阶。如果你现在正被中文实体边界问题困扰，不妨按这篇文章的思路先搭一个最小可用版本，用真实数据跑一遍，再决定下一步是加规则还是加训练数据。实践出真知，赶紧动手吧。