AI VIDEO BRIEFING

AI 평가(eval) 설계법: 위협 모델·명세·문항 작성까지 ARENA 강의 핵심 정리

AI 안전 평가는 왜 필요하고 어떻게 설계할까. ARENA 강의는 위협 모델과 명세를 먼저 세우고 교란 요인을 걷어낸 문항을 만들라고 강조하며, MMLU·TruthfulQA 같은 기존 벤치마크의 허술함을 사례로 지적한다.

AI 안전 평가는 위협 모델부터: ARENA 평가 설계 강의 정리 영상 대표 이미지

핵심 메시지

  • 평가(eval)의 목적은 점수 자체가 아니라, 배포 여부를 정하는 사람들이 함께 기댈 수 있는 근거를 만드는 것이다.
  • 평가는 '무엇을 재는가(능력·정렬·통제 견고성)'와 '어떻게 재는가(평균적 벤치마킹 vs 최악을 노리는 레드팀)'라는 두 축으로 나눠 생각할 수 있다.
  • 안전성 논거는 능력 부재 → 통제 가능 → 정렬 순으로 단계가 올라가고, 각 단계마다 필요한 평가 종류가 다르다.
  • MMLU에 오답 보기가 섞여 있고 TruthfulQA는 '튀는 보기 고르기'만으로도 상당 점수가 나오는 등, 널리 쓰이는 벤치마크에도 기본적인 결함이 남아 있다.
  • 좋은 문항은 추상적 우려를 구체적 인과 사슬로 바꾼 뒤, 위치 편향 같은 교란 요인을 제거한 상태에서 만들어진다.

쉽게 이해하기

AI 안전 교육 프로그램 ARENA의 평가(eval) 설계 강의는 '평가는 무엇을 위해 하는가'라는 질문으로 시작한다. 강연자는 능력과 정렬을 측정하는 것 자체가 목적이 아니라, 정책 담당자나 기업의 배포 결정권자가 서로 다른 견해를 갖고 있더라도 공통으로 인정할 수 있는 증거를 만드는 일이라고 설명한다. AI를 언제 배포해도 되는지, 어떤 제약을 걸어야 하는지 답하려면 결국 측정된 근거가 필요하다는 것이다.

강의는 평가를 두 축으로 정리한다. 하나는 무엇을 재느냐로, 위험한 능력의 유무, 모델의 성향(정렬), 그리고 통제·보안 장치가 모델의 우회 시도에 얼마나 견디는지가 여기 들어간다. 다른 하나는 어떻게 재느냐로, 배포 상황의 평균적인 모습을 중립적으로 보고하는 벤치마킹과, 적극적으로 유도해 최악의 경우를 끌어내는 레드팀이 구분된다.

평가를 설계하기 전에 세워야 할 것이 안전성 논거다. 지금 대부분의 논거는 '모델이 애초에 그 일을 해낼 능력이 없다'는 형태이고, 그다음 단계는 '능력이 있어도 배포 방식과 감시로 막을 수 있다', 마지막이 '막지 못하더라도 모델이 그럴 의도를 갖지 않는다'는 정렬 논거다. 각 단계는 위험 능력 평가, 통제 평가, 정렬 평가라는 서로 다른 증거를 요구한다. 강연자는 각 기업이 내놓은 책임 있는 확장 정책(RSP)류 문서가 어떤 임계값을 스스로 약속했는지 담고 있어 평가 아이디어의 출발점으로 쓸 만하다고 권한다.

그러면서도 강의는 현재 평가 문화에 꽤 날 선 비판을 던진다. 모든 모델 논문에 등장하는 MMLU조차 보기 자체가 틀린 문항을 품고 있고, TruthfulQA는 보기 중 혼자 튀는 것을 고르는 단순 요령만으로도 높은 점수가 나온다. 한 상용 모델의 시스템 카드에 실린 '마음 이론' 평가는 물건이 어디 있었는지 묻는 단순 문장 문제였다. 아첨(sycophancy) 성향을 미리 잡아낼 만한 신뢰할 평가가 없어 문제가 뒤늦게 드러난 일도 예로 들며, 평가는 기발한 아이디어보다 성실함이 부족해서 부실해진다고 지적한다.

실습 지침은 구체적이다. 위협 모델은 '이 성향은 나쁘다' 수준이 아니라, 모델의 성향이 사용자의 어떤 행동을 거쳐 어떤 피해로 이어지는지 고리마다 검증 가능한 주장으로 이어져야 한다. 명세는 한 속성의 핵심 한 조각만 아주 또렷하게 정의하는 편이 낫다. 객관식 문항은 서로 독립적이고 실제 배포 상황에 가깝게 쓰되, 항상 '예'를 고르거나 첫 보기를 고르는 모델의 편향, 그리고 '자원을 더 챙기겠는가'라는 질문에 '남을 돕고 싶어서' 동의하는 식의 교란 요인을 걷어내야 한다. 강연자는 언어 모델과 대화하며 문항을 다듬는 것이 실제 연구자들의 방식이라고 덧붙이면서, 아첨을 피하려면 초안을 '친구가 쓴 것'이라고 알려주고 비판을 시키라는 요령까지 소개한다.

주요 인사이트

  • 평가의 청중은 연구자가 아니라 의사결정자다. 전제가 다른 사람도 인과 사슬을 따라가 결론을 받아들일 수 있어야 평가가 제 역할을 한다.
  • 벤치마크 점수가 논문마다 인용된다고 해서 그 문항이 검증됐다는 뜻은 아니다. 결함이 발견된 것은 누군가 직접 데이터를 열어봤기 때문이며, 아직 아무도 열어보지 않은 벤치마크가 더 많다.
  • 위협 모델에서 가장 값진 지점은 결과가 뻔한 고리가 아니라 '나도 결과를 모르겠다'고 느끼는 고리다. 그 지점을 겨냥한 문항이 가장 많은 정보를 준다.
  • 모델에게 대놓고 '너는 권력을 추구하니?'라고 묻는 평가는 정보를 주지 못한다. 그렇게 답하지 않도록 학습됐기 때문이며, 상황을 부여한 현실적 시나리오가 필요하다.
  • 평가 설계는 위협 모델 → 명세 → 문항 → 레드팀의 일방향 절차가 아니라, 몇 주에 걸쳐 앞뒤를 오가는 반복 작업에 가깝다.

자주 묻는 질문

벤치마킹과 레드팀은 어떻게 다른가?

벤치마킹은 배포 상황에서 특정 행동이 평균적으로 얼마나 자주 나타나는지를 중립적으로 측정해 대표 수치로 보고하는 방식이고, 레드팀은 반대로 적극적으로 유도해 최악의 경우에도 모델이 버티는지를 확인하는 방식이다.

강의에서 지적한 기존 벤치마크의 문제는 무엇인가?

MMLU에는 보기 자체가 틀린 문항이 남아 있고, TruthfulQA는 보기 가운데 혼자 성격이 다른 것을 고르는 요령만으로도 상당한 점수를 얻을 수 있다. 한 모델의 시스템 카드에 실린 마음 이론 평가도 실제로는 물건의 위치를 묻는 단순 문제였다.

객관식 평가 문항을 만들 때 주의할 점은?

문항끼리 최대한 독립적이어야 하고, 실제 배포 상황처럼 맥락을 충분히 준 뒤 질문해야 한다. 또 모델이 첫 보기나 '예'를 고르는 편향, 그리고 측정하려는 성향이 아닌 다른 동기 때문에 특정 답을 고르게 만드는 교란 요인을 제거해야 한다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식