유용한 AI 평가는 리더보드의 축소판이 아니다. 시스템이 수행해야 할 일, 사용자가 알아챌 오류, 팀이 감수할 절충점을 압축해 담은 모델이다.
지표가 아니라 의사결정에서 시작하라
누가 시스템을 쓰고 무엇을 끝내려 하는지, 답이 틀리면 어떤 일이 생기는지 적는다. 답변 초안을 쓰는 고객 지원 도우미에는 정책 준수, 누락된 단계, 부적절한 확신을 시험하는 항목이 필요하다. 문서 추출기에는 필드 정확도, 스키마 유효성, 값이 없을 때의 명시적 처리가 필요하다. 똑같은 범용 ‘품질’ 점수로 둘 다 진단할 수는 없다.
OpenAI의 평가 지침은 작업별 시험, 이른 시점부터 반복하는 평가, 가능한 경우 자동 채점, 채점자를 보정하기 위한 사람의 피드백을 권한다. 이 원칙이 가리키는 평가 세트는 제품 테스트 스위트처럼 작동한다. 범위와 버전을 관리하고, 팀이 실제로 적용할 수 있는 변경과 연결해야 한다.
서로 다른 세 곳에서 사례를 모아라
먼저 일반적인 사용 흐름을 대표하는 평범한 사례를 모은다. 긴 입력, 모호한 요청, 빠진 맥락, 충돌하는 문서, 지원하지 않는 언어 같은 경계 사례를 더한다. 이어서 로그와 사용자 신고에서 확인된 실패를 넣는다. 세 번째 집단은 그럴듯한 설계가 실제로 무엇을 잘못했는지 기록하므로 가장 가치 있는 회귀 시험이 되곤 한다.
민감한 정보는 제거하고 동작을 재현하는 데 필요한 맥락만 남긴다. 이상적인 문단만 적지 말고 각 사례에 시험할 역량과 기대 증거를 표시한다. 정확히 하나의 답이 필요한 사례도 있고, ‘실행 전에 확인을 요청한다’ 또는 ‘제공된 문서만 인용한다’ 같은 루브릭이 필요한 사례도 있다.
구성 요소 시험과 종단 간 시험을 분리하라
에이전트는 검색이 출처를 놓치거나, 프롬프트에 지시가 묻히거나, 도구가 잘못된 형식의 데이터를 반환하거나, 모델이 좋지 않은 선택을 해서 실패할 수 있다. 모든 시험이 최종 답변만 보면 팀은 엉뚱한 구성 요소를 조정할 수 있다. 검색, 도구 인수, 정책 라우팅, 출력 형식에 초점을 맞춘 시험을 종단 간 작업 완료 시험과 함께 유지한다.
각 구성 요소가 따로는 정상이어도 상호작용에서 문제가 생길 수 있으므로 종단 간 사례도 중요하다. 진단에 필요한 검색 구절, 도구 호출, 중간 상태를 추적 기록으로 남긴다. 단, 숨겨진 추론은 필수 정보도 신뢰할 만한 감사 기록도 아닌 것으로 본다.
여러 채점 방식을 함께 써라
스키마 유효성, 필수 필드, 금지된 작업, 인용, 정확한 계산에는 결정론적 검사를 우선한다. 안정된 정답이 있는 작업에는 참조 답안을 쓴다. 관련성, 완전성, 어조는 사람이나 모델이 루브릭으로 평가할 수 있지만, 자동 채점자를 사람의 판단에 맞춰 보정하고 불일치를 조사해야 한다.
모든 것을 숫자 하나로 뭉개지 말고 스코어카드로 보고한다. 문체가 좋아졌지만 근거성이 떨어진 릴리스를 무조건 개선이라고 할 수는 없다. 핵심 차원마다 명확한 기준을 세우고 언어, 워크플로, 위험 수준별 성능을 검토한다.
평가를 상시 과정으로 만들어라
프롬프트, 모델, 도구, 검색 설정을 바꾸기 전에 기준선을 고정한다. 같은 시험 모음을 후보 시스템에 실행하고 구성과 비용을 기록하며, 중대한 회귀는 모두 조사한다. 새로 발견한 실패를 추가하되 어려운 사례를 몰래 지우지 않는다. 시간이 지나 시험을 폐기할 때도 이유를 문서화한다.
평가 세트는 계속 관리해야 하는 제품 자산이다. 담당자와 변경 이력, 접근 통제를 둔다. 해마다 두 번 돌리는 거대한 벤치마크보다 의미 있는 변경 때마다 실행하는 작은 시험 모음이 더 유용하다.
실전에 적용하는 방법
먼저 실제 실패를 잡아내는 AI 평가 세트 구축과 관련된, 범위가 명확한 워크플로 하나를 고른다. 시스템을 바꾸기 전에 현재 완료 시간, 품질 검사, 흔한 실패 범주, 에스컬레이션 경로, 결과 담당자를 한 페이지에 정리한다. 가장 깔끔한 사례만 고르지 말고 대표 표본을 선택한다. 일반 사례와 어려운 경계 사례, 그리고 멈추거나 추가 정보를 요청하는 것이 정답인 사례를 최소 하나 포함한다.
후보 시스템이 기존 절차를 대체하도록 허용하기 전에 두 시스템을 나란히 운영한다. 오류율이 낮아져도 영향이 큰 새로운 실패를 감출 수 있으므로 성공한 출력과 실패한 출력을 모두 검토한다. 각 시험에 사용한 정확한 구성을 기록하고, 다른 검토자가 결과를 재현할 수 있는 산출물을 보관한다. 파일럿이 끝나면 가장 인상적인 시연을 보고 뒤늦게 판단하지 말고, 미리 합의한 기준에 따라 확대·수정·중단을 결정한다.
벤더나 내부 팀에 물어볼 질문
핵심 주장을 뒷받침하는 증거가 무엇인지, 그 증거를 만든 시스템과 데이터의 버전은 무엇인지, 어떤 조건이 제외됐는지 묻는다. 실제 배포에서 맞닥뜨릴 언어, 입력 유형, 위험 범주별 결과를 요청한다. 변경 사항을 어떻게 알리고 회귀를 어떻게 탐지하는지, 고객이 사고 검토에 필요한 로그를 내보낼 수 있는지도 확인한다.
확신도가 낮거나 의존성이 실패하거나 요청이 지원 범위를 벗어날 때 시스템이 어떻게 작동하는지도 묻는다. 신뢰할 수 있는 제품에는 더 매끄러운 답변만이 아니라 정의된 실패 상태가 있어야 한다. 책임 주체도 중요하다. 누가 워크플로를 멈출 수 있는지, 누가 예외를 승인하는지, 중대한 오류가 운영 환경으로 빠져나갔을 때 누가 영향받은 사용자에게 알리는지 정한다.
실전 체크리스트
- 모델이나 도구를 선택하기 전에 사용자 작업과 중요하게 봐야 할 실패를 정의한다.
- 실제 업무에서 뽑은 작고 버전 관리되는 시험 세트를 유지하고, 까다로운 사례와 적대적 사례도 포함한다.
- 모든 실행에서 모델, 프롬프트, 도구, 검색 설정, 데이터 버전, 지연 시간, 비용을 기록한다.
- 되돌릴 수 없거나 영향이 크거나 외부에 공개되는 작업에는 사람의 확인을 요구한다.
- 평균 점수 하나가 아니라 범주별로 실패를 검토하고, 회귀 사례를 시험 세트에 추가한다.
Meydo Journal 관련 글
주요 출처
- 평가 모범 사례OpenAI
