企业官网建设流程全解析

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_min=2, n_max=6): 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:i+n]] += 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 级词需要霸道，因为一旦被切开就是硬伤；C 级词给太高的词频则会误伤，比如“人挤人”词频给到 5000，那“三人挤人”这种奇怪组合也可能被整体识别。所以分级是一个保险机制。

人工过筛时有个陷阱要提：别把带情感倾向的整句塞进去。有人喜欢把“服务态度差”“卫生条件不好”整条作为词，想着这样主题更清晰。问题是这类表达变体太多，“服务态度差”“服务态度很差”“服务态度太差”你要列多少条？而且一旦塞进去，LDA 就不再是“发现主题”，而是“统计你预定义好的标签”。这是把主题模型当分类模型用的典型误用。

2.4 停用词表要反向定制，别直接抄一份通用的

停用词这块，通用的哈工大表、百度表拿来直接用，会出两个问题。一是漏杀：景区评论里“景区”“景点”这种词极度高频但信息量为零，通用表里没有，必须自己加。二是误杀：“上”“下”“高处”“第一”这类字眼在通用表里常被当停用词，但在景区语境里可能是有效信息（“第一峰”“下山”“上山路线”），一刀切掉就亏了。

我的做法是建两张表：一张是硬停用词（语气词、代词、连词、纯数字、单个英文字母），一张是“条件停用词”——只有在特定上下文里才停用。第二张表实现起来麻烦，实际我一般简化处理：先把候选词按文档频率排序，取文档频率超过 70% 的那批词人工扫一遍，逐个决定留还是扔。

一个反直觉的观察：别急着把“不错”“推荐”“满意”这类词停掉。它们在情感分析里没区分度，但在 LDA 里是有用的——它们能把“整体满意度”这个主题撑起来，让你知道有一批人在夸服务、有一批人在夸风景。真正该停的是那些在各主题间均匀分布的纯功能词。

3. 把词库灌进 Jieba，加载方式和参数都得较真

词库准备好了，接下来是怎么喂。Jieba 提供三种路径，很多人随手用第一种，结果在批量处理时踩坑。

3.1 三种加载路径的差异与适用场景

用户词典文件格式是这样的，三列，空格分隔，第三列可以省略：

玻璃栈道 3000 n 悬崖秋千 2500 n 二次消费 1800 n 值回票价 500 nz 人挤人 400 nz

注意：文件编码必须是无 BOM 的 UTF-8。Windows 上另存为 UTF-8 时容易带 BOM，Jieba 读到第一行前面多个不可见字符，那个词就废了，而且不会报错，静默失效。我第一次踩就是这个问题，排查了两小时才发现首词“玻璃栈道”根本没进去。

还有一个隐蔽的坑：重复加载。如果你在多处调用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^7，f(玻璃) ≈ 2000，f(栈道) ≈ 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", encoding="utf-8") if w.strip()) PUNCT = re.compile(r"[\s，。！？、；：""''（）《》…—~·,.!?;:()\[\]{}]") @functools.lru_cache(maxsize=200000) def cut_one(text): return tuple(t for t in jieba.lcut(text, HMM=True) if t not in STOPWORDS and not PUNCT.fullmatch(t) and len(t) > 1) def tokenize_batch(texts, chunk=5000): out = [] for i in range(0, len(texts), chunk): out.extend(cut_one(t) for t in texts[i:i+chunk]) return out

lru_cache在有重复评论的语料上命中率相当高，实测能省三成以上时间。注意返回值必须是 tuple，list 不可哈希，缓存不生效。

关于 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 / total

4. 从切好的词到 LDA 主题，中间还有几道关

分词干净了，不代表 LDA 就好。中间还有词典构建、极端词过滤、主题数选择三道关，每一道都能把前面的努力作废。

4.1 词典构建与极端词过滤的尺度

用 gensim 建词典，关键是filter_extremes的两个参数。no_below控制低于多少篇文档就丢弃，no_above控制高于多少比例的文档就丢弃。景区评论数据我一般设no_below=3，no_above=0.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_below=3, no_above=0.6, keep_n=30000) 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(corpus=corpus, id2word=dictionary, num_topics=k, passes=20, iterations=200, alpha="auto", eta="auto", random_state=42) cm = CoherenceModel(model=lda, texts=tokenized_docs, dictionary=dictionary, coherence="c_v") results.append((k, cm.get_coherence())) for k, s in sorted(results, key=lambda x: -x[1])[:3]: print(f"K={k} c_v={s:.4f}")

alpha="auto"和eta="auto"建议开着。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提到 30，iterations提到 300 再试。

5.2 问题速查表

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 以上，主题的可用性提升更明显。所以如果你的主题模型现在跑得很别扭，别急着换模型、换算法，先回去看一眼分词结果里那些被切碎的词——答案大概率就在那里。