1. 为什么中文命名实体识别我选了 spaCy先交代一下背景。我前阵子接了个文本挖掘的活要在一批中文资讯里把人名、机构名、地点、时间这些实体抽出来喂给下游的关联分析。刚开始我没多想直接拿现成的一套分词工具加规则去搞结果实体边界各种乱人名和头衔粘在一起地名拆得七零八落规则越写越厚还互相打架。后来换了思路认真评估了一圈开源方案最后落地在 spaCy 上。很多人一听 spaCy 的第一反应是“这不是英文 NLP 的工具吗中文能行吗”。说实话我一开始也有这个顾虑但实际跑完一通之后我的结论是spaCy 在中文 NER 这件事上完全够用而且它的工程化体验比不少中文原生的框架要舒服得多。它能做到什么程度呢——预训练的中文模型直接能识别PERSON、ORG、GPE地理政治实体、TIME、DATE这些常见类型如果业务里有特殊实体比如药品名、产品名、文件编号你也可以用很小的样本量训练出自己的实体类型或者用基于规则的组件快速兜底。这篇文章适合谁看呢。一是刚接触 NLP、想找一个能快速落地中文实体抽取方案的开发者二是已经在用规则或词典做抽取、但被维护成本和准确率折磨得头大的朋友。我尽量把从安装、模型选型、推理、到自定义训练的完整链路都写清楚附上我实际跑过的参数和踩坑记录你可以直接照着复现不用再走一遍弯路。2. 方案选型spaCy 在中文 NER 里的定位和优势2.1 生态里有哪些选择我为什么没选它们中文实体识别这事市面上能用的方案大概分四类基于词典和规则的、基于标注平台生成的序列标注模型、各种大模型的 Few-shot 抽取、以及今天要重点讲的 spaCy 这类通用 NLP 框架。基于词典和规则比如自己维护一个机构名表加前后缀匹配短平快但泛化能力几乎没有。我遇到过的情况是今天新增一个公司名明天改个简称后天又来个“某某分公司”规则永远在打补丁。基于序列标注的模型比如用某个深度学习框架自己训 BERTCRF效果确实好但对硬件和数据标注量的要求偏高团队里如果没有专门做 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.10spaCy 版本是 3.7.x这两个版本组合相对稳定。安装命令非常简单pip install spacy python -m spacy download zh_core_web_lg这里有个细节要注意python -m spacy download下载的是指定版本的模型包它和 spaCy 框架版本必须匹配。如果你先装了一个很新的 spaCy再下载一个旧模型包可能在加载时直接报错提示版本不兼容。为了避免这个问题我推荐一种更稳妥的方式直接指定版本安装。pip install spacy3.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粗略适用场景zh_core_web_sm约 20MB快0.75~0.80原型验证、延迟敏感zh_core_web_md约 50MB中0.80~0.85一般生产环境zh_core_web_lg约 120MB较慢0.85~0.90离线批处理、质量优先注意这里 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, styleent, jupyterFalse) with open(visual.html, w, encodingutf-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, labelORG) 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, afterner) 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, beforener)这里我特意把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, encodingutf-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], sgdoptimizer, losseslosses) print(fiteration {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_size64, n_process2): # 处理单个 doc passbatch_size的选择要平衡内存和速度。我在一台 8 核 CPU 的机器上测试过batch_size32内存稳定吞吐量适中batch_size128吞吐量提升约 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] Cant 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等的判别能力。解决方案有几条使用较大的学习率衰减策略训练轮次控制在 20~30 之间训练数据里混入一部分带预置实体标签的历史样本比如每 100 条新数据里掺 20 条原始训练集样本先冻结 NER 组件的部分参数只更新最后几层如果资源允许也可以在完整数据集上从零训练而不是增量训练。我用过最有效的还是混合训练。具体操作从原始模型训练语料中截取一小部分或者拿一批已标注好的通用数据加入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 常见调优技巧数据增强和难例挖掘一个特别有效的技巧是难例挖掘。把模型预测错误的样本收集起来人工修正再加回训练集。这比随机补充数据高效得多因为模型最缺的恰恰是它“不确定”的那部分样本。具体操作流程在开发集上跑模型输出所有预测错误的实体按错误类型归类边界错误、标签错误、漏识别挑出高频的错误模式针对性地补标注数据每补充一批重新训练并评估看 F1 是否提升。我在一次项目里用这个流程三轮迭代把 F1 从 0.78 提到了 0.86每一轮只补充几百条样本。数据增强没有捷径但在方向正确的前提下少量高质量数据就能带来明显收益。8.3 规则和模型的配合策略走到这一步你应该能理解为什么我强调规则和模型要混合使用了。规则解决高置信、低泛化的场景模型解决低置信、高泛化的场景。两者是互补关系不是替代关系。我自己的实践准则是高频且模式稳定的实体型号、编号、固定品牌用规则低频且表达多样的实体人名、地名、机构全称用模型规则和模型都输出时以规则优先但要加入“重叠过滤”逻辑规则识别不到的再交给模型作为兜底。这套策略的好处是即使规则部分更新频繁也不会影响模型的稳定性。部署上线后我可以在不重新训练模型的情况下通过修改规则配置文件快速适配新业务这对运营迭代非常友好。9. 后续扩展与个人体会这个基于 spaCy 的中文 NER 项目最初只是我随手调研的一个技术方案但实际落地后帮我把一条完整的文本处理链路跑通了从数据标注、模型训练、规则融合到最终的接口封装。整套流程跑完我对 spaCy 的工程化能力有了很深的信任感。如果你后续想继续扩展有几个方向我认为值得投入一是把 NER 的结果接入知识图谱实体作为节点关系作为边做成一个完整的实体关系抽取 pipeline二是在现有模型基础上引入更多预训练语言模型特征比如用 Transformer 编码替代静态词向量进一步提升低频实体的识别效果三是做实体链接把识别出的“华为”链接到知识库中特定的实体现有编码上这个方向挑战很大但业务价值也很大。最后分享一个我个人的体会用 spaCy 做中文 NER最大的瓶颈从来不是框架本身而是你对数据的理解和对错误的分析能力。框架会给你一套好用的工具但只有当你愿意反复检查输出、拆分错误类型、针对性补充数据时模型效果才会真正上一个台阶。如果你现在正被中文实体边界问题困扰不妨按这篇文章的思路先搭一个最小可用版本用真实数据跑一遍再决定下一步是加规则还是加训练数据。实践出真知赶紧动手吧。