← 모든 독해

업데이트 검토 AI를 고쳤더니, 별도 시험 점수는 떨어졌다

Laya의 질문과 입력을 바꿔 개발 점수를 높였다. 별도 14건에서 확인 대상 하나를 놓쳤다. 실행 코드와 테스트 가이드로 개선과 검증의 차이를 살펴본다.

새 라이브러리의 변경 목록을 읽는 일과 내 프로젝트에 영향을 주는 항목을 찾는 일은 다르다. 예를 들어 BackgroundTasks를 사용한다는 사실만으로 app.frontend() 안에서 고친 백그라운드 작업 문제가 우리 코드에 적용된다고 볼 수는 없다. 변경의 적용 범위와 실제 사용 근거를 함께 확인해야 한다.

이번에는 이 일을 돕는 업데이트 검토 도구를 만들었다. 입력은 공식 변경 내용과 프로젝트의 기능 사용 설명이다. 출력은 확인 필요·관련성 낮음·판단 보류 세 가지다. 모델이 패키지를 설치하는 것이 아니라 읽을 순서를 제안한다.

01

실행 코드에서 시작하기

수집 단계는 일반 Python 코드다. 실제 설치 버전을 읽고 공식 릴리스 저장본에서 중복을 제거한 뒤 새로운 변경을 남긴다. 이번 범위는 FastAPI와 Transformers의 릴리스 24건이며 PR번호가 붙은 변경 835개 중 314개가 설치 버전보다 새 항목이었다. 전체 변경 이력을 빠짐없이 모은 자료는 아니다.

판단 단계에서는 프로젝트 설명과 변경 내용으로 입력을 만들고 predict()를 호출한다. 로컬에서 실행할 수 있는 Laya 다국어 모델을 사용했다. Jev는 같은 입력·출력 조건의 별도 비교 대상으로 실제 호출했다. Jev 호출은 기존에 충전한 API를 썼으며 무료 API로 표시하지 않는다. Laya도 장비·전력 비용까지 사라지는 것은 아니다.

자료: 프로젝트 업데이트 검토 실험 코드 · github.com

02

자기개선에서 실제로 고친 것

이번 실험에서 Laya의 가중치는 고정했다. 별도의 코딩 모델이 질문 문구와 프로젝트 설명을 고르는 설정을 바꿨다. 수정 대상은 같은 모델을 사용하는 프로그램의 설정이다.

RRSI는 Regularized Recursive Self-Improvement of Agent Harnesses의 약자다. 고정 모델 주변의 프로그램을 반복해서 수정할 때 연습 자료에만 맞는 개선을 덜 선택하려고 탐색·선택에 규칙을 둔다. 공식 방법에는 수정량 제한, 이력 활용, 답을 외워 넣는 수정 검사, 점수·비용 조건 등이 있다. 이번에는 공개 평가·선택 모듈을 제한된 설정 후보 세 개에 적용했다. 반복 탐색 전체를 재현한 실험은 아니다.

검토 기준 32건은 AI가 원문과 사용 코드를 대조해 작성했다. 독립 사람의 정답이나 실제 업그레이드 성공 판정이 아니다. 수정에 18건을 쓰고 관련 변경 계열을 분리한 14건은 코딩 모델에 전달하지 않았다. 후보 선택을 동결한 뒤 별도 자료를 평가했다. 영상 촬영용 재실행은 이 자료와 설정을 다시 실행한 것이며 새 독립 시험이 아니다.

세 후보 중 세 번째가 프로젝트 설명을 full에서 compact로 바꾸고 질문 문구를 수정했다. 개발용 자료에서 기준 일치는 8/18에서 10/18로 올랐다. 나머지 두 후보는 1/18, 3/18로 나빠졌고 선택 규칙에서 탈락했다.

자료: RRSI 원본 평가·선택 코드 · github.com · Regularized Recursive Self-Improvement of Agent Harnesses · arxiv.org

03

별도 자료에서는 결과가 달랐다

수정한 설정을 별도 14건에 적용하자 9/14에서 8/14로 낮아졌다. 실제로 쓰는 tokenizers 패키지의 허용 버전 변경을 이전에는 판단 보류로 남겼지만 수정 후에는 관련성 낮음으로 보냈다. 검토 기준은 확인 필요였다. 입력 설명과 질문을 함께 바꿨으므로 입력 축약만을 원인으로 단정할 수 없다.

같은 후보에서 단순히 최고 점수만 고르는 방법도 세 번째를 선택했다. 이번 실행은 RRSI의 추가 이점을 입증하지 못했다. 그렇다고 부분 적용의 작은 실험으로 전체 방법이 효과 없다고 일반화할 수도 없다.

Jev는 별도 14건 중 11건이 기준과 일치했다. 하지만 낮음이 11건인 자료여서 전부 낮음이라고 답해도 같은 점수가 나온다. 두 방법은 확인 대상 누락에서 차이가 있었다. Jev는 tokenizers 항목을 확인 필요로 남겼지만 낮은 관련성 2건도 검토/조사로 올렸다. 총점과 실제 검토 부담을 함께 봐야 하는 이유다.

추가로 MPS 관련 수정의 공식 변경 파일을 확인했다. 변경된 것은 여러 비전 모델 파일이고 실제 사용 모델은 modernbert였다. 파일 목록을 추가하자 Jev는 확인 필요에서 관련성 낮음으로 바뀌었다. 이 한 건은 기존 개발용 사례를 추가 조사한 것이며 새 일반화 평가가 아니다.

AI 작성 검토 기준과 별도 14건의 일치 및 누락
판정 방법기준 일치확인 필요→낮음 누락낮음을 검토·조사로 올린 수
Laya 초기9/1402
Laya 수정 후보8/1414
Jev11/1402
전부 낮음11/1410
04

가져갈 구현 순서

이번 수정안은 별도 평가에서 개선되지 않았으므로 운영 설정으로 자동 승격하지 않았다. 자기개선을 켜는 것보다 좋아졌는지 확인할 시험을 먼저 만드는 것이 이번 프로젝트의 결론이다. 실행 코드와 예제 데이터는 공개 저장소에서 받을 수 있다. 테스트 가이드에 설치, 저장 결과 재계산, 실제 모델 실행, 새 수정안 생성, 결과 해석을 정리했다.

저장소를 받은 뒤 모델 없이 예제 자료와 점수를 다시 계산할 수 있다. Laya 설치와 고정 모델 다운로드를 마치면 한 건 실행과 전체 후보 비교를 진행한다. 저장된 결과를 보여 주는 명령과 실제 모델을 호출하는 명령을 가이드에서 구별했다. 같은 자료를 다시 실행해 수치가 맞는지 확인하는 과정이며 새로운 독립 시험은 아니다.

자료: 설치·테스트·결과 해석 가이드 · github.com

FACT BOUNDARY

과장하지 않기 위해 남긴 경계

  • 검토 기준은 AI가 원문과 사용 코드를 대조해 작성했다. 독립 사람이 검증한 정답이나 실제 업그레이드 성공률이 아니다.
  • RRSI 평가·선택 모듈의 제한된 적용이며 전체 논문 재현이나 RRSI의 추가 효과를 입증한 실험이 아니다.
  • Jev는 기존 유료 API 실측을 비교했다. 공개 프로젝트에서 새 Jev 호출은 하지 않는다.
SOURCE LEDGER

확인한 공개 자료

  1. 01프로젝트 업데이트 검토 실험 코드 · github.com
  2. 02RRSI 원본 평가·선택 코드 · github.com
  3. 03Regularized Recursive Self-Improvement of Agent Harnesses · arxiv.org
  4. 04설치·테스트·결과 해석 가이드 · github.com