[Arxiv 2025] Bridging the Editing Gap in LLMs: FineEdit for Precise and Targeted Text Modifications

* ChatGPT를 이용한 번역이 섞여 있습니다.

 

• 읽은 이유 : LLM으로 글을 편집하는 것에 관심을 가지고 있었는데 비슷한 주제의 논문이 보여서 가져왔다.
• 논문 요약 : 텍스트 편집을 LLM에게 맡길 때 제대로 하였는지를 평가하기 위한 벤치마크를 만들었고, 그 벤치마크 데이터셋을 활용하여 모델 fine tuning을 해서 학습안한 LLM과 비교함. 

 

Abstract

 

• LLM은 여전히 정교하고 문맥을 고려한 수정이 필요한 직접적인 텍스트 편집 작업에서 어려움을 겪고 있으며,
• 편집 능력이 부족하여 깊은 구조적 또는 논리적 불일치보다는 피상적인 문제만 해결하는 경우가 많다.
• In this work, 
  • introduce a dual approach to enhance LLMs editing performance.
    • 1) we present InstrEditBench, a high-quality benchmark dataset
      • comprising over 20,000 structured editing tasks spanning Wiki articles, LaTeX documents, code, and database Domain-specific Languages (DSL).
    • 2) we propose FineEdit, a specialized model trained on this curated benchmark.
      • 실험 결과는 FineEdit이 직접 편집 작업에서 Gemini에 비해 약 10%의 성능 향상을 달성

 

1. Introduction

 

• LLM은 여전히 텍스트 편집 작업에서 성능이 안 좋다.
  • [7 "Chatgpt: A promising tool for academic editing"]에서는 ChatGPT를 편집에 활용할 때 명확한 한계가 있다고 언급
    • 편집 작업 지침을 정확하게 따르지 않거나 저자의 의도를 이해하지 못할 수 있습니다.
      -> 그로 인해 텍스트의 맥락에 적합하지 않은 변경이 이루어질 수 있습니다.  
•  반면, 철자 및 형식과 같은 표면적인 문제는 효과적으로 해결할 수 있지만, 긴 텍스트 맥락에서의 편집이나 작업 지침을 엄격히 따르는 등의 복잡한 문제는 해결하지 못한다.

 

• To address these limitations,
  • 기존 연구들) researchers have developed methods to enhance the editing capabilities of LLMs,
    • particularly under task-specific scenarios, e.g., editing in code, LaTeX, etc.
  • 그러나, LLMs’ general editing capabilities in task-specific settings often fall short [57, 31].
    • LLM은 종종 부정확한 출력을 생성하거나 주어진 편집 지침에서 벗어나는 경향을 보임.
    • 이러한 문제는 주로 모델이 특정 작업의 제약 조건을 지나치게 강조하면서, 불필요한 정보를 생성하는 ‘환각(hallucination)’ 현상에 취약하기 때문에 발생함.
• 반면, 모델의 초점을 두 가지 요소, 즉 편집이 이루어질 정확한 위치와 변경해야 할 특정 내용으로 좁히면 편집 작업 자체를 더 효과적으로 수행할 수 있음을 발견함. 
• -> 이러한 직관에 따라, 편집 작업을 위한 벤치마크와 FineEdit라는 모델로 구성된 이중 접근법을 제안함.

- 어떻게 위치랑 내용을 좁혔나?

-> 데이터셋을 그렇게 구성한 것 같다. 좀 더 세밀한 Instruction을 추가한 데이터셋을 사용함.

 

 

• 이 연구의 주요 기여:
  • 고품질 벤치마크 데이터셋 (InstrEditBench):
    • 위키 문서, LaTeX 문서, 코드, 데이터베이스 DSL 등 20,000개 이상의 구조화된 편집 작업을 포함하는 정제된 데이터셋을 구축, 통합 평가 기준을 제공
  • 자동 데이터셋 생성 워크플로우:
    • 정확한 줄 번호 식별 및 엄격한 기준을 적용하여 의미 있고 관련성이 높은 편집을 필터링
  • FineEdit 모델:
    • 구조화된 직접 텍스트 편집을 위해 설계된 특화된 모델을 제안하며, 기존 모델과 비교했을 때 벤치마크 전반에서 우수한 성능을 보여줍니다.

 

2. 배경

2.1 문제 정의

• 각 데이터 포인트는 원본 구조화된 텍스트(original structured text) T_orig,​ 와 편집 지시문( editing instruction)  I_edit로 구성됨.

-> 결국에는 T_orig이라는 데이터가 있을 때, I_edit이라는 instruction을 주고 편집한 결과물이 T_edit이 된다는 것. 데이터셋은 T_orig, I_edit, T_edit의 트리플로 이뤄져 있음.

-> 그리고 LLM 학습할때는 원본 글 + instruction을 하나의 프롬프트로 준 후에 편집된 버전(T_edit)을 생성하도록 함. 이때, fine tuning을 진행할 때는 loss 고려할땐 생성된 부분만 고려하도록 했다는 점. 

 

2.2 LLM Editing Tasks

 

• 이전 연구에서는 LLM을 위키 문서와 같은 자연어 편집 및 코드 편집 작업에 활용하는 방법을 탐구했음.
  • 예를 들어, CoEdIT [39]는 특정 작업을 위한 명령어 조정을 통해 정밀한 수정이 가능하도록 했으며,
  • 다른 연구에서는 T5 [38]와 같은 모델을 원본 텍스트와 편집된 텍스트 쌍에 대해 미세 조정하는 방식을 활용했습니다 [16, 41, 32, 14, 15, 24].
  • 그러나 이러한 접근 방식의 상당수는 특수한 기술에 의존하거나 특정 작업(예: 문법 교정 [32, 18], 텍스트 단순화 [59], 패러프레이징(문장 변형) [10], 스타일 변환 [42])에만 초점을 맞추고 있어 보다 광범위한 편집 작업에 일반화하기 어렵다는 한계를 가지고 있습니다.

• 이 연구에서도 비슷하게 fine tuning 한건 맞는데 무엇이 다른 것인지?
• -> 카테고리를 늘림(4개를 사용), instruction에 zero-shot 뿐 아니라 ICL도 적용(이 부분은 벤치마크 데이터셋을 만들때 적용한 듯하다)(The editing instruction generated through zero-shot or few-shot prompting based on the original content)

 

2.3 LLM Benchmarking

• LLM의 편집 성능을 벤치마킹한 연구는 많지 않음.
  • GEM [55]은 명확한 정답이 없는 주관적 작업을 위한 지표를 도입
  • CriticBench [28]는 반복적인 출력 개선을 평가
  • 또한 [5 "Can it edit? evaluating the ability of large language models to follow code editing instructions"]에서는 정제된 학습 데이터를 활용한 파인튜닝이 코드 편집 성능을 크게 향상시킨다고 분석했습니다.
• 일부 자동화된 평가 기법도 LLM 벤치마킹에 활용됩니다.
  • 예를 들어, G-Eval [29]은 대형 언어 모델을 활용해 생성 작업에서 텍스트 품질과 모델 성능을 평가하는 자동 평가 프레임워크입니다.
    • 이 프레임워크는 Chain-of-Thought (CoT) 프롬프팅 전략 [51]을 기반으로 하며, 모델이 최종 평가를 내리기 전에 중간 추론 과정을 명확히 서술하도록 유도함으로써 인간의 판단과 더욱 일치하는 출력을 생성합니다 [29].

• 그러나 기존 연구들은 짧은 문맥에서 독립적인 작업을 평가하는 데 집중하며, 긴 문맥 내에서 내용을 찾아 수정하는 LLM의 능력을 체계적으로 평가하지 않습니다. -> 본 연구는 이러한 한계를 극복하고자 Wiki, 코드, DSL, LaTeX을 포함한 포괄적인 벤치마크를 도입하여 long-context editing을 강조합니다.

 

3 Method (InstrEditBench 만들기)

3.1 Instruction categories : 우리는 대표적인 텍스트 응용 시나리오를 포괄하기 위해 네 가지 데이터 소스를 활용함 - 위키(Wiki), 코드(Code), DSL, 그리고 LaTeX.

 

3.2 Instruction Generation

그림 1: 고품질 FineEdit 벤치마크 생성 워크플로우. 내용 차이는 빨간색으로 강조 표시됩니다.

 

제로샷(Zero-shot) 방식 + 인컨텍스트 러닝(In-Context Learning, ICL) [13]을 결합한 접근 방식을 활용 (ChatGPT-4o mini)

 

Wiki 데이터의 경우, 주로 제목과 부제목과 같은 명확한 구조적 텍스트 요소로 구성되어 있기 때문에 제로샷 프롬프트 방식을 적용합니다. 반면, LaTeX, 코드, DSL과 같은 보다 복잡한 도메인의 경우, ICL을 활용하여 생성된 명령어의 다양성과 세밀함을 향상시킵니다. -> 카테고리별 전략 사용 (그림 1의 1번) (프롬프트에 대한 자세한 내용은 부록 A)

 

3.3 Instruction filtering (자동 필터링 시스템)

 

- 각 콘텐츠에 대한 편집 명령어를 얻은 후, 이를 원본 텍스트에 적용하여 편집된 버전을 생성하는데, 이는 그림 1의 과정 ➁에 해당함.

- 그러나 편집된 콘텐츠의 품질을 보장하는 것은 여전히 어려운 과제입니다. 일반적으로 LLM은 편집 명령어를 따르지만, 예를 들어 잘못된 줄 번호를 대상으로 하거나, 의도한 의미를 잘못 해석하는 등의 오류가 발생할 수 있습니다 [50, 6].

- 이러한 문제를 해결하고 데이터 품질을 향상시키기 위해, 우리는 G-Eval [29]과 Git-Diff를 통합한 자동 필터링 시스템인 DiffEval Pipeline을 제안합니다.

 

git diff 명령어를 사용하여 원본과 수정된 텍스트 간의 차이를 분석하며, 이는 그림 1의 과정 ➂에서 보여지는 바와 같이 다음 네 가지 유형으로 변경 사항을 분류합니다.

• 대체 (Replacements): 기존 텍스트가 새로운 형태로 변환되는 경우로, [original_text -> modified_text] 형식으로 표시됩니다. 이는 의미나 스타일이 변경될 수 있는 경우를 포착합니다.
• 삭제 (Deletions): 특정 부분이 완전히 제거되는 경우로, [-original_text-] 형식으로 나타납니다. 이는 텍스트를 간결하게 만들거나 불필요한 내용을 제거하는 데 활용될 수 있습니다.
• 삽입 (Insertions): 새로운 내용이 추가되는 경우로, [+modified_text+] 형식으로 표현됩니다. 삽입을 통해 텍스트가 보강되거나 명확성이 높아질 수 있습니다.
• 변경되지 않은 텍스트 (Unchanged Text): equal: unchanged_text로 표시되며, 원본과 수정본 간에 동일한 부분을 나타냅니다. 이는 모델이 유지한 부분을 참고하는 데 유용합니다.

 

그림 1의 과정 ➃에서는 DiffEval이 편집 요청과 함께 수정된 데이터를 검토하는 과정을 보여줍니다 (빨간색 화살표로 표시됨). 이를 통해 텍스트의 문맥, 구조, 세부 사항을 종합적으로 파악하며, 의도한 편집과 실제 수정 사항 간의 불일치를 식별하여 변경 사항이 편집 명령을 충실히 반영했는지 검증합니다.

 

DiffEval은 완전히 편집된 콘텐츠를 직접 분석하는 대신 git diff 출력을 활용하므로, 줄 번호 및 구조적 차이와 같은 보조 정보를 기반으로 수정 사항을 정확하게 파악할 수 있습니다. 또한 git diff는 불필요한 노이즈를 줄이고, 전체 편집된 콘텐츠와 비교했을 때 토큰 수를 크게 줄여 연산 비용을 절감하는 효과가 있습니다.

 

• G-Eval 기반 품질 평가

모든 필요한 데이터가 수집된 후, G-Eval 분석 프로세스는 이를 평가하여 데이터셋 품질을 더욱 향상시킵니다.

1. git diff 출력을 분석하여 변경 사항을 대체, 삭제, 삽입, 변경되지 않음 등의 유형으로 분류합니다.
2. 원본 내용과 수정 사항의 의미를 평가하여 변경이 정확하고 완전한지 확인합니다.
3. 원본 텍스트, 편집 요청, 수정된 결과를 종합적으로 검토하여 사전 정의된 규칙을 적용하고, 전반적인 일관성을 평가합니다.

이러한 분석 과정을 바탕으로, DiffEval은 편집된 콘텐츠의 의미적 완전성과 논리적 일관성을 반영하는 G-Score를 할당합니다. 이 점수는 특정 품질 임계값 α를 충족하지 않는 출력을 필터링하는 데 사용됩니다.

 

3.4 Data Statistics

 

우리의 정제된 벤치마크는 다양한 구조적 데이터 유형을 포괄하는 총 28,050개 항목으로 구성되어 있습니다. 이는 8,366개의 LaTeX 문맥, 7,712개의 코드 조각, 8,025개의 WikiText 항목, 3,947개의 데이터베이스 언어 샘플을 포함하며, 실제 구조적 데이터의 일반성과 규모를 반영합니다. 표 1에서는 이 네 가지 카테고리의 예시를 보여줍니다.

 

 

• Id: 각 항목의 고유 식별자.
• 원본 콘텐츠 (Original content): 데이터 소스에서 직접 추출한 원본 텍스트.
• 편집 요청 (Edit request): 원본 콘텐츠를 기반으로 제로샷(Zero-shot) 또는 퓨샷(Few-shot) 프롬프팅을 통해 생성된 편집 명령어.
• 편집된 콘텐츠 (Edited Content): 편집 요청을 원본 콘텐츠에 적용한 결과.
• 변경 사항 (Difference): 편집된 콘텐츠와 원본 콘텐츠 간의 차이점.
• G-Score: 편집 요청에 대한 엄격한 준수 여부를 기반으로 편집된 콘텐츠의 품질을 평가하는 점수.(DiffEval이 할당한 값)

---

4 Evaluation (FineEdit 평가하기)

4.1 Experimental Setup

- 데이터셋 분할, 모델 변형(variants), 베이스라인, 평가 지표, 구현 세부 사항을 포함한 실험 설정을 설명함.

 

• 데이터셋 및 모델 변형
  • 우리는 FineEdit 모델을 제안한 InstrEditBench 벤치마크에서 평가하며, 90/10의 학습-테스트(train-test) 분할을 적용합니다. 세 가지 버전의 FineEdit 모델을 도입.
    • FineEdit-L: LLaMA-3.2-1B에서 파인튜닝
    • FineEdit-XL: LLaMA-3.2-3B에서 파인튜닝
    • FineEdit-Pro: Qwen2.5-3B-Instruct 기반으로 파인튜닝

 

• 베이스라인(Baselines)
  • Gemini 1.5 Flash / Gemini 2.0 Flash / LLaMA-3.2-1B / LLaMA-3.2-3B / Qwen2.5-3B-Instruct / Mistral-7B
  • Gemini 모델에 대해서는 제로샷(zero-shot) 및 퓨샷(few-shot) 프롬팅을 평가하며, 오픈소스 모델들은 제로샷 프롬팅으로 평가합니다.

 

• 평가 지표(Metrics)

 

기존 연구 [36, 45]를 참고하여 BLEU 및 ROUGE-L 지표를 활용하여 편집된 텍스트와 정답(reference) 텍스트 간의 어휘 및 구조적 일관성을 평가합니다.

 

- 추가적인 하이퍼파라미터 설정 및 학습 세부 사항은 Appendix B에서.

 

4.2 Performance of Existing Models

 

InstrEditBench 데이터셋의 네 가지 데이터 카테고리에서 SOTA 베이스라인 모델과 FineEdit의 성능을 비교.

 

• 제로샷(Zero-shot) 성능 비교
  • Gemini 1.5 Flash가 전체적으로 가장 높은 점수를 기록
• FineEdit 성능 비교
  • FineEdit, 특히 FineEdit-Pro는 모든 제로샷 베이스라인 모델을 능가
  • FineEdit-Pro 전체 BLEU 점수: 0.9245
• 데이터 카테고리별 성능도 우수
  • DSL 분야 BLEU 0.9521 / Code 분야 BLEU 0.9538
• FineEdit의 타겟팅된 파인튜닝 전략이 효과적임을 입증
  • 편집 위치 및 내용을 정밀하게 조정하여 구조적·의미적 일관성을 유지

 

• 퓨샷(Few-shot) 성능 비교
  • Gemini 모델을 대상으로 퓨샷 학습(few-shot learning) 평가 진행
  • 일부 카테고리에서 퓨샷 성능이 향상됨
    • LaTeX 카테고리에서 BLEU 20% 증가
  • 그러나 퓨샷 성능도 FineEdit보다 낮음
  • SQL 카테고리에서는 퓨샷 학습이 BLEU 0.1600, ROUGE-L 0.1814로 거의 개선되지 않음

-> 이러한 결과는 우리의 InstrEditBench 벤치마크가 편집 작업 개선에 유용함을 보여줌

 

• 핵심 발견

FineEdit는 전반적으로 뛰어난 성능을 보여줌.

또한 타겟팅된 훈련 전략이 다양한 응용 시나리오에서 모델 성능을 어떻게 향상시킬 수 있는지에 대한 통찰을 제공함.

 

4.3 FineEdit: Supervised Finetuning

 

• FineEdit 모델은 FineEdit-L, FineEdit-XL, FineEdit-Pro 세 가지 변형으로 제공됩니다.
  • FineEdit-XL은 FineEdit-L과 유사한 성능을 보여주며, LLaMA를 사용하여 파라미터 수를 1B에서 3B로 늘리는 것이 성능 향상에 큰 차이를 만들지 않음을 시사합니다.
• Qwen2.5-3B-Instruct의 우수한 명령어 따르기 능력을 활용한 우리의 마지막 변형인 FineEdit-Pro는 성능을 한층 더 끌어올립니다. FineEdit-Pro는 전체 BLEU 점수 0.9245를 달성하며, 이는 Gemini 1.5 Flash보다 약 11.6% 향상된 결과입니다.
• 여러 데이터 카테고리에서 일관된 향상은 우리의 감독된 세밀한 미세 조정(supervised fine-tuning) 전략의 효과를 강조하며, 모델 크기를 단순히 늘리는 것보다 강력한 명령어 튜닝된 기본 모델의 중요성을 부각시킴(highlight the importance of a strong instruction-tuned base model over merely increasing model size.)

 

• 핵심 발견

FineEdit의 감독된 미세 조정(supervised fine-tuning)은 성능을 향상시킵니다. FineEdit-L은 제로샷 기준 모델을 능가하고, FineEdit-XL은 유사한 향상을 제공하며, FineEdit-Pro(Qwen2.5-3B-Instruct 기반)는 가장 높은 점수를 기록합니다. 이는 강력한 명령어 튜닝이 단순히 모델 크기를 확장하는 것보다 더 효과적임을 강조합니다.

 

4.4 Qualitative Study

FineEdit의 성능을 질적으로 평가하기 위해, 우리는 그림 2와 같이 여러 연구를 수행했습니다.

figure 2

 

• FineEdit-Pro와 Gemini가 다양한 편집 요청에 어떻게 반응하는지에 대한 8가지 예시

여러 경우에서, Gemini는 의도한 수정 사항을 구현하지 않고 단순히 명령을 반복하는 경우가 많습니다. Gemini 1.5 Flash와 2.0 Flash는 LaTeX와 Wiki 작업에서는 잘 수행되지만, DSL과 Code 작업에서는 어려움을 겪습니다.

 

그럼에도 불구하고, FineEdit에는 단점도 존재합니다. 그림 2에 나타난 LaTeX 예시에서, Gemini는 정확하게 subsection{Strengths}를 찾고 지정된 대로 업데이트하지만, FineEdit-Pro는 올바른 위치를 식별하고 수정도 잘 적용하지만, 결과를 두 번 생성하여 직접적인 편집 요구 사항에서 벗어납니다. 이 불일치는 FineEdit-Pro가 일반적으로 더 신뢰할 수 있지만, 특정 경우에서 수정을 과하게 적용할 수 있음을 시사합니다.

 

전체적으로, 이러한 결과들은 FineEdit-Pro가 DSL과 Code에서 더 복잡한 편집을 잘 처리할 수 있음을 보여주며, Gemini는 종종 이를 구현하지 못한다는 점을 강조합니다. 그러나 LaTeX 작업에서 중복된 출력과 같은 가끔 발생하는 문제는 FineEdit-Pro가 일관되게 직접적인 편집 요구 사항을 준수하면서 불필요한 내용을 도입하지 않도록 개선이 필요함을 시사합니다.

반면, Gemini는 LaTeX 업데이트와 같은 더 단순한 작업에서 가끔 더 잘 수행합니다.

 

• 핵심 발견

FineEdit-Pro는 Gemini에 비해 DSL과 Code 편집을 더 잘 처리하지만, LaTeX 작업에서 중복된 출력과 같은 사소한 문제가 남아 있습니다. 전반적으로, FineEdit의 질적인 성능은 복잡한 편집 지시를 해석하고 실행하는 데 강력한 능력을 가지고 있음을 확인시켜줍니다.

 

4.5 Human Evaluation

DiffEval이 데이터셋 품질을 향상시키는지 평가하기 위해, 우리는 인간 평가를 진행했습니다. 엄격한 평가를 보장하기 위해 다음과 같은 지침을 설정했습니다:

1. 정확한 관찰: 수정된 내용이 편집 요청에서 지정한 부분과 정확히 일치하는지 확인합니다.
2. 의도되지 않은 수정 없음: 다른 섹션이 수정되지 않았는지 확인합니다. 예상치 못한 변경이 있을 경우 실패로 처리됩니다.
3. 3단계 절차: 두 명의 평가자가 각 항목을 독립적으로 검토하고, 세 번째 평가자가 불일치를 해결합니다.

각 카테고리에서 100개 항목을 검토한 결과, DiffEval 파이프라인을 통해 처리된 데이터는 눈에 띄게 향상된 정확도를 보였습니다 (표 3 참조). 특히 Wiki와 Code 데이터셋은 요청된 수정 사항과 정확히 일치하는 편집 내용을 보여 가장 신뢰할 수 있는 결과를 나타냈습니다. 특히 DSL 데이터셋은 품질이 24% 이상 향상되어 DiffEval의 기준을 충족하지 않은 데이터와 비교했을 때 가장 큰 향상을 보였습니다.

 

• 핵심 발견

DiffEval 파이프라인은 데이터셋 품질을 크게 향상시킵니다. Wiki와 Code 카테고리는 높은 정확도를 달성했으며, DSL 카테고리는 품질이 24% 이상 향상되었습니다.

 

5. 결론

• 이 연구는 LLM이 정확하고 표적화된 텍스트 수정을 수행하는 능력에서의 중요한 격차를 해결합니다.
• 우리는 InstrEditBench를 도입하여, Wiki 기사, LaTeX 문서, 코드 및 데이터베이스 DSL을 포함한 20,000개 이상의 구조화된 편집 작업을 제공하는 고품질 벤치마크를 제시합니다.
• LLM의 편집 능력을 더 발전시키기 위해, 우리는 이 벤치마크를 기반으로 훈련된 특수 모델인 FineEdit를 제안합니다. 

 

6. 제한 사항

1. 제한된 배포 범위: 비용과 하드웨어 제한으로 인해 우리의 평가는 대형 상용 LLM(예: Gemini)으로 제한되었으며, 대형 오픈 소스 모델에 대해서는 진행되지 않았습니다.
2. 제어된 컨텍스트 평가: 우리의 벤치마크는 제어된 평가 컨텍스트에 초점을 맞추고 있으며, 아직 긴 컨텍스트 체인 사고 시나리오를 포함하고 있지 않습니다. 작은 LLM은 제한된 컨텍스트 창에 갇혀 있지만, 이러한 기술이 상용 모델에서 효과적일 수 있습니다.