长文摘要忠实度实测：文档越长，模型越容易"编"细节

LLM 摘要质量横评测过 800-3000 字文本上六个模型的综合表现,忠实度只是五个评分维度之一。但真正在生产里踩坑的场景往往不是这类中等长度文本,而是万字级以上的长文档——完整合同、整份财报、几十页的技术文档。当输入长度从几千字涨到一两万字,忠实度不是线性下降,而是在某个长度区间之后明显加速崩坏。这篇文章专门把”忠实度”从综合评分里拆出来,针对长文档单独测,重点看失真模式怎么随长度变化。

一、为什么要把忠实度从”质量”里单独拎出来测

摘要质量的其他维度(简洁度、可读性、覆盖度)出问题,后果是”摘要不够好用”,忠实度出问题的后果是”摘要在撒谎”——读者会基于一个看起来合理、实际上原文根本没这么说的结论做决策。合同摘要把”不可撤销”总结成”可撤销”、财报摘要把”同比下降”总结成”同比增长”,这类错误比”摘要写得啰嗦”严重一个数量级,值得单独衡量、单独对待。

二、测试方法:逐句核对而不是整体打分

综合质量评分常见做法是让人或者另一个模型给摘要打个 1-10 分,这种打分方式对忠实度问题不够敏感——评分者容易被”读起来很通顺、很专业”的摘要唬住,忽略里面一两处关键数字或因果关系被悄悄改写。

更可靠的方法是逐句核对(claim-level verification):

把摘要拆成独立的事实性陈述(claim),每条陈述只包含一个可验证的信息点
对每条陈述,回到原文里找支撑证据
按支撑情况分类打标:
- 完全支持:原文明确包含该信息
- 部分失真:原文有相关内容,但数字/程度/条件被改动
- 无中生有:原文完全没有对应内容,模型编造
- 因果臆造:原文分别提到了 A 和 B,摘要却声称 A 导致了 B,原文没有这层因果表述

def extract_claims(summary_text):
    """将摘要拆分为独立可验证的事实陈述"""
    prompt = f"""将以下摘要拆分为独立的事实性陈述，每条陈述只包含一个可验证信息点，
不要合并多个信息点到一句话里。

摘要：{summary_text}

输出格式：JSON 数组，每个元素是一条陈述。"""
    return call_model(prompt)

def verify_claim(claim, source_text):
    """核对单条陈述是否被原文支持"""
    prompt = f"""判断以下陈述是否被原文内容支持，只根据原文判断，不要用你自己的知识。

原文：{source_text}
陈述：{claim}

输出：完全支持 / 部分失真 / 无中生有 / 因果臆造，并引用原文对应片段作为依据。"""
    return call_model(prompt)

用模型做核对时要注意:核对模型和被测模型最好不是同一个,避免自证清白;核对 prompt 里要明确要求”只根据原文判断”,防止核对模型自己也开始用背景知识”脑补”支持理由。

三、随文档长度变化的三个观察

用同一份长文档(技术方案书,原文约 1.8 万字)截取不同长度区间(2000 字 / 8000 字 / 1.8 万字全文)分别做摘要,再用上面的逐句核对法统计失真比例,可以看到几个规律性的现象:

观察一:短文本几乎不出现”无中生有”。2000 字区间内,模型摘要基本能做到每条陈述都能在原文里找到对应支撑,编造信息的情况很少见——上下文短,模型不需要”取舍”,直接复述关键句就够了。

观察二:中长文本(8000 字左右)开始出现明显的位置偏差。原文开头和结尾部分的信息,摘要覆盖得比较准确;原文中段的信息,即便本身很关键,也容易被摘要忽略或者简化到失真的程度。这和长上下文领域常说的”lost in the middle”现象一致(可以参考长上下文大海捞针测试和长上下文召回率评测里对这个现象的专门测试),摘要任务对这个问题的暴露比单纯的信息检索任务更隐蔽——检索任务答错了会直接”找不到”,摘要任务答错了会生成一句读起来完全合理、但实际上是模型自己”平滑”出来的内容,不细查很难发现。

观察三:万字级长文本,“因果臆造”开始变得显著。原文里分散在不同段落的两个事实,摘要有明显倾向把它们编织成一条因果链——比如原文第 3 段提到”Q2 上线了新功能”,第 15 段提到”Q3 用户量增长”,摘要容易写成”上线新功能带动了用户量增长”,而原文完全没有做这个因果论断,甚至可能存在其他因素。这是长文档摘要里最危险的一类失真,因为读起来逻辑通顺、叙事完整,恰恰是这种”完整感”让人放松了警惕,忘了去核对原文是否真的支持这个因果关系。

四、几类模型的长文档忠实度倾向(定性观察,非精确评分)

不同模型家族在长文档摘要上的失真倾向有一些可复现的定性差异,这里不给具体分数(单次测试的分数波动较大,不构成严谨横评),只描述方向性倾向,供选型参考:

偏保守型:遇到原文信息不足以支撑某个判断时,倾向于用”原文提及”“可能”这类模糊表述,或者干脆不下结论,宁可摘要显得不够”漂亮”,也不臆造因果。这类模型的无中生有和因果臆造比例通常更低,但覆盖度上可能显得不够利落。
偏流畅型:更擅长把分散信息组织成一段读起来连贯、有叙事感的摘要,阅读体验更好,但也更容易在组织过程中不自觉地”补全”原文没有明说的逻辑关系,因果臆造出现频率相对更高。

生产场景如果摘要要直接用于决策(合同审查、财务分析),优先选偏保守倾向的模型,牺牲一点阅读流畅度换忠实度;如果摘要只是给人快速了解大意、后续会有人工复核原文,流畅度优先的模型效率更高。

五、降低长文档摘要幻觉率的实践建议

分段摘要 + 二次整合优于一次性长文本摘要。把长文档按逻辑章节切分,对每段单独生成摘要,再把这些子摘要拼起来做二次整合,比直接把全文塞进一次调用效果更可靠——每次调用面对的上下文更短,不容易触发”lost in the middle”和跨段落的因果臆造。代价是需要多次 API 调用,成本和延迟都会增加,需要按场景权衡。

摘要生成后加一道核查步骤。用前面提到的逐句核对法,对生成的摘要做一次自动核查,把”无中生有”和”因果臆造”的陈述标记出来,人工复核这部分而不是全文重新看一遍,能把复核成本压缩到原来的一小部分。

明确要求模型标注不确定性。在 prompt 里加一条”如果某个信息点原文表述模糊或存在矛盾,请明确标注’原文未明确说明’而不是自行推断”,能有效降低因果臆造的比例——这条指令本身不复杂,但很多摘要 prompt 里完全没有,默认让模型自由发挥。