优先用TextRank；若追求质量且允许GPU推理，则选微调BART。TextRank是无监督图算法，基于句子共现建图并运行PageRank筛选高分句拼接，无需训练和标注，适合新闻等结构化长文本及低延迟API场景。
直接说结论：如果要快速上线、资源有限、文本领域固定（比如新闻/论文/客服对话），优先用 TextRank；如果追求摘要质量、允许 GPU 推理、输入长度不超 1024，选 BART 微调后的生成式模型。
TextRank 快但受限于原文词句复用
它本质是无监督图算法，把句子或词当作节点，共现/相似关系作边，跑 PageRank 算权重后挑高分句子拼接。没训练过程，也不需要标注数据。
- 适合场景：
news、report这类结构清晰、主题集中的长文本；对延迟敏感的 API 服务（单次推理 - 常见错误：直接喂进大段含 Markdown 或 HTML 标签的原始网页文本 →
TextRank会把<p></p>、**当作普通词，打乱语义连贯性；务必先清洗 - 关键参数：句子分割不能只靠
.split('.')，中文得用jieba分句 + 过滤空句；相似度计算若用TF-IDF，注意停用词表必须覆盖领域术语（比如“GPU”在 AI 文档里不该被过滤） - 性能影响：CPU 即可运行，内存占用稳定（O(n²) 句子两两比较，但 n 通常
BART 生成摘要更自然但吃资源也吃数据
它是 encoder-decoder 架构，能重写、压缩、甚至补全信息，输出不是原文子集。但原生 BART-base 在中文上效果一般，必须微调。
- 使用前提：你有至少 500 条「原文→人工摘要」配对数据；显存 ≥ 8GB 才能 batch_size=2 微调
facebook/bart-base - 容易踩的坑：
tokenizer必须用facebook/bart-base对应的，不能混用bert-base-chinese的；输入超长会被截断，且BART对截断位置敏感——建议用truncation='longest_first'而非默认的'only_first' - 推理时别漏掉
decoder_start_token_id：BART 中文微调后，generate()必须显式传decoder_start_token_id=model.config.decoder_start_token_id，否则首字乱码或卡住 - 兼容性注意：Hugging Face
transformers >= 4.30才完整支持 BART 的past_key_values缓存，老版本生成长摘要极慢
别忽略预处理和评估方式的错位
很多人比模型前只喂同样 raw text，结果 TextRank 看似 ROUGE 高，其实是作弊：它输出的句子原文就有，ROUGE 自然匹配好；而 BART 重写后用词不同，ROUGE-1 低但人类觉得更准。
立即学习“Python免费学习笔记（深入）”；
- 公平对比必须统一预处理：都做句切分、去噪、繁简转换；
TextRank输出也需过一遍jieba分词再算 ROUGE，否则和 BART 的 token 匹配维度不一致 - 真正上线时，
TextRank的「可控性」反而是优势：你能手动加规则，比如强制包含含「风险」「警告」的句子；BART黑盒，出错难归因 - 一个常被跳过的细节：BART 微调时若用
label_smoothing=0.1，推理阶段num_beams=4比1更稳，但延迟翻倍——得按业务容忍度权衡
真正麻烦的从来不是选哪个模型，而是当客户扔来一份带表格、公式、代码块的 PDF 技术文档时，TextRank 和 BART 都得先活过解析这关。
