과도한 편집은 모델이 필요한 범위를 넘어서 코드를 수정하는 현상

• 최소 수정만으로 해결되는 버그에서도 함수 전체 재작성, 보조 로직 추가, 시그니처 변경까지 일어나며 거대한 diff가 생기기 쉬움
• 기존 구조를 유지하는 brown-field 작업에서는 테스트 통과만으로 충분하지 않고, 얼마나 적게 바꿨는지도 함께 봐야 검토 가능성과 변경 안전성이 유지됨
• 프로그램적으로 손상시킨 400개 BigCodeBench 문제를 바탕으로 토큰 단위 Levenshtein, 상대 패치 점수, Added Cognitive Complexity로 과도한 편집을 정량화함
• 최신 코딩 모델 전반에서 과도한 재작성 경향이 확인됐고, Claude Opus 4.6은 정확성과 최소 수정성 조합이 강했으며 GPT-5.4는 상대적으로 과도한 편집이 두드러짐
• 원본 보존을 명시한 프롬프트는 특히 추론 모델의 diff를 줄였고, 학습 방식 중에서는 RL이 최소 편집 행동을 익히면서 일반 코딩 성능 저하 없이 가장 균형 잡힌 결과를 냄

Over-Editing 문제

• Over-Editing은 버그를 고치는 데 필요한 최소 수정 범위를 넘어 코드 구조까지 크게 바꾸는 현상을 가리킴
  • 단순한 range(len(x) - 1)를 range(len(x))로 바꾸면 되는 오프바이원 버그에서도, 모델이 함수 전체를 다시 쓰고 보조 함수나 검증 로직을 추가하는 식의 과도한 변경이 발생함
  • 예시에서는 GPT-5.4가 None 검사, np.asarray(dtype=float) 변환, finite-value 마스킹, 배열 크기 검증, curve_fit 호출 시그니처 변경, 플로팅 로직 교체까지 수행했고, 테스트는 통과하지만 거대한 diff가 생김
• 기존 코드베이스를 다루는 brown-field 작업에서는 팀이 이미 이해하고 의도적으로 작성한 코드를 유지한 채 문제만 고치는 편이 중요함
  • 새로 만드는 green-field와 달리, 기존 구조를 존중하지 않는 수정은 리뷰어가 무엇이 왜 바뀌었는지 파악하기 어렵게 만듦
  • 함수 전체가 재작성되면 코드가 알아보기 어려워지고, 변경 안전성을 판단하기도 힘들어짐
• 테스트만 통과하면 된다는 기준으로는 이 문제를 잡기 어려움
  • Over-Editing은 정확성 실패가 아니라 편집 충실도 실패라서 테스트 스위트에 잘 드러나지 않음
  • 생성 코드가 많아질수록 검토해야 할 양이 늘고, 불필요한 복잡성이 누적되면서 코드베이스 품질이 조용히 떨어질 가능성이 커짐

Over-Editing 측정 방법

• 최소 수정의 정답이 분명한 데이터셋을 만들기 위해 BigCodeBench 문제 400개를 프로그램적으로 손상시켜 평가셋을 구성함
  • 기존 벤치마크처럼 다른 LLM으로 버그를 주입하지 않고, <를 <=로 바꾸거나 +를 -로, True를 False로 바꾸는 식으로 세밀하게 통제함
  • 각 손상 샘플은 문법적으로 유효하며 대응 테스트 케이스를 깨뜨리도록 검증했고, 정답 수정은 손상을 되돌리는 것 하나뿐이어서 최소 수정이 되도록 설계됨
• 이 구성 덕분에 모델이 버그를 고쳤는지뿐 아니라, 고치는 과정에서 얼마나 더 바꿨는지도 함께 평가할 수 있음
  • 기준 정답과 모델 출력을 모두 손상된 입력과 비교해 상대적 패치 크기를 계산함
  • 정답 복원 외 추가 변경이 많을수록 점수가 나빠지도록 구성됨
• 관련 코드는 GitHub 저장소에서 제공됨

측정 지표

• 토큰 단위 Levenshtein Distance

  • 일반적인 문자 단위 Levenshtein 대신 Python 토큰 단위 변형을 사용함
  • 코드를 Python tokenizer로 def, add, (, a, ,, b, ) 같은 원자적 문법 단위로 나눈 뒤, 이 토큰 시퀀스 위에서 거리를 계산함
  • def add(a, b):를 def someotherfunctionname(a, b):로 바꾸는 경우 문자 단위 거리는 19지만, 토큰 단위 거리는 식별자 하나가 바뀐 것으로 간주되어 1이 됨
  • 함수 길이가 달라도 비교할 수 있도록 총 토큰 수로 정규화함

• 상대 패치 점수

  • 모델 출력과 정답을 직접 비교하지 않고, 둘 다 손상된 입력을 기준으로 비교함
  • 손상된 해답에서 원래 해답으로 되돌리는 편집이 진짜 최소 수정이고, 모델이 만든 편집이 여기에 얼마나 가까운지 측정함
  • 값이 0에 가까울수록 모델 패치가 실제 최소 수정과 유사함

• Added Cognitive Complexity

  • Cyclomatic Complexity보다 읽기 난이도를 더 잘 반영하는 Cognitive Complexity를 함께 사용함
  • 중첩, 재귀, 복합 논리 연산자, 비직관적 제어 흐름에 페널티를 주며, if, 루프, try/except처럼 독자가 상태를 더 많이 추적해야 하는 구조가 복잡도를 높임
  • 예시의 중첩 루프와 조건문 코드는 Cognitive Complexity가 6이 됨
  • 이번 손상은 값만 바꾸고 구조는 건드리지 않으므로, 올바른 수정은 Added Cognitive Complexity가 항상 0이어야 함
  • 모델 출력에서 복잡도가 증가했다면 요청받지 않은 코드가 추가된 것이고, 0보다 작은 값도 불필요한 단순화라 바람직하지 않다고 봄

모델들은 실제로 Over-Edit하는가

• 최신 frontier 모델에서도 Over-Editing이 확인됨
  • 추론 모델과 비추론 모델 모두 Pass@1과 최소 수정성 사이에 차이가 존재함
  • 정확히 고치는 능력만으로는 충실한 편집 여부를 판단하기 어려움
• 추론 모델 비교에서는 Claude Opus 4.6이 가장 강한 조합을 보임
  • Pass@1이 0.912로 가장 높고, 정규화 Levenshtein 0.060, Added Cognitive Complexity 0.200으로 diff도 가장 작음
  • Gemini 3.1 Pro Preview도 비슷한 영역에 위치하고, 오픈 웨이트 모델 중에서는 GLM 5가 상대적으로 보수적으로 편집함
• GPT-5.4는 평가된 모델 중 Over-Editing이 가장 심한 축에 속함
  • 추론 모드에서 Levenshtein 0.395, Added Cognitive Complexity 2.313이고, 비추론 모드에서도 각각 0.327, 1.563으로 높게 나타남
  • Pass@1도 0.723, 0.770으로 낮은 편이라 정확성과 최소 수정성 모두 약한 결과를 보임
• 비추론 모델에서는 Qwen 3.6 Plus가 Pass@1 0.870으로 가장 높고, GLM 5가 Added Cognitive Complexity 0.235로 가장 낮음
  • Claude Opus 4.6 비추론 모델도 Levenshtein 0.079, Added Cognitive Complexity 0.313으로 매우 작은 변경 폭을 유지함

프롬프트로 개선되는가

• 프롬프트에 “IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible”를 추가했을 때 모든 모델의 Levenshtein Distance가 감소함
  • DeepSeek R1/v3를 제외하면 Pass@1도 함께 개선됨
  • 최소 수정 제약이 가능한 수정 공간을 좁혀 더 정확하고 표적화된 변경으로 유도하는 해석이 가능함
• 이 효과는 특히 추론 모델에서 더 크게 나타남
  • 명시적 지시를 더 잘 따르는 특성 때문에, 편집 최소화 요구가 diff 축소로 강하게 이어짐
  • 기본 상태에서는 과하게 손대더라도, 지시가 주어지면 더 충실한 수정으로 이동할 수 있음을 보여줌

추론은 과도한 재작성으로 이어지는가

• 같은 모델 계열의 추론형과 비추론형을 짝지어, 둘 다 정답을 맞힌 샘플만 대상으로 Levenshtein Distance를 비교함
  • 실패 샘플이 많으면 Over-Editing 기회 자체가 줄어드는 편향이 생기므로, 정확성을 통제한 뒤 편집 스타일만 분리해 본 것임
• 일반 프롬프트 설정에서는 대부분의 짝에서 추론 모델이 더 많이 재작성함
  • DeepSeek V3, GPT-5, GPT-5.4, Gemini 3.1 Pro Preview, Qwen 3.6 Plus, Kimi 2.5는 모두 추론 바가 더 높게 나타남
  • 확장된 추론이 최소 수정 대신 “더 나은 구현”으로 향하면서 불필요한 리팩터링을 낳는 경향이 드러남
  • 예외는 Claude Opus 4.6으로, 추론형이 비추론형보다 훨씬 덜 수정함
• 명시적으로 원본 보존을 지시하면 그림이 크게 달라짐
  • 추론 모델은 거의 모든 짝에서 비추론형과 같거나 더 낮은 Levenshtein Distance를 보임
  • Claude Opus 4.6 추론형은 이 설정에서 전체 모델 중 가장 낮은 Levenshtein을 기록함
  • GPT-5와 GPT-5.4도 추론형 점수가 크게 떨어지지만, GPT-5.4는 비추론형이 여전히 근소하게 앞섬
• 기본 동작으로는 추론 모델이 Over-Editing하기 쉽지만, 같은 추론 능력이 제약을 더 잘 따르게도 만듦
  • 일반 설정과 명시 설정의 차이가 추론 모델에서 일관되게 더 크게 나타남
  • 따라서 Over-Editing은 근본적 한계라기보다 기본 행동에 가깝고, 제약을 통해 뒤집을 수 있음

학습으로 충실한 편집자를 만들 수 있는가

• 기본 모델로 Qwen3 4B 2507 Instruct를 사용하고, 0-shot과 8-shot에 원본 보존 지시를 넣은 구성을 베이스라인으로 삼음
  • 다른 학습 방식들은 평가 시 명시적 원본 보존 지시 없이 일반 설정으로 테스트함

• 실험 구성

  • DeepCoder 문제를 같은 방식으로 손상시켜 합성 데이터셋을 만듦
  • 여기에 더해 기본 Qwen3 4B 2507 Instruct가 각 문제에 대해 8개 completion을 생성하게 하고, 기능적으로 맞는 샘플만 남긴 뒤 Levenshtein Distance로 순위를 매겨 self-distillation 데이터셋도 구성함
  • 학습은 Context Distillation과 비슷하게, 평가 때는 명시 지시 없이 최소 편집 행동을 하도록 맞춤

• 학습 방법

  • SFT: 프로그램적으로 만든 데이터셋으로 직접 지도 미세조정함
  • rSFT: self-distillation 데이터셋에서 샘플마다 Levenshtein Distance가 가장 낮은 3개 completion만 골라 학습함
  • DPO: 샘플마다 Levenshtein Distance가 가장 높은 completion과 가장 낮은 completion 사이에서 선호 최적화를 수행함
  • RL: 기능적 정확성과 Levenshtein 기반 최소 편집 보상을 합친 강화학습을 적용함
    • 모든 테스트를 통과하면 r = r_edit + 0.1
    • 통과하지 못하면 r = -0.2
    • r_edit는 정규화 Levenshtein 기반 보상으로 계산됨

같은 손상 유형에서는 어떻게 나왔는가

• 학습셋과 테스트셋의 손상 유형이 같은 in-domain 설정에서는 SFT가 거의 완벽에 가까운 결과를 냄
  • Baseline 0-shot은 Pass@1 0.735, Norm. Levenshtein 0.169, Added CC 0.731
  • Baseline 8-shot은 Pass@1 0.775, Norm. Levenshtein 0.115, Added CC 0.479
  • SFT는 Pass@1 0.932, Norm. Levenshtein 0.002, Added CC 0.000으로 세 지표 모두 최고를 기록함
  • rSFT는 0.782 / 0.100 / 0.435, DPO는 0.752 / 0.021 / 0.113, RL은 0.802 / 0.046 / 0.112를 기록함
• 이 결과가 지나치게 좋아 보여, 특정 손상 유형의 역변환만 암기했을 가능성을 점검하게 됨
  • 모델이 일반적인 최소 편집 행동을 배운 것이 아니라, 정해진 손상 패턴만 뒤집도록 학습했을 수 있다고 봄
  • 이를 확인하려고 학습 데이터와 평가 데이터의 손상 유형을 완전히 다르게 다시 구성함

다른 손상 유형에도 일반화되는가

• 학습셋과 테스트셋의 손상 유형이 다른 out-of-domain 설정에서는 SFT가 크게 무너짐
  • SFT의 Pass@1은 0.458까지 떨어지고, 모델이 실제로 버그를 고치지 못한 채 특정한 최소 변경만 시도하는 상태가 됨
  • Norm. Levenshtein은 -0.008, Added CC는 0.006으로 매우 낮지만, 정답 수정 능력이 붕괴함
• rSFT와 DPO는 8-shot 베이스라인보다 소폭 나아지지만 개선 폭은 작음
  • rSFT는 0.780 / 0.107 / 0.501 / LiveCodeBench -0.069
  • DPO는 Pass@1 0.787 / 0.092 / 0.348 / LiveCodeBench -0.046
  • 기본 모델이 스스로 만든 추적 데이터를 이용한 학습만으로도 어느 정도 일반화는 가능함
• RL만이 세 지표 전반에서 깔끔하게 일반화함
  • RL은 Pass@1 0.782, Norm. Levenshtein 0.050, Added CC 0.185, LiveCodeBench Change +0.006을 기록함
  • 두 베이스라인보다 세 지표가 모두 좋아지고, 일반 코딩 성능도 떨어지지 않음
  • Levenshtein과 Added Cognitive Complexity 개선 폭이 Pass@1보다 더 큰 점은, 단순한 손상 역변환 암기가 아니라 최소 편집 행동 자체를 학습했음을 뒷받침함

Catastrophic Forgetting

• 최소 편집을 위해 미세조정했을 때 일반 코딩 능력이 떨어지는지도 LiveCodeBench v6로 확인함
  • 목표는 학습 후에도 원래 pretrained 모델과 비슷한 수준을 유지하는 것임
• SFT는 일반 능력 저하가 매우 큼
  • LiveCodeBench에서 43% 성능 저하가 나타났고, 기본적인 버그 식별과 수정 능력도 유지하지 못함
• rSFT와 DPO도 소폭 하락함
  • 원래 모델이 생성한 샘플로 학습했어도, 작업 특성상 일정 수준의 Catastrophic Forgetting이 남아 있음
• RL은 성능 저하 없이 새 행동을 학습함
  • 일반 코딩 능력을 유지하면서 최소 편집 작업 성능도 가장 좋게 개선함
  • 이는 SFT memorizes while RL generalizes와 맞닿아 있음
• 분포 관점에서는 프로그램적으로 만든 데이터셋과 원래 모델 분포의 차이가 클수록 Forgetting이 커지는 해석도 가능함
  • SFT는 원래 분포와 많이 다른 데이터에 강하게 맞춰지면서 모델 분포가 크게 바뀜
  • rSFT와 DPO는 self-distilled 데이터가 원래 분포와 더 가깝기 때문에 변화가 덜 거칠게 일어남
  • Catastrophic Forgetting의 정도는 원래 분포와 작업 학습 데이터 분포 차이에 비례할 가능성이 큼

추가 실험

• RL with LoRA: 전체 미세조정이 필요한가

  • 이 작업은 새 지식을 넣기보다 기존 코드 수정 능력의 스타일 조정에 가까워 LoRA로도 충분할지 점검함
  • rank 1은 Pass@1 0.738, Norm. Levenshtein 0.166, Added CC 0.676, LiveCodeBench Δ -0.022
  • rank 8은 0.775 / 0.112 / 0.426 / -0.022
  • rank 16은 Pass@1 0.805 / 0.087 / 0.328 / -0.005
  • rank 32는 0.795 / 0.065 / 0.235 / -0.011
  • rank 64는 0.797 / 0.051 / 0.160 / +0.001
  • Full RL 최고 모델은 0.782 / 0.050 / 0.185 / +0.006
  • rank 64 LoRA는 Levenshtein에서 Full RL에 거의 근접하고 Added CC에서는 더 좋게 나옴
  • rank가 커질수록 Levenshtein과 Added CC가 1에서 64까지 단조롭게 감소함
  • 큰 개선은 초반에 집중되어 rank 1→16에서 Levenshtein이 0.166→0.087로 크게 줄고, 16→64는 0.087→0.051로 점진적으로 좁혀짐
  • rank 1과 8은 정확성과 최소 편집성 사이의 절충이 나타나며, 두 보상 함수를 함께 학습할 용량이 부족해 더 높은 보상인 편집 최소화 쪽으로 치우쳤을 가능성이 있음
  • 기존 능력이 이미 있는 작업의 스타일 수준 행동 변화에는 소수의 추가 파라미터로도 충분하고, 일정 지점 이후 추가 용량의 수익은 줄어듦

• 보상 해킹 메모

  • 초기 보상 함수에는 성공 실행이 하나도 없는 rollout에 0점을 주는 버그가 있었음
  • Levenshtein을 “클수록 좋음” 형태로 만들기 위해 부호를 바꾼 상태라, 이 0점이 오히려 성공 실행보다 더 높은 보상이 되는 상황이 생김
  • 그럼에도 Full RL은 작업을 학습했고, LoRA에서만 기능적으로 올바른 코드를 아예 출력하지 않는 식의 reward hacking이 나타나 환경 점검으로 이어짐
  • 보상 함수를 수정한 뒤 Full RL 결과는 소폭만 더 좋아짐

• 더 큰 모델에도 확장되는가

  • 같은 out-of-domain RL 레시피를 Qwen3 14B에 적용함
  • Baseline 14B는 Pass@1 0.770, Norm. Levenshtein 0.136, Added CC 0.315
  • RL 적용 후에는 Pass@1 0.833, Norm. Levenshtein 0.059, Added CC 0.165, LiveCodeBench Δ +0.011로 전반 개선이 나타남
  • 파라미터 수가 커져도 Pass@1 상승, Levenshtein 감소, Added Cognitive Complexity 감소, Catastrophic Forgetting 부재가 함께 유지됨
  • 최소 코드 편집용 RL 레시피가 여러 규모의 모델로 확장될 가능성을 뒷받침함

최종 정리

• Over-Editing은 널리 퍼져 있고 측정 가능한 문제로 나타남
  • frontier 코딩 모델 전반에서 정확히 고치는 능력과 최소한으로 고치는 능력이 별개로 드러남
  • 특히 GPT-5.4는 기본 설정에서 상대적으로 과도한 재작성 경향이 강하고, Opus 4.6은 강한 베이스라인을 보임
• 명시적 프롬프트만으로도 충실한 편집으로 상당 부분 유도 가능함
  • 특히 추론 모델은 기본적으로 과하게 손대는 경향이 있지만, 원본 보존 지시를 주면 더 잘 따름
  • GPT-5.4도 추론 모드에서 큰 개선 폭을 보여 instruction following 능력 자체는 강하게 드러남
  • Opus 4.6의 개선 폭이 작게 보이는 것은 이미 기본 성능이 높기 때문일 수 있음
• 학습 측면에서는 RL이 가장 균형 잡힌 해법으로 나타남
  • 더 충실한 편집 행동을 익히면서 일반 코딩 능력을 해치지 않았고, 4B와 14B Qwen3 모두에서 효과가 유지됨
  • SFT는 특정 손상 유형에는 강했지만 일반화와 일반 능력 유지에서 크게 실패함
• 단일 함수 단위 버그 수정 평가는 SWE-Bench Pro 같은 더 agentic한 평가보다 범위가 제한적이지만, 현실적인 설정에서 Over-Editing을 정량화하기 어려웠던 문제를 다루는 출발점이 됨
  • 최소 편집 능력을 평가하고 개선하는 방향이 AI 생성 코드의 전반적 품질 향상으로 이어질 수 있음