{"id":77740,"date":"2026-08-25T02:54:06","date_gmt":"2026-08-25T06:54:06","guid":{"rendered":"https:\/\/overcentral.com\/en\/?p=77740"},"modified":"2026-08-30T23:02:06","modified_gmt":"2026-08-31T03:02:06","slug":"fastino-gliner2-5-boundary-prediction-77740","status":"publish","type":"post","link":"https:\/\/overcentral.com\/en\/fastino-gliner2-5-boundary-prediction-77740\/","title":{"rendered":"Fastino Releases GLiNER2.5, Drops Span Enumeration in Extraction"},"content":{"rendered":"

The standard trade-off in information extraction has been a punishing one. Teams choose between small encoder models that are cheap to run but rigid in what they can capture, and large language models that offer flexibility at a cost that scales with every document processed. Fastino<\/a> has released GLiNER2.5<\/a>, a new version of its named entity recognition and extraction model that aims to collapse that trade-off by replacing the core architectural mechanism of span enumeration with boundary prediction. Instead of scoring every possible candidate span against a fixed width grid, the model now predicts where an entity starts and ends directly. This single architectural change removes the maximum entity width constraint, extends the context window to 4,096 words, and keeps computation linear in sequence length for a fixed schema. It also unlocks joint entity-relation decoding, cross-task label constraints, and per-span attributes. Across 16 zero-shot benchmarks, the multilingual checkpoint achieves 56.17 overall macro F1 against 56.09 for GLiNER2, with a 24.75-point gain on XNLI. Three checkpoints are now available on Hugging Face<\/a> under Apache 2.0 at 74 million, 194 million, and 287 million parameters.<\/p>\n

What Boundary Prediction Changes in Extraction Architecture<\/h2>\n

Earlier GLiNER models located entities by enumerating candidate spans. Every start position in the input sequence was paired with every allowed width, and each resulting span was scored against the schema. This design tied computational cost directly to a width axis and imposed a hard ceiling on the length of entities the model could detect. If a span fell outside the maximum width, typically around twelve words, it was never scored at all. The model could not rank it low because it could not see it.<\/p>\n

GLiNER2.5 removes enumeration entirely. The shared encoder still processes text and schema queries in a single forward pass. But instead of scoring spans, the model now predicts start and end scores over token boundaries, along with inside scores over individual tokens. A sparse proposal stage selects the most promising start and end positions per query and pairs them, with no restriction on the distance between them. A reranking head then scores each candidate using boundary evidence and span content. Relation candidates are drawn from the same pool rather than a separate path. The Fastino team reports that computation stays linear in sequence length for a fixed schema and candidate budget.<\/p>\n

For teams that have worked with earlier GLiNER versions, the practical difference is immediate. The concept of a maximum entity width, however generous, is gone. A forty-word indemnification clause in a legal contract costs the same computational resources to locate as a two-word person name. The removal of the width axis also means that the model can train on sequences up to 4,096 words, a significant increase that opens longer documents to direct processing without aggressive chunking.<\/p>\n

Is GLiNER2.5 Deployable in Production Today<\/h2>\n

Fastino has released three GLiNER2.5 checkpoints on Hugging Face<\/a> under the permissive Apache 2.0 license. Local inference is supported on CPU, CUDA, or MPS via pip install \"gliner2[local]\"<\/code>codecodecodecode with Python 3.10 or later. No inference provider currently hosts the checkpoints, so self-hosting is the only deployment path at launch. This is a meaningful constraint for teams that rely on managed inference services, but the checkpoints themselves are small enough that self-hosting is practical for a wide range of organizations.<\/p>\n

The 74 million and 194 million parameter checkpoints run on standard CPU boxes, which means a two-person team can ship extraction capabilities without a GPU budget. Larger organizations get a fine-tunable, privately hosted alternative to per-token LLM extraction, which can be critical for regulated industries where data cannot leave the network. The 287 million parameter checkpoint benefits from GPU acceleration but is still modest by modern standards.<\/p>\n

The industries that stand to benefit most directly include legal and contract operations, healthcare and clinical documentation, financial services, insurance claims processing, customer support, and AI safety<\/a> tooling. The applications span PII detection and redaction, contract clause extraction, knowledge graph construction for agent memory, agent and model routing, guardrail classification, and clinical entity extraction with negation and dosage attributes.<\/p>\n

Five Capabilities That Follow from the New Architecture<\/h2>\n

Long-Context Extraction Without Memory Penalty<\/h3>\n

Removing explicit span representations cut memory enough to train on sequences up to 4,096 words, and the checkpoints ship with max_len=4096<\/code>codecodecodecode as the default. The library also adds native chunking helpers through functions like extract_entities_long<\/code>codecodecodecode, extract_long<\/code>codecodecodecode, Classifier.classify_long<\/code>codecodecodecode, and JointIE.extract_long<\/code>codecodecodecode that remap spans back to character offsets in the original document. This matters for any organization processing documents that run beyond a few paragraphs, such as legal briefs, clinical notes, or technical manuals.<\/p>\n

Unlimited Span Length<\/h3>\n

This is the most direct consequence of the architectural change. In GLiNER2, spans were enumerated up to a fixed width, typically around twelve words. Longer entities were structurally invisible. In GLiNER2.5, a span can open at the first token of a document and close at the last. A forty-word indemnification clause costs the same to locate as a two-word name. For legal document processing, contract analysis, and any domain where entities can be long and descriptive, this removes a persistent failure mode.<\/p>\n

Joint Entity and Relation Extraction<\/h3>\n

Users can now declare entity types, typed relations, and structural rules such as unique_head=True<\/code>codecodecodecode and no_self_loops()<\/code>codecodecodecode. A beam search assembles a globally consistent graph where invalid combinations are never admitted, so output conforms by construction. The result.feasible<\/code>codecodecodecode flag tells downstream systems whether the graph is valid before they use it. For knowledge graph construction, this is a meaningful improvement over pipelines that extract entities and relations in separate stages and then reconcile them.<\/p>\n

Constrained Classification Across Tasks<\/h3>\n

The C.implies<\/code>codecodecodecode and C.excludes<\/code>codecodecodecode rules bind labels across tasks during decoding, which solves a specific problem that becomes visible in safety and guardrail applications. Fastino’s own GLiGuard guardrail model illustrates the issue: without constraints, a prompt can be labeled safe while simultaneously flagged for prompt injection. The decoder cannot produce outputs that violate declared rules. If no valid assignment exists, the classifier raises an error, which is far preferable to silently returning a contradictory or unsafe result.<\/p>\n

Span Attributes in the Same Pass<\/h3>\n

Attribute groups such as sentiment attach to specific entity types via applies_to<\/code>codecodecodecode and are decoded span-by-span in the same forward pass. Entities return qualified rather than flat. For clinical extraction, this means a medication entity can carry a negation attribute and a dosage attribute without requiring separate classification passes. The same applies to sentiment in customer feedback or urgency in support tickets.<\/p>\n

What Is a Featured Snippet Answer for GLiNER2.5<\/h2>\n

For readers encountering this model for the first time: GLiNER2.5 is a span-free information extraction model that predicts entity boundaries directly rather than scoring every possible span against a width grid. This architectural change removes the maximum entity width, allows a 4,096-word context, keeps computation linear in sequence length for a fixed schema, and enables joint entity-relation decoding, cross-task label constraints, and per-span attributes. The model is available in three sizes from 74 million to 287 million parameters under Apache 2.0.<\/p>\n

Benchmark Performance and the XNLI Jump<\/h2>\n

The Fastino team evaluated GLiNER2.5 zero-shot on 16 public datasets, reporting macro F1 against GLiNER2 at matched parameter sizes. The overall average for the multilingual checkpoint reaches 56.17 against 56.09 for GLiNER2 Multi, a modest improvement overall. The base checkpoint reaches 54.87 against 53.34 for GLiNER2 Base.<\/p>\n

The headline gain is on XNLI, where the multilingual checkpoint jumps to 62.30 from 37.55, a 24.75-point increase. This is a substantial improvement for a zero-shot cross-lingual benchmark and suggests that the boundary prediction approach generalizes better across languages than the span enumeration approach. Few-NERD improves for the base checkpoint to 55.14 from 47.22. Romanian RONEC, which represents a language the model was not explicitly trained on, improves for both the base and multilingual checkpoints.<\/p>\n

The benchmark results tell a nuanced story. The overall averages show that GLiNER2.5 is not a breakthrough in absolute performance across all tasks, but the specific gains on cross-lingual and low-resource benchmarks suggest that the architectural change has real value for multilingual and generalizable extraction. The XNLI result in particular is the kind of number that makes teams take notice, because cross-lingual transfer has been a persistent weakness of span-based encoder models.<\/p>\n

The Model Family and What Each Checkpoint Offers<\/h2>\n

Fastino ships three GLiNER2.5 checkpoints, all sharing the same public API. Users load with AutoExtractor<\/code>codecodecodecode rather than the legacy GLiNER2<\/code>codecodecodecode span loader. The 74 million parameter checkpoint is the smallest and most practical for CPU-only deployment. The 194 million parameter checkpoint offers a balance of capacity and inference cost. The 287 million parameter checkpoint is the largest and delivers the best benchmark performance, though it benefits from GPU acceleration.<\/p>\n

All three are released under Apache 2.0, which means they can be used in commercial products, fine-tuned, and redistributed without restriction. The licensing choice is consistent with Fastino’s approach to earlier GLiNER releases and positions the model for broad adoption.<\/p>\n

How the Decoding Process Works Under the Hood<\/h2>\n

The shared encoder processes text and schema queries in one pass. Instead of scoring spans, the model predicts start and end scores over token boundaries plus inside scores over individual tokens. A sparse proposal stage selects the most promising starts and ends per query and pairs them, with no restriction on distance. A reranking head then scores each candidate using boundary evidence and span content. Relation candidates are drawn from the same pool rather than a separate path, which is what enables joint entity-relation decoding.<\/p>\n

The computation stays linear in sequence length for a fixed schema and candidate budget because the proposal stage selects a fixed number of start and end candidates per query. The pairing operation is quadratic in the number of candidates, but that number is constant regardless of sequence length. This is the key scaling property that distinguishes GLiNER2.5 from both span enumeration and from transformer-based approaches that process every token pair.<\/p>\n

Deployment Considerations for Different Team Sizes<\/h2>\n

For a two-person team without a GPU budget, the 74 million parameter checkpoint running on a standard CPU box is the entry point. Inference speed will be slower than GPU-based alternatives, but the model is small enough that processing a few thousand documents per day is practical. The 194 million parameter checkpoint is a reasonable upgrade for teams that can allocate modest compute resources. The 287 million parameter checkpoint is best suited for teams with GPU access and higher throughput requirements.<\/p>\n

The self-hosting requirement is the most significant deployment constraint. Teams that rely on managed inference services from major cloud providers will need to set up their own infrastructure. The flip side is that self-hosting provides complete control over data, which is essential for regulated industries. The checkpoints are small enough that a single GPU instance can serve multiple requests in parallel, and the linear scaling property means that longer documents do not degrade throughput as dramatically as they would with span-based or transformer-based alternatives.<\/p>\n

What the Release Means for the Information Extraction Landscape<\/h2>\n

Fastino’s GLiNER2.5 release occupies a specific position in the extraction market. It is not competing with large language models on general-purpose extraction tasks where the flexibility of few-shot prompting matters more than cost or latency. It is competing for the middle ground: high-volume, structured extraction tasks where schema is known in advance, latency matters, and cost per document must be low.<\/p>\n

The architectural change from span enumeration to boundary prediction is the kind of incremental innovation that can shift the practical trade-offs for teams building extraction pipelines. Removing the maximum entity width alone addresses a persistent failure mode in legal, medical, and financial document processing. The joint entity-relation decoding and constraint system address the downstream cleanup that teams have to build around extraction models that cannot enforce their own structural rules.<\/p>\n

The XNLI benchmark result is the most striking single data point, because it suggests that boundary prediction generalizes better across languages than span enumeration. For organizations that need to extract entities from documents in multiple languages, this is a practical advantage that translates directly to lower maintenance overhead. The improvement on Romanian RONEC, a language the model was not explicitly trained on, reinforces the same point.<\/p>\n

The release also signals that the encoder-centric approach to information extraction is not finished evolving. The assumption that small encoder models are inherently limited compared to large language models is being challenged by architectural improvements that address their specific weaknesses. GLiNER2.5 does not<\/a> match the flexibility of GPT-4 for arbitrary extraction tasks, but it does not need to. It is targeting the volume use case where flexibility is less important than cost, latency, and the ability to enforce structural constraints.<\/p>\n

For teams that have been building extraction pipelines around GLiNER2, the upgrade path is straightforward. The API is similar, the model sizes are comparable, and the checkpoints are available under the same license. The main migration cost is revalidating the extraction behavior on the specific domains and document types that the pipeline handles. The gains in recall for long entities, the ability to extract relations jointly, and the constraint system for cross-task labels are likely to justify the migration effort for most production use cases.<\/p>\n

The broader implication is that the information extraction market is segmenting. Large language models will continue to dominate the flexible, few-shot, rapid-prototyping end of the market. Encoder-based models like GLiNER2.5 will continue to dominate the high-volume, low-cost, schema-constrained end of the market. The gap between them is narrowing, but it is narrowing from the bottom as much as from the top. Teams that have been waiting for encoder models to catch up in capability may find that GLiNER2.5 represents the point where the trade-off becomes genuinely favorable for a wide range of production use cases.<\/p>\n","protected":false},"excerpt":{"rendered":"

The standard trade-off in information extraction has been a punishing one. Teams choose between small encoder models that are cheap to run but rigid in what they can capture, and large language models that offer flexibility at a cost that scales with every document processed. Fastino has released GLiNER2.5, a new version of its named […]<\/p>\n","protected":false},"author":7,"featured_media":77751,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/pub-4d4fc17555de4152be07eaf2a416a31e.r2.dev\/en\/ocie_1787640875070.jpg","fifu_image_alt":"Fastino Releases GLiNER2.5, Drops Span Enumeration in Extraction","footnotes":""},"categories":[31],"tags":[],"class_list":["post-77740","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technology"],"fifu_image_url":"https:\/\/pub-4d4fc17555de4152be07eaf2a416a31e.r2.dev\/en\/ocie_1787640875070.jpg","fifu_image_alt":"Fastino Releases GLiNER2.5, Drops Span Enumeration in Extraction","_links":{"self":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/77740","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/comments?post=77740"}],"version-history":[{"count":0,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/77740\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media\/77751"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media?parent=77740"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/categories?post=77740"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/tags?post=77740"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}