Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions src/Microsoft.ML.Tokenizers/Model/BpeOptions.cs
Original file line number Diff line number Diff line change
Expand Up @@ -143,6 +143,14 @@ public BpeOptions(string vocabFile, string? mergesFile = null)
/// if true, the input text will be converted to UTF-8 bytes before encoding it.
/// Additionally, some ASCII characters will be transformed to different characters (e.g Space character will be transformed to 'Ġ' character).
/// </summary>
/// <remarks>
/// Byte-level encoding is normally paired with a byte-level pre-tokenizer. When this property is set to

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we describe the default pre-tokeniser’s behaviour rather than make this a requirement of ByteLevel?

/// <see langword="true"/>, <see cref="PreTokenizer"/> must be set as well.
/// On its own, byte-level encoding maps the space character to 'Ġ' but does not keep the whitespace attached
/// to the following token, so spaces and newlines are dropped during encoding and cannot be recovered by decoding.
/// Configuring a byte-level pre-tokenizer, for example <see cref="RegexPreTokenizer"/> built from the GPT-2

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we limit this claim to preserving whitespace during pre-tokenisation? Normalisation and missing vocabulary entries can still change or discard input, so the GPT-2 regex alone cannot guarantee a lossless round trip.

/// pattern, makes the round trip lossless.
/// </remarks>
public bool ByteLevel { get; set; }

/// <summary>
Expand Down