UAEF: A framework-agnostic system for closed-loop evaluation of AI agents

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

UAEF는 서로 다른 프레임워크의 AI 에이전트 실행을 AgentTrace로 표준화하고, 7개 차원의 36개 내장 지표와 버전 비교를 통해 반복 개선을 지원하는 프레임워크 독립형 평가 시스템이다.

📌 핵심 요약

• 통신·의료·금융 분야의 12개 조직 고객이 UAEF를 사용해 일관된 지표로 AI 에이전트를 평가하고 출시 전 버전을 비교했다.
• UAEF는 평가 대상 에이전트와 데이터셋을 입력받으며, 어댑터로 메시지·도구 호출·에이전트 간 인계를 공통 형식인 AgentTrace로 변환한다. 기존 실행 기록을 받거나 에이전트를 직접 호출해 기록을 수집할 수 있다.
• 36개 내장 지표는 도구 호출, 응답 품질, 책임 있는 AI, 성능, 다중 턴, 다중 에이전트, 추론의 7개 차원을 평가한다. 정답 데이터는 선택 사항이지만 참조 비교 지표에는 필요하며, 도구 호출 평가에는 예상 도구·순서·인자가 필요하다.
• 모든 지표 점수는 1이 최상인 [0, 1] 범위로 정규화된다. 결정론적 지표와 Amazon Bedrock 기반 LLM 심사 지표를 제공하며, LLM 심사 점수는 보안 통제를 결정하는 기준으로 사용해서는 안 된다.
• UAEF는 저장 전에 PII를 검사하고, Amazon DynamoDB에 실험 메타데이터를, Amazon S3에 전체 결과를 저장한다. 기본 5% 임계값으로 기준 실행 대비 지표 변화를 분류하고, 보고서와 인사이트를 통해 프롬프트·모델·도구의 반복 개선을 지원한다.

🧩 주요 포인트

1. 정규화와 채점을 분리하므로 LangGraph·LangChain·Strands Agents 및 Amazon Bedrock AgentCore 등 지원 환경이 달라도 같은 평가 척도로 에이전트를 비교할 수 있다.
2. 정답 데이터의 필요 여부와 7개 차원의 평가 목적이 다르므로, 평가하려는 행동에 맞춰 지표와 데이터셋을 구성해야 한다. 단일 정확도 점수만으로는 도구 사용·대화 유지·협업 등에서 발생한 차이를 설명하기 어렵다.
3. 저장된 지표별 평균과 기준 실행을 연결하면 변경에 따른 개선·퇴보를 추적할 수 있다. 다만 LLM 심사 결과는 평가 신호이며, 에이전트 실행 시점의 보호는 별도 호출 경로에 적용하는 Amazon Bedrock Guardrails로 다뤄야 한다.

🧠 상세 정리

1. 프레임워크별 평가 단절과 UAEF의 목적

AWS에서 AI 에이전트를 만드는 팀은 LangGraph, LangChain, Strands Agents, Amazon Bedrock AgentCore 등 다양한 프레임워크와 실행 환경을 사용하며, 각 환경은 메시지와 도구 호출, 에이전트 간 인계를 서로 다른 형식으로 기록한다. 평가 도구까지 특정 기록 형식에 결합되면 프레임워크를 바꾸거나 여러 환경을 함께 사용할 때 지표와 채점 로직, 결과 저장 구조를 다시 만들어야 한다. 이런 결합은 프롬프트·모델·도구의 변경이 실제로 에이전트를 개선했는지 일관되게 판단하기 어렵게 만든다. UAEF는 공통 평가 계층과 과거 결과 비교를 통해 이 문제를 해결하려는 시스템이며, 통신·의료·금융 분야의 12개 조직 고객이 출시 전 에이전트 평가와 버전 비교에 사용했다. 원문은 에이전트 품질이 단일 정확도 점수로 설명되지 않는다는 점을 출발점으로 삼고, 평가 결과를 다음 수정과 재평가로 연결하는 폐쇄 루프를 제시한다.

2. 입력 데이터와 AgentTrace 정규화

UAEF의 입력은 평가 대상 에이전트와 테스트 데이터셋이며, 데이터셋에는 각 사례의 입력과 선택적인 정답 데이터를 넣을 수 있다. 정답은 응답을 참조 답변과 비교하는 지표에서 사용하고, 도구 호출 평가에는 호출해야 할 도구와 순서, 전달 인자도 포함해야 한다. 어댑터는 에이전트의 메시지·도구 호출·에이전트 간 인계를 읽어 공통 표현인 AgentTrace로 변환하며, 이후의 지표와 보고서는 이 형식만 처리한다. 과거 실행이나 로그, 관측 저장소에 기록이 있으면 이를 정규화하고, 기록이 없으면 런타임 ARN 또는 HTTP 엔드포인트를 통해 데이터셋의 입력마다 에이전트를 호출해 응답 수집과 변환을 수행한다. 이 구조는 로컬 실행, 관리형 런타임, Langfuse 기록 유무 등 실행 조건이 달라도 동일한 채점 경로를 제공한다. 또한 데이터가 저장되기 전에 이메일 주소·전화번호·신용카드 번호 같은 개인 식별 정보인 PII를 검사한다.

3. 단일 정확도를 넘어서는 7개 평가 차원

평가 엔진은 에이전트 행동을 7개 차원으로 나누며, 도구 호출 차원에서는 올바른 도구 선택, 합리적인 호출 순서, 유효한 인자 전달을 살핀다. 응답 품질은 최종 답변의 관련성·완전성·정확성과 함께 제공된 맥락에 근거하는지, 환각이 발생하는지를 평가한다. 책임 있는 AI 차원은 안전성·편향·유해성·프롬프트 주입 저항성을 다루고, 성능 차원은 지연 시간·토큰 사용량·처리량이라는 운영 측면을 측정한다. 다중 턴 차원은 대화가 이어지는 동안 맥락 유지와 일관성, 목표 달성이 가능한지를 보고, 다중 에이전트 차원은 협력하는 에이전트 사이의 작업 위임과 업무 분담을 평가한다. 추론 차원은 에이전트 사고 과정의 내부 논리가 일관되는지, 논리적 오류가 없는지를 측정하는 것으로 설명된다. 각 차원은 하나 이상의 내장 지표로 계산되므로, 전체 점수만으로는 드러나지 않는 행동별 강점과 약점을 구분할 수 있다.

4. 채점 방식과 LLM 심사의 보안 경계

UAEF의 36개 내장 지표는 모두 1이 최상인 [0, 1] 범위의 정규화 점수를 반환하며, 결정론적 지표와 LLM 심사 지표로 구분된다. 결정론적 지표는 실행 기록과 정답 데이터에서 점수를 직접 계산해 반복 실행 시 같은 결과를 내고, LLM 심사는 관련성이나 안전성처럼 명확한 수식으로 정의하기 어려운 품질을 Amazon Bedrock 모델로 평가한다. 사용자 정의 지표를 추가하거나 RAGAS와 DeepEval 연동을 활용할 수도 있다. 에이전트 출력이 심사 프롬프트에 다시 들어가므로 이를 신뢰할 수 없는 입력으로 취급하고, 평가 기준을 별도로 전달하며 내용이 구분자를 벗어나 지시로 해석되지 않도록 이스케이프한다. 심사 응답은 엄격하게 파싱하고 평가한 내용의 원문 구절을 인용하도록 요구하며, 인용 근거를 찾을 수 없는 점수는 기록하지 않고 거부한다. 원문은 이런 조치에도 심사 점수를 보안 통제의 결정 기준으로 삼지 말아야 한다고 명시하며, 실행 중 보호는 에이전트 호출 경로에 Amazon Bedrock Guardrails를 적용하는 방식으로 구분한다.

5. 실험 저장과 변경 이력의 연결

evaluate() 또는 batch_evaluate()를 persist=True로 호출하면 UAEF는 선택적인 이름과 목적을 가진 새 실험을 만들고, 역할이 다른 두 저장소에 결과를 기록한다. Amazon DynamoDB에는 실험마다 한 행을 두어 평가 건수, 지표별 평균 점수, 전체 평균 등 목록 조회와 비교에 필요한 메타데이터를 저장한다. Amazon S3에는 지표별 점수와 심사 모델의 판단 근거를 포함한 전체 평가 결과를 JSON 파일로 저장하며, 민감한 데이터를 다루는 팀은 저장 사본에 PII 가림 처리를 켤 수 있다. Python 라이브러리는 실험 아래에 실행을 두는 더 세밀한 구조도 제공하고, 각 실행에는 평가한 프레임워크·모델·도구·시스템 프롬프트·매개변수를 기록한다. 구성 스냅샷과 Git 커밋도 남길 수 있으며, 실험 안의 한 실행을 기준 실행으로 지정할 수 있다. 이 연결을 통해 점수가 어떤 프롬프트 변경이나 모델 교체, 도구 추가에서 나온 결과인지 추적할 수 있다.

6. 기준 실행 비교와 퇴보 분류

비교 엔진은 저장된 지표별 평균을 사용하며, 두 실행에 공통으로 존재하는 각 지표에 대해 절대 변화량과 백분율 변화량을 계산한다. 이후 설정 가능한 임계값으로 퇴보·개선·변화 없음을 분류하고, 기본 임계값은 5%이며 여러 실행을 하나의 기준 실행과 한 번에 비교할 수 있다. 퇴보 감지기는 심각도를 경미한 퇴보 5~10%, 중간 수준 10~20%, 심각한 퇴보 20% 초과로 구분한다. 또한 퇴보를 평가 차원별로 묶어, 예를 들어 프롬프트 변경이 응답 품질에는 영향을 주지 않았지만 도구 호출에는 영향을 주었는지 살필 수 있게 한다. 웹 UI의 Compare 탭에서는 저장된 실험을 프레임워크나 데이터셋으로 필터링하고 둘 이상을 선택하며, 첫 번째 실험을 기준으로 지표별 개선과 퇴보를 강조한다. UI도 Python API와 같은 비교 엔진을 호출하므로 두 경로에서 비교 결과가 일치한다.

7. 결과 화면에서 개별 실패까지 확인

평가가 끝나면 웹 UI는 전체 점수, 평가한 테스트 사례 수, 사용한 프레임워크, 실행에 실패한 질의를 실험 요약으로 보여준다. 지표별 평균은 차원 레이더 차트와 지표 막대 차트로 제시되므로, 전체 성적과 차원별 분포를 함께 확인할 수 있다. 별도의 표에는 모든 테스트 사례의 질의, 에이전트 응답, 예상 답변, 점수를 나열해 평균 점수와 개별 결과를 연결한다. 사용자가 행을 펼치면 전체 응답과 해당 사례의 차원별·지표별 점수를 볼 수 있어, 어떤 응답에서 낮은 평가가 나왔는지 더 구체적으로 살필 수 있다. 다중 턴 대화에서는 각 턴의 점수와 에이전트가 호출한 도구까지 표시해, 대화 전체 결과뿐 아니라 턴별 행동도 확인한다. 이 결과 화면은 실행 성적을 확인하는 첫 단계이며, 저장된 결과를 이용한 상세 통계 보고서는 결과 화면이나 실험 목록에서 필요할 때 생성한다.

8. 통계 보고서와 인사이트로 닫는 개선 루프

상세 보고서는 Amazon S3에서 저장된 결과를 불러와 새 브라우저 탭에서 열리며, 차원별·지표별 분석과 각 지표의 신뢰구간·이상치·점수 분포를 제공한다. 지표 사이의 상관관계, 책임 있는 AI 요약, 실패가 보고된 테스트 사례도 보여주고, 가장 낮은 점수의 차원과 사례별 변동이 큰 지표를 중심으로 권고를 제시한다. 이 보고서는 LLM 없이 점수만으로 계산하므로 같은 결과에서는 같은 보고서가 생성된다. 별도로 Python 라이브러리에서는 보고서를 Amazon Bedrock 모델에 전달해 강점, 핵심 약점, 근본 원인에 관한 가설, 우선순위가 있는 권고를 분석할 수 있다. 여러 실행의 비교 분석에 관한 설명도 시작되지만, 제공된 본문은 해당 설명 중간에서 끝나므로 전체 분석 범위는 확인할 수 없다. 원문이 제시하는 폐쇄 루프는 이런 결과와 설명을 바탕으로 프롬프트·모델·도구를 수정하고 다시 평가해, 개선과 퇴보를 반복적으로 확인하는 과정이다.

🧾 핵심 주장 / 시사점

• 프레임워크 독립성의 핵심은 채점 전에 실행 기록을 AgentTrace로 통일하는 데 있다. 평가 로직을 공통 표현에 연결하면 지원 프레임워크 사이에서도 같은 척도를 유지할 수 있다.
• 전체 평균은 변경의 영향을 압축하지만, 지표별 비교와 차원별 퇴보 분류는 어느 행동이 개선되거나 나빠졌는지 구분한다. 따라서 버전 개선 여부를 판단할 때는 전체 점수와 세부 변화가 함께 필요하다.
• 결정론적 통계 보고서와 LLM 생성 인사이트는 근거의 성격이 다르다. 전자는 저장된 점수에서 재현 가능하게 계산되고, 후자는 원인에 관한 가설과 권고를 제공하므로 보안 통제의 판단과도 구분해야 한다.

✅ 액션 아이템

• UAEF의 7개 차원과 36개 내장 지표 중 평가 목적에 맞는 항목을 선정하고, 참조 비교 및 도구 호출 평가에 필요한 정답 데이터를 구성한다.
• Amazon DynamoDB와 Amazon S3에 저장한 결과를 기준 실행과 비교하고, 기본 5% 임계값에 따른 개선·퇴보를 프롬프트·모델·도구 수정에 반영한다.
• LLM 심사 점수는 평가 신호로 활용하고, 에이전트 실행 시점의 보호는 별도 호출 경로에 Amazon Bedrock Guardrails를 적용하는 방식으로 다룬다.

❓ 열린 질문

• 평가 대상 에이전트에서는 7개 차원 중 무엇이 중요하며, 해당 지표에 필요한 정답 데이터와 예상 도구 호출을 확보할 수 있는가?
• 기준 실행 대비 개선·퇴보를 분류하는 기본 5% 임계값이 평가 목적에 적합한가?
• LLM 심사 점수를 평가 신호로 활용하면서 Amazon Bedrock Guardrails를 에이전트의 어떤 호출 경로에 적용할 것인가?