Skip to content

fix: handle multiple GLiNER labels share the same span - #238

Open
asteier2026 wants to merge 3 commits into
mainfrom
asteier2026/bugfix/gliner-duplicate-span-score-tiebreak
Open

fix: handle multiple GLiNER labels share the same span#238
asteier2026 wants to merge 3 commits into
mainfrom
asteier2026/bugfix/gliner-duplicate-span-score-tiebreak

Conversation

@asteier2026

Copy link
Copy Markdown
Contributor

Summary

  • resolve_overlaps previously used alphabetical label order as the final tiebreaker when two GLiNER detections shared the exact same character span, causing higher-confidence labels to be silently dropped in favour of lower-confidence ones.
  • Added -item.score to the sort key (before item.label) so the highest-scoring label wins on exact-span ties.

Example: "Mum" was tagged as both relationship (score 0.941) and last_name (score 0.719). Before this fix, last_name won because l < r alphabetically. After, relationship correctly wins.

Test plan

  • Existing test_detection_postprocess.py parametrized test covers the new behaviour — verify it passes with make test
  • Spot-check a rewrite run on a text with relationship/family terms to confirm relationship entities surface correctly

🤖 Generated with Claude Code

@asteier2026
asteier2026 requested a review from a team as a code owner August 6, 2026 15:24
@greptile-apps

greptile-apps Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR changes exact-span entity conflict resolution and preserves detector provenance during occurrence propagation. It also extends W&B benchmark-import identity metadata and guarded SDK configuration behavior.

  • Prefer higher-confidence detections when labels share an exact character span.
  • Avoid creating propagation copies at coordinates already occupied by original entities.
  • Add benchmark identity validation, CLI/config projection, retry refresh behavior, documentation, and tests.

Confidence Score: 4/5

The PR is not yet safe to merge because mixed-source exact-span collisions can still replace detector entities with synthetic augmented entities.

The propagation-specific provenance regression is addressed, but resolve_overlaps still compares real detector confidence against synthetic score-1.0 values from apply_augmented_entities, leaving the previously reported mixed-source entity replacement behavior reachable.

Files Needing Attention: src/anonymizer/engine/detection/postprocess.py

Important Files Changed

Filename Overview
src/anonymizer/engine/detection/postprocess.py Adds score-based exact-span ordering and skips propagation copies at original entity coordinates.
tests/engine/test_detection_postprocess.py Adds coverage for exact-span score selection and preservation of detector provenance during propagation.
tools/measurement/import_wandb_run.py Adds benchmark identity inputs to strict W&B imports.
tools/measurement/measurement_tools/wandb_models.py Extends typed W&B configuration models with validated benchmark identity metadata.
tools/measurement/measurement_tools/wandb_setup.py Updates guarded W&B environment and publication configuration handling.

Reviews (4): Last reviewed commit: "fix: skip propagation copies for spans a..." | Re-trigger Greptile

Comment thread src/anonymizer/engine/detection/postprocess.py
@asteier2026 asteier2026 changed the title fix: prefer highest-scoring label when multiple GLiNER labels share the same span fix: handle multiple GLiNER labels share the same span Aug 10, 2026
lipikaramaswamy and others added 2 commits August 10, 2026 11:27
Signed-off-by: asteier2026 <asteier@nvidia.com>
…he same span

resolve_overlaps previously used alphabetical label order as a tiebreaker for
exact-span matches, causing higher-scoring labels like relationship (0.941) to
be dropped in favour of lower-scoring ones like last_name (0.719). Adding
-score before label in the sort key ensures the highest-confidence label wins.

Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: asteier2026 <asteier@nvidia.com>
@asteier2026
asteier2026 force-pushed the asteier2026/bugfix/gliner-duplicate-span-score-tiebreak branch from 5bb4fd6 to 06e5aaa Compare August 10, 2026 18:28
@asteier2026
asteier2026 requested a review from a team as a code owner August 10, 2026 18:28
The score-based tiebreak (added to prefer highest-scoring GLiNER label
for same-span conflicts) caused expand_entity_occurrences to emit
propagation copies with score=1.0 over original detector spans with
lower scores, replacing their source and score metadata in final_entities.

Fix: skip creating a propagation copy when the position is already
covered by an original entity span, preserving detector provenance.
Adds regression test confirming source and score are retained.

Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
@asteier2026

Copy link
Copy Markdown
Contributor Author

Changes made per Greptile suggestions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants