상담원 워크플로 대체와 재시도: 무엇을 선택해야 합니까?

문제 정의: fallback과 retry는 각각 어떤 문제를 해결하나요?

에이전트 워크플로에서 오류 처리는 시스템 견고성을 보장하는 데 중요합니다. 대체 및 재시도는 모두 오류를 처리하는 방법이지만 적용 가능한 시나리오는 완전히 다릅니다. 간단히 말하면, 특정 단계가 실패하면 재시도는 "다시 시도"를 의미하고 대체는 "다른 경로를 사용"을 의미합니다.

• 재시도: 일시적이고 복구 가능한 오류에 적합합니다. 예를 들어 API 호출 시간 초과, 네트워크 지터 및 리소스를 일시적으로 사용할 수 없습니다. 재시도에는 일반적으로 눈사태를 방지하기 위한 횟수(예: 3회)와 백오프 전략(예: 지수 백오프)에 대한 제한이 있습니다.
• 대체: 영구적이거나 복구할 수 없는 오류 또는 일종의 오류가 예상되는 경우에 적용됩니다. 예를 들어 모델 반환이 잘못되었거나 은밀한 솔루션(예: 더 간단한 모델로 다운그레이드)이거나 사용자 입력이 범위를 벗어났습니다. 대체는 일반적으로 캐시된 결과 사용, 사용자에게 다시 입력하라는 메시지 표시 또는 수동 처리로 전환과 같은 대체 논리를 트리거합니다.

작업 단계: 워크플로에서 대체 및 재시도를 구현하는 방법은 무엇입니까?

재시도의 표준 프로세스 구현

1. 재시도 가능한 오류 유형 식별: 예: HTTP 5xx, 시간 초과, 속도 제한. 4xx 또는 인증 실패 시 재시도하지 마세요.
2. 최대 재시도 횟수 설정: 일반적으로 2~3회이며, 너무 많이 반복하면 전체 프로세스가 지연됩니다.
3. 백오프 전략 구성: 고정 간격(예: 1초), 지수 백오프(예: 1초, 2초, 4초) 또는 지터가 있는 백오프(천둥 같은 무리를 방지하기 위해).
4. 재시도 로그 기록: 문제를 찾는 데 편리합니다.
5. 통합 타임아웃 제어: 총 재시도 시간은 무한할 수 없습니다.

구체적인 시나리오 예: 요약을 생성하려면 에이전트가 OpenAI API를 호출해야 합니다. 때때로 네트워크가 중단되고 503이 반환됩니다. 이때, 2초 간격으로 3회 재시도 하십시오. 세 번째에도 여전히 실패하면 fallback을 입력합니다.

대체 구현을 위한 표준 프로세스

1. 대체 조치가 필요한 단계를 식별: 일반적으로 중요한 경로에서 중요하지 않은 작업 또는 명확한 성능 저하 계획이 있는 작업입니다.
2. 대안 논리 설계: 예를 들어 더 저렴하거나 빠른 모델로 교체하거나, 캐시된 데이터를 반환하거나, 사용자에게 묻거나, 후속 수동 처리를 위해 배달 못한 편지 대기열에 기록합니다.
3. 워크플로에서 대체 노드 구성: 기본 경로에서 복구할 수 없는 오류가 발생하면 자동으로 대체 노드로 이동합니다.
4. 대체 경로 테스트: 대체 논리가 제대로 작동하고 새로운 문제가 발생하지 않는지 확인합니다.

구체적인 시나리오 예: 에이전트는 사용자 의도를 파싱할 때 주로 GPT-4를 사용합니다. 그러나 GPT-4가 잘못된 JSON 형식을 반환하는 경우(영구적인 오류) 규칙 기반 정규 일치로 대체되거나 사용자에게 이를 바꾸라는 메시지가 표시됩니다.

실제 시나리오: 고객 서비스 상담원의 의사결정

제품 질문에 대한 답변을 담당하는 고객 서비스 에이전트를 구축한다고 가정해 보겠습니다. 작업 흐름은 다음과 같습니다.

1. 사용자의 질문을 받습니다.
2. 벡터 검색을 사용하여 관련 문서 조각을 찾습니다.
3. LLM을 사용하여 스니펫을 기반으로 답변을 생성합니다.
4. 사용자에게 답변을 반환합니다.

가능한 실패 시나리오는 다음과 같습니다.

• 2단계의 벡터 데이터베이스 쿼리 시간 초과: 이는 복구 가능한 오류이므로 1~2회 다시 시도해야 합니다. 그래도 실패하면 키워드 검색을 사용하여 대체할 수 있습니다(대체 계획).
• 3단계의 LLM 응답에 형식 오류 또는 답변 거부(예: "답변할 수 없습니다")가 포함되어 있습니다. 이는 영구적인 오류이므로 재시도해서는 안 됩니다(재시도해도 여전히 동일한 결과를 얻을 가능성이 높음). 그러나 "죄송합니다. 지금은 답변할 수 없습니다. 나중에 다시 시도해 주세요."와 같은 기본 답변으로 직접 대체해야 합니다.

부적절한 선택의 결과: 영구적인 오류(예: 형식 오류)에 대해 재시도를 수행하면 시간과 비용을 낭비할 뿐만 아니라 사용자에게 똑같은 쓸모없는 결과를 반환하여 경험이 저하될 수 있습니다. 반면, 일시적인 오류(예: 네트워크 시간 초과)에 대해 느린 대기 논리로 직접 대체하는 경우 불필요한 성능 저하가 발생할 수 있습니다.

가장 쉬운 함정: 세 가지 일반적인 오해

오해 1: 모든 오류에 대해 재시도를 사용하세요

많은 사람들은 실패하면 다시 시도해도 해가 되지 않을 것이라고 생각하고 다시 시도하는 데 익숙합니다. 그러나 일부 오류를 다시 시도하면 시스템에 부담만 줄 뿐입니다. 예를 들어 사용자 입력이 토큰 제한을 초과하는 경우 재시도는 토큰을 반복적으로 사용하거나 실패합니다. 올바른 접근 방식은 오류 유형을 구별하는 것입니다. 영구 오류는 직접 대체됩니다.

오해 2: 대체 경로가 완전히 테스트되지 않았습니다.

대체 코드는 작성된 후 실행되는 경우가 거의 없으므로 버그를 숨기기 쉽습니다. 실제로 트리거되면 폴백 자체가 실패하여 전체 워크플로가 붕괴될 수 있습니다. 개발 단계에서 대체 시나리오를 수동으로 트리거하고 실행 효과를 모니터링해야 합니다.

오해 3: 실패 원인 분석을 무시하다

재시도인지 대체인지 실패 이유와 컨텍스트를 기록해야 합니다. 로그가 없으면 시스템을 개선할 수 없습니다. 예를 들어 특정 단계에서 폴백이 자주 발생한다면 이는 기본 프로세스 설계에 문제가 있어 조정이 필요하다는 의미일 수 있습니다.

실패 시 Fallback 계획: Fallback도 실패하면 어떻게 되나요?

이것은 많은 사람들이 간과하는 마지막 링크입니다. 기본 경로와 대체가 모두 실패하는 경우 워크플로에는 최종 기본 동작이 있어야 합니다. 일반적인 솔루션:

• 사용자에게 일반적인 오류 메시지를 반환하고 수동 개입을 요청합니다.
• 관리자가 정기적으로 처리할 수 있도록 실패한 작업을 배달 못한 편지 대기열에 기록합니다.
• 개발팀에 알림을 보냅니다.
• 중요하지 않은 프로세스의 경우 이 단계를 건너뛰고 계속할 수 있습니다.

즉, 내결함성을 설계할 때 완전한 오류 처리 체인(재시도 -> 대체 -> 최종 실패)을 구축해야 합니다.

선택 방법: 간단한 의사결정 트리

여전히 망설이고 있다면 다음을 사용하여 빠른 결정을 내릴 수 있습니다.

• 일시적인 상황으로 인해 오류가 사라질 수도 있나요? 그렇다면 재시도를 사용하세요.
• 오류는 현재 방법이 실현 가능하지 않지만 대안이 존재함을 나타냅니까? 그렇다면 대체를 사용하십시오.
• 둘 다 불가능하다면 실패를 받아들이고 단계적으로 다운그레이드하세요.

실제 프로젝트에서는 워크플로 다이어그램의 각 단계에 대한 내결함성 전략을 명확하게 표시하고 팀과 함께 검토하는 것이 좋습니다.

이제 에이전트 워크플로를 확인할 수 있습니다. 명확한 대체가 부족한 단계는 몇 개입니까? 오류가 발생하면 맹목적으로 재시도되는 단계는 몇 개입니까? 이러한 세부 사항을 최적화하면 시스템 안정성이 크게 향상됩니다.