构建 MiniGPT 第二步先从 Tokenizer 入手完成核心切分逻辑

Tokenizer 看似只是将文本切割为若干片段，但在编写具体代码之前，必须先确定文本切分的精确粒度。神经网络的底层运算是线性代数，它无法直接理解人类语言中的“单词”概念，所能接收和处理的数据形式仅限于向量和矩阵。Tokenizer 的核心职责便是把自然语言转化为模型可直接运算的整数序列。

在实际开发中，文本切分通常有三种主要粒度，每种方案各有优劣：

• 字符级 (Char-level)：将字母、空格及标点符号单独作为 token。以 "the cat sleeps" 为例，会被拆解为 ['t', 'h', 'e', ' ', 'c', 'a', 't'...]。该方案的词表极小，英文仅涉及几十个字符，实现门槛最低，但会导致文本序列显著变长，增加模型计算负担。
• 单词级 (Word-level)：以完整单词为 token。上述例子会变为 ['the', 'cat', 'sleeps']。这虽然缩短了序列长度，但词表规模会迅速膨胀至数万级别，且存在 OOV（Out of Vocabulary）问题：若遇到训练集未涵盖的新词，模型便无法处理。
• 子词级 (Subword)：如 GPT-2 采用的 BPE 算法属于此类。它在字符与单词间取得平衡，将高频字符组合合并。例如 "sleeping" 可能拆分为 "sleep" 和 "ing"。此法既解决 OOV 问题又控制序列长度，已是工业标准，但实现复杂度最高。

为确保 MiniGPT 项目能快速验证流程，避免被复杂的 BPE 合并算法延误进度，此次实践选用了最简化的字符级方案。尽管它并非生产环境的最优解，但足以用于理解“编码-解码”这一完整闭环机制。

在代码架构设计上，通过分离两个类来保障后续的可替换性。Vocabulary 类专注于维护字符与 ID 的双向映射关系，而 Tokenizer 类则调用词表执行实际转换。这种结构设计意味着，若未来需将字符级方案升级为 BPE，仅需替换 Tokenizer 的实现即可，无需对整体流程进行重构。

核心类的结构逻辑如下所示：

// Vocabulary 类负责维护字符到 ID 的 Map
public class Vocabulary {
    private Map<Character, Integer> charToId = new HashMap<>();
    private Map<Integer, Character> idToChar = new HashMap<>();
    
    public int encode(char c) {
        return charToId.getOrDefault(c, 0); // 0 作为未知字符
    }
    
    public char decode(int id) {
        return idToChar.getOrDefault(id, ' ');
    }
}

// Tokenizer 类负责处理字符串序列
public class Tokenizer {
    private Vocabulary vocab;
    
    public List<Integer> tokenize(String text) {
        return text.chars()
                   .mapToObj(vocab::encode)
                   .collect(Collectors.toList());
    }
}