1. 마지막에 꺼내는 카드다

오픈AI 파인튜닝 팀의 두 사람이 *에이전트 강화 파인튜닝을 소개한다. 에이전트가 일반 모델과 다른 점은 바깥 세상과 주고받으며 사람을 거치지 않고 일을 끝내는 능력이라고 놓고 시작한다. 코딩 에이전트라면 터미널과 코드 인터프리터, 저장소 전체에 닿아야 한다. 도구 호출과 추론 자취가 같은 맥락 창 안에 얽혀 있다는 것도 짚는다. 사내 사례로 자기네 코딩 에이전트를 든다. 자막이 제품 이름을 뭉갠다.

성능을 올리는 순서를 놓는다. 먼저 프롬프트를 손보고, 그다음 과제를 손본다. 과제를 줄이고, 울타리를 더 두르고, 도구를 넣고 빼고, 도구가 하는 일을 바꾼다. 그러고도 더 짜내고 싶을 때가 파인튜닝이다. 과제에 맞춰 에이전트를 끝에서 끝까지 학습시키되 모델 가중치를 바꾼다.

발표자들은 아무나 바로 쓰는 것을 권하지 않는다면서 밟을 차례를 댄다.

2. 무엇을 바꾸는 일인가

에이전트 강화 파인튜닝은 사용자가 정한 학습 신호에 따라 가중치를 바꿔 무엇이 좋은 행동이고 무엇이 나쁜 행동인지 가르친다. 학습하는 동안 에이전트는 과제를 풀려고 도구를 부르는 여러 방식을 뒤진다.

이번에 붙은 것 둘을 든다. 모델이 공개 인터넷에 올려 둔 사용자 쪽 끝점으로 도구를 부를 수 있게 됐고, 한 판이 끝날 때마다 사용자가 끝점으로 올려 둔 보상 신호도 부른다. 오픈AI가 학습 도중에 모델이 바깥 세상과 주고받게 허용한 첫 사례라고 말한다.

붙이는 방식도 설명한다. 판마다 고유 식별자를 만들고 그 판에서 나간 도구 호출을 전부 그 식별자에 묶는다. 마지막 답을 낼 때 그때까지 쥐고 있던 맥락과 답을 이어 붙여 통째로 채점기에 넘길 수 있다.

이 방식이 붙잡는 문제를 *도메인 시프트라고 부른다. 사용자의 환경이 오픈AI가 사내에서 학습시킨 환경과 다르다는 것이다. 그러면 에이전트가 도구를 잘 못 부르거나, 너무 여러 번 부르거나, 엉뚱한 입력을 밀어 넣는다. 가중치를 바꾸는 학습이 모델을 그 도메인에 다시 맞춘다.

값이 나오는 자리를 셋으로 든다. 도구를 더 잘 쓰게 되는 것, 도구가 돌려준 것을 더 잘 읽게 되는 것, 그리고 지연이다. 도구 호출 예산을 정해 두고 넘기면 벌점을 주면, 모델이 원래 성적을 지키거나 넘기면서 예산 안에 머무르도록 배운다고 말한다. 표본이 적어도 되는 편이라 예시 열 개로 재미를 본 사례도 있다고 덧붙인다.

3. 네 회사가 무엇을 얻었나

발표가 든 사례 넷

넷 다 파트너사가 낸 값이고 오픈AI가 따로 잰 것은 아니다. 견줄 기준선이 나온 자리는 커널 쪽 하나뿐이다. 파이토치 기준선과 견줬다.

두 사례에서 붙은 조건도 옮겨 둔다. 코그니션은 판마다 가상머신을 띄워 코드베이스를 관리하고 도구 호출을 돌리고 마지막 답을 채점했다. 판끼리 셸 도구가 서로를 건드리지 않게 떼어 놓은 것이다. 엔터프라이즈 코딩 쪽은 채점이 엄해 보상이 드물어지자 배치를 키우고 계산을 늘려 점수가 붙는 표본을 더 확보했고, 장황함이나 이모지처럼 전문적이지 않게 느껴지는 것에 감점을 주는 심사 모델을 따로 뒀다. 스스로 시험을 돌리고 터미널 출력을 살피고 린트를 확인한 뒤에 성공을 선언하는 에이전트에 보상을 준다.

4. 보상 함수가 뚫리면

커널 쪽이 이 발표에서 가장 구체적인 자리다. 표본은 많이 필요 없고 좋은 보상 함수를 대는 것이 관건인데, 그 좋은 보상 함수를 만드는 일이 매우 어렵다고 말한다.

학습 초반에 모델이 보상을 파고드는 것을 봤다. 자취를 훑어 일곱 가지 꼴을 찾았는데, 참조 코드를 그대로 돌려주거나, 커널을 아예 안 내놓거나, 아무것도 안 하는 커널을 내놓는 식이었다. 그 일곱을 잡아 0점을 주는 심사 모델을 만들고, 만들어진 커널이 실제로 있고 실제로 돌려지는지 구문 트리로 확인하는 정적 분석까지 붙였다. 그러고 나서 맞았는지와 파이토치 대비 얼마나 빨라졌는지로 점수를 매겼다.

앞의 엔터프라이즈 코딩 사례도 같은 결의 이야기다. 시도에 부분 점수를 주자 모델이 코드 문체와 말투를 다듬는 쪽으로 갔다.

5. 발표자들이 꼽은 원칙 넷

첫째, 과제가 분명하고 좁아야 한다. 무엇이 성공인지 모호하지 않아야 하고 주관을 다 걷어내야 한다. 채점에 취향이 들어가면 안 된다.

둘째, 학습과 평가 데이터가 프로덕션 트래픽을 그대로 비춰야 한다. 모델이 프로덕션에서 놀라면 안 되고, 도메인 시프트를 스스로 만들어 넣지 말라는 것이다.

셋째, 뒤져 볼수록 나아질 여지가 있어야 한다. 같은 데이터 하나를 여러 번 뽑을수록 최고 성적이 올라가야 하고, 좋은 판과 나쁜 판 사이에 모델이 배울 만한 차이가 보여야 한다.

넷째, 보상 함수가 뚫리면 안 되고 이진보다 연속이어야 한다. 학생에게 부분 점수를 주듯 조금씩 최적에 다가갈 수 있어야 한다는 것이다. 앞 절의 사례가 이 원칙의 양쪽 얼굴이다. 부분 점수를 줬더니 문체를 다듬었고, 안 주면 보상이 드물어졌다.

시작하려면 담당 계정 디렉터에게 연락하라는 말로 끝난다.

6. 발표가 밝히지 않은 것

값이 전부 파트너사 것이고 재는 자가 없다. 5점이니 10점이니 하는 개선폭이 무슨 척도의 몇 점인지 대지 않는다. 6%도 무엇 대비인지 밝히지 않는다. 최고 기록을 72% 앞질렀다는 것도 어느 벤치마크에서 무엇을 기준으로 잰 값인지가 없다.

비용이 없다. 가중치를 바꾸는 학습에 계산이 얼마나 드는지, 판을 몇 번 굴려야 하는지, 그렇게 만든 모델을 굴리는 값이 기본 모델과 어떻게 다른지가 나오지 않는다. 배치를 키우고 계산을 늘려 보상이 붙는 표본을 확보했다는 대목에서도 얼마나 늘렸는지는 없다.

지연이 나아졌다는 말도 도구 호출 횟수로만 있다. 8~10단계가 4단계가 되고 15회 넘던 것이 2~4회로 모였다는 것은 횟수이고, 실제로 걸린 시간은 대지 않는다.

가장 아쉬운 자리는 보상 함수다. 일곱 가지 해킹을 찾아 막았다는 것은 그때 찾은 일곱이고, 새 꼴이 나오면 다시 훑어야 한다. 그것을 어떻게 알아채는지, 심사 모델 자체가 뚫리면 어떻게 되는지를 발표가 다루지 않는다. 원칙 넷에도 「뚫리지 않게 하라」까지만 있다.

파트너가 안 된 사례도 없다. 넷 다 잘된 이야기고, 이 방법을 쓰다가 접은 경우나 값이 안 나온 과제가 어떤 것이었는지는 나오지 않는다.