大规模文本预处理需先解决内存与分词问题：用生成器+tf.data避免OOM，轻量分词器优先，合理设vocab_size、output_dim及trainable，转TFRecord提升I/O性能，并用padded_batch确保静态shape。
大规模文本预处理：别急着喂模型，先过掉内存和分词关
TensorFlow 本身不直接“处理”原始大规模文本，它吃的是数值张量。你手里的几GB日志或千万级评论，第一步不是 tf.keras.layers.Embedding，而是得把文本切开、编号、对齐，且不能 OOM（内存溢出）。
常见错误是用 open().readlines() 一次性加载全部文本，再用 fit_on_texts() —— 这在百万行以上基本卡死或爆内存。
- 用生成器（
yield）逐批读取文件，配合tf.data.Dataset.from_generator()构建流水线 - 分词优先选轻量确定性方案：
tf.keras.preprocessing.text.Tokenizer支持fit_on_texts()的num_words截断，但更稳的是用tf.text.WhitespaceTokenizer或tf.text.BertTokenizer（需搭配 vocab 文件） - 避免把整个词表塞进内存：设置
num_words=50000，并用oov_token='<UNK>'处理未登录词 - 序列长度统一用
tf.keras.preprocessing.sequence.pad_sequences(..., maxlen=128, truncating='post')，别依赖模型动态 padding —— 分布式训练时 shape 必须静态
Embedding 层怎么接才不掉坑：权重初始化、冻结、维度选择
tf.keras.layers.Embedding 看似简单，但三个参数一错，后续全白跑：输入维度（vocab_size）、输出维度（output_dim）、是否训练（trainable）。
典型翻车现场：用预训练词向量（如 GloVe）初始化 Embedding，却忘了设 trainable=False，结果微调时把向量全搅乱；或者 vocab_size 设成词表最大 index+1，但实际 tokenized 后出现 index >= vocab_size 报 InvalidArgumentError: indices[0] = 50001 is not in [0, 50000)。
立即学习“Python免费学习笔记（深入）”；
-
vocab_size必须 ≥ 词表 size + 1（预留0给 padding）；检查tokenizer.word_index最大值，再 +1 -
output_dim别盲目堆高：128 或 256 足够多数中文场景；超过 300 容易拖慢收敛，且 GPU 显存占用陡增 - 加载预训练向量时，确保
weights=[embedding_matrix]形状为(vocab_size, output_dim)，且embedding_matrix[0]是全零（对应 padding） - 下游任务数据少时，设
trainable=False；数据多或领域差异大，设trainable=True并加小学习率（如tf.keras.optimizers.Adam(1e-5)）
TFRecord 是绕不开的性能拐点：文本转二进制不是可选项
当文本样本超百万、单次 epoch 耗时超过 10 分钟，Dataset.from_tensor_slices() 或生成器会成为 I/O 瓶颈。此时必须切到 TFRecord —— 它把文本 ID 序列、label、length 等打包成二进制块，顺序读取快 3–5 倍，且天然支持分布式分片。
容易忽略的是：TFRecord 不存储原始字符串，只存 int64_list 和 int64。你得提前 tokenize 并保存好 maxlen，否则无法反查。
- 写入用
tf.train.Example+tf.train.SequenceExample（变长序列推荐后者） - 特征字段命名要一致：比如输入序列存为
'tokens'（int64_list），label 存为'label'（int64） - 读取时用
tf.io.parse_sequence_example()，并显式指定sequence_features和context_features - 务必加
.prefetch(tf.data.AUTOTUNE)和.cache()（内存够时），否则 TFRecord 优势打折扣
Batch 内长度不一致？别靠 model.fit 自动 padding
很多人以为 model.fit(dataset) 会自动对 batch 内所有样本做统一 padding，其实不会 —— 它只保证 batch 维度一致，但每个样本仍是变长 RaggedTensor 或已 pad 好的矩形张量。若你传入未 pad 的 list of lists，会直接报错 ValueError: Failed to convert a NumPy array to a Tensor。
真正可控的方式，是在构建 Dataset 时就完成 padding，并用 padded_batch() 替代 batch()。
- 用
dataset.padded_batch(batch_size, padded_shapes=([None], []), padding_values=(0, -1))，其中[None]表示序列轴动态补零，[]表示 label 是标量 - 如果已用
pad_sequences()预处理过，就用普通batch()，但必须确保所有样本len(sequence) == maxlen - 注意
padded_batch的padding_values类型要匹配：文本 ID 补0，label 补-1（分类任务中常过滤掉 -1 样本） - 验证方式：打印
next(iter(dataset)).shape，应为(batch_size, maxlen)，而非(batch_size, None)
Embedding 层本身不解决文本稀疏性，它只是把离散 ID 映射成稠密向量；真正决定效果的，是前面 tokenizer 的切分粒度（字/词/Subword）、词表覆盖度、以及 padding 和 batching 是否让 GPU 始终满载。这些环节里任何一个没对齐 shape 或内存，后面训十天也救不回。
