企业官网建设流程全解析

1. 这不是“识别文字”那么简单：OCR+NLP信息抽取在金融与物流现场的真实价值

你手头有一张银行回单、一份快递面单、一张保险保单，或者一叠扫描版的合同附件——这些纸面上的信息，每天都在真实业务中产生巨大成本。我做过三个不同规模的金融与物流系统升级项目，最深的体会是：90%以上的“自动化失败”，不是因为模型不准，而是因为没搞清OCR和NLP在真实业务流里各自该干啥、不该干啥、以及它们之间那条看不见的交接线在哪。这个标题里的“OCR+NLP信息抽取”，绝不是把两个技术名词拼在一起就完事了。它是一套需要深度嵌入业务毛细血管的操作体系：OCR负责把模糊、歪斜、带印章、有表格线、甚至被复印过三次的纸质文档，“翻译”成机器可读的文本坐标流；而NLP不是简单地对这段文本做关键词匹配，它要理解“开户行”后面跟着的到底是“中国XX银行XX支行”还是“XX村镇银行”，要分辨“收货地址”字段里混进来的“请勿拆封”备注，还要在物流运单上从“2024-03-15 14:22”和“预计3月18日送达”中精准锚定那个真正影响KPI的“承诺送达时间”。金融行业要的是零容错的结构化字段——比如“贷款金额”必须精确到小数点后两位且不能与“手续费”混淆；物流行业要的是强时效性字段——比如“装车时间”一旦识别延迟5分钟，整个分拨中心的调度算法就可能失效。所以这篇文章不讲模型架构图，不堆论文指标，只讲我在某银行票据中心、某全国性快递企业结算部、某供应链金融平台实际落地时，怎么用OCR+NLP组合拳把“一堆PDF”变成“可写入数据库的干净JSON”，以及踩过的那些连技术文档都不会写的坑。

2. 核心设计逻辑：为什么必须是“OCR+NLP”双阶段，而不是端到端大模型？

2.1 业务场景倒逼的技术分层：从“能认字”到“懂业务”的跃迁

很多人第一反应是：“现在大模型这么强，直接扔一张图片进去，让它输出结构化JSON不就行了？”我试过。用某开源多模态模型处理1000张银行承兑汇票扫描件，结果是：字段提取准确率表面看有86%，但其中72%的错误集中在“出票日期”和“到期日”的混淆上——模型把“2024年03月15日”识别为“2024年03月15日（出票）”，却把旁边手写的“到期：2024.06.15”当成备注过滤掉了。问题出在哪？OCR和NLP解决的是两类根本不同的问题，强行合并会牺牲关键业务约束。OCR的本质是空间感知任务：它必须回答“这个‘金额’字样在页面左上角第3行，它右边紧挨着的数字区域坐标是多少”，这依赖图像预处理、版面分析、文字检测与识别的完整链路；而NLP的本质是语义推理任务：它必须回答“这个数字区域里的‘¥5,000,000.00’，结合上下文‘出票金额’标题和下方‘小写金额’字样，应归属为‘票据金额’字段，且需去除逗号、保留两位小数”。把这两个任务塞进一个模型，就像让一个既要看地图又要算账的会计，同时盯着GPS坐标和资产负债表——注意力必然分散。在金融场景，我们要求“出票人全称”字段100%准确，哪怕OCR把某个字识别错了，NLP也必须通过上下文（如“XX证券股份有限公司”在银行业务中不可能是个人姓名）强行校正；在物流场景，我们要求“运单号”必须100%无歧义，哪怕OCR把“SF123456789CN”识别成“SF123456789CⅣ”，NLP也必须通过规则库（如顺丰单号末尾必为CN或HK）完成纠错。这种强业务规则驱动的校验，必须由独立的NLP模块承载。

2.2 为什么不用纯规则引擎？——当业务规则开始“长腿跑”

有人会说：“那我直接写正则表达式+模板匹配不就行了？”某物流客户最初就是这么干的。他们为TOP 20快递公司的面单设计了20套固定模板，每套模板定义了“收件人姓名”在第几行第几列。结果呢？当德邦快递上线新版电子面单，把“收件人电话”从右上角移到左下角，整个系统停摆4小时——因为规则引擎不会“看布局”，只会“数格子”。而OCR+NLP的威力在于：OCR先做版面分析（Layout Analysis），把整张面单自动切分成“寄件人区块”、“收件人区块”、“物品信息区块”、“条码区块”；NLP再在每个区块内做语义角色标注（Semantic Role Labeling），识别“谁是动作发出者（寄件人）、谁是接收者（收件人）、物品是什么、数量多少”。这就让系统具备了“理解文档结构”的能力，而不是死记硬背坐标。更关键的是，NLP模块可以接入动态知识库：比如金融行业新增了“绿色信贷”分类，只需在NLP的实体词典里增加“碳减排支持工具”“可持续发展挂钩债券”等术语，无需修改OCR代码；物流行业新增冷链运输品类，只需更新NLP的“货物类型”分类模型，OCR部分完全不动。这种解耦带来的可维护性，在业务快速迭代的今天，比初始开发节省的时间重要得多。

2.3 模型选型背后的现实妥协：精度、速度与部署成本的三角平衡

在真实项目里，没有“最好”的模型，只有“最合适”的组合。我给某城商行做的票据识别系统，最终选型是：OCR用PaddleOCR的PP-StructureV2（轻量版），NLP用基于BERT微调的序列标注模型。为什么？因为银行核心系统要求单张票据处理时间≤1.2秒，而服务器GPU资源只有2块T4。如果换成更强的YOLOv8+LayoutLMv3组合，单张处理要2.8秒，超时直接触发熔断。而在某快递企业的分拨中心，他们用的是更激进的方案：OCR用OpenCV+自研二值化算法（不依赖深度学习，CPU即可运行），NLP用TinyBERT+规则后处理。原因很实在——分拨中心的工控机没有GPU，且每小时要处理2万张面单，延迟必须压到300ms以内。这里的关键决策点是：OCR阶段追求“鲁棒性优先”，NLP阶段追求“语义精度优先”。OCR可以接受把“￥”识别成“Y”，只要数字区域坐标抓得准；NLP则必须区分“Y5000000”和“¥5,000,000.00”，因为前者可能是OCR噪声，后者才是有效金额。所以我们在OCR后加了一道“坐标清洗”环节：用规则过滤掉高度<8px、宽度>200px的异常文本框（通常是扫描污渍）；在NLP前加了一道“文本归一化”环节：把所有“Y”“¥”“RMB”统一转为“¥”，把“1,000.00”标准化为“1000.00”。这些看似琐碎的步骤，恰恰是工业级落地和实验室Demo的核心分水岭。

3. 核心细节拆解：从一张快递面单看OCR+NLP如何协同作战

3.1 OCR阶段：不只是“认字”，更是“读懂纸面空间关系”

以一张典型的申通电子面单为例（非真实单号，仅作示意），OCR要完成三重任务：

第一重：版面分割（Layout Parsing）
这不是简单的“找文字”，而是理解这张纸的“骨骼”。PP-StructureV2会输出这样的结构化结果：

{ "page_id": 0, "layout": [ {"type": "title", "bbox": [52, 48, 210, 72], "text": "申通快递"}, {"type": "table", "bbox": [30, 90, 580, 320], "rows": 5, "cols": 4}, {"type": "barcode", "bbox": [420, 330, 570, 380]}, {"type": "signature", "bbox": [100, 400, 300, 430]} ] }

注意，这里"table"类型不是指Excel表格，而是OCR识别出“这一片区域存在表格线，内容按行列组织”。这对后续NLP至关重要——我们知道“收件人信息”大概率在第二行，“物品名称”在第四行。

第二重：文字检测与识别（Detection & Recognition）
在"table"区域内，OCR会逐单元格输出文本及坐标：

{ "cell_2_1": {"text": "收件人", "bbox": [45, 125, 95, 145]}, "cell_2_2": {"text": "张三", "bbox": [110, 125, 150, 145]}, "cell_2_3": {"text": "联系电话", "bbox": [170, 125, 240, 145]}, "cell_2_4": {"text": "138****1234", "bbox": [255, 125, 340, 145]} }

这里的关键是"bbox"（边界框）坐标。很多团队忽略这点，直接把所有文本按y坐标排序拼成字符串，结果“张三”和“1381234”被连成“张三1381234”，NLP再也分不清姓名和电话。我们必须保留原始空间关系。

第三重：关键挑战应对（真实场景的“脏数据”处理）

• 印章覆盖：面单右上角常有红色“已验视”章，会干扰“寄件人电话”识别。我们的方案是：在OCR前加一道“红章抑制”预处理——用HSV色彩空间分离红色通道，对红色区域做形态学腐蚀，再用高斯模糊弱化边缘，实测将印章区域误识率从37%降到4%。
• 手写体混杂：客户常在“备注”栏手写“易碎请轻放”。OCR对印刷体准确率99%，对手写体只有62%。对策是：对低置信度文本（OCR返回score<0.85）打上[HANDWRITING]标签，NLP模块收到后自动触发“手写文本专用解析流”，用更小的LSTM模型专攻手写特征。
• 多语言混排：国际件面单有中英文地址。OCR必须支持多语言检测，我们用PaddleOCR的multilingual模型，但发现它对“深圳市南山区科技园”中的“科技园”（Park）识别成“ParK”，于是加了后处理规则：当英文单词首字母大写、末尾为K且长度≤4时，强制校正为“Park”。

提示：OCR输出的坐标必须是绝对坐标（相对于原图左上角），而非归一化坐标。否则在不同分辨率设备上，NLP的坐标关联会失效。我们曾因一个归一化bug，导致在高拍仪（300dpi）和手机拍照（72dpi）两种输入下，同一张面单的“收件人姓名”字段提取结果完全不同。

3.2 NLP阶段：从“文本串”到“业务实体”的语义炼金术

OCR输出的是带坐标的文本碎片，NLP的任务是把这些碎片“焊接”成业务认可的实体。仍以申通面单为例，NLP流程如下：

第一步：文本聚合与上下文构建
不直接处理单个"cell_2_2": "张三"，而是构建上下文窗口：

[上文] 收件人 | 联系电话 | 地址 | 备注 [当前行] 张三 | 138****1234 | 深圳市南山区科技园科发路8号 | 易碎请轻放 [下文] 寄件人 | 联系电话 | 地址 | ——

这个窗口让NLP模型能理解：“张三”出现在“收件人”标题下，且与“138****1234”在同一行，因此极大概率是收件人姓名而非公司名。

第二步：序列标注（Sequence Labeling）
我们用BiLSTM-CRF模型（微调自BERT-Base-Chinese）对上下文窗口做标注，标签体系为：

• B-RECEIVER_NAME,I-RECEIVER_NAME（收件人姓名）
• B-RECEIVER_PHONE,I-RECEIVER_PHONE（收件人电话）
• B-RECEIVER_ADDRESS,I-RECEIVER_ADDRESS（收件人地址）
• B-REMARK,I-REMARK（备注）

模型输出：

张三/ B-RECEIVER_NAME 138****1234/ B-RECEIVER_PHONE 深圳市/ B-RECEIVER_ADDRESS 南山区/ I-RECEIVER_ADDRESS 科技园/ I-RECEIVER_ADDRESS 科发路8号/ I-RECEIVER_ADDRESS 易碎请轻放/ B-REMARK

第三步：规则增强与冲突消解
纯模型会出错。比如“科发路8号”可能被标为B-RECEIVER_ADDRESS，但“8号”后面的“易碎请轻放”被标为B-REMARK，中间缺少衔接。这时规则引擎介入：

• 地址连续性规则：若I-RECEIVER_ADDRESS后紧跟B-REMARK，且B-REMARK文本含“请”“务必”“严禁”等指令词，则将B-REMARK降级为O（其他），确保地址完整性。
• 电话格式校验：B-RECEIVER_PHONE必须匹配^1[3-9]\d{9}$或^\d{3,4}-\d{7,8}$，否则触发人工复核队列。
• 跨行实体合并：当“收件人”标题在cell_2_1，“张三”在cell_2_2，但“先生”在cell_3_2（下一行同列），规则引擎会根据坐标距离（y差<20px）自动合并为“张三先生”。

注意：NLP的输入文本必须经过标准化清洗。我们发现，OCR输出的“138***1234”中星号是全角字符（＊），而正则校验用的是半角（），导致所有电话校验失败。解决方案是在NLP前加一步“全角转半角”和“空格压缩”，这是90%项目文档里不会提，但100%会踩的坑。

3.3 金融场景特例：银行回单的“抗干扰”设计

银行回单比快递面单复杂得多。以某国有银行对公回单为例，它有三大干扰源：

1. 密集表格线：30+行交易明细，每行有“交易时间”“摘要”“收入”“支出”“余额”五列，表格线极细，OCR易漏检；
2. 多级嵌套摘要：摘要栏写着“代发工资-XX公司-2024年3月”，需抽取出“XX公司”作为交易对手方；
3. 金额歧义：“余额”列有“¥1,234,567.89”，“收入”列有“¥50,000.00”，但OCR可能把“收入”列的“¥”识别成“Y”，导致NLP无法定位金额字段。

我们的应对方案是：

• OCR阶段：关闭PP-StructureV2的“表格线检测”，改用“文本行检测”模式，因为表格线干扰太大。先用DBNet检测所有文本行，再用规则（如y坐标差<25px视为同行）聚合成逻辑行。
• NLP阶段：构建“字段锚点”机制。不依赖OCR的“列”概念，而是用关键词定位：
  • 找到含“交易时间”的行 → 该行右侧第3个数字是“收入”，第4个是“支出”；
  • 找到含“摘要”的行 → 下一行的文本即为第一条交易摘要，用正则-([^-\n]+)-\d{4}年\d{1,2}月提取公司名；
  • 对所有数字字段，强制用re.findall(r'¥\d{1,3}(?:,\d{3})*\.\d{2}', text)提取，再按位置映射到对应字段。

这套方案在测试集上将“交易对手方”提取F1值从78.2%提升到94.6%，关键是放弃了对OCR“完美表格识别”的幻想，转而用NLP做业务逻辑兜底。

4. 实操全流程：从PDF上传到数据库写入的7个关键环节

4.1 环境准备与依赖安装（避坑版）

不要直接pip install paddlepaddle！某次在CentOS 7.6上，官方whl包因glibc版本不兼容直接报ImportError: GLIBC_2.18 not found。正确姿势是：

# 1. 先确认系统glibc版本 ldd --version # 需≥2.17 # 2. 安装适配的PaddlePaddle（以CUDA 11.2为例） pip install paddlepaddle-gpu==2.4.2.post112 -f https://www.paddlepaddle.org.cn/whl/linux/mkl/avx/stable.html # 3. 安装PaddleOCR（注意版本匹配） pip install "paddleocr>=2.7.0,<3.0.0" # 4. 安装NLP依赖（避免torch版本冲突） pip install torch==1.13.1+cu117 torchvision==0.14.1+cu117 -f https://download.pytorch.org/whl/torch_stable.html pip install transformers==4.26.1 seqeval==1.2.2

实操心得：在Docker中部署时，基础镜像必须用nvidia/cuda:11.2.2-cudnn8-runtime-ubuntu20.04，不能用ubuntu:20.04再装CUDA——后者会导致cuDNN路径错乱，OCR推理速度暴跌60%。

4.2 OCR模型配置与参数调优（非默认值清单）

PaddleOCR默认配置不适合金融/物流文档。关键参数调整如下：

配置文件config.yml核心段：

Global: use_gpu: True gpu_mem: 4000 enable_mkldnn: False # Intel CPU加速在GPU环境下反而拖慢 use_tensorrt: True # 开启TensorRT，T4卡提速1.8倍 Architecture: model_type: det algorithm: DB Transform: None Backbone: name: ResNet_vd layers: 18 Neck: name: DBFPN out_channels: 256 Head: name: DBHead k: 50 PostProcess: name: DBPostProcess box_thresh: 0.3 unclip_ratio: 1.6

4.3 NLP模型训练：从0到可用的3天速成法

别被“微调BERT”吓住。我们用3天时间，在1000张标注面单上训练出可用模型：

Day 1：数据准备与标注规范

• 工具：用Doccano搭建标注平台，但禁用其默认NER模板。自定义schema：
  RECEIVER_NAME,RECEIVER_PHONE,RECEIVER_ADDRESS,SENDER_NAME,ORDER_NO,AMOUNT,DATE
• 关键规范：
  • 地址必须标到“门牌号”级别（“科发路8号”不能只标“科发路”）；
  • 电话必须包含区号（“0755-12345678”不能标成“12345678”）；
  • 同一字段跨行时，用I-标签连续标注（如“深圳市/南山区/科技园”）。

Day 2：模型训练与验证

• 使用HuggingFacetransformers的TrainerAPI，关键超参：

  training_args = TrainingArguments( output_dir='./results', num_train_epochs=10, # 小数据集需更多轮次 per_device_train_batch_size=16, per_device_eval_batch_size=32, warmup_steps=500, # 防止初期梯度爆炸 weight_decay=0.01, logging_dir='./logs', evaluation_strategy="steps", eval_steps=200, # 每200步验证，快速发现问题 save_steps=500, load_best_model_at_end=True, # 自动加载最优checkpoint )

• 验证指标：不只看accuracy，重点监控seqeval的entity_f1，特别是RECEIVER_ADDRESS的召回率（常低于80%）。

Day 3：上线前压力测试

• 用locust模拟100并发请求，输入混合文档（PDF/ JPG/ PNG），监控：
  • 单请求平均耗时（目标≤800ms）；
  • GPU显存占用（T4卡≤3800MB）；
  • 错误率（目标≤0.5%，超限则触发降级：返回OCR原始文本+坐标）。

实操心得：第一次上线时，我们发现RECEIVER_ADDRESS召回率低是因为标注员把“XX大厦A座1201室”标成了“XX大厦A座”，漏了“1201室”。解决方案是：在训练数据生成脚本里加一道“地址完整性检查”——用高德API反查标准地址，若返回结果含“室”“号”“单元”等词，而标注未包含，则自动标记为“待复核”。

4.4 端到端流水线编排（Python实现）

核心代码框架，突出健壮性设计：

import cv2 import numpy as np from paddleocr import PaddleOCR from transformers import AutoTokenizer, AutoModelForTokenClassification import torch class OCRNLPProcessor: def __init__(self): # OCR初始化（启用GPU，禁用角度分类） self.ocr = PaddleOCR( use_gpu=True, lang='ch', det_model_dir='./models/det', rec_model_dir='./models/rec', cls_model_dir=None, # 关闭角度分类 use_angle_cls=False ) # NLP初始化 self.tokenizer = AutoTokenizer.from_pretrained('./nlp_model') self.model = AutoModelForTokenClassification.from_pretrained('./nlp_model') self.id2label = {i: label for i, label in enumerate(self.model.config.id2label.values())} def process_document(self, image_path: str) -> dict: """主处理函数，含完整错误处理""" try: # 1. OCR识别 ocr_result = self._run_ocr(image_path) if not ocr_result: return {"status": "OCR_FAILED", "error": "OCR no text detected"} # 2. 构建NLP上下文 context_text = self._build_context(ocr_result) # 3. NLP实体抽取 entities = self._extract_entities(context_text) # 4. 业务规则后处理 structured_data = self._apply_business_rules(entities, ocr_result) return { "status": "SUCCESS", "data": structured_data, "ocr_debug": {"text_count": len(ocr_result)} # 供调试 } except Exception as e: # 关键：捕获所有异常，绝不让上游崩溃 return {"status": "PROCESS_ERROR", "error": str(e)} def _run_ocr(self, image_path: str) -> list: """OCR执行，含图像预处理""" img = cv2.imread(image_path) # 针对扫描件的自适应二值化 if img.shape[0] * img.shape[1] > 2000000: # 大图降采样 scale = np.sqrt(2000000 / (img.shape[0] * img.shape[1])) img = cv2.resize(img, (0,0), fx=scale, fy=scale) result = self.ocr.ocr(img, cls=False) # 过滤低置信度结果 filtered = [line for line in result[0] if line[1][1] > 0.7] return filtered def _build_context(self, ocr_result: list) -> str: """按y坐标排序，构建逻辑行文本""" # 按y坐标分组（容忍10px误差） lines = {} for line in ocr_result: bbox = line[0] y_center = (bbox[0][1] + bbox[2][1]) / 2 line_key = round(y_center / 10) * 10 if line_key not in lines: lines[line_key] = [] lines[line_key].append((line[1][0], bbox[0][0])) # (text, x_start) # 每行按x坐标排序，拼接 context = "" for y_key in sorted(lines.keys()): line_texts = sorted(lines[y_key], key=lambda x: x[1]) context += " ".join([t for t, x in line_texts]) + "\n" return context.strip() def _extract_entities(self, text: str) -> list: """NLP实体抽取""" inputs = self.tokenizer(text, return_tensors="pt", truncation=True, max_length=512) with torch.no_grad(): outputs = self.model(**inputs) predictions = torch.argmax(outputs.logits, dim=-1)[0].cpu().numpy() tokens = self.tokenizer.convert_ids_to_tokens(inputs["input_ids"][0]) entities = [] for token, pred_id in zip(tokens, predictions): if pred_id != 0: # 0是O标签 label = self.id2label[pred_id] if label.startswith("B-"): entities.append({"word": token, "label": label[2:]}) elif label.startswith("I-") and entities: entities[-1]["word"] += token.replace("##", "") return entities def _apply_business_rules(self, entities: list, ocr_result: list) -> dict: """应用业务规则，生成结构化数据""" result = { "receiver_name": "", "receiver_phone": "", "receiver_address": "", "order_no": "", "amount": 0.0, "date": "" } # 规则1：电话必须是11位数字或带区号 phone_candidates = [e["word"] for e in entities if e["label"] == "RECEIVER_PHONE"] for cand in phone_candidates: if re.match(r'^1[3-9]\d{9}$', cand) or re.match(r'^\d{3,4}-\d{7,8}$', cand): result["receiver_phone"] = cand break # 规则2：地址需包含“市”“区”“路”“号” addr_candidates = [e["word"] for e in entities if e["label"] == "RECEIVER_ADDRESS"] for cand in addr_candidates: if "市" in cand and ("区" in cand or "县" in cand) and ("路" in cand or "街" in cand or "号" in cand): result["receiver_address"] = cand break return result # 使用示例 processor = OCRNLPProcessor() result = processor.process_document("./samples/shentong_waybill.jpg") print(result)

4.5 数据库写入与质量监控

提取结果不能直接入库，必须经质量网关：

def write_to_database(extracted_data: dict, doc_id: str): # 1. 字段完整性检查 required_fields = ["receiver_name", "receiver_phone", "receiver_address"] missing = [f for f in required_fields if not extracted_data.get(f)] if missing: # 写入“待人工复核”队列 redis.lpush("review_queue", json.dumps({ "doc_id": doc_id, "missing_fields": missing, "raw_data": extracted_data })) return {"status": "REVIEW_REQUIRED", "missing": missing} # 2. 电话格式二次校验（防OCR噪声） phone = extracted_data["receiver_phone"] if not re.match(r'^1[3-9]\d{9}$|^0\d{2,3}-\d{7,8}$', phone): # 触发短信通知负责人 send_alert(f"Doc {doc_id} phone format invalid: {phone}") return {"status": "FORMAT_ERROR", "phone": phone} # 3. 写入MySQL（使用INSERT ... ON DUPLICATE KEY UPDATE防重复） cursor.execute(""" INSERT INTO logistics_docs (doc_id, receiver_name, receiver_phone, receiver_address, created_at) VALUES (%s, %s, %s, %s, NOW()) ON DUPLICATE KEY UPDATE receiver_name=VALUES(receiver_name), receiver_phone=VALUES(receiver_phone), updated_at=NOW() """, (doc_id, extracted_data["receiver_name"], phone, extracted_data["receiver_address"])) return {"status": "SUCCESS", "doc_id": doc_id} # 质量监控仪表盘SQL（每日统计） """ SELECT DATE(created_at) as date, COUNT(*) as total_docs, AVG(CASE WHEN status='SUCCESS' THEN 1 ELSE 0 END) as success_rate, COUNT(CASE WHEN status='REVIEW_REQUIRED' THEN 1 END) as review_count, COUNT(CASE WHEN status='FORMAT_ERROR' THEN 1 END) as format_error_count FROM doc_processing_log GROUP BY DATE(created_at) ORDER BY date DESC LIMIT 7; """

5. 常见问题与独家排查技巧实录

5.1 OCR阶段高频问题速查表

5.2 NLP阶段典型故障与根因分析

故障1：地址字段总是截断（如“深圳市南山区”后无“科技园”）

• 根因：NLP模型最大长度设为128，而长地址+上下文超长，被截断。
• 排查：打印len(tokenizer.encode(context_text))，若>128则确认。
• 解法：不改模型长度（会大幅降速），改用滑动窗口：将长文本切成重叠片段（如128/64），分别预测，再用规则合并。我们用transformers的pipeline自动处理：

  nlp_pipeline = pipeline( "token-classification", model=model, tokenizer=tokenizer, aggregation_strategy="first", # 避免同一实体被多次标注 device=