스킬 5만여 개를 색인해 보니 평가가 딸린 것이 거의 없고, AI가 쓴 스킬은 성능을 되레 떨어뜨릴 수 있다는 조사 결과. 스킬 설명이 부를 때마다 백에서 이백 토큰을 무는 상시 비용이라는 셈, 케이스 117개로 성공률을 90% 가까이 올린 실제 사례, 정규식만으로 값싸게 채점하는 방법, 그리고 스킬을 언제 버릴지 정하는 켜고 끄기 대조가 나옴. 실패의 절반이 스킬을 잘못 불러서였다는 자기 고백도 담김.
한줄 코멘트. 스킬은 공짜가 아니다라는 셈이 이 발표의 뼈대다. 설명 한 줄이 모델을 부를 때마다 실리므로 상시 비용이고, 그러니 값을 하는지 재야 한다는 것이다. 값나가는 대목이 하나 더 있다 — 켜고 끈 채로 나란히 돌려 봐서 스킬 없이도 되면 그 스킬을 버린다는 규칙이다.
구글 딥마인드에서 API와 에이전트 쪽 일을 한다는 사람이 발표한다.
여는 수가 세다. 스킬 5만 개 넘게 색인한 벤치마크를 보니 거의 아무것도 평가를 갖고 있지 않았다. 대부분은 AI가 썼고 제대로 시험되지 않은 것이었다.
먼저 갈라 두는 것이 있다. 우리가 쓰는 에이전트와 우리가 만드는 에이전트는 다르다. 우리가 쓰는 쪽은 코딩 도구들이고, 만드는 쪽은 고객이 쓴다. 고객은 스킬이 무엇인지 모르고 「환불 스킬을 써서」로 말을 시작하지 않는다.
스킬의 세 층과 그 값
스킬은 파일 하나와 딸린 자료가 든 폴더다. *점진적 공개로 돈다.
셈이 여기서 나온다. 설명은 모델을 부를 때마다 무는 값이다. 백에서 이백 토큰이 늘 실린다. 그러니 여러 갈래로 갈리는 지침 — 이를테면 클라우드 업체마다 다른 배포 방법 — 은 본문이 아니라 참고 파일로 내려야 한다.
파일 자체는 500줄 아래로 두라고 말한다.
성격이 다르니 다루는 법도 다르다
| 갈래 | 무엇을 하나 | 얼마나 가나 |
|---|---|---|
| 능력 | 모델이 아직 일관되게 못 하는 것을 가르친다 | 한때뿐이다. 모델이 좋아지면 지운다 |
| 선호 | 그 팀의 방식과 결을 담는다 | 오래간다. 바탕 모델이 알 길이 없는 것이라 |
부르는 방식도 둘로 갈린다. 모델이 알아서 부르는 것과 사람이 짚어서 부르는 것이다. 발표자 자신은 PR 만들기나 문서 올리기 같은 일에 짚어 부르는 스킬을 여럿 쓴다고 말한다.
여기서 짚는 것이 중요하다. 고객용 에이전트를 만들 때는 짚어 부르는 쪽이 없다. 모델이 알아서 부르는 쪽만 남는다.
발표가 든 순서 그대로
| 팁 | 무엇을 하나 |
|---|---|
| 지시로 쓴다 | 설명을 글짓기가 아니라 시키는 말로 쓴다 |
| 값을 안다 | 설명은 늘 무는 값이니 짧게 벼린다 |
| 층을 나눈다 | 갈래가 갈리는 지침은 참고 파일로 내린다 |
| 자유도를 정한다 | 늘 같은 순서로 도는 일이면 스킬이 아니라 스크립트를 쓴다 |
| 안 쓸 자리를 적는다 | 안 적으면 엉뚱한 데서 불린다 |
| 일찍 시험한다 | 물음 열댓 개를 만든다. 되어야 할 것 다섯, 안 불려야 할 것 다섯 |
| 헛말을 지운다 | 행동을 안 바꾸는 지시를 걷어낸다 |
| 버릴 때를 안다 | 켜고 끄고 재 봐서 없이도 되면 지운다 |
여섯째가 눈에 띈다. 안 불려야 하는 경우를 다섯 개 만들라는 대목이다. 되는 것만 재면 과하게 불리는 것을 못 잡는다.
일곱째는 자기 것이 아니라고 밝히고 다른 사람 공으로 돌린다.
스킬을 채점하는 판
실제 사례가 나온다. 새로 낸 인터페이스가 모델을 마지막으로 학습시킨 뒤에 나와서, 모델이 그것을 아예 모르는 상황이었다.
그래서 테스트 케이스 117개를 만들었다. 실제 사용자에게서 본 것, 지어낸 것, 그리고 「이미 다음 판인데 모델이 옛 판을 쓴다」는 불평에서 뽑았다.
결과는 유효한 코드를 내놓는 성공률이 90% 가까이까지 올랐다는 것이다.
여기서 값나가는 대목은 든 물건이 적다는 것이다. 필요한 것은 둘뿐이었다. 케이스를 담은 파일 하나와 코딩 에이전트를 태워 돌리는 스크립트 하나다. 채점은 대개 정규식이면 된다 — 값이 싸다. 자취 전체를 봐야 하는 복잡한 것에만 모델에게 심사를 맡긴다.
안에서는 이것을 스킬 파일이 바뀔 때마다 돌리고, 케이스가 나아지지 않으면 병합하지 않는다고 말한다.
발표가 마지막에 든 것 중 서로 다른 것들
| 규칙 | 왜 |
|---|---|
| 길이 아니라 결과를 잰다 | 첫 턴에 스킬을 읽었나가 아니라 일을 해냈나를 본다 |
| 따로 떼어 놓고 돌린다 | 코딩 에이전트는 옛 대화나 다른 기록을 찾아 커닝을 잘한다 |
| 한 번으로 안 끝낸다 | 매번 달라지니 케이스마다 여러 번 돌려 믿음직함을 잰다 |
| 하네스를 바꿔 본다 | 어느 도구에서는 잘 되고 다른 도구에서는 나쁠 수 있다 |
| 버려도 평가는 남긴다 | 나중에 나빠지는 것이 보이면 그 스킬을 도로 넣는다 |
자기 실패도 밝힌다. 실패의 절반이 스킬이 제대로 불리지 않아서였고, 그 원인은 사용자의 물음이 충분히 구체적이지 않아서였다고 말한다.
닫는 말은 *어블레이션이다. 켠 채로 한 번, 끈 채로 한 번 돌려 견주라는 것이다.
15%가 무엇의 평균인지 얇다. 스킬이 평균적으로 성능을 그만큼 올렸다는 조사 결과를 드는데, 어떤 과제에서 얼마나 갈렸는지가 없다. 백 개 남짓 과제라는 것만 나온다.
90%도 견줄 앞의 값이 없다. 스킬 없이는 얼마였는지가 나오지 않는다. 무엇을 유효한 코드로 쳤는지도 없다.
AI가 쓴 스킬이 나쁘다는 대목에 수가 없다. 사람이 쓴 것이 가장 좋고 AI가 쓴 것은 성능을 떨어뜨릴 수 있다고 말하는데 얼마나인지가 없다.
500줄과 백에서 이백 토큰의 근거가 없다. 어디서 나온 선인지, 넘으면 무엇이 나빠지는지가 없다.
여러 번 돌리라면서 몇 번인지가 뭉개진다. 자막이 그 수를 흐려 놓아 정확한 횟수는 원문에서 갈린다.
유효기간을 스스로 짧게 잡는다. 모델이 갱신되는 속도를 보면 반년 전에 필요하던 스킬을 오늘은 버리게 되는 것에 놀랄 것이라고 말한다.
용어