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: 数字金额可包含小数点 } }正则约束的好处格式统一抽出来的数据格式一致方便后续处理过滤噪音过滤掉不符合格式的实体提高数据质量业务适配可以根据业务需求定制抽取规则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: 公司职位级别体系 } }枚举值约束的好处精准过滤只抽取我们关心的实体减少噪音数据标准化统一实体表述比如“北京”和“北京市”可以统一为“北京”业务聚焦聚焦在业务相关的实体上提高抽取的实用性3.3 组合使用正则枚举的双重约束更厉害的是我们可以把两种约束组合起来用。实际例子抽取特定格式的产品编号假设我们的产品编号规则是以“P”开头后面跟6位数字比如“P100001”、“P100002”等。而且我们只关心某几个特定的产品系列。{ 产品编号: { regex: ^P\\d{6}$, enum: [P100001, P100002, P100003, P200001, P200002], description: 特定系列的产品编号格式为P6位数字 } }这样既保证了格式正确又限制了取值范围双重保险。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 正则表达式写错了怎么办正则表达式是个双刃剑用好了很强大写错了就抽不到东西。常见错误转义问题在JSON里反斜杠要双写\d要写成\\d锚定问题^表示开头$表示结尾用错了可能匹配不上贪婪匹配.*可能会匹配太多内容调试建议先用在线正则测试工具如regex101.com测试你的正则在Schema里先不用正则看能抽到什么再针对性写正则正则尽量宽松一些比如用.*而不是精确匹配5.2 枚举值太多怎么办如果枚举值有几百上千个全写在Schema里不太现实。解决方案分类枚举把实体分成几个大类每个类用不同的Schema动态加载通过程序动态生成Schema从数据库或文件读取枚举值混合使用先用正则过滤格式再用程序过滤内容5.3 抽取结果不准确怎么办有时候模型会抽错或者抽不到。可能原因实体表述多样同一个实体可能有多种说法上下文依赖有些实体需要上下文才能识别模型限制毕竟是个通用模型不是专门为你业务训练的改进方法丰富枚举值把常见的表述都加进去调整正则让正则更宽松一些后处理过滤抽取后再用规则过滤一遍多模型组合用多个Schema多次抽取取并集或交集5.4 性能问题怎么处理复杂的Schema可能会影响抽取速度。优化建议简化正则避免复杂的正则表达式减少枚举枚举值不要太多必要时分组处理批量处理积累一定量的文本后批量抽取而不是单条处理缓存结果相同的文本和Schema可以缓存抽取结果6. 最佳实践我的经验总结用了这么久SiameseUIE我总结了一些最佳实践分享给你。6.1 Schema设计原则从简到繁先用简单Schema测试再逐步增加约束先格式后内容先用正则约束格式再用枚举约束内容保留原始文本在结果里同时保留原始文本和标准化后的值文档化给每个Schema写清楚描述和示例6.2 正则表达式技巧多用.*在实体前后加上.*提高匹配成功率避免绝对锚定除非确定格式否则少用^和$分组提取用()分组可以只提取需要的部分测试充分用各种边缘case测试你的正则6.3 枚举值管理分类管理按业务域分类管理枚举值版本控制枚举值变化时要有版本记录动态更新支持热更新枚举值不用重启服务统计分析定期分析哪些枚举值常用哪些从来没用过6.4 错误处理策略降级策略当约束太严格抽不到时尝试放宽约束多轮抽取第一轮用严格Schema第二轮用宽松Schema人工复核关键数据还是要人工复核一下反馈学习把错误案例收集起来优化Schema7. 总结自定义Schema的正则约束和枚举值约束让SiameseUIE从一个“通用抽取工具”变成了“精准业务助手”。通过这两种约束我们可以控制格式确保抽出来的数据格式符合要求过滤噪音只抽取我们关心的实体适配业务根据具体业务需求定制抽取规则提高准确率减少误抽和漏抽不过也要注意约束不是越严格越好。太严格的约束可能会导致抽不到东西太宽松的约束又会有太多噪音。关键是要在“准确率”和“召回率”之间找到平衡。我的建议是先用宽松的Schema测试了解数据情况再逐步增加约束。同时要建立完善的测试集用各种case测试你的Schema确保它既不会漏掉该抽的也不会抽到不该抽的。最后记住一点Schema只是工具真正的关键是理解你的业务需求。只有深入理解你要抽什么、为什么抽、怎么用才能设计出好的Schema。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
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: 数字金额可包含小数点 } }正则约束的好处格式统一抽出来的数据格式一致方便后续处理过滤噪音过滤掉不符合格式的实体提高数据质量业务适配可以根据业务需求定制抽取规则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: 公司职位级别体系 } }枚举值约束的好处精准过滤只抽取我们关心的实体减少噪音数据标准化统一实体表述比如“北京”和“北京市”可以统一为“北京”业务聚焦聚焦在业务相关的实体上提高抽取的实用性3.3 组合使用正则枚举的双重约束更厉害的是我们可以把两种约束组合起来用。实际例子抽取特定格式的产品编号假设我们的产品编号规则是以“P”开头后面跟6位数字比如“P100001”、“P100002”等。而且我们只关心某几个特定的产品系列。{ 产品编号: { regex: ^P\\d{6}$, enum: [P100001, P100002, P100003, P200001, P200002], description: 特定系列的产品编号格式为P6位数字 } }这样既保证了格式正确又限制了取值范围双重保险。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 正则表达式写错了怎么办正则表达式是个双刃剑用好了很强大写错了就抽不到东西。常见错误转义问题在JSON里反斜杠要双写\d要写成\\d锚定问题^表示开头$表示结尾用错了可能匹配不上贪婪匹配.*可能会匹配太多内容调试建议先用在线正则测试工具如regex101.com测试你的正则在Schema里先不用正则看能抽到什么再针对性写正则正则尽量宽松一些比如用.*而不是精确匹配5.2 枚举值太多怎么办如果枚举值有几百上千个全写在Schema里不太现实。解决方案分类枚举把实体分成几个大类每个类用不同的Schema动态加载通过程序动态生成Schema从数据库或文件读取枚举值混合使用先用正则过滤格式再用程序过滤内容5.3 抽取结果不准确怎么办有时候模型会抽错或者抽不到。可能原因实体表述多样同一个实体可能有多种说法上下文依赖有些实体需要上下文才能识别模型限制毕竟是个通用模型不是专门为你业务训练的改进方法丰富枚举值把常见的表述都加进去调整正则让正则更宽松一些后处理过滤抽取后再用规则过滤一遍多模型组合用多个Schema多次抽取取并集或交集5.4 性能问题怎么处理复杂的Schema可能会影响抽取速度。优化建议简化正则避免复杂的正则表达式减少枚举枚举值不要太多必要时分组处理批量处理积累一定量的文本后批量抽取而不是单条处理缓存结果相同的文本和Schema可以缓存抽取结果6. 最佳实践我的经验总结用了这么久SiameseUIE我总结了一些最佳实践分享给你。6.1 Schema设计原则从简到繁先用简单Schema测试再逐步增加约束先格式后内容先用正则约束格式再用枚举约束内容保留原始文本在结果里同时保留原始文本和标准化后的值文档化给每个Schema写清楚描述和示例6.2 正则表达式技巧多用.*在实体前后加上.*提高匹配成功率避免绝对锚定除非确定格式否则少用^和$分组提取用()分组可以只提取需要的部分测试充分用各种边缘case测试你的正则6.3 枚举值管理分类管理按业务域分类管理枚举值版本控制枚举值变化时要有版本记录动态更新支持热更新枚举值不用重启服务统计分析定期分析哪些枚举值常用哪些从来没用过6.4 错误处理策略降级策略当约束太严格抽不到时尝试放宽约束多轮抽取第一轮用严格Schema第二轮用宽松Schema人工复核关键数据还是要人工复核一下反馈学习把错误案例收集起来优化Schema7. 总结自定义Schema的正则约束和枚举值约束让SiameseUIE从一个“通用抽取工具”变成了“精准业务助手”。通过这两种约束我们可以控制格式确保抽出来的数据格式符合要求过滤噪音只抽取我们关心的实体适配业务根据具体业务需求定制抽取规则提高准确率减少误抽和漏抽不过也要注意约束不是越严格越好。太严格的约束可能会导致抽不到东西太宽松的约束又会有太多噪音。关键是要在“准确率”和“召回率”之间找到平衡。我的建议是先用宽松的Schema测试了解数据情况再逐步增加约束。同时要建立完善的测试集用各种case测试你的Schema确保它既不会漏掉该抽的也不会抽到不该抽的。最后记住一点Schema只是工具真正的关键是理解你的业务需求。只有深入理解你要抽什么、为什么抽、怎么用才能设计出好的Schema。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
