1. 평가가 값을 내고 있나

평가와 관측을 파는 회사 쪽 사람이 발표한다. 자막 안에서 자기 이름을 대지는 않는다.

좋은 평가는 공짜로 오지 않고 만들어 넣어야 한다고 연다. 지어낸 데이터와 인터넷에서 주워 온 채점 방식으로는 안 된다는 것이다.

그래서 잘 되고 있는지 가늠할 신호 셋을 든다.

평가가 값을 내고 있다는 신호

첫째 신호에는 실제 사례를 든다. 어느 회사가 최근 여러 번의 모델 출시 때마다 24시간 안에 새 모델을 넣었다는 것이다.

둘째에는 경고가 붙는다. 그 길이 없으면 쓸모 있는 정보가 그냥 허공으로 사라진다.

2. 남의 데이터와 남의 채점표

두 번째 교훈은 데이터다. 현실과 딱 맞는 데이터셋은 없다고 못 박는다. 시합용 수학 문제 같은 몇몇 예외뿐이다.

가장 좋은 데이터셋은 실제로 벌어지는 것과 계속 맞춰 나가는 것이고, 그 일을 잘하려면 손이 꽤 든다고 말한다.

채점표도 같다. 함께 일하는 회사 중 충분히 앞선 곳은 하나같이 자기 채점 함수를 직접 짜고 계속 고친다고 말한다.

여기서 이 발표에서 가장 잘 벼려진 한 줄이 나온다. 채점표는 그 애플리케이션의 명세다. 그러니 남이 만든 범용 채점표를 그대로 쓰면 그것은 내 프로젝트가 아니라 남의 프로젝트를 위한 명세가 된다.

3. 프롬프트를 채우는 것은 사람이 아니다

세 번째 교훈이다. 프롬프트를 시스템 프롬프트가 아니라 맥락 전체로 보는 쪽으로 옮겨 갔다고 말한다.

실제 에이전트 자취 몇 개를 뜯어 보니 평균적인 프롬프트에서 토큰의 대부분이 시스템 프롬프트에서 온 것이 아니었다. 도구 정의와 도구가 돌려준 것이 자리를 차지한다.

그래서 도구를 지금 있는 API를 그대로 비춘 것으로 만들면 안 된다고 말한다. 모델이 보고 싶어 하는 모양으로 짜야 한다는 것이다.

구체적인 사례가 하나 나온다. 사내 프로젝트에서 도구가 내놓는 형식을 JSON에서 YAML로 바꾼 것만으로 눈에 띄게 달라졌다. 이유는 토큰이 덜 들고 모델이 훑기 쉬워서다.

갈린 자리가 여기다. 코드가 보기에 둘은 같은 구조화 데이터인데 모델이 보기에는 아주 다르다.

4. 새 모델이 나오면 판이 바뀐다

네 번째 교훈이다. 어느 기능을 두고 몇 달마다 같은 평가를 돌려 왔다고 말한다. 한동안 최고이던 모델이 있었고 그다음이 조금 나았고 그다음이 훨씬 나았다.

그러다 10% 수준이라 사용자에게 내놓을 수 없던 기능이 갑자기 쓸 만해졌다. 새 모델이 나온 지 2주 만에 그 기능의 첫 판을 내보낸다고 말한다.

그럴 수 있었던 이유는 하나다. 평가를 미리 돌려 두고 있었다.

그래서 권한다. 오늘 모델로는 아직 안 될 만큼 야심 찬 평가를 만들어 두고, 새 모델이 나오면 바로 갈아 끼워 볼 수 있게 짜 두라는 것이다. 모델 공급자를 바꿔도 코드를 안 고쳐도 되게 사이에 무언가를 끼워 두라고 덧붙인다.

솔직한 대목도 있다. 어느 회사가 막 내놓은 모델이 이 벤치마크에서 1%를 받아 아예 표에 넣지도 않았다고 말한다. 그러면서 오늘 나온 것은 훨씬 나을 수도 있고 이 발표가 끝나면 몇 번 두드려 확인할 수 있다고 덧붙인다.

5. 프롬프트만 고치지 마라

다섯 번째다. 판을 셋으로 본다. 평가에 쓰는 데이터, 할 일(프롬프트와 에이전트 얼개와 도구), 채점 함수다.

같은 벤치마크로 두 번 돌렸다고 말한다. 한 번은 프롬프트만 주고 이것을 고치라 했고, 한 번은 프롬프트와 데이터와 채점표를 함께 주고 이 판을 고치라 했다. 차이가 극적이었고, 다시 한 번 못 쓰던 것이 쓸 수 있는 것으로 바뀌었다.

이어서 그 일을 자동으로 해 주는 자사 기능을 그날부터 연다고 소개한다. 프롬프트를 고쳐 달라거나, 이 데이터셋에서 빠진 것이 무엇이냐거나, 왜 점수가 낮거나 높으냐거나, 지금 것보다 더 깐깐한 채점표를 짜 달라는 요청이 잘 먹혔다고 말한다.

닫는 말이 세다. 새 모델이 나오면 알아채는 데서 그치지 말고 지금 얼개를 통째로 뜯어내 완전히 새 얼개로 갈아 끼울 각오까지 하라는 것이다.

6. 청중이 되물은 것

이 발표에서 가장 값나가는 대목이 질의응답에 있다.

한 사람이 묻는다. 사용자 피드백을 전부 평가로 넣으면 *과적합이 되는 것 아니냐.

답이 뒤집혀 있다. 사용자 피드백 없이 데이터셋에 과하게 맞춰지는 쪽이 더 걱정된다는 것이다. 그러면서 자기네 제품은 피드백을 자동으로 데이터셋에 넣지 않는다고 밝힌다 — 안목 있는 사람이 골라 넣기를 바란다는 이유다.

다른 사람이 자기 현장 이야기를 보탠다. 세금 답변에 사용자가 싫다고 누르는데, 그래서 「답은 맞는데 그냥 마음에 안 든다」를 따로 누를 자리를 만들었다고 말한다.

또 다른 사람은 모델을 여러 번 바꿔 봤지만 큰 차이를 못 느꼈다고 말한다. 발표자는 모든 벤치마크가 그런 것은 아니라고 답한다. 영화 대사로 어떤 영화인지 맞히는 평가는 오래전 모델부터 계속 잘 됐다는 예를 든다.

7. 발표가 밝히지 않은 것

가장 중요한 대조에 수가 없다. 프롬프트만 고칠 때와 판 전체를 고칠 때가 극적으로 갈렸다고 말하는데, 두 값이 얼마였는지가 없다.

JSON에서 YAML로 바꾼 사례도 마찬가지다. 눈에 띄게 달라졌다고만 하고 무엇이 얼마나 달라졌는지가 없다.

10%가 무엇의 10%인지 없다. 어떤 채점표로 잰 값인지, 얼마가 되어야 쓸 만한지가 없다.

1%도 한 벤치마크의 값이다. 발표자 스스로 이것이 모든 벤치마크에 해당하지 않는다고 말한다. 그러니 그 수로 모델의 우열을 읽으면 안 된다.

자막이 모델 이름을 뭉갠다. 판을 견주는 대목에서 이름과 번호가 여러 군데 어긋나 있어, 어느 판이 어느 판보다 나았다는 순서만 남고 정확한 이름은 원문에서 갈린다.

24시간과 2주는 남의 값과 자기 값이다. 24시간은 다른 회사 사례이고 2주는 자기네 것이다. 견줘서 얻은 값이 아니다.