The agent evaluation playbook: Built-in, DeepEval, and AutoEval on Amazon Bedrock AgentCore Evaluations
Quick Summary
Amazon Bedrock AgentCore Evaluations는 업무 성과를 관찰 가능한 행동으로 나누고, 내장·DeepEval·AutoEval·사용자 정의 평가기를 조합해 에이전트의 품질과 위험을 개발부터 운영까지 평가하는 접근법을 제시한다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약
Amazon Bedrock AgentCore Evaluations는 업무 성과를 관찰 가능한 행동으로 나누고, 내장·DeepEval·AutoEval·사용자 정의 평가기를 조합해 에이전트의 품질과 위험을 개발부터 운영까지 평가하는 접근법을 제시한다.
📌 핵심 요약
- 출력 표본 점검, 지연 시간, 사용자 피드백만으로는 과업 완료, 장기 대화의 일관성, 개인정보(PII) 유출, 절차 누락을 충분히 확인하기 어렵고, 높은 과업 완료율도 다른 실패를 가릴 수 있다.
- 평가는 업무 성과 정의, 관찰 가능한 행동으로 분해, 적절한 평가기와 수준에 연결하는 순서로 설계하며, 업무 성과를 가장 잘 보여주는 핵심 행동 2~3개부터 측정하고 놓친 실패가 발견될 때 확장한다.
- AgentCore는 AWS가 작성하고 품질을 검증한 내장 평가기, DeepEval·AutoEval의 관리형 평가기, 모델·프롬프트·평가 기준을 조정할 수 있는 사용자 정의 평가기를 제공한다.
- 다차원 평가기는 같은 증거에서 판단할 수 있는 여러 기준을 한 번의 판정 호출로 평가하고 차원별 결과를 반환한다. 정확성과 정책 준수처럼 독립적으로 실패할 수 있는 기준을 분리해 확인할 수 있지만, 모든 차원은 같은 평가 수준과 판정 모델을 공유한다.
- 온디맨드 평가는 개발·디버깅, 온라인 평가는 실시간 트래픽 표본의 운영 상태 확인, 배치 평가는 고정 세션 집합의 회귀 검증에 쓰인다. 세 모드는 같은 평가기 ID를 사용하며, 정답이나 예상 경로가 필요한 평가는 배치 평가에서만 실행한다.
🧩 주요 포인트
- 업무 성과에서 평가 기준을 도출하면 지표 이름에 끌려 선택하는 문제를 줄일 수 있다. 개별 턴·도구 호출은 트레이스 수준에서, 대화 전체의 목표 달성은 세션 수준에서 판단하는 구분이 중요하다.
- 과업 완료와 안전성은 서로 다른 실패를 드러낸다. 정확성·정책 준수 등의 차원별 결과는 종합 점수가 감추는 퇴행을 식별하는 데 유용하며, 증거·평가 수준·판정 모델이 다른 기준은 별도 평가기로 유지해야 한다.
- 같은 평가기 ID를 사용하는 세 실행 모드는 개발과 운영의 평가 연속성을 지원한다. 다만 정답이나 예상 경로가 필요한 기준과 참조 자료 없이 실행 가능한 기준을 분리해야 실시간 트래픽 평가에도 적용할 수 있다.
🧠 상세 정리
1. 실행 여부보다 업무 성과를 평가해야 하는 이유
운영 환경에 배포한 에이전트의 성공 기준은 단순히 실행되는지가 아니라, 규모가 커져도 업무에서 요구하는 일을 수행하는지에 있다. 많은 팀이 출력 일부를 점검하고 지연 시간을 관찰하며 가능한 범위에서 사용자 피드백을 수집하지만, 이런 신호만으로는 사용자의 과업을 끝냈는지, 긴 대화에서 주제를 유지했는지, 개인정보를 유출했는지, 필요한 절차를 생략했는지 알기 어렵다. 원문은 고객 지원 에이전트가 모든 티켓을 해결하더라도 답변에서 개인정보를 노출한다면 실패한 것이라고 설명한다. 따라서 높은 완료율 하나를 전체 성공으로 받아들이기보다, 각 에이전트에 중요한 행동을 적절한 세부 수준에서 함께 측정해야 한다.
2. 업무 성과를 행동과 평가 수준으로 연결하는 세 단계
평가 설계에서 흔한 실수는 지표 목록을 먼저 보고 Helpfulness처럼 좋아 보이는 이름을 선택하는 것이며, 이 경우 수치는 나오지만 실제 성공을 설명하는 통찰은 부족할 수 있다. 원문은 먼저 업무 용어로 성공을 정의하라고 제안하며, 고객 지원의 최초 접촉 해결, 검색 문서에 전적으로 근거한 완전하고 출처가 충실한 연구 답변, 필요한 항목만 빠짐없이 식별하는 콘텐츠 조정을 예로 든다. 다음으로 성과를 관찰 가능한 행동으로 나누는데, 고객 지원에서는 사용자 목표 완수, 여러 턴의 일관성, 규정 준수, 티켓 생성이나 주문 조회 도구의 올바른 호출이 여기에 해당한다. 마지막으로 각 행동을 적절한 평가기에 연결하며, 개별 턴이나 도구 호출은 트레이스 수준에서, 대화 전체를 봐야 의미가 있는 결과는 세션 수준에서 평가한다.
3. 내장·관리형·사용자 정의 평가기의 역할
AgentCore의 평가기 카탈로그는 AWS 내장 평가기, DeepEval·AutoEval의 서드파티 관리형 평가기, 사용자 정의 평가기로 구성된다. 내장 평가기는 AWS가 작성하고 품질과 신뢰성을 검증하며, 사용자는 Builtin.GoalSuccessRate나 Builtin.Helpfulness 같은 ID로 참조하고 나머지 실행은 서비스에 맡긴다. 서드파티 관리형 평가기는 AgentCore가 코드를 호스팅하고 판정 모델을 선택하며 자체 용량으로 추론하므로, 개발에서 쓰던 라이브러리의 지표를 별도 평가 서비스 없이 운영에서도 사용할 수 있다. 사용자 정의 파생 평가기는 내장 또는 서드파티 평가기를 바탕으로 모델을 교체하고 프롬프트나 평가 기준을 수정할 수 있으며, 생성 후에는 다른 평가기와 같은 방식으로 사용한다. 카탈로그에 맞는 평가기가 없는 경우에는 사용자 정의 LLM 판정 평가기를 작성할 수 있고, 정확한 정의·척도·입력 요건은 AgentCore 문서의 프롬프트 템플릿 라이브러리에서 확인할 수 있다.
4. AWS 내장 평가기와 도구 실행 경로 검증
AWS 내장 평가기는 응답 품질, 과업 및 목표 완료, 도구 사용, 스킬 사용, 안전성의 다섯 범주를 다룬다. 응답 품질에는 Correctness, Faithfulness, Helpfulness, ResponseRelevance, Conciseness, Coherence, InstructionFollowing, Refusal이 포함되며, GoalSuccessRate는 세션 전체에서 사용자 목표 달성 여부를 판단한다. 도구 사용은 ToolSelectionAccuracy와 ToolParameterAccuracy로 선택과 인수를 확인하고, 스킬 사용은 SkillSelectionAccuracy와 SkillInstructionFollowing으로 적절한 스킬 호출과 단계 준수를 확인한다. 안전성 범주는 Harmfulness와 Stereotyping을 제공한다. 별도로 TrajectoryExactOrderMatch, TrajectoryInOrderMatch, TrajectoryAnyOrderMatch는 실제 도구 실행 경로를 예상 경로와 비교하므로, 최종 결과뿐 아니라 도달 과정 자체가 중요한 상황에 적합하다.
5. DeepEval과 AutoEval이 제공하는 보완 신호
DeepEval의 관리형 지표는 과업·목표 완료에 TaskCompletion, GoalAccuracy, ConversationCompleteness를, 대화 품질에 TurnRelevancy, KnowledgeRetention, Summarization을 제공한다. 도구 사용에는 ToolUse가 있고, 안전성에는 Bias, Toxicity, PIILeakage가 포함된다. 특히 ConversationCompleteness는 최신 메시지에는 답했지만 이전 요청을 누락한 경우를, KnowledgeRetention은 사용자가 세 턴 전에 말한 내용을 잊은 경우를 포착하므로 여러 턴에 걸친 에이전트 평가에 유용하다. AutoEval은 더 특화된 신호를 제공하며, Security는 지시 주입이나 시스템 프롬프트 공개 시도 같은 악성 출력을 식별하고 Possible은 유효한 과업을 불가능하다고 잘못 선언하는 과도한 신중함을 탐지한다. Humor는 개성이 제품의 일부인 소비자 대상 에이전트에서 활용할 수 있는 평가 항목으로 소개된다.
6. 다차원 평가기의 이점과 분리해야 할 조건
하나의 고객 지원 답변이 문제 해결, 환불·데이터 정책 준수, 전문적인 태도를 모두 충족해야 할 때 이를 단일 점수로 합치면 어느 기준이 결과를 좌우했는지 알기 어렵다. 다차원 평가기는 각 차원에 이름·지시·숫자형 또는 범주형 척도를 두고, 판정 모델이 트레이스를 한 번 읽어 모든 차원을 평가한 뒤 종합 점수 없이 차원별 결과를 반환한다. 같은 증거에서 판단할 수 있으면서 독립적으로 실패할 수 있는 기준에 적합하며, 말투는 개선됐지만 정책 준수가 악화된 변경도 기준별로 식별할 수 있다. 다만 Builtin.Correctness나 ThirdParty.DeepEval.PIILeakage처럼 기존 평가기가 이미 적합한 경우에는 별도로 유지하는 것이 권장된다. 서로 다른 평가 수준이나 판정 모델이 필요한 기준도 분리해야 하며, 일부 기준에 {expected_response}나 {assertions} 같은 정답 자료가 필요하다면 참조 자료가 필요 없는 기준을 별도 평가기로 남겨 실시간 트래픽에서도 실행할 수 있게 해야 한다.
7. 에이전트 유형별 초기 평가 조합과 확장
원문은 각 에이전트의 업무 성과에 가장 잘 맞는 평가기 2~3개로 시작하고, 기존 조합이 놓치는 실패가 발견될 때 추가하도록 제안한다. 고객 지원은 한 세션에서 문제를 해결하면서 후속 위험을 만들지 않는 것이 목표이므로 Builtin.GoalSuccessRate를 중심으로 ThirdParty.DeepEval.ConversationCompleteness와 ThirdParty.DeepEval.PIILeakage를 사용하고, 필요하면 Toxicity나 민감한 계정 데이터를 위한 Security를 더한다. 여러 단계의 연구는 정해진 작업 흐름을 거친 완전하고 출처가 충실한 답변을 목표로 하며, 정답 자료가 필요한 Builtin.TrajectoryAnyOrderMatch에 ThirdParty.DeepEval.GoalAccuracy와 ThirdParty.DeepEval.KnowledgeRetention을 조합한다. 연구 에이전트에는 필요에 따라 Builtin.Helpfulness, Builtin.SkillInstructionFollowing, ThirdParty.AutoEval.Possible을 추가하며, 추론을 사용자 계정 안에서 수행해야 한다면 경로·스킬 평가에 파생 평가기를 사용한다. 의료·법률·금융 같은 전문 분야는 오답이 무응답보다 더 나쁘다는 위험을 전제로, 정답 자료가 필요한 Builtin.Correctness와 ThirdParty.DeepEval.PIILeakage, ThirdParty.AutoEval.Security로 시작하고 필요하면 Bias와 Helpfulness를 추가한다. 전문 분야에서는 모든 판정 호출을 데이터 거버넌스 아래에 두기 위해 거의 항상 파생 평가기를 사용하는 구성이 제시되며, 정답이나 예상 경로가 필요한 항목은 배치 평가에서만 실행한다.
8. 세 가지 실행 모드와 점진적인 평가 확장
온디맨드 평가는 개발이나 디버깅 중 세션을 client.evaluate()에 직접 전달하는 가장 빠른 피드백 경로이며, 서드파티를 포함한 모든 평가기를 사용할 수 있다. 예제는 ThirdParty.DeepEval.TaskCompletion에 sessionSpans를 전달하고 반환된 평가 결과의 값과 설명을 읽는 방식이다. 온라인 평가는 실행 중인 에이전트 런타임에 연결해 설정한 비율로 실제 트래픽을 표본 추출하며, 하나의 설정에서 내장 평가기와 서드파티 평가기를 함께 사용해 운영 상태를 확인한다. 배치 평가는 고정된 세션 집합인 골든 데이터셋에 평가기 조합을 실행해, 출시 전 프롬프트 변경이나 모델 업그레이드가 필요한 품질 차원을 유지했는지 검증한다. 세 모드가 같은 평가기 ID를 사용하므로 온디맨드 개발 평가에서 운영 온라인 평가로 이동할 때는 코드 재작성 대신 설정 변경으로 전환할 수 있다. 원문은 업무 성과를 보여주는 소수의 행동부터 측정하고 놓친 실패에 따라 평가기를 추가하라고 정리하며, ListEvaluators API로 내장·서드파티·자체 사용자 정의 평가기를 함께 조회할 수 있다고 설명한다.
🧾 핵심 주장 / 시사점
- 에이전트의 성공은 단일 점수보다 여러 행동의 동시 충족으로 판단해야 한다. 과업 완료율이 높아도 개인정보 유출이나 정책 위반이 있으면 업무 성과를 달성했다고 보기 어렵다.
- 평가기를 합칠지는 호출 수보다 판단 조건에 따라 결정해야 한다. 같은 증거·평가 수준·모델을 공유하는 기준은 다차원 평가에 적합하지만, 정답 자료의 필요 여부가 다르면 분리해야 운영 평가의 적용 범위를 유지할 수 있다.
- 평가 체계는 처음부터 모든 지표를 실행하는 방식보다 핵심 행동 2~3개에서 시작해 실제로 놓친 실패를 보완하는 방식으로 확장할 수 있다.
✅ 액션 아이템
- 업무 성과를 관찰 가능한 행동으로 나누고, 핵심 행동 2~3개에 대응하는 평가기와 트레이스·세션 수준을 선정.
- 정확성·정책 준수처럼 독립적으로 실패할 수 있는 기준은 차원별로 확인하고, 평가 수준이나 판정 모델이 다르면 별도 평가기로 분리.
- 정답이나 예상 경로가 필요한 기준은 배치 평가에 배치하고, 실시간 트래픽에는 참조 자료 없이 실행 가능한 평가 기준을 적용.
❓ 열린 질문
- 현재 에이전트의 업무 성과를 가장 잘 보여주는 핵심 행동 2~3개는 무엇인가?
- 과업 완료율이 높더라도 별도로 실패를 판정해야 할 개인정보(PII) 유출이나 정책 준수 기준은 무엇인가?
- 선정한 평가 기준 중 정답이나 예상 경로가 필요해 배치 평가에서만 실행해야 하는 항목은 무엇인가?