从社区帖子到话题图谱：ModelArts 上的小数据 NLP 实战与避坑记录

运营同学甩给我一个 Excel，两万一千多条华为开发者社区的帖子，字段是标题、正文、板块、回复数、时间。她的问题很直接：“能不能看出来大家最近到底在纠结什么？哪些是吐槽，哪些是真求助？”

我第一反应是把数据丢给大模型让它总结。但两万条全塞进上下文不现实，而且运营要的不是一段话，是一个每周能跑一次、出结构化标签的东西——这周吐槽集中在哪，下周是不是换了一批人骂另外的事。于是决定在 ModelArts 上搭一条小流水线：用预训练模型抽 embedding，做话题聚类，再训一个轻量分类器打情感标签。

任务本身不复杂，本地一台带卡的机器一下午也能跑完。但既然要每周复跑、数据也在 OBS 上，放云上跑定时作业更省事。真正花时间的不是建模，是云平台那些没写进快速入门文档的默认行为——它们让我多付了一个晚上的 GPU 钱，外加两个半天的排查。这篇文章记一下全过程，重点放在坑和填法上，给同样想在 ModelArts 上跑小数据 NLP 的人省点时间。

一、先说清楚数据和目标

数据长这样：

正文里有大量 <div class="cke-article"> 之类的富文本标签，得先清掉。还有一类帖子正文几乎为空，信息全在标题里，这类要保留但不能拿正文当主特征。

目标拆成两块：

1. 话题聚类——把两万条帖子按语义聚成几十个簇，看每个簇的代表词和帖子量，回答"最近集中讨论什么"。
2. 情感打标——每条帖子判一下是"吐槽/求助/分享/中性"。运营特别强调要区分吐槽和求助，因为前者是情绪，后者是要排的工单。

为什么不上大模型直接做这两件事？成本是一方面，两万条过一遍 API 也要点钱；更主要是可复现和稳定性。聚类这种事用 embedding + KMeans 每次跑结果可复现，大模型生成式总结每次都不一样，运营没法对齐"这周和上周比，哪个话题涨了"。情感那块倒是试过 zero-shot prompt，效果后面说。

二、环境：Notebook 里装包，装了个寂寞

我一开始的思路是开个 ModelArts Notebook，在里头交互式地把整条链路跑通，再固化成训练作业。Notebook 用来探索是对的，但第一个坑就栽在这。

坑 1：pip 装的包，重启就没了

ModelArts Notebook 给你一个 conda 环境，你在里头 pip install transformers scikit-learn 跑得好好的。关掉实例再开，包没了。

原因是 Notebook 的运行环境盘不是你挂载的那块持久化数据盘，conda 环境在另一块 ephemeral 盘上，实例停了就清掉。官方文档其实提过一句，但在快速入门里被一句"开箱即用"盖过去了。

填法有三个，按推荐度排：

• 最省心：把依赖写进 requirements.txt，放到 OBS，训练作业的"启动命令"里写 pip install -r requirements.txt && python train.py。Notebook 只用来调代码，不承担运行环境职责。
• 次之：conda env export --no-builds > env.yaml 导出到 OBS，下次 conda env create -f env.yaml。但跨版本有时会卡。
• 最不推荐：每次手动 pip install。两万条数据跑一次还行，每周跑谁记得装包。

我最后把 Notebook 降级成"写代码的编辑器"，真正跑训练用训练作业，依赖靠启动命令装。Notebook 实例也换成了 CPU 小规格——只是写代码要什么 GPU。

坑 2：自动停止没开，一晚上扣了不该扣的钱

这个坑纯怪我自己，但值得说，因为身边三个人都踩过。

Notebook 实例有个"自动停止"设置，可以选 1 小时、2 小时、4 小时后自动关。我开实例的时候没注意，改完代码去吃饭，回来又去干别的，GPU 实例就这么空转了一晚上。第二天看账单才反应过来。

后来定了个规矩：开 Notebook 第一件事先把自动停止设成 2 小时，哪怕正在用，超时被关了再开就是，比忘关省钱。训练作业本身跑完就释放，不存在这个问题，所以这也是我后来尽量用训练作业不用 Notebook 的原因之一。

三、特征抽取：预训练模型 + 一个版本对不上的报错

两万条帖子要做语义聚类，得先有个向量表示。直接用 TF-IDF 也行，但社区黑话多，“菊花厂”“踩坑”"填坑"这种 TF-IDF 抓不到语义。我用 bge-small-zh 抽 512 维 embedding，中文效果好、模型小、CPU 都能跑。

坑 3：tokenizer 和 model 版本不匹配

代码不长，但第一次跑就报错：

from transformers import AutoTokenizer, AutoModel
import torch

tokenizer = AutoTokenizer.from_pretrained("BAAI/bge-small-zh-v1.5")
model = AutoModel.from_pretrained("BAAI/bge-small-zh-v1.5")
model.eval()

def embed(texts, batch_size=64):
    vecs = []
    with torch.no_grad():
        for i in range(0, len(texts), batch_size):
            batch = texts[i:i+batch_size]
            enc = tokenizer(batch, padding=True, truncation=True,
                            max_length=128, return_tensors="pt")
            out = model(**enc)
            # bge 用 last_hidden_state 的 mean pooling
            v = out.last_hidden_state.mean(dim=1)
            v = torch.nn.functional.normalize(v, p=2, dim=1)
            vecs.append(v)
    return torch.cat(vecs).numpy()

报错是 vocab size mismatch 之类，tokenizer 加载出来的词表和 model checkpoint 对不上。

根因是 transformers 库版本和模型 checkpoint 不匹配。ModelArts 训练作业的基础镜像里 transformers 版本不是最新的，而 bge-small-zh-v1.5 这个 checkpoint 是后来发布的，用老版本 tokenizer 加载新 checkpoint 就会出问题。

填法：在启动命令里钉死版本，pip install transformers==4.36.2。别用 latest，也别依赖基础镜像自带的。这件事其实是个通用教训——云平台基础镜像里的库版本永远是某个"稳定但可能偏旧"的快照，你用到的预训练模型往往比它新，版本对不上是高频坑。

坑 4：数据在 OBS 上，逐条读慢得让人怀疑人生

训练作业的数据源指定成 OBS 路径，我一开始把两万条帖子存成了 21 个小 JSON 文件扔在 OBS 上，训练时逐个 obsClient.getObject 拉。慢。慢到什么程度——两万条数据光读取就花了二十多分钟，而聚类本身几秒就完了。

ModelArts 训练作业启动时，会把指定的 OBS 数据先同步到训练容器的本地缓存目录（一般是 /home/work/cache/ 或你配的路径），但这个同步是"把整个目录拉下来"，不是"你代码里读一条它去 OBS 拉一条"。我之前误解了这点，在代码里又自己调 OBS SDK 去读，相当于绕过了缓存机制，每次都走网络。

填法：数据在本地先合并成一个 parquet 文件再传 OBS，训练作业把它同步到本地后，用 pandas 一次读进内存。

import pandas as pd

# 数据已在训练容器本地：/home/work/cache/posts.parquet
df = pd.read_parquet("/home/work/cache/posts.parquet")
# 清洗：去 HTML 标签、拼 title+content、过滤空正文
df["text"] = df["title"].fillna("") + " " + df["content"].fillna("")
df["text"] = df["text"].str.replace(r"<[^>]+>", " ", regex=True)
df["text"] = df["text"].str.replace(r"\s+", " ", regex=True).str.strip()
df = df[df["text"].str.len() > 5].reset_index(drop=True)

两万条 parquet 才几 MB，同步加读取加起来不到十秒。和之前二十分钟的差距，全是网络往返的开销。

四、聚类：KMeans 够用，别上来就 BERTopic

embedding 拿到之后聚类。我一开始想用 BERTopic，显得高级。装上跑了下，两万条数据它在那做层次聚类、做 c-TF-IDF 算主题词，调了半天参数。后来冷静想了想——我要的就是把两万条帖子分个几十堆看分布，KMeans 几秒钟的事，主题词我自己从簇内 TF-IDF 提取就行。

小数据场景下，"用更简单的方法"几乎总是对的。BERTopic 解决的是大规模、要自动调簇数、要层次结构的问题，我这两万条数据用它是杀鸡用牛刀，还引入了一堆调参负担。

from sklearn.cluster import KMeans
from sklearn.feature_extraction.text import TfidfVectorizer

# embedding 已算好，shape = (21000, 512)
k = 40  # 簇数，下面说怎么定的
km = KMeans(n_clusters=k, random_state=42, n_init=10)
labels = km.fit_predict(embeddings)

# 每个簇的主题词：簇内文本跑一遍 TF-IDF，取 top 词
df["cluster"] = labels
for c in range(k):
    sub = df[df["cluster"] == c]["text"]
    if len(sub) < 5:
        continue
    tfidf = TfidfVectorizer(max_features=100, ngram_range=(1,2))
    tfidf.fit(sub)
    top_words = tfidf.get_feature_names_out()[:8]
    print(f"簇 {c:2d} ({len(sub):4d}条): {', '.join(top_words)}")

簇数 K 怎么定是个老问题。elbow 画出来在 30 到 50 之间都很平，看不出明显拐点。我最后是跑了 K=30/40/50 三个版本，人工看每个簇的主题词和代表性帖子，K=40 的时候簇的语义最干净——有明确讲 ModelArts 训练报错的、讲鸿蒙 ArkTS 布局的、讲 OBS 权限的，分得开。K=50 开始出现"两个簇其实说的是同一件事"的冗余。这种事靠指标定不了，得人看一眼。

跑完一看分布，不出所料：帖子量最大的几个簇是 ModelArts 训练作业相关、鸿蒙开发环境配置、OBS 上传下载。吐槽密度最高的是"文档示例跑不通"和"报错信息看不懂"这两簇——这俩结论运营拿去挺有用。

五、情感打标：zero-shot 不够，小模型来凑

聚类是没监督的，情感打标得有标签。我先试了 zero-shot prompt，用大模型直接判：

判断这条开发者社区帖子的情感倾向，从 [吐槽, 求助, 分享, 中性] 里选一个：
"{帖子文本}"

效果一般。问题是社区黑话和反讽多——"又踩坑了，文档一如既往地给力（反讽）“这种，大模型判成"分享/正面”。还有"菊花厂"这种代称，模型不一定知道指的是华为，上下文理解有偏差。

zero-shot 在领域语料上就是这么个水平：通用语义它懂，领域黑话和语用它不懂。要准，还是得标一批数据训个小模型。

我标了 800 条，四个类别大致均衡，用 bge-small-zh 冻结 encoder、只训一个四分类头。模型小、数据小，CPU 都能跑，一个 epoch 就收敛。

坑 5：训练作业的日志看不到 print

训练作业提交上去，控制台有日志输出，但我代码里的 print 一条都不显示。训练在跑（GPU 利用率有监控能看到），就是看不到我的进度打印。第一反应是代码没跑到那行，加了一堆 print 排查，还是没有。

根因是 Python 的 stdout 缓冲。训练作业收集日志是按行读 stdout，但 Python 默认行缓冲在非交互模式下不一定实时 flush，大段 print 攒在缓冲区里，作业结束了才一次性倒出来。

填法有两个：

# 方法一：强制无缓冲
import sys
sys.stdout.reconfigure(line_buffering=True)  # Python 3.7+

# 方法二：用 logging，handler 自动 flush
import logging
logging.basicConfig(level=logging.INFO, stream=sys.stdout,
                    format="%(asctime)s %(message)s")
log = logging.getLogger("train")
log.info(f"epoch {e} loss {loss:.4f}")  # 这种能实时看到

更推荐用 logging，不光解决 flush，还带时间戳，事后排查哪个阶段慢很方便。这个坑不是 ModelArts 独有，任何"收集容器 stdout 做日志"的平台都有，但云上排查更痛苦，因为你没法直接 attach 到容器里看。

训完之后情感分布也印证了聚类那步的直觉：吐槽类帖子里，“文档”“示例”"报错"三个词出现频率最高。运营后来把这结论做进了周报，还专门拉了个"文档可用性"的小专项。这条链路的价值到这就闭环了。

六、部署成在线服务：输入输出格式对不上

最后一步是把情感模型部署成在线服务，让运营的前端能调。ModelArts 可以把模型包成推理服务，给个 API endpoint。这步的坑在推理脚本的输入输出契约。

坑 6：handle 函数拿到的 data 不是你以为的 dict

ModelArts 在线服务的推理脚本要实现一个 handle(data, context) 函数。我一开始这么写：

# 错误写法
def handle(data, context):
    text = data["text"]  # ❌ 报 422
    label = model.predict(text)
    return label          # ❌ 返回裸字符串也不行

请求过 API 网关进来，data 是 bytes，不是 dict。得先 json.loads。返回值也得是 JSON 可序列化的结构，不能返回裸字符串或裸 numpy 值。

正确写法：

import json
import numpy as np

def handle(data, context):
    if not data:
        return {"error": "empty"}
    payload = json.loads(data)        # bytes -> dict
    text = payload.get("text", "")
    prob = model.predict_proba([text])[0]  # numpy array
    idx = int(np.argmax(prob))
    return {
        "label": LABELS[idx],
        "confidence": float(prob[idx]),
        "all": {LABELS[i]: float(prob[i]) for i in range(len(LABELS))}
    }

两个容易漏的点：json.loads(data) 而不是直接用 data；返回里 numpy 的 float 要显式 float() 转成 Python 原生类型，否则 json 序列化会报 Object of type float32 is not JSON serializable。这种类型问题本地测不出来——本地你直接调函数，不走 json 那层；上了服务才暴露。

调通之后，前端发 {"text": "又踩坑了文档一如既往给力"}，服务回 {"label": "吐槽", "confidence": 0.91, ...}。反讽这条判对了，因为训练数据里标了类似反讽样本。这是小模型 + 领域标注比 zero-shot 强的地方：你把领域知识塞进了标签里。

七、复盘：哪些做对了，哪些是绕路

回头看，做对的几件事：

• embedding + KMeans 而不是上 BERTopic。两万条数据简单方法就够了，省下的调参时间用来人工看簇心，反而更准。
• 把 Notebook 降级成编辑器，训练走训练作业。环境可复现、不丢包、跑完自动释放，比在 Notebook 里长跑稳得多。
• 情感用小模型 + 领域标注，不用 zero-shot。领域黑话是 zero-shot 的盲区，标 800 条的成本远低于反复调 prompt 的成本。

绕路和浪费的：

• Notebook 忘关那一晚的 GPU 钱，纯低级失误。
• 逐条读 OBS 那次，是因为我没搞清楚训练作业的数据同步机制，想当然地以为要自己调 SDK 读。这块文档其实有写，但藏在"训练作业"章节的某个子页里，快速入门没提。
• transformers 版本那个坑，排查了挺久，因为报错信息不直白。后来养成习惯：用任何预训练模型，先钉死 transformers 版本。

八、几点方法论

把这次实践里零散的经验往上一层提，有几个点我觉得对小数据 + 云平台场景是通用的。

第一，小数据别上重武器。 两万条帖子，TF-IDF 都能跑出个七七八八，embedding + KMeans 已经是"豪华配置"了。我见过太多人一上来就 BERTopic、就 LDA、就大模型生成式聚类，方法本身没错，但调参和工程化的成本远超过它带来的收益，最后项目卡在"方法跑不通"而不是"业务问题没解决"。方法复杂度应该和数据规模、问题难度匹配，不是和你的技术栈先进程度匹配。

第二，云平台省不省钱，取决于你知不知道它的默认行为。 这次花掉的冤枉钱和排查时间，没有一笔、没有一分钟是因为"云平台能力不够"，全是"我不知道它默认怎么处理某件事"——conda 环境不持久、数据同步机制、日志缓冲、实例不自动关。这些信息文档里都有，但都不在快速入门里，而在某个你不会主动去翻的子页。用云平台的学习成本，不在"怎么用"，在"它默认在替你做什么、什么时候不替你做"。

第三，可复现比单次效果好更重要。 运营要的是每周跑一次、能和上周对比的东西。这意味着所有步骤得能脚本化、随机种子得固定、环境得能重建。大模型生成式总结每次结果不一样，看着惊艳，但对"趋势对比"这个需求是废的。选方法的时候，先问"这个方法能不能稳定复跑"，再问"它单次效果多好"。

第四，领域标注的杠杆率很高。 800 条标注，换来反讽和黑话的正确识别，性价比极高。很多人在 zero-shot 效果不好的时候去调 prompt、换更大的模型，方向反了——效果瓶颈往往不在模型容量，在领域知识没进去。标几百条数据的成本，通常远低于把通用模型调到领域可用的成本。

最后给个具体的工程建议：如果你也要在 ModelArts 上跑类似的小数据 NLP 流水线，把 Notebook 当编辑器、把训练作业当运行环境、依赖钉死版本、数据合并成单文件再传 OBS、日志用 logging 不用 print、在线服务的 handle 记得 json.loads 和类型转换。这几条都做到，能省掉我这次踩的大部分坑。