SiameseUIE中文-base实操进阶：自定义Schema支持正则约束与枚举值

SiameseUIE中文-base实操进阶：自定义Schema支持正则约束与枚举值

1. 从零开始：为什么需要自定义Schema？

如果你用过SiameseUIE，肯定体验过它的神奇之处——不用训练，只要告诉它你想抽什么，它就能从文本里给你找出来。比如你想从新闻里抽人名、地名，写个{"人物": null, "地点": null}，它就能给你准确的结果。

但用久了你会发现一个问题：有时候它抽出来的东西，不是你想要的“那种”。

举个例子，你想从一堆商品评论里抽“手机型号”。你写个{"手机型号": null}，结果它可能把“苹果手机”、“华为手机”都抽出来了。这没错，但如果你只想抽具体的型号，比如“iPhone 15 Pro”、“华为Mate 60”，怎么办？

再比如，你想从合同里抽“金额”，但合同里的金额写法五花八门：“100万”、“100万元”、“100,000元”、“壹佰万元”。你只想抽数字格式的金额，不要中文大写的，怎么办？

这就是我们今天要解决的问题：如何让SiameseUIE更懂你的“具体要求”。

传统的Schema只能定义“抽什么类型”，但没法定义“抽什么格式”、“抽哪些具体值”。今天我要分享的，就是如何通过自定义Schema，加上正则约束和枚举值，让信息抽取更精准、更符合你的业务需求。

2. 基础回顾：SiameseUIE的Schema到底怎么用？

在讲高级用法之前，我们先快速回顾一下基础。如果你已经熟悉了，可以跳过这一节。

2.1 最简单的Schema格式

SiameseUIE的Schema其实就是一个JSON对象，格式特别简单：

{ "实体类型1": null, "实体类型2": null, "关系类型": {"关联实体": null} }

• 命名实体识别（NER）：{"实体类型": null}
• 关系抽取：{"关系类型": {"关联实体": null}}
• 情感抽取：{"属性词": {"情感词": null}}

2.2 实际例子看看

假设我们有这样一段文本：

张三在2023年入职阿里巴巴，担任高级工程师，月薪30000元。

基础抽取：

{ "人物": null, "时间": null, "公司": null, "职位": null, "金额": null }

结果可能是：

{ "人物": ["张三"], "时间": ["2023年"], "公司": ["阿里巴巴"], "职位": ["高级工程师"], "金额": ["30000元"] }

看起来不错，对吧？但问题来了：如果我只想要“入职时间”，不要“2023年”这种格式，只要“2023”这种纯数字年份呢？或者我只想要“月薪”的数值，不要带“元”字呢？

这就是基础Schema的局限性——它只能告诉模型“抽什么类型”，不能告诉它“抽什么格式”。

3. 进阶玩法：自定义Schema的两种高级约束

好了，重头戏来了。怎么让Schema更智能？有两种方法：正则约束和枚举值约束。

3.1 方法一：正则约束——控制抽取格式

正则表达式大家应该不陌生，就是用来匹配特定格式的文本模式。我们可以把正则表达式嵌入到Schema里，告诉模型：“我只想要匹配这个格式的实体”。

语法格式：

{ "实体类型": { "regex": "你的正则表达式", "description": "实体描述（可选）" } }

实际例子1：只抽取纯数字年份

假设我们有一堆文本，里面年份的写法有：“2023年”、“2023”、“二零二三年”、“2023-01-01”。我们只想抽“2023”这种纯数字格式。

{ "入职年份": { "regex": "^\\d{4}$", "description": "4位数字的年份，如2023、2024" } }

测试文本：

李四于2022年加入腾讯，王五在2023入职百度，赵六二零二四年去了字节跳动。

抽取结果：

{ "入职年份": ["2022", "2023"] }

看到了吗？“二零二四年”没有被抽出来，因为不符合^\d{4}$这个正则（要求是4位纯数字）。

实际例子2：只抽取标准手机号

手机号的写法也很多：“13800138000”、“138-0013-8000”、“138 0013 8000”、“+86-13800138000”。如果我们只想要11位纯数字的手机号：

{ "手机号": { "regex": "^1[3-9]\\d{9}$", "description": "11位数字的中国大陆手机号" } }

实际例子3：只抽取金额数值

金额的写法更是五花八门：“100元”、“100.00元”、“¥100”、“100块钱”、“一百元”。如果我们只想要带小数点的数字金额：

{ "金额": { "regex": "\\d+(\\.\\d+)?", "description": "数字金额，可包含小数点" } }

正则约束的好处：

1. 格式统一：抽出来的数据格式一致，方便后续处理
2. 过滤噪音：过滤掉不符合格式的实体，提高数据质量
3. 业务适配：可以根据业务需求定制抽取规则

3.2 方法二：枚举值约束——控制抽取范围

有时候，我们不是要控制格式，而是要控制内容。比如，我们只想抽特定的几个产品型号、特定的几个城市名、特定的几个职位名称。

这时候可以用枚举值约束。

语法格式：

{ "实体类型": { "enum": ["值1", "值2", "值3", ...], "description": "实体描述（可选）" } }

实际例子1：只抽取特定手机型号

假设我们是一个手机评测网站，只关心几款主流旗舰机：

{ "手机型号": { "enum": ["iPhone 15 Pro", "iPhone 15 Pro Max", "华为Mate 60", "华为Mate 60 Pro", "小米14", "小米14 Pro"], "description": "主流旗舰手机型号" } }

测试文本：

用户A买了iPhone 15 Pro，用户B买了三星S23，用户C买了华为Mate 60 Pro，用户D买了OPPO Find X7。

抽取结果：

{ "手机型号": ["iPhone 15 Pro", "华为Mate 60 Pro"] }

“三星S23”和“OPPO Find X7”没有被抽出来，因为它们不在枚举列表里。

实际例子2：只抽取一线城市

如果我们只关心北京、上海、广州、深圳这几个城市：

{ "工作城市": { "enum": ["北京", "上海", "广州", "深圳"], "description": "一线工作城市" } }

实际例子3：只抽取特定职位级别

公司职位体系里，我们只关心几个关键级别：

{ "职位级别": { "enum": ["实习生", "初级工程师", "中级工程师", "高级工程师", "专家", "总监", "副总裁", "总裁"], "description": "公司职位级别体系" } }

枚举值约束的好处：

1. 精准过滤：只抽取我们关心的实体，减少噪音
2. 数据标准化：统一实体表述，比如“北京”和“北京市”可以统一为“北京”
3. 业务聚焦：聚焦在业务相关的实体上，提高抽取的实用性

3.3 组合使用：正则+枚举的双重约束

更厉害的是，我们可以把两种约束组合起来用。

实际例子：抽取特定格式的产品编号

假设我们的产品编号规则是：以“P”开头，后面跟6位数字，比如“P100001”、“P100002”等。而且我们只关心某几个特定的产品系列。

{ "产品编号": { "regex": "^P\\d{6}$", "enum": ["P100001", "P100002", "P100003", "P200001", "P200002"], "description": "特定系列的产品编号，格式为P+6位数字" } }

这样既保证了格式正确，又限制了取值范围，双重保险。

4. 实战演练：从需求到实现的完整案例

光说不练假把式，我们来看几个完整的实战案例。

4.1 案例一：电商评论情感属性抽取

业务需求： 我们要从电商评论里抽取用户对手机的评价，但只关心几个关键属性：屏幕、电池、拍照、性能。而且对于电池，我们只关心“续航”相关的表述。

Schema设计：

{ "屏幕评价": { "enum": ["屏幕", "显示屏", "显示效果", "屏幕显示"], "description": "用户对屏幕的评价" }, "电池评价": { "regex": ".*(续航|电池|电量|待机).*", "description": "用户对电池续航的评价" }, "拍照评价": { "enum": ["拍照", "摄像头", "相机", "摄影"], "description": "用户对拍照功能的评价" }, "性能评价": { "enum": ["性能", "流畅度", "速度", "运行"], "description": "用户对性能的评价" } }

测试评论：

这款手机屏幕真的很清晰，色彩鲜艳。电池续航一般，一天要充两次电。拍照效果很棒，夜景也很清晰。玩游戏很流畅，不卡顿。就是价格有点贵。

抽取结果：

{ "屏幕评价": ["屏幕"], "电池评价": ["电池续航"], "拍照评价": ["拍照"], "性能评价": ["性能", "流畅"] }

4.2 案例二：简历信息标准化抽取

业务需求： HR要处理大量简历，需要自动抽取：毕业院校（只关心985高校）、工作年限（只关心数字）、期望薪资（只关心数字范围）。

Schema设计：

{ "毕业院校": { "enum": ["清华大学", "北京大学", "复旦大学", "上海交通大学", "浙江大学", "南京大学", "中国科学技术大学", "哈尔滨工业大学", "西安交通大学"], "description": "985高校名称" }, "工作年限": { "regex": "\\d+", "description": "数字形式的工作年限" }, "期望薪资": { "regex": "\\d+[kK]?\\s*-\\s*\\d+[kK]?", "description": "薪资范围，如20k-30k" } }

测试简历片段：

张三，毕业于北京大学，有5年工作经验，期望薪资25k-35k。李四，毕业于南京大学，工作经验3年，期望薪资20k-30k。王五，毕业于某普通高校，工作经验8年，期望面议。

抽取结果：

{ "毕业院校": ["北京大学", "南京大学"], "工作年限": ["5", "3", "8"], "期望薪资": ["25k-35k", "20k-30k"] }

4.3 案例三：合同关键信息抽取

业务需求： 从合同中抽取：合同编号（特定格式）、金额（数字格式）、签约日期（YYYY-MM-DD格式）、甲方公司（只关心合作方列表里的公司）。

Schema设计：

{ "合同编号": { "regex": "^CONTRACT-\\d{8}-\\d{3}$", "description": "合同编号格式：CONTRACT-日期-序号" }, "合同金额": { "regex": "\\d+(\\.\\d+)?\\s*[万万元元]?", "description": "合同金额，数字格式" }, "签约日期": { "regex": "\\d{4}-\\d{2}-\\d{2}", "description": "日期格式：YYYY-MM-DD" }, "甲方公司": { "enum": ["阿里巴巴", "腾讯", "百度", "华为", "字节跳动", "美团", "京东"], "description": "合作甲方公司名称" } }

测试合同文本：

合同编号：CONTRACT-20240115-001 甲方：阿里巴巴集团 乙方：某科技公司 合同金额：100万元 签约日期：2024-01-15 有效期至：2025-01-14

抽取结果：

{ "合同编号": ["CONTRACT-20240115-001"], "合同金额": ["100万元"], "签约日期": ["2024-01-15"], "甲方公司": ["阿里巴巴"] }

5. 避坑指南：常见问题与解决方案

在实际使用中，你可能会遇到一些问题。这里我总结了一些常见坑和解决方法。

5.1 正则表达式写错了怎么办？

正则表达式是个双刃剑，用好了很强大，写错了就抽不到东西。

常见错误：

1. 转义问题：在JSON里，反斜杠要双写，\d要写成\\d
2. 锚定问题：^表示开头，$表示结尾，用错了可能匹配不上
3. 贪婪匹配：.*可能会匹配太多内容

调试建议：

1. 先用在线正则测试工具（如regex101.com）测试你的正则
2. 在Schema里先不用正则，看能抽到什么，再针对性写正则
3. 正则尽量宽松一些，比如用.*而不是精确匹配

5.2 枚举值太多怎么办？

如果枚举值有几百上千个，全写在Schema里不太现实。

解决方案：

1. 分类枚举：把实体分成几个大类，每个类用不同的Schema
2. 动态加载：通过程序动态生成Schema，从数据库或文件读取枚举值
3. 混合使用：先用正则过滤格式，再用程序过滤内容

5.3 抽取结果不准确怎么办？

有时候模型会抽错，或者抽不到。

可能原因：

1. 实体表述多样：同一个实体可能有多种说法
2. 上下文依赖：有些实体需要上下文才能识别
3. 模型限制：毕竟是个通用模型，不是专门为你业务训练的

改进方法：

1. 丰富枚举值：把常见的表述都加进去
2. 调整正则：让正则更宽松一些
3. 后处理过滤：抽取后再用规则过滤一遍
4. 多模型组合：用多个Schema多次抽取，取并集或交集

5.4 性能问题怎么处理？

复杂的Schema可能会影响抽取速度。

优化建议：

1. 简化正则：避免复杂的正则表达式
2. 减少枚举：枚举值不要太多，必要时分组处理
3. 批量处理：积累一定量的文本后批量抽取，而不是单条处理
4. 缓存结果：相同的文本和Schema可以缓存抽取结果

6. 最佳实践：我的经验总结

用了这么久SiameseUIE，我总结了一些最佳实践，分享给你。

6.1 Schema设计原则

1. 从简到繁：先用简单Schema测试，再逐步增加约束
2. 先格式后内容：先用正则约束格式，再用枚举约束内容
3. 保留原始文本：在结果里同时保留原始文本和标准化后的值
4. 文档化：给每个Schema写清楚描述和示例

6.2 正则表达式技巧

1. 多用.*：在实体前后加上.*，提高匹配成功率
2. 避免绝对锚定：除非确定格式，否则少用^和$
3. 分组提取：用()分组，可以只提取需要的部分
4. 测试充分：用各种边缘case测试你的正则

6.3 枚举值管理

1. 分类管理：按业务域分类管理枚举值
2. 版本控制：枚举值变化时，要有版本记录
3. 动态更新：支持热更新枚举值，不用重启服务
4. 统计分析：定期分析哪些枚举值常用，哪些从来没用过

6.4 错误处理策略

1. 降级策略：当约束太严格抽不到时，尝试放宽约束
2. 多轮抽取：第一轮用严格Schema，第二轮用宽松Schema
3. 人工复核：关键数据还是要人工复核一下
4. 反馈学习：把错误案例收集起来，优化Schema

7. 总结

自定义Schema的正则约束和枚举值约束，让SiameseUIE从一个“通用抽取工具”变成了“精准业务助手”。通过这两种约束，我们可以：

1. 控制格式：确保抽出来的数据格式符合要求
2. 过滤噪音：只抽取我们关心的实体
3. 适配业务：根据具体业务需求定制抽取规则
4. 提高准确率：减少误抽和漏抽

不过也要注意，约束不是越严格越好。太严格的约束可能会导致抽不到东西，太宽松的约束又会有太多噪音。关键是要在“准确率”和“召回率”之间找到平衡。

我的建议是：先用宽松的Schema测试，了解数据情况，再逐步增加约束。同时，要建立完善的测试集，用各种case测试你的Schema，确保它既不会漏掉该抽的，也不会抽到不该抽的。

最后，记住一点：Schema只是工具，真正的关键是理解你的业务需求。只有深入理解你要抽什么、为什么抽、怎么用，才能设计出好的Schema。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。