简介这是一份基于深度学习的Wiki中文语料Word2Vec词向量模型构建资源包适合自然语言处理入门者及高校课程设计。资源围绕中文语料的获取、预处理、分词、模型训练与匹配测试的完整流程给出可直接运行的Python源码和配套设计报告可帮助读者掌握Word2Vec模型从数据准备到效果验证的基本方法。压缩包共8个文件以4个Python脚本为核心辅以设计报告、说明文档、命令文本及License信息整体约967KB结构紧凑适合快速上手。已有662人学习/下载。内容涵盖环境准备、语料获取、预处理、模型构建和测试五个实践环节既有源码也有报告便于对照学习与二次修改是完成深度学习或自然语言处理课程设计的实用参考。1. 基于深度学习的Wiki中文语料word2vec向量模型它在解决什么问题如果你做过中文文本召回或者情感分类大概率会遇到这个场景用户输入的是模型没见过的说法你想靠词向量兜底。word2vec 训练出的中文词向量把“电脑”和“计算机”这类近义词在向量空间里放得很近下游模型就算没碰到原词也能靠相似度泛化。标题里的 Wiki 中文语料 word2vec 是一套非常经典的中文词向量生产方案Wiki 语料句子规范、同义改写多比直接抓网页干净word2vec 又是浅层网络CPU 上几小时就能跑完一份几 GB 的 dump不需要深度学习 GPU 环境。这套方案适合做检索、聚类、文本特征工程的从业者也适合刚接触词向量的新手拿它当第一个完整落地的中文 NLP 项目。它不是黑匣子语料清洗、参数调整、结果验证都能自己控制。2. zhwiki 中文语料的清洗与分词从 dump 到可训练语料2.1 语料选择与重定向过滤为什么不用通用爬虫语料爬虫拿回来的网页噪声太多正文夹广告、乱码、重复句子word2vec 的训练信号来自上下文共现语料里混一句垃圾词向量就被拉偏一点。Wiki 中文语料每篇文章围绕一个主题展开句子大多是陈述句上下文语义集中训练出来的向量和人的直觉更贴合。要做的是把 wiki 原始 dump 转成纯文本。常见做法是先用 WikiExtractor 把zhwiki-latest-pages-articles.xml.bz2抽取成 JSON 格式一个文档一行。抽出来的结果是一个一个文档对象包含 title 和 text。这里要注意抽取后的目录是分层的直接用 glob 递归读文件最省事不要手工拼路径。import glob import json import os def valid_docs_from_dir(input_dir): for path in glob.glob(os.path.join(input_dir, **, *), recursiveTrue): if not os.path.isfile(path): continue with open(path, r, encodingutf-8) as f: for line in f: if not line.strip(): continue doc json.loads(line) text doc.get(text, ) # 重定向页面只有一行跳转指令对训练没有价值 if text.startswith(#REDIRECT): continue yield doc[title], text这里按行读 JSON 是为了不把整个 dump 塞进内存CPU 机器上尤其重要。#REDIRECT判断放在最前面能省掉后面大量无意义清洗。这个生成器函数是整个预处理的内存底线后续所有清洗都复用它。glob 的递归模式覆盖 WikiExtractor 按日期或文章名分出来的多层目录比手写文件名稳定得多。2.2 清洗流水线去引用、去模板、统一繁简Wiki 文本里真正影响训练的是三类东西引用脚注ref.../ref、信息框模板{{...}}、以及内链[[目标|显示文字]]。引用的网址和日期会把数字灌进分词结果模板会把大量无关属性名带进正文内链如果不处理分词后会出现竖线和方括号碎片。我一般维护一个五步正则清洗函数顺序不能乱import re def clean_wiki_text(raw): # 1. 注释与脚注整体删除避免残留网址和日期碎片 text re.sub(r!--.*?--, , raw, flagsre.S) text re.sub(rref[^]*.*?/ref, , text, flagsre.S) # 2. 模板包含的信息常带竖线属性先用非贪婪把整块去掉 text re.sub(r\{\{[^{}]*\}\}, , text) # 3. 内链只保留竖线后的显示文字 text re.sub(r\[\[[^\[\]]*\|([^\[\]]*)\]\], r\1, text) text re.sub(r\[\[([^\[\]]*)\]\], r\1, text) # 4. 外链、HTTP 与残留 HTML 标签 text re.sub(r(https?://|www\.)\S, , text) text re.sub(r[^], , text) # 5. 去掉表格控制符与连续空白 text text.replace({|, ).replace(|}, ) text re.sub(r\s, , text).strip() return text第 2 步的正则对嵌套模板无能为力但 wiki 信息框的嵌套深度通常只有一层实际跑下来足够。第 3 步把[[目标|显示文本]]保留成显示文本是要保住一句话里的自然语义比如[[北京大学|北大]]始建于1898年最后应该保留“北大始建于1898年”。这个清洗流程对后来做 LLM 知识库抽取的人同样有参考价值很多 RAG 项目卡住的不是向量模型而是源头文本太脏。清洗后要做繁简转换。zhwiki 里繁体和简体内容可能同时存在“程序”和“程式”如果同时进词表词向量训练时会被拆成两个低频向量。我用 OpenCC 统一转简体opencc -i zhwiki_clean.txt -o zhwiki_simplified.txt -c t2s.jsont2s.json表示繁体转简体。转换后最好再抽样看几行确认人名地名没有错转尤其台湾、香港译名OpenCC 对一部分专名会转成大陆说法这在词向量任务里通常可以接受。如果机器上没有 opencc 命令也可以用 Python 的 opencc-python 包接口是一样的正文语料大时命令行的速度更快。2.3 分句与分词给 word2vec 的句子定一个“边界”Wiki 里一篇文章经常一段几百字。word2vec 的窗口是在句子范围内滑动的如果一段话太长语境会被无关主题污染。所以分词之前先按中文标点把文本切成短句每一句作为训练样本里的一条 sentence。import jieba SENT_SPLIT re.compile(r[。!?;]) def segment_and_tokenize(text): sentences [] for chunk in SENT_SPLIT.split(text): if len(chunk) 4: continue tokens jieba.cut(chunk, cut_allFalse) words [w for w in tokens if w.strip()] if len(words) 3: sentences.append( .join(words)) return sentencescut_allFalse是精确模式会按词典做最长匹配比如“中华人民共和国”会被切成完整词而不是拆成“中华/人民/共和国”。分句长度小于 4 的碎片直接丢掉能过滤掉年份、编号这类没有上下文的噪声。词表之外的专名可以准备一个 userdict.txt用jieba.load_userdict(userdict.txt)加载里面有 3D 打印这类长词时分词稳定很多。分词完成以后不要做停用词过滤。word2vec 需要“的、了、在”这类虚词作为句法胶水强行删掉会把“我的电脑”变成“我 电脑”窗口里的共现关系反而被破坏。虚词问题留给模型参数里的 sample 去处理预处理阶段删停用词是最常见的翻车操作。把所有句子按一行一个、空格分隔词的方式写入zhwiki_simplified_seg.txt这个文件就是训练阶段的输入。3. word2vec 里值得较真的参数sg、negative 与 window 怎么定3.1 skip-gram 与 CBOW 的差异以及中文语料为什么默认选 skip-gramword2vec 有两种训练方式CBOW 用上下文预测中心词skip-gram 用中心词预测上下文。这两者不是随便选一个就能跑决定了低频词的表现和训练时间。CBOW 对频繁词更稳训练更快因为同一个中心词的概率被多次平均skip-gram 对低频词更友好因为它把每个词都当一次预测目标等价于给低频词更多曝光机会。wiki 中文语料里不少实体词只出现几次如果选 CBOW这些词会被高频上下文淹没最后学出来的向量跟随机初始化差不多。下游场景首选理由通用中文词向量sg1低频词与罕见词表示更稳大规模语料、追求速度sg0训练更快常用词语义足够下游是文本分类都行分类任务对词向量精度不敏感下游是相似度计算sg1相似度质量更稳定在 word2vec 原始论文的实验里skip-gram 在小语料上也更能打。wiki 中文语料属于中等体量所以我通常直接 sg1。需要注意 skip-gram 的训练时间大约比 CBOW 多 20% 到 50%但 CPU 上这个差距可以接受。如果你在做一个需要频繁迭代参数的 demo可以先 CBOW 跑通流程最后再换 skip-gram 出正式结果。3.2 负采样与下采样word2vec 训练过程里容易被忽略的两个闸门负采样数量的意思是训练每个正例时从全局词频分布里随机抽几个词当作负例。gensim 里对应negative参数默认 5。这个数字太小时常见词没有被充分推开相似度结果里会混入虚词太大时常见词被推得过远语义之间的梯度消失。中文 wiki 这类页面语料我一般用 10。负采样还跟向量维度有关系维度越高需要的负例越多但不要超过 15不然每个 batch 的更新成本明显上升。下采样阈值sample控制高频词被随机丢弃的概率。word2vec 原始做法是词频 t 越高保留概率越低公式为保留概率sqrt(sample/t)sample/t其中 sample 是阈值。默认 1e-3 对英文语料够用但中文里“的、了、在”出现频率极高1e-3 会让它们保留太多窗口里全是虚词共现。我把 sample 设成 1e-4让高频词更狠地被丢弃低频词相对保留更多。这两个参数不是深度学习里那种动辄上百万的 parameter它们影响的是每个训练样本的更新成本以及最终向量空间的干净程度。如果你发现相似度结果里“的”“了”“在”这类词频繁出现第一反应不应该是加停用词表而是把 sample 往下调同时确认 negative 不是太小。3.3 window 与 vector_size两个决定“距离感”的数字窗口大小window决定中心词左右各看多少个词。默认 5 在英文语料上很稳但中文句子信息密度更高修饰结构也更紧我通常从 5 起步。窗口太小比如 2词向量只学到紧邻搭配语义太“实”找不出“北京”和“城市”这种跨词关系窗口太大比如 10同句里无关的词会被当成正例wiki 长句多这个问题会被放大。如果真的要做词义相似度可以把 window 提高到 8但要牺牲一部分语法关系。向量维度vector_size我建议 200而不是越高越好。中文 wiki 清洗后词表通常在几十万到一百万之间200 维已经能表达语义差异。OpenAI 的词向量基准实验里300 维以后准确率增长曲线很平缓。把维度开到 512 或 1024除了占内存还会让低频词在小样本下过拟合。如果你的下游任务是短文本相似度可以 300 维任务本身是文本分类的话200 维足够。word2vec 对硬件的唯一要求是内存向量维度、词表大小和 workers 三者共同决定峰值内存而不是有没有 GPU。4. 用 gensim 跑通 wiki 中文语料的 word2vec 训练脚本4.1 一个可直接改用的训练脚本训练阶段我直接用 gensim 的 Word2Vec它把负采样、下采样和 Hierarchical Softmax 都封装好了比手写 PyTorch 实现稳定得多。下面这个脚本是完整可跑的文件路径改成自己预处理生成的zhwiki_simplified_seg.txt即可。import logging import multiprocessing from gensim.models import Word2Vec from gensim.models.word2vec import LineSentence logging.basicConfig(levellogging.INFO, format%(asctime)s %(message)s) train_file zhwiki_simplified_seg.txt model_file zhwiki_word2vec.model vector_file zhwiki_word2vec.txt # 返回生成器逐行读取不会一次性把全量语料读进内存 sentences LineSentence(train_file) model Word2Vec( sentences, vector_size200, window5, min_count10, sg1, negative10, sample1e-4, workersmultiprocessing.cpu_count() // 2, epochs5, ) model.save(model_file) model.wv.save_word2vec_format(vector_file, binaryFalse) print(vocab size:, len(model.wv))每个参数的作用我按踩过的坑重新排一下优先级。min_count10是词表闸门出现少于 10 次的词直接丢弃wiki 里低频词大多是人名、编号、错字留它们在模型里只会让词表膨胀并让每个低频词学到不可靠的向量。如果发现词表有一百多万不要急着调 min_count先去检查清洗环节是不是把模板里的属性名漏掉了。workers建议取物理核心数的一半超线程机器上multiprocessing.cpu_count()返回逻辑核直接赋给 workers 会导致上下文切换开销大于并行收益。可以在命令行先执行lscpu或grep core id /proc/cpuinfo | sort -u | wc -l拿到物理核数再写死到脚本里。LineSentence在这里是流式读取任何时刻只保留当前行所以内存占用只和词表有关和语料总行数无关。如果已经准备好在内存里的 list也能直接传但我不建议因为 wiki 清洗后文件可能几个 GBlist 会占掉几个 GB 内存CPU 机器很容易因为内存不足被系统杀掉。训练中观察什么第 1 轮 epoch 结束后打开日志应该看到vocab size在合理范围几十万到上百万都正常。如果词表只有几万要么是分词没切好要么是 min_count 设太高如果词表上百万多半是清洗没把模板和引用清干净低频碎片太多。这个阶段宁可重跑预处理也不要直接调参数硬压词表因为垃圾词和正常词混在一起会让后续相似度结果看起来“能跑但不对”。4.2 增量训练与两种导出方式的取舍业务上线后还会继续进来新语料比如每天的用户反馈文本。常见做法是做一个增量训练接口把新语料分词后继续喂给旧模型。注意不要重新初始化而是基于旧模型继续训练new_sentences LineSentence(new_user_feedback.txt) model.build_vocab(new_sentences, updateTrue) model.train(new_sentences, total_examplesmodel.corpus_count, epochs3) model.save(model_file)这段代码里updateTrue是往旧模型的词表里追加新词不传的话会重新清空词表等于把刚刚学到的词向量全部丢掉。total_examples用model.corpus_countgensim 会按这个值估算学习率衰减这一点很容易被忽略。很多人直接用epochs5但忘了给 total_examples导致学习率没有正确衰减新词和旧词的向量尺度对不上增量训练完相似度结果明显变差。导出成文本格式save_word2vec_format(binaryFalse)是给其他框架准备的。PyTorch 或 Paddle 加载预训练向量时通常要求一行一个词格式是“词 空格 数值”。第 4 行的二进制版只适合 gensim 自己加载跨框架用容易踩坑我一般都会同时存两份。model.save保存的是完整模型对象包含训练状态用来后续继续训练文本格式的.txt用来做推理部署。两份文件都有存在意义不要只保留一份。有时候别人给你一个word2vec.bin你用 gensim 加载会报版本不兼容那多半是 C 语言版 word2vec 的格式不是 gensim 的 model 文件转换时要用KeyedVectors.load_word2vec_format单独读。5. word2vec 训练最容易翻车的五个地方现象、根因、后悔药5.1 词表里全是功能词相似度结果没法用现象用most_similar查“中国”返回的结果全是“了”“的”“在”“与”这类虚词看起来像词向量训反了。原因高频虚词在窗口里几乎和所有实词共现负采样不够虚词成了语义中心。另一个成因是分句太碎比如“中国的北京”切成“中国/的/北京”窗口就把“的”和实体绑死。解决先确认sample是否生效把sample1e-4再往下调改成5e-5让高频虚词被丢弃得更狠同时检查分句规则的、了、在不应该成为句子的一部分。注意不要用停用词表直接删虚词否则窗口里的句法关系断裂会带来新的相似度偏差。5.2 简繁并存让同义词被劈成两半现象模型里“程序”和“程式”同时存在且相似度不高“计算机”和“电脑”能接近但“程式”游离在外。原因zhwiki 里有繁体条目清洗时没有统一繁简两个写法在向量空间各自占据一块区域低频的写法因为样本少语义不稳定。解决清洗流水线里必须加 OpenCC 繁转简并且转换要在分词之前。后悔药也有如果模型已经训完可以用model.wv.add_vector手工把“程式”的词向量初始化为“程序”的向量但这样只能补救几个词不如重跑一次预处理。真正上线前拿五十个高频词在词表里查一遍简繁体写法比看整体指标快。5.3 训练中段内存 OOM进程被系统直接杀掉现象CPU 机器跑 word2vec日志停在某个 epoch内存不断上涨最终进程被 kill。原因最常见的是语料没有走 LineSentence而是用list(texts)读进内存或者workers开满每个子进程都复制一份词表和 hashmap。解决把 list 改成生成器代码见第 4 章workers 降到物理核心数的一半。另一个容易被忽略的是vector_size开得太大词表又大几千维度的矩阵会占掉很多内存。对 wiki 这个体量200 维足够512 维就是给自己制造 OOM。5.4 推理阶段 OOV 词太多词向量形同虚设现象训练时词表几十万上线时一个业务句子 20 个词有 8 个不在词表里。原因分词不一致尤其是英文大小写、数字、中英文混杂。训练语料里“AI”和“ai”被分成两个词推理时“AI”查不到数字版式“2024/01/01”和“2024年1月1日”也不一样。解决在分词阶段统一大小写和数字格式把连续数字归一成NUM占位符同时给 jieba 准备 userdict把业务专名提前纳入。如果模型已经冻结就接受 OOV用wv.most_similar做退避策略把不在词表里的词映射到相似词上。这个坑几乎不会在训练时报错只会在下游任务里以“效果差”的形式暴露所以验证词表覆盖率要提前做。5.5 epochs 越多越好词向量在后期反而变形现象把 epochs 从 5 加到 20相似度结果没有变好反而“北京”和“首都”的关联被冲淡。原因word2vec 是浅层模型训练目标是上下文预测多轮迭代会让权重越来越贴近语料的局部统计甚至记住噪声共现。维基百科句子规范信息密度高5 轮已经饱和。解决用验证集观察固定训练集取一小段语料不参与训练每轮结束后在验证集上算most_similar的命中率如果第 7 轮开始命中率下滑就回滚到第 5 轮的 checkpoint。这就是词向量训练的后悔药前提是训练时把每轮的 checkpoint 都存下来。6. 验证词向量的三个手段和一个落地习惯6.1 三个验证手段模型训练完先别急着接下游用三个手段做快速体检。# 1. 相似度抽样 wv model.wv for word in [中国, 北京, 深度学习]: print(word, [w for w, s in wv.most_similar(word, topn10)]) # 2. 词类类比北京 - 中国 日本 东京 result wv.most_similar(positive[北京, 日本], negative[中国]) print(result) # 3. 业务词表覆盖率 with open(business_words.txt, r, encodingutf-8) as f: words [line.strip() for line in f] out_of_vocab [w for w in words if w not in wv] print(OOV率:, len(out_of_vocab) / len(words))相似度抽样看的是语义是否“像人话”词类类比看的是向量空间里的方向关系是否成立OOV 率看的是模型对业务词汇的覆盖。三个都过了再去接下游任务。只跑most_similar很容易被几个热门词骗过去真正上线后才发现专业术语全在词表外。6.2 词向量进入深度学习模型的落地习惯把 word2vec 导出的文本格式向量装进 PyTorch 的 Embedding 层是它和深度学习框架衔接最常见的方式。加载时要跳过第一行的“词表大小 维度”头然后构建 embedding_matrix。import torch pretrained {} with open(zhwiki_word2vec.txt, r, encodingutf-8) as f: next(f) # 跳过文件头的词表数量与维度 for line in f: parts line.rstrip().split() if len(parts) 200: continue pretrained[parts[0]] torch.tensor( list(map(float, parts[1:])), dtypetorch.float32) embedding_matrix torch.nn.init.normal_(torch.empty(len(vocab), 200)) for idx, token in enumerate(vocab): if token in pretrained: embedding_matrix[idx] pretrained[token] embedding torch.nn.Embedding.from_pretrained( embedding_matrix, freezeFalse)这里freezeFalse表示下游训练时会继续微调词向量。我现在的习惯是先微调让模型适应任务如果训练数据很少再改成freezeTrue防止小数据把预训练向量带偏。词向量质量差的时候深度学习模型怎么调参都救不回来词向量质量过关下游只需要少量标注数据就能稳住底线。每次训练完我会先跑一遍上面三个验证再决定要不要进下一步。希望这些参数和踩坑记录能帮到你少走一段我走过的弯路。本文还有配套的精品资源点击获取
