이미지: METAL LAB 생성
摘要
- Fastino发布了信息提取模型GLiNER2.5,不再采用逐一比对所有候选区间的旧方式,而是改为只预测实体起止位置的结构
- 74M、194M、287M三种参数规模的检查点以Apache 2.0协议上传至Hugging Face,仅靠CPU也能实现本地运行
- 在16项零样本基准测试中,多语言版整体macro F1达到56.17,较上一版小幅提升,XNLI指标更是跃升了24.75个百分点
- 공개
- MarkTechPost, 2026-08-24 보도
- 개발
- Fastino
- 체크포인트
- 74M·194M·287M 파라미터 3종
- 라이선스
- Apache 2.0
- 실행 환경
- CPU·CUDA·MPS 로컬 추론 (pip install "gliner2[local]", Python 3.10+)
- 컨텍스트 길이
- 최대 4,096단어 (max_len=4096)
- 벤치마크
- 16개 제로샷 데이터셋 전체 macro F1 56.17(다국어)·54.87(베이스)
- 배포
- 현재 별도 추론 호스팅 제공자 없음, 자체 호스팅만 가능
找一个实体为何会让计算量爆炸
从文档中提取姓名、日期、条款之类的信息,这项工作叫做信息提取。负责挑选执行这项任务的模型的团队,常常会陷入同一个两难境地:小型编码器模型便宜,但灵活性不足;大型语言模型什么都能提取,但每处理一份文档成本就会不断累积。Fastino这次发布的GLiNER2.5,正是试图缩小这道鸿沟的尝试。
上一版GLiNER2在寻找实体时,采用的是逐一列举候选区间的方式。它会把所有起始位置和允许的长度一一配对,再与预设的模式(schema)进行比对,这就导致计算量被"长度"这个变量死死绑住。如果不给长度设上限,计算量就会失控,所以通常只能把区间截断在十二个词左右。这意味着像四十个词长的免责条款这种较长的实体,从一开始就被排除在评分范围之外。
只预测边界,长度限制就此消失
GLiNER2.5不再列举区间,而是在词元(token)边界处预测起点和终点分数,在词元内部预测内部分数。共享编码器同时处理文本和模式查询的做法没有变,但后续步骤变了。稀疏提议阶段会为每个查询挑出最有可能的起点和终点,不受距离限制地进行配对;重排序阶段则综合边界证据和区间内容,给出最终分数。关系抽取的候选也是从同一个池子里选取,不再走单独的处理路径。
正是这一个变化,让实体长度的上限彻底消失了。Fastino团队解释说,在固定的模式和候选预算范围内,计算量会随句子长度呈线性增长。
新增的五项功能
由于不再显式列举区间,内存腾出了空间,这使得训练和推理时能处理最长4,096个词的文本。团队还配套推出了处理长文档的分块工具(如extract_entities_long、extract_long),它能把从截断片段中找到的区间,重新映射回原始文档中的字符位置。
实体长度限制也消失了。以前上限大约是十二个词,而现在从第一个词元开始、到最后一个词元结束的区间,也能以和两个词的姓名相同的成本被找出来。此外,只要声明实体类型、关系以及unique_head=True这类结构规则,束搜索(beam search)就会自动拼装出符合模式规则的图谱,这项联合抽取功能也是新增内容。
新版本还加入了约束分类功能,可以用C.implies和C.excludes这样的规则,在解码阶段把不同任务的标签关联起来。以Fastino的护栏模型GLiGuard为例:如果没有约束,同一段提示词有可能被同时标记为"安全"和"检测到提示词注入"这种自相矛盾的结果,而这项功能能够避免这种情况。同时推出的还有区间属性功能,可以把情感这类属性组绑定到特定实体类型上,在同一次前向传播中一并解码完成。
三种检查点,基准测试结果如何
Fastino把74M、194M、287M三种参数规模的检查点以Apache 2.0许可证上传到了Hugging Face。Hugging Face是一个流通平台,Meta、阿里巴巴等公司开发的开放模型都会上传到这里,Fastino这次也把自研的检查点放了上去。
| 模型 | 参数量 | 编码器 | 语言 |
|---|---|---|---|
| gliner2.5-small-v1 | 74M | DeBERTa-v3-xsmall | 英语 |
| gliner2.5-base-v1 | 194M | DeBERTa-v3-base | 英语 |
| gliner2.5-multi-v1 | 287M | mDeBERTa-v3-base | 多语言 |
团队按相同规模,把16项零样本基准测试结果与GLiNER2做了对比。多语言模型的整体平均macro F1为56.17,较GLiNER2的56.09小幅提升;base模型则从53.34跃升至54.87。
| 项目 | GLiNER2 | GLiNER2.5 |
|---|---|---|
| 整体平均(多语言) | 56.09 | 56.17 |
| 整体平均(base) | 53.34 | 54.87 |
| XNLI(多语言) | 37.55 | 62.30 |
| Few-NERD(base) | 47.22 | 55.14 |
涨幅最大的项目是XNLI,多语言模型从37.55跃升至62.30,提高了24.75个百分点。据悉,在训练数据中未出现过的语言——罗马尼亚语RONEC基准测试上,两种规模的模型都有所改善。
怎么用
这些检查点可以通过pip install "gliner2[local]"命令安装为本地软件包,在Python 3.10及以上环境中,CPU、CUDA、MPS都能用于推理。不过目前还没有代为托管这些检查点的推理服务,自行搭建服务器运行的自托管方式是唯一的部署途径。
加载模型时需要使用新的AutoExtractor,而不是旧版GLiNER2的区间加载器,三种检查点共用同一套公开API。适用场景也因组织规模而异:74M和194M模型可以在普通CPU服务器上运行,没有GPU预算的小团队也能直接接入提取功能;规模较大的组织则可以把它当作可微调的内部托管方案。Fastino列举的适用行业包括法律与合同审查、医疗与临床文档、金融服务、保险理赔、客户支持、AI安全工具,具体应用场景则包括个人信息检测与脱敏、合同条款提取、面向智能体记忆的知识图谱、模型路由、护栏分类,以及包含否定词和剂量属性的临床实体提取。
编辑视角
这次发布真正值得关注的地方,不在于基准分数本身,而在于"省下了哪部分成本"。用大型语言模型跑信息提取,每一份文档、每一个词元都会产生费用,而GLiNER2.5把这种成本结构挪到了完全不同的维度上。实体长度与计算量脱钩,意味着在实际业务中,处理一条四十个词的合同条款和一个两字姓名的成本可以完全相同——对那些整套跑大模型的团队来说,这个差异不容小觑。
把这类规模的开源模型放到实际业务中试用,得出的结论往往大同小异:基准测试的平均分差距看起来只有一两个百分点,并不惊人,但如果只挑出实际业务中真正会用到的特定类型(比如长条款、多语言文档)来看,体感差距要大得多。XNLI提升24.75个百分点,单看"平均值"很容易被忽略,但对处理多语言文档的团队来说,这足以成为换用新模型的理由。
对国内团队来说,可以这样设定实际应用的基准:如果是没有GPU预算的两三人小团队,不妨先用74M、194M检查点,仅靠CPU试着接入个人信息检测或合同条款提取功能。如果处理的是多语言文档,尤其是掺杂中文的文档,最好先用自己的数据验证一下287M多语言检查点的实际准确率。不过也要注意,目前还没有专门的托管服务,如果团队没有基础设施人员,直接接入生产服务可能还为时尚早。
接下来几周值得关注的,是会不会有推理服务提供商把这些检查点纳入托管选项。一旦自托管的负担减轻,小团队的采用速度肯定会明显加快。
评论