Amazon Bedrock AgentCore Skill Evaluation이 유창한 에이전트가 숨기는 문제를 드러내다

Amazon은 9월 22일 Amazon Bedrock AgentCore skill evaluation을 도입하며, 다듬어진 최종 답변을 넘어 에이전트의 행동을 점검하는 세 가지 검사를 추가했다. 이번 출시는 지속적으로 존재해 온 테스트의 사각지대를 겨냥한다. 에이전트는 잘못된 스킬을 선택하거나, 필수 단계를 건너뛰거나, 비즈니스 절차를 즉흥적으로 우회한 뒤에도 그럴듯하게 정확한 답변을 내놓을 수 있다.

새 평가기는 팀이 흔히 하나의 점수로 합쳐 보던 두 가지 질문을 분리한다. 에이전트는 적절한 스킬을 선택했는가, 그리고 해당 스킬을 로드한 뒤 이를 따랐는가? Strands Evals는 테스트가 호출해야 할 명명된 스킬을 이미 알고 있는 팀을 위해 세 번째의 결정론적 검사도 추가한다.

이러한 구분은 응답 품질에만 초점을 맞춘 평가 시스템에 압박을 가한다. 유용성, 관련성, 정확성은 여전히 중요하지만, 모든 라우팅 또는 실행 실패를 드러낼 수는 없다. 이제 핵심 경쟁은 최종 답변 점수와 에이전트가 그 답에 도달한 과정을 보여 주는 궤적 수준의 근거 사이에서 벌어진다.

Amazon Bedrock AgentCore Skill Evaluation, 하나의 실패를 세 가지로 분리하다

AWS는 최종 응답을 성공의 충분한 증거로 간주하는 대신, 스킬 사용을 측정 가능한 순서로 전환하고 있다.

스킬은 에이전트에 특화된 절차를 가르치는 재사용 가능한 지침 패키지다. 일반적으로 목적, 활성화 가이드, 필수 단계를 담은 SKILL.md 파일을 포함한다. 하니스는 사용할 수 있는 스킬을 제시하고, 에이전트는 요청에 맞춰 어떤 스킬을 로드할지 결정한다.

이 구조를 통해 개발자는 점점 길어지는 시스템 프롬프트에서 세부 절차를 분리할 수 있다. 기업은 송장 대사, 계약서 비식별화, 인시던트 에스컬레이션, 풀 리퀘스트 검토를 위한 별도 스킬을 만들 수 있다. 에이전트는 모든 상호작용에 모든 절차를 담아 두는 대신, 필요할 때 관련 지침을 로드한다.

이식성도 매력의 일부다. 개방형 Agent Skills 형식은 호환되는 에이전트 환경이 특화 지침을 패키징하는 공통 방식을 제공한다. 따라서 스킬은 단일 모델 호출에 묶인 프롬프트 조각이 아니라 운영 아티팩트 역할을 할 수 있다.

그러나 모듈형 지침은 일련의 의사결정을 도입한다. 에이전트는 사용자의 의도를 인식하고, 적절한 스킬을 찾고, 이를 호출하고, 내용을 읽고, 규정된 단계를 완료해야 한다. 훌륭한 최종 문단이 이 과정이 제대로 작동했다는 증거는 아니다.

AWS와 Strands 팀은 9월 22일 skill evaluation release에 따르면 이제 이 과정을 세 가지 평가기로 나눈다.

Skill Selection Accuracy는 호출된 각 스킬이 작업에 적절했는지를 묻는다. 호출된 모든 스킬에 대해 이진 결과를 반환한다. 이를 통해 에이전트가 다른 워크플로를 위한 지침을 로드했을 때 라우팅 오류를 확인할 수 있다.

Skill Instruction Following은 에이전트가 호출한 스킬에 규정된 단계를 얼마나 충실히 수행했는지 살핀다. 다섯 가지 평가는 Fully Followed, Mostly Followed, Partially Followed, Minimally Followed, Not Followed다. 문서화된 수치 값은 1.0부터 0.0까지 0.25 단위로 이어진다.

Skill Invoked는 Strands Evals 내에서 더 좁은 범위의 결정론적 검증을 제공한다. 에이전트가 명명된 스킬을 성공적으로 로드했는지 확인한다. 다른 두 평가기와 달리, 적절성이나 준수 여부를 모델에게 판단하게 하지 않는다.

이 측정 기준은 서로 다른 질문에 답한다. 필수 급여 스킬이 전혀 로드되지 않으면 라우팅 실패가 발생할 수 있다. 관련 없는 출장 요청에 로드되면 선택 실패가 된다. 올바르게 로드됐지만 승인 단계를 누락했다면 지침 준수 실패다.

이 분리가 핵심 변화다. 팀은 더 이상 모든 부진한 결과를 모호한 에이전트 품질 문제로 해석할 필요가 없다. 각 패턴을 서로 다른 구성 요소와 더 집중적인 개선책에 연결할 수 있다.

호출 누락은 발견 규칙, 설명 또는 라우팅 로직에 주목하게 한다. 부적절한 호출은 중복되는 스킬 범위를 시사한다. 올바르게 선택된 스킬의 준수도가 낮다면 해당 단계, 구조, 사용 가능한 도구 또는 기반 모델에 주목해야 한다.

이번 출시는 기존 품질 평가를 대체하지 않는다. 동적으로 로드되는 절차에 행동이 의존하는 에이전트를 위해 설계된 또 하나의 계층을 추가한다. 출력 정확성은 여전히 필수적이지만, 더 큰 테스트 기록의 한 부분이 된다.

유창한 답변만으로는 더 이상 충분한 증거가 아니다

궤적 평가를 지지하는 가장 강력한 논거는 간단하다. 서로 다른 내부 실패가 똑같이 설득력 있는 문장을 만들어 낼 수 있다.

한 직원이 외부 공유 전에 계약서를 비식별화해 달라고 에이전트에 요청하는 상황을 생각해 보자. 에이전트는 눈에 띄는 이름을 제거하고 깔끔해 보이는 문서를 반환할 수 있다. 하지만 승인된 스킬은 메타데이터, 숨겨진 댓글, 추적된 변경 사항, 첨부 파일 참조도 확인하도록 요구할 수 있다.

최종 문서만 보는 검토자는 이러한 누락된 검사를 알아차리지 못할 수 있다. 응답은 유능해 보이지만 조직의 실제 처리 절차를 위반할 수 있다. Skill Instruction Following은 기록된 행동을 각 규정 단계와 비교하도록 설계됐다.

같은 문제는 재무 운영에서도 나타난다. 송장 대사 에이전트는 비공식적인 추론을 거쳐 올바른 합계를 산출할 수 있다. 스킬이 공급업체 신원과 구매 승인 검증을 요구한다면, 결과는 여전히 절차상 불완전하다.

컴플라이언스는 이 구분을 특히 중요하게 만든다. 조직은 하나의 답변이 우연히 허용 가능했는지만 신경 쓰는 경우가 드물다. 반복 가능한 통제가 요구된 순서와 맥락에서 적용됐다는 증거도 필요하다.

전통적인 소프트웨어 테스트는 결정론적 함수에 대해 정확한 기대값을 제공한다. 에이전트는 동일한 프롬프트가 다양한 언어, 도구 호출, 추론 경로로 이어질 수 있기 때문에 다르게 행동한다. AWS는 앞서 한 번의 통과 실행은 통상적으로 일어나는 일이 아니라 일어날 수 있는 일을 보여 준다고 주장한 바 있다.

이러한 변동성은 집계된 응답 점수를 매력적으로 만든다. 팀은 데이터세트 전반의 정확성이나 유용성 평균을 내고 그 수치가 상승하는지 추적할 수 있다. 하지만 평균은 워크플로가 어디에서 실패했는지, 같은 단계가 계속 사라지는지를 감춘다.

스킬별 결과는 더 유용한 진단 단위를 제공한다. 에이전트가 한 세션에서 여러 스킬을 호출하면 평가기는 각 호출에 대한 결과를 반환한다. 따라서 약한 집계값을 이를 낮춘 특정 스킬까지 추적할 수 있다.

이 접근법은 팀이 스킬을 작성하는 방식도 바꾼다. 모호한 문단은 작성자에게는 이해하기 쉬울 수 있지만 일관되게 평가하기는 어렵다. 번호가 매겨진 관찰 가능한 단계는 판정기에 더 명확한 근거를 제공하고 누락을 더 쉽게 식별하게 한다.

그렇다고 모든 내부 사고가 공개되는 것은 아니다. 평가는 가시적인 메시지, 스킬 로드 작업, 도구 호출을 포함한 기록된 궤적과 추적 정보에 의존한다. 비공개 모델 추론은 필요하지도 않고 노출되지도 않는다.

관련 증거는 운영상 증거다. 에이전트는 스킬을 로드했는가? 어떤 스킬을 선택했는가? 기록된 작업은 규정된 검사를 완료했음을 보여 주는가? 이런 증거는 숨겨진 추론에 관한 추측보다 더 실행 가능하다.

이러한 변화는 완성된 계산을 확인하는 일과 그 주변의 통제를 감사하는 일의 차이와 닮아 있다. 두 관점 모두 중요하지만 서로 다른 질문에 답한다. 하나는 산출물을 측정하고, 다른 하나는 이를 만들어 낸 과정을 측정한다.

내부 에이전트를 구축하는 팀에게 과정은 종종 더 큰 조직적 위험을 수반한다. 유창한 답변은 한 번의 사용자 요청을 충족할 수 있다. 누락된 승인, 공개 또는 검증 단계는 동일한 조건이 반복될 때마다 워크플로를 훼손할 수 있다.

새 평가기는 이러한 절차적 격차에 이름을 붙이기 쉽게 만든다. 또한 다른 에이전트 플랫폼이 호환 가능한 궤적을 노출하도록 압박한다. 관찰 가능한 스킬 이벤트가 없다면, 팀은 호출 누락과 추출 실패를 자신 있게 구분할 수 없다.

Strands Evals, 개발 과정에 검사를 도입하다

Strands Evals는 프로덕션 트래픽이 테스트 모음이 되기 전에 개발자가 스킬 라우팅과 실행을 시험할 수 있는 로컬 테스트 계층을 제공한다.

Strands Evals는 에이전트와 언어 모델 애플리케이션을 평가하기 위한 오픈 소스 프레임워크다. 공개된 기능에는 출력 점수화, 궤적 분석, 도구 평가, 시뮬레이션, 실험, 추적 기반 평가가 포함된다.

프로젝트의 evaluation repository는 이제 세 가지 스킬 검사 모두를 문서화한다. 개발자는 기록된 세션 또는 원시 메시지 궤적을 대상으로 Skill Selection Accuracy와 Skill Instruction Following을 실행할 수 있다.

판정 모델 기반 평가기는 에이전트를 다시 실행하는 대신 궤적을 읽는다. 이는 실패 후 조사와 저장된 세션 간 비교를 지원한다. 또한 비용이 많이 드는 에이전트 실행과 동일 기록에 대한 반복 분석을 분리한다.

Skill Invoked는 다른 테스트 요구를 충족한다. 회귀 사례에 알려진 하나의 라우팅 요구 사항이 있다면, 개발자는 예상한 스킬이 로드됐다고 단언할 수 있다. 이 검사는 결정론적이며 판정 모델이 필요하지 않다.

따라서 릴리스 게이트에 적합하다. 계정 해지와 관련된 고객 지원 요청은 승인된 해지 스킬을 일관되게 로드해야 한다. 수정된 설명이 호출을 막는다면, 회귀 테스트는 배포 전에 실패할 수 있다.

둘 이상의 스킬이 합리적으로 적용될 수 있을 때도 선택 정확성은 유용하다. 하나의 고정된 이름하고만 비교하는 대신 호출된 스킬이 작업에 맞는지 묻는다. 이 유연성은 관련 절차가 있는 카탈로그와 정당한 라우팅 변동을 수용한다.

그다음 Instruction Following이 다음 단계를 시험한다. 평가기는 로드된 스킬에서 규정된 단계를 식별하고, 각 단계를 충족됨, 부분 충족됨 또는 누락됨으로 표시한다. 이 판단을 사용해 다섯 단계의 전체 평가를 산출한다.

이 조합은 간결한 테스트 매트릭스를 만든다.

선택 점수는 높지만 지침 준수도가 낮다면 라우팅은 작동했지만 실행은 작동하지 않았다는 뜻이다. 에이전트는 올바른 절차를 찾았지만 요구 사항을 건너뛰었거나 일부만 완료했다.

선택이 약하고 지침 준수도가 높다면 에이전트는 로드한 절차를 따랐지만, 그 절차가 요청에 맞지 않았다는 뜻이다. 스킬 내부 문구를 개선해도 이 라우팅 오류는 해결되지 않는다.

호출 누락에는 특별한 처리가 필요하다. AWS는 스킬이 호출되지 않았을 경우 두 판정 모델 기반 평가기가 점수를 반환하지 않는다고 언급한다. 명명된 스킬이 필수인 경우 팀은 이를 Skill Invoked와 함께 사용해야 한다.

이 동작은 오해의 소지가 있는 성공을 방지한다. 평가기는 한 번도 로드되지 않은 지침의 준수 여부를 판단할 수 없다. 하지만 테스트 모음이 비호출을 명시적으로 실패로 처리하지 않으면 빈 결과가 대시보드 안에서 사라질 수 있다.

Strands는 하니스에 계측 부담도 부과한다. 해당 추출기는 궤적에서 사용 가능한 스킬과 선택된 스킬을 인식해야 한다. 이 프로젝트는 여러 알려진 환경과 SKILL.md 파일을 읽는 일반적 패턴을 지원한다.

점수를 신뢰하기 전에 추출을 검증해야 한다. 인식되지 않는 스킬 신호를 가진 하니스는 에이전트가 스킬을 사용했더라도 빈 결과를 만들 수 있다. 이는 올바른 행동의 증거가 아니라 관찰 가능성의 격차다.

이 주의 사항은 맞춤형 오케스트레이션 계층을 통합하는 팀에 중요하다. 평가 품질은 이벤트의 충실한 기록에 달려 있다. 팀이 먼저 텔레메트리 계약을 검증하지 않으면, 누락된 추적 속성이 누락된 에이전트 작업처럼 보일 수 있다.

따라서 개발 워크플로는 두 단계로 구성됩니다. 먼저 평가기가 카탈로그, 호출, 스킬 콘텐츠 및 이후의 작업을 확인할 수 있는지 검증합니다. 다음으로 그 작업들이 과업에 부합하고 지침을 충족하는지 측정합니다.

로컬 기술 워크플로를 유지하는 엔지니어링 팀에게 이번 변화는 검색 가능한 엔지니어링 지식 베이스의 가치를 다시금 강조합니다. 스킬은 절차를 인코딩할 수 있고, 지속적으로 관리되는 소스 자료는 그 절차가 활용하는 사실을 제공합니다.

AgentCore, 스킬 평가를 프로덕션 트레이스로 확장

AgentCore는 큐레이션된 테스트에서 다루던 라우팅 및 준수 문제를 스테이징 세션과 샘플링된 실시간 트래픽으로 확장합니다.

Amazon Bedrock AgentCore Evaluations는 개발과 프로덕션 전반에서 에이전트 행동을 평가하는 관리형 서비스입니다. 이 서비스는 모델 호출, 도구 사용, 에이전트 작업과 같은 구조화된 이벤트를 기록하는 OpenTelemetry 트레이스를 활용합니다.

OpenTelemetry가 중요한 이유는 단일 에이전트 프레임워크에 대한 의존도를 낮추기 때문입니다. AgentCore 문서에 따르면 이 서비스는 OpenTelemetry 및 OpenInference 계측을 통해 Strands와 LangGraph를 포함한 통합을 지원합니다.

이 아키텍처는 이번 출시가 Strands 전용 기능보다 더 넓은 역할을 한다는 점을 보여줍니다. Strands Evals는 테스트 케이스와 기록된 개발 궤적을 처리합니다. AgentCore는 Strands 프레임워크 밖에서 생성된 세션을 포함해 배포된 에이전트의 호환 가능한 트레이스를 평가할 수 있습니다.

AWS는 세 가지 평가 모드를 제공합니다. 온디맨드 평가는 선택한 세션을 조사하거나 최근 변경 사항을 검증합니다. 배치 평가는 여러 저장된 세션을 처리해 기준선을 설정하거나 카탈로그 개정을 비교합니다.

온라인 평가는 프로덕션 트래픽을 지속적으로 샘플링합니다. 팀은 평가기, 데이터 소스, 필터, 샘플링 비율을 선택합니다. 이후 AgentCore는 일치하는 트레이스가 도착할 때 해당 평가를 적용합니다.

evaluation modes는 서로 다른 운영상의 질문을 지원합니다. 개발자는 실패한 세션 하나를 조사하고, 저장된 모집단에 점수를 매기거나, 실제 사용자 사이에서만 나타나는 행동을 모니터링할 수 있습니다.

이러한 진행 방식은 에이전트 테스트의 일반적인 공백을 해소합니다. 큐레이션된 프롬프트는 설계자가 사용자가 무엇을 물을 것으로 예상하는지 반영합니다. 프로덕션 요청에는 약어, 누락된 맥락, 이례적인 표현, 그리고 테스트 작성자가 예상하지 못한 조합이 포함됩니다.

스킬 카탈로그도 시간이 지나며 변합니다. 새 스킬은 기존 설명과 겹칠 수 있으며, 두 스킬의 내부 단계가 바뀌지 않았더라도 라우팅을 변화시킬 수 있습니다. AWS는 이를 카탈로그 드리프트라고 설명합니다.

온라인 평가는 선택 점수 하락을 통해 이러한 드리프트를 드러낼 수 있습니다. 그러면 팀은 어떤 스킬이 부적합한 요청을 끌어들이기 시작했는지 조사할 수 있습니다. 해결책은 한 설명의 범위를 좁히거나 인접한 스킬 간 경계를 명확히 하는 것일 수 있습니다.

긴 세션은 또 다른 우려를 만듭니다. 에이전트는 대화 초반에는 스킬을 안정적으로 따르다가도 컨텍스트가 쌓이면서 단계를 놓칠 수 있습니다. 프로덕션 트레이스는 고립된 테스트 프롬프트보다 이런 조건을 더 자연스럽게 노출합니다.

관리형 서비스는 대상 샘플링도 지원합니다. AWS 문서에 따르면 팀은 일정 비율의 세션을 평가하거나 조건부 필터를 적용할 수 있습니다. 이를 통해 운영자는 모든 상호작용을 처리하지 않고도 민감한 워크플로에 집중할 수 있습니다.

하지만 샘플링은 대시보드의 의미를 바꿉니다. 저용량 또는 좁게 필터링된 평가는 드문 실패를 놓칠 수 있습니다. 팀은 어떤 트래픽이 평가 대상이 되었는지 기록하고, 샘플링된 점수를 전체 커버리지인 것처럼 제시하지 않아야 합니다.

프로덕션 경로는 올바른 텔레메트리에도 의존합니다. AgentCore는 상호작용을 세션, 트레이스, 스팬으로 구성합니다. 세션은 대화를 포함하고, 트레이스는 하나의 교환을 포괄하며, 스팬은 개별 작업을 나타냅니다.

스킬 평가에는 이용 가능한 항목, 로드된 항목, 그리고 이후에 일어난 일을 재구성할 수 있을 만큼의 정보가 필요합니다. 계측이 스킬 콘텐츠 또는 호출 신호를 누락하면 평가기는 방어 가능한 결과에 필요한 증거를 확보할 수 없습니다.

AWS의 AgentCore guidance는 모델 기반 평가기로 점수를 매기는 통합 트레이스 형식을 설명합니다. 이러한 표준화는 운영을 단순화하지만, 애플리케이션이 기록하지 않은 이벤트를 복구할 수는 없습니다.

보안 팀은 트레이스 콘텐츠도 검토해야 합니다. 스킬 텍스트에는 내부 절차가 포함될 수 있고, 대화 기록에는 민감한 사용자 데이터가 포함될 수 있습니다. 평가는 텔레메트리의 가치를 확장하는 동시에 접근 제어와 보존 정책의 중요성을 높입니다.

그 결과는 단일 테스트가 아닌 라이프사이클 모델입니다. 개발자는 로컬에서 결정론적 게이트를 설정하고, 출시 전 저장된 세션을 비교하며, 배포 후 샘플링된 행동을 관찰할 수 있습니다. 각 계층은 서로 다른 유형의 실패를 포착합니다.

새로운 점수도 자체 평가가 필요하다

모델 기반 평가기는 진단 세부 정보를 더하지만, 절차 준수를 객관적 사실로 바꾸지는 않습니다.

Skill Selection Accuracy와 Skill Instruction Following은 평가 모델에 의존합니다. 평가기는 과업, 이용 가능한 증거, 스킬 지침을 읽은 뒤 등급을 산출합니다. 그 출력은 여전히 기록된 궤적에 대한 해석입니다.

이 해석은 모호한 단계에 따라 달라질 수 있습니다. 예를 들어 스킬이 “진행하기 전에 고객 상태를 확인하라”고 지시하면서 허용 가능한 확인 증거를 정의하지 않을 수 있습니다. 한 평가기는 데이터베이스 조회만으로 충분하다고 볼 수 있지만, 다른 평가기는 명시적 확인을 기대할 수 있습니다.

5단계 준수 척도는 뉘앙스를 제공하지만 거짓 정밀도를 만들 수도 있습니다. 0.75라는 평점은 Mostly Followed와 Partially Followed의 근본적인 구분이 판단에 좌우될 때에도 정확해 보입니다.

따라서 팀은 사람의 검토를 거친 사례를 기준으로 평가기를 보정해야 합니다. 목표는 모든 경계 사례에서 완벽히 일치하는 것이 아닙니다. 조직의 실제 절차 우선순위를 반영하는 안정적인 루브릭을 만드는 것입니다.

스킬은 중요한 단계를 관찰 가능하게 만들어야 합니다. “관련 정책을 고려하라”는 검증하기 어렵습니다. “현재 정책을 조회하고, 요청을 세 가지 적격성 조건과 비교하며, 결과를 기록하라”는 더 명확한 증거를 만듭니다.

부정 사례는 긍정 사례만큼 중요합니다. 선택 벤치마크에는 스킬의 영역과 유사하지만 호출되어서는 안 되는 요청도 포함되어야 합니다. 그렇지 않으면 광범위한 설명은 인접한 모든 과업에서 활성화되어 높은 점수를 받을 수 있습니다.

카탈로그 수준 테스트도 필수입니다. 스킬 하나를 고립해 평가하는 것은 유사한 선택지 열 개가 함께 있을 때의 라우팅에 대해 거의 알려주지 못합니다. 관련 테스트 환경은 에이전트가 실제로 보게 될 카탈로그와 유사해야 합니다.

결정론적인 Skill Invoked 검증에도 한계가 있습니다. 이는 명명된 스킬이 로드되었음을 증명할 뿐, 그 로딩이 적절했거나 유용했음을 증명하지는 않습니다. 팀은 완벽한 호출을 달성하면서도 잘못된 요청에 스킬을 선택할 수 있습니다.

마찬가지로, 강한 지침 준수가 정답을 보장하지는 않습니다. 결함 있는 스킬은 잘못된 단계를 규정할 수 있습니다. 에이전트는 그 단계를 충실히 수행하면서도 안전하지 않거나 부정확한 결과를 낼 수 있습니다.

그래서 응답 수준 평가는 스킬 평가와 함께 유지되어야 합니다. 팀은 여전히 정확성, 충실성, 유해성, 도구 파라미터 검사 및 도메인별 검증이 필요합니다. 절차 준수는 신뢰성의 한 차원입니다.

공식 prompt templates는 점수 산정 로직을 검토 가능하게 만듭니다. 이 템플릿은 준수 평가기가 단계를 식별하고, 이를 뒷받침하는 증거에 레이블을 붙이며, 결과를 다섯 가지 등급에 매핑하는 방식을 보여줍니다.

투명성은 팀이 평가기를 이해하는 데 도움이 되지만, 검증을 대체하지는 않습니다. 조직은 민감한 출시 결정에 점수를 사용하기 전에 평가기 결과를 전문가 검토와 비교해야 합니다.

비용과 지연 시간도 프로덕션 사용 방식을 좌우합니다. 평가기 기반 평가는 원래 에이전트 실행 이후 추가 모델 처리를 요구합니다. 샘플링과 필터는 그 부하를 제어할 수 있지만, 커버리지는 줄어듭니다.

팀은 모든 평가기를 하나의 헤드라인 점수로 합쳐서는 안 됩니다. 단일 종합 수치는 이번 출시가 해소하려는 모호성을 다시 만들어냅니다. 선택, 호출, 준수, 출력 품질은 각각 별도의 신호로 계속 보여야 합니다.

이번 출시는 거버넌스 문제도 범위 밖에 둡니다. 누가 스킬을 작성할 수 있는지, 누가 개정을 승인하는지, 어떤 절차를 필수로 정의할지 결정하지는 않습니다. 평가는 조직이 권위 있는 기준선을 수립한 뒤에야 일탈을 드러낼 수 있습니다.

성숙한 워크플로는 테스트 및 루브릭 변경과 함께 스킬의 버전을 관리합니다. 그렇지 않으면 팀은 점수가 에이전트 변화, 지침 변화, 평가기 변화 중 무엇 때문에 움직였는지 알 수 없습니다.

Amazon은 이 검증을 독립적인 준수 증명이 아니라 진단 도구로 제시합니다. 이는 적절한 경계입니다. 이 도구들은 에이전트 행동을 더 검토 가능하게 만들지만, 책임은 여전히 워크플로를 정의하고 검증하는 사람들에게 있습니다.

스킬 평가의 효과를 보여줄 세 가지 신호

다음 시험대는 팀이 스킬별 증거를 더 안전한 출시, 더 빠른 진단, 더 나은 스킬 카탈로그로 전환할 수 있는지 여부입니다.

첫 번째 신호는 개발 단계에서 결정론적 라우팅 게이트를 채택하는 것입니다. 팀은 하나의 명명된 스킬이 필수인 워크플로를 식별하고 회귀 테스트 모음에 Skill Invoked 단언을 추가해야 합니다.

이러한 게이트가 배포 전에 카탈로그 변경을 포착한다면 스킬 인식 테스트의 근거는 더 강해집니다. 추출 문제로 빈 결과가 자주 발생한다면 계측은 계속해서 당면한 장애물로 남을 것입니다.

두 번째 신호는 프로덕션 선택 점수가 카탈로그 드리프트를 드러내는지 여부입니다. 작성자는 새 스킬이 안정적으로 트리거되기를 원하기 때문에 넓은 설명을 붙이는 경우가 많습니다. 그런 설명은 기존 절차에서 요청을 빼앗아 올 수 있습니다.

유용한 프로덕션 시스템은 카탈로그 업데이트 이후 어떤 호출이 부적절해졌는지 보여줘야 합니다. 그러면 팀은 이러한 하락을 특정 설명, 중복 또는 요청 패턴과 연결할 수 있어야 합니다.

반복 가능한 진단의 증거는 AWS의 핵심 주장을 강화할 것입니다. 영향을 받은 스킬을 식별하지 못한 채 낮아진 총점만 보여주는 대시보드는 그 주장을 약화시킬 것입니다.

세 번째 신호는 Skill Instruction Following과 전문가 검토 간의 일치입니다. 조직은 평가기의 단계별 레이블을 절차를 이해하는 사람들의 판단과 비교해야 합니다.

일관된 일치는 출시 게이트와 온라인 모니터링에서의 더 폭넓은 사용을 정당화할 것입니다. 빈번한 불일치는 스킬 단계, 트레이스 증거 또는 평가기 루브릭에 추가 작업이 필요함을 시사합니다.

팀은 작은 카탈로그와 의도적으로 다양한 테스트 세트로 시작해야 합니다. 명확한 일치 사례, 근접 오답 사례, 스킬이 필요 없는 요청, 다중 스킬 워크플로를 포함하세요. 에이전트 행동은 여전히 비결정적이므로 각 시나리오는 한 번 이상 실행하세요.

네 가지 결과를 별도로 기록하세요. 예상한 스킬이 로드되었는지, 모든 호출이 적절했는지, 필수 단계가 준수되었는지, 최종 결과가 올바른지입니다. 이 구조는 새로운 평가기들의 진단적 가치를 보존합니다.

그런 다음 불일치를 평균으로 상쇄하지 말고 조사하세요. 단계를 건너뛴 올바른 답변은 잠재적인 운영 위험을 드러낼 수 있습니다. 충실한 실행 뒤의 부실한 답변은 약한 모델이 아니라 결함 있는 스킬을 나타낼 수 있습니다.

프로덕션 모니터링은 민감하거나 대량의 워크플로부터 시작해야 합니다. 필터와 샘플링을 의도적으로 사용하고, 점수 모집단에서 제외되는 항목을 문서화하세요. 심각한 실패와 이의가 제기된 평가에 대해서는 전문가 검토를 계속 활용하세요.

Amazon Bedrock AgentCore 스킬 평가가 중요한 이유는 무엇이 증거로 간주되는지를 바꾸기 때문입니다. 유창한 출력은 여전히 가치 있지만, 에이전트가 조직의 절차를 따랐는지 여부를 더 이상 그것만으로 판단할 수는 없습니다.

이제 실질적인 질문은 여러분에게 달려 있습니다. 여러분의 팀은 에이전트가 어떤 스킬을 선택했는지, 왜 그 선택이 적절했는지, 그리고 추적 기록이 어떤 필수 단계를 완료했음을 입증하는지 설명할 수 있나요? 그렇지 않다면 더 많은 스킬을 추가하기 전에 다음 테스트 주기에 그 근거를 반영하세요.