核心要点

  • FastText 把每个词拆成字符级 n-gram（subword），词向量等于该词所有子词向量之和，而 Word2Vec 把词当成不可分割的原子单位。

  • 因为可由子词组合，FastText 能为训练时没见过的未登录词（OOV）生成向量，Word2Vec 对 OOV 只能返回 unk 或报错。

  • 对形态丰富的语言（英语词缀、德语复合词、土耳其语黏着）和拼写变体、错别字更鲁棒，因为共享子词能迁移语义；注意 FastText 的 n-gram 按 Unicode 字符切，中文一个汉字即一个字符、无法利用偏旁部首（要用汉字内部结构需 cw2vec 等笔画/部首模型）。

  • FastText 还内置高效的有监督文本分类模块；代价是子词数量大、模型体积更大、内存占用更高。

标准回答

核心改进：从词到子词（subword）

Word2Vec 把每个词当作一个独立的、不可再分的单位，为词表里每个词学一个向量。FastText 的关键改进是引入字符级 n-gram：先在词两端加边界符（如 <where>），再切成定长字符片段（如 3-6 gram），把这些子词各学一个向量。一个词的最终向量等于它所有子词向量之和，因此 FastText 在词内部建模了形态结构。

能处理未登录词（OOV）

这是最实用的优势。遇到训练时没出现过的新词，Word2Vec 束手无策，只能给一个 unk 向量；FastText 只要能把新词切成已知子词，就能把这些子词向量相加，临时合成一个有意义的向量。对长尾词、新造词、网络用语场景非常关键。

对形态与拼写更鲁棒

对词缀丰富的语言（英语的 -ing/-ed、德语复合词），词根相同的词会共享大量子词，语义自然相近；对拼写变体和错别字（如 misspelling）也能因共享子词而保持稳健。这让低频词也能借助高频子词获得较好表示。

自带文本分类

FastText 还提供一个轻量高效的有监督分类器，用 n-gram 特征 + 层次 softmax，训练和预测都很快，常作为强基线。

适用场景与代价

当语料里 OOV 多、形态复杂、低频词多（社交文本、多语言、形态语言）时优先选 FastText；缺点是子词数量庞大，模型更大、内存占用更高，词表受控且形态简单时 Word2Vec 反而更轻便。

常见误区

⚠️ 常见踩坑

FastText 并不是「全新模型」，它的训练目标仍是 Skip-gram/CBOW，只是把词向量换成子词向量之和，别误以为它换了优化目标；另外它生成的仍是静态词向量，无法像 ELMo/BERT 那样按上下文区分一词多义。

追问

追问 1：FastText 是怎么具体切分子词的？为什么要加边界符？

它先在词首尾加上特殊边界符（例如把 where 写成 ），再按设定的最小/最大长度（常用 3 到 6）滑动切出字符 n-gram，比如 <wh、whe、her、ere、re>，词本身也作为一个特殊 token 保留。加边界符是为了区分「出现在词首/词尾的片段」和「出现在词中间的同样字符」，例如 her 作为独立词与 where 里的 her 含义不同，边界符让二者对应不同子词，避免语义串味。

追问 2：既然 FastText 能处理 OOV，是不是任何场景都该用它替代 Word2Vec？

不一定。FastText 的子词带来的代价是模型体积和内存显著增大，子词哈希桶很占空间。如果任务词表封闭、几乎没有 OOV、且语言形态简单（或已做好分词），Word2Vec 更轻量、加载更快、效果相当。是否上 FastText 取决于 OOV 比例、形态复杂度和资源预算的权衡。

追问 3：FastText 给 OOV 合成向量一定靠谱吗？有什么局限？

不一定靠谱。它合成的是「子词向量之和」，本质是形态层面的拼接，对那些拼写相近但语义无关的词（如 eat 和 eateries 关系尚可，但纯字形巧合的词）可能给出误导性相近向量；对完全由生僻字符或专有名词构成、子词在训练中也罕见的 OOV，合成质量会很差。它解决的是「有没有向量」，不能保证「向量语义正确」。

🔗 相似问题

同一考点的不同问法，面试官可能换着问，一起刷更稳

没找到想看的面试题？把你想看的告诉我们 →

延伸学习

按主题分类的相关资源，便于系统复习

核心术语

查看更多 →