Google 연구진, 자기 개선 AI 에이전트의 테스트 암기를 막기 위한 RRSI 제안

Google 연구진이 자기 개선 AI 에이전트의 테스트 암기를 억제하고, 보지 못한 벤치마크 점수를 높이는 동시에 런타임 토큰 사용량을 줄이기 위한 RRSI를 제안했다.

AI News

Google 연구진이 최적화에 사용된 작업에 AI 에이전트가 과적합하지 않도록 하면서 에이전트를 개선하는 방법을 제안했다. Regularized Recursive Self-Improvement of Agent Harnesses, 줄여서 RRSI라고 불리는 이 접근법은 시스템이 자체 프롬프트, 워크플로, 도구, 메모리 로직을 자동으로 다시 작성할수록 심각해지는 문제를 겨냥한다.

The Decoder가 소개한 연구 논문에 따르면 RRSI는 이전에 보지 못한 벤치마크의 결과를 최대 4.7점 높였고, 비정규화 최적화 방식보다 런타임 토큰을 약 30% 적게 사용했다. 보고된 성과는 모델 가중치를 업데이트하는 대신 동결된 모델을 둘러싼 에이전트 하니스를 변경해 얻은 것이다.

에이전트 하니스가 대상이 되는 이유

많은 프로덕션 AI 에이전트는 고정된 언어 모델과 이를 둘러싼 에이전트 하니스로 구성된다. 프롬프트, 도구 호출, 워크플로 규칙, 메모리 시스템, 복구 동작, 출력 처리가 모델의 작동 방식을 결정한다. 하니스는 에이전트가 파일을 편집하기 전에 확인할지, 오류 후 재시도할지, 최종 응답을 어떻게 구성할지 결정할 수 있다.

Google Cloud AI Research의 연구진과 대학 공동 연구자들은 이 계층의 개선을 자동화하는 방법을 연구하고 있다. 일반적인 재귀적 자기 개선 루프에서는 언어 모델이 하니스 변경을 제안하고, 작업 집합을 대상으로 평가한 뒤, 그 결과를 사용해 추가 변경을 생성한다.

문제는 소규모 테스트 모음에서 반복적으로 최적화하면 에이전트가 해당 테스트에는 더 강해지면서도 전반적인 능력은 향상되지 않을 수 있다는 점이다. 시스템은 벤치마크에 특화된 패턴을 학습하거나 우연히 성공하는 변경을 선택하거나, 측정 점수는 높이지만 비용과 취약성을 키우는 불필요한 복잡성을 축적할 수 있다.

이 문제는 AI 에이전트가 제한된 작업 모음으로 평가되는 반면, 실제 배포 환경은 훨씬 예측하기 어렵기 때문에 중요하다. 익숙한 워크플로에서 잘 작동하는 하니스도 파일 구조, 지시사항, 도구 또는 사용자 목표가 바뀌면 실패할 수 있다.

RRSI가 과적합을 제한하는 방식

RRSI는 최적화 과정의 두 지점에 제어 장치를 적용한다. 후보 수정안을 생성할 때 하나의 제안에 묶을 수 있는 독립적인 편집 수를 제한한다. 허용되는 편집 수는 시간이 지나면서 줄어들어, 광범위한 재설계에서 더 정밀한 수정으로 과정이 이동한다.

시스템은 이전 시도도 기록해 이미 실패한 변경을 반복적으로 탐색하지 않도록 돕는다. 진행이 멈추면 아직 검토되지 않은 하니스 부분으로 실험을 유도한다.

별도의 비평기가 제안된 변경이 영구 적용되기 전에 평가한다. 작업 이름, 해법 또는 기타 벤치마크 특화 동작을 하드코딩하는 것처럼 보이는 수정안을 거부한다. RRSI는 계산 비용을 높이는 변경을 수용하기 전에 관찰 가능한 성능 향상도 요구하며, 더 이상 기여하지 않는 구성 요소는 제거한다.

이 규칙들은 좁은 테스트 점수를 극대화하는 공격적인 변경보다 새로운 작업으로 이전되는 작고 설명 가능한 개선을 우선하도록 설계됐다. 이 방법은 하니스를 편집 가능한 상태로 유지하지만, 스스로를 얼마나 빠르고 자유롭게 다시 작성할 수 있는지는 제한한다.

보고된 결과가 보여주는 것

연구진은 코딩, 사무 업무 중심 에이전트 작업, 엔지니어링 설계를 포함하는 8개 벤치마크에서 RRSI를 테스트했다. 보고서에서 Claude Opus 4.8로 확인된 기반 모델은 동결된 상태로 유지됐다. 비교 대상에는 수정하지 않은 기준 하니스와 4개의 다른 최적화 방법이 포함됐다.

연구진이 보고한 결과는 상충 관계를 보여준다. RRSI는 최적화에 사용된 작업에서 최대 14.1점의 향상을 냈지만, 더 중요한 결과는 5개의 보지 못한 벤치마크에서 나타났다. 이곳에서 최대 개선 폭은 4.7점이었다. The Decoder가 전한 논문에 따르면 RRSI 하니스는 해당 보지 못한 평가 중 어느 것도 기준선보다 낮지 않았다.

다른 접근법은 훈련 작업에서는 강한 성능을 보였지만 새로운 작업으로의 이전은 덜 효과적이었던 것으로 보고됐다. 두 방법은 새로운 작업에서 기준선보다 낮았다. 테스트된 변형 중 RRSI의 훈련 세트 개선 폭은 가장 작았으며, 연구진은 이를 벤치마크 특화 대신 더 폭넓은 일반화를 선택한 증거로 해석했다.

토큰 관련 결과는 에이전트를 대규모로 운영하는 팀에도 중요하다. 최적화된 RRSI 시스템은 비정규화 버전보다 약 30% 적은 토큰을 사용했고, 최적화된 하니스 가운데 필요한 단계도 더 적었다. 그러나 기존 기준선이 여전히 더 경제적이었으므로, 정규화가 모든 대안보다 전체 시스템을 저렴하게 만든 것은 아니다.

이는 독립적인 프로덕션 벤치마크가 아닌 연구 결과다. 성능 수치는 연구진 평가에서 나온 주장이고, 현재의 근거만으로는 더 큰 작업 분포, 다른 모델 또는 실제 기업 워크로드에서 이 방법이 어떻게 작동할지 알 수 없다.

AI 개발자와 구매자에게 주는 의미

개발자에게 이 연구는 에이전트 개선이 개발 벤치마크의 점수 극대화보다 더 많은 것을 포함해야 한다고 시사한다. 평가 세트에는 최적화 과정이 한 번도 보지 못한 작업이 포함되어야 한다. 그렇지 않으면 자기 개선 시스템은 근본적인 워크플로를 개선하는 대신 테스트를 학습한 것에 보상을 줄 수 있다.

RRSI의 설계는 재귀적 자기 개선을 위한 운영 통제도 제시한다. 팀은 동시 변경 수를 제한하고, 실패한 실험의 기록을 유지하며, 더 비싼 워크플로에는 비용 정당화를 요구하고, 특정 테스트 사례와 연결된 것으로 보이는 편집을 차단할 수 있다. 이런 통제는 자동화된 하니스 최적화를 감사하고 되돌리기 쉽게 만들 수 있다.

이 접근법은 엔터프라이즈 AI에 특히 관련될 수 있다. 이 분야에서는 토큰 비용, 예측 가능한 동작, 다양한 내부 프로세스에서의 신뢰성이 최고 벤치마크 점수만큼 중요하다. 익숙하지 않은 문서나 절차에도 일반화되는 하니스가 고정된 시연 모음에서 더 높은 점수를 얻는 하니스보다 유용할 수 있다.

이 연구는 자체 운영 로직을 바꾸는 에이전트를 둘러싼 더 넓은 안전성과 거버넌스 문제를 해결하지 않는다. RRSI는 하니스 변경을 제한하지만, 비평기가 숨겨진 벤치마크 특화 동작을 모든 형태에서 안정적으로 찾아낼 수 있는지는 근거가 보여주지 않는다. 최적화 중 모델 가중치가 바뀌는 시스템도 다루지 않는다.

그럼에도 모델 간 이전 결과는 주목할 만하다. Gemini 3.5 Flash로 발견한 코딩 하니스가 후자의 모델을 수정하지 않고 더 약한 Gemini 3.1 Flash Lite의 정확도를 11.2점에서 14.6점으로 높였다고 보고됐다. 이는 일부 워크플로 개선이 서로 다른 능력의 모델 사이에서도 이전될 수 있음을 시사하지만, 같은 연구 보고서에서 나온 결과인 만큼 더 폭넓은 검증이 필요하다.

다음에 주목할 점

첫 번째 신호는 추가 모델과 작업군에서 RRSI를 독립적으로 재현하는 것이다. 결과는 하니스 최적화기와 비평기 모두에게 숨겨진 보류 작업을 대상으로 비교해야 한다.

연구자와 제품 팀은 배포 후 도구, 프롬프트, 메모리 저장소, 데이터 분포가 바뀌어도 이 방법이 효과적인지 테스트해야 한다. 비용 측정도 중요하다. 보고된 30% 토큰 감소는 비정규화된 최적화 시스템과 비교한 수치이지, 신중하게 설계된 기준선과 비교한 수치가 아닐 수 있다.

또 다른 미해결 문제는 주변 하니스뿐 아니라 모델 가중치를 업데이트하는 에이전트에도 유사한 통제를 적용할 수 있는지다. 현재 연구는 동결 모델을 다루므로 더욱 중대한 형태의 자기 개선은 범위 밖에 남아 있다.

Creati.ai의 관점

RRSI는 현재 에이전트 경쟁의 실용적인 약점을 다룬다. 팀은 더 나은 워크플로를 찾는 작업은 그 어느 때보다 빠르게 자동화할 수 있지만, 해당 워크플로가 일반화되는지 판단하는 속도는 그만큼 빠르지 않다. 따라서 가장 중요한 기여는 방법론적이다. 단일 최적화 점수에 의존하지 않고 보지 못한 작업에서의 성능과 계산 비용을 핵심 제약으로 다룬다.

이 연구는 재귀적 자기 개선이 감독 없는 배포에 준비됐다는 것을 증명하지 않는다. 그러나 개발자에게 더 명확한 설계 원칙을 제시한다. 에이전트는 변경을 만들어낸 테스트를 넘어 신뢰할 수 있는 향상을 보여야 더 복잡해질 자격을 얻어야 한다.

광고