TF-IDF在中小规模文本中表现稳定，因其不依赖预训练模型和GPU，仅靠词频与文档分布即可压制停用词、突出区分性词汇，使线性模型收敛快、鲁棒性强；但处理超大规模数据时，fit_transform会因需全量加载文本、构建词汇表及统计文档频次而引发OOM。
TF-IDF 不是“优先选择”的万能解，而是当你要做文本分类、关键词提取或相似度计算，且数据规模在内存可容纳范围内时，它刚好够用、够快、够解释——但一旦文本量超过几 GB，TfidfVectorizer.fit_transform 就会直接 OOM，这时候硬上 TF-IDF 反而是最差选择。
为什么小到中等规模文本里 TF-IDF 表现稳定
它不依赖预训练模型，也不需要 GPU，单靠词频和文档分布就能压制停用词、突出区分性词汇。比如“算法”在科技类文档中 TF 高、IDF 也高，权重自然碾压“的”“是”；而“进球”在体育类里同理。这种机制让逻辑回归、SVM 等线性模型在文本分类任务上收敛快、鲁棒性强。
-
max_df=0.95能筛掉出现在 95% 文档里的通用词，比max_df=1.0节省 30%+ 内存 -
min_df=5过滤只在 1–2 篇文档出现的拼写错误或噪声词 - 禁用
ngram_range=(1, 2)或设max_features=10000，否则二元词组合会让词汇表膨胀数倍
为什么一上大规模就崩：fit_transform 的三重内存陷阱
TfidfVectorizer.fit_transform 不是边读边算，它必须把全部原始文本加载进内存，再做三件事：分词 → 构建完整词汇表 → 统计每个词的文档频次（用于 IDF）→ 最后才生成稀疏矩阵。中间任何一步都可能触发 RSS 暴涨。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 常见报错：
MemoryError，或进程被 Linux OOM killer 杀掉，top显示 Python 进程 RSS 达 20GB+ - 根本原因不是矩阵本身大（稀疏矩阵可压缩），而是构建过程中的 token 缓存、n-gram 展开、临时 Counter 对象全驻留内存
-
vocabulary_字典一旦超过百万级 key，Python dict 开销就非常可观
替代方案不是“不用 TF-IDF”，而是绕过 fit_transform
真要保留 TF-IDF 语义又扛住大规模数据，得拆开底层组件来用：
立即学习“Python免费学习笔记（深入）”；
- 用
CountVectorizer.partial_fit分批累积词频，避免一次性加载全部文本 - 用
HashingVectorizer替代TfidfVectorizer：哈希函数直接映射到固定维度，彻底跳过词汇表构建，配合TfidfTransformer做 IDF 归一化 - 离线分词 + Dask：先用
spaCy或jieba流式处理文本，存成Parquet，再用dask.array.from_array加载稀疏块逐块计算
最容易被忽略的复杂点
IDF 是全局统计量，意味着你不能真正“流式计算” TF-IDF——哪怕用了 partial_fit，最终仍需遍历全部文档才能算准 IDF。所谓“增量”，只是把词频统计分了批；IDF 值必须等所有文档扫完才能确定。这点常被文档误导，以为 partial_fit 后就能实时输出带 IDF 权重的向量，实际不能。
