docs(analyzer): document and test configuring multiple GLiNERRecognizer instances via YAML#2180
Closed
kalra-mohit wants to merge 2 commits into
Closed
Conversation
…er instances via YAML Fixes data-privacy-stack#1760. The recognizer registry YAML loader already supports multiple predefined recognizer instances of the same class by giving each entry a distinct `name` while pointing `class_name` at the shared class (the mechanism used elsewhere for HuggingFaceNerRecognizer), but this wasn't documented for GLiNERRecognizer and had no regression coverage, leading users to file this as a missing feature. - Add a "Configuring multiple GLiNER recognizers via YAML" section to docs/samples/python/gliner.md with a two-model example. - Document the `class_name` field in docs/analyzer/recognizer_registry_provider.md and link to the new GLiNER section. - Add regression tests covering multiple GLiNERRecognizer instances loaded via class_name/name, both through RecognizerListLoader.get directly and through the full RecognizerRegistryProvider (Pydantic validation) path. The GLiNER model class is mocked so the tests run without the optional `gliner` extra installed. - Update CHANGELOG.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…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
Author
|
Superseded by #2181, which folds this docs-only change together with a fix for the entity-leakage bug (credited to #2154) and the auto-naming ergonomics (credited to #2018) into one consolidated PR, per the coordination note on the issue. Closing this one to avoid leaving redundant/overlapping PRs open. |
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
2 participants
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.
Summary
Configuring multiple
GLiNERRecognizerinstances side-by-side via the recognizer registry YAML (e.g. different models/thresholds/entity mappings) already works today by giving each entry a distinctnamewhile pointingclass_nameatGLiNERRecognizer— the same mechanism used forHuggingFaceNerRecognizer. It just wasn't documented, so users had no way to discover it.This PR:
class_namefield inrecognizer_registry_provider.mdGLiNERmocked, so no heavy optional dependency required) covering both the registry-provider path and the lower-level loader utilsentity_mappings differ — see Can multiple GLiNERRecognizer instances be configured via YAML? #1760's later comment thread and the pending fix in fix(analyzer): allow GLiNER labels to be scoped per recognizer #2154) so the doc doesn't imply stronger isolation than currently existsNo source code changes — this is docs + tests only.
Closes #1760
Loading flow
flowchart TD A["recognizer_registry.yaml"] --> B1["entry: name=GLiNERRecognizerMultiPII<br/>class_name=GLiNERRecognizer<br/>threshold=0.4"] A --> B2["entry: name=GLiNERRecognizerSmall<br/>class_name=GLiNERRecognizer<br/>threshold=0.25"] B1 --> C1["GLiNERRecognizer instance A<br/>gliner_multi_pii-v1"] B2 --> C2["GLiNERRecognizer instance B<br/>gliner_small-v2.5"] C1 --> D["RecognizerRegistry"] C2 --> D D --> E["AnalyzerEngine.analyze"] E -. "known gap #1760 / fix pending #2154:<br/>requested entities appended as labels to ALL instances" .-> C1 E -. same gap .-> C2Test plan
test_recognizer_registry_provider.pytest_recognizers_loader_utils.pyclass_nameresolution logic predates this change (not new behavior, just newly documented)