拿到爬虫抓下来的文本，第一个念头是不是直接塞进 HuggingFace 的 pipeline？别急，这一步踩坑的人可不少。很多人以为把原始 HTML 或者带乱码的字符串扔进去就行，结果模型要么报错，要么给出一个莫名其妙的结果。问题出在哪？出在文本预处理上。
常见错误是没做 strip() 和空格归一化。想象一下，文本里带着 \n\n 太差了 这样的换行和多余空格，tokenizer 会把它当成带着特殊字符的 token 来切分，这能不干扰结果吗？更隐蔽的是 Unicode 空格，比如 \u200b，或者广告插入的零宽字符，这些玩意儿会直接触发 tokenization 异常，或者更糟——静默截断，让你连错误提示都看不到。
实战中建议这样处理：
- 用
re.sub(r'[\s\u200b-\u200f\u2028-\u202f]+', ' ', text)把各种空白符统一成空格，再.strip()，干净利落。 - 如果数据来自微博、小红书这类平台，额外过滤一下 emoji，用
emoji.demojize(text)或者正则[\U0001F600-\U0001F64F\U0001F300-\U0001F5FF…]都行。原因很简单，部分中文情感模型没在 emoji 上 fine-tune 过，它们会把这些符号当成噪声，导致误判。 - 单条文本太长怎么办？别硬塞。HuggingFace 默认
max_length=512，超出就静默截断。所以一定要显式设置truncation=True, max_length=512，把控制权握在自己手里。
用 pipeline 还是手动 model.forward()
说到实时分析，很多人第一反应就是用 pipeline，毕竟它封装得好，一行代码就跑起来了。但如果你就这么直接用，默认的 framework='pt' 加上 device='cpu'，那个吞吐量，真的会让人怀疑人生。
反过来，手动调用 model.forward() 看似更底层、更可控，但容易漏掉两个关键点：tokenizer 的 return_tensors='pt' 参数，以及把张量搬到指定设备上的 to(device)。漏了任何一个，都会收获一个 RuntimeError: Expected all tensors to be on the same device，挺让人头疼的。
具体建议：
- 固定设备这事儿，最好在加载模型时就做好：
device = torch.device('cuda' if torch.cuda.is_a vailable() else 'cpu')。别偷懒，后面每次调用都省心。 - 如果非要用
pipeline，那就重写它的初始化，把设备参数传进去：pipe = pipeline('sentiment-analysis', model=model, tokenizer=tokenizer, device=device, return_all_scores=True)。这样至少能保证模型跑在 GPU 上，而不是默认的 CPU。 - 要是你的业务场景对延迟要求高，比如每秒要处理超过 10 条请求，那就别用
pipeline了，改用手动流程。先inputs = tokenizer(texts, truncation=True, padding=True, max_length=512, return_tensors='pt').to(device)，再outputs = model(**inputs)，最后torch.nn.functional.softmax(outputs.logits, dim=-1)拿到概率。这套流程，速度能提升一个量级。
中文情感模型选哪个？别直接用英文 base
拿 distilbert-base-uncased-finetuned-sst-2-english 来分析中文评论，结果大概率会让你怀疑人生——准确率可能连 50% 都不到。不是模型本身差，而是它的词表和预训练语料压根就没见过中文。这就像让一个只会英语的人去读中文诗，能猜对才怪。
HuggingFace 上中文情感专用模型不多，而且命名混乱，选错是常有的事。这里有几个避坑指南：
- 优先选那些明确标注了
Chinese和sentiment的模型。比如uer/roberta-finetuned-jd-binary-chinese，专门针对电商评论，效果不错。或者ckiplab/bert-base-chinese，但需要自己标注数据微调。 - 避开名字带
multilingual的模型，比如bert-base-multilingual-cased。这类模型通常只在 WikiAnn 上训过，对中文短评的泛化能力很差，结果往往不如人意。 - 怎么验证模型好不好用？很简单，拿 5 条真实评论跑一遍，比如“一般”、“还行”、“绝了”、“无语”、“太水了”。看看输出概率是否合理，如果所有结果都集中在 0.5±0.1 这个区间，那基本可以判定这个模型不适合你的场景。
爬虫与模型之间要不要加缓存和批处理
要是每来一条请求就跑一次 tokenizer → model → softmax，GPU 利用率常年趴在 10% 以下，这算不算暴殄天物？当然，全量缓存也不是办法，特别是用 roberta-large 这种大家伙，单条 embedding 就能吃掉 1.5GB 显存，内存很容易溢出。
比较好的做法是：
- 用
queue.Queue(maxsize=100)做一个简易缓冲，攒够 8 到 16 条再统一 forward。tokenizer是支持 batch 输入的，这样速度能提升 3 到 5 倍，性价比很高。 - 缓存只存原始文本和它的时间戳，别去缓存 logits 或 softmax 结果。为什么？因为不同业务场景可能需要不同的阈值，比如“正面”的定义可能是 >0.7，也可能是 >0.8。缓存了结果，反而限制了你后续的灵活性。
- 加个简单的去重机制：对清洗后的文本做
hashlib.md5(text.encode()).hexdigest()[:8]，10 分钟内遇到相同 hash 就跳过推理。这能有效防止爬虫重试风暴带来的无效计算，省点资源。
说到底，真正的卡点往往不在模型加载或 API 调用，而在于 tokenizer 对中文标点和网络用语的切分一致性。举个例子，“yyds”在不同 tokenizer 里，可能是单 token，也可能是 y、y、d、s 四个 token，这直接影响最终的 score。所以，上线前务必拿真实的弹幕或评论样本跑一遍端到端验证，别只测 hello world，那玩意儿不顶用。
