한 줄 정의
Eval(평가)는 모델이나 AI 기능이 원하는 답을 내는지, 미리 정한 기준으로 시험해 보는 작업이야. 성능을 뻥튀기하는 트릭도 아니고 비용을 직접 줄이는 요령도 아니고, 프롬프트, 워크플로, 에이전트가 실제 요구를 만족하는지 재는 테스트 층이라고 보면 돼.
어떻게 작동하나
보통은 입력 예시와 기대 기준을 먼저 모은 뒤, 모델 출력에 점수나 합격/불합격 규칙을 붙여 반복 실행해. 기준은 정답 일치율 같은 수치일 수도 있고, 문체를 지켰는지나 금지 정보를 말했는지처럼 채점 기준을 둔 grader일 수도 있어. 이 과정을 한 번만 돌리고 끝내지 않고, 프롬프트를 바꾸거나 모델을 교체하거나 검색 방식을 손댈 때 같은 묶음을 다시 돌려 차이를 본다. 그래서 eval은 모델 안에 들어 있는 기능이라기보다, 변경 전후를 같은 기준으로 비교하게 해 주는 검사 장치에 가깝다.
왜 중요한가
실무에서는 새 모델 도입, 프롬프트 수정, RAG 검색 변경, 에이전트 도구 연결 같은 변화가 생길 때 회귀를 잡는 데 eval이 필요해. 감으로 더 좋아 보인다고 넘기면 특정 질문 묶음이나 실패 조건에서만 무너지는 문제를 놓치기 쉽다. 기사나 홍보 자료를 읽을 때도 eval을 알아야 숫자의 자리를 구분할 수 있어. 공개 벤치마크 점수는 모델끼리 비교할 때 유용하지만, 네 서비스의 실제 응답 품질을 대신 보장하지는 않아서 점수가 올랐다는 말이 곧바로 실사용 개선을 뜻하지는 않아.
주의해서 볼 점
Eval은 잘 만들면 유용하지만, 기준이 좁으면 점수만 높고 체감은 나쁜 상태가 나온다. 예를 들어 짧은 사실 질문만 넣어 두면 긴 대화, 모호한 요청, 도구 실패 같은 실제 문제를 놓칠 수 있어. 또 eval 결과는 데이터셋 품질과 채점 방식에 크게 묶여 있어. 팀이 원하는 답을 너무 빡빡하게 고정하면 유효하지만 다른 표현을 오답으로 처리할 수 있고, 반대로 채점이 느슨하면 회귀가 생겨도 통과시켜 버린다.
관련 용어
- Red Teaming(레드 티밍)은 시스템을 일부러 깨뜨리거나 위험한 행동을 끌어내 보면서 취약점을 찾는 데 초점이 있어. Eval이 정해 둔 기준에 맞게 잘하나를 재는 쪽이라면, Red Teaming은 어디서 망가지나를 캐는 쪽이라 목적과 데이터 설계가 다르다.