word2vec 中文语料训练全流程：Wiki 数据预处理、jieba 分词与 gensim 实战

简介：面向自然语言处理初学者，这份课程设计资源以维基中文语料为基础，完整演示词向量模型的实践流程。内容覆盖环境准备、数据获取、数据预处理、模型构建与模型测试五个核心环节，适合用于深度学习或 NLP 课程设计、毕业设计参考以及动手入门。压缩包共 8 个文件，以 4 个 Python 脚本为主体，分别承担文本处理、结巴分词、模型训练与词向量匹配等任务；另含设计报告、说明文档和许可证等文件，包体仅 967KB，结构紧凑，便于快速下载与对照学习。目前已有 662 人学习使用。通过源码与设计报告，读者可清晰了解中文语料清洗、分词、词向量训练与相似词匹配的完整实现思路，并能直接复用或修改脚本，迁移到其他中文文本数据集上开展实验。

1. 这份 Wiki 中文语料 word2vec 向量模型课程设计，究竟帮你省掉哪几步

“训练一次 word2vec 很久，但效果玄学”是很多人在深度学习课程设计里的共同感受。这份基于深度学习的 Wiki 中文语料词 word2vec 向量模型课程设计资源，直接给出了一条完整的实操路径：用 Python 从 Wiki dump 语料抽取文字，清洗后分词，再用 gensim 训练词向量，最后用相似度、类比题测试效果。资源里四个脚本加设计报告一字排开，适合想从零把 word2vec 跑通、又不想被原理劝退的入门者、课设党，以及第一次接触中文语料预处理的同学。它不是原理讲义，而是一张可以直接照着复现的施工图。

2. 语料准备：从 Wiki dump 到可训练的短句列表，要过三道闸

很多第一次跑 NLP 课设的同学会忽略一个事实：word2vec 模型的输入不是“文章”，而是“句子列表”。这个词向量资源的第一步1_process.py，干的就是把几 GB 的 Wiki 中文语料压缩包，拆成一行一行的干净文本。这一步如果偷懒，后面分词、训练、测试全跟着跑偏。

2.1 解析 dump：跳过重定向与模板页，只留正文

Wiki 语料的原始形态是一个 bz2 压缩的 XML 文件，路径名通常类似zhwiki-latest-pages-articles.xml.bz2。一个文件里包含标题、正文、编辑记录、模板、重定向跳转等多类内容，直接全文喂给模型没有意义，必须把正文抽取出来。

常见做法是用 Python 内置的xml.etree.ElementTree做流式解析，边读边释放内存。我一般会按page节点为单位处理，提取title和text，再用elem.clear()把处理过的节点从内存中清掉，避免几 GB 文件把内存撑爆。

import bz2 import xml.etree.ElementTree as ET XML_PATH = "zhwiki-latest-pages-articles.xml.bz2" OUT_TXT = "wiki_raw.txt" def extract_text(xml_path=XML_PATH, out_path=OUT_TXT): with bz2.open(xml_path, "rb") as f: with open(out_path, "w", encoding="utf-8") as out: for event, elem in ET.iterparse(f, events=("end",)): if not elem.tag.endswith("page"): continue title_el = elem.find("title") text_el = elem.find("revision/text") if title_el is None or text_el is None or not text_el.text: elem.clear() continue title = title_el.text.strip() text = text_el.text.strip() # 跳过重定向页和命名空间页，这些不是正文内容 if text.startswith("#REDIRECT") or title.startswith( ("Wikipedia:", "Template:", "Category:", "File:", "Help:", "Portal:") ): elem.clear() continue out.write(f"{title}\n{text}\n") elem.clear() if __name__ == "__main__": extract_text()

这里有两个关键点。一是iterparse配合elem.clear()，它不会把整个 XML 树载入内存，适合处理上 GB 的 dump 文件；二是命名空间前缀，不同批次的 dump 文件里命名空间声明可能不同，直接用endswith("page")判断更稳，不用硬编码完整的命名空间字符串。如果你拿到的 XML 结构里title带类似{http://www.mediawiki.org/xml/export-0.10/}title的前缀，用find时会找不到，这时候最简单的方案就是改用正则或字符串匹配去定位<title>和<text>标签，不必纠结在 ElementTree 的命名空间处理上。

2.2 繁简转换：训练之前必须先统一成简体

Wiki 中文语料里简体、繁体混杂，同一篇内容可能是繁体旧版本，也可能是简体新版本。如果不做转换，分词阶段会把“计算机”和“計算機”当成两个完全不同的词，直接造成词表膨胀，训练出来的向量质量也会被稀释。

这个资源对应的常规流程里会用到 OpenCC 库，这是目前最成熟的中文繁简转换工具。我一般只做“繁体转简体”方向的转换，配置用t2s就够了，不需要做s2tw之类的地区性转换。你可以在1_process.py之后单独跑一个转换步骤，也可以把转换逻辑嵌进上一个脚本的文本抽取循环里，总之必须在分词之前完成。

from opencc import OpenCC cc = OpenCC("t2s") # t2s = Traditional Chinese to Simplified Chinese with open("wiki_raw.txt", encoding="utf-8") as f_in: with open("wiki_simple.txt", "w", encoding="utf-8") as f_out: for line in f_in: f_out.write(cc.convert(line))

这段代码的调用成本主要在大文件的行级转换上，OpenCC 对几千万行的文本处理速度还可以，但不要在脚本里反复初始化 OpenCC 实例。如果转换后你发现某个繁体词还是残留下来，通常是因为它不在标准繁体异体字表里，这种情况我一般直接丢进清洗阶段的正则过滤，不值得为它扩展字典。

2.3 清洗与按句落盘：把每篇文章变成可控长度的短句

清洗是整个语料准备阶段最容易被低估的一环。Wiki 正文里带有大量的方括号链接、HTML 标签、模板标记和特殊符号，其中模板标记在 XML 里是以{{...}}形式存在的。我推荐用正则做三层处理：去掉 HTML 标签和模板，把英文数字与中文之间加上分隔，再把剩余的非中文全转成空格。

import re def clean_text(text): text = re.sub(r"<[^>]+>", "", text) # HTML 标签 text = re.sub(r"\{\{.*?\}\}", " ", text, flags=re.S) # 模板标记 text = re.sub(r"[A-Za-z0-9]+", lambda m: f" {m.group(0)} ", text) text = re.sub(r"[^\u4e00-\u9fffA-Za-z0-9]", " ", text) text = re.sub(r"\s+", " ", text).strip() return text

清洗完成后还有个重要动作：把长文章切分成短句。为什么？如果直接把整篇文章作为一行丢给模型，word2vec 的window参数会在一个过大上下文里扫描，词与词之间的共现关系会被无关内容污染。常见做法是按句号、问号、感叹号进行切分，并按最小长度过滤掉空句子和碎片句子。

def split_sentences(paragraph, min_len=10): parts = re.split(r"[。！？；]", paragraph) return [p for p in parts if len(p) >= min_len] with open("wiki_simple.txt", encoding="utf-8") as f_in: with open("wiki_clean.txt", "w", encoding="utf-8") as f_out: for line in f_in: for sent in split_sentences(line): f_out.write(clean_text(sent) + "\n")

这一步输出的是“一行一句话”的纯文本文件，wiki_clean.txt就是下一步分词脚本的输入。4_model_match.py里做相似度测试时，你可能会发现有的词查不到向量，大概率就是这一步把低频词或者被清洗掉的内容过滤掉了。我跑这类资源时习惯在清洗后单独统计一下行数和字节数，做到心里有底，数据量萎缩一半以上属于正常现象，不用担心。

3. jieba 分词与停用词：词向量质量在这里定生死

语料清洗干净只是第一步，中文文本不像英文那样天然按空格分词，而是需要先分词。这个资源里2_jieba_participle.py的作用，就是把wiki_clean.txt里每一行中文短句切成词序列，再以空格连接成新的一行。分词粒度直接决定词表构成，也就间接决定了 word2vec 训练出的词向量分布。

3.1 jieba 的三种模式：为什么训练用精确模式而不是全模式

jieba 提供三种分词模式：精确模式、全模式、搜索引擎模式。很多初学者的误区是觉得全模式“分得全”，结果训练词表里出现大量交叉组合的冗余词，比如“自然语言处理”被同时切成“自然”“自然语言”“语言处理”“处理”，这些碎片会稀释词向量之间的语义区分度。

训练 word2vec 需要的是一份稳定的“词序列”，不是所有可能的切分组合，所以我一般会精确模式逐句切分。精确模式下的lcut返回的是 list，不需要再额外调用list()包裹，速度也远快于jieba.cut配合迭代器的方式。

import jieba text = "深度学习在自然语言处理中的应用越来越广泛。" print(jieba.lcut(text)) # 输出示例：["深度", "学习", "在", "自然语言", "处理", "中的", "应用", "越来越", "广泛", "。"] print(jieba.lcut(text, cut_all=True)) # 全模式输出：["深度", "学习", "自然", "自然语言", "语言", "处理", "中的", "应用", "越来越", "广泛"]

从对比里能看出来，全模式会多出很多冗余片段的候选组合。这些组合会增加词表大小，却不提高语义区分度。分词完成后，还需要处理一个细节：标点符号。虽然 word2vec 对标点不敏感，但标点参与了窗口上下文统计，会导致相邻词的共现关系被打乱，所以我通常会在分词之后顺手把纯标点符号 token 过滤掉。

3.2 停用词表：别全盘照搬，要针对 Wiki 语料单独补

停用词过滤是中文文本处理绕不开的操作，但经典的通用停用词表并不完全适用于 Wiki 语料。Wiki 正文里容易出现一种特殊高频词：结构性的导航词，比如“链接”“编辑”“维基百科”“求助”等。这些词在每篇文档里都会出现，但没有任何实际语义，它们的存在会把词向量的高频干扰放大。

通用停用词表一般是针对新闻语料整理的，里面可能没有这些 Wiki 导航词。我在跑这个资源时，会先用计数器统计一遍词频，把前 50 个高频词扫一眼，再决定向停用词表里加哪些词。

from collections import Counter with open("wiki_seg.txt", encoding="utf-8") as f: counter = Counter() for line in f: counter.update(line.split()) for word, count in counter.most_common(50): print(word, count)

看到“链接”“编辑”这类词出现在高频前列，就要把它们加进停用词表，再重新分词。停用词表不是越大越好，我从不用那种几千行的全量停用词表，因为里面一些词在 wiki 语境下是有用的：

我的习惯是：先用一个最小停用词表，只过滤标点、纯数字、单字虚词，然后再按照词频统计结果，把这个语料里特有的导肮词补进去。这样做词表不至于被过度压缩，也能消除最明显的结构性噪声。

3.3 分词脚本的输出格式：一行一句的约定

2_jieba_participle.py的输出应该保持“一行一个句子的分词结果”，词与词之间用空格隔开。这个格式恰好是 gensim 里LineSentence默认能直接读取的格式，不用额外做转换。我之前见过有同学把分词结果保存成 JSON 数组格式，结果后续训练脚本还得再写一层解析，纯属自己给自己挖坑。

def process_line(line, stopwords): words = [] for w in jieba.lcut(line): if w.strip() and w not in stopwords: words.append(w) return " ".join(words) with open("wiki_clean.txt", encoding="utf-8") as f_in: with open("wiki_seg.txt", "w", encoding="utf-8") as f_out: for line in f_in: seg_line = process_line(line, stopwords) if seg_line: f_out.write(seg_line + "\n")

这里stopwords是提前加载好的集合对象，用set而不是list，因为分词后每个词都要做一次成员判断，集合的哈希查询比列表的线性扫描快得多。如果你要对更大的语料加分词，还可以给jieba.lcut传HMM=True提升识别精度，但训练词向量时我一般关掉 HMM，因为新词识别对向量训练没有本质帮助，只增加不确定性。这一点属于玄学范畴，但我在实践中确实感觉 HMM 开与不开对最终相似度结果的影响不大。

4. 训练 word2vec：gensim 每个参数都有脾气，先看懂再动手

环境没问题、分词也跑完，接下来就是3_train_word2vec_model.py的本职工作。训练阶段的核心不是“把代码跑起来”，而是把sg、vector_size、window、min_count这几个参数跟你的语料规模对应起来。它们在 gensim 里各有各的脾气，调的时候要带着目的去调。

4.1 环境准备：gensim 4.x 与旧脚本的一个关键差异

先说环境。这个资源包里的源码是课程设计方向的写法，代码发布的年代可能比较早，而你现在跑的环境大概率是 gensim 4.x。gensim 4.x 把Word2Vec的参数名从size改成了vector_size，如果你直接运行会报TypeError: __init__() got an unexpected keyword argument 'size'。

pip install gensim jieba opencc-python-reimplemented

装好之后，先跑一个最小验证，确认 gensim 能正常加载：

from gensim.models import Word2Vec print(Word2Vec.__doc__[:500])

如果看到输出里有vector_size字样，说明环境已经是 4.x。此时遇到旧代码里的size=100，直接改成vector_size=100即可。这是我跑这个资源时遇到的第一个坑，也是最容易劝退新手的坑。

4.2 用 LineSentence 读取分词文件

gensim 官方推荐直接用LineSentence读取一行一个句子的文本文件，它会按行惰性加载。这一点对 Wiki 全量语料很重要，因为分词后的文件可能也有几个 GB，一次性全部载入内存会非常吃力。

from gensim.models import Word2Vec from gensim.models.word2vec import LineSentence sentences = LineSentence("wiki_seg.txt") model = Word2Vec( sentences, vector_size=200, window=5, min_count=5, sg=1, negative=10, sample=1e-4, workers=8, epochs=5, )

LineSentence返回的是一个可迭代对象，它不会把所有句子都读进内存，而是每次迭代一行、按空格拆成词列表。这样训练时内存压力小很多，磁盘 IO 反而是瓶颈。如果你的语料不大，也可以直接传入一个 Python list，但全量 Wiki 语料不建议这么做，一个多 G 的句子列表会把内存直接打满。

4.3 核心参数怎么理解

gensim 的 Word2Vec 对外暴露的参数很多，但真正影响结果的是下面这几个，其它参数保持默认问题不大。

这里最容易出错的是min_count。如果你设置成 1，模型会保留大量只出现一两次的噪声词，训练出来的词向量叫好不叫座；如果设置成 20，又会让很多有意义的领域词被过滤掉。课程设计场景下 5 是比较稳妥的值，至少能保证大多数常见实词被保留。

4.4 训练日志与 Command 输入顺序

这个资源包里的cmd.txt记录的应该是命令行执行顺序，README 里大概率也写了。我一般会按照1_process.py → 2_jieba_participle.py → 3_train_word2vec_model.py → 4_model_match.py这个顺序依次执行。

python 1_process.py python 2_jieba_participle.py python 3_train_word2vec_model.py python 4_model_match.py

训练时建议打开 gensim 的日志，不然你会觉得程序卡住了。加两行配置就能在控制台看到每个 epoch 的进度和 loss：

import logging logging.basicConfig(format="%(asctime)s - %(message)s", level=logging.INFO)

训练完成后，保存模型和词向量是两件不同的事。资源里的4_model_match.py如果只加载model.wv，说明保存时只保存了词向量部分；但如果是用来继续做相似度查询，这样够了。如果后面还打算增量训练，就必须用model.save("wiki_word2vec.model")保存完整模型对象，而不是model.wv.save_word2vec_format()。这个区别在避坑章里我会再展开说。

5. 避坑与排查：一版就训崩的五个常见问题

跑通这个资源不难，但如果你刚拿到手就急着运行，大概率会在以下五个地方翻车。我把它们分成了两类：数据和参数层面的高频翻车，以及代码和保存层面的报错，每一处都按现象、原因、解决的顺序写清楚。

5.1 数据与参数层面的高频翻车

1. 现象：most_similar("北京")返回的词跟“北京”毫无关联，甚至出现“的”“了”这类虚词。

原因：清洗阶段没做按句切分，整篇文章作为一行训练，window扫描的上下文跨了大量无关内容；同时停用词表太薄，高频虚词没有被降采样。

解决：退回第 2 章末尾，把整篇正文按句号切分后再清洗。然后在训练参数中确认min_count不低于 5、sample不高于 1e-3。我见过太多同学卡在这一步，根因不是模型参数，而是输入数据的句子粒度有问题。

2. 现象：模型里查不到“中国”，却查得到“中國”。

原因：上一个脚本跳过了繁简转换步骤，或者 OpenCC 只对部分文本做了转换，词表里存在大量繁体和简体并存的形式。

解决：在分词之前对每一行都执行OpenCC("t2s").convert(line)，转换后检查一下输出文本里是否还出现“係”“為”“説”这类高频繁体字。繁简混杂是 Wiki 语料特有的坑，英文语料和新闻语料都不会遇到，不跑一遍很难意识到。

3. 现象：训练时内存占用越来越高，最后进程被系统杀掉。

原因：用list一次性加载全部句子，或者分词结果没有被清洗过滤，词表里塞了大量低频词。

解决：改回LineSentence惰性读取，同时把min_count从 1 提高到 5。这两个改动可以显著降低词汇表大小，内存占用能降一个量级。如果你是拿课程设计用的笔记本在跑全量 Wiki 语料，这一步几乎必须做，否则 16 GB 内存也不够用。

5.2 代码与保存层面的常见报错

4. 现象：运行3_train_word2vec_model.py时报错TypeError: __init__() got an unexpected keyword argument 'size'。

原因：gensim 4.x 中size参数已更名为vector_size，课程设计脚本是按旧版 gensim 写的，直接运行必然报错。

解决：把脚本里Word2Vec(..., size=200, ...)改为vector_size=200。如果脚本里还用了iter参数，也一并改名为epochs。这是 gensim 4.x 升级后最常见的迁移差异，即使换一个新的3_train_word2vec_model.py，也大概率会遇到同样问题。

5. 现象：模型测试脚本可以加载词向量，但报错AttributeError: 'Word2Vec' object has no attribute 'trainables'或者增量训练时报错无法继续训练。

原因：保存时用了model.wv.save_word2vec_format()，只保存了词向量矩阵，没有保存完整模型状态，相当于把模型“砍半”了，后续无法继续训练或做增量更新。

解决：训练完成后用model.save("wiki_word2vec.model")保存完整模型，加载时用Word2Vec.load("wiki_word2vec.model")。如果只是做相似度查询这两种方式都行，但如果你有增量训练计划，就必须保存完整对象。

6. 模型测试与进阶：相似度、类比推理和向量可视化

训练完模型，第4_model_match.py做的事就是验证模型质量。这一步是很多课程设计的加分项，也是判断模型有没有白训的关键。除了 follow 资源里自带的验证脚本，我一般还会加两个操作：类比推理测试和 PCA 可视化。

6.1 相似度与类比推理验证

最基本的验证是查同义词和相似度，判断训练出来的向量空间里语义关系是否成立：

from gensim.models import Word2Vec model = Word2Vec.load("wiki_word2vec.model") print(model.wv.similarity("中国", "北京")) print(model.wv.most_similar("计算机", topn=10)) print(model.wv.most_similar(positive=["中国", "北京"], negative=["上海"], topn=1))

相似度的输出范围大致在 [-1, 1] 之间，值越大代表语义越接近。这里不要奢望“中国-北京+上海”能给出教科书式的精确类比结果，wiki 语料本身是百科性质，很多词之间的类比关系并不像新闻语料那么直观。能跑到 0.5 以上的相似度并返回合理的近义词集合，已经说明模型训练得很不错了。

6.2 用 PCA 看词向量分布

如果想让课程设计答辩更有说服力，可以用 sklearn 的 PCA 把词向量降到二维坐标，再画成散点图。这一步不是必需的，但可视化最能直观展示词向量的聚类效果：

import numpy as np from sklearn.decomposition import PCA import matplotlib.pyplot as plt words = ["中国", "北京", "上海", "美国", "纽约", "计算机", "技术", "互联网"] vecs = np.array([model.wv[w] for w in words]) pca = PCA(n_components=2) result = pca.fit_transform(vecs) plt.figure(figsize=(8, 6)) for i, word in enumerate(words): plt.scatter(result[i, 0], result[i, 1]) plt.annotate(word, xy=(result[i, 0], result[i, 1]), fontsize=14) plt.show()

这个可视化有很多细节值得注意。一是不同运行得到的坐标位置可能完全不对称，因为词向量初始化是随机的，PCA 之后横纵坐标的正负方向没有绝对含义，看相对聚类就好。二是“中国”和“北京”这类语义相近的词无论跑多少次都大概率聚在相近区域，这是验证模型有效性的最直观证据。另外，中文词向量经常出现数字和英文术语扎堆聚类，这在 Wiki 语料里属于正常现象，不代表模型有问题。

进阶一点的做法是增量训练。如果后续想加入某个领域的语料（比如医疗、法律），不需要从头训练，直接用build_vocab(update=True)扩展词表：

new_sentences = LineSentence("domain_seg.txt") model.build_vocab(new_sentences, update=True) model.train(new_sentences, total_examples=model.corpus_count, epochs=3) model.save("wiki_plus_domain.model")

增量训练会同时调整新词和旧词的向量，所以领域语料的规模如果远小于原始语料，旧词向量的语义可能被轻微带偏，训练后要用原语料里的基准词再验证一遍。从那以后我每次做词向量实验都强制走一遍：dump → 清洗 → 繁简 → 切句 → 分词 → 词频审视 → 训练 → 验证，最后一步验证绝不省略，因为训练 loss 降得好不好和相似度结果是否可用，是两码事。希望帮到你。

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