에스컬레이션 문제
도움을 절대 요청하지 않는 에이전트는 결국 무언가를 잘못하고 비용을 치르게 됩니다. 도움을 끊임없이 요청하는 에이전트는 그저 단계가 더 많은 챗봇입니다. 스위트 스폿은 일상적인 작업을 자율적으로 처리하고 진정으로 사람이 필요할 때 에스컬레이션하는 에이전트인데, 이는 들리는 것보다 구현하기 어렵습니다.
어려운 점은 에이전트가 자기 신뢰도를 평가하고, 진행할 위험과 사람을 방해할 비용을 추정하고, 다양한 상황에서 실시간으로 이 판단을 내려야 한다는 것입니다. 모든 작업에 통하는 보편적인 임계값은 없습니다.
신뢰도 기반 에스컬레이션
가장 흔한 패턴은 에이전트의 계획이나 출력에 대한 신뢰도에 에스컬레이션을 묶는 것입니다. 에이전트가 어떻게 진행할지 알고 결과가 옳을 것이라는 확신이 있다면, 자율적으로 진행합니다. 신뢰도가 임계값 아래로 떨어지면, 에스컬레이션합니다.
실용적인 도전은 신뢰도를 보정하는 것입니다. 모델은 자기 평가에 악명 높게 서툴러서, 때로는 틀렸을 때 자신만만하고 옳을 때 불확실합니다. 모델 신뢰도를 외부 신호로 보완하면 도움이 됩니다. 계획이 알려진 패턴과 일치하는가? 도구가 예상된 결과를 반환하고 있는가? 출력이 검증 점검을 통과하는가? 이런 객관적 신호는 모델의 주관적 신뢰도보다 더 신뢰할 만합니다.
위험 기반 에스컬레이션
에이전트가 자신만만할 때조차 일부 동작은 자율 실행에 너무 위험합니다. 데이터 삭제, 외부 통신 발송, 금융 거래, 프로덕션 코드 배포는 잘못되었을 때의 비용이 크기 때문에 에이전트의 신뢰도와 무관하게 사람의 승인을 요구해야 합니다.
이는 가드레일 개념에 매핑됩니다. 특정 동작 카테고리는 항상 에스컬레이션합니다. 에이전트의 신뢰도는 회색 영역에서 에스컬레이션할지 여부를 결정합니다. 위험 수준은 명확한 경우에 에스컬레이션할지 여부를 결정합니다.
에스컬레이션 경험 설계
에이전트가 에스컬레이션할 때, 에스컬레이션의 품질이 중요합니다. "도움이 필요합니다"는 쓸모없습니다. "사용자의 청구 플랜을 업데이트하려 시도하고 있는데, API가 인식할 수 없는 오류를 반환했습니다. 여기 오류가 있고, 여기 제가 시도한 것이 있고, 여기 제가 보는 옵션이 있습니다"는 유용합니다. 좋은 에스컬레이션은 컨텍스트를 제공하고, 지금까지 에이전트의 작업을 보여 주고, 사람이 선택할 수 있는 구체적인 옵션을 제시합니다.
사람이 빠르게 응답하실 수 있어야 합니다. 에스컬레이션이 페이지에 걸친 컨텍스트를 읽으셔야 한다면, 비용이 너무 큽니다. 에이전트는 상황을 간결하게 요약하고 명확한 결정 지점을 제시해야 합니다. 에스컬레이션을 잘 처리하는 에이전트 프레임워크는 이를 쉽게 구현할 수 있게 만들어 줍니다.
불필요한 에스컬레이션 줄이기
자동화 기회를 찾기 위해 에스컬레이션 패턴을 추적해 주십시오. 에이전트가 같은 종류의 질문을 반복적으로 에스컬레이션한다면, 그것을 처리하는 규칙이나 능력을 추가하실 수 있을 것입니다. 에스컬레이션의 30%가 "X를 할 권한이 없습니다"라면, 에이전트는 더 넓은 권한이 필요할 수도 있습니다(적절한 가드레일과 함께). 이러한 패턴을 드러낼 수 있는 에이전트 분석 도구를 검색해 보십시오.