Skip to content

AoA: tokenizer loading fallbacks for transformers-5.x-saved checkpoints - #5

Open
bylinina wants to merge 2 commits into
babylm-org:mainfrom
bylinina:aoa-tokenizer-fallbacks
Open

AoA: tokenizer loading fallbacks for transformers-5.x-saved checkpoints#5
bylinina wants to merge 2 commits into
babylm-org:mainfrom
bylinina:aoa-tokenizer-fallbacks

Conversation

@bylinina

Copy link
Copy Markdown
Contributor

Models saved with transformers 5.x record tokenizer_class: TokenizersBackend, which transformers 4.51.3 (pinned by this pipeline) cannot resolve. The rest of the pipeline (sentence_zero_shot, reading, finetune) already handles this via a PreTrainedTokenizerFast fallback (merged in #3); the AoA module has two call sites that were missed:

evaluation_functions.load_tokenizer_for_step — the AutoProcessor load raises per checkpoint, the surprisal loop swallows it, and the run completes "successfully" with an empty results dir (no surprisal.json; AoA is silently set to None at collation).
run.py scoring step — a raw AutoTokenizer load crashes after surprisal extraction succeeds, so aoa_score.json is never written.

This PR applies the same 3-level fallback (AutoProcessor → AutoTokenizer → PreTrainedTokenizerFast) to both call sites, matching the existing pattern. Tested on DeBERTa MLM checkpoints saved with transformers 5.x: both failure modes reproduce on upstream main and are resolved with this patch (surprisal extraction across 19 chck_*M revisions + scoring complete). No behavior change for models whose tokenizers load via AutoProcessor.

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.

1 participant