에이전트 평가 데이터셋은 전문가가 평가한 실행 사례 약 20개로 시작할 수 있다. 글쓴이는 이 사례를 모아 반복되는 실패를 평가 기준으로 만들고, 이를 바탕으로 언어 모델 평가자를 구축하라고 제안한다.
이 주장은 에이전트의 말뿐 아니라 도구 호출과 작업 과정까지 평가하려는 팀을 위한 방법론이다. 글쓴이는 코드로 확인할 수 있는 항목을 먼저 검사하고, 코드만으로 판단하기 어려운 부분에만 언어 모델 평가자를 쓰는 방식을 권한다.
왜 고정된 정답만으로는 부족한가?
산술 연산이나 데이터베이스 조회처럼 결정적인 시스템은 결과가 정해진 범위에 들어온다. 반면 대규모 언어 모델은 같은 뜻을 여러 문장과 구조로 표현할 수 있다. 온도를 0으로 설정해도 배치 크기 같은 추론 조건에 따라 결과가 조금씩 달라질 수 있어, 하나의 정답과 출력물을 단순 비교하기 어렵다.
무엇이 좋은 답인지도 사용자의 기준에 따라 달라진다. 간결한 답을 원하는 사람도 있고 세부 내용과 인용을 원하는 사람도 있다. 글쓴이는 이런 주관적인 평가를 위해 다음 네 단계를 제안한다.
네 단계는 무엇인가?
- 실행 환경과 기록을 고정한다. 에이전트 실행을 시작할 때 작업 순서와 전체 실행 기록을 저장하고, 시스템 프롬프트에 버전을 붙인다. 당시 사용할 수 있었던 파일과 도구도 저장하거나 같은 상태로 재현할 수 있어야 한다. 외부 도구와 MCP(모델이 외부 도구·데이터에 연결되는 프로토콜) 호출은 응답을 기록해 재실행할 때 모의 응답으로 사용할 수 있게 한다. 파일이나 도구가 나중에 바뀌거나 삭제되면 과거 실행을 재현할 수 없기 때문에, 이 기록은 모든 실행에 적용해야 한다.
- 전문가가 실행을 직접 평가한다. 주제 전문가(SME)가 저장된 실행을 살펴보고, 각 단계와 읽은 파일, 도구의 출력 등 중간 과정까지 평가한다. 중간 행동이 중요한 경우 어디서부터 수행이 느슨해졌는지도 확인한다. 각 단계에는 ‘정확함’, ‘부정확함’, ‘불필요함’처럼 정해진 평가 항목과 그 판단의 이유를 적는다.
- 평가 사례를 모아 반복 실패를 기준으로 만든다. 목표, 에이전트 실행 기록, 전문가의 평가와 주석을 함께 데이터셋으로 구성한다. 글쓴이는 약 20개 사례를 출발점으로 삼고, 더 다양한 실행과 새 실패 사례를 더해 데이터셋을 키우라고 제안한다. 충분한 평가가 쌓이면 주석에서 반복되는 실패를 찾아 좋은 실행과 나쁜 실행을 가르는 짧은 통과·실패 기준, 즉 루브릭(평가 기준표)으로 만든다. 글쓴이는 실제 실행을 채점하기 전에 기준부터 정하지 말라고 권한다. 실제 사례를 본 뒤 좋은 실행에 대한 판단이 달라질 수 있기 때문이다.
- 데이터셋으로 언어 모델 평가자를 만든다. 루브릭과 데이터셋의 평가 사례 몇 개를 프롬프트에 넣어 이후 실행을 평가하게 한다. 글쓴이는 추론 능력이 더 뛰어난 모델을 평가자로 쓰고, 대규모 적용 전에 전문가 평가나 다른 신뢰할 수 있는 평가와 비교해 검증해야 한다고 주장한다.
평가자는 언제 실행할까?
평가자를 에이전트 실행 중에 작동시키면 부정확하거나 바람직하지 않은 결과를 일찍 잡아 피드백을 줄 수 있다. 대신 평가 모델 호출이 추가돼 결과를 내는 시간이 길어진다. 다른 방법은 실행이 끝난 뒤 시간 단위나 주 단위 작업으로 여러 실행을 평가하는 것이다. 글쓴이는 대체로 이 사후 평가 방식을 선택한다고 말한다. 새 실패와 학습 내용은 데이터셋에 다시 반영한다.
평가자를 만든 뒤에도 정기적으로 살펴야 한다. 평가 모델의 판단이 전문가의 선호에서 벗어나는 ‘평가자 드리프트’가 누적될 수 있기 때문이다. 이런 차이를 바탕으로 프롬프트와 도구 구성을 개선하고, 안전장치와 도구를 추가하며, 목적에 맞는 모델을 고른다.
프롬프트를 바꾸거나 도구를 추가·수정·삭제할 때, 모델을 바꿀 때, MCP 연결이나 실행 환경(harness)을 변경할 때는 데이터셋을 다시 돌려 회귀가 생겼는지 확인해야 한다. 새 실패 유형이 나타나면 평가자의 판단도 전문가가 붙인 평가와 다시 대조할 필요가 있다. 원문은 전문가 간 평가 일치도나 평가자 검증에 쓸 구체적인 수치를 제시하지 않는다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요