持续文档创作中的知识拉取请求 Knowledge Pull Requests for Continual Document Authoring
借鉴软件工程Pull Request,把文档持续更新拆成可审查的知识级声明提案与文本diff
前置知识
Pull Request(拉取请求)
软件工程中的协作机制:贡献者不直接修改主干代码,而是提交一份变更提案,由维护者审查、讨论、解决冲突后合并进主干。Git 平台会自动生成代码diff,评审者逐块批准或拒绝。其核心价值是把'改了什么知识'与'文本怎么变'打包成可审查的工件,并保留完整的决策记录,使多人长期协作成为可能。
本文把这一工作流整体迁移到文档知识维护上:KPR 就是文档世界的 PR,ChangeLog 对应代码diff加变更说明,merge conflict 对应知识冲突。不理解这个类比,就无法理解全文的术语体系(提案、审查、合并)与设计动机。
原子声明与去上下文化
原子声明是独立可验证的最小事实陈述,如'火灾发生于2019年4月15日';去上下文化要求声明脱离原文语境仍可独立理解,不能出现'那位船长'这类依赖指代的表述。FActScore、VeriScore 等工作已证明:把文本拆成声明逐条核验,比整句、整段评估更可靠、更可解释,且能跨任务与模态迁移。
KPR 的一切操作——过滤、冲突检测、路由、改写——都以声明为基本单元而非文本段落;不掌握这个概念,就看不懂 claim proposal 到底在提案什么,也理解不了论文'声明优于原始文本'的核心实验结论。
信念修正( revision 与 update 之别)
形式认识论研究如何把新知识并入信念体系。AGM 在逻辑闭包信念集上定义收缩与修正;belief bases 用有限显式语句集;Katsuno-Mendelzon 区分 revision(世界未变,学到更多)与 update(世界变了)。本文维基百科修订属 revision,报告更新属 update。
论文的两个实验正是按这对概念设计的:维基百科场景下世界未变、只是英文条目缺信息;RAGTIME 场景下世界在变、新文档不断出现。理解 revision/update 之别才能明白两个实验的性质与评估方式为何不同。
信息精确率与召回率(MiRAGE)
MiRAGE 把产出与证据分解为原子子声明,用 LLM 判分函数 $s(c,R)\in[0,1]$ 打支持度;InfoP $=\frac{1}{|C_P|}\sum_c s(c,R)$ 衡量产出对来源的忠实度,InfoR 反转算覆盖率,分 InfoR-R(保留)与 InfoR-A(新增)。
论文几乎所有质量结论都建立在这三个指标上;不看懂它们,就无法读懂 Table 2 与 Table 6 中 KPR 领先基线的具体含义,也无法理解'保留'与'新增'这对互相牵制的目标。
查询驱动的报告生成
给定查询与角色设定,RAG 系统检索文档并生成回答报告;RAGTIME 是 TREC 2025 的多语言报告生成任务,以 nugget(原子事实式评估单元)衡量报告内容。其痛点是:新来源出现时只能从头重新生成,旧报告被整体丢弃,浪费算力且丢失已验证内容。
RAGTIME 是论文的第二应用场景。只有理解'每次查询都被重新回答、旧报告即弃'这一现状,才能体会把重新生成改造成增量更新(KPR 把它当作对常设报告的一次修订)有多大价值。
研究动机
大量重要文档永远处于'未完成'状态:维基百科条目、技术文档、情报报告都需要随新知识的出现持续修订,新知识可能来自新来源、其他语言或更晚的时间。现状有两条路线,各有硬伤。第一条是改写:把现有文档和新来源一起喂给语言模型重新生成(如 FRUIT、WiNELL),文本确实被更新了,但系统完全不说明哪些事实被加入、哪些被覆盖——而维基百科这个最典型的持续创作知识库每月有数百万次编辑、志愿评审者有限,他们看到的只是原始词级diff,无法判断一次编辑是在引入新事实、修正过时内容,还是与既有内容冲突。第二条是从头再生成:查询驱动系统(Deep Research 等)在新来源出现时把整条生成流水线对同一查询重跑,旧报告被当作废料丢弃,既浪费算力,也丢掉了原文档已经过的筛选与沉淀。此外,事件、实体、地点在各语言维基百科中的覆盖极不均衡——往往用当地区域语言记录得更详尽、在其他语言中稀疏——英文读者靠搜索引擎根本触达不了只存在于其他语言版本中的知识。
本文的目标是本文的目标是把持续文档创作从'不透明的端到端改写'升级为'可审查的知识级操作'。具体而言,作者希望构建一个名为 Knowledge Pull Request 的结构化流程,产出可审查工件 ChangeLog,把'什么知识变了'(claim proposal:从来源提取的声明提案,标注去往哪个章节、与现有内容是否冲突)与'文本怎么变'(document diff:接受提案后的文本差异)分离开;让人类评审者能像代码评审一样,逐条评估提案声明、裁决被标记的冲突、批准或拒绝变更,之后再合并进主文档;并且在不牺牲既有内容的前提下,把新来源(尤其是其他语言的维基百科版本)中的知识尽可能完整地整合进来。论文在两种设定下验证这一目标:revision——世界未变,从其他语言版本为英文条目补充缺失知识;update——世界在变,让查询驱动报告随新来源不断演进。
与已有工作不同的是,本文的独特切入角度有三点。第一,操作单元的转变:信念修正理论(AGM、belief bases)操作的是形式语句及其逻辑关系,要求信念集在逻辑闭包下包含所有推论,抽象层次太高,缺少承载'这条知识从哪来'的载体;而声明级方法(FActScore、VeriScore、Pyramid 方法)此前只用于评估事实性,从未被用作知识整合的执行单元。KPR 首次把原子、去上下文化的自然语言声明当作变更的原子单位,让每次变更天然携带'这是哪条知识'的语义。第二,工件设计的转变:与端到端改写不同,KPR 显式产出两级工件——知识级提案与文本级diff——使'提案-审查-合并'的人类协作回路成为可能,这正是把软件工程 Pull Request 的核心结构类比移植到文档领域。第三,冲突处理立场的转变:面对来源与主文档的矛盾,KPR 不像改写系统那样静默裁决,而是像 git 合并冲突一样显式标记出来交由人裁决,坦然承认'该相信哪个源'至今仍是开放问题;同时支持评审者推翻过滤决定,保留人的最终控制权。
核心方法
直觉上,KPR 把'拿新资料更新一篇文档'拆成图书编辑的审稿流程:先逐条摘出新资料里的事实,再判断哪些是文档已有的、哪些是新的、哪些与文档矛盾,新事实该放进哪个章节,最后只重写受影响的章节,打包成'提案+diff'的变更包供审查。技术路线是三阶段流水线。阶段一,声明分解:用 LLM 把来源拆成原子、去上下文化的声明;主文档同样分解,但其声明离线分解并缓存为索引;非英语来源直接'跨语言分解'成英文声明而非先翻译再分解,更忠实也省一次调用。阶段二,声明提案:对每个候选声明做四个决策——覆盖性(主文档是否已包含)、冲突性(是否与主文档矛盾)、相关性(是否满足创作标准,如查询相关性或维基百科方针)、路由(该放进哪个章节,必要时提议新章节);覆盖与冲突在同一次分类中解决,标记为 covered/conflicting/absent,冲突声明像合并冲突一样被显式标记供审查。阶段三,文档diff:按提案逐节重写收到新声明的新旧章节,未收到声明的章节原样保留,再与原文档做词级diff。所有 LLM 调用统一使用开源模型 Qwen3.5-27B。
核心创新是 ChangeLog 的两级分解:把一次文档更新同时表达为'知识级提案'(claim proposal)与'文本级diff'(document diff)两个可分别审查的工件。这与已有方法有本质区别:FRUIT、WiNELL 等改写方法把更新当作端到端的文本变换,输入旧文档加新来源,输出新文档,中间没有任何知识层面的显式表示,评审者只能对着词级diff猜测这次改动在知识上意味着什么;查询驱动系统则干脆抛弃旧文档从头生成。KPR 在两者之间插入了显式的声明中间层:来源先被还原为声明集合,主文档的声明集合被离线缓存,两者对齐后自然产生三类判定(已覆盖/缺失/冲突),其中只有'缺失且相关'的声明才会触发文本改动,冲突声明进入人工裁决队列而非被悄悄吸收。这一设计带来三个直接后果:改写被限定在受影响的章节内,未动内容逐字保留;评审单位从模糊的文本块变成清晰的原子声明,评审者可以就事论事;同一份声明索引还能离线转成 QA 集用于评估,一物两用。
方法步骤详情
完整流程如下。第一步,声明分解:输入来源与主文档;对来源每句,LLM 输出 JSON 数组形式的原子声明;非英语来源直接输出英文声明——Table 11 显示其忠实度(supported 89.0%)与母语分解再翻译(89.8%)相当,远好于先翻译再分解(幻觉率 13.2%~16.8%),且只需一次调用;主文档声明离线分解并缓存。第二步,声明提案:一次分类综合判定覆盖与冲突——SUPPORTED(主文档已蕴含)、ABSENT(缺失无矛盾)、CONTRADICTED(不相容),并逐字引用最多 40 词证据句;维基百科设定下 absent 声明不再做相关性过滤(候选本就来自同一方针条目),RAGTIME 设定下用查询相关性过滤离题声明;路由提示词把新声明分到最合适章节,都不合适则标 0,由新章节规划把孤儿声明聚成少量提议章节;冲突声明被暂扣留人裁决——实验无人工评审,作者选择'宁可少加也不武断改写'。第三步,文档diff:按提案重写收到声明的新旧章节,要求把共享主语的事实合并成流畅复合句、保留引用、不得虚构;未受影响章节逐字保留;最后与原文档做词级diff,与提案构成 ChangeLog。
技术新颖性
技术新颖性体现在四个层面。第一,声明从评估单位升格为操作单位:此前声明只用于事实性评估(FActScore 把输出分解为子声明逐条核验)和检索研究(Dense X 探讨检索粒度),本文首次证明把声明作为知识整合的生成条件能同时提升精确率与召回率,是角色迁移而非技术拼装。第二,跨语言直接分解:非英语来源不做'翻译→分解'两步,而是一步分解出英文声明,避免翻译误差与分解误差的复合放大(先翻译后分解的幻觉率高达 16.8% 与 13.2%,跨语言分解只有 9.2%),并把两次 LLM 调用压成一次。第三,冲突的显式化:借鉴版本控制系统的合并冲突概念,矛盾声明被隔离出来而非被改写隐式吞掉;RAGTIME 冲突设定证明了价值——没有冲突机制的 ConText 在该设定下精确率与信息整合同时下滑(InfoR-A 仅 0.429),KPR 以暂扣策略保住最高精确率(0.811)。第四,全程单模型:分类、路由、改写、评估都由 Qwen3.5-27B 一个中量级开源模型完成,不依赖任何前沿闭源模型,说明增益来自流程设计而非模型能力。
实验结果
维基百科修订(599 篇条目、49 种语言来源)。质量(Table 2):KPR InfoP/InfoR-R/InfoR-A 0.878/0.950/0.891 全最优(ConText 0.716)。QA(Table 1,7 模型):多语言 闭卷 36.9/原文档 29.5/ConText 48.4/ConClaim 58.5/KPR 69.2;英语三改写 87.6~88.0,近原文档 92.0。百道闭卷全错题(Table 4):Qwen3.5-27B 3→52 分,7B 约 50;GPT-5.6 挂搜索 38,KPR 文档 62。成本(Table 5):KPR 留 97.3% 原文、11.2 次审批 vs ConClaim 25.3。RAGTIME(Table 6):KPR InfoR-A 三变体 0.682/0.571/0.632 均最优;Conflict 下 ConText 隐式消解冲突致受抑,KPR 以 0.811 InfoP 居首;Scratch 只留 37.3% 旧报告、需 56.1 次审批(Table 7)。结论:声明优于文本,提案再增益,单位 token 收益最高。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 跨语言维基百科修订后的多语言 QA grounding(7 个开源模型平均) | QA 准确率(%) | KPR 69.2 | ConClaim 58.5;ConText 48.4;闭卷 36.9;原始英文条目 29.5 | 较最强基线 ConClaim 高 10.7 个百分点,较原始条目高 39.7 个百分点 |
| 最难 100 题多语言 QA(所有稠密模型闭卷均答错) | QA 准确率(%) | 基于 KPR 文档:Qwen3.5-27B 52,GPT-5.6 62 | GPT-5.6 + 网页搜索 38(问题译成源语言后 41);原始英文条目上 GPT-5.6 仅 32 | 超过前沿模型+搜索约 21~24 个百分点,且 7B 模型(KPR 文档)即优于 GPT-5.6+搜索 |
| 维基百科改写文章质量 | InfoR-A(新增信息召回) | KPR 0.891 | ConClaim 0.786;ConText 0.716 | 较 ConClaim +0.105,较 ConText +0.175;InfoP 同时最高(0.878) |
| 维基百科改写的评审成本 | Click(评审者需批准的连续编辑块数,越少越好) | KPR 11.2(并保留原文 97.3%) | ConClaim 25.3;ConText 14.7 | 审批次数比 ConClaim 减少 56%,且内容保留率最高 |
| RAGTIME 报告更新(Balanced 变体) | InfoR-R / InfoR-A | KPR 0.856 / 0.632 | ConText 0.739 / 0.537;Scratch 0.558 / 0.326 | 旧报告保留与新信息集成均最优,InfoR-R +0.117,InfoR-A +0.095 |
| RAGTIME 报告更新(Conflict 变体,来源与旧报告矛盾) | InfoP(信息精确率) | KPR 0.811(InfoR-A 0.571) | ConText 0.666(InfoR-A 仅 0.429);Scratch 0.875(InfoR-A 仅 0.286) | 在集成有意义信息量的方法中精确率最高,证明显式冲突处理优于隐式消解 |
局限与改进
作者承认的局限有二。一是计算效率:分解、分类、路由、改写每一步都是 LLM 调用,虽然只重写变化的章节而非整篇重新生成,但累积成本对'持续更新整个维基百科'级别的部署仍昂贵,作者也承认轻量编码器本可承担覆盖性分类与路由。二是人工审查环节未被评估:实验全程自动运行,冲突一律暂扣,论文没有回答'ChangeLog 是否真能让编辑更快更准'这一核心卖点问题,作者明言需要人因研究补课。我自己的观察还有:其一,所有质量指标都用 Qwen3.5-27B 作裁判,而它同时是流水线执行模型,存在自评偏好风险;其二,冲突'暂扣'策略在真实维基百科场景可能造成大量积压——过时数值需要被替换而非搁置,论文没有自动裁决或信任建模的尝试;其三,英语 QA 显示三种改写都让原文档性能从 92.0 降到 87~88,约 4 个点的损耗在'绝不能破坏现有条目'的维基语境下未必可忽略;其四,RAGTIME 用相关性判定直接取源文档、跳过真实检索,评估环境比实际 RAG 系统理想;其五,WER 类指标可超过 100%,对冗长改写偏宽容,需与 Click 结合才完整。
独立分析的弱点
独立分析还有更多弱点。第一,流水线延迟与费用:一篇条目要跑完分解、逐条分类、路由、逐节改写,长条目多来源时串行调用次数放大;改进方向:嵌入检索加轻量 NLI 粗筛声明包含性与路由,歧义时才唤起 LLM。第二,声明分解是单点故障:Table 11 显示最好策略也有约 9% 幻觉声明,错误会未经校验流入提案和改写;改进:提案阶段加来源回指验证或置信度打分。第三,冲突处理过于保守:暂扣策略保住精确率,但矛盾信息永远进不了文档;现实中过时值需要被替换(如 RAGTIME 中 2.7% 与 3% 的口径差);改进:引入来源可信度、时效衰减或多源投票半自动裁决,人做最终确认并记录理由。第四,评估裁判单一:所有 MiRAGE 分数出自同一个 27B 模型,应做裁判交叉验证并报告一致性。第五,新章节规划可能碎片化:多轮更新后文档结构会漂移,需全局结构维护策略。第六,Click 指标未建模'审一条声明'与'审一块文本'的认知成本差异,指标需人因数据校准。第七,Conflict 设定下 KPR 新信息量(0.571)仍低于其他设定,说明被暂扣声明中混有本可采纳的部分,值得细分冲突类型。
未来方向
作者明确提出的方向包括:用轻量编码器替代 LLM 做声明包含性分类与路由,降低单步成本以支撑维基百科规模的持续更新;开展人因研究,验证 ChangeLog 是否让编辑更快更准,以及人类应如何裁决声明提案。延伸方向有:其一,冲突裁决的知识工程——引入来源可信度、时效衰减、多源投票,把'信任哪个源'变成可配置策略,并记录裁决理由形成认识论审计日志。其二,规模化持续创作——把 KPR 接到实时编辑流或新闻源,研究声明索引增量维护、重复提案去重、多个 KPR 并发时类似 git rebase 的顺序问题。其三,个人知识库——论文引用 Karpathy 的'本地个人维基'设想,7B 模型即可受益说明 KPR 适合端侧部署。其四,跨模态扩展——声明表示已能迁移到多模态(FaithScore),KPR 式变更管理可推广到多模态文档、代码文档、法律合同版本管理。其五,评估协议——构建带人工裁决金标的冲突数据集,量化不同裁决策略的下游影响。其六,蒸馏训练——用被批准的提案-diff 对微调小型端到端改写模型,把多步流水线压缩进单模型。
复现评估
复现条件相当友好。代码已在 GitHub 开源(github.com/alexmartin1722/kpr);数据方面,维基百科实验基于公开的 MegaWika 2.0,从 2026 年 7 月 30 日版本采样 599 篇条目、来源覆盖除英语外 49 种语言并按链接数分层;RAGTIME 是 TREC 2025 公开任务,用相关性判定直接取源文档、跳过检索,三个变体(时间对半、冲突 nugget 分轮、均衡分配)的构造见附录 B。附录完整给出 QA 生成过滤流程与全部提示词(Figure 5-17),QA 集各阶段数量(多语言 427,898→81,490→44,683;英语 111,693→26,572)与 100 题最难题子集构造都有据可查。算力门槛低:流水线与评估只用一个 Qwen3.5-27B 做生成与裁判,QA 测试另用一批开源模型(8B~120B),全程只有推理没有训练;唯一较贵的是 GPT-5.6 网页搜索基线。总体难度中等:工程上需复刻 QA 生成过滤与 MiRAGE 评估;注意所有分解、判定与裁判都绑定 Qwen3.5-27B,复现数字应使用同版本模型与相同设置。
论文图表
用 MiRAGE 评估三种维基百科改写的质量:InfoP(信息精确率)、InfoR-R(保留英文原文信息)、InfoR-A(新增来源信息)。KPR 为 0.878/0.950/0.891,ConClaim 为 0.853/0.943/0.786,ConText 为 0.837/0.946/0.716。
把'声明作条件'(ConText→ConClaim)与'提案过滤'(ConClaim→KPR)两步增益解耦的关键表,显示两步各自提升精确率与召回率,是方法设计的消解验证。
四个 7B~9B 小模型在多语言 QA 上的表现:闭卷 25.5~38.9,原始英文条目 15.5~35.8,基于 KPR 文档 44.8~61.5。例如 Llama-3.1-8B 从闭卷 38.9 升到 61.5。
证明 KPR 的收益不依赖大模型:本地小模型同样能从 KPR 文档获得大幅提升,支撑'无需前沿模型即可搭建个人 grounding 维基'的应用叙事。