AI 에이전트를 평가하는 방법: 테스트 세트, 채점기, 회귀 검사

모든 훌륭한 AI 제품 뒤에는 평가(evals)라고 불리는 탄탄한 AI 에이전트 평가 프로세스가 있습니다. 이 프로세스는 오류를 조기에 발견하고 에이전트가 제대로 작동하도록 보장합니다. 평가는 누군가를 대신해 환불 처리처럼 위험도가 높은 작업을 수행하는 AI 에이전트에 특히 중요합니다.

이러한 프로세스를 구축하려면 어느 정도의 기술 지식과 데이터 분석 역량이 필요합니다. 하지만 생각만큼 어렵거나 다가가기 힘든 일은 결코 아닙니다. 시작하는 데 도움이 되도록 AI 에이전트를 평가하는 6가지 실용적인 단계와 프로세스를 망치는 흔한 오해를 정리했습니다.

AI 에이전트를 평가한다는 것은 무엇을 의미할까요?

AI 에이전트를 평가한다는 것은 에이전트가 작업을 올바르게 완료하는 성능과 그 결정이 조직의 요구 사항을 충족하는지를 평가하는 것을 의미합니다. 실무적으로 AI 에이전트 평가, 즉 evals는 조직이 에이전트가 의도된 역할을 수행할 만큼 안정적으로 작동하는지 판단하는 데 도움이 되는 구체적인 지표입니다.

제조 공장에서 예비 부품 재고를 확인하고 보충 요청서를 준비하는 AI 구매 에이전트를 생각해 보세요. 승인된 부품을 구할 수 없거나 공급업체 정보가 오래되었다면, 에이전트는 문제를 알릴까요, 아니면 승인되지 않은 대체품을 추천할까요?

그리고 이 문제를 해결하려고 시스템 프롬프트를 변경했다면, 또 다른 문제가 생기지 않았다는 것을 어떻게 알 수 있을까요?

평가 체계가 없다면 프로덕트 매니저는 사실상 추측에 의존할 수밖에 없습니다. 따라서 평가는 성능을 측정하고, 반복되는 문제를 찾아내고, 더 큰 확신을 갖고 변경 사항을 테스트할 수 있는 피드백 신호를 제공합니다.

이러한 맥락에서 에이전트 평가에서는 실행의 여러 측면을 검토할 수 있습니다:

• 최종 결과의 품질
• 에이전트가 사용한 정보
• 에이전트가 호출한 도구
• 에이전트의 행동을 규정하는 규칙을 준수했는지 여부

일반적인 AI 에이전트 평가 지표

평가는 정성적 데이터와 정량적 데이터를 모두 다룹니다. 정성적 평가는 에이전트의 결정을 직접 검토하는 것을 포함해 무슨 일이 일어나고 있으며 그 이유가 무엇인지 이해하는 데 도움이 됩니다. 정량적 평가는 특정 실패 유형의 빈도를 세거나 작업 성공률을 계산하는 것처럼 이러한 관찰을 측정 가능한 신호로 바꿉니다.

기본적인 AI 에이전트 평가 지표는 다음과 같습니다:

• 작업 성공은 에이전트가 의도한 결과를 달성했는지를 측정하며, 일반적으로 유효한 결과를 만들어 낸 실행의 비율로 측정합니다.
• 행동 정확성은 에이전트가 도구를 적절하게 사용하고, 유효한 인수를 선택하고, 권한을 준수했는지를 측정합니다.
• 답변 품질은 최종 출력이 정확하고 완전하며 유용한지를 평가합니다. 여기에는 사실 정확성, 지침 준수 여부, 에이전트가 사용 가능한 정보로 결정의 근거를 뒷받침하는지 여부 등이 포함될 수 있습니다.
• 신뢰성은 반복 시행, 다양한 입력, 엣지 케이스 전반에서의 일관성을 측정합니다.
• 비용 및 지연 시간은 실행 시간, 토큰 소비량, 도구 호출을 포함해 성공적인 결과를 달성하는 데 필요한 리소스를 측정합니다.

측정하려는 대상에 따라 평가는 에이전트의 엔드투엔드 성능, 실행 궤적, 또는 도구 호출 및 검색 단계와 같은 개별 구성 요소를 평가할 수 있습니다.

1단계: 성공적인 에이전트 실행이 어떤 모습인지 정의하기

먼저 에이전트가 달성해야 하는 것, 즉 제품 요구 사항을 명확하게 기술하세요. 당연한 이야기처럼 들리지만, 의외로 어려울 수 있습니다. 이를 가리키는 용어도 따로 있는데, 바로 사양 격차(specification gap)입니다.

당사의 시니어 데이터 사이언티스트인 Andrey Khomutov는 다음과 같이 접근할 것을 권합니다:

“먼저 “무엇을 해야 작업을 완수했다고 볼 수 있는가?”와 “겉보기에는 성공한 실행이라도 무엇 때문에 받아들일 수 없게 되는가?”라는 두 가지 질문에서 출발하세요.

기술적인 관점에서 보면, 에이전트의 경우 이는 결과뿐 아니라 에이전트가 그 결과에 도달한 과정까지 모두 확인해야 한다는 뜻입니다.”

에이전트는 유출된 정답지에 접근해 올바른 답을 내놓거나, 작업을 완료하는 과정에서 승인되지 않은 행동을 할 수도 있습니다. Khomutov는 정답 유출과 평가 중 안전하지 않은 행동이 최종 답변만으로 판단해서는 안 되는 구체적인 이유라고 지적합니다.

“저는 궤적 검사가 결과가 의심스러워 보일 때만 하는 일이 아니라 에이전트 평가 스위트의 표준 요소가 될 것으로 예상합니다.” 그는 이렇게 덧붙입니다.

그런 다음 도메인 전문가를 참여시켜 성공 기준을 검증하세요. 해당 분야에 대한 실무 지식을 갖춘 사람은 AI 에이전트에 설정한 조건이 성공적인 결과를 제대로 반영하는지 판단할 수 있습니다.

2단계. 실제 작업과 실패 사례로 테스트 세트 구축하기

실제 에이전트 동작을 살펴보며 좋은 성능과 나쁜 성능이 어떤 모습인지 파악하세요. 무엇이 잘못될지에 대한 추측만으로 수십 개의 테스트를 생성하는 것부터 시작하고 싶은 유혹을 이겨내야 합니다.

Parlance Lab의 ML 엔지니어 Hamel Husain과 ML 시스템 및 응용 AI 평가 연구자 Shreya Shankar가 권장하는 방법은 머신러닝과 데이터 과학에서 빌려온 기법인 오류 분석으로 시작하는 것입니다. 이 프로세스는 에이전트 실행 트레이스에 대한 정성적 분석에서 출발합니다. 실행 트레이스란 사용자의 입력, 도구 호출, 검색된 정보, 에이전트 출력을 보여 주는 기록입니다.

1. 개별 트레이스를 검토하고 오류에 주석 달기(개방 코딩). 도메인 전문가에게 에이전트 실행을 검토하고 무엇이 잘못되었는지 짧은 관찰 내용을 작성하도록 하세요. 처음 발생한 의미 있는 오류에 집중하세요.
2. 관찰 내용을 실패 유형별로 분류하기(축 코딩). 메모가 충분히 쌓이면 LLM을 사용해 유사한 오류의 범주를 제안받으세요. 예를 들어 호환되지 않는 부품 추천, 부정확한 재고 조회, 사람 담당자로의 인계 실패 등이 있을 수 있습니다.
3. 발생 횟수 세기. 각 관찰 내용을 범주에 할당한 다음, 스프레드시트나 피벗 테이블을 사용해 각 실패 유형이 얼마나 자주 나타나는지 계산하세요.
4. 해결할 문제의 우선순위를 정하되, 빈도와 심각도를 모두 고려하세요.
5. 중요한 실패를 테스트 케이스로 만들기. 관련 입력, 시작 조건, 예상 결과, 채점 기준을 저장해 두면 동일한 시나리오로 에이전트를 다시 테스트할 수 있습니다.

트레이스를 몇 개나 검토해야 할까요? 대략 100개 정도지만, 정해진 숫자는 없습니다. 이론적 포화에 도달하면 일찍 멈추세요. 이론적 포화란 트레이스를 추가로 검토해도 의미 있는 새로운 실패 패턴이 더 이상 드러나지 않는 시점을 말합니다.

아직 애플리케이션을 출시하지 않았나요? 합성 예제로 초기 테스트 세트를 구축할 수 있지만, 실제 사용자 데이터를 확보하는 즉시 이를 반영해야 합니다.

AI 에이전트 평가에서 벤치마크 활용하기

자체 테스트 케이스를 만드는 것 외에도, 벤치마크라고 하는 기존의 표준화된 평가 작업 모음을 사용해 에이전트의 역량을 평가할 수 있습니다.

하지만 벤치마크가 완벽한 것은 아닙니다. SWE-bench 감사, Epoch AI의 벤치마크 검토, TheoPhysEval에서 처음에 거부되었던 정답 사례는 결함이 있는 작업이나 예상 답변이 평가 결과를 어떻게 왜곡할 수 있는지 잘 보여 줍니다.

Khomutov의 조언처럼, 도메인과 관련된 최신 벤치마크를 선택하고, 점수를 에이전트 성능의 신뢰할 수 있는 증거로 받아들이기 전에 예상 밖의 통과나 실패를 조사하세요.

3단계. 반복 가능한 테스트 환경에서 에이전트 실행하기

반복 가능한 테스트 환경이란 동일한 시작 조건에서 동일한 테스트 케이스로 AI 에이전트를 실행하고 결과를 비교할 수 있는 통제된 설정을 말합니다. 여기에는 테스트 케이스 폴더, 에이전트를 실행하는 Python 스크립트, 또는 결과를 평가하는 일련의 검사 등이 포함됩니다.

먼저 대표적인 입력을 JSON 파일로 저장하고, Python 스크립트로 에이전트의 워크플로우를 실행한 뒤 어설션으로 출력을 검사하는 것부터 시작할 수 있습니다. 앞서 예로 든 제조 공장의 재고 에이전트라면 반복 가능한 테스트 환경은 다음과 같을 수 있습니다:

확대

반복 가능한 테스트 환경을 설정하려면 다음 단계를 따르세요:

1. 대표적인 입력 저장하기. 실제 이벤트나 테스트 케이스를 애플리케이션이 프로덕션 환경에서 받는 것과 동일한 구조로 저장하세요. 이 시나리오에서는 기계 ID, 필요한 예비 부품, 유지보수 날짜가 포함된 유지보수 요청을 재고 및 승인 부품 데이터의 스냅샷과 함께 JSON 파일로 저장합니다.
2. 워크플로우 실행하기. 검색 단계, 도구 호출, 응답 생성을 포함해 각 입력을 에이전트에 넣어 실행하세요.
3. 결과와 트레이스 기록하기. 최종 출력과 관련된 중간 작업(예: 재고 조회)을 기록해 두면 에이전트가 실패했는지뿐 아니라 어디에서 실패했는지도 확인할 수 있습니다.
4. 실패의 심각도, 빈도, 문제 해결의 난이도에 따라 케이스 반복하기. LLM 애플리케이션은 비결정적이므로(동일한 입력에서도 다른 결과를 생성할 수 있음) 한 번 실행에 성공했다고 해서 다음 실행도 성공한다는 보장은 없습니다. 성공한 시행의 비율을 보고하고 실패 사례를 검토하세요.

후자와 관련해 Khomutov는 pass@1(에이전트가 한 번의 시도에서 성공하는 빈도)과 pass@k(지정된 시도 횟수 중 적어도 한 번 성공할 확률)를 측정할 것을 권합니다. pass@k를 보고할 때는 시도 횟수를 명시하세요. 여러 답 중 하나가 정답이라고 해서 에이전트가 그중 어떤 답을 골라야 하는지 안다는 뜻은 아니기 때문입니다.

애플리케이션 규모가 커지면 pytest 같은 테스트 프레임워크를 사용해 테스트를 구성하고 실행하며, 대규모 테스트 데이터 세트와 결과를 데이터베이스에 저장하는 것도 고려해 보세요.

4단계. 검사마다 적합한 그레이더 선택하기

그레이더(흔히 평가자라고도 함)는 코드, 채점 루브릭에 따라 판단하는 LLM, 또는 사람 검토자의 형태로 에이전트의 출력이나 행동을 정의된 기준에 비추어 확인하는 메커니즘입니다. 그레이더는 통과/실패 판정과 함께 관련 근거를 짚어 주는 설명을 반환합니다.

참고: 채점 루브릭은 무엇을 올바르거나 허용 가능한 결과로 볼지 정의하는 기준과 지침의 모음입니다.

적합한 그레이더 유형은 무엇을 검증하려는지에 따라 달라집니다. 세 가지 접근 방식을 비교하면 다음과 같습니다:

같은 실행이라도 측면에 따라 서로 다른 평가 방법이 필요할 수 있으므로, 여러 그레이더를 조합해야 할 수도 있습니다.

그레이더는 어떻게 조합할까요?

이렇게 질문해 보세요. “결과를 알려진 규칙이나 예상 값과 대조해 검증할 수 있는가, 아니면 사람과 같은 판단이 필요한가?”

• 결과를 정확하게 검증할 수 있다면 코드 기반 그레이더로 시작하세요. 코드 기반 그레이더는 구조화된 출력, 유효한 필드 값, 도구 인수, 데이터베이스의 최종 상태도 검증할 수 있습니다.
• 검사에 맥락 해석이 필요하다면 LLM-as-a-judge를 사용하세요.
• 도메인 전문 지식이 필요하거나 의견이 갈리는 결정에는 사람 검토자를 활용하세요.

중요! LLM 그레이더는 근거를 잘못 해석하거나 루브릭을 잘못 적용할 수 있습니다. 따라서 추가적인 평가 단계, 즉 사람의 판단을 기준으로 한 보정이 필요합니다.

사람의 판단을 기준으로 LLM 그레이더를 보정하세요.

기본적으로 보정을 하려면 도메인 전문가가 실제 에이전트 실행을 평가해야 합니다. 그런 다음 전문가는 자신의 판단을 LLM의 판단과 비교하고, 서로 엇갈린 부분을 바탕으로 채점 루브릭을 개선합니다.

다음은 5단계로 이루어진 그레이더 보정 프로세스입니다:

1. 에이전트의 입력, 출력, 관련 트레이스 예시를 수집하세요.
2. 도메인 전문가에게 각 예시가 평가 기준을 충족하는지 독립적으로 평가하도록 하세요.
3. 해당 예시에 대해 LLM 그레이더를 실행하세요.
4. 사람의 판단과 모델의 판단을 비교하세요.
5. 판단이 엇갈린 부분을 조사하고, 새로운 예시로 테스트하기 전에 그레이더의 루브릭을 개선하세요.

Khomutov는 LLM 그레이더의 일관성을 별도로 테스트하는 것도 중요하다고 강조합니다:

“에이전트를 다시 실행하지 말고, 저장해 둔 동일한 실행과 파일을 그레이더에 여러 번 제공하세요. 그러면 에이전트 작업의 변동과 채점의 변동을 분리해서 볼 수 있습니다.”

같은 출력에 서로 다른 판정이 나온다면 모든 점수 변화가 에이전트 때문이라고 단정하지 마세요. 대신 그레이더가 오류를 정확히 식별한 경우, 놓친 경우, 허용 가능한 출력을 잘못 지적한 경우를 보여 주는 혼동 행렬을 살펴보세요.

사람의 검토는 기준이 되는 판단을 수립하고, 의견이 갈리는 사례를 해결하며, 기존 그레이더가 감지하도록 설계되지 않은 새로운 실패 유형을 발견하는 데 여전히 필수적입니다.

5단계. 버전 비교 및 회귀 검사 실행하기

오류 분석 결과, 재고 에이전트가 승인되지 않은 교체 부품을 자주 추천한다는 사실이 드러났다고 가정해 보겠습니다. 명시적인 호환성 검사를 요구하도록 시스템 프롬프트를 수정하자 원래 실패하던 케이스가 이제 통과합니다. 그런데 이 변경이 다른 작업에 영향을 미치지 않았다는 것을 어떻게 알 수 있을까요?

바로 이때 회귀 테스트가 필요합니다.

회귀 테스트란 에이전트의 프롬프트, 모델 또는 워크플로우를 변경한 후 이전에 성공했던 테스트 케이스를 다시 실행해 변경으로 인해 새로운 실패가 발생하지 않았는지 확인하는 것을 말합니다.

1. 테스트 세트에 저장된 입력을 사용해 원래의 실패를 재현하세요.
2. 프롬프트, 모델 또는 워크플로우에서 필요한 부분만 정확히 수정하세요.
3. 실패한 테스트를 다시 실행해 문제가 해결되었는지 확인하세요.
4. 나머지 테스트를 실행해 변경 사항 때문에 이전에 정상적으로 작동하던 부분이 망가지지 않았는지 확인합니다.
5. 결과를 검토하고 새로 발생한 실패를 조사합니다.

정확한 결과를 얻으려면 동일한 테스트 케이스와 채점 기준을 사용해 기준 에이전트와 업데이트된 에이전트를 비교합니다.

6단계: 프로덕션 환경에서 AI 에이전트 성능 모니터링

에이전트 평가는 애플리케이션을 배포한 후에도 끝나지 않습니다. Husain과 Shankar가 설명하듯이, 개발 단계에서 사용하는 것과 동일한 평가기를 실제 프로덕션 데이터를 대상으로 실행하여 시간이 지남에 따라 에이전트의 성능이 어떻게 변하는지 측정할 수 있습니다.

이를 온라인 평가라고 하며, 반복적으로 발생하는 실패와 이전에 알려지지 않았던 실패를 찾아내는 데 도움이 되는 더 폭넓은 프로덕션 모니터링 프로세스의 일부입니다.

이 프로세스는 반복적으로 진행되며, 서로를 보완하는 네 가지 활동으로 이루어집니다:

• 프로덕션 트레이스에 보정된 LLM 심사자를 실행합니다. 실제 에이전트 상호작용을 샘플링하고, 사람의 판단과 대조해 이미 검증한 평가기를 적용합니다.
• 시간 경과에 따른 실패율을 추적합니다. 오류 분석 과정에서 정립한 실패 범주를 활용해 반복되는 문제를 정량화합니다.
• 트레이스를 계속 수동으로 검토합니다. 자동 채점기는 탐지하도록 설계된 문제만 찾아냅니다. 실제 에이전트 상호작용 샘플을 직접 검토해 새로운 오류나 특이한 사용자 요청을 발견합니다.
• A/B 테스트로 비즈니스 성과를 측정합니다(적절한 경우에만). 작업 완료율, 사용자 만족도, 해결 소요 시간 등의 지표를 사용해 서로 다른 프롬프트, 모델 또는 워크플로우를 비교합니다. 이 과정을 통해 변경 사항이 개별 테스트 통과를 넘어 실제 제품 경험을 개선하는지 판단할 수 있습니다.

한 가지 중요한 점이 있습니다. 평가를 완벽하게 다듬을 필요는 없습니다. 제품을 개선하는 데 충분할 만큼만 좋으면 됩니다.

AI 에이전트 평가에 관한 흔한 오해

• 평가는 단위 테스트일 뿐이다. 그렇지 않습니다. 단위 테스트는 소규모 자동 검사로, 평가의 한 부분에 불과합니다. 평가에는 애플리케이션 품질을 측정하기 위한 정성적 오류 분석, 사람의 판단, 프로덕션 모니터링, 실험도 포함됩니다.
• 평가 플랫폼이 모든 것을 대신해 줄 수 있다. 기성 도구로 일부 검사를 자동화할 수는 있지만, 어떤 실패 모드(오류 유형 또는 원치 않는 에이전트 동작)가 제품에 중요한지는 판단할 수 없습니다.
• LLM에게 모든 평가를 맡겨도 된다. 이는 큰 착각입니다. LLM에는 모든 문제를 발견하는 데 필요한 비즈니스 맥락이 없으므로, 사람이 주도하는 오류 분석과 채점기 보정은 여전히 필수적입니다.
• A/B 테스트나 에이전트를 직접 사용해 보는 것으로 평가를 대체할 수 있다. 사실이 아닙니다. A/B 테스트는 선택한 지표에서 어떤 버전의 성능이 더 나은지 보여 줄 수는 있지만, 그 자체만으로는 근본적인 문제를 설명할 수 없습니다.

AI 에이전트 평가 FAQ

1. AI 에이전트 평가와 LLM 평가의 차이점은 무엇인가요?

LLM 평가는 질문 답변, 문서 요약, 정보 추출 등 주어진 작업을 언어 모델이 얼마나 잘 수행하는지 측정합니다. AI 에이전트 평가는 작업을 완료하기 위해 여러 단계를 독립적으로 실행하는 시스템을 평가합니다.

일반적인 LLM 평가와 달리 에이전트 평가는 최종 결과뿐 아니라 이를 달성하기 위해 수행한 일련의 행동, 즉 도구 호출, 의사 결정, 사전 정의된 규칙 준수 여부까지 함께 살펴봅니다.

2. AI 에이전트 평가의 주요 지표

AI 에이전트 평가 지표는 크게 두 가지 범주로 나뉩니다:

• 기술적 성능 지표: 작업 성공률, 행동 정확성, 답변 품질, 신뢰성(pass@1 및 pass@k), 지연 시간, 토큰 사용량, 성공한 작업당 비용.
• 비즈니스 및 사용자 경험 지표: 고객 만족도(CSAT), 문제 해결률, 에스컬레이션 비율, 전환율, 작업 완료 시간 및 에이전트의 역할에 따른 기타 성과.

예를 들어 고객 지원 에이전트는 문제 해결 성공 여부와 고객 만족도로 평가할 수 있고, AI 구매 에이전트는 재고 보충 요청의 정확도, 승인율, 조달 주기 시간으로 측정할 수 있습니다.

적절한 지표는 에이전트가 얼마나 안정적으로 작동하는지, 그리고 에이전트의 작업이 비즈니스 성과를 개선하는지를 모두 반영해야 합니다.

3. AI 에이전트 평가에 가장 적합한 도구는 무엇인가요?

일반적인 옵션은 다음과 같습니다:

• 테스트 프레임워크: Python 어설션과 pytest는 반복 가능한 테스트 케이스를 실행하고, 에이전트가 올바른 도구를 선택했는지 또는 유효한 부품 ID를 반환했는지 등 정확한 조건을 확인하는 데 유용합니다.
• AI 에이전트 평가 프레임워크: DeepEval과 Google의 agent-eval 툴킷은 실행 트레이스, LLM 기반 채점기, 자동화된 회귀 테스트를 포함한 더 복잡한 평가를 지원합니다.
• 평가 및 관측성 플랫폼: LangSmith, Arize Phoenix, MLflow는 팀이 에이전트 동작을 검사하고, 평가 데이터 세트를 관리하고, 에이전트 버전을 비교하고, 프로덕션 환경의 성능을 모니터링하는 데 도움이 됩니다.

4. AI 에이전트 평가를 자동화하려면 어떻게 해야 하나요?

반복 가능한 테스트를 구축하고, 자동 채점기를 적용하고, 이러한 검사를 개발 및 프로덕션 워크플로우에 통합하여 AI 에이전트 평가를 자동화할 수 있습니다:

1. 평가 데이터 세트 만들기: 대표적인 사용자 작업, 예상 결과, 알려진 실패, 에이전트 실행 트레이스를 수집합니다. 실패한 도구 호출, 누락된 정보, 무단 작업과 같은 엣지 케이스도 포함합니다.
2. 테스트 실행 및 채점 자동화: pytest나 DeepEval 같은 프레임워크를 사용해 테스트 케이스를 실행하고 코드 기반 검사나 LLM 채점기를 적용합니다. LLM 채점기의 점수를 신뢰하기 전에 사람의 판단과 대조해 검증합니다.
3. CI/CD에 평가 통합: 개발자가 에이전트의 프롬프트, 모델, 도구 또는 워크플로우를 업데이트하면 회귀 테스트를 자동으로 다시 실행합니다. 결과를 기준선과 비교하고, 핵심 검사가 실패하면 릴리스를 막는 품질 임곗값을 설정합니다.
4. 샘플링한 프로덕션 트레이스에 보정된 채점기를 적용하고, 실패율 및 기타 성능 지표를 추적하며, 수동 검토를 통해 새로운 오류를 조사합니다.