[GH-ISSUE #343] Possible inconsistencies arising from the pattern matching of CLIP tokenizer #296

Open
opened 2026-10-31 21:13:33 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @Mypathissional on GitHub (Apr 3, 2023).
Original GitHub issue: https://github.com/openai/CLIP/issues/343

Hi there,

I have been experimenting with the CLIP tokenizer and have observed that the tokenizer produces identical outputs for the following cases:

1). "1233" and "12 33"
2) "'Medicare For All" and "'M edicare For All"

In both cases, the tokenizer applies a pattern matching step using the regular expression re.compile(r"""<\|startoftext\|>|<\|endoftext\|>|'s|'t|'re|'ve|'m|'ll|'d|[\p{L}]+|[\p{N}]|[^\s\p{L}\p{N}]+""", re.IGNORECASE) before applying the BPE algorithm. This pattern matches the same characters for both cases (1) and (2), which seems to be a logical inconsistency, particularly for case (1).

I would suggest modifying the pattern to re.compile(r"""<\|startoftext\|>|<\|endoftext\|>|'s |'t |'re |'ve |'m |'ll |'d |[\p{L}]+|[\p{N}]+|[^\s\p{L}\p{N}]+""", re.IGNORECASE) to resolve this issue. This modified pattern should ensure that the tokenizer correctly handles cases where input text includes whitespace characters between numbers and preserves the integrity of the original input.

Best Regards,
Maria

Originally created by @Mypathissional on GitHub (Apr 3, 2023). Original GitHub issue: https://github.com/openai/CLIP/issues/343 Hi there, I have been experimenting with the CLIP tokenizer and have observed that the tokenizer produces identical outputs for the following cases: 1). "1233" and "12 33" 2) "'Medicare For All" and "'M edicare For All" In both cases, the tokenizer applies a pattern matching step using the regular expression `re.compile(r"""<\|startoftext\|>|<\|endoftext\|>|'s|'t|'re|'ve|'m|'ll|'d|[\p{L}]+|[\p{N}]|[^\s\p{L}\p{N}]+""", re.IGNORECASE)` before applying the BPE algorithm. This pattern matches the same characters for both cases (1) and (2), which seems to be a logical inconsistency, particularly for case (1). I would suggest modifying the pattern to `re.compile(r"""<\|startoftext\|>|<\|endoftext\|>|'s |'t |'re |'ve |'m |'ll |'d |[\p{L}]+|[\p{N}]+|[^\s\p{L}\p{N}]+""", re.IGNORECASE)` to resolve this issue. This modified pattern should ensure that the tokenizer correctly handles cases where input text includes whitespace characters between numbers and preserves the integrity of the original input. Best Regards, Maria
Sign in to join this conversation.
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
openai/CLIP#296
No description provided.