1. 先说说为什么现成的分词器喂不动景区评论景区评论数据做 LDA 建模十个人里有八个卡在同一个地方主题跑出来一堆“景区”“门票”“感觉”“不错”你盯着屏幕看半天愣是不知道这堆主题到底在讲什么。问题往往不在 LDA 本身而在上游的 Jieba 分词——通用词库是为新闻、网页、论坛语料配的它压根不认识“玻璃栈道”“摆渡车”“二次消费”“非遗展演”这些景区场景里的高频实体。我用本地词库优化Jieba 分词、再拿优化后的切分结果去跑景区评论数据的LDA 建模前后主题可读性的差距大到我一度怀疑是不是换了个模型。这篇就把从语料摸底、词库构建、Jieba 加载调参到 LDA 主题收敛的完整链路掰开讲适合手上有几万条评论、想认真做主题分析的数据分析同学也适合刚接触中文 NLP、被分词结果气到过的朋友。先说清楚痛点长什么样。一条典型评论“索道排队两小时坐上去三分钟性价比真的一般不过山顶云海确实值回票价。”Jieba 默认切分会给你“索道/排队/两/小时//坐上/去/三/分钟//性价比/真/的/一般//不过/山顶/云海/确实/值/回/票价”。看上去还行对吧但“索道”和“缆车”在你后续统计里是两回事“值回票价”被拆成“值/回/票价”就彻底丢了口碑属性而“二次消费”这种四个字的行业黑话大概率被切成“二次/消费”主题建模时它在“消费”这个词上跟“门票消费”“餐饮消费”混成一锅粥。这类误差累积到大几千条文档上LDA 的文档-词共现矩阵就已经被污染了主题质量是救不回来的。1.1 通用词库与垂直语料的错位到底在哪Jieba 的核心是一个前缀词典加动态规划求最大概率路径再叠加 HMM 处理未登录词。它的默认词典约六十万条词来源偏通用语料。景区评论这个语料域有几个特别的地方一是专有名词密度高索道、观光车、摆渡车、玻璃栈道、悬崖秋千、溶洞、丹霞、夜游、演艺、讲解器、母婴室、无障碍通道全是长尾实体二是口语化表达集中“人挤人”“排队排到怀疑人生”“拍照很出片”“价格刺客”这类短语的情感信息全在整体上拆开就散了三是评论里混着大量营销话术“必打卡”“绝美”“封神”“冲”这些词高频但几乎不携带真实体验信息。错位的直接后果是切分歧义。举几个我实际调整过的例子“网红打卡地”默认切成“网红/打卡/地”那个“地”单独成词毫无意义还会稀释掉打卡类主题的权重。“亲子游”有时候被切对有时候被切散取决于上下文这种不确定性对 LDA 是致命的——同一个概念在不同文档里以不同粒度出现主题词分布就会撕裂。“二次消费”几乎必被切开而这恰恰是景区运营方最想从评论里挖出来的主题之一。“非遗”单独成词“非遗展演”会被切开导致展演类主题的关键词永远凑不齐。注意不要指望开个 search 模式或者换个分词器就能解决。这类问题本质是词典覆盖率问题不补词库换什么切分算法都是在别人的词典上做无源之水。1.2 LDA 对切分粒度的敏感度被严重低估LDA 是词袋模型它只认“某个词在第 d 篇文档出现了几次”。分词粒度一变词袋就变了。粒度太细特征维度膨胀稀疏性加剧短文本上尤其明显——一条评论只有四十个字切出二十个词其中一半是“的”“很”“了”这种剩下一半还都是碎词模型根本攒不出共现统计。粒度太粗也不行。如果把“索道排队”“门票价格”“酒店服务”都当成独立词等于提前替模型做了主题聚类LDA 就退化成了一张频次表失去了发现隐含主题的意义。所以词库构建有个核心原则补实体不补语义。实体类词景点名、设施名、项目名、地域性表达该补就补抽象概念比如“体验感差”别硬塞成一个词让模型自己去聚合。我做过一个对照实验同一批两万条评论一份用默认词典一份用本地词库其余参数完全一致跑 8 个主题。默认词典那版的 top 词是“景区、门票、感觉、不错、人、去、一个、还、但是、时间”几乎全是高频泛词主题之间区分度极低。补完词库那版能清楚看到“排队/等候/小时/人流/高峰”“索道/缆车/摆渡/运力”“性价比/价格/偏贵/值”“演出/演员/场次/震撼”这样的语义簇。这不是调参调出来的是分词质量换来的。1.3 为什么押注本地词库而不是换模型或上预训练方案选型上其实有几条路可走。第一条是直接上 BERT 之类预训练模型的词向量做主题建模比如 BERTopic效果确实好但有两个现实门槛一是算力长评论批量编码在普通开发机上跑一晚上是常事二是可解释性与可控性业务方要的是“为什么会出这个主题”词库方案每一处改动可追溯、可解释说服成本低得多。第二条是上更好的分词器比如基于深度学习的分词工具通用准确率确实更高但对领域未登录词同样无能为力——它不认识“悬崖秋千”就是不认识模型再大也不行。第三条就是 Jieba 加本地词库成本最低见效最快改哪儿看哪儿。我选第三条还有个很实际的原因词库是资产。这次做完下次换个景区、换个季节的数据词库能复用、能增量迭代而调参调出来的东西换一批数据就废了。这个判断我在后面几个项目里反复验证过词库方案是长期投入产出比最高的那个。2. 本地词库怎么攒从评论里把词一个一个捞出来词库不是拍脑袋列出来的。我见过有人直接拿一份“旅游行业术语表”往里灌两三千条词结果一半以上在语料里一次都没出现过纯属噪声还白白抬高了词典总量。正确做法是让数据自己说话先摸底再机器发现最后人工过筛。2.1 语料摸底先看清手里这批数据是什么形状拿到评论数据的第一件事不是写代码是抽样读。我一般随机抽 200 条从头到尾读一遍边读边记两类东西一类是反复出现的陌生词另一类是切成两半显得别扭的地方。这一步纯手工花不了半小时但能让你对数据的“语言风格”有直觉判断。接着跑基础统计。评论长度分布决定了后面要不要做文档聚合。景区评论有个特点短的很短“不错”“还行”“好评”这种五字评论占比可能到 15%长的能到八百字那种认真写游记的。长度分布严重右偏的时候短评论必须处理否则 LDA 里全是噪声文档。import pandas as pd df pd.read_csv(reviews.csv) df[len] df[content].str.len() print(df[len].describe(percentiles[.1, .25, .5, .75, .9, .99])) # 常见结果中位数 45 字90 分位 210 字99 分位 780 字如果中位数落在 50 字以下就要认真考虑按“景区 月份”或“景区 主题标签”把多条短评论拼接成一篇文档。LDA 在百字以下的文档上表现很差这是常识别硬扛。清洗环节要做的事很朴素去 HTML 标签、去 URL、去表情符号、统一全半角、繁转简。这里有个细节容易被跳过——错别字和网络缩写归一化。“绝绝子”“yyds”“笑不活了”这类要单独建一张映射表“值回票价”和“值会票价”“植回票价”这种要归到同一个规范形。归一化做不做直接影响后面词频统计的可信度。2.2 新词发现的三个筛子频次、凝固度、自由度手工记不完所有词得上算法辅助。中文新词发现有一套很成熟的统计方法核心是三个指标。第一个筛子是频次。出现次数太少的候选词直接扔掉一般设个下限比如在全部语料里出现 5 次以上。这一步能砍掉 90% 的噪声。第二个筛子是凝固度内部凝聚度。判断一个字串是不是“粘”在一起的用点间互信息。逻辑是如果“玻璃”和“栈道”各自独立出现得多但它们俩一起出现的次数远超随机组合的期望说明它们是一个整体。import math from collections import Counter def ngram_counter(docs, n_min2, n_max6): cnt Counter() for doc in docs: for n in range(n_min, n_max 1): for i in range(len(doc) - n 1): cnt[doc[i:in]] 1 return cnt def pmi_score(word, cnt, total): 取最小的切分点算凝固度切法遍历所有二分 scores [] for i in range(1, len(word)): left, right word[:i], word[i:] if cnt[left] 2 or cnt[right] 2: continue p_ab cnt[word] / total p_a cnt[left] / total p_b cnt[right] / total scores.append(math.log(p_ab / (p_a * p_b) 1e-12)) return min(scores) if scores else 0.0经验阈值凝固度取各切分点的最小值大于 4 到 5 就可以进候选池。注意一定要取最小值而不是平均值——“玻璃栈道”整体是粘的但“玻璃”和“栈道”之间粘不代表“玻”和“璃栈道”之间也粘取最小才能保证每一段都成立。第三个筛子是自由度左右邻接熵。判断这个词在语料里能不能“自由活动”。如果“玻璃栈道”前面永远跟着“去”后面永远跟着“玩”那它可能只是某个固定句式的一部分不是独立词。计算方法看它的左右邻字有多丰富。def neighbor_entropy(word, docs): left, right Counter(), Counter() for doc in docs: start 0 while True: idx doc.find(word, start) if idx -1: break left[doc[idx-1] if idx 0 else S] 1 end idx len(word) right[doc[end] if end len(doc) else E] 1 start idx 1 result [] for c in (left, right): total sum(c.values()) if total 0: result.append(0.0) continue h -sum((v/total) * math.log(v/total) for v in c.values() if v 0) result.append(h) return result # [左熵, 右熵]左右熵都大于 0.8 左右说明这个词左右搭配足够丰富。把三个筛子串起来候选项从几千个收敛到几百个这个规模人工过一遍完全可行。提示别忘了用 Jieba 自带的jieba.analyse.extract_tags作为交叉验证。它基于 TF-IDF 抽关键词抽出来的高权重词和新词发现结果取交集可靠度会高很多。两边都命中的词基本可以直接进词库。2.3 词库分级与词频赋值这一步决定了切分稳定性候选词捞出来人工过筛时我会分成三档这决定了后面给多少词频。分级判定标准词频建议举例类型A 级强实体专有名词、设施名、项目名不能被切开2000 - 5000玻璃栈道、悬崖秋千、摆渡车、讲解器B 级弱实体行业惯用语、组合短语切开会影响语义800 - 2000二次消费、亲子游、夜游经济、旺季客诉C 级口语表达网络热词、评价性短语整体承载情感300 - 800值回票价、人挤人、拍照出片、价格刺客分级的意义在于控制副作用。词频给得越高这个词在最大概率路径里的权重越大切分时越“霸道”。A 级词需要霸道因为一旦被切开就是硬伤C 级词给太高的词频则会误伤比如“人挤人”词频给到 5000那“三人挤人”这种奇怪组合也可能被整体识别。所以分级是一个保险机制。人工过筛时有个陷阱要提别把带情感倾向的整句塞进去。有人喜欢把“服务态度差”“卫生条件不好”整条作为词想着这样主题更清晰。问题是这类表达变体太多“服务态度差”“服务态度很差”“服务态度太差”你要列多少条而且一旦塞进去LDA 就不再是“发现主题”而是“统计你预定义好的标签”。这是把主题模型当分类模型用的典型误用。2.4 停用词表要反向定制别直接抄一份通用的停用词这块通用的哈工大表、百度表拿来直接用会出两个问题。一是漏杀景区评论里“景区”“景点”这种词极度高频但信息量为零通用表里没有必须自己加。二是误杀“上”“下”“高处”“第一”这类字眼在通用表里常被当停用词但在景区语境里可能是有效信息“第一峰”“下山”“上山路线”一刀切掉就亏了。我的做法是建两张表一张是硬停用词语气词、代词、连词、纯数字、单个英文字母一张是“条件停用词”——只有在特定上下文里才停用。第二张表实现起来麻烦实际我一般简化处理先把候选词按文档频率排序取文档频率超过 70% 的那批词人工扫一遍逐个决定留还是扔。一个反直觉的观察别急着把“不错”“推荐”“满意”这类词停掉。它们在情感分析里没区分度但在 LDA 里是有用的——它们能把“整体满意度”这个主题撑起来让你知道有一批人在夸服务、有一批人在夸风景。真正该停的是那些在各主题间均匀分布的纯功能词。3. 把词库灌进 Jieba加载方式和参数都得较真词库准备好了接下来是怎么喂。Jieba 提供三种路径很多人随手用第一种结果在批量处理时踩坑。3.1 三种加载路径的差异与适用场景方式接口生效范围适用场景主要坑用户词典文件jieba.load_userdict(path)全局进程级一次性批量处理格式要求严格编码必须是 UTF-8单词添加jieba.add_word(w, freq, tag)全局进程级补少量词或线上热更新重复调用会累加词频强制成词jieba.suggest_freq(seg, True)全局调整内部词频修正个别切分歧义只影响该词不改变词典结构用户词典文件格式是这样的三列空格分隔第三列可以省略玻璃栈道 3000 n 悬崖秋千 2500 n 二次消费 1800 n 值回票价 500 nz 人挤人 400 nz注意文件编码必须是无 BOM 的 UTF-8。Windows 上另存为 UTF-8 时容易带 BOMJieba 读到第一行前面多个不可见字符那个词就废了而且不会报错静默失效。我第一次踩就是这个问题排查了两小时才发现首词“玻璃栈道”根本没进去。还有一个隐蔽的坑重复加载。如果你在多处调用load_userdict词频是累加的。有的词被加载两次词频翻倍切分行为就变了。建议在初始化处统一加载一次用模块级的 flag 控制。3.2 词频数值怎么给算一遍就清楚了Jieba 的切分是求最大概率路径。假设词典总词频为 T词 w 出现概率是 f(w)/T切分路径得分是路径上所有词的对数概率之和。对“玻璃栈道”这四个字模型比较两条路整体成词log(f(玻璃栈道)/T)切成两词log(f(玻璃)/T) log(f(栈道)/T)要整体成词胜出需要f(玻璃栈道) / T (f(玻璃) / T) × (f(栈道) / T) 即 f(玻璃栈道) f(玻璃) × f(栈道) / T假设 Jieba 默认 T 约 6×10^7f(玻璃) ≈ 2000f(栈道) ≈ 600代入得阈值约 2000×600/6e7 0.02。也就是说只要词频大于 1理论上就能胜出。但实际不能这么卡边因为一是默认词典里的词频是估算值二是 HMM 会插手未登录词三是多条路径得分接近时结果不稳定。所以我给的 2000 到 5000是为了留足安全边际让这条路径的得分明显领先。反过来词频别给太大。给到 10^6 这种量级虽然能保证成词但 T 会被抬高其他所有词的概率被整体压低。如果词库里几百个词都给了夸张词频T 可能涨了百分之几十间接影响其他边界判断。这是个典型的过度拟合词典的问题。保守区间 300 到 5000 就够用了。3.3 分词器封装与批量处理提速默认的jieba.cut是单线程的几万条评论跑起来慢尤其是加载了大词库之后。有两个提速方向一是用jieba.enable_parallel但它依赖多进程且只在 Linux 上稳二是我更推荐的自建批处理函数加lru_cache。import jieba import functools import re jieba.load_userdict(scenic_userdict.txt) STOPWORDS set(w.strip() for w in open(stopwords.txt, encodingutf-8) if w.strip()) PUNCT re.compile(r[\s。、《》…—~·,.!?;:()\[\]{}]) functools.lru_cache(maxsize200000) def cut_one(text): return tuple(t for t in jieba.lcut(text, HMMTrue) if t not in STOPWORDS and not PUNCT.fullmatch(t) and len(t) 1) def tokenize_batch(texts, chunk5000): out [] for i in range(0, len(texts), chunk): out.extend(cut_one(t) for t in texts[i:ichunk]) return outlru_cache在有重复评论的语料上命中率相当高实测能省三成以上时间。注意返回值必须是 tuplelist 不可哈希缓存不生效。关于 HMM 开关默认开着能发现一些未登录词但也可能把该切开的粘一起。我的经验是词库覆盖足够全之后把 HMM 关掉反而更稳定因为切分完全由词典决定结果可复现。但如果你的语料里有大量没法穷举的人名、地名变体还是开着。3.4 切分效果怎么验证别靠肉眼扫验证不能只看“感觉变好了”得有量化手段。我一般做三步。第一步构造一个 100 条左右的金标测试集。挑出那些切分歧义最严重的句子人工标好正确切分然后算准确率。不用太精确能看出前后差异就行。第二步看词表覆盖率的提升。统计本地词库里的每个词在切分结果中作为独立词出现的次数除以它在原始文本中出现的原始次数。这个比值从默认词典的 30% 左右提到 95% 以上就说明词库真的生效了。第三步看碎片词比例。切分后长度为 1 的中文词占比默认词典通常在 35% 到 45%补完词库后能压到 20% 出头。这个指标很直观碎片词少了词袋就干净了。def single_char_ratio(tokenized): total sum(len(d) for d in tokenized) single sum(1 for d in tokenized for t in d if len(t) 1) return single / total4. 从切好的词到 LDA 主题中间还有几道关分词干净了不代表 LDA 就好。中间还有词典构建、极端词过滤、主题数选择三道关每一道都能把前面的努力作废。4.1 词典构建与极端词过滤的尺度用 gensim 建词典关键是filter_extremes的两个参数。no_below控制低于多少篇文档就丢弃no_above控制高于多少比例的文档就丢弃。景区评论数据我一般设no_below3no_above0.6。no_above这个参数要谨慎。设太小比如 0.3会把“景区”“门票”这种真正的高频词全砍掉但有些主题比如“价格”本来就需要这些词撑着设太大比如 0.9那批词又全留着稀释主题。0.5 到 0.7 之间试两三个值比较稳妥。from gensim import corpora from gensim.models import LdaModel, CoherenceModel dictionary corpora.Dictionary(tokenized_docs) dictionary.filter_extremes(no_below3, no_above0.6, keep_n30000) corpus [dictionary.doc2bow(doc) for doc in tokenized_docs]keep_n也别设太狠。词表从三万砍到三千跑得快了但很多低频但极有辨识度的词比如某个特定项目的名字全语料只出现 20 次就没了而这些词恰恰是区分主题的关键。我一般留着两万到三万靠no_below去噪不靠keep_n压缩。提示建完词典后把词典里文档频率最高的 50 个词打出来看一眼。这一步只要十秒但能立刻暴露清洗是否到位。如果前 50 个词里还有“的”“了”“是”说明停用词表漏了。4.2 主题数 K 的确定别拍脑袋K 值的确定是 LDA 最玄学的地方。我用的是“一致性分数扫描 人工解读”双轨。粗筛用u_mass快精选用c_v慢但更准。results [] for k in range(5, 13): lda LdaModel(corpuscorpus, id2worddictionary, num_topicsk, passes20, iterations200, alphaauto, etaauto, random_state42) cm CoherenceModel(modellda, textstokenized_docs, dictionarydictionary, coherencec_v) results.append((k, cm.get_coherence())) for k, s in sorted(results, keylambda x: -x[1])[:3]: print(fK{k} c_v{s:.4f})alphaauto和etaauto建议开着。alpha自动学习文档-主题分布的稀疏度eta自动学习主题-词分布的稀疏度对主题质量提升明显特别是评论这种短文本多的语料。passes设 20 以上iterations设 200别用默认值默认参数在真实语料上基本收敛不充分。我的经验是景区评论数据的合理 K 一般落在 6 到 11 之间。低于 6主题太粗“设施”“服务”“风景”什么都混在一起高于 12主题开始碎裂出现两三个只差几个词的重复主题。最终选 K 不能只看一致性分数还要看 top 词能不能被你用一句话说清楚。说不清楚的主题宁可合并。还有一个提升主题质量的实用技巧按景区或按月份分组建模而不是把所有数据混在一起跑一遍。如果一个产品线覆盖多个类型差异极大的景区山地、古镇、主题乐园混跑出来的主题是“平均脸”什么特征都不突出。分开跑再对比能挖出很多有价值的差异信息。4.3 主题结果的人工解读与命名模型输出的 top 词列表只是原材料命名和解读是人的活。我的做法是每个主题把 top 20 词的权重打出来然后完整读 10 条该主题概率最高的文档读完了再取名。光看词取名很容易跑偏。举个例子top 词里出现“排队、等候、小时、人流、高峰、进园”你可能第一反应叫“排队问题”但读完文档会发现这里面有一半在抱怨入园效率另一半在夸“错峰来完全不用等”两拨情绪截然不同。这时候合理的命名是“客流与入园体验”而不是“排队投诉”。另一个技巧是给主题加上文档占比和情感倾向。同一个主题下正面文档和负面文档各占多少这个信息对业务方来说比主题词本身更有价值。计算方式很简单用主题概率最高的文档配一个现成的情感打分结果做交叉统计就行。5. 常见问题与排查速查5.1 几个我真实踩过的坑第一个坑词加了但没生效。排查顺序是先确认文件编码BOM 问题再确认加载时机必须在 import 分词模块后、分词调用前最后确认有没有别处又调用了load_userdict覆盖。判断是否生效最直接的办法是单独测这个词print(jieba.lcut(我去玻璃栈道了))看输出。第二个坑加了词反而切错别的地方。典型场景是短词污染了长词。比如你加了“栈道”词频给得很高结果“玻璃栈道”反而被切成“玻璃/栈道”。原因是长词的词频不足以压过短词。解决办法是把长词的词频调高到短词的 3 到 5 倍或者用suggest_freq强制。第三个坑LDA 跑出来的主题全是“的”。这不是 LDA 的问题是停用词没清干净。有时候是停用词表里写的是“的”但实际文本里是“地”“得”字形不同有时候是清洗时把标点去了但把空格留下了导致分词把整句当一个词。跑之前一定打一批 sample 出来看。第四个坑主题结果每次跑都不一样。LDA 有随机性random_state必须固定。但固定了随机种子还是不稳定那就是passes和iterations太小没收敛。把passes提到 30iterations提到 300 再试。5.2 问题速查表现象最可能的原因定位方法处理方式主题词全是泛词停用词漏杀 / 极端词过滤太松打印词典 DF 最高的 50 词补停用词调低 no_above主题之间高度重复K 值偏大 / 词库粒度太粗对比各主题 top 词重合度降 K拆解过粗的词短评论聚类效果差文档长度不足看长度分布中位数按景区或月份聚合文档某个主题只有一条评论极端词保留了低频词看该主题的文档频率提高 no_below改词库后结果大变词频给得过大检查词典 T 的总量变化词频回落到合理区间分词切片出现长串清洗没去空格 / 词频异常抽样打印分词结果补清洗规则查异常词频5.3 几条不写在文档里的经验词库别一次加太多。新手容易一口气加两千条加完发现效果还不如不加。原因是大量低频词挤进了词典改变了整体概率分布。我的建议是分三批第一批加 100 到 200 条最关键的实体词跑一遍看效果第二批加行业惯用语第三批加口语表达。每批加完都回归验证一遍。保留一份“基线词库”。做对照实验时永远拿最初那版默认词典的结果做参照别每次只跟前一次比。前一次的结果可能就已经跑偏了跟前一次比会越比越偏。停用词表也需要版本管理。我见过最惨的情况是中途改了停用词表没记录两个月后要复现某个结论怎么也复现不出来。6. 词库是活的资产维护方式决定长期收益词库这东西做完第一个版本只是开始。景区是有季节性、有生命周期的新项目上线会催生新词“XX 光影秀”“夏日泼水节”老项目关停会让一批词变成死词网络流行语也在变。半年不更新的词库覆盖率可能从 95% 掉到 70%。6.1 版本管理和回归测试套件我把词库文件放到版本控制里每次改动都带提交说明写清楚加了什么、为什么加。配套维护两个小工具一个是覆盖率检测脚本拿最近一个月的新评论跑一遍看多少词不在词库中另一个是固定的 200 条金标测试集每次改完词库就跑一遍分数跌了就不合入。覆盖率检测脚本的核心逻辑很朴素对未登录的候选词做频次统计出现次数超过阈值的新词自动进“待评审清单”人工确认后再进词库。这条流水线跑通之后维护成本从“每次大改”变成“每次小补”轻松很多。6.2 增量更新与主题漂移监控真正做长期项目的话建议每个月跑一次主题建模记录每个主题的 top 词和文档占比做成时间序列。主题的 top 词突然换了往往意味着现实世界发生了变化——可能是新项目上线也可能是某次舆情。我遇到过一次某主题的 top 词里突然冒出“维修”“封闭”去查才知道是索道检修了一个月评论自然集中在那里。这种信号如果只跑一次模型是绝对看不到的而恰恰是运营方最想第一时间知道的东西。一个提醒增量更新时如果新评论量不大比如一个月只有几百条别单独建模容易过拟合出噪声主题。正确做法是把它拼到最近一个季度或半年的数据里一起跑保持样本量用同一条流水线出结果这样跨期可比性才有保证。最后分享一个我在多个项目里反复验证过的小结论在景区评论这类垂直短文本语料上词库质量的边际收益远大于调参的边际收益。同样花一天时间调 LDA 的 alpha、eta、passes一致性分数可能从 0.42 提到 0.45而补 100 条关键实体词分数能直接跳到 0.55 以上主题的可用性提升更明显。所以如果你的主题模型现在跑得很别扭别急着换模型、换算法先回去看一眼分词结果里那些被切碎的词——答案大概率就在那里。