실전 AI 에이전트: 트레이스(Trace)를 통한 실패 분석
AI 에이전트는 충돌(crash)하지 않습니다. 성공했다고 보고하죠. 하지만 당신의 은행 계좌에는 오류가 나타납니다.
취소된 적 없는 주문에 대해 환불이 진행되었습니다. 고객은 상품과 돈을 모두 가졌습니다. 에이전트는 자신의 일을 완수했다고 생각했습니다.
더 큰 모델을 찾지 마세요. 단순히 재시도 루프(retry loop)를 추가하지도 마세요. 둘 다 추측일 뿐입니다.
대신, 트레이스를 읽으세요. 에이전트는 이미 자신이 무엇을 했는지 기록해 두었습니다.
제대로 된 프로덕션 트레이스는 루프의 단계를 하나씩 기록해야 합니다. 다음 내용이 포함되어야 합니다:
- 에이전트가 관찰한 내용
- 에이전트의 결정
- 호출한 도구(tool)
- 도구의 반환 값
- 신뢰할 수 있는 원천(source of truth)으로부터 읽어온 검증 데이터
- 최종 상태 및 비용
가장 중요한 부분은 도구의 응답과 검증 데이터 사이의 간극입니다. 도구는 "수락됨(accepted)"이라고 말할 수 있지만, 그것이 실제 세상이 변했다는 것을 의미하지는 않습니다. 검증 데이터를 통해 변화가 실제로 일어났는지 확인할 수 있습니다.
실패는 보통 두 가지 그룹으로 나뉩니다:
- 실행 실패 (Execution Failures)
- 도구 실패: 잘못된 인자(argument) 또는 타임아웃.
- 추론 실패: 모델이 잘못된 행동을 선택함.
- 제어 상태(control-state) 실패: 에이전트가 거짓을 믿음. 데이터베이스의 상태와 상관없이 도구가 그렇다고 말했기 때문에 주문이 취소되었다고 믿는 경우.
- 구조적 루프 실패 (Structural Loop Failures)
- 컨텍스트 저하(Context degradation): 에이전트가 맥락을 놓침.
- 루프 폭주(Loop runaway): 에이전트가 진전 없이 단계를 반복함.
- 침묵 상태의 정체(Silent stalls): 에이전트가 오류 없이 멈춤. 침묵을 실패로 간주할 와치독(watchdog)이 필요합니다.
실패를 발견했을 때, 단순히 재시도하지 마세요. 재시도는 전략이지 진단이 아닙니다.
- 타임아웃과 같은 일시적인 오류라면 재시도하세요.
- 논리적 오류라면, 재시도는 똑같은 벽에 부딪히기 위해 예산만 낭비하는 꼴입니다.
- 에이전트가 차단 요소(blocker)에 부딪혔다면, 중단하고 사람에게 알리세요.
실패를 해결하는 가장 좋은 방법은 그것을 테스트로 만드는 것입니다.
트레이스를 사용하여 그레이더(grader)를 작성하세요. 에이전트가 취소 확인을 실패했다면, 취소 상태가 확인되지 않은 채 환불이 발생할 경우 실패하는 테스트를 작성하세요. 이미 비용을 지불한 실패를, 다시는 비용을 지불하지 않아도 되는 실패로 바꾸십시오.
Optional learning community: https://t.me/GyaanSetuAi