TL;DR

  • 에이전트 시스템 평가는 비결정적이고 개방형인 출력의 특성을 고려해 4단계로 설계해야 함.
  • 에이전트의 모든 실행을 재현할 수 있도록 작업 순서, 시스템 프롬프트, 파일, 도구와 외부 호출 응답을 버전 관리하고 고정된 스냅샷으로 저장함.
  • 주제 전문가(SME)가 저장된 실행을 단계별로 평가하고, 반복되는 실패 유형을 바탕으로 약 20개 실행부터 시작하는 주석 데이터셋과 평가 루브릭을 구축함.
  • 데이터셋의 루브릭과 레이블이 지정된 예시를 활용해 LLM 심사자(LLM-as-a-Judge)를 만들고, SME 평가와 대조해 신뢰성을 검증함.
  • 프롬프트·도구·모델·MCP·하네스 변경 때마다 회귀 테스트를 수행하고, 심사자의 평가자 드리프트를 지속적으로 점검함.

시스템 평가가 어려운 이유

  • 모든 시스템 평가는 입력, 시스템 로직, 출력으로 구성되며, 출력과 기대 출력을 비교하는 방식이 기본임.
  • 산술 연산이나 데이터베이스 조회 같은 결정적 시스템은 출력이 고정된 범위에 있으므로, 예상 동작이나 값과 비교하는 단위 테스트·통합 테스트를 작성한 뒤 자동화하기 쉬움.
  • 대형 언어 모델(LLM) 같은 비결정적 시스템은 출력이 개방형 범위에 놓임. 출력 분포가 원하는 답변 쪽으로 치우칠 수는 있지만 일치율이 100%가 되지는 않으며, 온도가 0이어도 배치 크기 같은 추론 세부 사항에 따라 결과가 조금씩 달라질 수 있음.
  • 개방형 출력은 하나의 기대 문장과 비교하는 방식만으로 평가하기 어려움. 같은 내용을 수백 가지 문장·구조·세부 수준으로 표현할 수 있고, 간결한 답변과 세부 정보 및 인용을 포함한 답변, 불릿과 문단 중 무엇을 선호하는지도 평가 기준에 영향을 줌.
  • 모든 에이전트 동작이 개방형인 것은 아님. 표현이 달라져도 데이터베이스가 올바른 상태인지, 적절한 도구를 호출했는지, 출력이 스키마에 맞게 파싱되는지 등은 일반 코드로 확인할 수 있음.
  • 따라서 코드로 확인할 수 있는 항목을 먼저 검사하고, 코드로 평가할 수 없는 부분에만 심사자를 적용하는 접근이 적절함.
  • 에이전트 시스템은 비결정적이고 개방형이어서 이상적인 출력이 주관적이며, 이상적인 결과를 규정하는 보편적 지침도 없음.

1단계: 실행 기록을 고정 스냅샷과 버전으로 저장

  • 에이전트가 수행한 모든 작업의 순서를 추적하고, 실행을 초기화할 때 전체 기록을 고정 스냅샷으로 저장함.
  • 시스템 프롬프트를 버전 관리하고, 초기화 시점에 제공된 파일과 도구도 저장하거나 재현할 수 있는 상태로 유지함.
  • 파일이나 도구를 고정된 버전으로 저장하지 않으면, 이후 수정 또는 삭제된 뒤 이전 실행을 재생할 수 없어 기록이 오래되고 쓸모없어질 수 있음.
  • 외부 도구와 모델 컨텍스트 프로토콜(MCP) 호출도 응답을 기록해 재생 시 모의 응답으로 사용할 수 있게 함.
  • 이 기록 방식은 일부 실행이 아니라 모든 실행에 적용함.

2단계: 실행을 수동으로 평가

  • 저장된 에이전트 실행을 주제 전문가(SME)가 평가함. 이 단계는 지루하고 수작업이 많아 AI 평가를 구축하다가 중단하기 쉬운 부분임.
  • 중간 동작도 중요한 경우 각 단계, 읽은 파일, 도구 출력 등을 평가해 시스템이 어느 지점에서 기준을 벗어나는지 파악함.
  • 관련된 각 단계에 ‘정확함’, ‘부정확함’, ‘불필요한 추가 동작’ 등 고정된 피드백 유형과 의견을 기록함.
  • 의견에는 해당 피드백을 부여한 이유를 포함함.

3단계: SME 평가 실행 데이터셋 구축

  • 목표, 에이전트 실행, SME 평가와 주석을 포함하는 데이터셋을 구성함.
  • 처음에는 약 20개 실행으로 시작하고, 실행의 다양성을 넓히며 새로운 실패 사례가 생길 때마다 데이터셋을 확장함.
  • 평가된 실행이 충분히 쌓이면 SME 의견을 검토해 반복되는 실패 유형을 찾고, 이를 좋은 실행과 나쁜 실행을 판별하는 점수 기준인 루브릭으로 전환함.
  • 루브릭은 좋은 실행의 조건을 나타내는 짧은 통과·실패 검사 목록으로 구성함.
  • 실제 실행을 살펴보면서 좋은 실행에 대한 기준이 달라질 수 있으므로, SME 평가 전에 루브릭을 만들지 않고 평가 후에 작성함.

4단계: 데이터셋을 바탕으로 LLM 심사자 구축

  • LLM 심사자로 SME의 작업을 줄임. 심사자 모델의 프롬프트에 루브릭과 데이터셋의 레이블 지정 예시 몇 개를 제공해 향후 실행을 평가하게 함.
  • 심사자에는 추론 성능이 더 뛰어난 모델을 사용하는 것이 이상적이며, 대규모로 신뢰하기 전에 SME 평가 또는 다른 신뢰할 수 있는 평가와 대조해 결과를 검증함.
  • LLM 심사자 운영 방식은 두 가지임.
  • 실행 중 심사자가 계속 평가하고 에이전트에 피드백을 되돌려주는 방식은 원치 않거나 정확도가 낮은 출력을 더 일찍 포착할 수 있지만, 심사 모델 호출이 추가되어 출력 생성 시간이 늘어남.
  • 실행 후 심사자가 평가하는 방식은 매주 또는 매시간 크론 작업으로 실행할 수 있음. 선택된 실행을 심사자와 평가 기준에 따라 처리하고, 새로운 실패와 학습 내용을 데이터셋에 추가함. 대부분의 경우 이 방식이 일반적인 선택임.
  • LLM 심사자는 한 번 만들고 끝내는 작업이 아니며, 정기적으로 모니터링하고 개선해야 함.
  • 평가자 드리프트는 심사자 모델의 평가가 SME의 선호에서 벗어나기 시작하는 비교적 흔한 경향이며, 작은 차이도 시간이 지나며 누적될 수 있음.
  • 평가에서 얻은 학습 내용은 프롬프트 개선, 도구 구조 조정, 가드레일과 도구 추가, 목적에 가장 적합한 LLM 선정에 활용함.

변경 사항 회귀 테스트와 지속 개선

  • 프롬프트를 바꾸거나 도구를 추가·갱신·삭제하거나, 모델을 변경하거나, MCP를 추가·제거하거나, 하네스를 변경할 때마다 구축한 데이터셋을 실행해 회귀를 점검함.
  • 새로운 실패 유형이 기존 사례와 달라 보이는 경우에는 특히 SME 레이블과 심사자 평가의 일치 여부를 다시 확인함.