Evaluate any agent framework with Amazon Bedrock AgentCore Evaluations

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock AgentCore Evaluations는 표준 OpenTelemetry 계측으로 수집한 세션과 메시지를 재구성해 에이전트 프레임워크에 독립적인 평가를 제공한다.

📌 핵심 요약

• AgentCore Evaluations는 OpenTelemetry GenAI와 OpenInference 규약을 해석하며, Strands Agents, LangGraph, OpenAI Agents SDK, LlamaIndex, Google ADK, Claude Agent SDK를 지원 대상으로 설명한다.
• 평가에 필요한 핵심 스팬은 사용자 요청과 최종 응답을 담는 invoke agent, 모델 호출 내역을 담는 inference, 도구 이름·입력·결과를 담는 execute tool의 3가지이며, 그 밖의 스팬은 평가 필수 정보로 사용하지 않는다.
• 서비스는 Amazon CloudWatch에서 스팬과 이벤트 레코드를 가져오고 session.id로 세션을 구성하며, 재구성한 데이터에 GoalSuccessRate, Correctness, Helpfulness 및 사용자 정의 LLM 심사 평가를 동일하게 적용한다.
• 계측 방식은 scope.name으로 자동 판별하며, 명시된 프레임워크 외에도 규약을 따르는 opentelemetry.instrumentation.* 또는 openinference.instrumentation.* 접두사의 계측 라이브러리를 일반 처리 경로로 읽는다.
• 평가에는 runtimeSessionId와 일치하는 session.id 및 메시지 본문이 필요하다. 통합 관측 구성에서는 단일 에이전트 로그 그룹으로 충분하지만, 기존 분리 구성에서 aws/spans만 포함하면 메시지 본문이 비어 응답 품질 평가가 오류를 반환한다.

🧩 주요 포인트

1. OpenTelemetry GenAI와 OpenInference를 공통 평가 입력으로 변환 → 프레임워크 선택과 평가 기준을 분리.
2. 가지 핵심 스팬만 선별해 해석 → 검색·메모리 등 부가 스팬이나 낯선 스팬 유형이 포함돼도 평가 처리 유지.
3. scope.name 규칙, session.id 연결, 메시지 본문 확보가 함께 필요 → 스팬 수집·분류 성공만으로 평가 가능성을 보장하지 않음.

🧠 상세 정리

1. 프레임워크 다양화와 평가 도구의 호환성 문제

원문은 에이전트 프레임워크의 선택지가 늘어나는 반면, 평가 도구는 특정 SDK와 모델 클라이언트, 추적 방식에 의존해 호환 범위 밖에서 평가 파이프라인이 깨지는 문제로 시작한다. 팀은 워크플로 오케스트레이션에 LangGraph, 검색 파이프라인 통합에 LlamaIndex, GPT 표준화 환경에 OpenAI Agents SDK를 선택하며, 다중 에이전트 조정에는 Google ADK, Anthropic 고유 기능에는 Claude Agent SDK를 활용한다. Strands Agents는 모델 중심 실행 루프로 AgentCore에서 빠르게 에이전트를 구동하는 선택지로 소개되며, AgentCore 런타임은 호스팅·확장·메모리·관측 인프라를 담당한다. AgentCore Evaluations가 제시하는 해법은 개별 프레임워크에 평가를 결합하는 대신, 공통 계측 규약으로 수집한 실행 정보를 읽어 프레임워크 선택과 평가를 분리하는 것이다.

2. OpenTelemetry를 통한 공통 실행 정보 수집

OpenTelemetry는 분산 시스템이 추적·메트릭·로그를 내보내는 방식을 표준화하는 공급업체 중립 계측 프레임워크이며, 추적은 개별 작업을 나타내는 스팬의 트리로 구성된다. 각 스팬에는 작업 이름과 타임스탬프, 형식이 지정된 속성, 선택적인 스팬 이벤트가 들어가고, 스팬은 OpenTelemetry Protocol인 OTLP를 통해 수집 백엔드로 전달된다. AgentCore 런타임에서는 AWS Distro for OpenTelemetry인 ADOT가 스팬과 이벤트 레코드를 Amazon CloudWatch로 보낸다. 에이전트의 한 차례 실행에도 모델 호출, 도구 실행, 문서 검색, 재순위화, 임베딩 생성, 가드레일 검사, 프롬프트 렌더링, 메모리 읽기·쓰기 등이 섞이므로, 평가 서비스는 다양한 작업이 공존하는 추적에서 필요한 정보를 구별해야 한다.

3. 평가가 읽는 3가지 핵심 스팬

AgentCore Evaluations가 세션의 동작을 재구성하는 데 사용하는 역할은 invoke agent, inference, execute tool의 3가지로 구분된다. invoke agent 스팬은 대화에서 한 번의 사용자 요청과 에이전트의 최종 응답을 담고, inference 스팬은 개별 모델 호출에 전달한 메시지 이력과 모델의 답변을 담는다. execute tool 스팬에는 에이전트가 호출한 도구의 이름과 입력 매개변수, 실행 결과가 기록되므로, 모델 호출과 실제 도구 실행을 평가할 정보를 제공한다. 서비스는 수신한 스팬을 분류한 뒤 이 역할들에서 필요한 값을 추출하며, 검색·재순위화·가드레일·메모리 스팬은 평가에 필수적이지 않은 추가 맥락으로 취급한다. 앞으로 규약이나 프레임워크에 새로운 스팬 유형이 추가되더라도, 모르는 유형을 오류로 처리하지 않고 건너뛰는 방식으로 호환성을 유지한다.

4. 세션 재구성과 공통 평가 기준 적용

온디맨드 평가나 온라인 평가 구성을 실행하면 서비스는 CloudWatch에서 에이전트의 스팬과 이벤트 레코드를 가져와 세션을 재구성한다. 세션의 묶음 기준은 session.id이며, 그 안에서 하나의 trace_id로 구분되는 추적은 사용자의 한 차례 대화 턴을 나타낸다. 서비스는 각 스팬의 역할을 분류하고 사용자 입력, 모델 메시지, 도구 실행 결과 등 필요한 값을 추출한 다음 재구성한 세션을 평가기에 전달한다. 이후에는 에이전트를 어떤 프레임워크로 구현했는지와 관계없이 GoalSuccessRate, Correctness, Helpfulness 및 사용자 정의 LLM 심사 평가가 같은 방식으로 적용된다. 이 구조에서 프레임워크별 차이는 실행 정보를 읽고 변환하는 단계에서 처리되며, 평가기는 공통 형태로 재구성된 세션을 대상으로 동작한다.

5. scope.name 자동 판별과 지원 범위의 조건

평가 서비스는 계측 라이브러리가 스팬과 이벤트 레코드에 기록하는 scope.name을 이용해 데이터를 읽는 방식을 자동으로 결정하므로, 지원 계측 패키지에 맞춘 해석을 사용자가 별도로 설정할 필요가 없다. 원문이 명시한 지원 대상은 Strands Agents, LangGraph, OpenAI Agents SDK, LlamaIndex, Google ADK, Claude Agent SDK이며, 대부분은 OpenTelemetry와 OpenInference 계측을 모두 제공한다. 목록 밖의 라이브러리도 해당 규약을 준수하면서 scope.name이 opentelemetry.instrumentation.* 또는 openinference.instrumentation.*에 속하면 일반 처리 경로로 읽힌다. 반대로 mycompany.agent.tracing이라는 이름은 스팬 내용이 규약과 정확히 일치해도 인식되지 않으며, 원문은 이 접두사를 계측 작성자가 문서화된 스키마를 의도적으로 준수했다는 신호로 설명한다.

6. 세션 연결과 메시지 본문 확보의 필수 조건

종단 간 평가의 첫 번째 조건은 스팬의 session.id가 에이전트 호출에 사용한 runtimeSessionId와 일치하는 것이며, AgentCore 런타임에서는 ADOT가 이 속성을 자동으로 주입한다. 두 번째 조건은 평가 데이터 소스가 스팬뿐 아니라 메시지 본문도 포함하는 것으로, 새 에이전트의 기본값인 통합 관측 구성에서는 본문과 스팬이 동일한 에이전트별 로그 그룹에 있어 하나의 로그 그룹으로 충분하다. 기존의 통합 이전 구성에서는 스팬이 공유 aws/spans 로그 그룹에 저장되고 메시지 본문은 에이전트 로그 그룹의 연결된 이벤트 레코드에 별도로 저장된다. 이 분리 구성에서 데이터 소스가 aws/spans만 포함하면 스팬 분류 자체는 성공하지만 메시지 본문은 빈 값으로 돌아오며, 응답 품질을 채점하는 평가기는 오류를 반환한다.

7. OpenTelemetry GenAI 속성의 평가상 역할

OpenTelemetry GenAI 규약에서는 gen_ai.operation.name의 invoke_agent, chat, execute_tool 값으로 각각 에이전트 요청·응답, 모델 추론, 도구 실행 스팬을 분류한다. 이 속성이 없는 일부 LlamaIndex 추적에서는 traceloop.span.kind를 대신 읽어 workflow, llm, tool을 대응시키며, 도구 이름은 gen_ai.tool.name에서 가져온다. gen_ai.tool.call.id는 모델이 요청한 도구 호출과 실행 결과를 연결하고, 추론 스팬의 gen_ai.tool.definitions는 도구 스키마의 JSON 배열을 담아 GoalSuccessRate가 호출된 도구가 사용 가능하다고 선언됐는지 확인하는 데 사용된다. 메시지 본문은 분리 수집 시 이벤트 레코드의 body.input.messages와 body.output.messages에, 비분리 수집 시 스팬의 gen_ai.input.messages와 gen_ai.output.messages 또는 인라인 스팬 이벤트에 위치하며, 서비스는 실제 저장 위치에서 내용을 읽는다.

8. OpenInference의 대체 스키마와 메시지 표현

OpenInference는 Arize AI가 관리하는 공개 명세로, LlamaIndex·Haystack·Phoenix 생태계에서 널리 채택되며 OpenTelemetry GenAI와 다른 속성 이름으로 모델 관련 작업을 표현한다. OpenAI Agents SDK의 openinference-instrumentation-openai-agents 계측과 Google ADK, Claude Agent SDK 등이 이 형식의 스팬을 생성하며, openinference.span.kind의 LLM, TOOL, AGENT, CHAIN은 각각 추론, 도구 실행, 에이전트 호출, 구조적 컨테이너에 대응한다. 추론 입력 메시지는 llm.input_messages.{i}.message.role과 llm.input_messages.{i}.message.content처럼 0부터 시작하는 인덱스를 붙인 평탄한 속성으로 기록하고, 도구 결과 메시지는 message.tool_call_id를 추가해 해당 호출과 연결한다. 출력 메시지도 같은 인덱스 방식을 사용하면서 도구 호출의 함수 이름과 인수를 더 깊은 속성 경로에 기록하며, 제공된 원문은 이 출력 속성 예시의 인수 문자열 중간에서 끝난다.

🧾 핵심 주장 / 시사점

• 프레임워크 독립성은 모든 추적 형식을 무조건 수용한다는 뜻이 아니라, 지원되는 계측 이름과 의미 규약을 공통 평가 데이터로 변환하는 데서 나온다.
• 스팬이 정상적으로 수집되고 분류되더라도 메시지 본문이 빠지면 응답 품질 평가가 실패하므로, 관측 데이터의 존재와 평가 입력의 완전성을 구분해야 한다.
• 평가에 필요한 역할을 3가지로 제한하고 나머지 스팬을 건너뛰는 설계는 풍부한 실행 추적과 새로운 스팬 유형을 수용하는 근거가 된다.

✅ 액션 아이템

• 사용 중인 계측 라이브러리의 scope.name이 지원 대상 또는 opentelemetry.instrumentation.·openinference.instrumentation. 접두사 조건을 충족하는지 확인.
• 에이전트 스팬의 session.id와 호출에 사용한 runtimeSessionId의 일치 여부 확인.
• 기존 분리 구성의 평가 데이터 소스가 aws/spans뿐 아니라 메시지 본문도 포함하는지 점검.

❓ 열린 질문

• 현재 계측 라이브러리의 scope.name은 지원 대상 또는 opentelemetry.instrumentation.·openinference.instrumentation. 접두사 조건을 충족하는가?
• 평가 대상 스팬의 session.id는 에이전트 호출에 사용한 runtimeSessionId와 일치하는가?
• 현재 평가 데이터 소스는 aws/spans의 스팬과 함께 응답 품질 평가에 필요한 메시지 본문을 제공하는가?