새 AI 모델이 실제로 내 업무에 더 나은지 확인하는 방법

출시 벤치마크가 질문에 답하지 못하는 이유

모든 프론티어 모델은 표준화된 평가에서 앞선 결과를 보여주는 차트와 함께 출시됩니다. 그 수치는 실제이지만, 월요일에 무엇을 써야 할지 결정하는 데는 거의 쓸모가 없는데, 이유는 세 가지입니다.

차이는 작고, 과제는 당신의 것이 아닙니다. 추론 벤치마크에서 2점 차이가 난다고 해서 한 모델이 더 나은 고객 이메일을 쓰는지, 200행에 걸쳐 스키마를 더 안정적으로 유지하는지는 전혀 알 수 없습니다.

벤치마크는 채점하기 쉬운 과제만 측정합니다. 정답이 있는 것들입니다. 대부분의 전문적인 업무에는 정답이 없습니다: 어조, 구조, 무엇을 뺄지에 대한 판단력. 모델들이 가장 크게 갈리는 지점이 바로 여기이고, 아무것도 측정되지 않는 지점 또한 여기입니다.

출시 비교는 벤더가 직접 만듭니다. 반드시 부정직해서가 아니라, 자기 모델이 2등을 한 평가를 공개하는 벤더는 없기 때문입니다.

정말 답할 가치가 있는 질문은 더 좁습니다: 일주일에 스무 번씩 하는 그 특정 업무에서 이 둘 중 어느 쪽이 더 나은가? 이건 공개된 답이 없고, 알아내는 데 한 시간쯤 걸립니다.

출시마다 실제로 바뀌는 것들

최근 프론티어 모델 출시들을 보면, 실제 사용에서 중요한 개선은 늘 같은 영역에서 일어나고, 발표에서 강조되는 것과는 거의 겹치지 않습니다.

개선된 부분	체감 방식	벤치마크에 나타나는가
지시 사항 준수	세 번째 조건을 더 이상 무시하지 않음	거의 없음
부정 지시	"비유를 쓰지 마세요"가 실제로 지켜짐	아니오
긴 문맥 기억	3쪽이 아니라 140쪽에 있는 내용도 찾아냄	부분적
형식 준수	요청한 열이 매번 정확히 나오는 표	아니오
보정된 불확실성	지어내는 대신 모른다고 말함	아니오
어조 조절	보낼 수 있는 상태가 되기까지 다시 쓰는 횟수가 줄어듦	아니오
추론 깊이	놓쳤던 예외 상황을 잡아냄	예, 이것만 측정합니다

일곱 개 중 다섯 개는 벤치마크 차트에는 보이지 않으며, 새 모델을 쓸 때 더 낫게 혹은 더 나쁘게 느껴지는 이유가 바로 여기에 있습니다. 특히 지시 사항 준수는, 편집해서 쓸 초안과 버리게 될 초안의 차이를 만듭니다.

1시간짜리 평가법

출시 소식을 읽는 대신 이렇게 해보세요. 두 모델을 자신의 자료로 나란히 실행합니다.

1. 실제 과제 다섯 개를 모으세요 지난 2주 동안의 것으로요. 실제 맥락을 그대로 붙여넣은 진짜 과제여야 하며, 장난감 같은 프롬프트는 안 됩니다. 글쓰기 과제 하나, 구조화된 출력 과제 하나, 익숙하지 않은 것에 대한 추론이 필요했던 과제를 하나 이상 포함하세요.
2. 좋은 답변의 조건을 먼저 적어두세요 각 과제마다 한 문장으로, 실행하기 전에요. 이 단계는 더 길고 더 자신감 있어 보이는 출력을 무의식적으로 선호하게 되는, 강력하지만 대체로 무의식적인 편향을 막아줍니다.
3. 각 과제를 두 모델 모두에 동시에 실행하세요 어느 한쪽 답이 다른 쪽에 영향을 주지 않도록요.
4. 편집에 드는 노력을 기준으로 채점하세요 출력물과 실제로 보낼 만한 결과물 사이에 얼마나 손이 가는지를 뜻합니다. 읽히는 느낌이 아니라요.
5. 격차의 크기를 기록하세요 승자만이 아니라요. 결과가 서로 바꿔써도 될 정도라면, 그 과제에 대해서는 모델 선택을 더 고민할 필요가 없다는 뜻이고, 이는 정말 유용한 정보입니다.
6. 기록을 남겨두세요. 3개월 후 다음 모델이 나올 때, 같은 다섯 과제를 다시 실행하면 20분 만에 진짜 답을 얻을 수 있습니다.

마지막 항목이 복리로 작용하는 부분입니다. 저장해둔 평가 세트만이 이후의 모든 출시를 저렴하게 평가할 수 있게 해줍니다.

프론티어 모델을 구분해주는 여섯 가지 프롬프트

일반적인 질문에는 어떤 유능한 모델이든 비슷한 답을 내놓습니다. 차이를 보고 싶다면 특정 능력에 압박을 가하세요.

• 어려운 상황에서의 어조. 마감을 놓쳤다고 고객에게 알리는 메모를 작성하세요. 과도하게 사과하지 않고 변명도 하지 않으면서 책임을 지는 내용으로, 120단어 이내로 작성하세요. 어투 차이가 즉시 드러납니다.
• 부정 제약. 비유나 은유를 전혀 사용하지 않고 [개념]을 설명하세요. 부정 지시를 따르는 정도는 예상보다 훨씬 크게 갈립니다.
• 엄격한 추출. 모든 날짜, 금액, 당사자를 정확히 이 키들로 이루어진 JSON 배열로 추출하세요. 필드가 없으면 null을 사용하세요. 추론하지 마세요. 형식 준수와 빈칸을 채우려는 경향을 테스트합니다.
• 긴 문맥 기억. 긴 문서를 업로드하고 중간 부분에 대해 질문하세요. 광고된 문맥 길이와는 다른, 실제로 쓸 수 있는 문맥을 드러냅니다.
• 모름을 인정하기. 정말로 생소하거나 아주 최근의 것을 물어보세요. 가장 좋은 답은 명확한 "모릅니다"이거나 출처가 있는 검색 결과입니다. 여기서 지어낸 답은 어떤 벤치마크와도 무관하게 실격입니다.
• 다중 제약 준수. 조건 여섯 개를 한꺼번에 주고 몇 개나 살아남는지 세어보세요. 이 테스트 하나가 목록의 다른 어떤 것보다도 일상적인 만족도를 잘 예측합니다.

대답은 대개 "둘 다, 다른 용도로"입니다

사람들은 출시를 마주할 때 결론을 원하지만, 평가를 실제로 해본 뒤 나오는 솔직한 결과는 거의 항상 갈립니다. 한 모델은 글쓰기와 어조에서 이기고, 다른 모델은 엄격한 구조와 속도에서 이깁니다. 일반적인 추론에서는 둘의 차이가 무엇도 결정하지 못할 만큼 근소합니다.

이건 얼버무림이 아니라 실제 결과이며, 실용적인 함의가 있습니다. 모델을 하나만 쓸 수 있다면, 어떤 범주의 과제에서 더 못할지를 선택하는 셈입니다. 둘 다 쓸 수 있다면, 출시라는 질문은 "갈아탈까"가 아니라 "어떤 과제를 옮길까"가 되고, 이는 훨씬 작고 부담이 적은 결정입니다.

이는 출시가 당신에게 갖는 의미도 바꿉니다. 이미 여러 모델이 있는 워크스페이스에 새 모델이 들어오면, 다섯 과제를 다시 실행하고 라우팅을 조정한 뒤 계속 쓰면 됩니다. 마이그레이션도 없고, 구독 해지도 없으며, 미리 결정해버린 탓에 더 나쁜 것을 한 달 동안 쓰는 일도 없습니다.

출시일에 해야 할 일

기본값을 바로 바꾸지 마세요. 출시 첫 주의 인상은 참신함과 가장 먼저 퍼진 예시들에 좌우됩니다.

평가 세트를 다시 실행하세요. 지난번 것을 남겨두었다면 20분이면 됩니다.

지루한 부분들을 확인하세요. 문맥 창 크기, 기존 프롬프트가 여전히 같은 방식으로 작동하는지, 의존하던 무언가가 바뀌었는지를요. 전반적으로 더 나은 모델이 당신의 특정 템플릿에서는 더 나쁠 수 있으니, 실제 업무를 그쪽으로 옮기기 전에 확인해둘 가치가 있습니다.

전체가 아니라 과제별로 라우팅을 업데이트하세요. 새 모델이 확실히 이긴 범주만 옮기고 나머지는 그대로 두세요.

한계가 드러날 때까지 2주를 기다리세요. 새 모델의 실패 양상은 널리 쓰인 지 2주쯤 지나야 드러나며, 발표에는 거의 실리지 않습니다.

전반적인 프레임워크는 AI 모델을 고르는 방법을 참고하고, 한 프롬프트에 두 모델을 실행하는 방법은 모델을 나란히 비교하기를 참고하세요.