이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- agent 품질은 최종 답변 외에 무엇을 평가해야 하는가?
- agent trace를 replay 가능하게 남기는 이유는 무엇인가?
- agent 장애를 eval scenario로 만들려면 어떤 데이터가 필요한가?
개요
Agent는 여러 step과 tool call을 거치므로 최종 답변만 평가하면 부족하다. 어떤 tool을 골랐는지, 몇 번 호출했는지, 비용이 얼마나 들었는지, 실패를 어떻게 복구했는지를 함께 봐야 한다.
평가 항목
- 목표 달성 여부
- tool 선택 적절성
- 불필요한 tool call 수
- max step 초과 여부
- 비용
- latency
- 권한 거절 처리
- write tool approval 준수
- prompt injection 방어
Trace 구조
agent trace에는 다음이 필요하다.
- user request id
- agent version
- prompt version
- model profile
- step number
- selected tool
- tool args summary
- tool result status
- decision
- cost
- final output
원문은 제한 저장한다.
코드로 이해하기
{
"agent_run_id": "run-123",
"agent_version": "support-agent-v2",
"steps": [
{
"step": 1,
"action": "tool_call",
"tool": "search_policy",
"status": "ok",
"elapsed_ms": 320
},
{
"step": 2,
"action": "draft_answer",
"status": "ok"
}
],
"total_tool_calls": 1,
"final_status": "waiting_approval"
}이 정도 구조가 있어야 replay와 debugging이 가능하다.
Replay
replay는 같은 입력과 tool result를 사용해 agent 동작을 재현하는 것이다. 모델 출력은 완전히 같지 않을 수 있지만, 장애 분석에는 큰 도움이 된다.
replay에 필요한 것:
- prompt version
- model profile
- tool schema version
- tool result snapshot 또는 mock
- user permission snapshot
- agent config
장애 상황과 대응
agent 장애:
- loop
- wrong tool
- permission denied 반복
- write tool 중복
- final answer mismatch
대응:
- trace replay
- max step 조정
- tool description 개선
- workflow로 고정
- eval scenario 추가
인프라 협업 포인트
agent trace는 크다. 인프라팀과 sampling, 보존 기간, 민감정보 저장 방식, trace storage 비용을 합의한다.
실전 팁
- agent eval은 최종 답변뿐 아니라 path를 본다.
- tool result mock을 만들면 regression eval이 쉬워진다.
- 실패한 agent run은 scenario로 저장한다.
- write tool 결과는 audit log와 trace를 연결한다.
위험 신호!
- agent 실행 결과만 있고 중간 step이 없다.
- tool args 원문이 무제한 저장된다.
- agent failure를 재현할 수 없다.
- max step 초과가 metric으로 없다.
확인 질문
확인 질문
- agent eval에서 path를 봐야 하는 이유는 무엇인가?
- 중간 tool call이 비용, side effect, 보안 위험을 만들 수 있기 때문이다.
- replay에 필요한 핵심 정보는 무엇인가?
- prompt version, model profile, tool schema, tool result, permission snapshot, agent config다.