HelloBench: Evaluating Long Text Generation Capabilities of Large Language Models

• arXiv/venue: 2409.16191 (2024-09；代码 Quehry/HelloBench)
• 作者: Haoran Que, Feiyu Duan, Liqun He, Yutao Mou, Wangchunshu Zhou, Jiaheng Liu, Wenge Rong, Zekun Moore Wang, Jian Yang, Ge Zhang, Junran Peng, Zhaoxiang Zhang, Songyang Zhang, Kai Chen 等
• 类型: 长文生成能力评测基准 + 人对齐的分层评估法 HelloEval
• 一句话: 按 Bloom 分类法把长文生成分 5 类任务共 647 样本，实测发现 GPT-4o/Claude-3.5 等几乎写不出超过 4000 词的长文，且越长越重复、越掉质量；配套 HelloEval 与人评相关性 0.32，远超 BLEU/ROUGE（近乎 0 甚至负）。

1. 要解决的问题

LLM 的长文理解（long-context understanding）被研究得很多，但长文生成（long text generation）能力几乎没被系统评过。现实里"写一篇长报告/长故事"是刚需，却缺一个 in-the-wild、开放式的评测基准，也缺一个不靠海量人工就能可靠打分的方法。

2. 方法 / 核心思路

2.1 任务设计：Bloom 分类法驱动的 5 类任务

共 647 样本 / 5 子任务 / 38 子类： - Open-Ended QA：200 样本 - Summarization：100 样本（5 子类 ×20） - Chat：147 样本（15 子类） - Text Completion：~80 样本（3 子类） - Heuristic Text Generation（启发式生成，如续写/命题写作）：~100 样本（5 子类 ×20）

强调 in-the-wild、开放式、需要自然流畅的长回答。

2.2 HelloEval：分层长文评估（核心方法）

用"学习权重的 checklist"把 LLM-as-Judge 校准到人类，分两阶段： - 准备阶段（Preparation）： - 每个任务由标注员对 4–6 个 yes/no checklist 项打分，并给整体质量分。 - 用线性回归拟合各 checklist 项权重：y = w₁x₁ + w₂x₂ + … + wₙxₙ（y=人类整体分，xᵢ=各 checklist 命中）。 - 数据来自 LLaMA-3.1-8B、Qwen-2-7B、Claude-3.5-Sonnet、GPT-4o-Mini 的输出。 - 执行阶段（Execution）： - 用 GPT-4o 作 LLM-Judge 判定各 checklist 项，按学到的权重加权得最终分（分数从 [0,100] 重标到 [-300,100]，放大区分度）。

2.3 长度约束实验

显式设 4 档字数要求：2K / 4K / 8K / 16K 词，考察"能不能按要求写这么长且不崩"。

3. 数据与实验

• 评测 ~30 个主流开源/闭源 LLM（GPT-4o、Claude-3.5-Sonnet、Mistral-Large、Yi-1.5、GLM-4、LongWriter、Suri 等）。
• 同时测隐式长度约束（不明说字数）与显式长度约束（明说 2K/4K/8K/16K）。
• HelloEval 与人评的相关性对比 BLEU/ROUGE-L/METEOR/LLM-Eval/Average-Checklists 等多种方法。

4. 主要发现 / 结果

• ~4000 词天花板（核心结论）：即便多数模型 max_new_tokens 已达 16,384，当前 LLM 依然难以按显式长度要求写出长文；显式约束一旦超过 4K 词，各家分数普遍暴跌（如 GPT-4o-2024-08-06 从基线 47.87 掉到 4K 约束下的 -18.32）。
• 能写长的往往质量崩：
• Claude-3.5-Sonnet 表现最好，8K 约束下约写 5,471 词、得分 18.74。
• LongWriter-GLM4-9B 在 16K 约束下能写到 ~10,010 词，但质量严重退化（-9.78）。
• Suri-I-ORPO 16K 约束下 ~4,405 词但 -216.41（质量崩坏）。
• 多数标准模型在隐式约束下只写 ~1,000–2,000 词。
• 长输入 ≠ 长输出：长上下文增强模型（Yi-1.5-34B-16K、GLM-4-9B-1M）生成质量反而比基座差，平均低 11.23 分——"读得长"和"写得长"存在张力。
• HelloEval 最贴合人评：Spearman（×100）HelloEval = 31.93（p=4.67e-7），远高于 Average-Checklists 25.72、LLM-Eval+Checklists 15.38、LLM-Eval 8.05；而 METEOR 1.64、ROUGE-L -5.61、BLEU -6.76 近乎 0 甚至负相关——传统指标在长文生成上基本失效。

5. 局限

• HelloEval 执行阶段仍依赖 GPT-4o 作裁判，继承其偏置；权重靠有限人标线性回归拟合，跨任务泛化有限。
• 31.93 的相关虽为最高，但绝对值仍属"中等偏低"，长文主观质量评估远未解决。
• 647 样本、38 子类，规模相对有限；重标到 [-300,100] 便于区分但可解释性下降。

6. 对做产品 / 工程的启发

• 别轻信"写 8000 字"的承诺：本文实测多数模型 4000 词后质量断崖，产品若需长文应分段生成 + 段间校验/拼接，而非一次性硬顶长度。
• 传统指标（BLEU/ROUGE）在长文生成上不能用：做质量闸门必须上"checklist + 学权重 + LLM-judge"这类方法，HelloEval 是可直接借鉴的模板。
• 长上下文模型 ≠ 长输出模型：选型时"能读 1M token"不代表"能写好长文"，需单独评生成侧。
• checklist 项 + 线性回归权重的做法，可低成本迁移到自家长文任务，构成可解释的评分卡。

关联

• 与 [[20_writingbench]] 的 length 维度互相印证：两篇都发现"按长度要求写"是硬骨头。
• 长文"重复 / 质量退化"现象与 [[01_lost_in_stories]] 的一致性 bug、[[03_dome]] 关注的长程连贯同源。
• HelloEval 的"checklist + LLM-judge"评审范式与 [[23_story_eval_survey]] 归纳的 LLM-based 生成式评审一脉相承。
• 长文退化的部分成因（多样性坍缩）可参见 [[21_narrative_flattening]]。