What gliner2 2.0.0 actually offers for entity attributes #362

Activity

1. antejavor

   added

   wayfinder:researchWayfinder research ticketWayfinder research ticket

   on Sep 22, 2026
2. antejavor

   added a parent issue on Sep 22, 2026

   • Map: Typed relation model for context-graph extraction #344
3. antejavor

   self-assigned this

   on Sep 22, 2026
4. antejavor

   marked this as blocking on Sep 22, 2026

   • Values, not links: do entity attributes belong in the model #361
5. antejavor commented on Sep 22, 2026

   

   antejavor

   on Sep 22, 2026

   ContributorAuthor

   More actions

   Resolution

   Full write-up, 754 lines with per-claim file:line and command output: unstructured2graph/docs/research/gliner2-attributes.md on branch research/gliner2-attributes (commit 0020973). Branch only, no PR, same convention as the #345 note.

   1. No attribute mechanism exists on the joint path — none, anywhere

   EntitySpec carries six fields, none a value (joint_ie/schema.py:22-32), and entity() is keyword-only with no **aliases — unlike relation(), so the absence reads as deliberate rather than an oversight. JointSchema has no field/structure/classification/entity_attributes; compile_schema hard-codes "json_structures": [] and "classifications": [] (joint_ie/compiler.py:26-28); JointResult/JointEntity have no slot to put a value in.

   Verified by forcing it: a structure appended directly into compiled.model_schema runs without error and the result still contains only ['entities', 'relations'] — silently dropped.

   A trap worth writing down: JointSchema.from_dict ignores any unknown top-level key without complaint. A config file carrying an attributes: block would load cleanly, validate, and do nothing.

   2. The legacy API is the mechanism — three of them — and using it costs typed relations

   • entity_attributes() + AttributeGroup — closed label sets bound to entity spans
   • structure().field() — the only mechanism that extracts an actual value
   • classification() — document-level, entity-free

   All three compose with entities and relations in a single extract() call (verified: result keys ['facts', 'entities', 'topic', 'relation_extraction']). But that call is the legacy runtime #345 retired: relations there compile to {"head": "", "tail": ""} and endpoints come back as span dicts.

   So the trade is stark: values in the same pass, or typed relations — not both. Keeping JointSchema means a second inference call per window (+90% wall clock, measured), and that second call has no entity ids — which resurrects exactly the span-matching apparatus #345 established we could delete.

   3. Three landing places, only one of which is a real value

   mechanism	what comes back	attached to
   entity_attributes	{"label", "confidence"} — no offsets, no text grounding	co-located with the entity row, but legacy output has no ids
   structure().field()	a real span: {"text": "25:50", "confidence": 0.9999, "start": 82, "end": 87}	nothing — document-scoped
   structure(mode="natural", anchor=...)	per-anchor instances	the only per-entity construct

   Record mode's anchor spans match joint entity ids exactly by (start, end) — verified (414,419) -> e10, (540,545) -> e14 — so coupling the two paths is mechanically recoverable even though the library does not hand it to you.

   4. Constrained by construction; nothing enforced during decoding; no feasibility signal

   Closed sets (AttributeGroup.labels, field choices=) are enforced by only ever scoring declared labels — there is no allow_edge analogue because there is no search. Cardinality is dtype ("str" -> spans[0], "list" -> all); cardinality=/exclusive= are inert outside record mode. validators= (regex) is a provable post-hoc filter: the same span returns at byte-identical confidence 0.9882827401161194 with and without a matching validator. There is no feasible analogue — the legacy result is a plain dict, so #350's infeasibility question has no counterpart here.

   Two sharp edges:

   • A single-label group can never abstain. It is a softmax argmax: three unrelated entities given a planet group all came back Mars.
   • choices= hallucinates. It returned "alpha" at confidence 0.99 from a list whose members appear nowhere in the text.

   The only abstention route is multi_label=True plus a threshold. An unfillable field returns null; an all-unfillable structure is silently dropped entirely.

   5. Composes with per-window driving, is cheap — and conflicts across windows

   Costs on a 572-char window, CPU, median of 5: joint baseline 157ms; +1 attribute group (3 labels) +12ms; +6-field structure +12ms; +18-field structure +88ms; joint-then-legacy as two calls 299ms (+90%). Candidate growth is linear, not quadratic — attribute labels become extra entity queries (5 -> 8), unlike the endpoint expansion #350 measured.

   The real problem is structural, and it lands on #352: a structure is one instance per document, so every window competes to fill every field. Same text, same schema — purchase_date came back as both March 14, 2025 and last Saturday; pair_count as both 3 pairs and Three pairs; personal_best flipped from 26:34 to 25:50 purely by changing window size 220 -> 400. Nothing in the output says which is right.

   6. No version bump exists, let alone is needed

   gliner2==2.0.0 is installed and is the latest on PyPI. "Span attributes" is Schema.entity_attributes — its own docstring says the labels are "decoded as span attributes" (inference/schema.py:331), and AttributeGroup is a public export (__init__.py:42). The "2.5" upstream markets is the checkpoint generation (fastino/gliner2.5-base-v1), not a library version, and we already run it — its BoundaryHeadSettings has enable_records=True, enable_relations=True, enable_abstention=True. Requires-Dist: transformers<5,>=4.38 is still 2.0.0's pin, so adopting attributes needs no new dependency, extra, or version, and nothing touches the CVE-2026-1839 floor.

   Beyond the brief: #350's gap was its vocabulary, not the API

   Declaring Duration, Quantity, TimeWindow, Money, Date as entity types and relating into them expresses all five value facts on the joint path — one pass, entity ids and #345's constraint enforcement intact, feasible=True:

   REL owns_count     Person:'user'  -> Quantity:'3 pairs'        conf=0.985
   REL paid           Person:'user'  -> Money:'$129.99'           conf=0.964
   REL personal_best  Person:'user'  -> Duration:'26:34'          conf=0.971
   REL works_shift    Person:'Admon' -> TimeWindow:'Sunday shift' conf=0.879
   

   So "3 of 6 question types have no expressible answer" (#350) is a property of that prototype's vocabulary, not of the library. Carried to #361 as a third option alongside attributes and reified assertions.

   Three caveats, all visible in that same output: 2 of 4 values are wrong (personal_best bound 26:34, the previous PB — 25:50 was never extracted as a Duration at all; works_shift bound 'Sunday shift' while '8am-4pm' sat two tokens away, extracted at conf 0.998); relations triplicated (the same 3.3x mention duplication #350 measured); 280ms against a 124ms baseline. The structure path got 5/5 on the same text where this got 2/4 — a sample of one, and not a quality result.

   Relatedly, and worth keeping: in the same single legacy pass, the relation mechanism answered personal_best = 26:34 while the structure mechanism answered 25:50. Same model, same text, two mechanisms, two different answers.

   Could not determine

   • Accuracy of any of this. Everything is one 572-char window. The 5/5-vs-2/4 split must not be read as a quality result; that needs the eval over the session corpus.
   • Whether record mode's field-to-anchor binding is controllable from the schema. It bound a value 460 chars away to the wrong anchor — gave a runner's personal best to Admon the physio, twice, and left shift null. occurrence_policy ("all"|"first"|"error_on_ambiguous"|"latent_all") exists and was not swept; error_on_ambiguous in particular may surface ambiguity rather than guess. This is the most consequential unknown here, because record mode is the only per-entity value construct — folded into Values, not links: do entity attributes belong in the model #361 as work its session does.
   • Whether attributes survive extract_long (source says yes; not run, since we own windowing per Wire a constrained ontology and read the edges #350/Chunking and the durability of constraints #352).
   • The span (non-boundary) architecture, which carries a second, separate attribute implementation with an extra overlap-dedupe pass.
   • Whether a value-shaped-entity-type vocabulary could ever be derived (The derivation contract for LlmRecommendationStrategy #353) rather than hand-written.
   • Calibration: structure-field confidences cluster at 0.99+, attribute confidences spread 0.44-0.99. Different heads, not calibrated against each other — a single threshold across both would be unsound.
6. antejavor

   closed this as completedon Sep 22, 2026