[논문리뷰] Knowledge Pull Requests for Continual Document Authoring (KPR, 문서를 코드리뷰처럼 갱신하기)

About this offer

(출처: arXiv:2609.26634, Figure 1) Knowledge Pull Requests for Continual Document Authoring 저자 : Alexander Martin, Benjamin Van Durme (Johns Hopkins University) 공개일 : 2026년 9월 22일 (arXiv, cs.CL) arXiv : https://arxiv.org/abs/2609.26634 코드 : https://github.com/alexmartin1722/kpr 분류 : LLM · 문서 자동 저술(Continual Document Authoring) · 지식 통합 · 멀티링구얼 · RAG 🔖 TL;DR (한눈에) 기존 문서를 새 자료로 갱신하는 작업을 코드의 Pull Request처럼 다루는 프레임워크 KPR(Knowledge Pull Request) 을 제안한다. 소스 문서를 원자적 claim으로 분해 → 이미 있는 내용/충돌/무관 여부로 걸러내고 → 들어갈 섹션으로 라우팅 → 해당 섹션만 재작성한다. 산출물은 ChangeLog : "무슨 지식이 바뀌는가(Claim Proposal)"와 "문장이 어떻게 바뀌는가(Document Diff)"를 분리해 사람이 리뷰할 수 있게 만든다. 영어 위키백과를 49개 언어판으로 보강하는 실험에서 추가 정보 재현율(InfoR-A) 0.716 → 0.891 , 기존 내용 보존율 97.3%, 리뷰 클릭 수는 경쟁 기법의 절반 미만(11.2 vs 25.3). 다국어 QA에서 KPR로 갱신된 문서를 근거로 주면 평균 정확도 29.5 → 69.2 . 가장 어려운 100문항에서는 7B 모델(49점)이 웹 검색을 쓴 프런티어 모델(41점)을 이겼다. 한 줄 요약 : 문서를 매번 새로 쓰거나 통째로 덮어쓰는 대신, "어떤 사실이 왜 추가·보류되는지"를 리뷰 가능한 diff로 남기면서 점진적으로 갱신하는 방법. 📄 초록(Abstract) 완역 우리는 각각의 변경을 해석 가능하게 만드는 지속적 문서 저술(continual document authoring) 프레임워크인 Knowledge Pull Requests(KPRs) 를 소개한다. 문서는 다른 출처, 다른 언어, 다른 시점에서 새로운 지식이 드러날 때마다 지속적인 개정을 요구하지만, 기존 접근법들은 어떤 지식이 바뀌었는지에 대한 설명 없이 편집하거나 처음부터 다시 생성한다. KPR은 claim을 추출하고, 이를 필터링해 섹션으로 라우팅하며, 기존 내용과의 충돌을 표시함으로써 새로운 지식을 문서에 통합한다. 이 과정에서 어떤 지식이 변하는지(claim proposal)와 텍스트가 어떻게 변하는지(document diff)를 분리한 ChangeLog 를 생성한다. 우리는 여러 언어에 걸쳐 위키백과를 개정하는 과제와 RAGTIME에서 질의 기반 보고서를 갱신하는 과제로 KPR을 평가한다. KPR은 출처로부터 다시 쓰거나 처음부터 재생성하는 방식보다 더 많은 정보를 통합하고 기존 내용을 더 잘 보존하며, 동시에 생성된 토큰당 가장 많은 정보를 추가한다. 또한 KPR로 개정된 문서는, 다른 언어에만 기록된 지식을 찾아내지 못하는 검색 기능을 갖춘 프런티어 모델보다 질의응답을 더 잘 뒷받침한다. 요약하면 , 이 논문의 문제의식은 "문서 갱신을 LLM에게 맡기면 결과물만 나오고 근거가 남지 않는다"는 것이다. KPR은 갱신 단위를 문장이나 문단이 아니라 claim(원자적·탈문맥화된 사실 진술) 으로 내리고, 그 claim들이 통과·보류·기각된 기록을 문서와 함께 남긴다. 실험은 두 축으로 진행된다. 하나는 "이미 잘 정제된 다른 언어 문서에서 영어 문서로 지식을 옮길 수 있는가"(위키백과), 다른 하나는 "시간이 지나 새 문서가 들어왔을 때 보고서를 갱신할 수 있는가"(RAGTIME)다. 🧩 왜 이 문제가 중요한가 LLM으로 문서를 만드는 일은 이제 어렵지 않다. 정작 어려운 것은 이미 존재하는 문서를 계속 살려두는 일 이다. 사내 위키, 제품 문서, 리서치 리포트, 운영 런북은 모두 "한 번 쓰고 끝"이 아니라 새 자료가 생길 때마다 갱신되어야 한다. 그런데 현재 방식은 대체로 두 갈래로 갈린다. 첫째, 처음부터 다시 생성하기 . 논문이 지적하듯 오늘날의 deep research·보고서 생성 시스템 대부분이 이 방식이고, 이전 문서에 들어간 작업은 그냥 버려진다. 사람이 다듬어 놓은 표현, 조심스럽게 조율한 뉘앙스, 지난번 리뷰에서 고친 오류가 함께 사라진다. 둘째, 그냥 편집하도록 맡기기 . 결과 텍스트는 얻지만 무엇이 왜 바뀌었는지 알 수 없다. 텍스트 diff만으로는 "이 문장이 왜 고쳐졌는가"를 판단할 수 없기 때문에, 신뢰가 필요한 문서일수록 사람이 전부 다시 읽어야 한다. 저자들이 든 비유가 정확하다. 소프트웨어에서 우리는 코드를 남이 통째로 덮어쓰게 두지 않는다. PR을 열고, diff를 보고, 리뷰하고, 머지한다. 문서 지식에도 같은 장치가 필요하다는 것이 이 논문의 출발점이다. 특히 지식 충돌 — 한 자료는 승차 2.7%라 쓰고 다른 자료는 3%라 쓰는 상황 — 에서 모델이 조용히 한쪽을 골라버리는 대신 "여기 충돌이 있습니다"라고 올려주는 것 이 더 안전하다는 관점이다. 또 하나 흥미로운 문제 설정은 언어 장벽 이다. 어떤 사실이 인터넷에 공개돼 있고 검색 엔진에 색인돼 있어도, 그것이 영어가 아닌 위키백과 판에만 적혀 있으면 실질적으로 찾아지지 않는다. 논문은 이 구멍을 QA 실험으로 정량화한다. 🔬 방법론 1) KPR의 구성 요소 KPR은 두 개의 입력을 받는다. main (이미 작성된 대상 문서)과 sources (새 지식을 담고 있을 수 있는 문서들)이다. 목표는 main을 덮어쓰는 것이 아니라 "기존 내용과 함께 작업하며" 소스의 정보를 통합하는 것이다. 핵심 동작 단위는 claim , 즉 원자적이고 탈문맥화된 사실 진술이다. 문단 단위가 아니라 claim 단위로 내려가는 이유는 세 가지를 정밀하게 추적하기 위해서다. (a) 어떤 지식이 제안되고 있는지, (b) main의 어디에 들어가야 하는지, (c) 기존 내용과 충돌하는지. 그리고 산출물인 ChangeLog 가 KPR을 단순 재작성과 구분한다. ChangeLog는 두 부분으로 나뉜다. Claim Proposal : 새 claim들이 main의 어느 섹션(필요하면 새 섹션)에 들어갈지에 대한 매핑. 이미 main이 담고 있는 claim(coverage)과 문서의 저술 기준에 맞지 않는 claim(relevance)은 여기서 탈락한다. 그리고 기존 claim과 모순되는 claim은 조용히 해결하지 않고 리뷰용으로 표시(flag) 된다. Document Diff : 통합이 적용되면 문서가 어떻게 읽히게 되는지에 대한 텍스트 변경 기록. 사람 리뷰어는 이 위에서 충돌을 판정하고, claim을 승인/기각하고, 필터링 결정을 되돌릴 수 있다. 저자들은 이를 명시적으로 "소프트웨어 공학의 코드 리뷰와 유사하다"고 표현한다. 2) 3단계 파이프라인 논문은 KPR을 만들어내는 3단계 베이스라인 구현을 제시한다. Stage 1 — Claim Decomposition. LLM이 소스를 원자적·탈문맥화된 claim 집합으로 분해한다. main도 같은 방식으로 분해하지만, 이쪽은 온라인이 아니라 오프라인에서 미리 인덱스로 캐싱 해 둔다. 비영어 소스는 번역한 뒤 분해하지 않고 곧바로 영어 claim으로 분해(cross-lingual decomposition) 하는데, 이것이 더 충실한 claim을 만든다는 점을 부록 실험으로 보였다. (출처: arXiv:2609.26634, Figure 2) Stage 2 — Claim Proposal. 후보 claim마다 네 가지를 판단한다. coverage — main이 이미 담고 있는가 conflict — main의 기존 claim과 모순되는가 relevance — 문서의 저술 기준(질의 관련성 또는 저술 가이드라인)에 맞는가 routing — 어느 섹션에 속하는가 구현상 coverage와 conflict는 한 번의 분류 패스 로 함께 처리되어 각 소스 claim이 'covered' / 'conflicting' / 'absent' 중 하나로 라벨링된다. 이어서 relevance는 'absent' claim에만 적용되는데, RAGTIME 설정에서는 정보 요청(query) 기준으로 필터링하고, 위키백과 설정에서는 후보 자체가 같은 가이드라인으로 쓰인 문서에서 오기 때문에 필터를 걸지 않는다. 마지막으로 라우팅이 살아남은 claim을 기존 섹션에 배치하거나 새 섹션을 제안한다. 'covered'와 무관한 claim은 드롭 되고, 'conflicting' claim은 flag 된다. (출처: arXiv:2609.26634, Figure 3) Stage 3 — Document Diff. 승인된 proposal이 섹션 단위로 적용된다. claim을 하나 이상 받은 섹션(신규 또는 기존)만 재작성되고, 제안된 claim이 없는 섹션은 손대지 않는다. 결과를 원본 main과 diff하면 document diff가 나온다. 이 "건드리지 않는다"가 뒤에 나오는 보존율·클릭 수 지표의 근원이다. (출처: arXiv:2609.26634, Figure 4) 3) 비교 대상(베이스라인) 세 베이스라인 모두 claim proposal이 없다는 점이 공통이다. 이름 무엇을 조건으로 재작성하는가 KPR과의 차이 ConText 소스의 원문 텍스트 claim 분해 자체가 없음. WiNELL(Gangi Reddy et al., 2026)을 저자들이 각색한 것으로, 검색 단계 대신 LLM이 섹션 관련성을 분류 ConClaim 소스의 claim claim 분해와 라우팅은 KPR과 동일하지만 coverage·conflict·relevance 필터가 전혀 없다. 즉 "claim 리뷰가 없는 KPR" Scratch 모든 소스를 한 번에 기존 문서를 버리고 재생성. RAGTIME 설정에서만 사용 이 구성 덕분에 ConText → ConClaim → KPR이 깔끔한 단계적 ablation이 된다. 앞의 화살표는 "원문 대신 claim을 쓰는 효과", 뒤의 화살표는 "claim proposal(리뷰)을 추가하는 효과"를 각각 분리해 보여준다. 4) 구현 세부 분류·라우팅·재작성 모든 LLM 호출에 Qwen3.5-27B 하나만 사용한다(vLLM 서빙). 위키백과 문서는 섹션 구조가 이미 있어 그대로 쓰고, RAGTIME 보고서는 섹션이 없어 1라운드 보고서에 개요를 부여 해 모든 기법이 섹션 단위로 작동할 수 있게 했다. 실험에는 사람 리뷰어가 없다. 충돌로 표시된 claim은 해결되지 않고 재작성에서 보류(withheld) 된다. 저자들의 설명은 "충돌 해결은 어느 출처를 믿을지 결정하는 일이고, 출처 신뢰 판정은 여전히 열린 문제"라는 것이다. 이 점은 결과 해석에서 중요하다. 평가 지표 MiRAGE의 근거 판정기(support judge)도 Qwen3.5-27B이며, 비교 대상 프런티어 모델은 GPT-5.6("Sol") 로 reasoning effort를 최대로 설정했다. 5) 평가 지표 직관 품질은 MiRAGE 기반 두 축으로 본다. InfoP(Information Precision) : 출력의 서브클레임 중 소스가 뒷받침하는 비율. FActScore의 소스 제한 변형. "쓴 내용이 근거가 있는가." InfoR(Information Recall) : 반대 방향. 두 갈래로 쓴다. InfoR-R(retain) 은 원본 문서의 claim이 얼마나 보존됐는지, InfoR-A(add) 는 소스의 claim이 얼마나 반영됐는지. 편집 비용은 원본과 재작성본의 단어 단위 diff에서 뽑는다. WER (단어 편집률, 원본보다 많이 추가하면 100%를 넘을 수 있다), Click (리뷰어가 승인 버튼을 눌러야 하는 연속 편집 블록 수 — 길이와 무관하게 블록 하나당 1클릭이므로, 잘게 흩어진 수정이 큰 덩어리 하나보다 비싸다), Tok (추가된 토큰 수), Presv (원본이 그대로 보존된 비율), Add (원본 대비 길이 배율). 저자들은 WER·Click·Tok을 비용으로, Presv·Add를 "변경의 모양"으로 구분하며, 후자는 높거나 낮은 쪽이 일방적으로 좋은 것은 아니라고 명시한다. 📊 실험 결과 실험 1: 위키백과 교차언어 개정 영어 위키백과를 main, 다른 언어판을 sources로 둔다. MegaWika 2.0에서 599개 문서 를 교차언어 링크 수 분포에 맞춰 샘플링했고, 영어를 제외한 49개 언어 가 소스로 등장한다. 문서 품질 (Table 2) Method InfoP InfoR-R InfoR-A ConText 0.837 0.946 0.716 ConClaim 0.853 0.943 0.786 KPR 0.878 0.950 0.891 두 단계 개선이 뚜렷하다. 원문 대신 claim을 조건으로 주는 것만으로 정밀도 0.837 → 0.853, 추가 정보 재현율 0.716 → 0.786이 오르고, 여기에 claim proposal을 붙이면 0.878 / 0.891로 한 번 더 오른다. 이득이 더 큰 쪽은 추가 정보 재현율 이다. 기존 내용 보존(InfoR-R)은 세 기법 모두 0.943~0.950으로 높아, 실질적 차이는 "소스 지식을 얼마나 실제로 통합했는가"에서 갈린다. 다국어 QA (Table 1, Multi-QA) — 각 조건의 문서를 근거로 주고 답을 맞히게 한 정확도다. Model CB(문서 없음) EW(원본 영어 문서) ConText ConClaim KPR Qwen3.5-27B 36.3 15.5 41.7 54.6 67.8 Qwen3-30B 31.0 29.4 49.1 59.9 70.7 Gemma-4-31B 35.9 14.6 39.5 52.7 66.3 Llama-3.3-70B 43.5 31.9 52.9 62.8 74.0 Llama-4-Scout 33.9 34.5 42.3 48.9 54.8 Mixtral-8x7B 36.4 39.0 55.7 64.2 74.5 Nemotron-3-120B 41.6 41.3 57.1 66.1 76.6 평균 36.9 29.5 48.4 58.5 69.2 눈에 띄는 것은 원본 영어 문서(EW, 평균 29.5)가 문서를 아예 안 주는 것(CB, 36.9)보다도 낮다 는 점이다. 질문된 사실이 영어 문서에 없기 때문이고, 일부 모델은 추측 대신 성실하게 답을 거부한다(각주: Gemma-4와 Qwen3.5는 약 70%에서 abstain). 세 재작성 기법 모두 이를 회복하지만 KPR의 회복량이 가장 크다. 반대로 영어 QA(Table 1, En-QA) 에서는 원본 문서가 평균 92.0으로 가장 높고, 세 재작성본은 87.6 / 88.0 / 87.7로 서로 0.5% 안쪽이다. 즉 교차언어 지식을 통합하는 대가로 기존 내용이 유의미하게 희생되지는 않는다. 작은 모델도 같은 이득 (Table 3) Model CB EW KPR Qwen3.5-9B 37.4 15.5 44.8 Qwen3-8B 33.5 35.8 61.4 Llama-3.1-8B 38.9 33.8 61.5 OLMo-3-7B 25.5 25.1 51.1 가장 어려운 100문항 (Table 4) — 어떤 오픈 모델도 closed-book으로 맞히지 못한 다국어 질문 100개다. (WS = 웹 검색, -T = 질문을 소스 언어로 번역) Model CB CB-T EW KPR WS WS-T Qwen3.5-9B 2 3 2 49 – – Qwen3-8B 4 4 9 56 – – Llama-3.1-8B 2 1 7 56 – – OLMo-3-7B 2 2 13 50 – – Qwen3.5-27B 0 5 3 52 – – Qwen3-30B 0 3 12 54 – – Gemma-4-31B 0 4 4 54 – – Llama-3.3-70B 0 5 8 51 – – GPT-5.6 (Sol) 13 20 32 62 38 41 이 표가 논문에서 가장 인상적인 부분이다. 웹 검색을 붙인 GPT-5.6이 38점(번역 시 41점)인데, 원본 영어 문서만 준 경우의 32점보다 겨우 조금 높다. 반면 가장 작은 7 9B 모델이 KPR로 갱신된 문서를 근거로 받으면 49 56점 을 낸다. 저자들의 해석: 소스가 다른 언어판 위키백과이므로 그 지식은 공개돼 있고 색인도 되어 있지만, 검색으로 표면화되지 않는다. 편집 비용 (Table 5) Method WER Click Tok Presv Add KPR 131 11.2 1,299 97.3 2.3 ConClaim 92 25.3 898 94.6 1.8 ConText 138 14.7 1,374 96.9 2.3 KPR은 원본을 가장 많이 보존하면서(97.3%) 가장 적은 연속 편집(11.2 클릭)으로 변경을 만든다. KPR과 ConText는 추가 분량이 사실상 같은데(둘 다 Add 2.3배, Tok 1,299 vs 1,374) KPR이 훨씬 많은 소스 지식을 통합한다. ConClaim은 전체 변경량이 가장 작지만(WER 92, Add 1.8배) 승인 클릭은 KPR의 두 배가 넘는다(25.3) . claim proposal이 없으면 섹션에 라우팅된 모든 claim이 그대로 재작성에 넘어가, 바뀔 필요 없던 내용까지 모델이 건드리기 때문이다. 실험 2: RAGTIME 질의 기반 보고서 갱신 RAGTIME은 페르소나와 질의를 받아 다국어 문서 집합에 대해 RAG를 수행하는 다국어 보고서 생성 과제다(여기서는 검색 대신 관련성 판정을 직접 사용). 저자들은 2라운드 변형 세 가지를 만들었다. Temporal (발행일 기준 전/후 절반), Conflict (OR 너깃의 상충 답변이나 AND 너깃의 상보 조각을 서로 다른 라운드에 배치), Balanced (라운드별 너깃 수를 최대한 같게). 설정 Round-2 InfoP InfoR-R InfoR-A Temporal R1 Main 0.928 0.416 – Temporal Scratch 0.882 0.475 0.223 Temporal ConText 0.620 0.649 0.632 Temporal KPR 0.729 0.709 0.682 Conflict R1 Main 0.904 0.430 – Conflict Scratch 0.875 0.456 0.286 Conflict ConText 0.666 0.625 0.429 Conflict KPR 0.811 0.782 0.571 Balanced R1 Main 0.961 0.453 – Balanced Scratch 0.862 0.558 0.326 Balanced ConText 0.692 0.739 0.537 Balanced KPR 0.841 0.856 0.632 KPR이 세 설정 모두에서 InfoR-R과 InfoR-A 최고이고, 재작성 기법들 중 정밀도도 가장 높다. Scratch는 라운드 간 정보를 가장 적게 추가한다 (InfoR-A 0.223 / 0.286 / 0.326). 처음부터 다시 쓰는 방식이 실제로 얼마나 손해인지 보여주는 숫자다. Conflict 설정이 특히 흥미롭다. ConText는 여기서 InfoR-A가 0.429로 떨어지는데(Temporal 0.632, Balanced 0.537), 충돌을 표시할 장치가 없으니 재작성 중에 암묵적으로 해결해야 하고 그 과정이 정보 통합 자체를 억제하는 것으로 보인다. KPR은 충돌 claim을 보류하면서 다른 설정과 비슷한 비율로 새 사실을 추가하고, 의미 있는 양을 통합하는 기법 중 가장 높은 정밀도(0.811 vs ConText 0.666)를 유지한다. 또 하나: 모든 기법이 1라운드 보고서 자신보다 1라운드 너깃을 더 많이 재현한다 (Temporal에서 R1 Main 0.416 < Scratch 0.475 < ConText 0.649 < KPR 0.709). 1라운드 정보 일부가 2라운드 문서에도 다시 등장하므로, 2라운드 소스를 통합하는 과정에서 원래 보고서가 놓쳤던 너깃이 회수된다. 점진적 기법들이 1라운드 문서를 다시 읽지 않았는데도 그렇다. 편집 비용 (Table 7) Method WER Click Tok Presv Add Scratch 130 56.1 770 37.3 1.2 ConText 330 12.5 3,091 98.2 4.3 KPR 372 20.5 3,475 96.3 4.7 Scratch의 높은 정밀도는 "짧지만 확신 있는 보고서"라는 모양과 맞아떨어지지만(Presv 37.3, Add 1.2배), 리뷰 비용은 가장 비싸다(56.1 클릭). 재생성이라 우연한 n-gram 중복만 보존되기 때문이다. 부록의