AI VIDEO BRIEFING
생성형 AI 평가 방법: 공개 벤치마크의 한계와 실무용 평가 데이터셋·단위 테스트 만드는 법
리더보드 순위가 실제 사용자 선호와 뒤집히는 사례들을 짚으며, 생성형 AI 애플리케이션을 위한 동등성 지표와 단위 테스트 기반 평가 체계를 어떻게 설계하고 실사용자 검증까지 순환시키는지 정리한 강연 요약이다.

핵심 메시지
쉽게 이해하기
생성형 AI로 맞춤형 이메일을 쓰는 일은 시작은 쉽지만 운영에 올리는 순간 이야기가 달라진다. 강연은 커서(Cursor)의 고객 지원 봇이 실제로는 없는 정책, 즉 구독 하나당 기기 하나만 쓸 수 있다는 규정을 만들어 낸 사례를 든다. 사용자들이 그것을 진짜 정책으로 믿으면서 해지가 이어졌고 금전적·평판상 피해로 이어졌다. 법원이 챗봇의 발언을 직원의 발언과 다르지 않게 본다는 점, 생성한 이미지가 남의 저작물과 닮을 수 있다는 점도 같은 맥락의 위험이다.
그렇다면 벤치마크를 믿으면 되지 않을까. 강연자는 그렇지 않다고 말한다. 앤트로픽이 모델 세대를 비교했을 때 벤치마크상으로는 새 모델이 나았지만 사람에게 물었더니 판단이 달랐다. 임베딩 모델에서도 리더보드 순위와 실제 사용자의 선호가 뒤집힌 사례가 보고됐다. 심지어 MMLU 같은 객관식 시험조차 어떤 평가 하네스를 쓰느냐에 따라 프롬프트의 사소한 표현 차이만으로 정확도가 최대 5퍼센트포인트까지 흔들려 순위가 바뀐다.
재현성 문제도 남아 있다. 같은 입력과 온도, 시드를 줘도 출력이 같지 않아 시스템 지문 같은 장치가 도입됐지만 여전히 완전한 결정성은 확보되지 않았고, 희소 전문가 혼합 구조가 퍼지면서 더 어려워질 것이라는 전망도 나온다. 결국 평가하는 사람이 모델의 프롬프트 민감도와 비결정성을 지도처럼 파악하고 있어야 한다는 것이 강연의 첫 번째 요구다.
실무 절차는 명료하다. 먼저 전문가와 함께 정답, 즉 골드 답변을 만들고 모델 출력이 그것과 사실상 같은지 판정하는 동등성 지표를 세운다. 단일 지표이므로 설정을 바꿔가며 개선 여부를 바로 확인할 수 있다. 다만 이것은 숲을 보는 방식이라 톤이나 스타일, 법적 준수 같은 면은 놓친다. 그래서 나쁜 예시를 모아 실패 유형을 분류하고, 길이 검사처럼 파이썬 몇 줄로 끝나는 테스트와 톤 판정처럼 모델을 심판으로 쓰는 테스트를 함께 만든다.
강연은 성과가 선형으로 쌓인다는 통념도 깬다. 열심히 해도 진전이 없다가 우연한 시도에서 크게 튀는 것이 실제 모습이며, 평가 데이터셋을 만들고 지표를 끌어올린 뒤에는 반드시 실사용자 수용 테스트를 거쳐 다시 개선하는 순환을 돌아야 한다. 이때 평가셋에 과적합되지 않도록 경계해야 하고, 심판 모델이 앞쪽 항목을 선호하는 위치 편향이나 긴 답변을 선호하는 경향을 가진다는 점도 감안해야 한다.
주요 인사이트
- 평가는 기술 지표만의 문제가 아니다. 아무리 잘 만들어도 사업적으로 돈을 벌거나 아끼지 못하면 채택되지 않고, GPU를 잔뜩 쓰는 구조라면 운영 비용이 발목을 잡는다.
- 가장 어려운 작업은 코드가 아니라 대화다. 무엇이 나쁜 답인지 정의하려면 현업 전문가와 실사용자의 머릿속을 꺼내야 하며, 그것을 평가 흐름에 넣지 못하면 평가 자체가 사용자가 중요하게 여기는 것을 담지 못한다.
- 도구는 나중 문제다. 강연자가 함께 일하는 팀은 전용 라벨링 도구 없이 스프레드시트만으로 충분히 굴러가며, 도구를 만드는 재미에 빠져 정작 문제를 놓치는 경우를 경계하라고 조언한다.
- 프레임워크는 데모에는 좋지만 수명이 긴 애플리케이션에서는 부담이 된다. 문제가 생기면 자기 코드가 아니라 남이 짠 프레임워크 내부를 파고들어야 하기 때문이다.
- 합성 데이터는 평가용 질문을 만드는 데는 유용하지만 답변 생성에는 환각 위험이 크고, 다양성이 부족해 모델이나 평가를 좁게 만들 수 있다.
자주 묻는 질문
공개 벤치마크만으로 평가하면 안 되나요?
강연은 공개 벤치마크가 모델의 대략적인 수준을 가늠하는 용도라고 봅니다. 실제로 리더보드 순위와 사용자 선호가 뒤집힌 사례가 있어, 자기 사용 사례에 맞는 데이터셋과 평가를 직접 만들어야 한다고 강조합니다.
동등성 지표란 무엇인가요?
전문가가 정한 골드 답변과 모델 출력이 글자 단위로 같은지가 아니라 사실상 같은 답인지를 모델로 판정하는 방식입니다. 단일 지표라 설정을 바꿔가며 개선 여부를 비교하기 쉽습니다.
에이전트 시스템은 어떻게 평가하나요?
요청을 어떤 작업으로 보낼지 정하는 라우팅이 잘 되는지 먼저 보고, 각 작업이 얼마나 잘 수행되는지를 따로 측정합니다. 두 단계 모두에 대해 같은 방식의 오류 분석을 적용합니다.
모델을 심판으로 쓸 때 주의할 점은 무엇인가요?
심판 모델에도 편향이 있습니다. 목록에서 앞쪽 항목을 선호하는 위치 편향이 있어 순서를 섞어 줄 필요가 있고, 긴 답변을 더 좋게 보는 경향도 알려져 있습니다. 사람 평가와의 정렬을 주기적으로 확인해야 합니다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗