不用 LLM 也能抽 JSONGLiNER2 机制与工程落地文刚刚在掘金传开【免费下载链接】gliner2.5-multi-v1项目地址: https://ai.gitcode.com/hf_mirrors/fastino/gliner2.5-multi-v12026 年 6 月 18 日掘金上一篇题为《不用 LLM 抽 JSONGLiNER2 机制与工程落地》的文章开始进入技术圈视野作者贵慜_Derek信源指向论文 arXiv:2507.18546 与仓库 fastino-ai/GLiNER2。标题本身就带着一个反直觉的提问信息抽取不是已经被大模型承包了吗为什么还要绕开 LLM答案藏在 GLiNER 这条被低估的技术路线上用几亿参数的 encoder 模型在纯 CPU 上完成实体识别、文本分类、关系抽取和结构化记录JSON抽取不调 API、不上 GPU、数据不出本地。本文结合论文原文、Fastino 的 GLiNER2.5 多语言模型仓库与本仓库源码把这套机制的来龙去脉和工程落地讲清楚。一条线索两个GLiNER2先澄清命名混淆要读懂这篇文章必须先处理一个真实的搜索陷阱中文社区里叫GLiNER2的东西有两个技术路线完全不同。一个是 urchade/GLiNER 仓库演进出的 v2走 bi-encoder 路线约 6000 万参数社区文章描述其主打边缘部署与推理加速另一个是 Fastino AI 在 2025 年 7 月 24 日发表的论文《GLiNER2: An Efficient Multi-Task Information Extraction System with Schema-Driven Interface》arXiv:2507.18546所对应的统一多任务抽取框架。掘金这篇文章指向的是后者——一个将 NER、文本分类、层级结构化抽取收进同一架构、以 schema 声明式接口驱动的系统。这种命名撞车恰恰解释了为什么 GLiNER2 的中文资料传播得如此零散关键词检索总是同时命中两条叙事线。这也是下文为什么中文开发者现在才注意到它的线索之一。机制拆解从span 网格到boundary 稀疏配对Fastino 的 GLiNER2 延续了原版 GLiNER 的核心思路——用自然语言标签提示一个预训练 encoder 做零样本抽取而不是为每个标签单独训练。论文给出的统一输入格式是[Task Prompt] ⊕ [SEP] ⊕ [Input Text]任务提示词里写的是什么模型就抽什么。这一点在本仓库的 tokenizer_config.json 里有直接证据词表中新增了一批语义化的特殊 token——[P]任务提示起始、[E]实体类型、[C]结构字段/子组件、[L]分类标签、[R]关系、[SEP_STRUCT]、[SEP_TEXT]等。模型在训练中学会用这些 token 的嵌入与文本 span 做相似度打分打分高于阈值即输出实体或字段值。但 GLiNER2 真正的机制升级在解码端。原版 GLiNER 枚举最大宽度内所有 span复杂度随文本宽度增长GLiNER2 改为boundary 架构——只预测 start/end 边界再做稀疏配对任意长度的 span 只要落在编码窗口内都能表达不再受固定宽度网格限制。本仓库 config.json 将这一设计落到了具体超参数上architecture: boundary模型类为BoundaryExtractorstart_top_k: 24、end_top_k: 24、ends_per_start: 12每侧只保留 Top-K 候选边界再做配对把 O(n²) 的枚举压缩成稀疏候选集boundary_top_k_max: 128、candidate_budget: 192全局候选预算控制max_len: 4096boundary 模式下 span 长度上限即编码窗口长度overlap_policy: flat重叠 span 通过加权区间调度去重。仓库中的gliner2.5-multi-v1正是这条路线的最新多语言检查点287M 参数编码器为 mDeBERTa-v3-base权重约 594MBREADME.md 的 Model details 一节并已开启 classification、records、relations 三个任务头config 中enable_records: true、enable_relations: true。加载时需使用AutoExtractor——因为GLiNER2.from_pretrained是旧版 span 架构的加载器不会分发这个检查点from gliner2 import AutoExtractor model AutoExtractor.from_pretrained(fastino/gliner2.5-multi-v1) print(type(model).__name__) # BoundaryExtractor print(model.config.architecture) # boundary不用 LLM 抽 JSON的工程价值成本与延迟结构化抽取论文称 hierarchical structure extraction仓库称 structured records是这篇文章标题里抽 JSON的落点。论文验证了它的可行性与代价训练数据共 254,334 条其中 135,698 条真实文档新闻、法律、PubMed、ArXiv、Wikipedia由 GPT-4o 自动标注加 118,636 条合成数据5 个 epoch、AdamW、任务层学习率 2×10⁻⁵。这样一个通用小模型的零样本成绩是分类任务平均准确率 0.72GPT-4o 为 0.84但模型参数差了三个数量级CrossNER 五个领域平均 F1 为 0.590几乎贴住 GPT-4o 的 0.599。真正拉开差距的是延迟与部署成本。论文 Table 4 的 CPU 延迟实测单位毫秒标签数GPT-4oAPIDeBERTa-v3 zero-shotGLiNER2535817141302042567581635046316897208相对加速比1.00×0.10×2.62×两个关键结论一是 GLiNER2 在标准 CPU 上比 GPT-4o API 快约 2.6 倍二是它把全部标签放进一次前向传播延迟几乎不随标签数增长而 DeBERTa 式逐标签前向的方法在 20 个标签时慢了 6.8 倍。对每天处理海量短文本、对 QPS 敏感的生产管线这就是从按 token 计费 网络往返到固定成本 本地推理的切换。更现实的意义在数据主权医疗、金融、政务场景要求 PII 不出域GLiNER2 的本地部署能力直接踩中了 GDPR/HIPAA 合规诉求。工程落地从 schema 到 JSON一次前向仓库源码展示的落地方式比论文更细。结构化记录用声明式 schema 描述natural模式配合锚点字段保持实例身份——谁买了什么而不是把字段摊平成无关列表schema ( model.create_schema() .structure(purchase, modenatural, anchorbuyer) .field(buyer, dtypestr, cardinalityrequired_one) .field(item, dtypestr, cardinalityrequired_one) ) result model.extract( Alice bought apples and Bob bought oranges., schema, ) # { # purchase: [ # {buyer: Alice, item: apples}, # {buyer: Bob, item: oranges}, # ] # }这个输出就是文章标题里说的JSON——只是它由一个小型 encoder 在本地推理得出。同一套 API 还支持多任务组合实体 文档级分类 关系 结构化记录在一次extract调用内完成README.md 的 Task combination 一节给出了实体、sentiment 属性、topic 分类、works_for/announced关系与 announcement 结构同时输出的完整示例。长文本场景下extract_entities_long/extract_long以重叠分块扫描并按原文 offset 重映射 span规避了max_len截断。配套的还有托管训练链路仓库里的 SKILL.md 记录了 Fastino 的托管 API 契约——上传数据集、提交训练任务、评估、部署检查点覆盖基础模型效果不够 → 用领域数据微调 → 部署的完整闭环。也就是说GLiNER2.5 既有 Apache 2.0 的开源权重本仓库即其 Hugging Face 镜像也有从零样本到微调的工程路径。中文开发者为什么现在才注意到它把情报与源码放在一起看迟到的原因大致有三层。第一层是认知惯性。过去两年信息抽取的叙事被 LLM 主导多数工程团队默认结构化抽取 调 API 写 prompt很少有人意识到 encoder 路线的 GLiNER 已在 PII 脱敏等场景成为事实标准——论文专门提到它被 Presidio、Gretel 等隐私工具采用。GLiNER2 把 NER 扩展到分类与结构化抽取后覆盖的恰好是 RAG 预处理、客服意图识别、票据结构化这类高频、高量、对成本敏感的工程需求但中文资料里长期只有零散的单点教程多语言支持、微调手册、性能评估缺少机制 落地的整合视角。第二层是命名混乱抬高了检索成本。如上文所述GLiNER2同时指向 urchade 的 bi-encoder 小模型与 Fastino 的 schema 驱动统一框架搜索引擎给的两条线索互相稀释读者很难第一时间定位到论文与仓库的对应关系。第三层是价值锚点的迁移。随着 API 定价逐渐敏感、数据合规约束收紧免费额度内跑通 Demo与生产级成本可控之间的鸿沟被放大。GLiNER2 给出的叙事恰好切中这个痛点参数规模在 LLM 面前不值一提但 CPU 可跑、Apache 2.0、数据不出域——在效率优先的场景里小模型的竞争力从来不是能力上限而是单位成本下的可用性。掘金这篇文章踩中的正是这个从能不能转向划不划算的节点。回到标题的问题不用 LLM 能不能抽 JSON能而且延迟更低、成本更可控、合规更干净。GLiNER2 的边界在于能力上限——复杂推理、开放域常识、模糊长文仍是 LLM 的主场但在标签可枚举、结构可声明的抽取任务上一个 2.87 亿参数、跑在 CPU 上的 BoundaryExtractor已经把结构化抽取这件事从 API 账单里搬回了自己的服务器。【免费下载链接】gliner2.5-multi-v1项目地址: https://ai.gitcode.com/hf_mirrors/fastino/gliner2.5-multi-v1创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/11/3 19:06:29 · 阅读 1.2k 不用 LLM 也能抽 JSON？GLiNER2 机制与工程落地文刚刚在掘金传开
不用 LLM 也能抽 JSONGLiNER2 机制与工程落地文刚刚在掘金传开【免费下载链接】gliner2.5-multi-v1项目地址: https://ai.gitcode.com/hf_mirrors/fastino/gliner2.5-multi-v12026 年 6 月 18 日掘金上一篇题为《不用 LLM 抽 JSONGLiNER2 机制与工程落地》的文章开始进入技术圈视野作者贵慜_Derek信源指向论文 arXiv:2507.18546 与仓库 fastino-ai/GLiNER2。标题本身就带着一个反直觉的提问信息抽取不是已经被大模型承包了吗为什么还要绕开 LLM答案藏在 GLiNER 这条被低估的技术路线上用几亿参数的 encoder 模型在纯 CPU 上完成实体识别、文本分类、关系抽取和结构化记录JSON抽取不调 API、不上 GPU、数据不出本地。本文结合论文原文、Fastino 的 GLiNER2.5 多语言模型仓库与本仓库源码把这套机制的来龙去脉和工程落地讲清楚。一条线索两个GLiNER2先澄清命名混淆要读懂这篇文章必须先处理一个真实的搜索陷阱中文社区里叫GLiNER2的东西有两个技术路线完全不同。一个是 urchade/GLiNER 仓库演进出的 v2走 bi-encoder 路线约 6000 万参数社区文章描述其主打边缘部署与推理加速另一个是 Fastino AI 在 2025 年 7 月 24 日发表的论文《GLiNER2: An Efficient Multi-Task Information Extraction System with Schema-Driven Interface》arXiv:2507.18546所对应的统一多任务抽取框架。掘金这篇文章指向的是后者——一个将 NER、文本分类、层级结构化抽取收进同一架构、以 schema 声明式接口驱动的系统。这种命名撞车恰恰解释了为什么 GLiNER2 的中文资料传播得如此零散关键词检索总是同时命中两条叙事线。这也是下文为什么中文开发者现在才注意到它的线索之一。机制拆解从span 网格到boundary 稀疏配对Fastino 的 GLiNER2 延续了原版 GLiNER 的核心思路——用自然语言标签提示一个预训练 encoder 做零样本抽取而不是为每个标签单独训练。论文给出的统一输入格式是[Task Prompt] ⊕ [SEP] ⊕ [Input Text]任务提示词里写的是什么模型就抽什么。这一点在本仓库的 tokenizer_config.json 里有直接证据词表中新增了一批语义化的特殊 token——[P]任务提示起始、[E]实体类型、[C]结构字段/子组件、[L]分类标签、[R]关系、[SEP_STRUCT]、[SEP_TEXT]等。模型在训练中学会用这些 token 的嵌入与文本 span 做相似度打分打分高于阈值即输出实体或字段值。但 GLiNER2 真正的机制升级在解码端。原版 GLiNER 枚举最大宽度内所有 span复杂度随文本宽度增长GLiNER2 改为boundary 架构——只预测 start/end 边界再做稀疏配对任意长度的 span 只要落在编码窗口内都能表达不再受固定宽度网格限制。本仓库 config.json 将这一设计落到了具体超参数上architecture: boundary模型类为BoundaryExtractorstart_top_k: 24、end_top_k: 24、ends_per_start: 12每侧只保留 Top-K 候选边界再做配对把 O(n²) 的枚举压缩成稀疏候选集boundary_top_k_max: 128、candidate_budget: 192全局候选预算控制max_len: 4096boundary 模式下 span 长度上限即编码窗口长度overlap_policy: flat重叠 span 通过加权区间调度去重。仓库中的gliner2.5-multi-v1正是这条路线的最新多语言检查点287M 参数编码器为 mDeBERTa-v3-base权重约 594MBREADME.md 的 Model details 一节并已开启 classification、records、relations 三个任务头config 中enable_records: true、enable_relations: true。加载时需使用AutoExtractor——因为GLiNER2.from_pretrained是旧版 span 架构的加载器不会分发这个检查点from gliner2 import AutoExtractor model AutoExtractor.from_pretrained(fastino/gliner2.5-multi-v1) print(type(model).__name__) # BoundaryExtractor print(model.config.architecture) # boundary不用 LLM 抽 JSON的工程价值成本与延迟结构化抽取论文称 hierarchical structure extraction仓库称 structured records是这篇文章标题里抽 JSON的落点。论文验证了它的可行性与代价训练数据共 254,334 条其中 135,698 条真实文档新闻、法律、PubMed、ArXiv、Wikipedia由 GPT-4o 自动标注加 118,636 条合成数据5 个 epoch、AdamW、任务层学习率 2×10⁻⁵。这样一个通用小模型的零样本成绩是分类任务平均准确率 0.72GPT-4o 为 0.84但模型参数差了三个数量级CrossNER 五个领域平均 F1 为 0.590几乎贴住 GPT-4o 的 0.599。真正拉开差距的是延迟与部署成本。论文 Table 4 的 CPU 延迟实测单位毫秒标签数GPT-4oAPIDeBERTa-v3 zero-shotGLiNER2535817141302042567581635046316897208相对加速比1.00×0.10×2.62×两个关键结论一是 GLiNER2 在标准 CPU 上比 GPT-4o API 快约 2.6 倍二是它把全部标签放进一次前向传播延迟几乎不随标签数增长而 DeBERTa 式逐标签前向的方法在 20 个标签时慢了 6.8 倍。对每天处理海量短文本、对 QPS 敏感的生产管线这就是从按 token 计费 网络往返到固定成本 本地推理的切换。更现实的意义在数据主权医疗、金融、政务场景要求 PII 不出域GLiNER2 的本地部署能力直接踩中了 GDPR/HIPAA 合规诉求。工程落地从 schema 到 JSON一次前向仓库源码展示的落地方式比论文更细。结构化记录用声明式 schema 描述natural模式配合锚点字段保持实例身份——谁买了什么而不是把字段摊平成无关列表schema ( model.create_schema() .structure(purchase, modenatural, anchorbuyer) .field(buyer, dtypestr, cardinalityrequired_one) .field(item, dtypestr, cardinalityrequired_one) ) result model.extract( Alice bought apples and Bob bought oranges., schema, ) # { # purchase: [ # {buyer: Alice, item: apples}, # {buyer: Bob, item: oranges}, # ] # }这个输出就是文章标题里说的JSON——只是它由一个小型 encoder 在本地推理得出。同一套 API 还支持多任务组合实体 文档级分类 关系 结构化记录在一次extract调用内完成README.md 的 Task combination 一节给出了实体、sentiment 属性、topic 分类、works_for/announced关系与 announcement 结构同时输出的完整示例。长文本场景下extract_entities_long/extract_long以重叠分块扫描并按原文 offset 重映射 span规避了max_len截断。配套的还有托管训练链路仓库里的 SKILL.md 记录了 Fastino 的托管 API 契约——上传数据集、提交训练任务、评估、部署检查点覆盖基础模型效果不够 → 用领域数据微调 → 部署的完整闭环。也就是说GLiNER2.5 既有 Apache 2.0 的开源权重本仓库即其 Hugging Face 镜像也有从零样本到微调的工程路径。中文开发者为什么现在才注意到它把情报与源码放在一起看迟到的原因大致有三层。第一层是认知惯性。过去两年信息抽取的叙事被 LLM 主导多数工程团队默认结构化抽取 调 API 写 prompt很少有人意识到 encoder 路线的 GLiNER 已在 PII 脱敏等场景成为事实标准——论文专门提到它被 Presidio、Gretel 等隐私工具采用。GLiNER2 把 NER 扩展到分类与结构化抽取后覆盖的恰好是 RAG 预处理、客服意图识别、票据结构化这类高频、高量、对成本敏感的工程需求但中文资料里长期只有零散的单点教程多语言支持、微调手册、性能评估缺少机制 落地的整合视角。第二层是命名混乱抬高了检索成本。如上文所述GLiNER2同时指向 urchade 的 bi-encoder 小模型与 Fastino 的 schema 驱动统一框架搜索引擎给的两条线索互相稀释读者很难第一时间定位到论文与仓库的对应关系。第三层是价值锚点的迁移。随着 API 定价逐渐敏感、数据合规约束收紧免费额度内跑通 Demo与生产级成本可控之间的鸿沟被放大。GLiNER2 给出的叙事恰好切中这个痛点参数规模在 LLM 面前不值一提但 CPU 可跑、Apache 2.0、数据不出域——在效率优先的场景里小模型的竞争力从来不是能力上限而是单位成本下的可用性。掘金这篇文章踩中的正是这个从能不能转向划不划算的节点。回到标题的问题不用 LLM 能不能抽 JSON能而且延迟更低、成本更可控、合规更干净。GLiNER2 的边界在于能力上限——复杂推理、开放域常识、模糊长文仍是 LLM 的主场但在标签可枚举、结构可声明的抽取任务上一个 2.87 亿参数、跑在 CPU 上的 BoundaryExtractor已经把结构化抽取这件事从 API 账单里搬回了自己的服务器。【免费下载链接】gliner2.5-multi-v1项目地址: https://ai.gitcode.com/hf_mirrors/fastino/gliner2.5-multi-v1创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考