fix(analyzer): allow GLiNER labels to be scoped per recognizer#2154
Open
ultramancode wants to merge 1 commit into
Open
fix(analyzer): allow GLiNER labels to be scoped per recognizer#2154ultramancode wants to merge 1 commit into
ultramancode wants to merge 1 commit into
Conversation
kalra-mohit
pushed a commit
to kalra-mohit/presidio
that referenced
this pull request
Jul 21, 2026
…e GLiNER example The worked example configures instances with different entity_mapping values, which is exactly the scenario reported in data-privacy-stack#1760's later comment thread as leaking entity types across instances due to threshold semantics. Link to the repro and the pending fix (data-privacy-stack#2154) so readers aren't misled into thinking the pattern is fully isolated today.
This was referenced Jul 21, 2026
Closed
kalra-mohit
added a commit
to kalra-mohit/presidio
that referenced
this pull request
Jul 21, 2026
…e GLiNER example The worked example configures instances with different entity_mapping values, which is exactly the scenario reported in data-privacy-stack#1760's later comment thread as leaking entity types across instances due to threshold semantics. Link to the repro and the pending fix (data-privacy-stack#2154) so readers aren't misled into thinking the pattern is fully isolated today.
kalra-mohit
added a commit
to kalra-mohit/presidio
that referenced
this pull request
Jul 21, 2026
…config (data-privacy-stack#1760) Consolidates and builds on two other open PRs against this issue, crediting both explicitly: - Auto-derives a unique recognizer name from class_name + model_name when name is omitted on a class_name: GLiNERRecognizer YAML entry, so multiple instances no longer each require an explicit unique name. Approach credited to data-privacy-stack#2018 (ynachiket). - Adds an include_requested_entities_as_labels option (default true) to GLiNERRecognizer. When multiple instances are configured with different entity_mapping/threshold values, GLiNER's ad-hoc-label support previously let a requested entity type "leak" into an instance that wasn't configured for it, evaluated against the wrong threshold. Setting this to false per-instance closes the leak by restricting that instance to only ever request labels it's configured for. Design credited to data-privacy-stack#2154 (ultramancode), reproducing hexsm's original report. - Updates the GLiNER sample docs and recognizer_registry_provider.md to document both, replacing the earlier docs-only PR's caveat about the leakage bug with the actual fix. Closes data-privacy-stack#1760 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change Description
When multiple
GLiNERRecognizerinstances use differententity_mappingvalues and thresholds, entities from an analyze request are currently added as ad-hoc labels to every selected GLiNER recognizer.As a result, an entity can pass the threshold of a recognizer that was not configured to handle it.
This change adds an
include_requested_entities_as_labelsoption toGLiNERRecognizerand its YAML configuration.The option defaults to
trueto preserve the existing behavior. When set tofalse, only the recognizer's configured GLiNER labels are sent to the model.Issue reference
Related to #1760, specifically the runtime threshold edge case and backward-compatible opt-out proposed by @hexsm
in this comment.
Checklist