이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
다중 턴 에이전트는 초기에 잘못된 도구 인자 하나가 이후 턴 전체로 퍼질 수 있어 최종 결과만 평가하면 최초 원인을 찾기 어렵습니다. AWS ML Blog의 Agent Evaluation Metric(AEM)은 correctness를 truthfulness와 completeness라는 두 하위 지표로 나누고, 자연어 응답과 도구 호출을 대화의 전체 맥락 안에서 턴별로 판정합니다. 의미적 유사도와 구조적 키 검사를 거친 뒤 실패 이유를 inconsistent_parameter_values, missing_parameters, incomplete_response처럼 구체화하고, prior_action_failed를 사용해 원인과 연쇄 효과를 분리합니다. 다섯 턴 영업 보고서 예시에서는 success_rate가 0.2이고 2번 턴의 inconsistent_parameter_values가 유일한 root cause이며 3건은 cascade로 귀속되므로, 해당 인자를 고치는 방식으로 조사 범위를 줄일 수 있습니다.
섹션별 상세
다중 턴 에이전트의 최종 결과만 채점하면 한 번의 잘못된 도구 호출이 뒤따르는 모든 실패와 섞입니다. 영업 보고서 예시에서 2번 턴이 기대값 revenue 대신 profit을 전달하자 3~5번 턴도 잘못된 중간 결과를 소비하며 실패합니다. AEM은 대화 전체를 실패로 표시하는 대신 실제 오류가 발생한 턴과 그 오류를 물려받은 턴을 구분해 수정 대상을 좁힙니다.
기존 goal-completion이나 LLM-as-judge 방식은 작업 성공 여부 또는 응답 전체의 품질을 하나의 신호로 합치는 경향이 있습니다. 이 방식만으로는 사실 오류, 필수 정보 누락, 잘못된 도구 선택 중 무엇이 점수를 떨어뜨렸는지 알기 어렵고 safety나 instruction retention 같은 새 차원을 같은 방식으로 추가하기도 어렵습니다. AEM은 품질을 이름이 있는 하위 지표로 분해하고 각 턴을 평가한 뒤 다시 하나의 지표로 합치는 구조를 사용합니다.
AEM의 첫 구현 대상은 correctness이며 truthfulness와 completeness를 독립적으로 계산합니다. Response turn에서는 completeness가 질문의 모든 부분을 다뤘는지 확인하고 truthfulness가 사실관계와 맞는지 비교하며, action turn에서는 필요한 parameter key가 모두 있는지와 각 parameter value가 의미상 올바른지를 검사합니다. 도구 호출에는 이 두 지표에 앞서 올바른 tool과 action을 선택했는지도 확인하므로 자연어 응답과 실행 단계가 같은 계층에서 평가됩니다.
문자열을 그대로 비교하면 같은 의미를 가진 표현을 잘못 실패 처리할 수 있으므로 AEM은 정확히 일치하는 경우를 빠른 경로로 통과시킨 뒤 semantic similarity를 계산합니다. embedding 기반 scorer나 LLM-as-judge를 사용할 수 있으며, 예시 임계값 0.5는 조정되지 않은 시작값으로서 false positive와 false negative에 대한 도메인 허용도에 맞춰 바꿔야 합니다. Completeness는 응답 턴에서 의미적 범위로, action turn에서 required key의 누락과 unexpected extra를 구조적으로 확인합니다.
python
def evaluate_truthfulness(gold_value, predicted_value, scorer, threshold=0.5):
"""Score semantic equivalence of a predicted value against gold."""
if gold_value == predicted_value:
return True, 1.0 # Exact match (fast path)
score = scorer.score(gold_value, predicted_value)
return score >= threshold, score기대값과 예측값을 먼저 정확히 비교하고, 다르면 의미적 유사도 점수와 임계값으로 truthfulness를 판정합니다.
python
def evaluate_completeness(gold_args, predicted_args):
"""Check all required parameters are present, with no unexpected extras."""
missing = set(gold_args.keys()) - set(predicted_args.keys())
extra = set(predicted_args.keys()) - set(gold_args.keys())
return len(missing) == 0 and len(extra) == 0, missing, extra기대되는 도구 인자의 키와 실제 인자의 키를 비교해 누락된 매개변수와 불필요한 매개변수를 함께 찾습니다.
python
def attribute_errors(turn_results):
"""Separate root cause failures from cascading failures."""
root_causes = []
cascading = []
for result in turn_results:
if not result.success:
if result.failure_reason == "prior_action_failed":
cascading.append(result)
else:
root_causes.append(result)
return {
"first_failure_turn": root_causes[0].turn_no if root_causes else None,
"root_cause": root_causes[0].failure_reason if root_causes else None,
"total_failures": len(root_causes) + len(cascading),
"root_cause_count": len(root_causes),
"cascading_count": len(cascading),
}
# Example output:
# first_failure_turn: 2, root_cause: "inconsistent_parameter_values"
# root_cause_count: 1, cascading_count: 3턴별 실패 결과를 순회해 독립적인 최초 실패와 이전 실패에서 파생된 연쇄 실패를 분리합니다.
각 턴은 이 글의 기본 설정에서 pass 또는 fail로 판정되고, 통과한 턴의 비율이 대화의 success_rate가 됩니다. 실패 taxonomy에는 inconsistent_response, incomplete_response, tool_mismatch, action_mismatch, missing_parameters, extra_parameters, inconsistent_parameter_values가 있으며, 이전 턴의 출력 때문에 실패한 경우에는 prior_action_failed를 붙입니다. 다섯 턴 예시의 결과는 success_rate 0.2, first_failure_turn 2, root_cause_count 1, cascading_count 3으로 집계되어 네 번의 실패를 하나의 수정 과제와 세 개의 파생 결과로 재구성합니다.
평가 파이프라인은 사람이 주석 처리한 gold dialog와 agent의 predicted turn을 입력으로 받아 턴별 검사, 오류 귀속, 대화 및 데이터셋 집계를 거칩니다. order-invariant 태그가 있으면 여러 도구 호출이 허용된 순서로 실행된 경우를 실패로 처리하지 않으며, 결과는 release regression, chain length별 품질, failure reason 분포, latency와 correctness의 관계를 모니터링하는 JSON으로 활용됩니다. Strands Agents evaluation SDK에서는 이 로직을 custom evaluator로 감싸 기존 goal-completion 및 LLM-as-judge 평가와 함께 실행할 수 있고, 이후 safety와 다른 차원도 같은 분해·평가·귀속·결합 흐름에 추가할 수 있습니다.
용어 해설
- 턴 단위 평가(Turn-level Evaluation)
- — 다중 턴 대화 전체를 한 번에 채점하지 않고 각 사용자 응답이나 도구 호출을 개별 평가하는 방식입니다. 각 턴의 입력과 기대 결과를 실제 결과와 비교해 실패한 위치와 원인을 좁힐 수 있으며, 앞선 오류가 뒤의 결과에 미친 영향을 분리하는 데 중요합니다.
- 의미적 유사도(Semantic Similarity)
- — 두 문자열이 글자 그대로 같은지보다 전달하는 의미가 같은지를 비교하는 방법입니다. AEM은 “New York City”와 “NYC”처럼 표현이 다른 동등한 값은 통과시키고, 임계값을 기준으로 실제 의미 차이가 있는 값은 실패로 판정합니다.
- 오류 귀속(Error Attribution)
- — 대화에서 발생한 실패를 최초 원인과 앞선 실패를 물려받은 연쇄 오류로 나누는 절차입니다. AEM은 각 턴의 의존 관계를 확인해 root cause와 prior_action_failed를 구분하고, 수정 우선순위를 최초 원인에 집중시킵니다.
- 골드 데이터셋(Gold Dataset)
- — 각 대화 턴에서 올바른 자연어 응답과 도구 호출을 사람이 주석 처리한 기준 데이터입니다. 예측 결과를 이 기준과 비교해야 truthfulness와 completeness를 일관되게 판정할 수 있으며, 자동 평가 점수가 사람의 판단과 맞는지도 검증할 수 있습니다.
- LLM 평가자(LLM-as-Judge)
- — LLM을 평가자로 사용해 응답 품질이나 의미적 일치 여부를 판정하는 방식입니다. AEM에서는 embedding 기반 유사도보다 미묘한 차이를 포착할 수 있지만, 내부 판단 과정을 직접 확인하기 어려워 임계값과 사람 주석을 함께 검증해야 합니다.
기술
- Agent Evaluation Metric (AEM)
- Strands Agents
- Strands Agents evaluation SDK
- embedding-based similarity check
- LLM-as-judge
- Amazon Quick Suite
- Python
활용 사례
- 영업 보고서 생성과 필터링을 수행하는 enterprise assistant
- 다중 도구 호출을 포함한 multi-turn agent 평가
- 모델 release별 correctness regression detection
- 도구 호출의 root cause 및 cascading failure 추적
- Strands Agents 기반 평가 파이프라인과 monitoring dashboard 연동
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 09. 11.수집 2026. 09. 11.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
