AI 에이전트 평가는 최종 답변 채점만으로 충분하지 않다. 에이전트는 계획, 도구 선택, 인자 생성, 실행, 오류 복구를 거치기 때문에 reasoning layer와 action layer를 따로 봐야 실패 원인을 찾을 수 있다.
평가 설계 순서
- 태스크, 환경, 성공 조건, 금지 행동을 먼저 명확히 쓴다.
- 도구 호출 순서, 인자 형식, 최종 환경 상태는 결정론적 코드 grader로 확인한다.
- 답변 품질, 근거성, 어조처럼 결정론적으로 어려운 항목만 LLM judge로 보완한다.
- 실행 trace에 tool call, arguments, observations, latency, token, 비용을 남긴다.
- 단발 실행 대신 pass@k와 pass^k로 비결정성을 측정한다.
- 새 능력을 재는 capability eval과 회귀를 막는 regression eval을 분리한다.
pass@k와 pass^k
pass@k는 k번 중 한 번이라도 성공하면 되는 상황에 맞다. 예를 들어 코드 생성에서 여러 후보를 만들고 테스트가 통과한 하나를 고를 수 있다면 유용하다. 반대로 고객 지원, 결제, 의료 상담처럼 매번 안정적이어야 하는 흐름은 pass^k가 더 중요하다. 단일 실행 성공률이 75%라도 세 번 연속 성공 확률은 훨씬 낮아진다.
운영까지 이어지는 평가
개발 eval은 예상 가능한 실패를 막고, 프로덕션 모니터링은 실제 사용자가 만든 예외를 발견한다. LangSmith, Arize Phoenix, Braintrust, Langfuse 같은 trace/eval 도구와 Harbor, DeepEval 같은 하네스 계층을 함께 쓰면 오프라인 평가와 운영 관측을 연결할 수 있다.
참고 자료
- The Roadmap to Mastering AI Agent Evaluation — Machine Learning Mastery (2026-06-18)