做中文词向量这件事我前后折腾过好几轮最开始也是直接照搬英文教程结果训练出来的模型一查相似词就全是的了是这类东西或者干脆给个词语不在词表中的报错。后来才慢慢摸清楚中文转词向量这件事难点根本不在那行Word2Vec(...)调用上而是在它前后的两件事语料怎么切和参数怎么定。这篇文章我打算把这套流程从头到尾拆一遍——从语料清洗、分词、自定义词典到 word2vec 训练时每个参数到底在动什么、算力该怎么估再到模型存盘、加载、效果验证以及那些文档里不会写、只有自己跑过一次才会撞上的坑。不管你是刚接触 NLP 的新手还是已经能跑通流程但结果总觉得不太对的中级选手应该都能从里面捞到点能直接抄的东西。1. 先想明白中文词向量到底卡在哪一步1.1 英文天然分词中文得先人工切一刀很多人第一次跑 word2vec 都会有种错觉觉得这玩意儿是喂进去文本吐出来向量。英文语境下这个错觉勉强成立因为英文单词之间天然有空格text.split()就能拿到一个还算像样的词序列。中文不是这样今天天气不错这六个字连成一片模型的视角里这就是一个符号它根本不知道里面藏着今天天气不错三个语义单元。所以中文词向量的第一步永远是分词而分词本身就是一个有歧义、有取舍的动作。同一个南京市长江大桥切法不同最后进到词表里的东西就完全不同。这件事的分量我在第一次做的时候就低估了当时拿了一份混合了新闻和论坛回帖的语料用默认词典切完直接训练结果手机这个词的相似词里居然出现了手和机一看就是切碎了。后来加了自定义词典才修好。这件事说明中文词向量的质量上限很大程度上是被分词这一步锁死的后面的模型再怎么调参也救不回来。1.2 词向量本质上是一次共现统计的压缩把 word2vec 当成黑箱容易踩坑我更愿意把它理解成一句话一个词的向量是它在语料里和谁一起出现这件事的压缩表示。训练时模型滑动一个窗口看到咖啡和提神经常挨着就把它们的向量往彼此的方向拉一点看到咖啡和轮胎几乎不共现就推远一点。跑完几轮语义相近、用法相近的词自然就聚到一块去了。理解了这一点很多决策就顺理成章了窗口开多大决定了你捕捉的是句法层面的搭配还是主题层面的关联语料里如果某个领域的内容占比过高词向量就会带着那个领域的偏见低频词如果只出现过两三次它的向量基本是噪声不如丢掉。也正因为如此词向量没有绝对正确的答案只有和你的语料、你的下游任务匹配不匹配。我见过有人拿通用新闻语料训出来的模型去处理垂直领域文本然后抱怨相似度不准这锅其实不在模型身上。2. 环境与语料准备别急着敲训练命令2.1 依赖安装与版本上的几个坑主流的做法是用gensim里的Word2Vec实现分词用jieba。安装本身没什么难度pip install gensim jieba但版本上确实有坑。gensim4.x 之后model.wv.vocab这个属性被移除了改成了model.wv.key_to_index网上大量 3.x 时代的教程代码直接抄过来会报AttributeError。另外size参数改名成了vector_sizeiter改成了epochs这两个是我见过最多的参数写错了但没报错的情况——老参数名如果被当成**kwargs吞掉模型会用默认值训练你以为自己设了 200 维实际跑的是 100 维。提示装完之后先打印一下gensim.__version__然后对着官方文档的版本号看参数名别对着三年前的博客抄。还有个容易被忽略的点是numpy和scipy的版本兼容。gensim对scipy的版本比较敏感某些组合下会在导入阶段就炸掉报一堆cannot import name的错误。我一般会在虚拟环境里装完先python -c import gensim跑一下确认能导入再往下走避免写到一半才发现环境有问题。2.2 语料清洗宁可少不要脏语料这一步我投的时间比调参多得多。原始文本通常长这样夹杂着 HTML 标签、全角半角混排、一堆没人看的页脚、重复转载的同一篇稿子。这些东西进去之后模型照样能训但训出来的是垃圾。我自己的清洗顺序大致是先统一编码成 UTF-8混编码是中文语料的重灾区gbk和utf-8混着来时直接读会报UnicodeDecodeError我一般用errorsignore先兜住再看丢了多少然后去掉 HTML 标签、URL、邮箱这类结构化噪声接着做全半角归一化最后按行切句。一个经验值有效语料在百万词级别以下时词向量的质量会明显不稳定。所谓有效指的是清洗完之后真正有信息量的正文不是原始文件体积。我做过对比10MB 的原始网页抓取内容清洗完可能只剩 1.5MB 正文这个缩水比例很常见估语料量的时候要按清洗后的算。清洗的代码大概长这样import re import unicodedata def clean_line(line: str) - str: line unicodedata.normalize(NFKC, line) # 全角转半角 line re.sub(r[^], , line) # 去 HTML 标签 line re.sub(rhttps?://\S|www\.\S, , line) # 去链接 line re.sub(r\s, , line) # 压缩空白 return line.strip()NFKC归一化这一步挺关键的它会把全角数字、全角标点统一成半角避免和2024被当成两个不同的 token。2.3 分词器选择与自定义词典的正确用法jieba的默认词典覆盖的是通用领域垂直领域基本都要加自定义词典。加词典有两种方式差别很大jieba.add_word(word)临时加一个词适合少量动态补充。jieba.load_userdict(path)加载词典文件一行一个词可以带词频和词性。词典文件的格式是词语 词频 词性词频可以不写。我这里有个实打实的教训词频不写的时候自定义词的权重往往不够遇到有歧义的句子还是会被切碎。比如某个专有名词默认词典里恰好有个更常见的切法你不给词频jieba可能仍然选择它自己的切法。我的做法是给自定义词一个偏高但不离谱的词频比如 1000 到 5000 之间实测下来切分稳定性明显好很多。分词之后还有一步去停用词。这件事争议挺大有人主张全去有人主张不去。我的看法是看下游任务——如果是做通用语义相似度停用词留着会让的了占据大量共现位置稀释有效信号该去但如果是做句法相关的任务某些虚词反而是有用的。我一般会去但保留程度副词和否定词因为不好和好的语义完全相反把不去掉就出事了。3. 训练参数逐个拆每个数字都在改变结果3.1 vector_size 和 window最容易被随手填的两个数vector_size是维度window是上下文窗口。这两个参数几乎所有教程都写 100 和 5然后就没解释。实际上它们都有明确的权衡。维度不是越大越好。维度上去了能表达的语义区分度确实更强但参数量是线性增长的而语料不够时高维空间里全是稀疏的噪声相似度反而更不稳。我的经验区间是语料规模清洗后有效词数建议 vector_size说明100 万以下50 ~ 100维度再高也学不出东西纯浪费100 万 ~ 1000 万100 ~ 200大多数中小项目的舒适区1000 万以上200 ~ 300再往上收益递减明显内存估算这里可以算一笔账。gensim 的 Word2Vec 主要占两块输入向量矩阵syn0大小是词表大小 × vector_size × 4字节float32负采样时还有一块syn1neg同尺寸。假设词表 50 万、维度 200500000 × 200 × 4 400 MB 400 MB × 2 800 MB再加上词频表、索引字典、语料缓冲实际内存占用通常在 1.5 到 2 倍之间。所以 8G 内存的机器跑 50 万词表、200 维是能跑但会很紧张的。这个估算我每次开训前都会在纸上划一遍比训到一半被 OOM 杀掉强。window的含义是看多远。窗口小2~3偏向捕捉句法层面的搭配比如喝后面跟水窗口大8~10偏向捕捉主题层面的关联同领域的词更容易聚到一起。通用场景我一般用 5主题聚类任务会开到 8。3.2 sg、negative、sample决定训练效率和质量的三角sg0是 CBOW用上下文预测中心词sg1是 Skip-gram用中心词预测上下文。选型逻辑很直白Skip-gram 对低频词更友好小语料下效果更好但训练慢CBOW 快高频词表现好低频词容易被淹没。我的默认选择是sg1除非语料大到训练时间不可接受。negative是负采样个数默认 5。小语料可以降到 5 以内3~5大语料可以提到 10~15。这个参数的作用是每次更新只动少量假样本的权重比全量 softmax 快几个数量级。它的值太小会导致梯度信号不足太大会让训练变慢、且对低频词产生偏置。sample是高频词下采样阈值默认1e-3。这个参数我是强烈建议保留的。中文语料里的出现频率可能占到 4% 以上不降采样的话模型把大量算力花在学的的上下文上而这些信息对语义几乎没贡献。降到 1e-3 之后的被保留的概率会大幅下降训练速度和有效性都会提升。这个技巧在文档里经常一笔带过但它对最终效果的影响比我预期的大得多。3.3 min_count、epochs、workers决定训几轮才算完min_count是词频门槛低于这个数的词直接不进词表。默认 5。这个参数决定了词表大小和质量设太低一堆出现一两次的词占据词表它们学出来的向量基本是随机噪声设太高专业术语可能被一刀切掉。我的做法是先统计一下词频分布看看 min_count5 之后词表还剩多少再决定。epochs是遍历语料的轮数默认 5。这里有个常见的误解轮数越多越好。实际上不是。轮数太少欠拟合轮数太多会过拟合到语料的具体表达上泛化变差。我一般会在 5 到 15 之间试用小规模验证集人工标注几十对相似词算个相关系数来定而不是凭感觉。workers是并行线程数。这里有个反直觉的点workers 不是越大越好也不是结果可复现的。多线程训练时不同线程的更新顺序不同最终结果会有细微差异。如果你需要可复现把workers1并且设seed。另外workers建议设成 CPU 核数减一留一个核给系统不然机器会卡到没法干别的。4. 完整训练流程与实操记录4.1 从原始文本到词向量一份可以直接跑的脚本我把整条链路写成一个脚本核心思路是用迭代器流式喂语料而不是一次性把所有句子读进内存。语料大的时候这个差别是致命的。import re import jieba from gensim.models import Word2Vec STOPWORDS set(open(stopwords.txt, encodingutf-8).read().split()) def iter_tokenized(path): with open(path, encodingutf-8, errorsignore) as f: for line in f: line re.sub(r[^], , line).strip() if not line: continue words jieba.lcut(line) tokens [w for w in words if len(w) 1 or re.match(r[a-zA-Z0-9], w)] tokens [w for w in tokens if w not in STOPWORDS] if len(tokens) 3: yield tokens model Word2Vec( sentencesiter_tokenized(corpus.txt), vector_size200, window5, min_count5, sg1, negative5, sample1e-3, epochs10, workers4, seed42, )这里有几个细节值得单独说。len(w) 1 or re.match(...)这个过滤条件的意思是单字词除非是数字或字母否则丢掉。原因是中文单字词大多没有独立语义的了着留着只会污染共现统计而像猫狗这类单字实词在语料里的高频用法通常也有双字形式。这个过滤是经验性的不同语料可以微调。if len(tokens) 3是丢掉过短的句子。一句话只有一两个词窗口都划不开对训练没有正贡献。语料特别大的时候还可以用corpus_file参数直接传文件路径让 gensim 自己处理流式读取省掉 Python 层的迭代开销model Word2Vec(corpus_filecorpus.txt, vector_size200, ...)但这种方式要求文件里每行是一句已经分好词的文本所以得先把分词结果落盘。空间换时间看你的瓶颈在哪。4.2 模型存盘、加载与增量训练训练完之后第一件事是只保存词向量不要保存整个模型。整个模型里包含syn0和syn1neg两块大矩阵体积是词向量的两倍。如果只做相似度查询、下游任务特征提取syn1neg根本用不上。model.wv.save(w2v.kv) # 只存词向量体积小 from gensim.models import KeyedVectors kv KeyedVectors.load(w2v.kv)如果需要以后继续训练再存完整的model.save(w2v.model) model Word2Vec.load(w2v.model)增量训练这事要特别小心。model.build_vocab(new_sentences, updateTrue)之后model.train(...)是可行的但词表里的词和新语料的词会被硬塞进同一个空间如果新语料的领域差异很大老词的向量会被拖偏。我的经验是增量训练适合同领域、新数据的场景跨领域混合训练大概率会把模型训糊。真要做跨领域不如重新训一个。还有个操作上的注意点build_vocab(updateTrue)之后vector_size不能改如果新语料里有大量新词词表会膨胀内存占用跟着涨这一点要提前算好。4.3 效果验证别只看 most_similar很多人验证词向量的方式就是敲一句model.wv.most_similar(手机)看一眼顺不顺眼就完事了。这种方式太主观而且覆盖不了真实问题。我一般会做三层验证。第一层近邻检查。挑十几个不同领域的种子词看近邻列表。重点是看有没有切错的词混进来——如果人工智能的近邻里有人工和智能说明分词就有问题回头改词典。for w in [手机, 股票, 足球, 医生]: print(w, [x[0] for x in model.wv.most_similar(w, topn8)])第二层类比任务。经典的king - man woman ≈ queen。中文上这个效果通常一般因为中文的形态变化少性别、时态这类规则性的语义关系本来就弱。如果类比结果很差不一定是你训坏了可能只是中文语料本身不适合这个任务。model.wv.most_similar(positive[爸爸, 女性], negative[男性], topn5)第三层人工标注对打分。准备 50 到 100 对词人工标上非常相关/一般/不相关三档分数然后用模型的余弦相似度和人工分数算 Spearman 相关系数。这个数字在 0.4 到 0.6 之间算是正常水平低于 0.3 基本说明模型有问题。这套流程麻烦但它是唯一能横向比较不同参数组合的方式。我调参的时候就是靠这个定下来的最终配置。5. 常见问题排查与实战避坑5.1 相似度结果离谱先按顺序排这六个原因这是我被问得最多的一类问题。排查顺序我总结成下面这张表从上往下走基本能定位到根因现象大概率原因处理方式相似词全是单字或碎片分词切碎词典缺词加自定义词典给足词频相似词全是的了是停用词未过滤或 sample 太高过滤停用词sample 设 1e-3相近义原词不聚在一起语料量不足或领域偏差扩语料检查领域覆盖报 KeyError 词不在词表词频低于 min_count 或未分词降 min_count或检查输入分词两次训练结果差异很大未设 seedworkers 多线程固定 seedworkers1 复现向量维度对但数值异常小训练轮数不足提高 epochs加验证集确认这里单独拎一条词不在词表这个报错十有八九不是模型问题是输入没分词。有人直接拿一句话去查相似度模型期望的是词你给的是句子当然找不到。查询前先jieba.lcut一下或者干脆用model.wv.most_similar(positivejieba.lcut(句子))。5.2 内存和耗时几个能救命的实操技巧训到一半内存爆掉是我踩过最多次的坑。几个有效的办法一是训练前先把min_count提上去词表小一圈内存直接省一半二是在iter_tokenized里用生成器别用列表三是如果实在内存紧张把vector_size降到 100训完确认效果可接受再决定要不要升。耗时方面sg1比sg0慢大概 2 到 3 倍negative从 5 提到 15 慢 30% 左右workers的加速不是线性的4 线程大概能到 2.5 倍8 线程大概 4 倍再往上边际收益很低。这些数字是我在不同语料上反复跑出来的大概区间具体机器上会有出入但量级不会差太多。注意训练过程中 gensim 会定期打印进度和当前学习率如果发现进度条长时间不动多半是内存开始换页了这时候赶紧手动中断别硬等硬等的结局通常是系统卡死。还有个小技巧先拿语料的 10% 跑一遍完整流程确认脚本能跑通、参数没写错、输出的相似词大致合理再上全量。全量跑一次可能几十分钟到几小时用 10% 验证一次只要几分钟这个投入回报比极高。5.3 词向量训完了接下来怎么用很多人卡在这一步拿到个.kv文件然后不知道干什么。几个典型的用法。找相似词做关键词扩展。做内容标签、搜索召回的时候用种子词取近邻能捞出一批自己想不到的相关词。这个用法最直接效果也最好验证。做句子向量。最朴素的做法是把句子里所有词的向量取平均。这个方法在短文本上尚可长文本上效果一般因为平均会丢掉词序信息。更好一点的做法是用词频加权平均或者用 SIF 加权词频的倒数加权再减去主成分。我一般先用简单平均跑通链路觉得不够再加权。当特征喂给下游模型。分类、聚类、召回都能用。这里是词向量最朴素也最稳的用法把文本表示成向量矩阵然后接个分类器。缺点是词向量是静态的同一个词在任何上下文里向量都一样苹果手机和苹果好吃里的苹果没有区分。要解决这个得上上下文相关的模型那是另一个话题了。做冷启动的语义去重。用余弦相似度找重复问题、重复标题阈值一般设在 0.85 到 0.92 之间具体值要在自己的数据上校准。这个场景对精度要求不高粗筛之后再人工确认性价比很高。5.4 什么时候该考虑换方案word2vec 不是万能钥匙。有几种情况下我会直接换路子。语料里有大量没登录词、错别字、网络新词。词向量的词表是封闭的训练时没见过的词一律 OOV。这时候可以考虑 fastText 这类引入子词信息的方案它把词拆成字符 n-gram能对未登录词给出一个近似向量。需要区分同一个词在不同上下文里的含义。静态词向量天生做不到得用上下文相关的表示。不过这类方案对算力要求高不少中小项目未必划算。任务本身有成熟的预训练资源可用。大多数通用场景下自己从零训一个通用词向量效果通常比不上直接用一个在海量语料上训好的通用向量。自训的价值主要在于领域适配——垂直领域的术语、黑话通用向量里没有这部分才是自训的护城河。我现在的做法是通用部分用现成的领域术语用自训的小模型补充两套向量拼起来用在检索里比单独用哪一套都稳。最后分享一个我自己踩过的坑有次拿训好的模型去做检索效果忽好忽坏排查了两天才发现是保存的时候用了model.save加载的时候用了KeyedVectors.load两个格式不兼容但没报错读出来的东西是乱的。从那之后我养成一个习惯模型存完立刻重新加载一次跑一句most_similar确认结果和存之前一致再往下用。这个检查只花两分钟能省掉两天的排查。