SiameseUIE效果对比：custom_entities模式 vs 通用规则模式差异
1. 为什么这次对比值得你花5分钟看完
你有没有遇到过这样的情况：模型跑通了，结果却“不太对劲”？
比如，输入“李白出生在碎叶城”，它抽出了“李白”“碎叶城”——很好；
但再试一句“杜甫在成都草堂写诗”，它却返回“杜甫在成”“都草堂”……这显然不是你想要的“实体”。
这不是模型坏了，而是抽取逻辑没选对。
SiameseUIE 镜像默认启用的是custom_entities模式——它不靠猜，只认你明确告诉它的名字和地点；而另一条路是“通用规则模式”，用正则+词长硬匹配，省事但容易出错。
两者不是“谁更好”，而是“谁更适合你的场景”。
本文不讲论文、不贴公式，就用镜像里自带的5个真实测试例子，带你亲眼看到两种模式在人物/地点抽取上的表现差异：哪里稳如磐石，哪里容易翻车，什么情况下该切换、怎么切、切完怎么验证。所有操作都在已部署好的镜像里一键可试，不需要重装、不改环境、不碰GPU配置。
如果你正在做历史文献处理、政务文本分析、或任何需要“精准识别固定对象”的任务，这篇实测就是为你写的。
2. 先搞清楚：两种模式到底在做什么
2.1 custom_entities 模式 —— “指名道姓”式抽取
这个模式就像你给模型发了一份“点名册”：
“请在这段文字里，只找我列出来的这些人和地方，一个都不能多，一个都不能少。”
它完全不依赖字符规律，而是通过语义对齐（Siamese 结构）判断文本片段是否与你提供的候选实体语义一致。
优势：结果干净、无碎片、抗干扰强（比如“杜甫在成都草堂”不会拆成“杜甫在成”）
❌ 局限：必须提前知道要找哪些实体——适合有明确目标清单的场景（如：某部史书里涉及的37位人物+22个地名）
2.2 通用规则模式 —— “按字数+关键词”硬匹配
这个模式不看语义，只看表面特征：
- 人名：连续2个汉字（如“李白”“张三”），且不在停用词表中；
- 地点：含“市/省/县/城/州/山/江/河”等后缀的2–4字词（如“成都市”“终南山”“黄州”）。
优势：零配置、开箱即用，适合探索性分析或实体未知的初期阶段
❌ 局限：极易误召（如“草堂”被当“堂”→误判为地名）、漏召（如单字名“禹”、古地名“琅琊”不含后缀）、碎片化（“成都草堂”→抽出“成都”“草堂”两个地点）
注意：这两种模式不是模型结构不同，而是后处理逻辑不同。同一个 SiameseUIE 模型，加载一次，仅靠传入
custom_entities参数的有无，就能切换行为。
3. 实测对比：5个典型例子逐条拆解
我们直接运行镜像内置的test.py，分别在两种模式下执行全部5个测试例，并人工核对每一条抽取结果。所有测试均在未修改任何代码、未新增依赖的原始镜像环境中完成。
3.1 例子1：历史人物+多地点
原文：李白出生在碎叶城，杜甫在成都修建了杜甫草堂，王维隐居在终南山。
| 模式 | 抽取结果 | 评价 |
|---|---|---|
custom_entities（默认） | - 人物：李白，杜甫，王维<br>- 地点：碎叶城，成都，终南山 | 完整、准确、无冗余。“杜甫草堂”未被误拆，“终南山”完整保留 |
| 通用规则 | - 人物：李白，杜甫，王维<br>- 地点：碎叶城，成都，杜甫草堂，终南山 | ❌ “杜甫草堂”被当作地点误召（含“堂”字），且“草堂”本身不是地理实体 |
3.2 例子2：现代人物+城市
原文：张三就职于北京市朝阳区，李四常驻上海市浦东新区，王五在深圳市南山区创业。
| 模式 | 抽取结果 | 评价 |
|---|---|---|
custom_entities | - 人物：张三，李四，王五<br>- 地点：北京市，上海市，深圳市 | 精准命中“市”级单位，忽略“朝阳区”“浦东新区”等下级行政单位（符合多数业务需求） |
| 通用规则 | - 人物：张三，李四，王五<br>- 地点：北京市，朝阳区，上海市，浦东新区，深圳市，南山区 | ❌ 过度泛化，把所有带“区”“市”“新区”的词全抓出来，结果膨胀3倍，实用性骤降 |
3.3 例子3：单人物+单地点
原文：苏轼被贬黄州，在东坡开荒种地，写下《赤壁赋》。
| 模式 | 抽取结果 | 评价 |
|---|---|---|
custom_entities | - 人物：苏轼<br>- 地点：黄州 | 干净利落。“东坡”“赤壁”未被误召（非预设地点） |
| 通用规则 | - 人物：苏轼，东坡，赤壁<br>- 地点：黄州，东坡，赤壁 | ❌ “东坡”“赤壁”既是文学意象又是地名，通用规则无法区分语境，导致严重误召 |
3.4 例子4：无匹配实体
原文：今天天气晴朗，适合出门散步，记得带伞以防午后雷阵雨。
| 模式 | 抽取结果 | 评价 |
|---|---|---|
custom_entities | - 人物：无<br>- 地点：无 | 明确返回“无”，便于程序判断空结果 |
| 通用规则 | - 人物：无<br>- 地点：无 | 两者在此例表现一致，均未强行匹配 |
3.5 例子5：混合场景（含冗余文本）
原文：周杰伦在台北市开演唱会，林俊杰在杭州市西湖边录制新歌，后台工作人员说“快把设备搬到B3层”。
| 模式 | 抽取结果 | 评价 |
|---|---|---|
custom_entities | - 人物：周杰伦，林俊杰<br>- 地点：台北市，杭州市 | “西湖”未被抽出（未在预设地点列表中），“B3层”完全忽略 |
| 通用规则 | - 人物：周杰伦，林俊杰<br>- 地点：台北市，杭州市，西湖，B3层 | ❌ “西湖”作为文化符号被误召；“B3层”含“层”字也被捕获，纯属噪音 |
3.6 对比小结：一张表看清核心差异
| 维度 | custom_entities模式 | 通用规则模式 |
|---|---|---|
| 结果纯净度 | 极高（只返回预设项） | 低（易混入语义无关词） |
| 抗干扰能力 | 强（“杜甫草堂”不拆，“东坡”不召） | 弱（依赖字面特征，无语义理解） |
| 适用前提 | 需提前整理实体清单（适合闭环场景） | 无需先验知识（适合开放探索） |
| 开发成本 | 初期需维护实体列表，但后期零调试 | 启动快，但后期需大量规则调优 |
| 典型适用场景 | 古籍专有名词提取、企业客户名单识别、政策文件中固定机构抽取 | 新闻热点初筛、社交媒体话题发现、数据探查阶段 |
4. 怎么切换？三步搞定，不改一行模型代码
切换模式不需要重装模型、不改配置文件、不碰权重，只需修改test.py中的一处参数调用。以下是具体操作：
4.1 查看当前模式（确认默认状态）
打开test.py，找到类似以下的调用行（通常在for example in test_examples:循环内）：
extract_results = extract_pure_entities( text=example["text"], schema=example["schema"], custom_entities=example.get("custom_entities", None) )注意：example.get("custom_entities", None)表示——如果测试例里定义了custom_entities字段，就用它；否则传None，即启用通用规则。
而镜像内置的5个测试例，全部显式声明了custom_entities字段，因此默认走的是自定义模式。
4.2 切换到通用规则模式（临时验证）
最简单的方法：注释掉custom_entities的传参，强制传None
修改为：
extract_results = extract_pure_entities( text=example["text"], schema=example["schema"], custom_entities=None # ← 关键改动：显式传 None )保存后，重新运行：
cd nlp_structbert_siamese-uie_chinese-base python test.py你会立刻看到输出变成通用规则的结果（如例子1中出现“杜甫草堂”）。
4.3 混合使用：同一脚本，按需切换
你甚至可以让不同测试例用不同模式。例如，让例子1–3用custom_entities（精准），例子4–5用通用规则（探索）：
# 在 test_examples 列表中，为例子4和5显式设为 None { "name": "例子4：无匹配实体", "text": "今天天气晴朗...", "schema": {"人物": None, "地点": None}, "custom_entities": None # ← 此处设为 None，覆盖默认行为 }, { "name": "例子5：混合场景", "text": "周杰伦在台北市开演唱会...", "schema": {"人物": None, "地点": None}, "custom_entities": None }这样，一个脚本就能同时服务“精准交付”和“开放探索”两类需求。
5. 什么情况下该坚持用 custom_entities 模式？
别被“通用”二字迷惑——在真实工程中，绝大多数需要交付结果的场景，都应该锁定custom_entities模式。我们总结了3个不可妥协的信号：
5.1 你的实体有明确边界，且不能容忍错误
比如处理《清史稿》人物传：
- 要抽“曾国藩”“左宗棠”“李鸿章”，但绝不能把“国藩”“宗棠”“鸿章”单独抽出来；
- 要抽“安庆府”“武昌府”，但不能把“安庆”“武昌”“府”拆开或重复。
通用规则在这里会全面失守，而custom_entities模式能稳定守住底线。
5.2 文本含大量同形异义词，语义决定一切
例如：“长安”可以是地名（西安古称）、人名（汉宣帝年号）、品牌名（长安汽车）、诗句意象（“长安一片月”）。
只有custom_entities模式能结合上下文判断——当你只把“长安”加入地点列表时，它就不会在“长安汽车”中误召。
5.3 你需要结果可解释、可审计、可回溯
custom_entities模式的每一次抽取，背后都有明确的候选集支撑。
- 出错了？检查候选集是否漏了“琅琊王氏”；
- 多抽了？确认“草堂”没误加进地点列表；
- 客户质疑？直接出示你提供的实体清单即可。
而通用规则的逻辑藏在正则里，一旦出错，排查成本远高于维护一份Excel清单。
6. 总结：选模式，本质是选工作方式
custom_entities模式不是“更高级”，而是“更诚实”——它坦白告诉你：我能做的，仅限于你授权的范围。它把“识别能力”的主动权交还给你，用结构化清单替代模糊规则，换来的是结果的确定性、可维护性和业务可信度。
通用规则模式也不是“更差”，而是“更试探”——它在信息未知时帮你快速探底，但一旦进入交付阶段，就必须收束到可控范围内。
所以，别问“哪个模式更好”，而要问：
你现在是在画地图，还是在导航？
你手上有名单，还是在大海捞针？
你要交报告，还是在找线索？
答案清晰了，模式自然就定了。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
