AI 에이전트 평가 지표, 무엇을 측정할까?
- 최종 답변과 중간 행동을 나눠 평가해야 합니다.
- 업무 위험도에 따라 지표와 통과 기준을 정합니다.
- 오프라인 회귀 평가와 운영 모니터링을 함께 씁니다.
AI 에이전트 평가는 답변이 그럴듯한지만 확인하는 일이 아닙니다. 요청한 작업을 끝냈는지, 올바른 도구를 적절한 순서로 사용했는지, 권한과 안전 규칙을 지켰는지, 시간과 비용을 감당할 수 있는지를 함께 측정해야 합니다. 먼저 대표 업무 사례와 실패했을 때의 위험을 정하고, 그에 맞춰 작업 성공·행동 품질·안전성·운영 효율 지표를 따로 설계하세요.
에이전트 평가에서 먼저 정할 것
채점 대상은 답변과 실행 과정입니다
에이전트는 외부 도구를 호출하고 여러 단계를 거쳐 목표를 수행합니다. 그러므로 최종 답변이 맞더라도 잘못된 계정을 조회하거나, 승인 없이 변경 작업을 실행했다면 성공으로 보기 어렵습니다. 평가는 최종 결과와 중간 실행 기록을 함께 봐야 합니다. 실행 기록(trace)은 입력, 모델 출력, 도구 호출과 결과가 시간 순서대로 남은 데이터입니다.
측정 가능한 성공 조건을 사례로 표현합니다
“유용하게 답한다”처럼 넓은 목표만 두면 평가자마다 점수가 달라집니다. 예를 들어 고객 문의 처리라면 ‘환불 조건을 정확히 안내함’, ‘필요한 주문 정보를 확인함’, ‘환불을 실제 처리하기 전 사용자 승인을 받음’처럼 관찰 가능한 조건으로 쪼갭니다. 조건마다 정답이 있는지, 사람이 판단해야 하는지, 위반 시 허용할 수 없는지를 표시해 두세요.
핵심 평가 지표 4개 영역
1. 작업 완료와 결과 품질
작업 성공률은 사전에 정한 완료 조건을 모두 충족한 사례의 비율입니다. 여러 단계 업무라면 전체 성공 여부만 기록하지 말고 단계별 완료율도 남겨 어느 지점에서 막혔는지 확인합니다. 정보 답변형 업무에서는 사실 정확성, 근거의 적합성, 누락 여부를 별도 채점하세요. 성공률이 높아도 중요한 조건 하나를 자주 빠뜨린다면 실제 품질은 낮을 수 있습니다.
2. 도구 선택과 실행의 적절성
도구 선택 정확도는 해당 상황에서 알맞은 도구를 선택했는지, 호출하지 않아도 될 때 불필요한 호출을 피했는지 봅니다. 인수 정확도는 도구에 전달한 대상·값·형식이 맞는지 확인합니다. 도구 실행 성공 여부와 결과가 최종 목표에 기여했는지도 나눠 기록하세요. 도구 호출 원리와 검증 포인트는 AI 에이전트 도구 호출 과정에서 더 살펴볼 수 있습니다.
3. 안전성·정책 준수·복구 능력
민감 정보 노출, 권한을 넘는 작업, 승인 누락처럼 발생하면 안 되는 실패는 평균 점수에 묻히지 않도록 별도의 위반률로 관리합니다. 공격성 입력이나 모호한 요청을 넣어 거절·확인·안전한 대안 제시가 적절한지도 시험하세요. 도구 오류나 빈 결과가 났을 때 재시도, 사용자 확인, 중단 중 어떤 행동을 택하는지와 무한 반복을 피하는지도 평가 대상입니다.
4. 지연 시간과 비용
응답 시간은 평균뿐 아니라 느린 요청 구간도 살펴야 합니다. 평균이 양호해도 일부 요청이 오래 걸리면 사용자는 서비스가 불안정하다고 느낄 수 있습니다. 요청당 모델·도구 호출 비용, 토큰 사용량, 재시도 횟수도 함께 기록해 품질 개선의 비용을 판단하세요. 업무별로 허용 가능한 지연과 비용을 정하고, 단순히 호출 횟수를 줄이는 최적화가 성공률이나 안전성을 해치지 않았는지 비교해야 합니다.
| 영역 | 예시 지표 | 확인할 질문 |
|---|---|---|
| 결과 | 작업 성공률, 사실 정확성 | 요청한 목표와 필수 조건을 충족했나? |
| 행동 | 도구 선택·인수 정확도 | 필요한 도구를 올바르게 썼나? |
| 안전 | 정책 위반률, 승인 누락률 | 금지 행동과 권한 경계를 지켰나? |
| 운영 | 지연 시간, 요청당 비용 | 품질을 감당 가능한 자원으로 제공하나? |
기억할 점: 작업 성공률 하나로 배포 여부를 판단하지 마세요. 안전 위반과 필수 조건 누락은 별도 지표와 통과 조건으로 관리해야 합니다.
평가 데이터와 채점 기준 만들기
실제 업무를 대표하는 사례를 모읍니다
평가 데이터셋에는 흔한 요청만 아니라 모호한 표현, 정보 부족, 도구 실패, 권한이 없는 요청, 여러 단계가 필요한 사례를 포함합니다. 개인정보와 고객 정보를 그대로 복사하지 말고 안전하게 비식별화하세요. 각 사례에는 입력, 기대 결과 또는 완료 조건, 허용되는 도구 행동, 금지 행동, 난이도와 위험 수준을 기록합니다. 합성 데이터로 시작할 수는 있지만 실제 사용 기록에서 드러난 실패를 반영해 계속 보완해야 합니다.
규칙 채점과 모델 채점을 구분합니다
JSON 형식, 필수 필드, 금지 도구 호출처럼 명확한 조건은 코드로 검사하면 반복 실행 시 일관성이 높습니다. 자연스러운 설명의 유용성이나 의미상 정확성처럼 정답이 하나로 고정되지 않는 항목은 평가 모델(LLM-as-a-judge, 다른 언어 모델을 채점자로 쓰는 방식)을 보조적으로 활용할 수 있습니다. 채점 프롬프트와 기준을 고정하고, 일부 결과를 사람이 재검토해 평가 모델의 오판을 찾으세요. 점수만 저장하지 말고 판단 근거와 실패 사례도 남기는 편이 개선에 유용합니다.
오프라인 테스트부터 운영 모니터링까지
변경 전후를 같은 사례로 비교합니다
프롬프트, 모델, 도구 설명이나 실행 로직을 바꾸면 같은 데이터셋으로 이전 버전과 새 버전을 평가합니다. 전체 평균뿐 아니라 업무 유형·위험 수준·실패 유형별 결과도 비교해야 특정 집단의 품질 하락을 놓치지 않습니다. 평균 점수가 조금 올랐더라도 안전 위반이 늘거나 핵심 사례의 성공률이 떨어졌다면 개선으로 단정할 수 없습니다. LangSmith의 평가 유형 공식 문서는 배포 전 오프라인 평가와 운영 중 온라인 평가, 코드·모델 기반 평가의 용도를 구분해 설명합니다. Amazon Bedrock AgentCore의 평가 안내는 작업 완료와 도구 호출 정확도를 평가 예로 들고, ground-truth 평가 안내는 예상 답변·조건(assertions)·도구 실행 경로를 기준 자료로 사용하는 방법을 설명합니다.
실서비스 사례를 다시 평가 데이터로 환류합니다
배포 후에는 사용자 피드백, 실패한 실행 기록, 긴 지연, 반복 호출과 같은 신호를 관찰합니다. 개인정보나 불필요한 민감 정보는 수집을 최소화하고 접근 권한과 보관 기준을 정하세요. 운영에서 발견한 문제는 재현 가능한 평가 사례로 정리해 다음 변경의 회귀 테스트에 포함합니다. 샘플링 평가를 쓴다면 표본이 전체 사용자를 대표하는지 확인하고, 드물지만 위험도가 큰 상황은 별도 테스트로 보완합니다.
- 업무 목표와 위험한 실패를 정의합니다.
- 대표 입력, 기대 조건, 허용·금지 행동을 데이터셋으로 만듭니다.
- 코드 검사와 사람 또는 모델 채점 기준을 지표별로 설정합니다.
- 변경 전후 같은 사례를 실행하고 세부 유형별 결과를 비교합니다.
- 배포 뒤 운영 신호를 확인하고 새 실패를 테스트 사례에 추가합니다.
통과 기준은 업무 위험도에 맞추세요. 모든 에이전트에 공통으로 적용할 성공률 숫자를 정하기보다, 허용할 수 없는 안전 위반과 필수 완료 조건부터 명시하고 그 기준을 충족하는지 확인해야 합니다.
자주 묻는 질문
Q. AI 에이전트 평가와 일반 챗봇 평가는 무엇이 다른가요?
챗봇은 주로 응답의 정확성과 유용성을 보지만, 에이전트는 도구 선택, 인수 전달, 실행 순서, 권한 준수와 작업 완료까지 평가해야 합니다. 도구를 사용하지 않는 상황에서 불필요한 호출을 하지 않는지도 확인합니다.
Q. 작업 성공률은 어떻게 계산하나요?
평가 사례별 완료 조건을 먼저 정한 뒤, 그 조건을 충족한 사례 수를 전체 유효 사례 수로 나눠 계산합니다. 일부 조건만 충족한 경우를 성공으로 셀지 부분 점수로 둘지는 업무 목적에 맞게 사전에 정의하세요.
Q. 평가 데이터가 적어도 시작할 수 있나요?
가능합니다. 우선 자주 발생하는 업무와 위험한 실패 사례를 작게 모아 기준을 세우고, 배포 전후 발견한 오류를 추가하면 됩니다. 사례 수보다 각 사례가 어떤 사용 상황과 실패 유형을 대표하는지 명확히 관리하는 것이 중요합니다.
Q. 모델 채점 결과만으로 배포해도 되나요?
모델 채점은 주관적인 항목을 빠르게 비교하는 데 도움이 되지만 오판할 수 있습니다. 명확한 규칙은 코드로 검사하고, 모델 채점 결과는 사람이 표본 검토해 신뢰도를 확인하세요. 안전이나 권한 관련 항목은 별도 규칙과 검토 절차를 두는 것이 좋습니다.
