PTB数据集全解析：从格式到语言模型训练实践

简介：PTB（Penn Treebank Dataset）是自然语言处理领域广泛使用的标准文本语料库，源自《华尔街日报》约100万单词，常被用于词嵌入、语言模型及序列到序列任务的训练与评估。这份资源面向深度学习研究者、NLP初学者及相关课程实践者，省去了自行下载与整理的麻烦。

RAR压缩包内共62个文件，以shell训练脚本、C/C++源码、txt数据文件及readme说明为主，另有预训练模型和gz压缩备份，整体约31.2MB。目录采用simple-examples、rnnlm等模块划分，包含多项实验的train/test脚本，方便按需调用。

内容上提供了标准的train/valid/test划分，并附带字符级文本，覆盖数据预处理、词映射、RNN/LSTM语言模型构建、困惑度评估等关键环节。随包的示例代码可帮助读者快速跑通从数据加载到模型训练的完整流程，适合用来对比不同网络结构或作为毕设、课程项目的起点。目前已有1825人学习使用，是入门语言建模与词向量实验的实用资料。 搞NLP这行的人，十有八九都听说过PTB这个名字。

PTB全称Penn Treebank Dataset，出自宾夕法尼亚大学在上世纪90年代做的树库标注项目，原本是为了给句法分析提供高质量语料。后来Mikolov等人在做语言模型研究时，从树库中把纯文本部分提取出来，整理成了train/valid/test三个文件，结果这个版本成了整个深度学习社区最常用的文本数据集之一。到现在，不管是RNN、LSTM还是Transformer早期的工作，只要涉及语言模型，基本都绕不开在PTB上报一个perplexity。

这篇文章就围绕PTB展开，讲清楚它到底是什么、文件格式是什么样、怎么加载成模型能用的张量、为什么它能在语言模型评测里霸榜这么多年，以及我在实际折腾数据时踩过哪些坑。

1. PTB到底是什么，为什么值得认真对待

1.1 从华尔街日报到各大论文的常客

PTB最早的语料来源，是《华尔街日报》1989年到1993年的文章。宾夕法尼亚大学对这些文章做了精细的句法标注，形成了树库，这就是Penn Treebank的原始形态。树库本身是带标签的，比如名词短语、动词短语、语法树结构，这套东西在自然语言处理早期是非常宝贵的资源。

后来做语言模型的人发现，不需要那么复杂的标注，只需要纯文本序列就够了。于是就有了从树库中提取出来的简化版本，去掉了句法树标签，只保留单词和标点，按空格分开。这个版本在学术界流传极广，很多开源实现里直接叫PTB dataset，也就是你现在能在GitHub上看到的那个只有几个文本文件的版本。

一个数据集的经典程度，从引用量就能看出来。从上世纪90年代至今，PTB被用于词性标注、命名实体识别、句法分析、语言模型、词向量评估等几乎每一个NLP子领域。尤其是语言模型方向，几乎每个新模型出来，都要先在PTB和WikiText-2上跑一个baseline，看看perplexity降没降。可以说，PTB就是语言模型领域的“标准考场”。

1.2 它到底能拿来干哪些事

PTB最核心的用途是训练和评估语言模型。语言模型的任务就是给定前面的词，预测下一个词的概率分布。PTB刚好提供了连续的英文文本序列，又有固定的词表规模，跑起来又快，特别适合用来验证一个新模型结构是否有效。

除了语言模型，PTB还能用来做这些事：

• 词性标注和句法分析的评测基准。树库原始版本带了标注，可以拿来评测序列标注模型。
• 词向量质量的快速验证。在这个语料上训练的word embeddings虽然不算大规模，但是用来排查训练流程问题很好用。
• 作为入门学习的首选语料。因为它小，词表才10000左右，一个CPU都能跑起来，非常适合新手理解语言模型训练的整体流程。

适合参考这篇内容的人，主要两类：一类是刚开始接触NLP、想做语言模型实验的学生和算法工程师；另一类是已经会用PTB，但想搞清楚数据预处理细节、提高实验复现效率的从业者。

2. 文件和格式：动手前先把数据看明白

2.1 train、valid、test三个文件的关系

通常你在开源仓库里下载到的PTB，是三个文本文件：

• ptb.train.txt
• ptb.valid.txt
• ptb.test.txt

这三个文件分别对应训练集、验证集和测试集。不同版本在具体数值上略有差异，但大致规模如下：

训练集负责训练模型参数，验证集用来做超参数调整和早停，测试集只在最终评估时使用一次。这个划分比例大约是89% / 6.5% / 4.5%，放在今天看训练集偏小，但正因为小，训练速度快，才适合做快速迭代。

有一点要提醒：网上流传的PTB版本非常多，不同的处理脚本会导致token数量差个几千。比如有些版本把句子首字母大写了，有些版本全小写了，有些版本把换行处理成<eos>，有些没有。遇到统计数据对不上的情况不用太纠结，只要保证自己实验里使用的是同一个版本，前后一致即可。

2.2 一行文本里藏着的预处理细节

直接打开ptb.train.txt，你会看到这样的内容：

aer banknote berlitz calloway centrust cluett fromstein gitano guterman hydro-quebec ipo kia memotec mlx nahb puntsave regio role ral simons

这段内容是PTB特有的“词汇表”行。PTB的作者把词频排序后的全部词汇写在第一行，这个习惯导致了后来很多人在处理时，会特地把第一行单独拿出来做词表，而不是像WikiText那样逐步统计。

再看正常的句子样例：

N years ago , the conglomerate said its 1988 results had been affected by a huge $ N write-off in its mining operations , which were mainly in South Africa .

这里能看出几个非常明显的预处理特征：

• 所有数字都被替换成了N，不管是“1988”还是“$1.4 billion”里的数字，一律变成N。
• 标点符号和单词之间用空格隔开，比如逗号前后都有空格。
• 句子首字母没有做强制大写，很多词都是小写。
• 特殊词（如地名、人名等）中的连字符被保留，如hydro-quebec。

这些细节不是你看到才要注意，而是在你做实验对比时必须了解的事。因为不同的预处理方式会对perplexity数值产生不小的影响。如果一篇论文用了PTB但没说清楚数字是怎么处理的，那你对比数值时就要小心了。

3. 预处理实操：从原始文本到模型可用的张量

3.1 搭建词表

拿到PTB文本后，第一步是把tokenize好的词映射成数字id。这里不需要自己额外做分词，因为PTB本身已经处理好了，词和标点之间都有空格。

下面这段代码是我常用的词表构建方式：

from collections import Counter with open('ptb.train.txt', 'r') as f: text = f.read() tokens = text.split() word_freq = Counter(tokens) vocab = ['<unk>', '<eos>'] + [w for w, c in word_freq.items() if c > 0] word2idx = {w: i for i, w in enumerate(vocab)} idx2word = {i: w for w, i in word2idx.items()}

注意这里我在最前面加了<unk>和<eos>两个特殊符号。<unk>表示词表外词，<eos>表示句尾。后面把句子转成id序列时，遇到词表之外的词全部映射到<unk>。

关于<eos>，有的实现会把它加在每句话结尾，有的不加。加的好处是让模型学到“一句话说完了”这个边界信号，这在做文本生成时很有用。PTB原始脚本通常会在每句话末尾插入<eos>，所以你在按行读取文件时，可以这样处理：

sentences = [] with open('ptb.train.txt', 'r') as f: for line in f: words = line.strip().split() if not words: continue sentences.append(words + ['<eos>'])

3.2 把语料切成batch和训练样本

PTB语言模型训练有一个经典做法：不按单个句子组织batch，而是把整个训练集当成一个超长序列，然后切成连续的时间步。这样做的好处是能充分利用长距离依赖信息，同时代码实现也简单。

具体操作流程：

1. 把所有训练句子拼接成一个很长的token id列表。
2. 根据batch_size把这个列表切成batch_size份，每份长度大致相等。
3. 在每个batch中，按num_steps滑动窗口取输入和目标。

常规参数是batch_size=20，num_steps=35。这个组合在PTB上非常经典，很多论文和开源代码都用这组参数。

示例代码如下：

import torch def token_ids_to_tensor(token_ids, batch_size, num_steps): num_batches = len(token_ids) // batch_size token_ids = token_ids[:num_batches * batch_size] data = torch.tensor(token_ids, dtype=torch.long) data = data.view(batch_size, -1) return data data = token_ids_to_tensor(all_token_ids, batch_size=20, num_steps=35)

然后在训练循环里按列滑动取窗口。这里有个关键点：输入序列是data[:, i:i+num_steps]，目标序列是data[:, i+1:i+num_steps+1]，刚好把下一个词当作监督信号。这种切法比逐句处理高效很多，因为每个batch内部都是连续的上下文，模型能学到跨句子的语言规律。

3.3 验证集和测试集要用同一套词表

这是一个非常容易踩的坑。验证集和测试集里的词，必须使用训练集构建的word2idx来映射，不能单独重新建词表。

原因是这样的：如果在验证集上重新统计词频并构建词表，那验证集里所有词都是词表内词，不会有<unk>出现。但在训练集里低频词很多，测试时模型要学会处理未知词。两边词表不一致，perplexity数值就没有可比性。

正确的操作是：

def encode_sentences(sentences, word2idx): all_ids = [] for words in sentences: ids = [word2idx.get(w, word2idx['<unk>']) for w in words] all_ids.extend(ids) return all_ids valid_ids = encode_sentences(valid_sentences, word2idx) test_ids = encode_sentences(test_sentences, word2idx)

一句话，test集里的词，能用word2idx查到的就用，查不到的继承者身份，一律给<unk>。

4. 为什么PTB能成为语言模型的标准考场

4.1 小而全的控制变量优势

要说PTB对语言模型研究的贡献，核心就是提供了一套固定词表、固定语料、固定划分的标准评测环境。这在深度学习早期尤其重要，因为算力紧张，谁都不能拿一个几GB的大语料反复试错。

PTB的优势可以概括为三点：

• 规模小、训练快。单卡GPU跑一个标准LSTM，几个小时就到收敛线。即使是新手在CPU上跑，也能在一天内看到完整结果。
• 词表固定，复杂度可控。10000词的词表，在做softmax输出层时开销不大，很多早期模型都能跑得动。
• 数据分布相对干净。因为语料来自同一时期的报纸，风格统一，模型只需专注学习语言规律，不需要处理太多领域跳变。

这种“小”恰恰成为它的标签。以前面的比例来看，PTB大约是887k个token，而WikiText-2有2M个token，WikiText-103有100M以上。所以现在大多数论文在验证模型结构时，还是会先在PTB上跑，快速看趋势，再换到更大数据集上做最终实验。

4.2 它的局限性和被吐槽的点

PTB也不是没有毛病，甚至可以说毛病很突出。

第一，语料来源是上世纪90年代初的华尔街日报。这意味着，今天你拿一个现代模型去建模PTB，它看到的词汇分布和现代英语使用习惯差得很远，很多高科技词汇、网络用语根本没有。这不是模型的问题，而是数据本身已经“过时”了。

第二，预处理把数字全部变成N，导致模型学不到数字之间的数值关系。比如“$N million”和“$N billion”，模型只能通过位置和上下文区分大概语义，完全无法感知数量级。对于强调整数推理的现代NLP任务来说，这显然是个缺陷。

第三，train/valid/test三个文件的分布太接近了。三者都是同一时期的报纸文本，只是文章不同。这意味着模型即使出现了记忆化现象，perplexity依然会很好看。但真实场景中，模型要面对的是分布漂移的文本，PTB无法评测这种泛化能力。

所以现在的做法通常是，PTB当作快速测试平台，真实效果还要去更大的语料以及下游任务上确认。我在实际项目中，PTB只用来验证模型能不能通，最后是否采用，还是看其他数据集的结果。

5. 常见问题与排查经验

5.1 文件下载不到、版本混淆

PTB因为年代久远，原始版本在LDC那里是要付费的。网上流传的免费版本大多来自Mikolov的personal website，或者一些大学课程、GitHub仓库的镜像。

我遇到过的情况是，下载的ptb.train.txt和官方统计的token数对不上，原因就是不同人处理时对句尾标记的处理方式不同。有的人把每句话末尾加了<eos>，有的人没有。有的版本里，句子之间用空行分隔；有的版本没有任何空行。

排查方法很简单：直接统计文件行数、总token数、词汇量，再和目标版本做对比。如果只是略差几千个token，问题通常出在<eos>标记上。要么自己加，要么统一不加，关键保证所有实验一致。

5.2 注意不要在数据清洗时“二次加工”

这一点特别要强调。PTB文本已经做了分词和标准化，你在使用它时，不要再自己写正则去清洗。比如把N恢复成数字、把标点重新合并，这些都是画蛇添足。

我见过有人拿到PTB后，先做了一遍小写化、去标点、去掉<unk>词，结果训练出来的模型根本没法和论文对比。PTB每个预处理步骤的存在都有其原因：N是数字替换，<unk>是低频词统一，标点保留是为了让模型学到语法停顿。改动任何一环，perplexity都会出现系统性偏差。

还有一个小细节：文件里的<unk>和N是两个完全不同概念。N是被替换的数字，它本身就是合法的token；<unk>是词表外的占位符，在你的词表构建之后才会出现。很多人会把这两个搞混，导致词表里多了N，却把N的词频算进未知词统计里。

5.3 评估标准不一致导致结果不可比

用PTB做评估时，perplexity是一个关键指标。但perplexity的计算口径如果不统一，跨论文对比很容易出问题。

主要有两个口径差别：

• 是否计算<unk>的loss。如果某个词不在词表里，被映射到<unk>，模型的预测损失要不要算入困惑度？有的实现算了，有的不算，这会造成perplexity差好几点。
• 是否把句尾<eos>纳入计算。同样，不同实现有不同约定。

在对比实验时，我的习惯是固定一个计算口径，在代码里写清楚，然后在报告结果时把口径一起写上。这样虽然做不到完全还原对方的设置，但至少保证了自己多个实验之间是公平比较的。

6. 个人实操里的一点心得

最后分享一个我从PTB上得到的实打实的经验。

我最早入门语言模型时，用了很大的语料，训练一个LSTM要跑一整天，出问题后很难快速定位是模型bug还是数据处理bug。后来我把所有流程都先在PTB上跑一遍，跑通了再换到大数据集。这个小习惯帮我省了至少一个月的调参时间。

PTB就像一个完美的单元测试：数据规模小到能快速迭代，词表简单到不用考虑太多分布式系统问题。每次写一个新的模型结构，我会先看看它能不能把PTB的perplexity训练到60以下，如果连这个基线都达不到，说明结构或者训练配置肯定有问题，不用急着去大语料上浪费算力。

再分享一个小技巧。如果你只是想做语言模型结构对比，建议把PTB作为第一份评测数据，同时准备一份WikiText-2作为第二份。前者验证“模型是否能工作”，后者验证“模型在大一点的数据上是否还能工作”。两个数据集一起用，比只使用任何一个都更有说服力。

关于PTB能说的内容还有很多，但从使用角度讲，把这些细节处理透，就已经能帮你少踩很多坑了。整个数据集的加载、预处理、训练、评估，现在再回头看一遍，其实并不复杂，麻烦的是那些藏在细节里的隐性约定。希望这篇文章能帮你把PTB的使用门槛降下来，下次拿它做实验时，能够把精力真正花在模型本身。

本文还有配套的精品资源，点击获取