AI 에이전트 평가: 정답률에 추적·결과를 더하는 절차

여러 단계로 도구를 쓰는 AI 에이전트는 답변이 맞아 보이는지만으로 평가할 수 없다. 먼저 과제마다 성공 조건을 정하고, 실행이 끝난 뒤 실제 업무 상태와 도구 사용 기록을 각각 확인해야 한다. 구조화된 결과는 코드로 채점하고, 한국어 설명의 적절성은 모델과 사람이 평가한 다음, 같은 과제를 반복 시행해 결과가 얼마나 안정적인지 본다.

가상의 한국어 고객지원 에이전트가 환불 요청에 ‘처리했습니다’라고 답했다고 하자. 고객에게 적용되는 규정을 확인했는지, 필요한 도구를 적절히 사용했는지, 실제 환불 상태가 바뀌었는지는 서로 다른 질문이다. 아래 환불 사례는 평가 절차를 설명하기 위한 가정이며, 특정 서비스에서 관찰한 운영 결과가 아니다.

작업과 성공 조건을 먼저 고정한다

평가의 기본 단위는 막연한 ‘좋은 응대’가 아니라 입력과 기대 결과가 명시된 작업이다. 고객의 한국어 요청, 주문의 초기 상태, 적용할 환불 규정, 사용 가능한 도구와 도구가 반환할 값을 한 과제에 묶는다. 정답 문장 하나를 지정하기보다 허용되는 최종 상태와 금지되는 행동을 적으면, 표현이 달라도 같은 기준으로 판단할 수 있다.

환불 가능한 주문이라면 규정에 필요한 확인을 거쳐 환불이 실행되고, 고객에게 처리 결과가 정확히 전달되는 것이 성공 조건이다. 환불 대상이 아닌 주문이라면 상태를 바꾸지 않고 그 이유를 설명하는 것이 성공이다. 두 유형을 함께 넣어야 필요한 실행을 빠뜨리는 경우와 해서는 안 될 실행을 하는 경우를 모두 발견할 수 있다. 과제의 초기 상태와 규정 자료를 보관하면 변경 전후의 에이전트를 같은 조건에서 비교할 수 있다.

실행 추적과 최종 상태를 따로 확인한다

OpenAI의 에이전트 평가 안내는 한 번의 실행에서 모델 호출, 도구 호출, 가드레일, 인계까지 이어지는 추적을 채점해 실패 유형과 회귀를 찾도록 설명한다. 환불 과제에서는 어떤 도구를 어떤 순서로 불렀고 무엇을 전달받았는지 시행별로 남겨야 한다. 과제와 추적을 연결해 두면 실패한 고객 응답에서 판단이 갈라진 단계까지 거슬러 올라갈 수 있다.

추적과 별개로, 실행이 끝난 뒤 주문·환불 시스템의 상태를 읽어 기대한 결과가 존재하는지 확인한다. 답변은 완료를 주장하지만 상태 변경이 없다면 작업 결과가 실패한 것이다. 상태는 바뀌었어도 해당 업무에서 요구한 본인 확인을 건너뛰었다면 절차에 문제가 있다. 두 기록을 분리하면 응답 생성, 도구 연결, 업무 규칙 가운데 어디를 고쳐야 할지 좁힐 수 있다.

코드·모델·사람에게 서로 다른 판정을 맡긴다

Anthropic의 에이전트 평가 지침은 작업과 개별 시행, 채점기, 실행 기록, 최종 환경 상태를 구분하고 코드·모델·사람 채점을 조합한다. 코드 기반 채점기는 최종 주문 상태, 금지된 환불 실행, 중복 처리처럼 구조화된 조건에 적합하다. 필수 확인 절차도 기록에서 검사할 수 있지만, 업무상 꼭 필요한 조건과 단지 예상한 호출 순서는 구분해야 한다.

자연어 답변은 한국어 안내가 규정에 근거하는지, 고객에게 실제 처리 결과를 정확히 전달하는지 평가한다. 모델 채점기에는 대화만 주지 말고 적용할 규정과 판정 기준도 함께 제공해야 근거 없는 약속이나 설명 누락을 구별할 수 있다. 표현을 한 문장과 똑같이 맞추도록 하면 의미상 올바른 답변까지 탈락할 수 있다. 판단이 갈리는 사례는 담당자가 읽고 채점 기준을 조정한다.

도구 호출을 평가할 때도 모든 성공 경로에 똑같은 순서를 강제할 필요는 없다. 예컨대 환불 실행 전에 신원 확인이 반드시 필요하다는 업무 규칙은 검사하되, 규정 조회와 주문 조회의 순서가 결과에 영향을 주지 않는다면 둘 중 한 순서만 정답으로 취급하지 않는다. 이 구분이 있어야 절차 위반을 잡으면서도 유효한 해결 경로를 잘못 실패로 표시하지 않는다.

반복 시행에는 같은 출발 상태가 필요하다

모델의 출력은 시행마다 달라질 수 있으므로 한 번의 합격으로 안정성을 판단하기 어렵다. 같은 과제를 여러 차례 실행하되 주문의 초기 상태, 대화 기록, 사용 가능한 도구와 규정 자료를 매번 되돌린다. 앞선 시행의 환불 기록이 남아 있으면 다음 시행의 결과가 에이전트의 행동 때문인지, 남아 있던 상태 때문인지 구별하기 어렵다.

에이전트의 모델과 프롬프트 버전, 도구 설정, 과제 버전도 시행 기록에 함께 둔다. 결과를 모을 때는 전체 평균만 보지 않고 환불 가능·불가 과제별 성공 여부와 실패 유형을 나눠 본다. 실행 누락, 잘못된 실행, 한국어 안내의 오류는 원인과 수정 방법이 다르기 때문이다. 점수가 예상과 다르면 해당 추적을 읽어 에이전트의 실패인지 과제 설명이나 채점기의 오류인지 확인한다.

한국어 고객지원 평가 설계표

다음 항목을 한 과제에 연결하면 입력부터 배포 판정까지 빠짐없이 기록할 수 있다. 합격 기준의 수치는 서비스의 업무 규칙과 허용 위험에 맞춰 정해야 하므로 여기서는 임의의 성공률을 제시하지 않는다.

작업 입력: 고객 요청, 주문의 초기 상태, 적용할 규정, 허용된 도구와 그 반환값을 저장한다. 환불 가능 사례와 환불 불가 사례를 별도 과제로 둔다.
성공 조건: 가능한 요청은 필요한 확인 후 실제 환불 상태가 바뀌고 결과가 안내돼야 한다. 불가능한 요청은 상태 변경 없이 사유가 설명돼야 한다.
실행 추적: 시행별 모델 응답, 도구 호출과 반환값, 가드레일 판단, 사람에게 넘긴 경우의 인계를 기록한다. 과제와 시행을 식별할 수 있게 연결한다.
코드 채점: 최종 상태와 필수 절차를 검사하고 금지된 실행이나 중복 환불을 실패로 표시한다. 허용되는 여러 도구 사용 경로를 불필요하게 한 순서로 제한하지 않는다.
모델·사람 채점: 한국어 설명이 규정과 실제 결과에 맞는지 평가한다. 불명확한 판정과 배포에 영향을 주는 경계 사례는 사람이 검토해 기준을 다듬는다.
반복·회귀 판정: 초기 상태를 복원해 같은 과제를 반복하고, 작업별 결과와 실패 유형을 이전 버전과 비교한다. 중대한 절차 위반은 안내 문구의 좋은 점수로 상쇄하지 않는다.

변경 전후에는 같은 과제로 회귀를 판정한다

프롬프트, 모델, 도구 연결 또는 업무 규칙을 바꿨다면 보관한 과제 묶음을 새 버전에도 실행한다. 환불 가능한 요청의 안내가 좋아졌더라도 환불 불가 요청에서 실행 도구를 잘못 사용한다면 해당 변경에는 문제가 있다. 반대로 문구만 달라지고 최종 상태와 필수 절차가 모두 맞다면 단순한 문자열 차이를 회귀로 세지 않는다.

배포 판정에서는 작업별 최종 상태, 절차 위반, 한국어 안내 품질, 반복 시행의 변동을 함께 놓는다. 실패가 늘어난 과제는 추적에서 처음 판단이 달라진 단계와 도구 반환값을 확인하면 수정 대상을 구체화할 수 있다. 같은 과제와 채점 기준으로 다시 시행해야 수정 후의 변화도 비교할 수 있다.

함께 읽기: